From owner-mpls@UU.NET Sun Jul 2 16:03: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 QAA09852 for ; Sun, 2 Jul 2000 16:03:28 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwdk05535; Sun, 2 Jul 2000 20:02:50 GMT Received: by mail-control.mail.uu.net id QQiwdk03829 for mpls-outgoing; Sun, 2 Jul 2000 20:02: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 QQiwdk02500 for ; Sun, 2 Jul 2000 20:02: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 QQiwdk18143 for ; Sun, 2 Jul 2000 16:02:01 -0400 (EDT) Received: from dirty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: ns1.research.bell-labs.com [204.178.16.6]) id QQiwdk24616 for ; Sun, 2 Jul 2000 20:02:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Sun Jul 2 16:00:34 EDT 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 QAA02723; Sun, 2 Jul 2000 16:01:12 -0400 (EDT) Message-ID: <395FA056.D597D2A2@dnrc.bell-labs.com> Date: Sun, 02 Jul 2000 13:04:38 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois Le Faucheur CC: mpls@UU.NET Subject: Simplifying tunnel modes Re: Last Call feedback on MPLS-Diff-Serv References: <200006121753.NAA22286@lir.cisco.com> <200006262008.WAA24871@europe.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Francois, Replying to another part of our discussion (simplifying the tunnel mode specifications in 2.6.3 and 2.6.4): Francois Le Faucheur wrote: [..] > >#5 Vastly simplify sections 2.6.3 and 2.6.4 (tunnel models) > > > > The last paragraph of 2.6.4 admits that basically the only > > difference between the Uniform and Pipe models is in the > > push/pop behaviors. At the very least 2.6.4 can be vastly > > simplified by simply specifying the 'Pipe Model' in terms > > of how it differs from the 'Uniform Model' in 2.6.3 (right > > now 2.6.4 contains a load of redundant descriptive text). > > > > Yes, as pointed out in the draft, the two models "only" differ in > their push and pop behaviours. But the push and pop behaviours > (with/without PHP) are the complex aspects discussed in a big part > of the text anyway (the swap behavior is quite straight-forward > in both models). So , saying they "only" differ by push/pop doesn't > mean that you would save that much text by describing operations > of Pipe as delta over Uniform. My gut feel is that descriptions of the push/pop behaviors could be made much more concise - I wont argue that they're the key differences between the two models. But without sitting down to rewrite both sections, I'll settle for the edits you propose below :) > However, we could simplify 2.6.3 by combining the 2nd paragraph > ("With this Uniform Model:...") with the last paragraph ("For > support of the Uniform Model over an LSP ..."). Yes, that would be a great improvement. The last paragraph (and its bullet points) in 2.6.3 practically represents the necessary and sufficient text to describe Uniform mode of operation. The redundancy between the 2nd para (and bullets) and the last para (and bullets) was one of things that worried me about this section. I would also take a further step and remove descriptive text regarding LSR hops that only perform label swapping. Since we are, by definition, talking about MPLS I think readers can be assumed to understand that in the middle of an LSP LSRs only operate on the outermost header. (Also, the 2nd last bullet in the 2nd para "-It is also possible to not use PHP..." seems rather convoluted in that it covers non-PHP as a special case, whereas we all know that non-PHP is simply where the penultimate LSR is just a regular old LSR doing regular old label swapping. In the non-PHP case indeed there is nothing special about a penultimate LSR anyway. Hopefully this description will disappear when you collapse the 2nd and last paras in 2.6.3) > Similarly we could simplify 2.6.4 by combining the 3rd paragraph > ("With this Pipe Model: ...") with the two paragraphs before last > ("For support of the Pipe Model over an LSP..."). Yes, that would similarly be a great improvement (applying again my comments about removing special text discussing LSRs that only 'swap' since that's just regular MPLS, and deconvolute discussions about non-PHP penultimate behavior since that's just regular swapping too.) (Finally, I wonder how normative this tunnel text ought to be anyway, given that its architectural genesis lies in the DiffServ WGs tunnel document currently heading for Informational status? Aren't we preempting the evolution of DiffServ-style tunneling architectures?) cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mpls@UU.NET Mon Jul 3 05:43: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 FAA28339 for ; Mon, 3 Jul 2000 05:43:30 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwfm19092; Mon, 3 Jul 2000 09:42:46 GMT Received: by mail-control.mail.uu.net id QQiwfm14552 for mpls-outgoing; Mon, 3 Jul 2000 09:42: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 QQiwfm14547 for ; Mon, 3 Jul 2000 09:42:11 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 QQiwfm05446 for ; Mon, 3 Jul 2000 05:42:01 -0400 (EDT) From: navin.agrawal@ecapsol.com Received: from c004.sfo.cp.net by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: c004-h026.c004.sfo.cp.net [209.228.13.43]) id QQiwfm18825 for ; Mon, 3 Jul 2000 09:42:00 GMT Received: (cpmta 29013 invoked from network); 3 Jul 2000 02:41:59 -0700 Date: 3 Jul 2000 02:41:59 -0700 Message-ID: <20000703094159.29012.cpmta@c004.sfo.cp.net> X-Sent: 3 Jul 2000 09:41:59 GMT Received: from [203.197.208.5] by mail.ecapsol.com with HTTP; 03 Jul 2000 02:41:59 PDT Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: jzou@mars.iol.unh.edu Cc: mpls@UU.NET X-Mailer: Web Mail 3.6.3.1 Subject: Re: Several questions about RSVP Sender: owner-mpls@UU.NET Precedence: bulk Hi, > I hope some one can help me. > > I have some questions about RSVP-TE on > "draft-ietf-mpls-rsvp-lsp-tunnel-05.txt": > > 1. On page 18, section 4.2 > "L3PID an identifier of the layer 3 protocal using this path. > Standard Ethertype values are used" > My question is where I can find out these Standard Ethertype values on > the layer 3 protocal ? Read RFC1700. > 2. On page 21, line 8, section 4.2.1, > "The LABEL_REQUEST SHOULD be stored in the Path State Block", to > this, my consideration is that the LRO SHOULD be stored in the Path State > Block in the intermediate nodes, not ingress node and egress node. Even If I go by your thought as well, LRO should be stored in the PSB of the egress node as well. Strictly my opinion. Regards, Navin > But there is another possible: the LRO is stored in all nodes > including ingress and egress node. Which one is correct or there is > another explaination? > > > 3. on page 48, line 16, section 5.3 > > "On receipt of a message containing a HELLO REQUEST object, the > receiver MUST generate a Hello message containing a HELLO ACK object" > > "The receiver SHOULD also verify that the neighbor has not reset. > This is done by comparing the sender's Src_Instance field value with > the previously received value. If the value differs, then a node > MUST treat the neighbor as if communication has been lost." > > my confused is about "the previously received value": if the receiver > received a message containing a HRO first time(no previously > received value), then the value should be difference(I guess), then the > communication has been lost at the first time by the explaination of > draft. It seems that establishing communication is not possible. But it > is possible. The question is how they can do it. > > > Thanks > > > Jie Zou > > > ------------------- > MPLS Consortium > IOL, UNH > ------------------- From owner-mpls@UU.NET Mon Jul 3 09:43: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 JAA01911 for ; Mon, 3 Jul 2000 09:43:19 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwgc11906; Mon, 3 Jul 2000 13:42:13 GMT Received: by mail-control.mail.uu.net id QQiwgc13634 for mpls-outgoing; Mon, 3 Jul 2000 13:41: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 QQiwgc13625 for ; Mon, 3 Jul 2000 13:41: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 QQiwgc01125 for ; Mon, 3 Jul 2000 09:41:40 -0400 (EDT) From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQiwgc14522 for ; Mon, 3 Jul 2000 13:41:39 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id WAA29152 for ; Mon, 3 Jul 2000 22:42:20 +0900 (KST) X-OpenMail-Hops: 2 Date: Mon, 3 Jul 2000 21:39:02 +0800 Message-Id: Subject: LDP Test Cases MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Mon, 3 Jul 2000 21:34:32 +0800" ;Modification-Date="Mon, 3 Jul 2000 21:38:57 +0800" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hello, I would like to know whether there are any test cases for MPLS-LDP available on the net. If so can u pls give me the details of it. thanks in advance seenu From owner-mpls@UU.NET Mon Jul 3 09:54: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 JAA02013 for ; Mon, 3 Jul 2000 09:54:06 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwgd19804; Mon, 3 Jul 2000 13:52:51 GMT Received: by mail-control.mail.uu.net id QQiwgd14571 for mpls-outgoing; Mon, 3 Jul 2000 13:52:14 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiwgd14564 for ; Mon, 3 Jul 2000 13:52:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiwgd02564 for ; Mon, 3 Jul 2000 09:51:55 -0400 (EDT) Received: from aix10.segi.ulg.ac.be by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: aix10.segi.ulg.ac.be [139.165.32.133]) id QQiwgd18958 for ; Mon, 3 Jul 2000 13:51:55 GMT Received: from [139.165.11.33] (ssamac13.montefiore.ulg.ac.be [139.165.11.33]) by aix10.segi.ulg.ac.be (8.9.1a/8.9.1a) with SMTP id PAA93680 for ; Mon, 3 Jul 2000 15:51:54 +0200 X-Sender: leduc@pop.montefiore.ulg.ac.be Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Eudora F1.5.4 Date: Mon, 3 Jul 2000 15:52:47 +0100 To: mpls@UU.NET From: leduc@montefiore.ulg.ac.be (Guy Leduc) Subject: (Post-)Doctoral positions on MPLS traffic engineering Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA02013 Hi, (Post-)Doctoral positions are available at the University of Liège, in the Research Unit in Networking (RUN), on the following topic: "Intra-domain traffic engineering for IP/MPLS over DWDM networks" The work will take place in the framework of a European funded project. The expected starting date is October 2000 and the duration is expected to be 30 months. The University of Liege: Founded in 1817, the University of Liege is the only public community-sponsored university in the French-speaking part of Belgium, which offers a complete range of university courses at undergraduate and post-graduate levels. It is divided into eight faculties: Philosophy and Letters; Law and School of Criminology; Sciences; Medicine; Applied Sciences; Veterinary Medicine; Psychology and Educational Sciences; Economics, Management and Social Sciences. Its staff comprises 3,300 employees, including 400 lecturers and 2000 researchers. 18% of its 14,000 students come from 70 different countries. Lecturers, researchers and students take part in exchange programmes with over 300 institutions. The quality and originality of the research work (pure and applied) have met with international recognition. The University of Liege is involved in many European and international research programmes. The Research Unit in Networking (RUN): RUN is the Research Unit in Networking of the University of Liege. It is part of the Montefiore Institute and the Faculty of Applied Science. The unit was founded by Prof. A. Danthine in 1972 and is now headed by Prof. Guy Leduc since 1997. Research in RUN bears on computer networks: (a) Quality of Service and multicast in IP networks, (b) (active) communication services and middleware protocols for multimedia applications, (c) study of TCP/IP over ATM networks, and (d) formal specification, verification, implementation and testing of these systems, and especially of real-time systems. More information about RUN can be found at: http://www-run.montefiore.ulg.ac.be Interested candidates are invited to send their Curriculum Vitae to (and for further information to get in touch with) : Prof. Guy Leduc Université de Liege, Institut Montefiore, B28, B-4000 Liège 1, Belgium Email: leduc@montefiore.ulg.ac.be Tel: +32 4 366 26 98 (secretariat: +32 4 366 26 91) - Fax: +32 4 366 29 89 ________________________________________________________________________ Prof. Guy Leduc Tel : +32 4 366 26 98 Universite de Liege Secr : +32 4 366 26 91 Reseaux Informatiques Fax : +32 4 366 29 89 Research Unit in Networking (RUN) leduc@montefiore.ulg.ac.be Institut d'Electricite Montefiore, B 28, B-4000 LIEGE 1, BELGIUM http://www-run.montefiore.ulg.ac.be/users/leduc.html From owner-mpls@UU.NET Mon Jul 3 11:06: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 LAA03035 for ; Mon, 3 Jul 2000 11:06:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwgi25807; Mon, 3 Jul 2000 15:05:23 GMT Received: by mail-control.mail.uu.net id QQiwgi12105 for mpls-outgoing; Mon, 3 Jul 2000 15:04: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 QQiwgi12096 for ; Mon, 3 Jul 2000 15:04: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 QQiwgi08843 for ; Mon, 3 Jul 2000 11:04:39 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiwgi13098 for ; Mon, 3 Jul 2000 15:04:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA06776 for mpls@uu.net; Mon, 3 Jul 2000 11:04:38 -0400 (EDT) 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 QQiwgi12074 for ; Mon, 3 Jul 2000 15:04:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiwgi12618 for ; Mon, 3 Jul 2000 11:03:53 -0400 (EDT) Received: from hawk.CrescentNetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.177.194.54]) id QQiwgi12384 for ; Mon, 3 Jul 2000 15:03:53 GMT Received: from crescentnetworks.com (langille.in.crescentnets.com [192.168.29.105]) by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id LAA10798; Mon, 3 Jul 2000 11:03:52 -0400 (EDT) Message-ID: <3960AC2D.96B780DF@crescentnetworks.com> Date: Mon, 03 Jul 2000 11:07:25 -0400 From: Paul Langille Organization: Crescent Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: MPLS List Subject: NIST Switch Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Greetings. Is anyone using the NIST Switch source code (http://www.antd.nist.gov/itg/nistswitch/)? (We are having trouble installing the code and we are not getting any responses from the NIST Switch mailing lists.) Thanks Paul -- Paul Langille e-mail: langille@crescentnetworks.com Crescent Networks phone: (978) 244-9002 x244 201 Riverneck Road fax: (978) 244-9211 Chelmsford, MA 01824 From owner-mpls@UU.NET Mon Jul 3 11:24: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 LAA03219 for ; Mon, 3 Jul 2000 11:24:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwgj27868; Mon, 3 Jul 2000 15:23:46 GMT Received: by mail-control.mail.uu.net id QQiwgj13501 for mpls-outgoing; Mon, 3 Jul 2000 15:23: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 QQiwgj13489 for ; Mon, 3 Jul 2000 15:22:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiwgj18152 for ; Mon, 3 Jul 2000 11:22:45 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiwgj27166 for ; Mon, 3 Jul 2000 15:22:44 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA08011 for mpls@uu.net; Mon, 3 Jul 2000 11:22:43 -0400 (EDT) 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 QQiwgj13422 for ; Mon, 3 Jul 2000 15:22: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 QQiwgj15389 for ; Mon, 3 Jul 2000 11:21:55 -0400 (EDT) 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 QQiwgj26428 for ; Mon, 3 Jul 2000 15:21:55 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 4D9A41D4F; Mon, 3 Jul 2000 17:21:41 +0200 (MET DST) Received: from flefauch-8kcdt.cisco.com (nice-dhcp15.cisco.com [144.254.60.37]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id RAA20384; Mon, 3 Jul 2000 17:21:34 +0200 (MET DST) Message-Id: <4.0.2.20000703162853.012af1f0@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 03 Jul 2000 16:55:17 +0200 To: Grenville Armitage From: Francois Le Faucheur Subject: Re: Simplifying tunnel modes Re: Last Call feedback on MPLS-Diff-Serv Cc: Francois Le Faucheur , mpls@UU.NET In-Reply-To: <395FA056.D597D2A2@dnrc.bell-labs.com> References: <200006121753.NAA22286@lir.cisco.com> <200006262008.WAA24871@europe.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Grenville, At 13:04 02/07/2000 -0700, Grenville Armitage wrote: >Hi Francois, > >Replying to another part of our discussion (simplifying >the tunnel mode specifications in 2.6.3 and 2.6.4): >> However, we could simplify 2.6.3 by combining the 2nd paragraph >> ("With this Uniform Model:...") with the last paragraph ("For >> support of the Uniform Model over an LSP ..."). > >Yes, that would be a great improvement. The last paragraph (and Will do. I may get you to check the new text off-line. >its bullet points) in 2.6.3 practically represents the necessary >and sufficient text to describe Uniform mode of operation. The >redundancy between the 2nd para (and bullets) and the last para >(and bullets) was one of things that worried me about this section. > >I would also take a further step and remove descriptive text >regarding LSR hops that only perform label swapping. Since we >are, by definition, talking about MPLS I think readers can be >assumed to understand that in the middle of an LSP LSRs only >operate on the outermost header. > I'd like to keep the statement about intermediate LSRs. It is one sentence long and simple. You may argue that it is stating the obvious but I think it should be clearly stated once. >(Also, the 2nd last bullet in the 2nd para "-It is also possible >to not use PHP..." seems rather convoluted in that it covers >non-PHP as a special case, agreed. >whereas we all know that non-PHP is >simply where the penultimate LSR is just a regular old LSR doing >regular old label swapping. In the non-PHP case indeed there is >nothing special about a penultimate LSR anyway. Hopefully this agreed. >description will disappear when you collapse the 2nd and last >paras in 2.6.3) > >> Similarly we could simplify 2.6.4 by combining the 3rd paragraph >> ("With this Pipe Model: ...") with the two paragraphs before last >> ("For support of the Pipe Model over an LSP..."). > >Yes, that would similarly be a great improvement (applying again my >comments about removing special text discussing LSRs that only >'swap' since that's just regular MPLS, and deconvolute discussions >about non-PHP penultimate behavior since that's just regular swapping >too.) > ditto. thank you Francois _________________________________________________________________ Francois Le Faucheur Development Engineer, IOS Layer 3 Services Cisco Systems Office Phone: +33 4 92 96 75 64 Home Office Phone: +33 4 92 94 00 78 Mobile : +33 6 89 108 159 Vmail: +33 1 58 04 62 66 Fax: +33 4 92 96 79 08 Email: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Mon Jul 3 11:29: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 LAA03291 for ; Mon, 3 Jul 2000 11:29:57 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwgj02308; Mon, 3 Jul 2000 15:29:18 GMT Received: by mail-control.mail.uu.net id QQiwgj13829 for mpls-outgoing; Mon, 3 Jul 2000 15:28:54 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiwgj13814 for ; Mon, 3 Jul 2000 15:28: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 QQiwgj16180 for ; Mon, 3 Jul 2000 11:28:32 -0400 (EDT) Received: from mason2.gmu.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQiwgj16964 for ; Mon, 3 Jul 2000 15:28:32 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id LAA15545; Mon, 3 Jul 2000 11:28:13 -0400 (EDT) Date: Mon, 3 Jul 2000 11:28:13 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: seenu@samsung.co.kr cc: mpls@UU.NET Subject: Re: LDP Test Cases In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Seenu, Advanced Internet Lab(AIL) at Geroge Mason University, Fairfax, Va is is involved in testing the interoperability between the various implementations of MPLS. For this purpose, AIL has formulated a comprehensive set of test plans that are focussed on MPLS, and are derived from the "AIL MPLS core capability set", which has copious input from the industry. The AIL interoperability test plan includes the test cases for the following: 1) Traffic Engineering over MPLS 2) LDP 3) RSVP-TE 4) CR-LDP 5) IS-IS (including TE extensions) 6) OSPF (including TE extensions) 7) BGP-4/MPLS 8) ATM-LSRs 9) Other requirement driven specific tests. The test plans noted above are ready and documented, but because of binding Non-Disclosure agreements with the sponsors of the lab, the the plans are not available for public review. However, the precedent AIL core capability set will be available on our homepage in the near future. Sponsors of the lab include major router vendors, ISPs and test equipment manufacturers. For further information regarding the functioning and sponsorship of the Advanced Internet Lab, please visit our web site at http://ail.gmu.edu/. Regards Rajiv Papneja On Mon, 3 Jul 2000 seenu@samsung.co.kr wrote: > Hello, > > I would like to know whether there are any test cases for MPLS-LDP available on the net. > If so can u pls give me the details of it. > > thanks in advance > > seenu > ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4700 email: rpapneja@osf1.gmu.edu visit us at http://ail.gmu.edu/ ******************************** From owner-mpls@UU.NET Mon Jul 3 13:25: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 NAA05185 for ; Mon, 3 Jul 2000 13:25:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwgr24536; Mon, 3 Jul 2000 17:24:47 GMT Received: by mail-control.mail.uu.net id QQiwgr20019 for mpls-outgoing; Mon, 3 Jul 2000 17:24:15 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiwgr19947 for ; Mon, 3 Jul 2000 17:24:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiwgr19373 for ; Mon, 3 Jul 2000 13:24:02 -0400 (EDT) Received: from dirty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: ns1.research.bell-labs.com [204.178.16.6]) id QQiwgr24404 for ; Mon, 3 Jul 2000 17:24:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Jul 3 13:23:13 EDT 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 NAA07895; Mon, 3 Jul 2000 13:23:52 -0400 (EDT) Message-ID: <3960CCFD.2F6D4E@dnrc.bell-labs.com> Date: Mon, 03 Jul 2000 10:27:25 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois Le Faucheur CC: mpls@UU.NET Subject: Re: Simplifying tunnel modes Re: Last Call feedback onMPLS-Diff-Serv References: <200006121753.NAA22286@lir.cisco.com> <200006262008.WAA24871@europe.cisco.com> <4.0.2.20000703162853.012af1f0@europe.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Francois, One quibble: Francois Le Faucheur wrote: > > Grenville, > > At 13:04 02/07/2000 -0700, Grenville Armitage wrote: [..] > >I would also take a further step and remove descriptive text > >regarding LSR hops that only perform label swapping. Since we > >are, by definition, talking about MPLS I think readers can be > >assumed to understand that in the middle of an LSP LSRs only > >operate on the outermost header. > > > > I'd like to keep the statement about intermediate LSRs. It is > one sentence long and simple. You may argue that it is stating > the obvious but I think it should be clearly stated once. I certainly think it is reasonable to remind readers that a transit LSR just forwards using the top label. But my feeling is that this concept is raised already in a number of ways around the document: - Last sentence, first para, section 1 - Last sentence, first para, section 1.2 - 2nd sentence, 1st para, section 1.3 - All of section 2.1, arguably all of 2.4 (And specifically in section 2.6) - Section 2.6.1, sub-bullet 2 (the quote from MPLS_ARCH) - Section 2.6.3, 1st para, 3rd&4th sentences beginning "In this model" - Section 2.6.3, 2nd bullet under "With this Uniform Model:" - Section 2.6.4, 2nd bullet under "With this Pipe Model:" .... I would suggest it would be sufficient to remind readers that "LSRs in the middle of an LSP perform forwarding, queuing, and scheduling based solely on the outer MPLS Header consisting of Label and EXP field." This clarification could be placed at the start of section 2 as a whole, and thereby allow removal of similar subsequent texts. IMHO :) cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mpls@UU.NET Mon Jul 3 21:03: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 VAA08895 for ; Mon, 3 Jul 2000 21:03:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwhw17337; Tue, 4 Jul 2000 01:02:45 GMT Received: by mail-control.mail.uu.net id QQiwhw23172 for mpls-outgoing; Tue, 4 Jul 2000 01:02: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 QQiwhw22705 for ; Tue, 4 Jul 2000 01:02: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 QQiwhw21316 for ; Mon, 3 Jul 2000 21:02:16 -0400 (EDT) Received: from crufty.research.bell-labs.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: ns2.research.bell-labs.com [204.178.16.49]) id QQiwhw16734 for ; Tue, 4 Jul 2000 01:02:01 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Mon Jul 3 21:01:48 EDT 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 VAA10205; Mon, 3 Jul 2000 21:02:27 -0400 (EDT) Message-ID: <39612EF6.C7DFE11D@dnrc.bell-labs.com> Date: Mon, 03 Jul 2000 17:25:26 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois Le Faucheur CC: mpls@UU.NET Subject: Rationalizing E-/L-LSPs Re: Last Call feedback on MPLS-Diff-Serv References: <200006121753.NAA22286@lir.cisco.com> <200006262008.WAA24871@europe.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Francois, Following up on this subtopic (rationalizing sections 3 and 4) I only have some suggestions and observations rather than strong requests. Mostly I'm working with a gut feel that there's a way to combine many of the similar elements in the definitions of both E- and L-LSPs. Hopefully the following might be helpful :-) Francois Le Faucheur wrote: [..] > >#8 Rationalize sections 3 and 4 [..] > > (Indeed, these two sections could probably be > > beneficially collapsed into one section.) > > I am not sure what you are calling the "two sections" (ie 3 and 4 , > or 3.5 and 4.5) I was thinking of 3 and 4 as a whole. > Although the descriptions of E-LSPs and L-LSPs have a number of things > in common, they have a lot of differences: > - 3.2 and 4.2 are completely differnet. 3.2 uses > preconfigured/signaled mappings applying on EXP > only, 4.2 uses MAndatory/Default mappings applying > to EXP/CLP/DE. It occured me that section 3.2 is really a subset of 4.2 that differs primarily in the scope of default mappings. I would write a combined version of these sections as: "Populating Encaps-->PHB mapping" - For an E-LSP this table only contains mappings of the form EXP->PHB. In the absence of any other mappings configured or signalled by the network operator for the E-LSP, the default mapping maps all EXP values to the BE PHB. - For an L-LSP this table may have one or more entries, and in each case the entries indicate only the drop precedence to be applied within the context of the PSC associated with the L-LSP. - [Go on to list the current default mandatory EXP->PHB, CLP->PHB, and DE->PHB mappings] Also, in light of sections 7, 8, 9, and 10 specifying the circumstances underwhich each of the various types of Encaps<->PHB mappings are utilized, we could remove the equivalent descriptive texts from 4.2.1, 4.2.2, and 4.2.3 (e.g. section 4.2.3's "If the LSR does not terminate an MPLS Shim Layer over this incoming label..." description is superceded by text in section 9, and therefore isn't needed in 4.2.3) Focus on what the mapping rules *are* in 4.2, and leave it until section 7, 8, 9, or 10 to specify *when* each of these mappings would be used. > - 3.4 and 4.4 are very differnet. 3.4 must have a PHB-->EXP > mapping while 4.4 may or may not have a PHB-->EXP mapping. Okay. So both sections could be replaced by a single section discussing PHB->EXP mappings, and a qualifying statement that an E-LSP requires such a mapping while an L-LSP MAY have such a mapping ? > 3.4 uses configured signaled mapping to populate it. 4.4 uses > Mandatory mapping. If I was writing this as a single section, a single line of text would suffice to note whether mappings could be configured, signaled, or used mandatory mappings. > 4.4 needs to cover the cases of LC-ATM > and LC-FR while 3.4 shoudl not. 4.4.4 is the same as 3.4.4 > and already use a refernec to 3.4.4.1. I dont follow see that this is a major distinction. For example, sections 3.4.2 and 4.4.2 are practically identical bar some minor special case observations for 4.4.2 - especially clear since much of the wordage in 4.4.2 defaults to "Use the mappings in 3.4.2.1". So instead, why not just use the text in 3.4.2, the default mappings in 3.4.2.1, and the special-case text in the final para of 4.4.2 to clarify some differences between E- and L-LSP scenarios when mapping PHB->CLP ? I notice equivalent similarities between other sections 3.4.* and 4.4.*, which is why it seems to me there's a lot of redundant text. (For example, I struggle to find meaningful differences between 3.4.4 and 4.4.4 that would prevent them being merged, or one being a reference to the other.) > So section 3 and section 4 could not be collapsed together. > > 3.3 is indeeed a subset of 4.3, but 3.3 already boils down to > a single paragraph so I am not sure we would gain much by replacing > that with a cross-reference. Also you might have to clarify that > only a subset of the cases are relevant to E-LSPs to avoid confusion. > So there is not much to be gained there. At least it does show we could replace these two sections by a single one (if one was inclined to collapse 3 and 4 together, which I'm hoping to convince you is feasible and would greatly benefit your document :-) (Actually, I'd even go so far as to suggest that 4.3.1, 4.3.2, and 4.3.3 are superfluous - since all they essentially state is "If the 'Encaps-->PHB mapping' is of the form 'XXX-->PHB' then determine the PHB by looking at the XXX field". This hardly seems to make 4.3 and 3.3 all that different, since 3.3 is the same process applied solely to the EXP-->PHB case, i.e. equivalent to 4.3 & 4.3.1) > 3.5 and 4.5 are the only ones that could usefully be combined. > With very minor editing around, 4.5 could be replaced by a > reference to 3.5. I think that would be beneficial, yes. I would also suggest that 3.6 and 4.6 (on merging) could easily be written as a single section too, since the principles of merging are common. It is only the specific restrictions on when merging can/cannot occur that differ - and in each section you've already captured those restrictions in a single sentence anyway. > > > A lot of the wording in both sections ought to be tightened > > up significantly to focus primarily on the normative > > statements. > > > > Could you provide specific suggestions? or at least point us towards > the issues you see? Hopefully the above helps somewhat :) cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mpls@UU.NET Mon Jul 3 21:05:59 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08916 for ; Mon, 3 Jul 2000 21:05:59 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwhw19137; Tue, 4 Jul 2000 01:05:19 GMT Received: by mail-control.mail.uu.net id QQiwhw26837 for mpls-outgoing; Tue, 4 Jul 2000 01:04: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 QQiwhw26831 for ; Tue, 4 Jul 2000 01:04: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 QQiwhw27518 for ; Mon, 3 Jul 2000 21:04:33 -0400 (EDT) Received: from crufty.research.bell-labs.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: ns2.research.bell-labs.com [204.178.16.49]) id QQiwhw08534 for ; Tue, 4 Jul 2000 01:04:05 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Mon Jul 3 21:02:20 EDT 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 VAA10211; Mon, 3 Jul 2000 21:03:00 -0400 (EDT) Message-ID: <39613867.B85BC750@dnrc.bell-labs.com> Date: Mon, 03 Jul 2000 18:05:43 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois Le Faucheur CC: mpls@UU.NET Subject: Sections 7, 8, 9 & 10 Re: Last Call feedback on MPLS-Diff-Serv References: <200006121753.NAA22286@lir.cisco.com> <200006262008.WAA24871@europe.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Francois, Wrapping up the last open issue, I promise ;) Francois Le Faucheur wrote: [..] > At 01:26 26/06/2000 -0700, Grenville Armitage wrote: [..] > >#10 Why is section 7 here? > > > > Section 7 repeats material that is redundant for a reader who > > gets this far into the document. Clearly the mechanisms for > > handling MPLS over PPP are documented elsewhere, and this > > document has already stated how various Encaps<->PHB mappings > > are built for E- and L-LSPs. Section 7 ought to be removed, > > perhaps to an informational/applicability document. > > Section 7 is NOT redundant. It specifies , out of all the previously > defined options, which ones are MUST and which ones are MAY for PPP > interfaces. Unless you specify that you may have one implemnetation > supporting one option and another implementation supporting another > option which prevents actual interoperability. Oh, I certainly agree such information is worthwhile. The MUST/MAY text in section 7 just seemed overly wordy (and that probably made me feel a lot of it wasn't neeeded). It simply boils down to saying that "E-LSPs with configured EXP<-->PHB mappings MUST be supported, signalled mappings MAY be supported, and L-LSPs with signalled mappings MAY be supported". There, done in one sentence :-) (There are couple of instances of "..then it MUST do so in compliance with all the material from this specification pertaining to.." which is just distracting fluff - the normative text is normative, no need to add eyestrain to the readers by restating that they're reading a normative spec ;) (7.2 and 7.3 could also be collapsed into 7.1 by removing the words "..specified in section 7.1.." from each and removing the subsection headings.) > >#11 Why are sections 8 and 9 here? > > > > Sections 8&9 suffer the same question of focus as section 7. > > How an ATM or FR interface operates is pretty much covered by > > existing MPLS documents - excluding perhaps the recommendation > > to use EPD for ATM, I dont see sections 8&9 adding anything > > normative to what has already been stated earlier in the document. > > They ought to follow section 7 into another document (or oblivion). > > > > Same as above, these sections clarify which of the various options > are applicable to these media. > Also it clarifies media specific issues which have come up during > the WG progress (eg that the requirement is for ATM LSRs to support PHB > scheduling rather than "traditional" ATM scheduling, that only two drop > levels are supported , that EPD is a good idea, that the spec only > covers the case where the shim layer is used...) > > I believe this is useful information and should be kept. Okay. I would suggest removing a few instances of redundant "..in compliance with all the material from this specification pertaining to.." wordage. However, 2nd para in 8.2 "Since there is only one bit..." seems unecessary in light of all the previous discussion about how to map PHB->CLP for L-LSPs (and oddly it points back to DIFF_AF as the normative behavior reference, instead of the PHB->CLP mapping rules already stated in this document). Ditto for 2nd para in 9.2 - I'd have thought a backwards reference to this document's own PHB->DE mapping rules would be less confusing to readers. > >#12 Why is section 10 here? > > > > Again, as with section 7 there's an issue of focus here. > > No new normative text exists here, and it is at best a subset > > of section 7 anyway. > > > > Section 10 is NOT redundant. It specifies , out of all the previously > defined options, which ones are MUST and which ones are MAY for LAN > interfaces. Unless you specify that, you may have one implemnetation > supporting one option and another implementation supporting another > option which prevents actual interoperability. > > We could easily group it with section 7 though. Folding LSR over LAN interfaces into section 7 would be good. cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mpls@UU.NET Tue Jul 4 04:45: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 EAA25835 for ; Tue, 4 Jul 2000 04:45:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwja07846; Tue, 4 Jul 2000 08:44:48 GMT Received: by mail-control.mail.uu.net id QQiwja09402 for mpls-outgoing; Tue, 4 Jul 2000 08:44:23 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiwja09393 for ; Tue, 4 Jul 2000 08:44: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 QQiwja13408 for ; Tue, 4 Jul 2000 04:44:20 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiwja07490 for ; Tue, 4 Jul 2000 08:44:15 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id EAA15559 for mpls@uu.net; Tue, 4 Jul 2000 04:44:15 -0400 (EDT) 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 QQiwja09376 for ; Tue, 4 Jul 2000 08:43: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 QQiwja19989 for ; Tue, 4 Jul 2000 04:43:50 -0400 (EDT) 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 QQiwja07306 for ; Tue, 4 Jul 2000 08:43:50 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 96C4F103; Tue, 4 Jul 2000 10:43:48 +0200 (MET DST) Received: from flefauch-8kcdt.cisco.com (nice-dhcp15.cisco.com [144.254.60.37]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id KAA17295; Tue, 4 Jul 2000 10:43:40 +0200 (MET DST) Message-Id: <4.0.2.20000704093433.021468c0@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 04 Jul 2000 10:29:15 +0200 To: "tom worster" From: Francois Le Faucheur Subject: New Error Codes RE: draft-ietf-mpls-diff-ext-05.txt comments Cc: "'Shahram Davari'" , "'mpls@uu.net'" In-Reply-To: <000701bfe04d$1e188410$a803010a@tst.ennovatenetworks.com> References: <336ECDAFDF7DD311B9E30090277AEE4101B40647@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 Hello, Here's a proposal for review, to address the thread on New Error Codes. 1) "per-LSP context allocation failure" ========================================= * Add one Error Value to the "Diff-Serv Error" (in RSVP section 5.5): 5 Per-label context allocation failure * Add corresponding text in the RSVP section "5.3 Handling Diff-Serv Object". Something like: "A node receiving a PAth message with the DIFFSERV object, which recognizes the DIFFSERV object but that is unable to allocate the required per-LSP Diff-Serv context sends a PathErr with the error code "Diff-Serv Error" and the error value "Per-label context allocation failure". * similar additions to coresponding LDP sections 2) "Policy Control Failure" =========================== This refers to the last example given below by Tom where an LSP set-up may be rejected because of policies. Regular RSVP already has an Error Code for reservations rejected because of Policy Control: "Error Code = 02: Policy Control failure Reservation or path message has been rejected for administrative reasons, for example, required credentials not submitted, insufficient quota or balance, or administrative preemption. This Error Code may appear in a PathErr or ResvErr message. Contents of the Error Value field are to be determined in the future." I would propose to rely on this existing error code. Would that be acceptable or do you see a lot of value in identifying that it is a "Diff-Serv Policy Control Failure"? Thanks Francois At 11:33 27/06/2000 -0400, tom worster wrote: >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of >Shahram Davari > >> Bora, >> >> Could you please identify why/how a node could understand the Diffserv >> object and the E-LSP C-type and still can't support the >> signaled E-LSP. >> >> -Shahram >> >> >From: Bora Akyol [mailto:akyol@pluris.com] >> > >> > >> >Why not have another error code for nodes that understand the >> >DS object but can >> >not provide per-label context. This makes sense to me. > > >i think bora's suggestion makes sense. > >one example that fits: you recently described a method of >cacheing exp->phb mappings (excerpt from your mail below). the >method was an example of an lsr design that requires less >memory in total than one that stores a mapping with each lsp. >it's probably not worth using that cacheing method unless the >maximum number of mappings the lsr can cache is designed to be >smaller than the maximum number of lsps it can simultaneously >support. if the mapping cache were to be exhausted, the error >code bora described would be appropriate. > >none of the error/status codes defined seem appropriate in >this case: the ds object/tlv was not unexpected; the >mapping is not invalid; and the phbs are not unsupported. >"cannot provide per-label context" sounds like it would >fit. > >another example: for reasons associated with routeing, a >network may want to keep certain sets of phbs separated >from each other on different lsps. in such a case, lsrs might >be configured to not accept certain combinations of phbids >in an e-lsp ds object/tlv. (i can imagine other reasons to >use similar policies.) > >c u >tom > > > >> -----Original Message----- >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram >> Davari >> Sent: Tuesday, June 06, 2000 11:54 AM >> To: 'tom worster'; curtis@avici.com >> Cc: 'CATANZARITI Sergio FTR&D/TI'; mpls@UU.NET >> Subject: RE: MPLS Diffserv Extensions related questions/comments > > > >> Regarding the reduction of per-LSP memory; well it all >> depends on what you >> are comparing it to. One solution which will reduce the >> per-LSP memory and >> still uses the signaled EXP->PHB mapping is to build a few >> general purpose >> EXP->PHB mapping tables (in each LSR), from the first few LSP setup >> messages, and use them as an index in per-LSP ILM/NHLFE >> tables. Using this >> method, the amount of per-LSP memory is less than or equal to your >> proposal. > _________________________________________________________________ Francois Le Faucheur Development Engineer, IOS Layer 3 Services Cisco Systems Office Phone: +33 4 92 96 75 64 Home Office Phone: +33 4 92 94 00 78 Mobile : +33 6 89 108 159 Vmail: +33 1 58 04 62 66 Fax: +33 4 92 96 79 08 Email: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Tue Jul 4 05:38: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 FAA26095 for ; Tue, 4 Jul 2000 05:38:58 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwje05665; Tue, 4 Jul 2000 09:38:25 GMT Received: by mail-control.mail.uu.net id QQiwje23459 for mpls-outgoing; Tue, 4 Jul 2000 09:38: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 QQiwje23454 for ; Tue, 4 Jul 2000 09:37:59 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiwje24754 for ; Tue, 4 Jul 2000 05:37:47 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiwje05049 for ; Tue, 4 Jul 2000 09:37:31 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA17539 for mpls@uu.net; Tue, 4 Jul 2000 05:37:31 -0400 (EDT) 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 QQiwje23439 for ; Tue, 4 Jul 2000 09:37: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 QQiwje06965 for ; Tue, 4 Jul 2000 05:36:57 -0400 (EDT) Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQiwje24549 for ; Tue, 4 Jul 2000 09:36:57 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id A52B8152; Tue, 4 Jul 2000 11:36:56 +0200 (MET DST) Received: from flefauch-8kcdt.cisco.com (nice-dhcp15.cisco.com [144.254.60.37]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id LAA13977; Tue, 4 Jul 2000 11:36:55 +0200 (MET DST) Message-Id: <200007040936.LAA13977@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 04 Jul 2000 11:34:23 +0200 To: Grenville Armitage From: Francois Le Faucheur Subject: Re: Sections 7, 8, 9 & 10 Re: Last Call feedback on MPLS-Diff-Serv Cc: Francois Le Faucheur , mpls@UU.NET In-Reply-To: <39613867.B85BC750@dnrc.bell-labs.com> References: <200006121753.NAA22286@lir.cisco.com> <200006262008.WAA24871@europe.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Grenville, At 18:05 03/07/2000 -0700, Grenville Armitage wrote: >Francois, > >Wrapping up the last open issue, I promise ;) > getting there '^) >Francois Le Faucheur wrote: > [..] >> At 01:26 26/06/2000 -0700, Grenville Armitage wrote: > [..] >> >#10 Why is section 7 here? >> > >> > Section 7 repeats material that is redundant for a reader who >> > gets this far into the document. Clearly the mechanisms for >> > handling MPLS over PPP are documented elsewhere, and this >> > document has already stated how various Encaps<->PHB mappings >> > are built for E- and L-LSPs. Section 7 ought to be removed, >> > perhaps to an informational/applicability document. >> >> Section 7 is NOT redundant. It specifies , out of all the previously >> defined options, which ones are MUST and which ones are MAY for PPP >> interfaces. Unless you specify that you may have one implemnetation >> supporting one option and another implementation supporting another >> option which prevents actual interoperability. > >Oh, I certainly agree such information is worthwhile. Good. >The MUST/MAY >text in section 7 just seemed overly wordy (and that probably made >me feel a lot of it wasn't neeeded). It simply boils down to >saying that "E-LSPs with configured EXP<-->PHB mappings MUST >be supported, signalled mappings MAY be supported, and L-LSPs >with signalled mappings MAY be supported". There, done in one >sentence :-) (There are couple of instances of "..then it MUST do >so in compliance with all the material from this specification >pertaining to.." which is just distracting fluff - the normative >text is normative, no need to add eyestrain to the readers by >restating that they're reading a normative spec ;) > Will do. >(7.2 and 7.3 could also be collapsed into 7.1 by removing the >words "..specified in section 7.1.." from each and removing >the subsection headings.) > I'd prefer to keep the 7.2 and 7.3 section titles. It will be useful for people to see where those particular cases are discussed (e.g. from the Table of Content that we will add in next Rev). >> >#11 Why are sections 8 and 9 here? >> > >> > Sections 8&9 suffer the same question of focus as section 7. >> > How an ATM or FR interface operates is pretty much covered by >> > existing MPLS documents - excluding perhaps the recommendation >> > to use EPD for ATM, I dont see sections 8&9 adding anything >> > normative to what has already been stated earlier in the document. >> > They ought to follow section 7 into another document (or oblivion). >> > >> >> Same as above, these sections clarify which of the various options >> are applicable to these media. >> Also it clarifies media specific issues which have come up during >> the WG progress (eg that the requirement is for ATM LSRs to support PHB >> scheduling rather than "traditional" ATM scheduling, that only two drop >> levels are supported , that EPD is a good idea, that the spec only >> covers the case where the shim layer is used...) >> >> I believe this is useful information and should be kept. > >Okay. I would suggest removing a few instances of redundant >"..in compliance with all the material from this specification >pertaining to.." wordage. > will do. >However, 2nd para in 8.2 "Since there is only one bit..." seems >unecessary in light of all the previous discussion about how >to map PHB->CLP for L-LSPs (and oddly it points back to DIFF_AF >as the normative behavior reference, instead of the PHB->CLP Section 8.2 focusing on implementation of "Diff-Serv PHBs" in an ATM context. The mapping into CLP has been detailed earlier and we don't need to get back to it here. The point we wanted to bring forward is that although the AF Spec defines 3 levels of drops , it does discuss the case where only two levels of drop are supported and this is the case that applies to ATM Diff-SErv LSRs. >mapping rules already stated in this document). Ditto for >2nd para in 9.2 - I'd have thought a backwards reference to this >document's own PHB->DE mapping rules would be less confusing to >readers. > >> >#12 Why is section 10 here? >> > >> > Again, as with section 7 there's an issue of focus here. >> > No new normative text exists here, and it is at best a subset >> > of section 7 anyway. >> > >> >> Section 10 is NOT redundant. It specifies , out of all the previously >> defined options, which ones are MUST and which ones are MAY for LAN >> interfaces. Unless you specify that, you may have one implemnetation >> supporting one option and another implementation supporting another >> option which prevents actual interoperability. >> >> We could easily group it with section 7 though. > >Folding LSR over LAN interfaces into section 7 would be good. > will do. thnaks Francois >cheers, >gja >________________________________________________________________________ >Grenville Armitage http://members.home.net/garmitage/ >Bell Labs Research Silicon Valley > _________________________________________________________________ Francois Le Faucheur Development Engineer, IOS Layer 3 Services Cisco Systems Office Phone: +33 4 92 96 75 64 Home Office Phone: +33 4 92 94 00 78 Mobile : +33 6 89 108 159 Vmail: +33 1 58 04 62 66 Fax: +33 4 92 96 79 08 Email: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Tue Jul 4 13:07: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 NAA29124 for ; Tue, 4 Jul 2000 13:07:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwki02443; Tue, 4 Jul 2000 17:06:40 GMT Received: by mail-control.mail.uu.net id QQiwki16999 for mpls-outgoing; Tue, 4 Jul 2000 17:06: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 QQiwki16980 for ; Tue, 4 Jul 2000 17:06: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 QQiwki28298 for ; Tue, 4 Jul 2000 13:06:02 -0400 (EDT) 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 QQiwki01914 for ; Tue, 4 Jul 2000 17:06:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Tue Jul 4 13:05:04 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn68.pa.bell-labs.com [135.250.1.68]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA13504; Tue, 4 Jul 2000 13:05:45 -0400 (EDT) Message-ID: <39621A3E.A2E3300E@dnrc.bell-labs.com> Date: Tue, 04 Jul 2000 10:09:18 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois Le Faucheur CC: mpls@UU.NET Subject: Re: Sections 7, 8, 9 & 10 Re: Last Call feedback onMPLS-Diff-Serv References: <200006121753.NAA22286@lir.cisco.com> <200006262008.WAA24871@europe.cisco.com> <200007040936.LAA13977@europe.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Francois Le Faucheur wrote: [..] > At 18:05 03/07/2000 -0700, Grenville Armitage wrote: [..] > >However, 2nd para in 8.2 "Since there is only one bit..." seems > >unecessary in light of all the previous discussion about how > >to map PHB->CLP for L-LSPs (and oddly it points back to DIFF_AF > >as the normative behavior reference, instead of the PHB->CLP > > Section 8.2 focusing on implementation of "Diff-Serv PHBs" in an > ATM context. > The mapping into CLP has been detailed earlier and we don't need > to get back to it here. The point we wanted to bring forward is > that although the AF Spec defines 3 levels of drops , it does > discuss the case where only two levels of drop are supported > and this is the case that applies to ATM Diff-SErv LSRs. But that's my point - the fact that there are only 2 drop values in ATM, and the implications for AFxy mapping, has already been documented earlier in *this* spec when the PHB<-->CLP mappings are defined. 4.2.2 and 4.4.2 are clear about the mapping rules to 3 AF drop precedence. If section 8.2 simply pointed back to the earlier discussion of AFxy<-->CLP mappings the text would be more self contained (and readers would be less likely to wonder if 8.2 is actually providing some further insight or normative requirement over and above 4.2.2 and 4.4.2, which it does not). That's a minor confusion easily avoided, either by removing 8.2 or at least writing the text like "Only two possible drop precedence may be indicated by the CLP bit. Sections 4.2.2 and 4.4.2 define how three AFxy precedence levels [DIFF_AF] are mapped to these two values." cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mpls@UU.NET Tue Jul 4 13:25: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 NAA29287 for ; Tue, 4 Jul 2000 13:25:11 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwkj09097; Tue, 4 Jul 2000 17:24:36 GMT Received: by mail-control.mail.uu.net id QQiwkj18274 for mpls-outgoing; Tue, 4 Jul 2000 17:24: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 QQiwkj18265 for ; Tue, 4 Jul 2000 17:24: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 QQiwkj09017 for ; Tue, 4 Jul 2000 13:24:03 -0400 (EDT) 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 QQiwkj13605 for ; Tue, 4 Jul 2000 17:24:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Tue Jul 4 13:23:01 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn68.pa.bell-labs.com [135.250.1.68]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA13600; Tue, 4 Jul 2000 13:23:41 -0400 (EDT) Message-ID: <39621E72.125AB5CB@dnrc.bell-labs.com> Date: Tue, 04 Jul 2000 10:27:14 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois Le Faucheur , mpls@UU.NET Subject: correction Re: Sections 7, 8, 9 & 10 Re: Last Call feedback onMPLS-Diff-Serv References: <200006121753.NAA22286@lir.cisco.com> <200006262008.WAA24871@europe.cisco.com> <200007040936.LAA13977@europe.cisco.com> <39621A3E.A2E3300E@dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit clarification to my post a few minutes ago - meant to focus on the 2nd para of section 8.2: Grenville Armitage wrote: [..] > If section 8.2 simply pointed back to ^ "2nd para of.." > the earlier discussion of AFxy<-->CLP mappings the text would be > more self contained (and readers would be less likely to wonder > if 8.2 is actually providing some further insight or normative ^ "2nd para of.." > requirement over and above 4.2.2 and 4.4.2, which it does not). > > That's a minor confusion easily avoided, either by removing 8.2 "2nd para of.." ^ > or at least writing the text like "Only two possible drop precedence > may be indicated by the CLP bit. Sections 4.2.2 and 4.4.2 define > how three AFxy precedence levels [DIFF_AF] are mapped to these > two values." cheers, gja From owner-mpls@UU.NET Wed Jul 5 09:19: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 JAA01098 for ; Wed, 5 Jul 2000 09:19:36 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwnl00013; Wed, 5 Jul 2000 13:18:32 GMT Received: by mail-control.mail.uu.net id QQiwnl04812 for mpls-outgoing; Wed, 5 Jul 2000 13:17: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 QQiwnl04798 for ; Wed, 5 Jul 2000 13:17:52 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiwnl04619 for ; Wed, 5 Jul 2000 09:17:46 -0400 (EDT) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQiwnl05718 for ; Wed, 5 Jul 2000 13:17:30 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id JAA14838; Wed, 5 Jul 2000 09:11:05 -0400 Message-ID: <396343B4.26DEA342@tellium.com> Date: Wed, 05 Jul 2000 09:18:28 -0500 From: Debanjan Saha Organization: Tellium Optical Systems X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Yakov Rekhter CC: mpls@UU.NET, vsriniva@cosinecom.com, swallow@cisco.com Subject: Re: Link Bundling References: <200007051257.FAA08163@omega.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yakov, Yakov Rekhter wrote: > Kireeti and myself would like to ask the MPLS WG to > accept draft-kompella-mpls-bundle-01.txt as an > MPLS WG document. I requested some clarification (see attached) on the draft. Have n't heard anything from the authors to date. Any chance that they will be addressed? Regards, Debanjan ------------------------------------------------------------- Quoted from section 3.1 of the draft.. "Component links may either be unnumbered, or all components links must be numbered identically. In the former case, the bundled link may be either unnumbered or numbered with IP addresses assigned to some "virtual" interfaces on an LSR (it is assumed that an LSR may have multiple virtual interfaces). In the latter case, the bundled link is numbered the same as the component links." In the first sentence, you say "all component links must be numbered identically". What does "identically" really mean? In the last sentence, you say "the bundled link is numbered the same as the component links". Does it mean that the bundle can be numbered with the IP address of any one of the component links? Also, have you considered taking SRLG information into account for bundling? What about including resource information of the kind? 4 OC-48 2 OC-192 etc... Current mode of bandwidth accounting does not provide sufficient information on bandwidth granularity which is very important for optical networks. Debanjan -- Debanjan Saha Phone: 732-923-4264 Senior Network Architect Fax: 732-923-9804 Tellium Optical Systems http://www.tellium.com From owner-mpls@UU.NET Wed Jul 5 09:23: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 JAA01350 for ; Wed, 5 Jul 2000 09:23:51 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwnj21228; Wed, 5 Jul 2000 12:59:14 GMT Received: by mail-control.mail.uu.net id QQiwnj22094 for mpls-outgoing; Wed, 5 Jul 2000 12:58:57 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiwnj22084 for ; Wed, 5 Jul 2000 12:58:54 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiwnj01341 for ; Wed, 5 Jul 2000 08:58:42 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiwnj20710 for ; Wed, 5 Jul 2000 12:58:41 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA14053 for mpls@uu.net; Wed, 5 Jul 2000 08:58:40 -0400 (EDT) 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 QQiwnj22067 for ; Wed, 5 Jul 2000 12:58: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 QQiwnj01188 for ; Wed, 5 Jul 2000 08:57:34 -0400 (EDT) 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 QQiwnj13211 for ; Wed, 5 Jul 2000 12:57:33 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id FAA08163; Wed, 5 Jul 2000 05:57:32 -0700 (PDT) Message-Id: <200007051257.FAA08163@omega.cisco.com> To: mpls@UU.NET cc: vsriniva@cosinecom.com, swallow@cisco.com Subject: Link Bundling MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8161.962801852.1@cisco.com> Date: Wed, 05 Jul 2000 05:57:32 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Folks, Kireeti and myself would like to ask the MPLS WG to accept draft-kompella-mpls-bundle-01.txt as an MPLS WG document. Yakov. From owner-mpls@UU.NET Wed Jul 5 12:50: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 MAA11340 for ; Wed, 5 Jul 2000 12:50:14 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwnz24762; Wed, 5 Jul 2000 16:49:28 GMT Received: by mail-control.mail.uu.net id QQiwnz24416 for mpls-outgoing; Wed, 5 Jul 2000 16:48: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 QQiwnz24397 for ; Wed, 5 Jul 2000 16:48: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 QQiwnz11253 for ; Wed, 5 Jul 2000 12:48:39 -0400 (EDT) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQiwnz03750 for ; Wed, 5 Jul 2000 16:48:39 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id JAA10624; Wed, 5 Jul 2000 09:48:37 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id JAA12373; Wed, 5 Jul 2000 09:47:57 -0700 (PDT) Date: Wed, 5 Jul 2000 09:47:57 -0700 (PDT) From: Kireeti Kompella Message-Id: <200007051647.JAA12373@kummer.juniper.net> To: dsaha@tellium.com, yakov@cisco.com Subject: Re: Link Bundling Cc: mpls@UU.NET, swallow@cisco.com, vsriniva@cosinecom.com Sender: owner-mpls@UU.NET Precedence: bulk Hi Debanjan, Here are some of the clarifications you requested: 1) Component link addresses: we've loosened the wording on this slightly; the new text follows. Component links may be unnumbered, or the various component links may be numbered differently, or all components links may be numbered identically. In the first two cases, the bundled link is unnumbered by default; in the last case, the bundled link is numbered the same as the component links by default. In all cases, the bundled link's addresses may be overridden by configuration with IP addresses assigned to some "virtual" interfaces on an LSR (it is assumed that an LSR may have multiple virtual interfaces). "Numbered identically" means that local addresses are the same AND remote addresses are the same. 2) Bundling SRLG and other resource information should be covered in the routing drafts for "optical" MPLS, as bundling as described in this document is a generic MPLS construct. Hope that helps, Kireeti. From owner-mpls@UU.NET Wed Jul 5 13:11: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 NAA12034 for ; Wed, 5 Jul 2000 13:11:48 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwoa22567; Wed, 5 Jul 2000 17:10:44 GMT Received: by mail-control.mail.uu.net id QQiwoa08009 for mpls-outgoing; Wed, 5 Jul 2000 17:10: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 QQiwoa07933 for ; Wed, 5 Jul 2000 17:10:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiwoa19621 for ; Wed, 5 Jul 2000 13:10:03 -0400 (EDT) Received: from outside.whiterocknetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [64.48.28.18]) id QQiwoa09838 for ; Wed, 5 Jul 2000 17:10:02 GMT Received: from [192.168.1.220] by outside.whiterocknetworks.com for mpls@uu.net id MAA05351; Wed Jul 5 12:07:22 2000 Received: by WRNXCHG with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jul 2000 12:05:55 -0500 Message-ID: <758F0C2C951CD411B15300D0B74444650A5CAB@WRNXCHG> Subject: Optical MPLS Date: Wed, 5 Jul 2000 12:05:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFE6A3.475E7576" To: "MPLS Mailing-list (E-mail)" From: "Chatterjee, Shash" 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_01BFE6A3.475E7576 Content-Type: text/plain; charset="iso-8859-1" Hello everyone! Where can I get a comprehensive list of the MPLS/CR-LDP optical/lambda-switching drafts? So far, I have read draft-kompella...,draft-fan..., draft-basak... and draft-krishnaswamy... Are there any others? Also, are there any other (potentially non-IETF) documents/mailing-lists where I can learn about the various standards efforts and issues related to this topic? Any pointers on this topic would be very welcome. Thanks in advance, Shash Sasvata (Shash) Chatterjee schatterjee@whiterocknetworks.com White Rock Networks Dallas, Texas, USA ------_=_NextPart_000_01BFE6A3.475E7576 Content-Type: application/octet-stream; name="Shash Chatterjee (E-mail).vcf" Content-Disposition: attachment; filename="Shash Chatterjee (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Chatterjee;Shash FN:Chatterjee, Shash ORG:White Rock Networks NOTE:WRN USER TEL;WORK;VOICE:972-588-3757 EMAIL;PREF;INTERNET:schatterjee@WhiteRockNetworks.com REV:20000627T180230Z END:VCARD ------_=_NextPart_000_01BFE6A3.475E7576-- From owner-mpls@UU.NET Wed Jul 5 13:15: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 NAA12088 for ; Wed, 5 Jul 2000 13:15:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwoa12466; Wed, 5 Jul 2000 17:13:32 GMT Received: by mail-control.mail.uu.net id QQiwoa08615 for mpls-outgoing; Wed, 5 Jul 2000 17:13:11 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiwoa08600 for ; Wed, 5 Jul 2000 17:13: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 QQiwoa15007 for ; Wed, 5 Jul 2000 13:12:45 -0400 (EDT) Received: from iol.unh.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mars.iol.unh.edu [132.177.121.222]) id QQiwoa11795 for ; Wed, 5 Jul 2000 17:12:44 GMT Received: from localhost (jzou@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id NAA17128; Wed, 5 Jul 2000 13:12:37 -0400 (EDT) Date: Wed, 5 Jul 2000 13:12:37 -0400 From: Jie Zou To: navin.agrawal@ecapsol.com cc: mpls@UU.NET Subject: Re: Several questions about RSVP In-Reply-To: <20000703094159.29012.cpmta@c004.sfo.cp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Navin, Thanks for your help. I have another questions for the answer: 1. for the first question, I searched the RFC1700 and found the ethertype value for IPv4(2048,decimal). I am wondering if there is a value for the IPv4 or ARP? Is there other Layer 3 protocals ? 2. For the second question, is there some reference for the answer? Thanks. Sincerely, Jie Zou On 3 Jul 2000 navin.agrawal@ecapsol.com wrote: > Hi, > > > I hope some one can help me. > > > > I have some questions about RSVP-TE on > > "draft-ietf-mpls-rsvp-lsp-tunnel-05.txt": > > > > 1. On page 18, section 4.2 > > "L3PID an identifier of the layer 3 protocal using this path. > > Standard Ethertype values are used" > > My question is where I can find out these Standard Ethertype values on > > the layer 3 protocal ? > > Read RFC1700. > > > 2. On page 21, line 8, section 4.2.1, > > "The LABEL_REQUEST SHOULD be stored in the Path State Block", to > > this, my consideration is that the LRO SHOULD be stored in the Path State > > Block in the intermediate nodes, not ingress node and egress node. > > Even If I go by your thought as well, LRO should be stored in the > PSB of the egress node as well. > > Strictly my opinion. > > Regards, > Navin > > > > But there is another possible: the LRO is stored in all nodes > > including ingress and egress node. Which one is correct or there is > > another explaination? > > > > > > > > Thanks > > > > > > Jie Zou > > > > > > ------------------- > > MPLS Consortium > > IOL, UNH > > ------------------- > > From owner-mpls@UU.NET Wed Jul 5 13:34: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 NAA12564 for ; Wed, 5 Jul 2000 13:34:12 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwoc27766; Wed, 5 Jul 2000 17:33:28 GMT Received: by mail-control.mail.uu.net id QQiwoc11169 for mpls-outgoing; Wed, 5 Jul 2000 17:32: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 QQiwoc11143 for ; Wed, 5 Jul 2000 17:32: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 QQiwoc18124 for ; Wed, 5 Jul 2000 13:32:21 -0400 (EDT) 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 QQiwoc10835 for ; Wed, 5 Jul 2000 17:32:17 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA19423 for mpls@uu.net; Wed, 5 Jul 2000 13:32:16 -0400 (EDT) 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 QQiwoc11059 for ; Wed, 5 Jul 2000 17:31: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 QQiwoc18042 for ; Wed, 5 Jul 2000 13:31:27 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQiwoc26201 for ; Wed, 5 Jul 2000 17:31:27 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 KAA15940; Wed, 5 Jul 2000 10:31:17 -0700 (PDT) Message-ID: <396370E5.90C463B@pluris.com> Date: Wed, 05 Jul 2000 10:31:17 -0700 From: Bora Akyol X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois Le Faucheur CC: tom worster , "'Shahram Davari'" , "'mpls@uu.net'" Subject: Re: New Error Codes RE: draft-ietf-mpls-diff-ext-05.txt comments References: <336ECDAFDF7DD311B9E30090277AEE4101B40647@nt-exchange-bby.pmc-sierra.bc.ca> <4.0.2.20000704093433.021468c0@europe.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit These look good to me. Bora Francois Le Faucheur wrote: > Hello, > > Here's a proposal for review, to address the thread on New Error Codes. > > 1) "per-LSP context allocation failure" > ========================================= > > * Add one Error Value to the "Diff-Serv Error" (in RSVP section 5.5): > 5 Per-label context allocation failure > > * Add corresponding text in the RSVP section "5.3 Handling Diff-Serv Object". > Something like: > "A node receiving a PAth message with the DIFFSERV object, which recognizes the > DIFFSERV object but that is unable to allocate the required per-LSP Diff-Serv > context sends a PathErr with the error code "Diff-Serv Error" and the error > value "Per-label context allocation failure". > > * similar additions to coresponding LDP sections > > 2) "Policy Control Failure" > =========================== > > This refers to the last example given below by Tom where an LSP set-up may be > rejected because of policies. > > Regular RSVP already has an Error Code for reservations rejected because of > Policy Control: > "Error Code = 02: Policy Control failure > Reservation or path message has been rejected for administrative > reasons, for example, required credentials not submitted, > insufficient quota or balance, or administrative preemption. > This Error Code may appear in a PathErr or ResvErr message. > Contents of the Error Value field are to be determined in the > future." > > I would propose to rely on this existing error code. > > Would that be acceptable or do you see a lot of value in identifying that it is > a "Diff-Serv Policy Control Failure"? > > Thanks > > Francois > > At 11:33 27/06/2000 -0400, tom worster wrote: > >From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > >Shahram Davari > > > >> Bora, > >> > >> Could you please identify why/how a node could understand the Diffserv > >> object and the E-LSP C-type and still can't support the > >> signaled E-LSP. > >> > >> -Shahram > >> > >> >From: Bora Akyol [mailto:akyol@pluris.com] > >> > > > >> > > >> >Why not have another error code for nodes that understand the > >> >DS object but can > >> >not provide per-label context. This makes sense to me. > > > > > >i think bora's suggestion makes sense. > > > >one example that fits: you recently described a method of > >cacheing exp->phb mappings (excerpt from your mail below). the > >method was an example of an lsr design that requires less > >memory in total than one that stores a mapping with each lsp. > >it's probably not worth using that cacheing method unless the > >maximum number of mappings the lsr can cache is designed to be > >smaller than the maximum number of lsps it can simultaneously > >support. if the mapping cache were to be exhausted, the error > >code bora described would be appropriate. > > > >none of the error/status codes defined seem appropriate in > >this case: the ds object/tlv was not unexpected; the > >mapping is not invalid; and the phbs are not unsupported. > >"cannot provide per-label context" sounds like it would > >fit. > > > >another example: for reasons associated with routeing, a > >network may want to keep certain sets of phbs separated > >from each other on different lsps. in such a case, lsrs might > >be configured to not accept certain combinations of phbids > >in an e-lsp ds object/tlv. (i can imagine other reasons to > >use similar policies.) > > > >c u > >tom > > > > > > > >> -----Original Message----- > >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram > >> Davari > >> Sent: Tuesday, June 06, 2000 11:54 AM > >> To: 'tom worster'; curtis@avici.com > >> Cc: 'CATANZARITI Sergio FTR&D/TI'; mpls@UU.NET > >> Subject: RE: MPLS Diffserv Extensions related questions/comments > > > > > > > >> Regarding the reduction of per-LSP memory; well it all > >> depends on what you > >> are comparing it to. One solution which will reduce the > >> per-LSP memory and > >> still uses the signaled EXP->PHB mapping is to build a few > >> general purpose > >> EXP->PHB mapping tables (in each LSR), from the first few LSP setup > >> messages, and use them as an index in per-LSP ILM/NHLFE > >> tables. Using this > >> method, the amount of per-LSP memory is less than or equal to your > >> proposal. > > > _________________________________________________________________ > Francois Le Faucheur > Development Engineer, IOS Layer 3 Services > Cisco Systems > Office Phone: +33 4 92 96 75 64 > Home Office Phone: +33 4 92 94 00 78 > Mobile : +33 6 89 108 159 > Vmail: +33 1 58 04 62 66 > Fax: +33 4 92 96 79 08 > Email: flefauch@cisco.com > _________________________________________________________________ > Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France > _________________________________________________________________ From owner-mpls@UU.NET Wed Jul 5 14:36: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 OAA13699 for ; Wed, 5 Jul 2000 14:36:28 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwog06010; Wed, 5 Jul 2000 18:35:42 GMT Received: by mail-control.mail.uu.net id QQiwog29617 for mpls-outgoing; Wed, 5 Jul 2000 18:35: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 QQiwog29587 for ; Wed, 5 Jul 2000 18:34: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 QQiwog28876 for ; Wed, 5 Jul 2000 14:34:46 -0400 (EDT) Received: from bgslc02.TBG.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQiwog04877 for ; Wed, 5 Jul 2000 18:34:31 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id <3HAWF5YZ>; Wed, 5 Jul 2000 12:26:10 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE7BAE70D@BGSLC02> From: Irwin Lazar To: "'Chatterjee, Shash'" , "MPLS Mailing-list (E-mail)" Subject: RE: Optical MPLS Date: Wed, 5 Jul 2000 12:26:09 -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 We maintain several at http://www.mplsrc.com/drafts.shtml You might also want to try http://www.awduche.com irwin -----Original Message----- From: Chatterjee, Shash [mailto:schatterjee@WhiteRockNetworks.com] Sent: Wednesday, July 05, 2000 1:06 PM To: MPLS Mailing-list (E-mail) Subject: Optical MPLS Hello everyone! Where can I get a comprehensive list of the MPLS/CR-LDP optical/lambda-switching drafts? So far, I have read draft-kompella...,draft-fan..., draft-basak... and draft-krishnaswamy... Are there any others? Also, are there any other (potentially non-IETF) documents/mailing-lists where I can learn about the various standards efforts and issues related to this topic? Any pointers on this topic would be very welcome. Thanks in advance, Shash Sasvata (Shash) Chatterjee schatterjee@whiterocknetworks.com White Rock Networks Dallas, Texas, USA From owner-mpls@UU.NET Wed Jul 5 14:44:56 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13970 for ; Wed, 5 Jul 2000 14:44:55 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwog14070; Wed, 5 Jul 2000 18:44:00 GMT Received: by mail-control.mail.uu.net id QQiwog00564 for mpls-outgoing; Wed, 5 Jul 2000 18:43:42 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiwog00554 for ; Wed, 5 Jul 2000 18:43:40 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiwog00716 for ; Wed, 5 Jul 2000 14:43:30 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQiwog13548 for ; Wed, 5 Jul 2000 18:43:29 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA03790 for ; Wed, 5 Jul 2000 11:43:41 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA26533 for mpls@uu.net; Wed, 5 Jul 2000 14:43:27 -0400 (EDT) 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 QQiwgh29434 for ; Mon, 3 Jul 2000 14:48: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 QQiwgh00471 for ; Mon, 3 Jul 2000 10:48:36 -0400 (EDT) Received: from web510.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web510.mail.yahoo.com [216.115.104.225]) id QQiwgh10184 for ; Mon, 3 Jul 2000 14:48:36 GMT Message-ID: <20000703144835.25214.qmail@web510.mail.yahoo.com> Received: from [147.83.106.78] by web510.mail.yahoo.com; Mon, 03 Jul 2000 07:48:35 PDT Date: Mon, 3 Jul 2000 07:48:35 -0700 (PDT) From: juan diego otero Subject: MPLS TE and Constraint Based Routing To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I would like to know who does the constraint based routing (CBR) when we do TE in an MPLS domain. I mean, is there a special CBR module in every router? or is there a server that computes a kind of "off-line" CBR? Are there any available commercial solution? Thanks a lot. Diego Otero. __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ From owner-mpls@UU.NET Wed Jul 5 14:45: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 OAA14003 for ; Wed, 5 Jul 2000 14:45:47 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwoh26212; Wed, 5 Jul 2000 18:45:02 GMT Received: by mail-control.mail.uu.net id QQiwog00659 for mpls-outgoing; Wed, 5 Jul 2000 18:44: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 QQiwog00653 for ; Wed, 5 Jul 2000 18:44:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiwog00870 for ; Wed, 5 Jul 2000 14:44:17 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQiwog14464 for ; Wed, 5 Jul 2000 18:44:16 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA04393 for ; Wed, 5 Jul 2000 11:44:28 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA26543 for mpls@uu.net; Wed, 5 Jul 2000 14:44:14 -0400 (EDT) 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 QQiwiu22959 for ; Tue, 4 Jul 2000 07:07:05 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiwiu29448 for ; Tue, 4 Jul 2000 03:06:59 -0400 (EDT) Received: from sky.irisa.fr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sky.irisa.fr [131.254.60.147]) id QQiwiu03687 for ; Tue, 4 Jul 2000 07:06:59 GMT Received: from irisa.fr (oxygene.irisa.fr [131.254.13.73]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id JAA17848; Tue, 4 Jul 2000 09:06:52 +0200 (MET DST) Message-ID: <39618D0E.5D23E7BB@irisa.fr> Date: Tue, 04 Jul 2000 09:06:54 +0200 From: Miled Tezeghdanti Organization: Irisa X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Langille CC: MPLS List Subject: Re: NIST Switch References: <3960AC2D.96B780DF@crescentnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Paul, You should subscribe to the list to be able to send messages to it. I had installed Nistswitch. Don't apply the patch4.2a4 to rsvpd and don't copy tc_altq.c to the rsvpd directory as was said in the rsvp-kit-991103/README file. Miled. Paul Langille wrote: > Greetings. Is anyone using the NIST Switch source code > (http://www.antd.nist.gov/itg/nistswitch/)? (We are having trouble > installing the code and we are not getting any responses from the NIST > Switch mailing lists.) > > Thanks Paul > > -- > Paul Langille e-mail: langille@crescentnetworks.com > Crescent Networks phone: (978) 244-9002 x244 > 201 Riverneck Road fax: (978) 244-9211 > Chelmsford, MA 01824 From owner-mpls@UU.NET Wed Jul 5 14:47: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 OAA14057 for ; Wed, 5 Jul 2000 14:47:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwoh16638; Wed, 5 Jul 2000 18:46:20 GMT Received: by mail-control.mail.uu.net id QQiwoh00999 for mpls-outgoing; Wed, 5 Jul 2000 18:45: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 QQiwoh00991 for ; Wed, 5 Jul 2000 18:45: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 QQiwoh08837 for ; Wed, 5 Jul 2000 14:45:47 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQiwoh15911 for ; Wed, 5 Jul 2000 18:45:46 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA05725 for ; Wed, 5 Jul 2000 11:45:58 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA26559 for mpls@uu.net; Wed, 5 Jul 2000 14:45:45 -0400 (EDT) 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 QQiwod13033 for ; Wed, 5 Jul 2000 17:45:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiwod20052 for ; Wed, 5 Jul 2000 13:45:24 -0400 (EDT) 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 QQiwod06962 for ; Wed, 5 Jul 2000 17:45:24 GMT Received: from globespan.net (ROHIT [192.168.25.21]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3GTZYMTW; Wed, 5 Jul 2000 13:47:21 -0400 Message-ID: <39637434.D8AA81EF@globespan.net> Date: Wed, 05 Jul 2000 13:45:24 -0400 From: Rohit Chhapolia Organization: Globespan, Inc. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jie Zou CC: mpls@UU.NET Subject: Re: Several questions about RSVP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jie, > 3. on page 48, line 16, section 5.3 > > "On receipt of a message containing a HELLO REQUEST object, the > receiver MUST generate a Hello message containing a HELLO ACK object" > > "The receiver SHOULD also verify that the neighbor has not reset. > This is done by comparing the sender's Src_Instance field value with > the previously received value. If the value differs, then a node > MUST treat the neighbor as if communication has been lost." > > my confused is about "the previously received value": if the receiver > received a message containing a HRO first time(no previously > received value), then the value should be difference(I guess), then the > communication has been lost at the first time by the explaination of > draft. It seems that establishing communication is not possible. But it > is possible. The question is how they can do it. I agree with you that as currently stated it is a problem in the draft. Perhaps it can be addressed by making the following change. "The receiver SHOULD also verify that the neighbor has not reset IF IT HAS EXISTING STATE FROM THIS NEIGHBOR." When the Hello message is sent first time, there should not be any existing state from this neighbor and protocol should work fine. Rohit -- Rohit Chhapolia Globespan, Inc. voice: 732-345-6237 mailto:rohit@globespan.net http://www.globespan.net From owner-mpls@UU.NET Wed Jul 5 17:44: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 RAA17635 for ; Wed, 5 Jul 2000 17:44:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwos10214; Wed, 5 Jul 2000 21:44:07 GMT Received: by mail-control.mail.uu.net id QQiwos19176 for mpls-outgoing; Wed, 5 Jul 2000 21:43: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 QQiwos19170 for ; Wed, 5 Jul 2000 21:43: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 QQiwos28591 for ; Wed, 5 Jul 2000 17:43:21 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiwos09393 for ; Wed, 5 Jul 2000 21:43:06 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA22723 for mpls@uu.net; Wed, 5 Jul 2000 17:43:05 -0400 (EDT) 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 QQiwos19092 for ; Wed, 5 Jul 2000 21:42: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 QQiwos28481 for ; Wed, 5 Jul 2000 17:42:26 -0400 (EDT) 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 QQiwos08775 for ; Wed, 5 Jul 2000 21:42:11 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 RAA28089; Wed, 5 Jul 2000 17:42:09 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA14677; Wed, 5 Jul 2000 17:42:08 -0400 (EDT) Message-Id: <200007052142.RAA14677@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Yakov Rekhter cc: mpls@UU.NET, vsriniva@cosinecom.com, swallow@cisco.com, swallow@cisco.com Subject: Re: Link Bundling In-reply-to: Your message of "Wed, 05 Jul 2000 05:57:32 PDT." <200007051257.FAA08163@omega.cisco.com> Date: Wed, 05 Jul 2000 17:42:08 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > Folks, > > Kireeti and myself would like to ask the MPLS WG to > accept draft-kompella-mpls-bundle-01.txt as an > MPLS WG document. > > Yakov. Consensus on this will be assessed on 7/12. Opinions should be aired by then. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Jul 5 18:17: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 SAA17971 for ; Wed, 5 Jul 2000 18:17:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwov05480; Wed, 5 Jul 2000 22:17:17 GMT Received: by mail-control.mail.uu.net id QQiwov04833 for mpls-outgoing; Wed, 5 Jul 2000 22:16:50 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 QQiwov04828 for ; Wed, 5 Jul 2000 22:16: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 QQiwov09845 for ; Wed, 5 Jul 2000 18:16:47 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQiwov05043 for ; Wed, 5 Jul 2000 22:16:47 GMT Received: from tworster (dhcp168.tst.ennovatenetworks.com [10.1.3.168]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id SAA06444; Wed, 5 Jul 2000 18:15:59 -0400 (EDT) (envelope-from tom@ennovatenetworks.com) From: "tom worster" To: "'Francois Le Faucheur'" Cc: "'Shahram Davari'" , "'mpls@uu.net'" Subject: RE: New Error Codes RE: draft-ietf-mpls-diff-ext-05.txt comments Date: Wed, 5 Jul 2000 18:16:39 -0400 Message-ID: <000001bfe6ce$b1bf50e0$a803010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <4.0.2.20000704093433.021468c0@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: 7bit From: flefauch@europe.cisco.com [mailto:flefauch@europe.cisco.com]On > > Here's a proposal for review, to address the thread on New > Error Codes. > > 1) "per-LSP context allocation failure" > ========================================= > > * Add one Error Value to the "Diff-Serv Error" (in RSVP section 5.5): > 5 Per-label context allocation failure > > * Add corresponding text in the RSVP section "5.3 Handling > Diff-Serv Object". > Something like: > "A node receiving a PAth message with the DIFFSERV object, > which recognizes the > DIFFSERV object but that is unable to allocate the required > per-LSP Diff-Serv > context sends a PathErr with the error code "Diff-Serv Error" > and the error > value "Per-label context allocation failure". > > * similar additions to coresponding LDP sections this looks fine. > 2) "Policy Control Failure" > =========================== > > This refers to the last example given below by Tom where an > LSP set-up may be > rejected because of policies. > > Regular RSVP already has an Error Code for reservations > rejected because of > Policy Control: > "Error Code = 02: Policy Control failure > Reservation or path message has been rejected for > administrative > reasons, for example, required credentials not submitted, > insufficient quota or balance, or administrative preemption. > This Error Code may appear in a PathErr or ResvErr message. > Contents of the Error Value field are to be determined in the > future." > > I would propose to rely on this existing error code. > > Would that be acceptable or do you see a lot of value in > identifying that it is > a "Diff-Serv Policy Control Failure"? not really. your suggestion for rsvp looks ok. but i'm unsure what to do with ldp. i checked through the ldp and crldp specs and didn't notice anything suitable. hmmm. btw: as i was checking through the docs i noticed that in section 5.3 of the -05 draft the term "the reservation" is used in a way that is potentially confusing. elsewhere in the document the word is only used to refer to bandwidth reservations (this seems also to be true of the rsvp-lsp-tunnel draft) but in section 5.3 it seems to be used to refer to a label request. c u tom From owner-mpls@UU.NET Wed Jul 5 22:22: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 WAA22317 for ; Wed, 5 Jul 2000 22:22:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwpl20495; Thu, 6 Jul 2000 02:21:20 GMT Received: by mail-control.mail.uu.net id QQiwpl15268 for mpls-outgoing; Thu, 6 Jul 2000 02:20: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 QQiwpl15260 for ; Thu, 6 Jul 2000 02:20: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 QQiwpl08275 for ; Wed, 5 Jul 2000 22:20:49 -0400 (EDT) Received: from mason2.gmu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQiwpl19960 for ; Thu, 6 Jul 2000 02:20:34 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id WAA12182; Wed, 5 Jul 2000 22:20:32 -0400 (EDT) Date: Wed, 5 Jul 2000 22:20:32 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: "Chatterjee, Shash" cc: "MPLS Mailing-list (E-mail)" Subject: Re: Optical MPLS In-Reply-To: <758F0C2C951CD411B15300D0B74444650A5CAB@WRNXCHG> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Shash, Here are some more drafts related to MPL(ambda)S that you can refer. These are available at IETF website. 1) Multi-Protocol Lambda Switching:Combining MPLS Traffic Engineering Control With Optical Crossconnects (draft-awduche-mpls-te-optical-01.txt) 2) Extensions to RSVP for optical networking (draft-lang-mpls-rsvp-oxc-00.txt) Also, you can find some good links related to optical networks at the following site : http://user.chollian.net/~son6971/optical/opticalinternet.htm Regards Rajiv Papneja (GRA-AIL) On Wed, 5 Jul 2000, Chatterjee, Shash wrote: > Hello everyone! > > Where can I get a comprehensive list of the MPLS/CR-LDP > optical/lambda-switching drafts? > So far, I have read draft-kompella...,draft-fan..., draft-basak... and > draft-krishnaswamy... Are there any others? Also, are there any other > (potentially non-IETF) documents/mailing-lists where I can learn about the > various standards efforts and issues related to this topic? > > Any pointers on this topic would be very welcome. > > Thanks in advance, > Shash > > Sasvata (Shash) Chatterjee > schatterjee@whiterocknetworks.com > White Rock Networks > Dallas, Texas, USA > > ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4700 email: rpapneja@osf1.gmu.edu ******************************** From owner-mpls@UU.NET Wed Jul 5 23: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 XAA24448 for ; Wed, 5 Jul 2000 23:58:09 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwpr23092; Thu, 6 Jul 2000 03:57:14 GMT Received: by mail-control.mail.uu.net id QQiwpr07271 for mpls-outgoing; Thu, 6 Jul 2000 03:56: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 QQiwpr07259 for ; Thu, 6 Jul 2000 03:56: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 QQiwpr18734 for ; Wed, 5 Jul 2000 23:56:44 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiwpr22684 for ; Thu, 6 Jul 2000 03:56:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA16915 for mpls@uu.net; Wed, 5 Jul 2000 23:56:43 -0400 (EDT) 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 QQiwpr07152 for ; Thu, 6 Jul 2000 03:56: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 QQiwpr18602 for ; Wed, 5 Jul 2000 23:55:54 -0400 (EDT) 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 QQiwpr10747 for ; Thu, 6 Jul 2000 03:55:38 GMT Received: from chmetz-pc (rtp-dial-1-20.cisco.com [10.83.97.20]) by mailman.cisco.com (8.9.3/8.9.1) with SMTP id UAA02373; Wed, 5 Jul 2000 20:52:14 -0700 (PDT) Message-Id: <200007060352.UAA02373@mailman.cisco.com> X-Sender: chmetz@sj-email.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 05 Jul 2000 23:55:25 -0700 To: "Chatterjee, Shash" From: Chris Metz Subject: Re: Optical MPLS Cc: "MPLS Mailing-list (E-mail)" In-Reply-To: <758F0C2C951CD411B15300D0B74444650A5CAB@WRNXCHG> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Check out: http://infonet.aist-nara.ac.jp/member/nori-d/mlr/ At 12:05 PM 07/05/2000 -0500, Chatterjee, Shash wrote: >Hello everyone! > >Where can I get a comprehensive list of the MPLS/CR-LDP >optical/lambda-switching drafts? >So far, I have read draft-kompella...,draft-fan..., draft-basak... and >draft-krishnaswamy... Are there any others? Also, are there any other >(potentially non-IETF) documents/mailing-lists where I can learn about the >various standards efforts and issues related to this topic? > >Any pointers on this topic would be very welcome. > >Thanks in advance, >Shash > >Sasvata (Shash) Chatterjee >schatterjee@whiterocknetworks.com >White Rock Networks >Dallas, Texas, USA > > > Chris Metz Lead IP Architect Solutions Integration Service Provider Line of Business Cisco Systems email: chmetz@cisco.com offic phone: 408-525-3275 home office: 914-241-0423 pager: 800-365-4578 Internal URL: http://wwwin-people.cisco.com/chmetz/chmetz.htm From owner-mpls@UU.NET Thu Jul 6 05:01:49 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09822 for ; Thu, 6 Jul 2000 05:01:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwqm08059; Thu, 6 Jul 2000 09:00:46 GMT Received: by mail-control.mail.uu.net id QQiwqm06554 for mpls-outgoing; Thu, 6 Jul 2000 09:00: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 QQiwqm06362 for ; Thu, 6 Jul 2000 09:00:11 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiwqm15411 for ; Thu, 6 Jul 2000 05:00:03 -0400 (EDT) From: darren.freeland@bt.com Received: from marvin.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQiwql07258 for ; Thu, 6 Jul 2000 08:59:47 GMT Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Thu, 6 Jul 2000 09:56:35 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <3GLQ3N5B>; Thu, 6 Jul 2000 09:56:33 +0100 Message-ID: <71DA16F18D32D2119A1D0000F8FE9A940920C313@mbtlipnt01.btlabs.bt.co.uk> To: yakov@cisco.com, mpls@UU.NET Subject: RE: draft-kompella-mpls-optical-00.txt Date: Thu, 6 Jul 2000 09:55:57 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Please accept my apologies if I'm going over old ground here - I'm relatively new to this list. I have a question regarding draft-kompella-mpls-optical-00.txt Section 3.4 Control channels, data channels, and IP links: "..If all the fibers can share the same TE characteristics, then a single control channel suffices." Have the authors given any consideration to the disadvantages that a single control plane would bring? Regards, Darren. -----Original Message----- From: George Swallow [mailto:swallow@cisco.com] Sent: 05 July 2000 22:42 To: Yakov Rekhter Cc: mpls@UU.NET; vsriniva@cosinecom.com; swallow@cisco.com; swallow@cisco.com Subject: Re: Link Bundling > Folks, > > Kireeti and myself would like to ask the MPLS WG to > accept draft-kompella-mpls-bundle-01.txt as an > MPLS WG document. > > Yakov. Consensus on this will be assessed on 7/12. Opinions should be aired by then. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Jul 6 11:05: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 LAA18001 for ; Thu, 6 Jul 2000 11:05:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwrk26254; Thu, 6 Jul 2000 15:03:58 GMT Received: by mail-control.mail.uu.net id QQiwrk21272 for mpls-outgoing; Thu, 6 Jul 2000 15:03: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 QQiwrk21166 for ; Thu, 6 Jul 2000 15:03:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiwrk01900 for ; Thu, 6 Jul 2000 11:03:04 -0400 (EDT) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQiwrk25388 for ; Thu, 6 Jul 2000 15:03:03 GMT Received: from tellium.com by alpha.tellium.com (SMI-8.6/SMI-SVR4) id KAA15798; Thu, 6 Jul 2000 10:56:45 -0400 Message-ID: <3964ADF2.920274C5@tellium.com> Date: Thu, 06 Jul 2000 11:04:02 -0500 From: Debanjan Saha Organization: Tellium Optical Systems X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpls@UU.NET Subject: [FYI: I-D ACTION:draft-rs-optical-bundling-00.txt] Content-Type: multipart/mixed; boundary="------------D898E19A82B8F3E0FB1CC11C" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------D898E19A82B8F3E0FB1CC11C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Debanjan Saha Phone: 732-923-4264 Senior Network Architect Fax: 732-923-9804 Tellium Optical Systems http://www.tellium.com --------------D898E19A82B8F3E0FB1CC11C Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from loki.ietf.org by alpha.tellium.com (SMI-8.6/SMI-SVR4) id JAA10606; Thu, 6 Jul 2000 09:29:56 -0400 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id GAA01510 for ietf-123-outbound.05@ietf.org; Thu, 6 Jul 2000 06:45:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01423 for ; Thu, 6 Jul 2000 06:31:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10782 for ; Thu, 6 Jul 2000 06:31:29 -0400 (EDT) Message-Id: <200007061031.GAA10782@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@loki.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rs-optical-bundling-00.txt Date: Thu, 06 Jul 2000 06:31:29 -0400 Sender: scoya@cnri.reston.va.us X-Mozilla-Status2: 00000000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Link Bundling Considerations in Optical Networks Author(s) : B. Rajagopalan, D. Saha Filename : draft-rs-optical-bundling-00.txt Pages : 7 Date : 05-Jul-00 In an optical mesh network, two adjacent optical cross connects (OXCs) may have multiple, parallel, discrete bandwidth links connecting them [1]. When a link state routing protocol (e.g., OSPF) is used, these links may all be bundled together and advertised in a single link state advertisement (LSA). This draft describes the issues that arise when optical links are bundled, and proposes a rule for bundling optical links. This work is complimentary to the work on link bundling for MPLS TE [2]. The differences between optical link bundling and link bundling for MPLS TE are also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rs-optical-bundling-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-rs-optical-bundling-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-rs-optical-bundling-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: <20000705073923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rs-optical-bundling-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rs-optical-bundling-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000705073923.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------D898E19A82B8F3E0FB1CC11C-- From owner-mpls@UU.NET Thu Jul 6 11:44: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 LAA19150 for ; Thu, 6 Jul 2000 11:44:51 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwrm11571; Thu, 6 Jul 2000 15:43:55 GMT Received: by mail-control.mail.uu.net id QQiwrm03920 for mpls-outgoing; Thu, 6 Jul 2000 15:43: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 QQiwrm03913 for ; Thu, 6 Jul 2000 15:43: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 QQiwrm04132 for ; Thu, 6 Jul 2000 11:43:09 -0400 (EDT) Received: from osf1.gmu.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: osf1.gmu.edu [129.174.1.13]) id QQiwrm10858 for ; Thu, 6 Jul 2000 15:43:08 GMT Received: from localhost (rpapneja@localhost) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id LAA26438; Thu, 6 Jul 2000 11:43:07 -0400 (EDT) Date: Thu, 6 Jul 2000 11:43:07 -0400 (EDT) From: Rajiv Papneja To: juan diego otero cc: mpls@UU.NET Subject: Re: MPLS TE and Constraint Based Routing In-Reply-To: <20000703144835.25214.qmail@web510.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk hi Juan, According to the RFC 2702, "Requirements of Traffic Engineering Over MPLS" section 7.0, constraint based routing can be incorporated in the LSRs in two ways: firstly by extending the current IGPs to support CBR and secondly by including the CBR process in the routers, which coexists with the current IGP. Atleast one of the two must exist. You can probably use off-line tools for path computation but sometimes the off-line tools do not scale well with the network size and are not much responsive to the network states. Take care Rajiv On Mon, 3 Jul 2000, juan diego otero wrote: > Hi, > > I would like to know who does the constraint > based routing (CBR) when we do TE in an MPLS domain. > I mean, is there a special CBR module in every router? > or is there a server that computes a kind of > "off-line" CBR? Are there any available commercial > solution? > > Thanks a lot. > > Diego Otero. > > > __________________________________________________ > Do You Yahoo!? > Kick off your party with Yahoo! Invites. > http://invites.yahoo.com/ > > ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University Tel: 703.993.4700 email: rpapneja@osf1.gmu.edu ******************************** From owner-mpls@UU.NET Thu Jul 6 15:17: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 PAA23804 for ; Thu, 6 Jul 2000 15:17:40 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwsb12973; Thu, 6 Jul 2000 19:16:36 GMT Received: by mail-control.mail.uu.net id QQiwsb12172 for mpls-outgoing; Thu, 6 Jul 2000 19:16: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 QQiwsb12144 for ; Thu, 6 Jul 2000 19:16: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 QQiwsb07061 for ; Thu, 6 Jul 2000 15:15:47 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiwsb12257 for ; Thu, 6 Jul 2000 19:15:42 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA02177 for mpls@uu.net; Thu, 6 Jul 2000 15:15:42 -0400 (EDT) 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 QQiwsb12038 for ; Thu, 6 Jul 2000 19:15: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 QQiwsa15183 for ; Thu, 6 Jul 2000 15:14:43 -0400 (EDT) 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 QQiwsa06769 for ; Thu, 6 Jul 2000 19:14:27 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA05507; Thu, 6 Jul 2000 15:14:27 -0400 (EDT) Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-178.cisco.com [161.44.134.178]) by bucket.cisco.com (Mirapoint) with ESMTP id AAA48248; Thu, 6 Jul 2000 15:17:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20000706151449.05443db0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Jul 2000 15:14:57 -0400 To: arun Viswanathan From: "Thomas D. Nadeau" Subject: Re: MPLS TE MIB - Doubts Cc: "Friedeborn, William" , cheenu Srinivasan , arun Viswanathan , mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Paul, > Hi Tom. I apologize. I did not mean to imply that these comments would be >incorporated into the MIB. I was just trying to shed some light on some >commonly >used terms. I choose the term "LSP tunnel" over "tunnel" based on the text in >draft-ietf-mpls-rsvp-lsp-tunnel-05.txt. I think that there is still some confusion here. By "tunnel" I mean MPLS Traffic Engineered Tunnel, nothing more, nothing less. It was not our intent to create a generic tunnel MIB; rather, just to model MPLS Tunnels. > I must say I am surprised by your 'tunnel statement' below. I thought > that the >TE MIB was based on RSVP and CR-LDP (explicitly routed) LSPs. I did not >think of it >as a general tunnel MIB. Don't get me wrong, I don't mean to imply that >this is a >bad thing. I did not realize the scope was this broad. A TE Tunnel first contains the desired parameters that a user wishes to have signaled via the MPLS signaling protocol to form an LSP which can support said parameters. If those parameters are successfully signaled by the MPLS signaling protocol, a corresponding LSP(s) will have been signaled (and will appear in the LSR MIB). It is this LSP(s) which are then pointed at by the TE Tunnel to indicate that they are being used by the TE Tunnel. >I guess the first comment I >have is that the text at the front of the MIB needs to reflect this. Agreed. The text at the front of the MIB should be updated if it does not state that. Can you point out where we contradict the statements I made? --Tom > Paul > >"Thomas D. Nadeau" wrote: > > > > > > > > > > 3. LSP vs Tunnel vs LSP Tunnel - Yep, this stumps me also. > > > > > >First let's get rid of one of the terms. I think that a "tunnel" and > an "LSP > > >tunnel" in the context of the TE MIB are the same things. So throw out > > >"tunnel". It is too general. > > > > No LSP Tunnel. The use of "tunnel" in the TE MIB > > refers to the specific parameters used to describe a > > traffic engineered tunnel which may or may not result in > > the formation of an LSP. > > > > --Tom > >-- >Paul Langille e-mail: langille@crescentnetworks.com >Crescent Networks phone: (978) 244-9002 x244 >201 Riverneck Road fax: (978) 244-9211 >Chelmsford, MA 01824 From owner-mpls@UU.NET Thu Jul 6 19:21: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 TAA27361 for ; Thu, 6 Jul 2000 19:21:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwsr19044; Thu, 6 Jul 2000 23:20:23 GMT Received: by mail-control.mail.uu.net id QQiwsr18651 for mpls-outgoing; Thu, 6 Jul 2000 23:20: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 QQiwsr18642 for ; Thu, 6 Jul 2000 23:19: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 QQiwsr05557 for ; Thu, 6 Jul 2000 19:17:41 -0400 (EDT) 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 QQiwsr17131 for ; Thu, 6 Jul 2000 23:17:25 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA29207 for mpls@uu.net; Thu, 6 Jul 2000 19:17:24 -0400 (EDT) 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 QQiwsr18375 for ; Thu, 6 Jul 2000 23: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 QQiwsq04609 for ; Thu, 6 Jul 2000 19:14:28 -0400 (EDT) Received: from hawk.CrescentNetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.177.194.54]) id QQiwsq17760 for ; Thu, 6 Jul 2000 23:14:12 GMT Received: from crescentnetworks.com (langille.in.crescentnets.com [192.168.29.105]) by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id RAA20161; Thu, 6 Jul 2000 17:23:09 -0400 (EDT) Message-ID: <3964F9BF.C27C68B3@crescentnetworks.com> Date: Thu, 06 Jul 2000 17:27:27 -0400 From: Paul Langille Organization: Crescent Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: arun Viswanathan , "Friedeborn, William" , cheenu Srinivasan , mpls@UU.NET Subject: Re: MPLS TE MIB - Doubts References: <4.3.2.7.2.20000706151449.05443db0@bucket.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tom. Good, now I understand. It would probably be good to have some text at the front of the draft that explains this and references the terms used in the RSVP Tunnel draft and the CR-LDP draft. I will try to throw together some text. (I will be out of the office next week so there will be a delay!) Paul "Thomas D. Nadeau" wrote: > Hi Paul, > > > Hi Tom. I apologize. I did not mean to imply that these comments would be > >incorporated into the MIB. I was just trying to shed some light on some > >commonly > >used terms. I choose the term "LSP tunnel" over "tunnel" based on the text in > >draft-ietf-mpls-rsvp-lsp-tunnel-05.txt. > > I think that there is still some confusion here. By "tunnel" I mean > MPLS Traffic Engineered Tunnel, nothing more, nothing less. It was > not our intent to create a generic tunnel MIB; rather, just to model > MPLS Tunnels. > > > I must say I am surprised by your 'tunnel statement' below. I thought > > that the > >TE MIB was based on RSVP and CR-LDP (explicitly routed) LSPs. I did not > >think of it > >as a general tunnel MIB. Don't get me wrong, I don't mean to imply that > >this is a > >bad thing. I did not realize the scope was this broad. > > A TE Tunnel first contains the desired parameters that a > user wishes to have signaled via the MPLS signaling protocol to form an > LSP which can support said parameters. If those parameters are successfully > signaled by the MPLS signaling protocol, a corresponding LSP(s) will > have been signaled (and will appear in the LSR MIB). It is > this LSP(s) which are then pointed at by the TE Tunnel to > indicate that they are being used by the TE Tunnel. > > >I guess the first comment I > >have is that the text at the front of the MIB needs to reflect this. > > Agreed. The text at the front of the MIB should be updated if > it does not state that. Can you point out where we contradict the > statements I made? > > --Tom > > > Paul > > > >"Thomas D. Nadeau" wrote: > > > > > > > > > > > > > > > 3. LSP vs Tunnel vs LSP Tunnel - Yep, this stumps me also. > > > > > > > >First let's get rid of one of the terms. I think that a "tunnel" and > > an "LSP > > > >tunnel" in the context of the TE MIB are the same things. So throw out > > > >"tunnel". It is too general. > > > > > > No LSP Tunnel. The use of "tunnel" in the TE MIB > > > refers to the specific parameters used to describe a > > > traffic engineered tunnel which may or may not result in > > > the formation of an LSP. > > > > > > --Tom > > > >-- > >Paul Langille e-mail: langille@crescentnetworks.com > >Crescent Networks phone: (978) 244-9002 x244 > >201 Riverneck Road fax: (978) 244-9211 > >Chelmsford, MA 01824 -- Paul Langille e-mail: langille@crescentnetworks.com Crescent Networks phone: (978) 244-9002 x244 201 Riverneck Road fax: (978) 244-9211 Chelmsford, MA 01824 From owner-mpls@UU.NET Thu Jul 6 20:22:21 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27914 for ; Thu, 6 Jul 2000 20:22:20 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwsv16955; Fri, 7 Jul 2000 00:20:34 GMT Received: by mail-control.mail.uu.net id QQiwsv03638 for mpls-outgoing; Fri, 7 Jul 2000 00: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 QQiwsv03626 for ; Fri, 7 Jul 2000 00:20:00 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiwsv27725 for ; Thu, 6 Jul 2000 20:19:53 -0400 (EDT) Received: from web4206.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web4206.mail.yahoo.com [216.115.104.139]) id QQiwsv10769 for ; Fri, 7 Jul 2000 00:19:23 GMT Message-ID: <20000707001922.9320.qmail@web4206.mail.yahoo.com> Received: from [63.88.104.20] by web4206.mail.yahoo.com; Thu, 06 Jul 2000 17:19:22 PDT Date: Thu, 6 Jul 2000 17:19:22 -0700 (PDT) From: Jay Wang Subject: test To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk From owner-mpls@UU.NET Fri Jul 7 07:07: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 HAA20323 for ; Fri, 7 Jul 2000 07:07:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwum05553; Fri, 7 Jul 2000 11:06:32 GMT Received: by mail-control.mail.uu.net id QQiwum06054 for mpls-outgoing; Fri, 7 Jul 2000 11:06: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 QQiwum05743 for ; Fri, 7 Jul 2000 11:05: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 QQiwum06111 for ; Fri, 7 Jul 2000 07:05:40 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiwum05023 for ; Fri, 7 Jul 2000 11:05:25 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA01770 for mpls@uu.net; Fri, 7 Jul 2000 07:05:24 -0400 (EDT) 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 QQiwum05330 for ; Fri, 7 Jul 2000 11:04: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 QQiwum16046 for ; Fri, 7 Jul 2000 07:04:47 -0400 (EDT) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQiwum18863 for ; Fri, 7 Jul 2000 11:04:47 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20241; Fri, 7 Jul 2000 07:04:46 -0400 (EDT) Message-Id: <200007071104.HAA20241@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-mo-mpls-protection-00.txt Date: Fri, 07 Jul 2000 07:04:46 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : General Considerations for Bandwidth Reservation in Protection Author(s) : L. Mo Filename : draft-mo-mpls-protection-00.txt Pages : 5 Date : 06-Jul-00 Protection issues for MPLS LSP have been discussed in recent IETF meetings. Various drafts have different proposals on establishing the working and protection LSP ([1]-[5]). But how to reserve bandwidth for the protection LSP has not be discussed. If the bandwidth for the protection LSP is reserved in a similar fashion as that of the working LSP, the bandwidth utilization in the network would be very poor. In this draft, an algorithm for reserve bandwidth for protection LSP is presented which enables very efficient bandwidth reservation for single fault protection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mo-mpls-protection-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-mo-mpls-protection-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-mo-mpls-protection-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: <20000706151937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mo-mpls-protection-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mo-mpls-protection-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000706151937.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Jul 7 07:47: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 HAA21862 for ; Fri, 7 Jul 2000 07:47:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwup21543; Fri, 7 Jul 2000 11:46:06 GMT Received: by mail-control.mail.uu.net id QQiwup12765 for mpls-outgoing; Fri, 7 Jul 2000 11:45: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 QQiwup12741 for ; Fri, 7 Jul 2000 11:45: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 QQiwup10758 for ; Fri, 7 Jul 2000 07:45:15 -0400 (EDT) From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQiwup21071 for ; Fri, 7 Jul 2000 11:45:00 GMT Received: from cclmsent02.lon.bt.com by gandalf (local) with ESMTP; Fri, 7 Jul 2000 12:18:52 +0100 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2651.88) id <32D4VV01>; Fri, 7 Jul 2000 12:18:40 +0100 Message-ID: To: mpls@UU.NET Subject: Static and dynamic label distribution protocol relationships Date: Fri, 7 Jul 2000 12:18:43 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Folks, Some of you are aware that I am considering the user-plane OAM functional requirements of MPLS LSPs from an operator's perspective. Indeed, I have already had some off/on-list discussions with some of you which have been very useful - so many thanks to those who took time to comment. Note - Our discussions seemed to be converging on defining special 'OAM label' that would sit below the normal user-plane traffic forwarding label. This would simply mean that when a OAM pkt was sent the label depth which would normally be M (say) at some nested LSP level (at or below the level of the OAM pkt insertion) would become M+1. The key identifier now would be the fact that the S bit would be set in the special OAM label instead of the normal forwarding label. More recently however, and partly in preparation of pursuing the OAM work, I have been trying to figure out what are the configuration and dynamic behaviour relationships between the various Label Distribution Protocols (LDPs) and I would be very grateful if anyone could help me on this matter. Considering that........ There are 4 LDP varieties that I am aware of - Vanilla_LDP, RSVP_LDP, CR_LDP and iBGP4_LDP. And where: - The former is the most generic, and largely based on the IGP functional behaviour (eg for the major FEC-types). It uses UDP for discovery and TCP for everything else. - The latter is largely targeted at delivering MPLS-based VPNs, obviously based on BGP4 functional behaviour and has a key role is isolating overlapping v4 private address spaces. It is based on TCP sessions. - The other 2 are mainly targeted at a CBR/TE role and use RSVP extensions and Vanilla_LDP extensions respectively. And one would normally only choose to implement one of these and not both. .......then: 1 What are the allowable or deprecated combinations of LDP that can exist in an operator's network? 2 Does it matter which order the various LDP-types are implemented and brought up? For example, the LSPs of an iBGP4 based VPN would need a server layer LSP (ie label stack of >= 2) within the core LSR network. 3 In 2, should (must?) the server layer LSPs be Vanilla_LDP or could they be RSVP_LDP or CR_LDP? Note that the latter might make more sense when one considers the dynamics of the various LDPs under failure modes, and especially in the case of offering SLAs to VPN customers......see next question. 4 Suppose one had iBGP4 VPN LSPs, running over Vanilla LSPs, running over RSVP or CR_LDP LSPs. What happens dynamically on failure here (this could be various failure modes, but just assume a physical link failure for now)? Note - if the answer to 2 was that the 'bringing-up' order of LDP-types was important, then if seems it would also have to remain so here. So has anyone done any work on understanding the dynamic post-failure relationships of the IGP convergence, BGP4 survival (TCP sessions), Vanilla_LDP (UDP/TCP aspects, and assuming a stable IGP?), the potentially very fast explicitly routed TE LSPs using RSVP/CR_LDP and the overarching iBGP4 VPN LSPs (and the ensuing VPN availability/QoS behaviour that an operator can offer in SLAs)? This whole area of the dynamic post-failure behaviour stacked LDP varieties concerns me and it something I think operators would need to understand better. 5 Can the PHP phenomenon appear in any type of LDP? And if so, are there any hidden implications when various LDP-types are nested? Note - I personally do not like the notion of PHP since it means that I cannot define a consistent trail termination point for an LSP and hence cannot be clear on exactly where key functional behaviour is located, eg defect processing, consequent actions on defect detection (eg sending a FDI to higher level LSPs), restoration triggers, QoS/avail metric processing, etc. I think many operators tuned-in to the list would be grateful for any help in understanding the above relationships more clearly. Regards, Neil From owner-mpls@UU.NET Fri Jul 7 12:23: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 MAA02058 for ; Fri, 7 Jul 2000 12:23:53 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwvh03556; Fri, 7 Jul 2000 16:22:47 GMT Received: by mail-control.mail.uu.net id QQiwvh02843 for mpls-outgoing; Fri, 7 Jul 2000 16:22: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 QQiwvh02790 for ; Fri, 7 Jul 2000 16:21: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 QQiwvh02153 for ; Fri, 7 Jul 2000 12:21:43 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiwvh06424 for ; Fri, 7 Jul 2000 16:21:28 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA13012 for ; Fri, 7 Jul 2000 09:21:40 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA03445 for mpls@uu.net; Fri, 7 Jul 2000 12:21:26 -0400 (EDT) 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 QQiwvh02074 for ; Fri, 7 Jul 2000 16:16: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 QQiwvh27041 for ; Fri, 7 Jul 2000 12:16:15 -0400 (EDT) Received: from tns04.tns-inc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.tns-inc.com [38.164.22.4]) id QQiwvh03546 for ; Fri, 7 Jul 2000 16:16:14 GMT Received: from thrupoint.net (port-b195.ctcnet.com [192.187.244.195]) by tns04.tns-inc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 33RFXBHT; Fri, 7 Jul 2000 12:10:28 -0400 Message-ID: <396601E2.DA9BD474@thrupoint.net> Date: Fri, 07 Jul 2000 12:14:26 -0400 From: Andrew Bender X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: li.mo@fnc.fujitsu.com CC: mpls@UU.NET Subject: Re: I-D ACTION:draft-mo-mpls-protection-00.txt References: <200007071104.HAA20241@ietf.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit If I read this correctly, there are only gains when the working and protect paths incorporate a common node; although this could happen is practice, it is not the preferred alignment. If "X" is in a protect path which is disjoint from the working path, "X" must still reserve the protect path, without any reduction. For every new "Y", this seems to be compounded, if I understand the algorith presented. If we are resigned to the notion of maintaining state on all of the working and protect paths passing through "this" node, it would be desirable to have a provision / means to accommodate only the maximum of outbound link reservations for any given Y failure, rather than all Y failures. Doing so would allow for less UPSR [sic] -like allocation, in the case where single node resiliency is sufficient. > Signaling protocol (either CR-LDP or RSVP-TE) needs to be > improved to convey the following information in order to establish the > D(Y|L,X) and P(Y|L,X). > > ò list of node IDs (router IDs) where the working LSP traverse > ò nature of the setup signaling, either working LSP setup or the > protection LSP setup : : > This algorithm does not require any node to have the complete > bandwidth reservation picture inside the network. Any nodes will only > store the information when it is part of the working or the protection > LSP. Wouldn't a "node list" for the intended "protect LSP" have to be distributed as well, in order for this to work? > This algorithm can also be extended to cover multiple faults > inside the network for efficient bandwidth reservation and such > extensions will not be pursued here. For each compound failure case involving one common node, different protect paths might be preferable / selected in each case. How would "X" be so notified, or which ones would "X" choose? Regards, Andrew Bender thrupoint.net From owner-mpls@UU.NET Fri Jul 7 14:15: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 OAA08314 for ; Fri, 7 Jul 2000 14:15:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwvo05261; Fri, 7 Jul 2000 18:14:23 GMT Received: by mail-control.mail.uu.net id QQiwvo08573 for mpls-outgoing; Fri, 7 Jul 2000 18:13: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 QQiwvo08553 for ; Fri, 7 Jul 2000 18:13: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 QQiwvo16765 for ; Fri, 7 Jul 2000 14:13:32 -0400 (EDT) Received: from kiwi.equinix.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: kiwi.equinix.com [207.20.85.65]) id QQiwvo21982 for ; Fri, 7 Jul 2000 18:13:16 GMT Received: from silicon.corp.equinix.com (silicon [172.16.3.99]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id LAA18349 for ; Fri, 7 Jul 2000 11:13:16 -0700 (PDT) Received: by silicon.corp.equinix.com with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jul 2000 11:13:15 -0700 Message-ID: <29C363D591B1D211B6BF0090273C238031ECA3@silicon.corp.equinix.com> From: Diarmuid Flynn To: mpls@UU.NET Subject: Route Server using labels in BGP-4 attributes Date: Fri, 7 Jul 2000 11:13:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I have recently implemented a version of the Route Sever from Merit, that incorporates the carrying of MPLS labels in BGPv4 attributes. I based the implementation on the draft "Carrying Label Information in BGP-4" by Yakov Rekhter and Eric Rosen. I would like to carry out interoperability testing with this code and was wondering if anybody else has also written code based on Rekhter/Rosen draft that I could use for this purpose. Any joint testing of course would be done under a non- disclosure agreement. Thanks, Diarmuid Flynn Member of Research and Development Staff Equinix Inc, 901 Marshall Rd, Redwood City,CA 94063, U.S.A Tel: 650-817-2257 e-mail : flynn@equinix.com From owner-mpls@UU.NET Fri Jul 7 14:44: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 OAA09553 for ; Fri, 7 Jul 2000 14:44:23 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwvq06727; Fri, 7 Jul 2000 18:43:20 GMT Received: by mail-control.mail.uu.net id QQiwvq11596 for mpls-outgoing; Fri, 7 Jul 2000 18:42: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 QQiwvq11586 for ; Fri, 7 Jul 2000 18:42: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 QQiwvq23542 for ; Fri, 7 Jul 2000 14:42:14 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiwvq21053 for ; Fri, 7 Jul 2000 18:42:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA19417 for mpls@uu.net; Fri, 7 Jul 2000 14:42:13 -0400 (EDT) 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 QQiwvq11563 for ; Fri, 7 Jul 2000 18:41: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 QQiwvq23455 for ; Fri, 7 Jul 2000 14:41:37 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQiwvq20746 for ; Fri, 7 Jul 2000 18:41:36 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 LAA09214; Fri, 7 Jul 2000 11:41:34 -0700 (PDT) Message-ID: <396623BB.5C1282B9@pluris.com> Date: Fri, 07 Jul 2000 11:38:51 -0700 From: Bora Akyol X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow , mpls@UU.NET Subject: Re: Link Bundling References: <200007052142.RAA14677@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, Yakov, et al., I do not think that this internet draft should be adopted as an MPLS working group document. My primary objection to this document is the fact that bundling of L1/L2 interfaces has nothing specific to do with MPLS. In fact, this is an L2 abstraction that should be completely transparent to MPLS, IP or ISIS. I feel that this particular draft is very focused on MPLS-specific concerns and does not provide a good abstraction of the L2 bundling aspects and also places significant restrictions on what can be done with a bundled link and what kind of members it can have. I personally know of at least one implementation (ours) of bundled links that forms such an abstraction to all upper layer protocols. In this implementation, a heterogeneous group of L1/L2 interfaces are bonded together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP treats the bundled (bonded) interface as just another type of interface. When MPLS RSVP messages are passed over the bundled interface, the labels that are assigned are programmed into all members of the bundled links even though in reality a hash is used so that only one of the members are used (to prevent reordering). Bandwidth management is handled by means of the apriori knowledge of the hash. Also note that this particular implementation is not MLPPP since no additional headers are added to the packets. For MPLS specific concerns, the methods that are used in this approach can be expanded. For IP, this particular approach works very well. If there is interest from the MPLS WG, we (myself and another colleague) would be perfectly willing to author an Internet Draft on this particular bond implementation. The question that I have is what is the proper forum to submit a generalized layer 2 bundling draft in the IETF. It is certainly relevant to MPLS, but it is just as relevant to IP, ISIS, etc. Regards Bora Akyol George Swallow wrote: > > Folks, > > > > Kireeti and myself would like to ask the MPLS WG to > > accept draft-kompella-mpls-bundle-01.txt as an > > MPLS WG document. > > > > Yakov. > > Consensus on this will be assessed on 7/12. Opinions should be aired > by then. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Jul 7 15:08: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 PAA10250 for ; Fri, 7 Jul 2000 15:08:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwvs04295; Fri, 7 Jul 2000 19:07:33 GMT Received: by mail-control.mail.uu.net id QQiwvs25077 for mpls-outgoing; Fri, 7 Jul 2000 19:06:57 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiwvs25072 for ; Fri, 7 Jul 2000 19:06: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 QQiwvs26564 for ; Fri, 7 Jul 2000 15:06:46 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQiwvs17685 for ; Fri, 7 Jul 2000 19:06:45 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jul 2000 12:13:30 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A66269085F@ICARIAN> From: Eric Gray To: "'Bora Akyol'" , George Swallow , mpls@UU.NET Cc: Eric Gray Subject: RE: Link Bundling Date: Fri, 7 Jul 2000 12:13:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Bora, I essentially agree with the observation that link bundling is not inherently an MPLS issue and I also feel that this draft - at least as is - should not be adopted by the MPLS working group. However, my reasoning is slightly different than yours. While the draft does include a lot of stuff that is specific to MPLS, it also includes a ton of IS-IS and OSPF specific stuff as well. My sense is that it actually has significantly more non-MPLS related stuff in it than MPLS related stuff. Other people may disagree but, at the very least, this work should be done in a forum that is less focused on label switching and more focused on routing. I do not think it is very useful to provide examples of proprietary approaches to solving the problem. It takes two to bundle links. But, if your point is that it may be a good idea to back away from a link-bundling scheme that is particular to MPLS LSP based links, I think it is a good point. -- Eric Gray > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: Friday, July 07, 2000 11:39 AM > To: George Swallow; mpls@UU.NET > Subject: Re: Link Bundling > > > George, Yakov, et al., > > I do not think that this internet draft should be adopted as an MPLS > working group document. My primary objection to this document > is the fact > that bundling of L1/L2 interfaces has nothing specific to do > with MPLS. > In fact, this is an L2 abstraction that should be completely > transparent > to MPLS, IP or ISIS. I feel that this particular draft is > very focused on > MPLS-specific concerns and does not provide a good > abstraction of the L2 > bundling aspects and also places significant restrictions on > what can be > done with a bundled link and what kind of members it can have. > > I personally know of at least one implementation (ours) of > bundled links > that forms such an abstraction to all upper layer protocols. In this > implementation, a heterogeneous group of L1/L2 interfaces are bonded > together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP > treats the > bundled (bonded) interface as just another type of interface. > When MPLS > RSVP messages are passed over the bundled interface, the > labels that are > assigned are programmed into all members of the bundled links > even though > in reality a hash is used so that only one of the members are used (to > prevent reordering). Bandwidth management is handled by means of the > apriori knowledge of the hash. Also note that this particular > implementation is not MLPPP since no additional headers are > added to the > packets. > For MPLS specific concerns, the methods that are used in this approach > can be expanded. For IP, this particular approach works very well. > > If there is interest from the MPLS WG, we (myself and another > colleague) > would be perfectly willing to author an Internet Draft on > this particular > bond implementation. The question that I have is what is the > proper forum > to submit a generalized layer 2 bundling draft in the IETF. It is > certainly relevant to MPLS, but it is just as relevant to IP, > ISIS, etc. > > Regards > > Bora Akyol > > > George Swallow wrote: > > > > Folks, > > > > > > Kireeti and myself would like to ask the MPLS WG to > > > accept draft-kompella-mpls-bundle-01.txt as an > > > MPLS WG document. > > > > > > Yakov. > > > > Consensus on this will be assessed on 7/12. Opinions > should be aired > > by then. > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > From owner-mpls@UU.NET Fri Jul 7 15:19: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 PAA10467 for ; Fri, 7 Jul 2000 15:19:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwvt23775; Fri, 7 Jul 2000 19:18:46 GMT Received: by mail-control.mail.uu.net id QQiwvt26179 for mpls-outgoing; Fri, 7 Jul 2000 19:18: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 QQiwvt26174 for ; Fri, 7 Jul 2000 19:18: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 QQiwvt28744 for ; Fri, 7 Jul 2000 15:18:06 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiwvt10329 for ; Fri, 7 Jul 2000 19:18:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA24632 for mpls@uu.net; Fri, 7 Jul 2000 15:18:05 -0400 (EDT) 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 QQiwvt26151 for ; Fri, 7 Jul 2000 19:17: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 QQiwvt29135 for ; Fri, 7 Jul 2000 15:17:30 -0400 (EDT) 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 QQiwvt09924 for ; Fri, 7 Jul 2000 19:17:15 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 PAA27213; Fri, 7 Jul 2000 15:17:05 -0400 (EDT) Received: (tnadeau@localhost) by spectacle.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) id PAA29978; Fri, 7 Jul 2000 15:17:05 -0400 (EDT) Date: Fri, 7 Jul 2000 15:17:05 -0400 (EDT) Message-Id: <200007071917.PAA29978@spectacle.cisco.com> From: "Thomas D. Nadeau" To: mpls@UU.NET CC: cheenu Srinivasan , arun Viswanathan , tnadeau@cisco.com Subject: draft-ietf-mpls-lsr-mib-05.txt Sender: owner-mpls@UU.NET Precedence: bulk FYI, a new version of the MPLS LSR MIB was submitted today which reflects changes made during the MPLS WG Last Call II comment period. It should be available shortly on the WG web page. Title : MPLS Label Switch Router Management Information Base Using SMIv2 Author(s) : Cheenu Srinivasan, Cheenu Srinivasan, Thomas D. Nadeau Filename : draft-ietf-mpls-lsr-mib-05.txt Pages : 54 Date : 07-Jul-00 From owner-mpls@UU.NET Fri Jul 7 15:26: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 PAA10607 for ; Fri, 7 Jul 2000 15:26:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwvt27048; Fri, 7 Jul 2000 19:25:04 GMT Received: by mail-control.mail.uu.net id QQiwvt26981 for mpls-outgoing; Fri, 7 Jul 2000 19:24:39 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 QQiwvt26974 for ; Fri, 7 Jul 2000 19:24:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiwvt29934 for ; Fri, 7 Jul 2000 15:24:24 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiwvt13804 for ; Fri, 7 Jul 2000 19:24:23 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA25670 for mpls@uu.net; Fri, 7 Jul 2000 15:24:23 -0400 (EDT) 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 QQiwvt26941 for ; Fri, 7 Jul 2000 19:24: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 QQiwvt29847 for ; Fri, 7 Jul 2000 15:23:51 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQiwvt13367 for ; Fri, 7 Jul 2000 19:23:20 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 MAA13208; Fri, 7 Jul 2000 12:23:11 -0700 (PDT) Message-ID: <39662E1E.F90E8B0E@pluris.com> Date: Fri, 07 Jul 2000 12:23:10 -0700 From: Bora Akyol X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Gray CC: George Swallow , mpls@UU.NET Subject: Re: Link Bundling References: <9A564CC874B5D3118FB9009027B0A66269085F@ICARIAN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric As I mentioned in my previous email, I would be happy to write an ID that describes our approach and work with the community to make it an open standard. I believe that the bonding of L1 links into one bonded (bundled) L2 link is something that should be protocol-neutral and should work with all L3 protocols. I believe that such an abstraction is possible and is actually fairly straightforward to implement and provides a coherent framework that one can use to ask questions like if protocol X were to run over a bonded link, how would it run; and then actually answer it in an easy manner. Thanks for the comments, Bora Eric Gray wrote: > Bora, > > I essentially agree with the observation that > link bundling is not inherently an MPLS issue and I > also feel that this draft - at least as is - should > not be adopted by the MPLS working group. However, > my reasoning is slightly different than yours. > > While the draft does include a lot of stuff > that is specific to MPLS, it also includes a ton of > IS-IS and OSPF specific stuff as well. My sense is > that it actually has significantly more non-MPLS > related stuff in it than MPLS related stuff. Other > people may disagree but, at the very least, this > work should be done in a forum that is less focused > on label switching and more focused on routing. > > I do not think it is very useful to provide > examples of proprietary approaches to solving the > problem. It takes two to bundle links. But, if > your point is that it may be a good idea to back > away from a link-bundling scheme that is particular > to MPLS LSP based links, I think it is a good point. > > -- > Eric Gray > > > -----Original Message----- > > From: Bora Akyol [mailto:akyol@pluris.com] > > Sent: Friday, July 07, 2000 11:39 AM > > To: George Swallow; mpls@UU.NET > > Subject: Re: Link Bundling > > > > > > George, Yakov, et al., > > > > I do not think that this internet draft should be adopted as an MPLS > > working group document. My primary objection to this document > > is the fact > > that bundling of L1/L2 interfaces has nothing specific to do > > with MPLS. > > In fact, this is an L2 abstraction that should be completely > > transparent > > to MPLS, IP or ISIS. I feel that this particular draft is > > very focused on > > MPLS-specific concerns and does not provide a good > > abstraction of the L2 > > bundling aspects and also places significant restrictions on > > what can be > > done with a bundled link and what kind of members it can have. > > > > I personally know of at least one implementation (ours) of > > bundled links > > that forms such an abstraction to all upper layer protocols. In this > > implementation, a heterogeneous group of L1/L2 interfaces are bonded > > together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP > > treats the > > bundled (bonded) interface as just another type of interface. > > When MPLS > > RSVP messages are passed over the bundled interface, the > > labels that are > > assigned are programmed into all members of the bundled links > > even though > > in reality a hash is used so that only one of the members are used (to > > prevent reordering). Bandwidth management is handled by means of the > > apriori knowledge of the hash. Also note that this particular > > implementation is not MLPPP since no additional headers are > > added to the > > packets. > > For MPLS specific concerns, the methods that are used in this approach > > can be expanded. For IP, this particular approach works very well. > > > > If there is interest from the MPLS WG, we (myself and another > > colleague) > > would be perfectly willing to author an Internet Draft on > > this particular > > bond implementation. The question that I have is what is the > > proper forum > > to submit a generalized layer 2 bundling draft in the IETF. It is > > certainly relevant to MPLS, but it is just as relevant to IP, > > ISIS, etc. > > > > Regards > > > > Bora Akyol > > > > > > George Swallow wrote: > > > > > > Folks, > > > > > > > > Kireeti and myself would like to ask the MPLS WG to > > > > accept draft-kompella-mpls-bundle-01.txt as an > > > > MPLS WG document. > > > > > > > > Yakov. > > > > > > Consensus on this will be assessed on 7/12. Opinions > > should be aired > > > by then. > > > > > > ...George > > > > > > ================================================================== > > > George Swallow Cisco Systems (978) 244-8143 > > > 250 Apollo Drive > > > Chelmsford, Ma 01824 > > > > > > From owner-mpls@UU.NET Fri Jul 7 18:37: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 SAA14853 for ; Fri, 7 Jul 2000 18:37:02 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwwg27384; Fri, 7 Jul 2000 22:35:41 GMT Received: by mail-control.mail.uu.net id QQiwwg12940 for mpls-outgoing; Fri, 7 Jul 2000 22:35: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 QQiwwg12932 for ; Fri, 7 Jul 2000 22:35: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 QQiwwg01990 for ; Fri, 7 Jul 2000 18:34:57 -0400 (EDT) Received: from ix.eng.level3.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gdffw1.denver1.level3.net [209.244.1.161]) id QQiwwg26386 for ; Fri, 7 Jul 2000 22:34:56 GMT Received: from level3.net (IDENT:luca@localhost [127.0.0.1]) by ix.eng.level3.net (8.9.3/8.9.3) with ESMTP id QAA09450; Fri, 7 Jul 2000 16:33:38 -0600 Message-ID: <39665AC1.4D99A82E@level3.net> Date: Fri, 07 Jul 2000 22:33:37 +0000 From: Luca Martini Organization: Level 3 Communications X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: it,fr-CA,fr-FR,en-US MIME-Version: 1.0 To: "Andrew G. Malis" CC: nna@level3.net, dvlachos@cisco.com, tappan@cisco.com, erosen@cisco.com, sjv@laurelnetworks.com, mpls@UU.NET, roy@level3.net Subject: Re: Comments on draft-martini-l2circuit-trans-mpls-01.txt References: <4.3.2.7.2.20000630224554.02901f68@10.2.0.5> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the comments , see balow. "Andrew G. Malis" wrote: > > Luca et al, > > I was glad to see that you addressed some (but not all of) the comments on > -00, and I have some additional comments as well on -01. > > 1. There is no way to signal whether or not the sequencing control word is > used on a particular LSP, which is necessary since it is listed as optional > in sections 4 and 5. You either need a bit in the LDP VC FEC Element TLV, > or a second set of VC types. It's probably easiest to allocate the top bit > from the VC type field for this use. > Yes, I had originally intended to have it configured properly , on both ends. But I agree that in some cases it would be better to signal it. I'll add this. > 2. When encapsulating Ethernet and Ethernet VLAN, section 5.3 does not > state whether or not the original FCS is preserved in the encapsulated > frame. You should make this clear, and also follow the examples of RFCs > 2684 and 2427 and have different VC types for VCs with and without FCS > preserved. > Actually I want to be consistent and strip the FCS in the same way as the aal5 trailer is stripped out. > 3. What is the intended functionality for the Group ID field? One possible > use could be to allow some sort of end-to-end multilink capability over > multiple LSPs. Another possible use is to identify the particular port an > LSP is associated with, since there could be many ports on the same > terminating node with the same DLCI or VPI/VCI. It clearly needs to be > much better defined, along with the specific semantics of the VC ID length > being zero. Right now I can only speculate. > It is a user configurable value meant to augment the VC space. It is intended to group all VCs going to a specific egress LSR. I will add some more explanation. As far as the VC length=0 it just means that all VCs in that group are withdrawn. This might be useful if one considers a group equivalent to a virtual tunnel between two LSRs, and the tunnel is shutdown. > 4. Back in December, Greg Waters had a good comment that since FR and ATM > VCs are bidirectional, there needs to be a discussion of how this can be > simulated using two associated tunneled LDP sessions. This comment wasn't > addressed. Or perhaps this is the actual intended use of the Group ID? > In order to achieve bidirectional transport both ends where packets ingress the network will need to be configured with the egress destination. The VC mapping should be the same, for simplicity , but this is not necessary. There will only be one LDP session between any two LSRs,and there should be no problem as label exchange goes in both directions. I am not sure that I understand what the problem is, I added some more explenation on this subject. > 5. VC types 5, 6, and 7 are missing associated text in section 5. > I have left those TBD so I did not put a section in yet. > Thanks, > Andy > > ________________________________________________________________________ > Andrew G. Malis Andy.Malis@vivacenetworks.com phone:408-383-7223 > Vivace Networks/2730 Orchard Parkway/San Jose, CA 95134/fax:408-904-4748 -- Just say no to summer. Ski all year ! Luca Martini Senior Network Engineer, Level 3 Communications - Broomfield, CO luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager page-luca@level3.net From owner-mpls@UU.NET Sat Jul 8 04:22: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 EAA04048 for ; Sat, 8 Jul 2000 04:22:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwxs13633; Sat, 8 Jul 2000 08:12:06 GMT Received: by mail-control.mail.uu.net id QQiwxs04701 for mpls-outgoing; Sat, 8 Jul 2000 08:11:26 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiwxs04695 for ; Sat, 8 Jul 2000 08:11: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 QQiwxs10444 for ; Sat, 8 Jul 2000 04:11:14 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiwxs05500 for ; Sat, 8 Jul 2000 08:10:58 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id EAA10657 for mpls@uu.net; Sat, 8 Jul 2000 04:10:58 -0400 (EDT) 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 QQiwxs04467 for ; Sat, 8 Jul 2000 08:10:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiwxs05388 for ; Sat, 8 Jul 2000 04:10:11 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQiwxs11663 for ; Sat, 8 Jul 2000 08:09:40 GMT Received: from sj-dial-1-136.cisco.com (sj-dial-1-136.cisco.com [171.68.179.137]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA26729; Sat, 8 Jul 2000 01:09:06 -0700 (PDT) Date: Sat, 8 Jul 2000 01:04:12 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <944.000708@cisco.com> To: Bora Akyol CC: Eric Gray , George Swallow , mpls@UU.NET Subject: Re: Link Bundling In-reply-To: <39662E1E.F90E8B0E@pluris.com> References: <39662E1E.F90E8B0E@pluris.com> 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 Bora, Eric, group. 1. I think it is not quite appropriate to speak about L2 vs L3 link bundling. Approaches can be different, both have their pros and cons, but both have a right to live. So, I don't think this should be a driving factor. 2. Link bundling, in the context it is presented in the document, seems to be MPLS-specific to me. 3. MPLS-specific contents vs routing-protocol-specific contents. It should be noted that TE attributes introduced to OSPF and ISIS are transmitted by respective protocols as opaque data, not taken into consideration by the protocol itself (other than flooding), so, strictly speaking, as soon as we have specified a standard way to carry such data, and this data does not affect operations of the protocol itself, changes in the actual data being propagated is no more a business of that protocol. I think the document is purely MPLS-specific, covering several areas of MPLS-related functions. OSPF & ISIS are used just as transport protocols and that makes perfect sense to me. I don't see much sense in braking the document into 3 separate parts and presenting them at OSPF, ISIS, and RSVP WGs, especially taking into consideration that the changes are MPLS-specific... My vote: accept. -- Alex Zinin Friday, July 07, 2000, 12:23 PM, Bora Akyol wrote: > Eric > As I mentioned in my previous email, I would be happy to write an ID that > describes our approach and work with the community to make it an open > standard. > I believe that the bonding of L1 links into one bonded (bundled) L2 link is > something that should be protocol-neutral and should work with all L3 > protocols. I believe that such an abstraction is possible and is actually > fairly straightforward to implement and provides a coherent framework that > one can use to ask questions like if protocol X were to run over a bonded > link, how would it run; and then actually answer it in an easy manner. > Thanks for the comments, > Bora > Eric Gray wrote: >> Bora, >> >> I essentially agree with the observation that >> link bundling is not inherently an MPLS issue and I >> also feel that this draft - at least as is - should >> not be adopted by the MPLS working group. However, >> my reasoning is slightly different than yours. >> >> While the draft does include a lot of stuff >> that is specific to MPLS, it also includes a ton of >> IS-IS and OSPF specific stuff as well. My sense is >> that it actually has significantly more non-MPLS >> related stuff in it than MPLS related stuff. Other >> people may disagree but, at the very least, this >> work should be done in a forum that is less focused >> on label switching and more focused on routing. >> >> I do not think it is very useful to provide >> examples of proprietary approaches to solving the >> problem. It takes two to bundle links. But, if >> your point is that it may be a good idea to back >> away from a link-bundling scheme that is particular >> to MPLS LSP based links, I think it is a good point. >> >> -- >> Eric Gray >> >> > -----Original Message----- >> > From: Bora Akyol [mailto:akyol@pluris.com] >> > Sent: Friday, July 07, 2000 11:39 AM >> > To: George Swallow; mpls@UU.NET >> > Subject: Re: Link Bundling >> > >> > >> > George, Yakov, et al., >> > >> > I do not think that this internet draft should be adopted as an MPLS >> > working group document. My primary objection to this document >> > is the fact >> > that bundling of L1/L2 interfaces has nothing specific to do >> > with MPLS. >> > In fact, this is an L2 abstraction that should be completely >> > transparent >> > to MPLS, IP or ISIS. I feel that this particular draft is >> > very focused on >> > MPLS-specific concerns and does not provide a good >> > abstraction of the L2 >> > bundling aspects and also places significant restrictions on >> > what can be >> > done with a bundled link and what kind of members it can have. >> > >> > I personally know of at least one implementation (ours) of >> > bundled links >> > that forms such an abstraction to all upper layer protocols. In this >> > implementation, a heterogeneous group of L1/L2 interfaces are bonded >> > together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP >> > treats the >> > bundled (bonded) interface as just another type of interface. >> > When MPLS >> > RSVP messages are passed over the bundled interface, the >> > labels that are >> > assigned are programmed into all members of the bundled links >> > even though >> > in reality a hash is used so that only one of the members are used (to >> > prevent reordering). Bandwidth management is handled by means of the >> > apriori knowledge of the hash. Also note that this particular >> > implementation is not MLPPP since no additional headers are >> > added to the >> > packets. >> > For MPLS specific concerns, the methods that are used in this approach >> > can be expanded. For IP, this particular approach works very well. >> > >> > If there is interest from the MPLS WG, we (myself and another >> > colleague) >> > would be perfectly willing to author an Internet Draft on >> > this particular >> > bond implementation. The question that I have is what is the >> > proper forum >> > to submit a generalized layer 2 bundling draft in the IETF. It is >> > certainly relevant to MPLS, but it is just as relevant to IP, >> > ISIS, etc. >> > >> > Regards >> > >> > Bora Akyol >> > >> > >> > George Swallow wrote: >> > >> > > > Folks, >> > > > >> > > > Kireeti and myself would like to ask the MPLS WG to >> > > > accept draft-kompella-mpls-bundle-01.txt as an >> > > > MPLS WG document. >> > > > >> > > > Yakov. >> > > >> > > Consensus on this will be assessed on 7/12. Opinions >> > should be aired >> > > by then. >> > > >> > > ...George >> > > >> > > ================================================================== >> > > George Swallow Cisco Systems (978) 244-8143 >> > > 250 Apollo Drive >> > > Chelmsford, Ma 01824 >> > >> > >> > From owner-mpls@UU.NET Sat Jul 8 11:39: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 LAA06719 for ; Sat, 8 Jul 2000 11:39:45 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiwyw02132; Sat, 8 Jul 2000 15:30:22 GMT Received: by mail-control.mail.uu.net id QQiwyw16445 for mpls-outgoing; Sat, 8 Jul 2000 15:30: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 QQiwyv16410 for ; Sat, 8 Jul 2000 15:29: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 QQiwyv08579 for ; Sat, 8 Jul 2000 11:29:38 -0400 (EDT) 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 QQiwyv10602 for ; Sat, 8 Jul 2000 15:29:37 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA22624 for mpls@uu.net; Sat, 8 Jul 2000 11:29:37 -0400 (EDT) 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 QQiwyv16385 for ; Sat, 8 Jul 2000 15:29:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiwyv14315 for ; Sat, 8 Jul 2000 11:29:12 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQiwyv10346 for ; Sat, 8 Jul 2000 15:29:11 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 IAA15830; Sat, 8 Jul 2000 08:29:08 -0700 (PDT) Message-ID: <396748A9.2EFB6F98@pluris.com> Date: Sat, 08 Jul 2000 08:28:41 -0700 From: Bora Akyol X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: Eric Gray , George Swallow , mpls@UU.NET Subject: Re: Link Bundling References: <39662E1E.F90E8B0E@pluris.com> <944.000708@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Alex Zinin wrote: > Bora, Eric, group. > > 1. I think it is not quite appropriate to speak about L2 vs L3 > link bundling. Approaches can be different, both have their > pros and cons, but both have a right to live. So, I don't think > this should be a driving factor. IMHO, bundling at L2 level and representing a single abstraction to L3 protocols is a cleaner approach. For example, in this draft, even though the links are bundled, when you request a label, there is the notion of requesting a label on a particular link (essentially unbundling things). When ISIS/OSPF run over a bundled link, the text mentions the fact that they can indeed run over only a single member of the link. But which member? What happens if that particular member fails? These are some of the questions that would be (are) answered by a good L2 bundling abstraction. > > 2. Link bundling, in the context it is presented in the document, > seems to be MPLS-specific to me. > Yes, but there is no reason for it to be MPLS specific. > > 3. MPLS-specific contents vs routing-protocol-specific contents. > It should be noted that TE attributes introduced to OSPF and ISIS > are transmitted by respective protocols as opaque data, not > taken into consideration by the protocol itself (other than > flooding), so, strictly speaking, as soon as we have specified > a standard way to carry such data, and this data does not affect > operations of the protocol itself, changes in the actual data > being propagated is no more a business of that protocol. > OK. > > I think the document is purely MPLS-specific, covering several > areas of MPLS-related functions. OSPF & ISIS are used just as transport > protocols and that makes perfect sense to me. > I don't see much sense in braking the document into 3 separate > parts and presenting them at OSPF, ISIS, and RSVP WGs, especially > taking into consideration that the changes are MPLS-specific... > My suggestion was not to split the document but to come up with a better abstraction than what is presented in this document. We will be submitting an internet draft on such an implementation soon (but probably not before the deadline for Pittsburgh). Regards Bora Akyol > > My vote: accept. > > -- > Alex Zinin > > Friday, July 07, 2000, 12:23 PM, Bora Akyol wrote: > > > Eric > > > As I mentioned in my previous email, I would be happy to write an ID that > > describes our approach and work with the community to make it an open > > standard. > > > I believe that the bonding of L1 links into one bonded (bundled) L2 link is > > something that should be protocol-neutral and should work with all L3 > > protocols. I believe that such an abstraction is possible and is actually > > fairly straightforward to implement and provides a coherent framework that > > one can use to ask questions like if protocol X were to run over a bonded > > link, how would it run; and then actually answer it in an easy manner. > > > Thanks for the comments, > > > Bora > > > Eric Gray wrote: > > >> Bora, > >> > >> I essentially agree with the observation that > >> link bundling is not inherently an MPLS issue and I > >> also feel that this draft - at least as is - should > >> not be adopted by the MPLS working group. However, > >> my reasoning is slightly different than yours. > >> > >> While the draft does include a lot of stuff > >> that is specific to MPLS, it also includes a ton of > >> IS-IS and OSPF specific stuff as well. My sense is > >> that it actually has significantly more non-MPLS > >> related stuff in it than MPLS related stuff. Other > >> people may disagree but, at the very least, this > >> work should be done in a forum that is less focused > >> on label switching and more focused on routing. > >> > >> I do not think it is very useful to provide > >> examples of proprietary approaches to solving the > >> problem. It takes two to bundle links. But, if > >> your point is that it may be a good idea to back > >> away from a link-bundling scheme that is particular > >> to MPLS LSP based links, I think it is a good point. > >> > >> -- > >> Eric Gray > >> > >> > -----Original Message----- > >> > From: Bora Akyol [mailto:akyol@pluris.com] > >> > Sent: Friday, July 07, 2000 11:39 AM > >> > To: George Swallow; mpls@UU.NET > >> > Subject: Re: Link Bundling > >> > > >> > > >> > George, Yakov, et al., > >> > > >> > I do not think that this internet draft should be adopted as an MPLS > >> > working group document. My primary objection to this document > >> > is the fact > >> > that bundling of L1/L2 interfaces has nothing specific to do > >> > with MPLS. > >> > In fact, this is an L2 abstraction that should be completely > >> > transparent > >> > to MPLS, IP or ISIS. I feel that this particular draft is > >> > very focused on > >> > MPLS-specific concerns and does not provide a good > >> > abstraction of the L2 > >> > bundling aspects and also places significant restrictions on > >> > what can be > >> > done with a bundled link and what kind of members it can have. > >> > > >> > I personally know of at least one implementation (ours) of > >> > bundled links > >> > that forms such an abstraction to all upper layer protocols. In this > >> > implementation, a heterogeneous group of L1/L2 interfaces are bonded > >> > together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP > >> > treats the > >> > bundled (bonded) interface as just another type of interface. > >> > When MPLS > >> > RSVP messages are passed over the bundled interface, the > >> > labels that are > >> > assigned are programmed into all members of the bundled links > >> > even though > >> > in reality a hash is used so that only one of the members are used (to > >> > prevent reordering). Bandwidth management is handled by means of the > >> > apriori knowledge of the hash. Also note that this particular > >> > implementation is not MLPPP since no additional headers are > >> > added to the > >> > packets. > >> > For MPLS specific concerns, the methods that are used in this approach > >> > can be expanded. For IP, this particular approach works very well. > >> > > >> > If there is interest from the MPLS WG, we (myself and another > >> > colleague) > >> > would be perfectly willing to author an Internet Draft on > >> > this particular > >> > bond implementation. The question that I have is what is the > >> > proper forum > >> > to submit a generalized layer 2 bundling draft in the IETF. It is > >> > certainly relevant to MPLS, but it is just as relevant to IP, > >> > ISIS, etc. > >> > > >> > Regards > >> > > >> > Bora Akyol > >> > > >> > > >> > George Swallow wrote: > >> > > >> > > > Folks, > >> > > > > >> > > > Kireeti and myself would like to ask the MPLS WG to > >> > > > accept draft-kompella-mpls-bundle-01.txt as an > >> > > > MPLS WG document. > >> > > > > >> > > > Yakov. > >> > > > >> > > Consensus on this will be assessed on 7/12. Opinions > >> > should be aired > >> > > by then. > >> > > > >> > > ...George > >> > > > >> > > ================================================================== > >> > > George Swallow Cisco Systems (978) 244-8143 > >> > > 250 Apollo Drive > >> > > Chelmsford, Ma 01824 > >> > > >> > > >> > From owner-mpls@UU.NET Sun Jul 9 04:27: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 EAA06898 for ; Sun, 9 Jul 2000 04:27:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixbl18415; Sun, 9 Jul 2000 08:17:37 GMT Received: by mail-control.mail.uu.net id QQixbl18861 for mpls-outgoing; Sun, 9 Jul 2000 08:17: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 QQixbl18856 for ; Sun, 9 Jul 2000 08:17:02 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixbl26220 for ; Sun, 9 Jul 2000 04:16:59 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQixbl13236 for ; Sun, 9 Jul 2000 08:16:59 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id BAA18785; Sun, 9 Jul 2000 01:16:47 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id BAA26488; Sun, 9 Jul 2000 01:15:57 -0700 (PDT) Date: Sun, 9 Jul 2000 01:15:57 -0700 (PDT) From: Kireeti Kompella Message-Id: <200007090815.BAA26488@kummer.juniper.net> To: akyol@pluris.com, azinin@cisco.com Subject: Re: Link Bundling Cc: EGray@zaffire.com, mpls@UU.NET, swallow@cisco.com Sender: owner-mpls@UU.NET Precedence: bulk Bora, > IMHO, bundling at L2 level and representing a single abstraction to L3 protocols > is a cleaner approach. Would you likewise say that MPLS protection is redundant because L2 protection is "cleaner"? Let me repeat the primary intent of the bundling document: to reduce TE state in ISIS/OSPF. Forcing bundling at L2 just to improve TE scaling seems an overkill. There are other issues: 1) L2 "bundling" changes the topology of the network. Those who are satisfied with their topology for IP but would like better scaling for MPLS/TE may not want L2 bundling. 2) Can L2 bundling deal with disparate L1/L2 media? 3) How does L2 bundling solve the problem of hundreds of lambdas in a fiber (or multiple fibers) connecting two LSRs? > For example, in this draft, even though the links are > bundled, when you request a label, there is the notion of requesting a label on a > particular link (essentially unbundling things). Again, the intent to reduce ISIS/OSPF TE state. "Unbundling" locally between two neighbors is perfectly fine, even necessary. > When ISIS/OSPF run over a > bundled link, the text mentions the fact that they can indeed run over only a > single member of the link. But which member? What happens if that particular > member fails? Running ISIS/OSPF over a single member is a small but useful optimization, and quite orthogonal to the issue of bundling. Is this the extent of your issues with MPLS/TE bundling? [...] > My suggestion was not to split the document but to come up with a better > abstraction than what is presented in this document. We will be submitting an > internet draft on such an implementation soon (but probably not before the > deadline for Pittsburgh). I'm sure your document is an excellent one. However, having L2 bonding doesn't preclude having MPLS/TE bundling. You have yet to convince me that L2 bonding is better than MPLS/TE bundling, and more importantly, that L2 bonding is even as good as MPLS/TE bundling in the MPL(ambda)S context. Kireeti. From owner-mpls@UU.NET Sun Jul 9 14:33: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 OAA09509 for ; Sun, 9 Jul 2000 14:33:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixcz02482; Sun, 9 Jul 2000 18:23:56 GMT Received: by mail-control.mail.uu.net id QQixcz12780 for mpls-outgoing; Sun, 9 Jul 2000 18:23: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 QQixcz12772 for ; Sun, 9 Jul 2000 18:23: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 QQixcz14795 for ; Sun, 9 Jul 2000 14:23:11 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQixcz01843 for ; Sun, 9 Jul 2000 18:23:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA10565 for mpls@uu.net; Sun, 9 Jul 2000 14:23:09 -0400 (EDT) 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 QQixcz12744 for ; Sun, 9 Jul 2000 18:22: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 QQixcz28805 for ; Sun, 9 Jul 2000 14:22:28 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQixcz02510 for ; Sun, 9 Jul 2000 18:22:08 GMT Received: from sj-dial-2-149.cisco.com (sj-dial-2-149.cisco.com [10.19.226.150]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA19599; Sun, 9 Jul 2000 11:21:24 -0700 (PDT) Date: Sun, 9 Jul 2000 11:16:29 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <9469.000709@cisco.com> To: "James R. Leu" CC: mpls@UU.NET Subject: Re: LSP hierarchy with MPLS TE In-reply-To: <20000626104316.B901@laurelnetworks.com> References: <20000626104316.B901@laurelnetworks.com> 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 James, the draft talks about TE attributes, described in [OSPF-TE], not about the link records in router-LSA. -- Alex Zinin Monday, June 26, 2000, 7:43 AM, James R. Leu wrote: > On Thu, Jun 22, 2000 at 11:05:43AM -0400, George Swallow wrote: >> Folks, >> >> Yakov and Kireeti have requested that draft-kompella-lsp-hierarchy-00.txt >> be accepted as a work group document. So far I've only seen support. >> If there are no objects by 6/27, we'll declare it so. > Maybe this isn't a significant issues, but: > In section "4.1.2. Link ID (OSPF only)" it states: > The Link ID is set to the Router ID of the head end of FA-LSP. > Doesn't this conflict with RFC2328 Section 12.4.1. Router-LSAs: > Link type Description Link ID > __________________________________________________ > 1 Point-to-point Neighbor Router ID > link > How does the above affect the following (from RFC2328 Section 12.4.1 > as well)? > In addition, the Link Data field is specified for each link. > For ... numbered point-to-point links ... this field specifies > the IP interface address of the associated router interface. > ... > For unnumbered point-to-point links, the Link Data field should > be set to the unnumbered interface's MIB-II [Ref8] ifIndex value. > Jim From owner-mpls@UU.NET Sun Jul 9 18:41: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 SAA11432 for ; Sun, 9 Jul 2000 18:41:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixdq06708; Sun, 9 Jul 2000 22:32:07 GMT Received: by mail-control.mail.uu.net id QQixdq10415 for mpls-outgoing; Sun, 9 Jul 2000 22:31:50 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 QQixdq10405 for ; Sun, 9 Jul 2000 22:31: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 QQixdq00829 for ; Sun, 9 Jul 2000 18:31:21 -0400 (EDT) Received: from mail.krioukov.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: cj114416-a.reston1.va.home.com [24.15.191.36]) id QQixdq06310 for ; Sun, 9 Jul 2000 22:31:05 GMT Received: from VA1ENG128 (dhcp-host-017.cj114416-a.reston1.va.home.com [192.168.1.17]) by mail.krioukov.net (8.9.3/8.9.3) with SMTP id SAA04165 for ; Sun, 9 Jul 2000 18:18:16 -0400 From: "Dmitri Krioukov" To: Subject: mpl(amda)s questions Date: Sun, 9 Jul 2000 18:45:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit in the context of the (augmented) ip over mpl(amda)s model, advertising lsp/lp state information as link state information into the igp becomes virtually unavoidable. doesn't this again pose the question about the fundamental problem of running routing protocols derived from the static graph theory (stable, fixed topology) on essentially dynamic (being dynamically modified by the te control plane) l2 topologies? what is the fundamental difference between this approach and having, say, an ls protocol with weights depending on load (with all its well-known downsides (oscillations, instability, cpu load, etc.))? on the other hand, although it's well understood that *highly* dynamic, data driven lsp setups are not permitted, some manageable and *relatively* dynamic (ie, "stable") te control systems are required for te purposes (like congestion avoidance). any references to these systems? do they already exist or are they under research? are any statistical prediction mechanisms (like markov chains) used here? thanks, -- dima. From owner-mpls@UU.NET Sun Jul 9 20:59: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 UAA12387 for ; Sun, 9 Jul 2000 20:59:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixdz11713; Mon, 10 Jul 2000 00:49:38 GMT Received: by mail-control.mail.uu.net id QQixdz09751 for mpls-outgoing; Mon, 10 Jul 2000 00:49: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 QQixdz09746 for ; Mon, 10 Jul 2000 00:48: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 QQixdz03182 for ; Sun, 9 Jul 2000 20:48:49 -0400 (EDT) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQixdz11022 for ; Mon, 10 Jul 2000 00:48:34 GMT Received: from tellium.com (client-151-198-92-132.bellatlantic.net [151.198.92.132] (may be forged)) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e6A0g5u19193; Sun, 9 Jul 2000 20:42:05 -0400 (EDT) Message-ID: <39692BCF.BFCF7296@tellium.com> Date: Sun, 09 Jul 2000 20:50:07 -0500 From: Debanjan Saha Organization: Tellium Optical Systems X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Kireeti Kompella CC: akyol@pluris.com, azinin@cisco.com, EGray@zaffire.com, mpls@UU.NET, swallow@cisco.com Subject: Re: Link Bundling References: <200007090815.BAA26488@kummer.juniper.net> 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 a draft that may be relevant here.. http://www.ietf.org/internet-drafts/draft-rs-optical-bundling-00.txt > 3) How does L2 bundling solve the problem of hundreds of lambdas in a > fiber (or multiple fibers) connecting two LSRs? Regards, Debanjan -- Debanjan Saha Phone: 732-923-4264 Senior Network Architect Fax: 732-923-9804 Tellium Optical Systems http://www.tellium.com From owner-mpls@UU.NET Sun Jul 9 21:30: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 VAA12673 for ; Sun, 9 Jul 2000 21:30:56 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixeb00616; Mon, 10 Jul 2000 01:29:40 GMT Received: by mail-control.mail.uu.net id QQixeb23119 for mpls-outgoing; Mon, 10 Jul 2000 01:29:22 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQixeb23114 for ; Mon, 10 Jul 2000 01:29:13 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixeb21128 for ; Sun, 9 Jul 2000 21:28:54 -0400 (EDT) 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 QQixeb06188 for ; Mon, 10 Jul 2000 01:28:53 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA25063 for mpls@uu.net; Sun, 9 Jul 2000 21:28:52 -0400 (EDT) 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 QQixeb23099 for ; Mon, 10 Jul 2000 01:28: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 QQixeb07217 for ; Sun, 9 Jul 2000 21:28:14 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQixeb29440 for ; Mon, 10 Jul 2000 01:27:58 GMT Received: from sj-dial-2-45.cisco.com (sj-dial-2-45.cisco.com [10.19.226.46]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA25075; Sun, 9 Jul 2000 18:27:14 -0700 (PDT) Date: Sun, 9 Jul 2000 18:22:19 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <10765.000709@cisco.com> To: "Dmitri Krioukov" CC: Subject: Re: mpl(amda)s questions In-reply-To: References: 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 Dmitry, Several points here. Others will add more. 1. The only part in link-state routing protocols that is really using static graph theory is the Dijkstra algorithm. Everything else (topology abstraction, continuous LSDB synchronization, etc.) is really dynamic and, in fact, comes from the theory of distributed algorithms. 2. When we say an LSP should be announced into an IGP, it does not mean it is announced as a native IGP adjacency, but instead it is announced as one of TE attributes. At the extremum of this technique, each announced TE can be augmented with its level. In this case, IGP adjacencies are used to perform level-0 topology abstraction (i.e., abstraction of the physical topology) and announced TE LSPs are used to abstract higher-level topology (topology of the LSPs) so that they can be used to tunnel other, newly established LSPs. 3. As for comparing this method to dynamically calculated link costs, it seems to be very important to me that LSP announcement should not cause immediate recalculation of already established LSPs, while dynamic link costs immediately affect paths of forwarded packets, and thus cause circular feedback dependency (Curtis Vilamizar's OMP addresses this problem). Also, even if already established LSPs are rerouted, proper signaling and resource reservation should prevent LSP bouncing. The main problem with dynamic link costs in current IGPs is that when routers converge on a new SPT, traffic trajectories are changed and so are link load and link costs, so current best paths become not quite best and IGP reroutes again. This causes constant route bouncing. In the case of LSPs, when a new LSP is announced, some LSRs may reroute their already established LSPs through the new pseudo-link. When all resources are allocated, the network will converge on a finite set of LSPs tunneled over the new LSP within some time, other LSPs will stay on their previous paths (LSPs being rerouted should not be torn down until the signaling procedure is complete for the new path). Note, however, that exhaustion of resources of this tunnel LSP should not lead to rerouting of tunneled LSPs, since resource requirements are met for them. In short, I'd say MPLS networks inherit a lot from the VC-oriented network concept and this allows us to avoid some screaming problems we have in datagram networks, if we're careful, of course. -- Alex Zinin Sunday, July 09, 2000, 3:45 PM, Dmitri Krioukov wrote: > in the context of the (augmented) ip over mpl(amda)s > model, advertising lsp/lp state information as link > state information into the igp becomes virtually unavoidable. > doesn't this again pose the question about the fundamental > problem of running routing protocols derived from the static > graph theory (stable, fixed topology) on essentially dynamic > (being dynamically modified by the te control plane) l2 > topologies? what is the fundamental difference between > this approach and having, say, an ls protocol with weights > depending on load (with all its well-known downsides > (oscillations, instability, cpu load, etc.))? > on the other hand, although it's well understood > that *highly* dynamic, data driven lsp setups are > not permitted, some manageable and *relatively* dynamic > (ie, "stable") te control systems are required for te > purposes (like congestion avoidance). any references > to these systems? do they already exist or are they > under research? are any statistical prediction mechanisms > (like markov chains) used here? > thanks, > -- > dima. From owner-mpls@UU.NET Sun Jul 9 22:52: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 WAA15129 for ; Sun, 9 Jul 2000 22:52:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixeh05996; Mon, 10 Jul 2000 02:50:54 GMT Received: by mail-control.mail.uu.net id QQixeh08756 for mpls-outgoing; Mon, 10 Jul 2000 02:50: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 QQixeh08751 for ; Mon, 10 Jul 2000 02:50: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 QQixeh01078 for ; Sun, 9 Jul 2000 22:50:06 -0400 (EDT) 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 QQixeh05412 for ; Mon, 10 Jul 2000 02:49:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA27814 for mpls@uu.net; Sun, 9 Jul 2000 22:49:49 -0400 (EDT) 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 QQixeh08729 for ; Mon, 10 Jul 2000 02:49: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 QQixeh17004 for ; Sun, 9 Jul 2000 22:49:20 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQixeh05134 for ; Mon, 10 Jul 2000 02:49:20 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 TAA18719; Sun, 9 Jul 2000 19:49:16 -0700 (PDT) Message-ID: <39693963.4845187E@pluris.com> Date: Sun, 09 Jul 2000 19:48:03 -0700 From: Bora Akyol X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: azinin@cisco.com, EGray@zaffire.com, mpls@UU.NET, swallow@cisco.com Subject: Re: Link Bundling References: <200007090815.BAA26488@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti Kompella wrote: > Bora, > > > IMHO, bundling at L2 level and representing a single abstraction to L3 protocols > > is a cleaner approach. > > Would you likewise say that MPLS protection is redundant because L2 > protection is "cleaner"? > I fail to see the relation of MPLS protection to L2 bundling. There are quite a few people in this WG and in the community that know my opinions on MPLS protection. > > Let me repeat the primary intent of the bundling document: to reduce > TE state in ISIS/OSPF. Forcing bundling at L2 just to improve TE > scaling seems an overkill. There are other issues: > > 1) L2 "bundling" changes the topology of the network. Those who are > satisfied with their topology for IP but would like better scaling > for MPLS/TE may not want L2 bundling. > Yes, L2 bundling actually simplifies the total topology of the network, as opposed to saving a few CPU cycles here or there for MPLS, ISIS-TE, etc which I think is a major advantage. > 2) Can L2 bundling deal with disparate L1/L2 media? Yes, it can. Really not that difficult if you get the initial abstraction right, which is the reason of my objection to this draft becoming a WG document. It does not get the abstraction of a bundle right and is solving a very small problem instead of addressing the root of the problem: Next gen routers will have lots and lots of interfaces and this coupled with OXCs etc. will cause a lot of links between neighboring routers. Admittedly, this is less of a problem for smaller non-scalable routers. > > 3) How does L2 bundling solve the problem of hundreds of lambdas in a > fiber (or multiple fibers) connecting two LSRs? > Again, I thought this would be kind of obvious, but I guess not. If you get the abstraction of an L2 aggregate right (let us call that a "bond"), then you can support thousands of phsyical ports aggregated to a bond with dynamically varying membership and represented as a single entity to the upper layers. Not only this, but this particular L2 aggregate (BOND) also supports N+K protection with rapid healing. > > > For example, in this draft, even though the links are > > bundled, when you request a label, there is the notion of requesting a label on a > > particular link (essentially unbundling things). > > Again, the intent to reduce ISIS/OSPF TE state. "Unbundling" locally > between two neighbors is perfectly fine, even necessary. > You think it is necessary because of the model that you are using. It really isn't necessary. > > > When ISIS/OSPF run over a > > bundled link, the text mentions the fact that they can indeed run over only a > > single member of the link. But which member? What happens if that particular > > member fails? > > Running ISIS/OSPF over a single member is a small but useful > optimization, and quite orthogonal to the issue of bundling. Is this > the extent of your issues with MPLS/TE bundling? > > [...] > > > My suggestion was not to split the document but to come up with a better > > abstraction than what is presented in this document. We will be submitting an > > internet draft on such an implementation soon (but probably not before the > > deadline for Pittsburgh). > > I'm sure your document is an excellent one. However, having L2 bonding > doesn't preclude having MPLS/TE bundling. You have yet to convince me > that L2 bonding is better than MPLS/TE bundling, and more importantly, > that L2 bonding is even as good as MPLS/TE bundling in the MPL(ambda)S > context. > > Kireeti. Kireeti, I don't have a document, I have an implementation that is well-advanced and works; which I thought was one of the guiding principles of IETF: "Working code." I am not in the document producing business. Again, if your document had gotten the abstraction of an aggregate of multiple links right and then dove into the details of MPLS, I would have had no problems with it. But this is not the case right now, hence my objection. Regards Bora From owner-mpls@UU.NET Sun Jul 9 22:56:21 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15149 for ; Sun, 9 Jul 2000 22:56:21 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixeh07614; Mon, 10 Jul 2000 02:54:59 GMT Received: by mail-control.mail.uu.net id QQixeh09000 for mpls-outgoing; Mon, 10 Jul 2000 02:54: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 QQixeh08993 for ; Mon, 10 Jul 2000 02:54:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixeh01542 for ; Sun, 9 Jul 2000 22:54:13 -0400 (EDT) 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 QQixeh07273 for ; Mon, 10 Jul 2000 02:54:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA28386 for mpls@uu.net; Sun, 9 Jul 2000 22:54:08 -0400 (EDT) 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 QQixeh08971 for ; Mon, 10 Jul 2000 02:53: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 QQixeh17483 for ; Sun, 9 Jul 2000 22:53:23 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQixeh06955 for ; Mon, 10 Jul 2000 02:52:52 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 TAA18749; Sun, 9 Jul 2000 19:52:49 -0700 (PDT) Message-ID: <39693A38.2576E36A@pluris.com> Date: Sun, 09 Jul 2000 19:51:36 -0700 From: Bora Akyol X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: John Drake , mpls@UU.NET Subject: Re: Link Bundling References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit John Can you please point me to this document? I do not see a document listed with this title at www.ietf.org under MPLS WG documents. Thanks Bora John Drake wrote: > Bora, > > A lot of your questions are addressed by Link Management Protocol (LMP), > which is explicitly part of the MPLS working group charter. > > Thanks, > > John > > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: Saturday, July 08, 2000 8:29 AM > To: Alex Zinin > Cc: Eric Gray; George Swallow; mpls@UU.NET > Subject: Re: Link Bundling > > Alex Zinin wrote: > > > Bora, Eric, group. > > > > 1. I think it is not quite appropriate to speak about L2 vs L3 > > link bundling. Approaches can be different, both have their > > pros and cons, but both have a right to live. So, I don't think > > this should be a driving factor. > > IMHO, bundling at L2 level and representing a single abstraction to L3 > protocols > is a cleaner approach. For example, in this draft, even though the links are > bundled, when you request a label, there is the notion of requesting a label > on a > particular link (essentially unbundling things). When ISIS/OSPF run over a > bundled link, the text mentions the fact that they can indeed run over only > a > single member of the link. But which member? What happens if that particular > member fails? These are some of the questions that would be (are) answered > by a > good L2 bundling abstraction. > > > > > 2. Link bundling, in the context it is presented in the document, > > seems to be MPLS-specific to me. > > > > Yes, but there is no reason for it to be MPLS specific. > > > > > 3. MPLS-specific contents vs routing-protocol-specific contents. > > It should be noted that TE attributes introduced to OSPF and ISIS > > are transmitted by respective protocols as opaque data, not > > taken into consideration by the protocol itself (other than > > flooding), so, strictly speaking, as soon as we have specified > > a standard way to carry such data, and this data does not affect > > operations of the protocol itself, changes in the actual data > > being propagated is no more a business of that protocol. > > > > OK. > > > > > I think the document is purely MPLS-specific, covering several > > areas of MPLS-related functions. OSPF & ISIS are used just as transport > > protocols and that makes perfect sense to me. > > I don't see much sense in braking the document into 3 separate > > parts and presenting them at OSPF, ISIS, and RSVP WGs, especially > > taking into consideration that the changes are MPLS-specific... > > > > My suggestion was not to split the document but to come up with a better > abstraction than what is presented in this document. We will be submitting > an > internet draft on such an implementation soon (but probably not before the > deadline for Pittsburgh). > > Regards > > Bora Akyol > > > > > My vote: accept. > > > > -- > > Alex Zinin > > > > Friday, July 07, 2000, 12:23 PM, Bora Akyol wrote: > > > > > Eric > > > > > As I mentioned in my previous email, I would be happy to write an ID > that > > > describes our approach and work with the community to make it an open > > > standard. > > > > > I believe that the bonding of L1 links into one bonded (bundled) L2 link > is > > > something that should be protocol-neutral and should work with all L3 > > > protocols. I believe that such an abstraction is possible and is > actually > > > fairly straightforward to implement and provides a coherent framework > that > > > one can use to ask questions like if protocol X were to run over a > bonded > > > link, how would it run; and then actually answer it in an easy manner. > > > > > Thanks for the comments, > > > > > Bora > > > > > Eric Gray wrote: > > > > >> Bora, > > >> > > >> I essentially agree with the observation that > > >> link bundling is not inherently an MPLS issue and I > > >> also feel that this draft - at least as is - should > > >> not be adopted by the MPLS working group. However, > > >> my reasoning is slightly different than yours. > > >> > > >> While the draft does include a lot of stuff > > >> that is specific to MPLS, it also includes a ton of > > >> IS-IS and OSPF specific stuff as well. My sense is > > >> that it actually has significantly more non-MPLS > > >> related stuff in it than MPLS related stuff. Other > > >> people may disagree but, at the very least, this > > >> work should be done in a forum that is less focused > > >> on label switching and more focused on routing. > > >> > > >> I do not think it is very useful to provide > > >> examples of proprietary approaches to solving the > > >> problem. It takes two to bundle links. But, if > > >> your point is that it may be a good idea to back > > >> away from a link-bundling scheme that is particular > > >> to MPLS LSP based links, I think it is a good point. > > >> > > >> -- > > >> Eric Gray > > >> > > >> > -----Original Message----- > > >> > From: Bora Akyol [mailto:akyol@pluris.com] > > >> > Sent: Friday, July 07, 2000 11:39 AM > > >> > To: George Swallow; mpls@UU.NET > > >> > Subject: Re: Link Bundling > > >> > > > >> > > > >> > George, Yakov, et al., > > >> > > > >> > I do not think that this internet draft should be adopted as an MPLS > > >> > working group document. My primary objection to this document > > >> > is the fact > > >> > that bundling of L1/L2 interfaces has nothing specific to do > > >> > with MPLS. > > >> > In fact, this is an L2 abstraction that should be completely > > >> > transparent > > >> > to MPLS, IP or ISIS. I feel that this particular draft is > > >> > very focused on > > >> > MPLS-specific concerns and does not provide a good > > >> > abstraction of the L2 > > >> > bundling aspects and also places significant restrictions on > > >> > what can be > > >> > done with a bundled link and what kind of members it can have. > > >> > > > >> > I personally know of at least one implementation (ours) of > > >> > bundled links > > >> > that forms such an abstraction to all upper layer protocols. In this > > >> > implementation, a heterogeneous group of L1/L2 interfaces are bonded > > >> > together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP > > >> > treats the > > >> > bundled (bonded) interface as just another type of interface. > > >> > When MPLS > > >> > RSVP messages are passed over the bundled interface, the > > >> > labels that are > > >> > assigned are programmed into all members of the bundled links > > >> > even though > > >> > in reality a hash is used so that only one of the members are used > (to > > >> > prevent reordering). Bandwidth management is handled by means of the > > >> > apriori knowledge of the hash. Also note that this particular > > >> > implementation is not MLPPP since no additional headers are > > >> > added to the > > >> > packets. > > >> > For MPLS specific concerns, the methods that are used in this > approach > > >> > can be expanded. For IP, this particular approach works very well. > > >> > > > >> > If there is interest from the MPLS WG, we (myself and another > > >> > colleague) > > >> > would be perfectly willing to author an Internet Draft on > > >> > this particular > > >> > bond implementation. The question that I have is what is the > > >> > proper forum > > >> > to submit a generalized layer 2 bundling draft in the IETF. It is > > >> > certainly relevant to MPLS, but it is just as relevant to IP, > > >> > ISIS, etc. > > >> > > > >> > Regards > > >> > > > >> > Bora Akyol > > >> > > > >> > > > >> > George Swallow wrote: > > >> > > > >> > > > Folks, > > >> > > > > > >> > > > Kireeti and myself would like to ask the MPLS WG to > > >> > > > accept draft-kompella-mpls-bundle-01.txt as an > > >> > > > MPLS WG document. > > >> > > > > > >> > > > Yakov. > > >> > > > > >> > > Consensus on this will be assessed on 7/12. Opinions > > >> > should be aired > > >> > > by then. > > >> > > > > >> > > ...George > > >> > > > > >> > > ================================================================== > > >> > > George Swallow Cisco Systems (978) 244-8143 > > >> > > 250 Apollo Drive > > >> > > Chelmsford, Ma 01824 > > >> > > > >> > > > >> > From owner-mpls@UU.NET Mon Jul 10 00:03: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 AAA16088 for ; Mon, 10 Jul 2000 00:03:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixel12078; Mon, 10 Jul 2000 03:53:40 GMT Received: by mail-control.mail.uu.net id QQixel23533 for mpls-outgoing; Mon, 10 Jul 2000 03:53: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 QQixel23528 for ; Mon, 10 Jul 2000 03:53: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 QQixel26151 for ; Sun, 9 Jul 2000 23:52:50 -0400 (EDT) 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 QQixel29237 for ; Mon, 10 Jul 2000 03:52:49 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id XAA00745 for mpls@uu.net; Sun, 9 Jul 2000 23:52:49 -0400 (EDT) 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 QQixel23515 for ; Mon, 10 Jul 2000 03:52:28 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 QQixel26106 for ; Sun, 9 Jul 2000 23:52:17 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQixel29050 for ; Mon, 10 Jul 2000 03:51:57 GMT Received: from sj-dial-1-200.cisco.com (sj-dial-1-200.cisco.com [171.68.179.201]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA02669; Sun, 9 Jul 2000 20:51:22 -0700 (PDT) Date: Sun, 9 Jul 2000 20:46:27 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <12865.000709@cisco.com> To: Bora Akyol CC: Kireeti Kompella , EGray@zaffire.com, mpls@UU.NET, swallow@cisco.com Subject: Re: Link Bundling In-reply-To: <39693963.4845187E@pluris.com> References: <39693963.4845187E@pluris.com> 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 Bora, I still think *both* approaches are feasible. We have seen both of them used in traditional IP networks. L3 bundling seems to be attractive to me exactly because it does not require a special L2 protocol on the component links, which is really good from the customer and deployment perspective. From the implementation perspective, it may also be simpler to introduce a change in the topo abstraction logic of a network control layer protocol, rather then trying to completely solve the problem at the link-control layer. I'm not saying, however, that L2 bundling should never be used. With that being said, I personally think it makes sense to accept the document as a WG item. If you think your approach is better and the industry should use it, why don't you document it in a draft (as a separate effort or as an extension to LMP) and then ask for the feedback. This does not mean, however, that other approaches will not be used. Different opinions can co-exist and this is absolutely fine. -- Alex Zinin Sunday, July 09, 2000, 7:48 PM, Bora Akyol wrote: > Kireeti Kompella wrote: >> Bora, >> >> > IMHO, bundling at L2 level and representing a single abstraction to L3 protocols >> > is a cleaner approach. >> >> Would you likewise say that MPLS protection is redundant because L2 >> protection is "cleaner"? >> > I fail to see the relation of MPLS protection to L2 bundling. There are quite a few > people in this WG and in the community that know my opinions on MPLS protection. >> >> Let me repeat the primary intent of the bundling document: to reduce >> TE state in ISIS/OSPF. Forcing bundling at L2 just to improve TE >> scaling seems an overkill. There are other issues: >> >> 1) L2 "bundling" changes the topology of the network. Those who are >> satisfied with their topology for IP but would like better scaling >> for MPLS/TE may not want L2 bundling. >> > Yes, L2 bundling actually simplifies the total topology of the network, as opposed to > saving a few CPU cycles here or there for MPLS, ISIS-TE, etc which I think is a major > advantage. >> 2) Can L2 bundling deal with disparate L1/L2 media? > Yes, it can. Really not that difficult if you get the initial abstraction right, which > is the reason of my objection to this draft becoming a WG document. It does not get the > abstraction of a bundle right and is solving a very small problem instead of addressing > the root of the problem: Next gen routers will have lots and lots of interfaces and > this coupled with OXCs etc. will cause a lot of links between neighboring routers. > Admittedly, this is less of a problem for smaller non-scalable routers. >> >> 3) How does L2 bundling solve the problem of hundreds of lambdas in a >> fiber (or multiple fibers) connecting two LSRs? >> > Again, I thought this would be kind of obvious, but I guess not. If you get the > abstraction of an L2 aggregate right (let us call that a "bond"), then you can support > thousands of phsyical ports aggregated to a bond with dynamically varying membership > and represented as a single entity to the upper layers. Not only this, but this > particular L2 aggregate (BOND) also supports N+K protection with rapid healing. >> >> > For example, in this draft, even though the links are >> > bundled, when you request a label, there is the notion of requesting a label on a >> > particular link (essentially unbundling things). >> >> Again, the intent to reduce ISIS/OSPF TE state. "Unbundling" locally >> between two neighbors is perfectly fine, even necessary. >> > You think it is necessary because of the model that you are using. It really isn't > necessary. >> >> > When ISIS/OSPF run over a >> > bundled link, the text mentions the fact that they can indeed run over only a >> > single member of the link. But which member? What happens if that particular >> > member fails? >> >> Running ISIS/OSPF over a single member is a small but useful >> optimization, and quite orthogonal to the issue of bundling. Is this >> the extent of your issues with MPLS/TE bundling? >> >> [...] >> >> > My suggestion was not to split the document but to come up with a better >> > abstraction than what is presented in this document. We will be submitting an >> > internet draft on such an implementation soon (but probably not before the >> > deadline for Pittsburgh). >> >> I'm sure your document is an excellent one. However, having L2 bonding >> doesn't preclude having MPLS/TE bundling. You have yet to convince me >> that L2 bonding is better than MPLS/TE bundling, and more importantly, >> that L2 bonding is even as good as MPLS/TE bundling in the MPL(ambda)S >> context. >> >> Kireeti. > Kireeti, > I don't have a document, I have an implementation that is well-advanced and works; > which I thought was one of the guiding principles of IETF: "Working code." I am not in > the document producing business. > Again, if your document had gotten the abstraction of an aggregate of multiple links > right and then dove into the details of MPLS, I would have had no problems with it. But > this is not the case right now, hence my objection. > Regards > Bora From owner-mpls@UU.NET Mon Jul 10 00:20: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 AAA16141 for ; Mon, 10 Jul 2000 00:20:09 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixem05314; Mon, 10 Jul 2000 04:09:33 GMT Received: by mail-control.mail.uu.net id QQixem05471 for mpls-outgoing; Mon, 10 Jul 2000 04:08: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 QQixem05466 for ; Mon, 10 Jul 2000 04:08: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 QQixem11819 for ; Mon, 10 Jul 2000 00:08:44 -0400 (EDT) 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 QQixem04867 for ; Mon, 10 Jul 2000 04:08:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA01813 for mpls@uu.net; Mon, 10 Jul 2000 00:08:43 -0400 (EDT) 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 QQixem05457 for ; Mon, 10 Jul 2000 04:08: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 QQixem28129 for ; Mon, 10 Jul 2000 00:08:16 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQixem04521 for ; Mon, 10 Jul 2000 04:08:00 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 VAA19236; Sun, 9 Jul 2000 21:07:57 -0700 (PDT) Message-ID: <39694BD1.1C74E9EE@pluris.com> Date: Sun, 09 Jul 2000 21:06:41 -0700 From: Bora Akyol X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: Kireeti Kompella , EGray@zaffire.com, mpls@UU.NET, swallow@cisco.com Subject: Re: Link Bundling References: <39693963.4845187E@pluris.com> <12865.000709@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Alex Just to make sure that I did not misrepresent the approach I was advocating, I am going to go into more details here: In this approach, a group of heterogeneous links are bundled such that, to L3 protocols and above this group of links appears as a single "interface" This in nature is similar to 802.3ad link aggregation but is a superset of that since it works with POS interfaces as well. Such an approach also reduces routing protocol processing load, and also simplifies link management as well. Thanks for your comments, I have just downloaded the LMP document and will review it tomorrow and see if it covers relevant aspects of bonding. Bora Alex Zinin wrote: > Bora, > > I still think *both* approaches are feasible. > We have seen both of them used in traditional IP networks. > > L3 bundling seems to be attractive to me exactly because > it does not require a special L2 protocol on the component > links, which is really good from the customer and deployment > perspective. From the implementation perspective, it may also > be simpler to introduce a change in the topo abstraction logic > of a network control layer protocol, rather then trying to > completely solve the problem at the link-control layer. > I'm not saying, however, that L2 bundling should never be > used. > > With that being said, I personally think it makes sense > to accept the document as a WG item. If you think your approach > is better and the industry should use it, why don't you document > it in a draft (as a separate effort or as an extension to LMP) > and then ask for the feedback. This does not mean, however, that > other approaches will not be used. Different opinions can > co-exist and this is absolutely fine. > > -- > Alex Zinin > > Sunday, July 09, 2000, 7:48 PM, Bora Akyol wrote: > > > Kireeti Kompella wrote: > > >> Bora, > >> > >> > IMHO, bundling at L2 level and representing a single abstraction to L3 protocols > >> > is a cleaner approach. > >> > >> Would you likewise say that MPLS protection is redundant because L2 > >> protection is "cleaner"? > >> > > > I fail to see the relation of MPLS protection to L2 bundling. There are quite a few > > people in this WG and in the community that know my opinions on MPLS protection. > > >> > >> Let me repeat the primary intent of the bundling document: to reduce > >> TE state in ISIS/OSPF. Forcing bundling at L2 just to improve TE > >> scaling seems an overkill. There are other issues: > >> > >> 1) L2 "bundling" changes the topology of the network. Those who are > >> satisfied with their topology for IP but would like better scaling > >> for MPLS/TE may not want L2 bundling. > >> > > > Yes, L2 bundling actually simplifies the total topology of the network, as opposed to > > saving a few CPU cycles here or there for MPLS, ISIS-TE, etc which I think is a major > > advantage. > > >> 2) Can L2 bundling deal with disparate L1/L2 media? > > > Yes, it can. Really not that difficult if you get the initial abstraction right, which > > is the reason of my objection to this draft becoming a WG document. It does not get the > > abstraction of a bundle right and is solving a very small problem instead of addressing > > the root of the problem: Next gen routers will have lots and lots of interfaces and > > this coupled with OXCs etc. will cause a lot of links between neighboring routers. > > Admittedly, this is less of a problem for smaller non-scalable routers. > > >> > >> 3) How does L2 bundling solve the problem of hundreds of lambdas in a > >> fiber (or multiple fibers) connecting two LSRs? > >> > > > Again, I thought this would be kind of obvious, but I guess not. If you get the > > abstraction of an L2 aggregate right (let us call that a "bond"), then you can support > > thousands of phsyical ports aggregated to a bond with dynamically varying membership > > and represented as a single entity to the upper layers. Not only this, but this > > particular L2 aggregate (BOND) also supports N+K protection with rapid healing. > > >> > >> > For example, in this draft, even though the links are > >> > bundled, when you request a label, there is the notion of requesting a label on a > >> > particular link (essentially unbundling things). > >> > >> Again, the intent to reduce ISIS/OSPF TE state. "Unbundling" locally > >> between two neighbors is perfectly fine, even necessary. > >> > > > You think it is necessary because of the model that you are using. It really isn't > > necessary. > > >> > >> > When ISIS/OSPF run over a > >> > bundled link, the text mentions the fact that they can indeed run over only a > >> > single member of the link. But which member? What happens if that particular > >> > member fails? > >> > >> Running ISIS/OSPF over a single member is a small but useful > >> optimization, and quite orthogonal to the issue of bundling. Is this > >> the extent of your issues with MPLS/TE bundling? > >> > >> [...] > >> > >> > My suggestion was not to split the document but to come up with a better > >> > abstraction than what is presented in this document. We will be submitting an > >> > internet draft on such an implementation soon (but probably not before the > >> > deadline for Pittsburgh). > >> > >> I'm sure your document is an excellent one. However, having L2 bonding > >> doesn't preclude having MPLS/TE bundling. You have yet to convince me > >> that L2 bonding is better than MPLS/TE bundling, and more importantly, > >> that L2 bonding is even as good as MPLS/TE bundling in the MPL(ambda)S > >> context. > >> > >> Kireeti. > > > Kireeti, > > > I don't have a document, I have an implementation that is well-advanced and works; > > which I thought was one of the guiding principles of IETF: "Working code." I am not in > > the document producing business. > > > Again, if your document had gotten the abstraction of an aggregate of multiple links > > right and then dove into the details of MPLS, I would have had no problems with it. But > > this is not the case right now, hence my objection. > > > Regards > > > Bora From owner-mpls@UU.NET Mon Jul 10 01:27: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 BAA19946 for ; Mon, 10 Jul 2000 01:27:57 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixer01592; Mon, 10 Jul 2000 05:18:11 GMT Received: by mail-control.mail.uu.net id QQixer20302 for mpls-outgoing; Mon, 10 Jul 2000 05:17: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 QQixer20293 for ; Mon, 10 Jul 2000 05:17: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 QQixer21199 for ; Mon, 10 Jul 2000 01:17:45 -0400 (EDT) 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 QQixer01102 for ; Mon, 10 Jul 2000 05:17:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA07402 for mpls@uu.net; Mon, 10 Jul 2000 01:17:14 -0400 (EDT) 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 QQixer20268 for ; Mon, 10 Jul 2000 05:16: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 QQixer07581 for ; Mon, 10 Jul 2000 01:16:28 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQixer00831 for ; Mon, 10 Jul 2000 05:16:12 GMT Received: from sj-dial-2-45.cisco.com (sj-dial-2-45.cisco.com [10.19.226.46]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA23757; Sun, 9 Jul 2000 22:15:35 -0700 (PDT) Date: Sun, 9 Jul 2000 22:10:40 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <1924.000709@cisco.com> To: Rajiv Papneja CC: juan diego otero , mpls@UU.NET Subject: Re: MPLS TE and Constraint Based Routing In-reply-To: References: 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 Rajiv, [...] > You can probably use off-line tools for path computation but sometimes > the off-line tools do not scale well with the network size Can you elaborate on the scaling comment a bit? Regards, Alex. > and are not > much responsive to the network states. > Take care > Rajiv > On Mon, 3 Jul 2000, juan diego otero wrote: >> Hi, >> >> I would like to know who does the constraint >> based routing (CBR) when we do TE in an MPLS domain. >> I mean, is there a special CBR module in every router? >> or is there a server that computes a kind of >> "off-line" CBR? Are there any available commercial >> solution? >> >> Thanks a lot. >> >> Diego Otero. >> >> >> __________________________________________________ >> Do You Yahoo!? >> Kick off your party with Yahoo! Invites. >> http://invites.yahoo.com/ >> >> > ******************************** > Rajiv Papneja (GRA) > Advanced Internet Laboratory > George Mason University > Tel: 703.993.4700 > email: rpapneja@osf1.gmu.edu > ******************************** From owner-mpls@UU.NET Mon Jul 10 02:08: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 CAA29254 for ; Mon, 10 Jul 2000 02:08:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixeu17348; Mon, 10 Jul 2000 06:06:43 GMT Received: by mail-control.mail.uu.net id QQixeu03808 for mpls-outgoing; Mon, 10 Jul 2000 06:06: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 QQixeu03704 for ; Mon, 10 Jul 2000 06:05: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 QQixeu26588 for ; Mon, 10 Jul 2000 02:05:30 -0400 (EDT) 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 QQixeu18174 for ; Mon, 10 Jul 2000 06:05:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA09297 for mpls@uu.net; Mon, 10 Jul 2000 02:05:14 -0400 (EDT) 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 QQixeu03619 for ; Mon, 10 Jul 2000 06:04: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 QQixeu12912 for ; Mon, 10 Jul 2000 02:04:20 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQixeu17716 for ; Mon, 10 Jul 2000 06:03:50 GMT Received: from sj-dial-2-45.cisco.com (sj-dial-2-45.cisco.com [10.19.226.46]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA05839 for ; Sun, 9 Jul 2000 23:03:43 -0700 (PDT) Date: Sun, 9 Jul 2000 22:58:48 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <1957.000709@cisco.com> To: Subject: draft-ietf-mpls-te-feed-00.txt 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 Peter, et al. In your draft you recommend to change the contents of IGP's LSDB whenever the feedback from the signaling component is received. I'm afraid it is not quite good. 1. If the checksum of the LSA/LSP is not recalculated after the contents were changed, the IGP may report a fatal error if the checksum is verified before the next version of the LSA/LSP arrives. 2. Recalculating the checksum is also wrong, because: a) only the originating router must do this b) if this is done by other routers it may affect LSA/LSP version comparison algo. Because of the above and because it is a 'bad thing' to modify link-state PDUs originated by others, I think it is safer and makes some more sense to say that implementations must account for a method to link the information provided by the signaling component to the corresponding elements of the TE database, instead of overwriting it. Cheers, -- Alex Zinin From owner-mpls@UU.NET Mon Jul 10 03:28:58 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00023 for ; Mon, 10 Jul 2000 03:28:58 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixez23297; Mon, 10 Jul 2000 07:19:06 GMT Received: by mail-control.mail.uu.net id QQixez18957 for mpls-outgoing; Mon, 10 Jul 2000 07:18: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 QQixez18952 for ; Mon, 10 Jul 2000 07:18:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixez23626 for ; Mon, 10 Jul 2000 03:18:31 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQixez22872 for ; Mon, 10 Jul 2000 07:18:30 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id DAA11768 for mpls@uu.net; Mon, 10 Jul 2000 03:18:29 -0400 (EDT) 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 QQixez18935 for ; Mon, 10 Jul 2000 07:18: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 QQixez23568 for ; Mon, 10 Jul 2000 03:17:57 -0400 (EDT) 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 QQixez22618 for ; Mon, 10 Jul 2000 07:17:57 GMT Received: from brussels.cisco.com (brussels.cisco.com [144.254.15.68]) by ogma.cisco.com (Postfix) with ESMTP id 1E83DCE for ; Mon, 10 Jul 2000 09:17:57 +0200 (MET DST) Received: from bdewonck-8kcdt.cisco.com (bdewonck-isdn-home.cisco.com [10.49.5.22]) by brussels.cisco.com (8.8.8+Sun/8.8.8) with SMTP id JAA25000 for ; Mon, 10 Jul 2000 09:17:56 +0200 (MET DST) Message-Id: <200007100717.JAA25000@brussels.cisco.com> X-Sender: bdewonck@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 10 Jul 2000 09:20:41 +0100 To: mpls@UU.NET From: Benoit Dewonck Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk unsubscribe __________________________________________ Benoit Dewonck SE Team Leader Small and Medium Business Cisco Systems Belgium Tel ++ 32 2 778 42 91 Fax ++ 32 2 778 46 89 __________________________________________ C I S C O S Y S T E M S EMPOWERING THE INTERNET GENERATION Changing The Way We Work, Live, Play & Learn Cisco Connection Online http://www.cisco.com/be From owner-mpls@UU.NET Mon Jul 10 06:37: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 GAA02461 for ; Mon, 10 Jul 2000 06:37:12 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixfm22503; Mon, 10 Jul 2000 10:35:01 GMT Received: by mail-control.mail.uu.net id QQixfm03190 for mpls-outgoing; Mon, 10 Jul 2000 10:34:26 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQixfm03181 for ; Mon, 10 Jul 2000 10:34: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 QQixfm17523 for ; Mon, 10 Jul 2000 06:34:15 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQixfm27051 for ; Mon, 10 Jul 2000 10:34:14 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA18062 for mpls@uu.net; Mon, 10 Jul 2000 06:34:10 -0400 (EDT) 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 QQixfm03161 for ; Mon, 10 Jul 2000 10:33: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 QQixfm17496 for ; Mon, 10 Jul 2000 06:33:21 -0400 (EDT) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQixfm26714 for ; Mon, 10 Jul 2000 10:33:21 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02233; Mon, 10 Jul 2000 06:33:20 -0400 (EDT) Message-Id: <200007101033.GAA02233@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-crldp-applic-01.txt Date: Mon, 10 Jul 2000 06:33:20 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Applicability Statement for CR-LDP Author(s) : J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright Filename : draft-ietf-mpls-crldp-applic-01.txt Pages : 6 Date : 07-Jul-00 This Internet-Draft discusses the applicability of Constraint-Based LSP Setup using LDP [1]. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) [2] required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-crldp-applic-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-crldp-applic-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-crldp-applic-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000707143821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-crldp-applic-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-crldp-applic-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000707143821.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jul 10 06:37: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 GAA02478 for ; Mon, 10 Jul 2000 06:37:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixfm27504; Mon, 10 Jul 2000 10:35:05 GMT Received: by mail-control.mail.uu.net id QQixfm03195 for mpls-outgoing; Mon, 10 Jul 2000 10:34: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 QQixfm03182 for ; Mon, 10 Jul 2000 10:34: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 QQixfm17521 for ; Mon, 10 Jul 2000 06:34:12 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQixfm27018 for ; Mon, 10 Jul 2000 10:34:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA18063 for mpls@uu.net; Mon, 10 Jul 2000 06:34:10 -0400 (EDT) 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 QQixfm03159 for ; Mon, 10 Jul 2000 10:33: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 QQixfm00168 for ; Mon, 10 Jul 2000 06:33:27 -0400 (EDT) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQixfm26766 for ; Mon, 10 Jul 2000 10:33:26 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02258; Mon, 10 Jul 2000 06:33:26 -0400 (EDT) Message-Id: <200007101033.GAA02258@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-cr-ldp-04.txt Date: Mon, 10 Jul 2000 06:33:25 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Constraint-Based LSP Setup using LDP Author(s) : B. Jamoussi Filename : draft-ietf-mpls-cr-ldp-04.txt Pages : 38 Date : 07-Jul-00 Label Distribution Protocol (LDP) is defined in [1] for distribution of labels inside one MPLS domain. One of the most important services that may be offered using MPLS in general and LDP in particular is support for constraint-based routing of traffic across the routed network. Constraint-based routing offers the opportunity to extend the information used to setup paths beyond what is available for the routing protocol. For instance, an LSP can be setup based on explicit route constraints, QoS constraints, and other constraints. Constraint-based routing (CR) is a mechanism used to meet Traffic Engineering requirements that have been proposed by [2], [3] and [4]. These requirements may be met by extending LDP for support of constraint-based routed label switched paths (CR-LSPs). Other uses for CR-LSPs include MPLS-based VPNs [5]. More information about the applicability of CR-LDP can be found in [6]. This draft specifies mechanisms and TLVs for support of CR-LSPs using LDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-cr-ldp-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-cr-ldp-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-cr-ldp-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: <20000707143834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-cr-ldp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-cr-ldp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000707143834.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jul 10 08:40:13 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06398 for ; Mon, 10 Jul 2000 08:40:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixfu27067; Mon, 10 Jul 2000 12:37:57 GMT Received: by mail-control.mail.uu.net id QQixfu02782 for mpls-outgoing; Mon, 10 Jul 2000 12:37:22 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 QQixfu02670 for ; Mon, 10 Jul 2000 12:37:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixfu02511 for ; Mon, 10 Jul 2000 08:36:54 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQixfu26402 for ; Mon, 10 Jul 2000 12:36:53 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id FAA22817 for ; Mon, 10 Jul 2000 05:37:05 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA13044 for mpls@uu.net; Mon, 10 Jul 2000 08:36:51 -0400 (EDT) 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 QQixdj12949 for ; Sun, 9 Jul 2000 20:58:40 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 QQixdj19787 for ; Sun, 9 Jul 2000 16:58:24 -0400 (EDT) Received: from lumen.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.55.200]) id QQixdj23652 for ; Sun, 9 Jul 2000 20:58:24 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2448.0) id <33V044V7>; Sun, 9 Jul 2000 13:58:23 -0700 Message-ID: From: John Drake To: Alex Zinin , Bora Akyol Cc: Eric Gray , George Swallow , mpls@UU.NET Subject: RE: Link Bundling Date: Sun, 9 Jul 2000 13:58:15 -0700 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 This note saves me some typing. I think it makes perfect sense. John -----Original Message----- From: Alex Zinin [mailto:azinin@cisco.com] Sent: Saturday, July 08, 2000 1:04 AM To: Bora Akyol Cc: Eric Gray; George Swallow; mpls@UU.NET Subject: Re: Link Bundling Bora, Eric, group. 1. I think it is not quite appropriate to speak about L2 vs L3 link bundling. Approaches can be different, both have their pros and cons, but both have a right to live. So, I don't think this should be a driving factor. 2. Link bundling, in the context it is presented in the document, seems to be MPLS-specific to me. 3. MPLS-specific contents vs routing-protocol-specific contents. It should be noted that TE attributes introduced to OSPF and ISIS are transmitted by respective protocols as opaque data, not taken into consideration by the protocol itself (other than flooding), so, strictly speaking, as soon as we have specified a standard way to carry such data, and this data does not affect operations of the protocol itself, changes in the actual data being propagated is no more a business of that protocol. I think the document is purely MPLS-specific, covering several areas of MPLS-related functions. OSPF & ISIS are used just as transport protocols and that makes perfect sense to me. I don't see much sense in braking the document into 3 separate parts and presenting them at OSPF, ISIS, and RSVP WGs, especially taking into consideration that the changes are MPLS-specific... My vote: accept. -- Alex Zinin Friday, July 07, 2000, 12:23 PM, Bora Akyol wrote: > Eric > As I mentioned in my previous email, I would be happy to write an ID that > describes our approach and work with the community to make it an open > standard. > I believe that the bonding of L1 links into one bonded (bundled) L2 link is > something that should be protocol-neutral and should work with all L3 > protocols. I believe that such an abstraction is possible and is actually > fairly straightforward to implement and provides a coherent framework that > one can use to ask questions like if protocol X were to run over a bonded > link, how would it run; and then actually answer it in an easy manner. > Thanks for the comments, > Bora > Eric Gray wrote: >> Bora, >> >> I essentially agree with the observation that >> link bundling is not inherently an MPLS issue and I >> also feel that this draft - at least as is - should >> not be adopted by the MPLS working group. However, >> my reasoning is slightly different than yours. >> >> While the draft does include a lot of stuff >> that is specific to MPLS, it also includes a ton of >> IS-IS and OSPF specific stuff as well. My sense is >> that it actually has significantly more non-MPLS >> related stuff in it than MPLS related stuff. Other >> people may disagree but, at the very least, this >> work should be done in a forum that is less focused >> on label switching and more focused on routing. >> >> I do not think it is very useful to provide >> examples of proprietary approaches to solving the >> problem. It takes two to bundle links. But, if >> your point is that it may be a good idea to back >> away from a link-bundling scheme that is particular >> to MPLS LSP based links, I think it is a good point. >> >> -- >> Eric Gray >> >> > -----Original Message----- >> > From: Bora Akyol [mailto:akyol@pluris.com] >> > Sent: Friday, July 07, 2000 11:39 AM >> > To: George Swallow; mpls@UU.NET >> > Subject: Re: Link Bundling >> > >> > >> > George, Yakov, et al., >> > >> > I do not think that this internet draft should be adopted as an MPLS >> > working group document. My primary objection to this document >> > is the fact >> > that bundling of L1/L2 interfaces has nothing specific to do >> > with MPLS. >> > In fact, this is an L2 abstraction that should be completely >> > transparent >> > to MPLS, IP or ISIS. I feel that this particular draft is >> > very focused on >> > MPLS-specific concerns and does not provide a good >> > abstraction of the L2 >> > bundling aspects and also places significant restrictions on >> > what can be >> > done with a bundled link and what kind of members it can have. >> > >> > I personally know of at least one implementation (ours) of >> > bundled links >> > that forms such an abstraction to all upper layer protocols. In this >> > implementation, a heterogeneous group of L1/L2 interfaces are bonded >> > together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP >> > treats the >> > bundled (bonded) interface as just another type of interface. >> > When MPLS >> > RSVP messages are passed over the bundled interface, the >> > labels that are >> > assigned are programmed into all members of the bundled links >> > even though >> > in reality a hash is used so that only one of the members are used (to >> > prevent reordering). Bandwidth management is handled by means of the >> > apriori knowledge of the hash. Also note that this particular >> > implementation is not MLPPP since no additional headers are >> > added to the >> > packets. >> > For MPLS specific concerns, the methods that are used in this approach >> > can be expanded. For IP, this particular approach works very well. >> > >> > If there is interest from the MPLS WG, we (myself and another >> > colleague) >> > would be perfectly willing to author an Internet Draft on >> > this particular >> > bond implementation. The question that I have is what is the >> > proper forum >> > to submit a generalized layer 2 bundling draft in the IETF. It is >> > certainly relevant to MPLS, but it is just as relevant to IP, >> > ISIS, etc. >> > >> > Regards >> > >> > Bora Akyol >> > >> > >> > George Swallow wrote: >> > >> > > > Folks, >> > > > >> > > > Kireeti and myself would like to ask the MPLS WG to >> > > > accept draft-kompella-mpls-bundle-01.txt as an >> > > > MPLS WG document. >> > > > >> > > > Yakov. >> > > >> > > Consensus on this will be assessed on 7/12. Opinions >> > should be aired >> > > by then. >> > > >> > > ...George >> > > >> > > ================================================================== >> > > George Swallow Cisco Systems (978) 244-8143 >> > > 250 Apollo Drive >> > > Chelmsford, Ma 01824 >> > >> > >> > From owner-mpls@UU.NET Mon Jul 10 08:41: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 IAA06424 for ; Mon, 10 Jul 2000 08:41:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixfu09047; Mon, 10 Jul 2000 12:38:56 GMT Received: by mail-control.mail.uu.net id QQixfu02942 for mpls-outgoing; Mon, 10 Jul 2000 12:38: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 QQixfu02924 for ; Mon, 10 Jul 2000 12:38: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 QQixfu02694 for ; Mon, 10 Jul 2000 08:37:54 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQixfu08356 for ; Mon, 10 Jul 2000 12:37:38 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA27946 for ; Mon, 10 Jul 2000 05:37:51 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA13054 for mpls@uu.net; Mon, 10 Jul 2000 08:37:36 -0400 (EDT) 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 QQixdj12951 for ; Sun, 9 Jul 2000 20:58:42 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixdj05343 for ; Sun, 9 Jul 2000 16:58:25 -0400 (EDT) Received: from lumen.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.55.200]) id QQixdj23665 for ; Sun, 9 Jul 2000 20:58:24 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2448.0) id <33V044V8>; Sun, 9 Jul 2000 13:58:23 -0700 Message-ID: From: John Drake To: Bora Akyol , Alex Zinin Cc: Eric Gray , George Swallow , mpls@UU.NET Subject: RE: Link Bundling Date: Sun, 9 Jul 2000 13:58:20 -0700 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 Bora, A lot of your questions are addressed by Link Management Protocol (LMP), which is explicitly part of the MPLS working group charter. Thanks, John -----Original Message----- From: Bora Akyol [mailto:akyol@pluris.com] Sent: Saturday, July 08, 2000 8:29 AM To: Alex Zinin Cc: Eric Gray; George Swallow; mpls@UU.NET Subject: Re: Link Bundling Alex Zinin wrote: > Bora, Eric, group. > > 1. I think it is not quite appropriate to speak about L2 vs L3 > link bundling. Approaches can be different, both have their > pros and cons, but both have a right to live. So, I don't think > this should be a driving factor. IMHO, bundling at L2 level and representing a single abstraction to L3 protocols is a cleaner approach. For example, in this draft, even though the links are bundled, when you request a label, there is the notion of requesting a label on a particular link (essentially unbundling things). When ISIS/OSPF run over a bundled link, the text mentions the fact that they can indeed run over only a single member of the link. But which member? What happens if that particular member fails? These are some of the questions that would be (are) answered by a good L2 bundling abstraction. > > 2. Link bundling, in the context it is presented in the document, > seems to be MPLS-specific to me. > Yes, but there is no reason for it to be MPLS specific. > > 3. MPLS-specific contents vs routing-protocol-specific contents. > It should be noted that TE attributes introduced to OSPF and ISIS > are transmitted by respective protocols as opaque data, not > taken into consideration by the protocol itself (other than > flooding), so, strictly speaking, as soon as we have specified > a standard way to carry such data, and this data does not affect > operations of the protocol itself, changes in the actual data > being propagated is no more a business of that protocol. > OK. > > I think the document is purely MPLS-specific, covering several > areas of MPLS-related functions. OSPF & ISIS are used just as transport > protocols and that makes perfect sense to me. > I don't see much sense in braking the document into 3 separate > parts and presenting them at OSPF, ISIS, and RSVP WGs, especially > taking into consideration that the changes are MPLS-specific... > My suggestion was not to split the document but to come up with a better abstraction than what is presented in this document. We will be submitting an internet draft on such an implementation soon (but probably not before the deadline for Pittsburgh). Regards Bora Akyol > > My vote: accept. > > -- > Alex Zinin > > Friday, July 07, 2000, 12:23 PM, Bora Akyol wrote: > > > Eric > > > As I mentioned in my previous email, I would be happy to write an ID that > > describes our approach and work with the community to make it an open > > standard. > > > I believe that the bonding of L1 links into one bonded (bundled) L2 link is > > something that should be protocol-neutral and should work with all L3 > > protocols. I believe that such an abstraction is possible and is actually > > fairly straightforward to implement and provides a coherent framework that > > one can use to ask questions like if protocol X were to run over a bonded > > link, how would it run; and then actually answer it in an easy manner. > > > Thanks for the comments, > > > Bora > > > Eric Gray wrote: > > >> Bora, > >> > >> I essentially agree with the observation that > >> link bundling is not inherently an MPLS issue and I > >> also feel that this draft - at least as is - should > >> not be adopted by the MPLS working group. However, > >> my reasoning is slightly different than yours. > >> > >> While the draft does include a lot of stuff > >> that is specific to MPLS, it also includes a ton of > >> IS-IS and OSPF specific stuff as well. My sense is > >> that it actually has significantly more non-MPLS > >> related stuff in it than MPLS related stuff. Other > >> people may disagree but, at the very least, this > >> work should be done in a forum that is less focused > >> on label switching and more focused on routing. > >> > >> I do not think it is very useful to provide > >> examples of proprietary approaches to solving the > >> problem. It takes two to bundle links. But, if > >> your point is that it may be a good idea to back > >> away from a link-bundling scheme that is particular > >> to MPLS LSP based links, I think it is a good point. > >> > >> -- > >> Eric Gray > >> > >> > -----Original Message----- > >> > From: Bora Akyol [mailto:akyol@pluris.com] > >> > Sent: Friday, July 07, 2000 11:39 AM > >> > To: George Swallow; mpls@UU.NET > >> > Subject: Re: Link Bundling > >> > > >> > > >> > George, Yakov, et al., > >> > > >> > I do not think that this internet draft should be adopted as an MPLS > >> > working group document. My primary objection to this document > >> > is the fact > >> > that bundling of L1/L2 interfaces has nothing specific to do > >> > with MPLS. > >> > In fact, this is an L2 abstraction that should be completely > >> > transparent > >> > to MPLS, IP or ISIS. I feel that this particular draft is > >> > very focused on > >> > MPLS-specific concerns and does not provide a good > >> > abstraction of the L2 > >> > bundling aspects and also places significant restrictions on > >> > what can be > >> > done with a bundled link and what kind of members it can have. > >> > > >> > I personally know of at least one implementation (ours) of > >> > bundled links > >> > that forms such an abstraction to all upper layer protocols. In this > >> > implementation, a heterogeneous group of L1/L2 interfaces are bonded > >> > together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP > >> > treats the > >> > bundled (bonded) interface as just another type of interface. > >> > When MPLS > >> > RSVP messages are passed over the bundled interface, the > >> > labels that are > >> > assigned are programmed into all members of the bundled links > >> > even though > >> > in reality a hash is used so that only one of the members are used (to > >> > prevent reordering). Bandwidth management is handled by means of the > >> > apriori knowledge of the hash. Also note that this particular > >> > implementation is not MLPPP since no additional headers are > >> > added to the > >> > packets. > >> > For MPLS specific concerns, the methods that are used in this approach > >> > can be expanded. For IP, this particular approach works very well. > >> > > >> > If there is interest from the MPLS WG, we (myself and another > >> > colleague) > >> > would be perfectly willing to author an Internet Draft on > >> > this particular > >> > bond implementation. The question that I have is what is the > >> > proper forum > >> > to submit a generalized layer 2 bundling draft in the IETF. It is > >> > certainly relevant to MPLS, but it is just as relevant to IP, > >> > ISIS, etc. > >> > > >> > Regards > >> > > >> > Bora Akyol > >> > > >> > > >> > George Swallow wrote: > >> > > >> > > > Folks, > >> > > > > >> > > > Kireeti and myself would like to ask the MPLS WG to > >> > > > accept draft-kompella-mpls-bundle-01.txt as an > >> > > > MPLS WG document. > >> > > > > >> > > > Yakov. > >> > > > >> > > Consensus on this will be assessed on 7/12. Opinions > >> > should be aired > >> > > by then. > >> > > > >> > > ...George > >> > > > >> > > ================================================================== > >> > > George Swallow Cisco Systems (978) 244-8143 > >> > > 250 Apollo Drive > >> > > Chelmsford, Ma 01824 > >> > > >> > > >> > From owner-mpls@UU.NET Mon Jul 10 08:53: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 IAA06851 for ; Mon, 10 Jul 2000 08:53:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixfu27792; Mon, 10 Jul 2000 12:38:35 GMT Received: by mail-control.mail.uu.net id QQixfu02939 for mpls-outgoing; Mon, 10 Jul 2000 12:38:18 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQixfu02923 for ; Mon, 10 Jul 2000 12:38: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 QQixfu02730 for ; Mon, 10 Jul 2000 08:38:02 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQixfu26924 for ; Mon, 10 Jul 2000 12:37:47 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id FAA23269 for ; Mon, 10 Jul 2000 05:37:59 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA13061 for mpls@uu.net; Mon, 10 Jul 2000 08:37:45 -0400 (EDT) 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 QQixez19338 for ; Mon, 10 Jul 2000 07:25:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixez24718 for ; Mon, 10 Jul 2000 03:25:13 -0400 (EDT) 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 QQixez17298 for ; Mon, 10 Jul 2000 07:25:12 GMT Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id DAA04288 for ; Mon, 10 Jul 2000 03:18:25 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAA5wA6t_; Mon Jul 10 03:18:19 2000 Received: from hkmail01.ap.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Mon, 10 Jul 2000 03:24:52 -0400 Received: from newbridge.com ([138.120.201.128]) by hkmail01.ap.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA7164 for ; Mon, 10 Jul 2000 15:24:48 +0800 Message-Id: <39697843.A7AB0465@newbridge.com> Date: Mon, 10 Jul 2000 15:16:20 +0800 From: "ABDUL RAZAQUE" Reply-To: abdul.razaque@alcatel.com Organization: Internal X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: (no subject) Content-Type: multipart/mixed; boundary="------------D28C3D01C42119561652B671" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------D28C3D01C42119561652B671 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe --------------D28C3D01C42119561652B671 Content-Type: text/x-vcard; charset=us-ascii; name="armemon.vcf" Content-Description: Card for Abdul Razaque Memon Content-Disposition: attachment; filename="armemon.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:RAZAQUE;MEMON ABDUL tel;fax:+852-28072570 tel;work:+852-21048335 x-mozilla-html:FALSE url:http://www.cid.alcatel.com org:Learning services APR;Alcatel Carrier Internetworking Division adr:;;;HONG KONG;;; version:2.1 email;internet:abdul.razaque@alcatel.com title:Manager Customer Learning x-mozilla-cpt:;6320 fn:ABDUL RAZAQUE end:vcard --------------D28C3D01C42119561652B671-- From owner-mpls@UU.NET Mon Jul 10 10: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 KAA10070 for ; Mon, 10 Jul 2000 10:21:14 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixgb05589; Mon, 10 Jul 2000 14:18:00 GMT Received: by mail-control.mail.uu.net id QQixgb01561 for mpls-outgoing; Mon, 10 Jul 2000 14:17:25 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQixgb01545 for ; Mon, 10 Jul 2000 14:17: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 QQixgb23803 for ; Mon, 10 Jul 2000 10:16:06 -0400 (EDT) Received: from smtprch2.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15]) id QQixgb04815 for ; Mon, 10 Jul 2000 14:16:06 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 10 Jul 2000 09:12:38 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 09:15:50 -0500 Message-ID: <03E3E0690542D211A1490000F80836F4029F97F2@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'Alex Zinin'" , mpls Subject: RE: draft-ietf-mpls-te-feed-00.txt Date: Mon, 10 Jul 2000 09:15:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEA79.586BB2BE" 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_01BFEA79.586BB2BE Content-Type: text/plain Alex, Thanks for the comments. The thing to keep in mind here is that how an implementation chooses to store the feedback information is not really part of the draft, and does not need to be standardized. The important point is that you receive feedback and you use that feedback information in subsequent computations until you get another LSA. There are a variety of different ways to accomplish this but probably the easiest is to store feedback information separately from flooded information. In any case, fed back information is never re-flooded, only the originator can flood its bandwidth information. If however you would prefer that I add a sentence or two to make this more clear I will be happy to do so if you want to send me something. Cheers, Peter -----Original Message----- From: Alex Zinin [SMTP:azinin@cisco.com] Sent: Monday, July 10, 2000 1:59 AM To: mpls Subject: draft-ietf-mpls-te-feed-00.txt Peter, et al. In your draft you recommend to change the contents of IGP's LSDB whenever the feedback from the signaling component is received. I'm afraid it is not quite good. 1. If the checksum of the LSA/LSP is not recalculated after the contents were changed, the IGP may report a fatal error if the checksum is verified before the next version of the LSA/LSP arrives. 2. Recalculating the checksum is also wrong, because: a) only the originating router must do this b) if this is done by other routers it may affect LSA/LSP version comparison algo. Because of the above and because it is a 'bad thing' to modify link-state PDUs originated by others, I think it is safer and makes some more sense to say that implementations must account for a method to link the information provided by the signaling component to the corresponding elements of the TE database, instead of overwriting it. Cheers, -- Alex Zinin ------_=_NextPart_001_01BFEA79.586BB2BE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-ietf-mpls-te-feed-00.txt

   Alex,

   Thanks for the comments. = The thing to keep in mind here is that how an implementation chooses to = store the feedback information is not really part of the draft, and = does not need to be standardized. The important point is that you = receive feedback and you use that feedback information in subsequent = computations until you get another LSA. There are a variety of = different ways to accomplish this but probably the easiest is to store = feedback information separately from flooded information. In any case, = fed back information is never re-flooded, only the originator can flood = its bandwidth information.

    If however you = would prefer that I add a sentence or two  to make this more clear = I will be happy to do so if you want to send me something.

    Cheers,

    Peter

    -----Original = Message-----
    From:   Alex Zinin = [SMTP:azinin@cisco.com]
    Sent:   Monday, July 10, 2000 1:59 AM
    To:     mpls
    Subject:       = draft-ietf-mpls-te-feed-00.txt


      Peter, et al.

      In your draft you recommend to = change the contents
      of IGP's LSDB whenever the = feedback from the signaling
      component is received. I'm = afraid it is not quite good.

      1. If the checksum of the = LSA/LSP is not recalculated
         after the = contents were changed, the IGP may report
         a fatal = error if the checksum is verified before
         the next = version of the LSA/LSP arrives.

      2. Recalculating the checksum = is also wrong, because:

          a) only = the originating router must do this

          b) if = this is done by other routers it may affect
             LSA/LSP = version comparison algo.

      Because of the above and = because it is a 'bad thing' to
      modify link-state PDUs = originated by others, I think it
      is safer and makes some more = sense to say that implementations
      must account for a method to = link the information provided
      by the signaling component to = the corresponding elements
      of the TE database, instead of = overwriting it.

      Cheers,
     
    --
    Alex Zinin


------_=_NextPart_001_01BFEA79.586BB2BE-- From owner-mpls@UU.NET Mon Jul 10 10:32: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 KAA10643 for ; Mon, 10 Jul 2000 10:32:36 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixgb12247; Mon, 10 Jul 2000 14:28:55 GMT Received: by mail-control.mail.uu.net id QQixgb02353 for mpls-outgoing; Mon, 10 Jul 2000 14:28: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 QQixgb02348 for ; Mon, 10 Jul 2000 14:28: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 QQixgb26267 for ; Mon, 10 Jul 2000 10:28:14 -0400 (EDT) Received: from bgslc02.TBG.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQixgb13071 for ; Mon, 10 Jul 2000 14:28:11 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id <3LKVQ3AV>; Mon, 10 Jul 2000 08:19:43 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE7BAE753@BGSLC02> From: Irwin Lazar To: "'Bora Akyol'" , mpls@UU.NET Subject: RE: Link Bundling Date: Mon, 10 Jul 2000 08:19:43 -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 See: http://www.ietf.org/internet-drafts/draft-lang-mpls-lmp-00.txt Please note that we keep a fairly complete list of MPLS related drafts at http://www.mplsrc.com/drafts.shtml Irwin -----Original Message----- From: Bora Akyol [mailto:akyol@pluris.com] Sent: Sunday, July 09, 2000 10:52 PM To: John Drake; mpls@UU.NET Subject: Re: Link Bundling John Can you please point me to this document? I do not see a document listed with this title at www.ietf.org under MPLS WG documents. Thanks Bora John Drake wrote: > Bora, > > A lot of your questions are addressed by Link Management Protocol (LMP), > which is explicitly part of the MPLS working group charter. > > Thanks, > > John > > -----Original Message----- > From: Bora Akyol [mailto:akyol@pluris.com] > Sent: Saturday, July 08, 2000 8:29 AM > To: Alex Zinin > Cc: Eric Gray; George Swallow; mpls@UU.NET > Subject: Re: Link Bundling > > Alex Zinin wrote: > > > Bora, Eric, group. > > > > 1. I think it is not quite appropriate to speak about L2 vs L3 > > link bundling. Approaches can be different, both have their > > pros and cons, but both have a right to live. So, I don't think > > this should be a driving factor. > > IMHO, bundling at L2 level and representing a single abstraction to L3 > protocols > is a cleaner approach. For example, in this draft, even though the links are > bundled, when you request a label, there is the notion of requesting a label > on a > particular link (essentially unbundling things). When ISIS/OSPF run over a > bundled link, the text mentions the fact that they can indeed run over only > a > single member of the link. But which member? What happens if that particular > member fails? These are some of the questions that would be (are) answered > by a > good L2 bundling abstraction. > > > > > 2. Link bundling, in the context it is presented in the document, > > seems to be MPLS-specific to me. > > > > Yes, but there is no reason for it to be MPLS specific. > > > > > 3. MPLS-specific contents vs routing-protocol-specific contents. > > It should be noted that TE attributes introduced to OSPF and ISIS > > are transmitted by respective protocols as opaque data, not > > taken into consideration by the protocol itself (other than > > flooding), so, strictly speaking, as soon as we have specified > > a standard way to carry such data, and this data does not affect > > operations of the protocol itself, changes in the actual data > > being propagated is no more a business of that protocol. > > > > OK. > > > > > I think the document is purely MPLS-specific, covering several > > areas of MPLS-related functions. OSPF & ISIS are used just as transport > > protocols and that makes perfect sense to me. > > I don't see much sense in braking the document into 3 separate > > parts and presenting them at OSPF, ISIS, and RSVP WGs, especially > > taking into consideration that the changes are MPLS-specific... > > > > My suggestion was not to split the document but to come up with a better > abstraction than what is presented in this document. We will be submitting > an > internet draft on such an implementation soon (but probably not before the > deadline for Pittsburgh). > > Regards > > Bora Akyol > > > > > My vote: accept. > > > > -- > > Alex Zinin > > > > Friday, July 07, 2000, 12:23 PM, Bora Akyol wrote: > > > > > Eric > > > > > As I mentioned in my previous email, I would be happy to write an ID > that > > > describes our approach and work with the community to make it an open > > > standard. > > > > > I believe that the bonding of L1 links into one bonded (bundled) L2 link > is > > > something that should be protocol-neutral and should work with all L3 > > > protocols. I believe that such an abstraction is possible and is > actually > > > fairly straightforward to implement and provides a coherent framework > that > > > one can use to ask questions like if protocol X were to run over a > bonded > > > link, how would it run; and then actually answer it in an easy manner. > > > > > Thanks for the comments, > > > > > Bora > > > > > Eric Gray wrote: > > > > >> Bora, > > >> > > >> I essentially agree with the observation that > > >> link bundling is not inherently an MPLS issue and I > > >> also feel that this draft - at least as is - should > > >> not be adopted by the MPLS working group. However, > > >> my reasoning is slightly different than yours. > > >> > > >> While the draft does include a lot of stuff > > >> that is specific to MPLS, it also includes a ton of > > >> IS-IS and OSPF specific stuff as well. My sense is > > >> that it actually has significantly more non-MPLS > > >> related stuff in it than MPLS related stuff. Other > > >> people may disagree but, at the very least, this > > >> work should be done in a forum that is less focused > > >> on label switching and more focused on routing. > > >> > > >> I do not think it is very useful to provide > > >> examples of proprietary approaches to solving the > > >> problem. It takes two to bundle links. But, if > > >> your point is that it may be a good idea to back > > >> away from a link-bundling scheme that is particular > > >> to MPLS LSP based links, I think it is a good point. > > >> > > >> -- > > >> Eric Gray > > >> > > >> > -----Original Message----- > > >> > From: Bora Akyol [mailto:akyol@pluris.com] > > >> > Sent: Friday, July 07, 2000 11:39 AM > > >> > To: George Swallow; mpls@UU.NET > > >> > Subject: Re: Link Bundling > > >> > > > >> > > > >> > George, Yakov, et al., > > >> > > > >> > I do not think that this internet draft should be adopted as an MPLS > > >> > working group document. My primary objection to this document > > >> > is the fact > > >> > that bundling of L1/L2 interfaces has nothing specific to do > > >> > with MPLS. > > >> > In fact, this is an L2 abstraction that should be completely > > >> > transparent > > >> > to MPLS, IP or ISIS. I feel that this particular draft is > > >> > very focused on > > >> > MPLS-specific concerns and does not provide a good > > >> > abstraction of the L2 > > >> > bundling aspects and also places significant restrictions on > > >> > what can be > > >> > done with a bundled link and what kind of members it can have. > > >> > > > >> > I personally know of at least one implementation (ours) of > > >> > bundled links > > >> > that forms such an abstraction to all upper layer protocols. In this > > >> > implementation, a heterogeneous group of L1/L2 interfaces are bonded > > >> > together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP > > >> > treats the > > >> > bundled (bonded) interface as just another type of interface. > > >> > When MPLS > > >> > RSVP messages are passed over the bundled interface, the > > >> > labels that are > > >> > assigned are programmed into all members of the bundled links > > >> > even though > > >> > in reality a hash is used so that only one of the members are used > (to > > >> > prevent reordering). Bandwidth management is handled by means of the > > >> > apriori knowledge of the hash. Also note that this particular > > >> > implementation is not MLPPP since no additional headers are > > >> > added to the > > >> > packets. > > >> > For MPLS specific concerns, the methods that are used in this > approach > > >> > can be expanded. For IP, this particular approach works very well. > > >> > > > >> > If there is interest from the MPLS WG, we (myself and another > > >> > colleague) > > >> > would be perfectly willing to author an Internet Draft on > > >> > this particular > > >> > bond implementation. The question that I have is what is the > > >> > proper forum > > >> > to submit a generalized layer 2 bundling draft in the IETF. It is > > >> > certainly relevant to MPLS, but it is just as relevant to IP, > > >> > ISIS, etc. > > >> > > > >> > Regards > > >> > > > >> > Bora Akyol > > >> > > > >> > > > >> > George Swallow wrote: > > >> > > > >> > > > Folks, > > >> > > > > > >> > > > Kireeti and myself would like to ask the MPLS WG to > > >> > > > accept draft-kompella-mpls-bundle-01.txt as an > > >> > > > MPLS WG document. > > >> > > > > > >> > > > Yakov. > > >> > > > > >> > > Consensus on this will be assessed on 7/12. Opinions > > >> > should be aired > > >> > > by then. > > >> > > > > >> > > ...George > > >> > > > > >> > > ================================================================== > > >> > > George Swallow Cisco Systems (978) 244-8143 > > >> > > 250 Apollo Drive > > >> > > Chelmsford, Ma 01824 > > >> > > > >> > > > >> > From owner-mpls@UU.NET Mon Jul 10 10:33: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 KAA10695 for ; Mon, 10 Jul 2000 10:33:53 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixgc13776; Mon, 10 Jul 2000 14:30:24 GMT Received: by mail-control.mail.uu.net id QQixgc02422 for mpls-outgoing; Mon, 10 Jul 2000 14:30: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 QQixgb02394 for ; Mon, 10 Jul 2000 14:29:58 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixgb08086 for ; Mon, 10 Jul 2000 10:29:25 -0400 (EDT) Received: from bgslc02.TBG.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQixgb13880 for ; Mon, 10 Jul 2000 14:29:24 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id <3LKVQ3AY>; Mon, 10 Jul 2000 08:20:56 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE7BAE754@BGSLC02> From: Irwin Lazar To: "'mpls@uu.net'" Subject: RFC/Draft status Date: Mon, 10 Jul 2000 08:20:56 -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 Hi folks, Is there any sort of WG master list of the current status of various ID's and RFC's? I'm trying to gain an understanding of how close various MPLS proposed standards are toward ratification. Thanks in advance. Irwin From owner-mpls@UU.NET Mon Jul 10 11:16:01 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12453 for ; Mon, 10 Jul 2000 11:16:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixge11726; Mon, 10 Jul 2000 15:13:12 GMT Received: by mail-control.mail.uu.net id QQixge18800 for mpls-outgoing; Mon, 10 Jul 2000 15:12: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 QQixge18769 for ; Mon, 10 Jul 2000 15:12: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 QQixge05867 for ; Mon, 10 Jul 2000 11:12:24 -0400 (EDT) Received: from iol.unh.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mars.iol.unh.edu [132.177.121.222]) id QQixge07103 for ; Mon, 10 Jul 2000 15:12:07 GMT Received: from localhost (jzou@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id LAA19693 for ; Mon, 10 Jul 2000 11:12:06 -0400 (EDT) Date: Mon, 10 Jul 2000 11:12:06 -0400 From: Jie Zou To: mpls@UU.NET Subject: determine the presence of non-RSVP routers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello everyone, I have a question about the determination of the presence of non-RSVP routers: In section 4.2.2, draft-ietf-mpls-rsvp-lsp-tunnel-05.txt "if a router has a neighbor that is known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when sending messages that pass through the non-RSVP routers." My question is that how a upstream node knows the downstream node is the non-RSVP router or not? Thanks. --------------- Jie Zou MPLS Consortium IOL, UNH --------------- From owner-mpls@UU.NET Mon Jul 10 15:25: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 PAA24919 for ; Mon, 10 Jul 2000 15:25:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixgv00668; Mon, 10 Jul 2000 19:22:59 GMT Received: by mail-control.mail.uu.net id QQixgv26453 for mpls-outgoing; Mon, 10 Jul 2000 19:22: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 QQixgv26444 for ; Mon, 10 Jul 2000 19:22: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 QQixgv02361 for ; Mon, 10 Jul 2000 15:22:11 -0400 (EDT) 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 QQixgv27363 for ; Mon, 10 Jul 2000 19:22:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA25922 for mpls@uu.net; Mon, 10 Jul 2000 15:22:10 -0400 (EDT) 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 QQixgv26418 for ; Mon, 10 Jul 2000 19:21:46 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixgv22710 for ; Mon, 10 Jul 2000 15:21:16 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQixgv26339 for ; Mon, 10 Jul 2000 19:20:45 GMT Received: from rtp-dial-1-148.cisco.com (rtp-dial-1-148.cisco.com [10.83.97.148]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA02699; Mon, 10 Jul 2000 12:20:21 -0700 (PDT) Date: Mon, 10 Jul 2000 10:34:21 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <12440.000710@cisco.com> To: "Peter Ashwood-Smith" CC: mpls Subject: Re: draft-ietf-mpls-te-feed-00.txt In-reply-To: <03E3E0690542D211A1490000F80836F4029F97F2@zcard00f.ca.nortel.com> References: <03E3E0690542D211A1490000F80836F4029F97F2@zcard00f.ca.nortel.com> 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 Peter, You have several places in the document that explicitly speak about LSDB modification. Some examples below. I think this should be changed to something more neutral. > constructed. Eventually this message arrives back at the source > node, where the vector is taken and inserted into the topology > database. This node has just learned from its mistake and is now > When the LDP session that originated a CR-LDP label request receives > a notification that contains feedback TLV's it is recommended that > these bandwidth values overwrite the corresponding values in the > nodes topology database. Doing so permits this node to immediately Thanks, -- Alex Zinin Monday, July 10, 2000, 7:15 AM, Peter Ashwood-Smith wrote: > Alex, > Thanks for the comments. The thing to keep in mind here is that how an > implementation chooses to store the feedback information is not really part > of the draft, and does not need to be standardized. The important point is > that you receive feedback and you use that feedback information in > subsequent computations until you get another LSA. There are a variety of > different ways to accomplish this but probably the easiest is to store > feedback information separately from flooded information. In any case, fed > back information is never re-flooded, only the originator can flood its > bandwidth information. > If however you would prefer that I add a sentence or two to make this > more clear I will be happy to do so if you want to send me something. > Cheers, > Peter > -----Original Message----- > From: Alex Zinin [SMTP:azinin@cisco.com] > Sent: Monday, July 10, 2000 1:59 AM > To: mpls > Subject: draft-ietf-mpls-te-feed-00.txt > Peter, et al. > In your draft you recommend to change the contents > of IGP's LSDB whenever the feedback from the signaling > component is received. I'm afraid it is not quite good. > 1. If the checksum of the LSA/LSP is not recalculated > after the contents were changed, the IGP may report > a fatal error if the checksum is verified before > the next version of the LSA/LSP arrives. > 2. Recalculating the checksum is also wrong, because: > a) only the originating router must do this > b) if this is done by other routers it may affect > LSA/LSP version comparison algo. > Because of the above and because it is a 'bad thing' to > modify link-state PDUs originated by others, I think it > is safer and makes some more sense to say that implementations > must account for a method to link the information provided > by the signaling component to the corresponding elements > of the TE database, instead of overwriting it. > Cheers, > -- > Alex Zinin From owner-mpls@UU.NET Mon Jul 10 17:26: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 RAA29108 for ; Mon, 10 Jul 2000 17:26:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixhd15619; Mon, 10 Jul 2000 21:26:51 GMT Received: by mail-control.mail.uu.net id QQixhd27976 for mpls-outgoing; Mon, 10 Jul 2000 21:26: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 QQixhd27971 for ; Mon, 10 Jul 2000 21:26:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixhd19530 for ; Mon, 10 Jul 2000 17:25:57 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQixhd14095 for ; Mon, 10 Jul 2000 21:25:56 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id QAA18331; Mon, 10 Jul 2000 16:25:41 -0500 Message-Id: <4.3.2.7.2.20000710081826.00b74ec0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Jul 2000 17:26:20 -0400 To: Bora Akyol From: Lou Berger Subject: Re: Link Bundling Cc: George Swallow , mpls@UU.NET In-Reply-To: <396623BB.5C1282B9@pluris.com> References: <200007052142.RAA14677@lir.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Bora, There is a difference specific to MPLS, i.e., both sides of a link need to agree on the label. You only briefly mentioned this key point in your mail. I believe the choices open to synchronize labels over bundled/bonded links are: 1. Allow the receipt of each label over any/all links in the bundle. This is essentially the equivalent of what's done for IP. This approach just doesn't work for non-packet links (MPLamdaS). 2. The link is selected algorithmically (per your message) Some algorithm would need to be standardized. An algorithmic approach is likely to either be artificially limiting (by not taking into account allocations or loading) or so complex that it's prone to error. 3. Have the underlying layer signals the link. This can be done using some or some lower level signaling protocol (such as LMP.) 4. Have MPLS signaling just provide the link information. This is what's documented in the draft. It does mean that signaling needs to convey link information, but it allows greater flexibility than an algorithmic approach and doesn't require the use of yet another signaling protocol to setup each LSP. Note: In this case, the underlying layer can still pick the link, it's just transported by signaling, much like RSVP opaquely carries int-serv information. There's no problem if you want to use your hash, or if someone else wants to use more dynamic information. Also, the draft doesn't require that routing and IP understand the component links (they can operate on aggregated information). We can certainly alter the text to make all this more explicit. It seems to me that much of your objection is really based on that link selection is dynamic rather than algorithmic and that the draft isn't explicit about routing, IP and even signaling not needing to understand the specifics of the component links. Is this correct? Lou At 11:38 AM 7/7/00 -0700, Bora Akyol wrote: >George, Yakov, et al., > >I do not think that this internet draft should be adopted as an MPLS >working group document. My primary objection to this document is the fact >that bundling of L1/L2 interfaces has nothing specific to do with MPLS. >In fact, this is an L2 abstraction that should be completely transparent >to MPLS, IP or ISIS. I feel that this particular draft is very focused on >MPLS-specific concerns and does not provide a good abstraction of the L2 >bundling aspects and also places significant restrictions on what can be >done with a bundled link and what kind of members it can have. > >I personally know of at least one implementation (ours) of bundled links >that forms such an abstraction to all upper layer protocols. In this >implementation, a heterogeneous group of L1/L2 interfaces are bonded >together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP treats the >bundled (bonded) interface as just another type of interface. When MPLS >RSVP messages are passed over the bundled interface, the labels that are >assigned are programmed into all members of the bundled links even though >in reality a hash is used so that only one of the members are used (to >prevent reordering). Bandwidth management is handled by means of the >apriori knowledge of the hash. Also note that this particular >implementation is not MLPPP since no additional headers are added to the >packets. >For MPLS specific concerns, the methods that are used in this approach >can be expanded. For IP, this particular approach works very well. > >If there is interest from the MPLS WG, we (myself and another colleague) >would be perfectly willing to author an Internet Draft on this particular >bond implementation. The question that I have is what is the proper forum >to submit a generalized layer 2 bundling draft in the IETF. It is >certainly relevant to MPLS, but it is just as relevant to IP, ISIS, etc. > >Regards > >Bora Akyol > > >George Swallow wrote: > > > > Folks, > > > > > > Kireeti and myself would like to ask the MPLS WG to > > > accept draft-kompella-mpls-bundle-01.txt as an > > > MPLS WG document. > > > > > > Yakov. > > > > Consensus on this will be assessed on 7/12. Opinions should be aired > > by then. > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 From owner-mpls@UU.NET Mon Jul 10 18:22: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 SAA00134 for ; Mon, 10 Jul 2000 18:22:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixhh03726; Mon, 10 Jul 2000 22:22:38 GMT Received: by mail-control.mail.uu.net id QQixhh15453 for mpls-outgoing; Mon, 10 Jul 2000 22:22: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 QQixhh15365 for ; Mon, 10 Jul 2000 22:22: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 QQixhh01341 for ; Mon, 10 Jul 2000 18:21:58 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQixhh02791 for ; Mon, 10 Jul 2000 22:21:57 GMT Received: from gwaters-pc.avici.com (gwaters-pc.avici.com [10.1.1.169]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id SAA18435; Mon, 10 Jul 2000 18:21:21 -0400 (EDT) Message-Id: <4.3.1.2.20000710174453.00b6cc20@mailhost.avici.com> X-Sender: gwaters@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 10 Jul 2000 18:20:45 -0400 To: Lou Berger From: Greg Waters Subject: Re: Link Bundling Cc: Bora Akyol , George Swallow , mpls@UU.NET In-Reply-To: <4.3.2.7.2.20000710081826.00b74ec0@mail.labn.net> References: <396623BB.5C1282B9@pluris.com> <200007052142.RAA14677@lir.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Lou, you're getting warm. You suggest that option (1) is not good for MPLamdaS, perhaps because you assume that a given LSP's packets appear on a single link during bundled operation? I read you as thinking that a label goes to waste on all but one link in the bundle, in option (1). Bora's model, which I find valuable, is to allow one or more suitable IPv4-bearing and IPv6-bearing LSPs to appear simultaneously, load-balanced, on all links within a bundle. The traffic volume within each LSP is irrelevant to the load balancing, unlike Kireeti's model. As with some link aggregation methods, the load-balancing uses IPv4/v6 address hashing, or another technique that maintains order within each microflow. Given a rich hash in relation to the bundle size, it does not matter what hashing algorithm each hop uses. The benefit: A "best-effort" or "premium" Internet LSP can be configured with a capacity ten times larger than one's fastest physical link. I won't suggest that this major benefit extends to "CBR LSPs" of a kind which don't tolerate burstiness and which defy good load-balancing. Recent demos showed that Bora's model works over optical switches in which all traffic on the fibers in one bundle are switched to as many fibers in another bundle. I suppose that falls short of the MPLamdaS requirements, of which I confess ignorance. --Greg W., Avici Systems At 05:26 PM 7/10/00 -0400, Lou Berger wrote: >Bora, >There is a difference specific to MPLS, i.e., both sides of a link need to >agree on the label. You only briefly mentioned this key point in your >mail. I believe the choices open to synchronize labels over >bundled/bonded links are: > 1. Allow the receipt of each label over any/all links in the bundle. > This is essentially the equivalent of what's done for IP. > This approach just doesn't work for non-packet links (MPLamdaS). > > 2. The link is selected algorithmically (per your message) > Some algorithm would need to be standardized. An algorithmic > approach is likely to either be artificially limiting (by not > taking into account allocations or loading) or so complex that > it's prone to error. > > 3. Have the underlying layer signals the link. > This can be done using some or some lower level signaling protocol > (such as LMP.) > > 4. Have MPLS signaling just provide the link information. > This is what's documented in the draft. It does mean that signaling > needs to convey link information, but it allows greater flexibility > than an algorithmic approach and doesn't require the use of yet > another signaling protocol to setup each LSP. > > Note: In this case, the underlying layer can still pick the link, > it's just transported by signaling, much like RSVP opaquely > carries int-serv information. There's no problem if you want to > use your hash, or if someone else wants to use more dynamic > information. > > Also, the draft doesn't require that routing and IP understand the > component links (they can operate on aggregated information). > We can certainly alter the text to make all this more explicit. > >It seems to me that much of your objection is really based on that link >selection is dynamic rather than algorithmic and that the draft isn't >explicit about routing, IP and even signaling not needing to understand >the specifics of the component links. Is this correct? >Lou > >At 11:38 AM 7/7/00 -0700, Bora Akyol wrote: >>George, Yakov, et al., >> >>I do not think that this internet draft should be adopted as an MPLS >>working group document. My primary objection to this document is the fact >>that bundling of L1/L2 interfaces has nothing specific to do with MPLS. >>In fact, this is an L2 abstraction that should be completely transparent >>to MPLS, IP or ISIS. I feel that this particular draft is very focused on >>MPLS-specific concerns and does not provide a good abstraction of the L2 >>bundling aspects and also places significant restrictions on what can be >>done with a bundled link and what kind of members it can have. >> >>I personally know of at least one implementation (ours) of bundled links >>that forms such an abstraction to all upper layer protocols. In this >>implementation, a heterogeneous group of L1/L2 interfaces are bonded >>together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP treats the >>bundled (bonded) interface as just another type of interface. When MPLS >>RSVP messages are passed over the bundled interface, the labels that are >>assigned are programmed into all members of the bundled links even though >>in reality a hash is used so that only one of the members are used (to >>prevent reordering). Bandwidth management is handled by means of the >>apriori knowledge of the hash. Also note that this particular >>implementation is not MLPPP since no additional headers are added to the >>packets. >>For MPLS specific concerns, the methods that are used in this approach >>can be expanded. For IP, this particular approach works very well. >> >>If there is interest from the MPLS WG, we (myself and another colleague) >>would be perfectly willing to author an Internet Draft on this particular >>bond implementation. The question that I have is what is the proper forum >>to submit a generalized layer 2 bundling draft in the IETF. It is >>certainly relevant to MPLS, but it is just as relevant to IP, ISIS, etc. >>Regards >>Bora Akyol >> >>George Swallow wrote: >> > > Folks, >> > > Kireeti and myself would like to ask the MPLS WG to >> > > accept draft-kompella-mpls-bundle-01.txt as an >> > > MPLS WG document. >> > > Yakov. >> > >> > Consensus on this will be assessed on 7/12. Opinions should be aired >> > by then. >> > ...George Swallow From owner-mpls@UU.NET Mon Jul 10 19:33: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 TAA01812 for ; Mon, 10 Jul 2000 19:33:10 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixhm01817; Mon, 10 Jul 2000 23:33:10 GMT Received: by mail-control.mail.uu.net id QQixhm02036 for mpls-outgoing; Mon, 10 Jul 2000 23:32: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 QQixhm02030 for ; Mon, 10 Jul 2000 23:32: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 QQixhm13321 for ; Mon, 10 Jul 2000 19:32:52 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [64.232.69.132]) id QQixhm14832 for ; Mon, 10 Jul 2000 23:32:52 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jul 2000 16:39:01 -0700 Message-ID: <9A564CC874B5D3118FB9009027B0A66269086B@ICARIAN> From: Eric Gray To: "'Lou Berger'" Cc: mpls@UU.NET Subject: RE: Link Bundling Date: Mon, 10 Jul 2000 16:39:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Lou, I seem to recall that someone had made a proposal some (real long) time back to include link information in MPLS signaling. I can't see to recall whatever happened to the idea though. :-) -- Eric Gray > --- ... ... > > 4. Have MPLS signaling just provide the link information. > This is what's documented in the draft. It does mean > that signaling needs to convey link information, but it allows greater flexibility than an algorithmic approach and doesn't require the use of yet another signaling protocol to setup each LSP. > ... ... > From owner-mpls@UU.NET Mon Jul 10 19:49: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 TAA02002 for ; Mon, 10 Jul 2000 19:49:10 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixhn20738; Mon, 10 Jul 2000 23:49:11 GMT Received: by mail-control.mail.uu.net id QQixhn03452 for mpls-outgoing; Mon, 10 Jul 2000 23:48: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 QQixhn03447 for ; Mon, 10 Jul 2000 23:48:32 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 QQixhn22612 for ; Mon, 10 Jul 2000 19:48:18 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQixhn09663 for ; Mon, 10 Jul 2000 23:48:03 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id SAA32305; Mon, 10 Jul 2000 18:47:20 -0500 Message-Id: <4.3.2.7.2.20000710194056.00baf100@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Jul 2000 19:48:01 -0400 To: Greg Waters From: Lou Berger Subject: Re: Link Bundling Cc: Lou Berger , Bora Akyol , George Swallow , mpls@UU.NET In-Reply-To: <4.3.1.2.20000710174453.00b6cc20@mailhost.avici.com> References: <4.3.2.7.2.20000710081826.00b74ec0@mail.labn.net> <396623BB.5C1282B9@pluris.com> <200007052142.RAA14677@lir.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Greg, You are correct, spreading a single LSP over multiple component links is not supported in the bundle draft. I agree this could have some value for best-effort LSPs. (The draft was concerned with TE LSPs.) We could support such "spreading" by adding a special link value or bit to indicated that the label should be made available on all PSC (packet) links of a bundle/bond. (The spreading algorithm need not be standardized for this case.) Lou At 06:20 PM 7/10/00 -0400, Greg Waters wrote: >Lou, you're getting warm. You suggest that option (1) is not good for >MPLamdaS, perhaps because you assume that a given LSP's packets appear on >a single link during bundled operation? I read you as thinking that a >label goes to waste on all but one link in the bundle, in option (1). > >Bora's model, which I find valuable, is to allow one or more suitable >IPv4-bearing and IPv6-bearing LSPs to appear simultaneously, >load-balanced, on all links within a bundle. The traffic volume within >each LSP is irrelevant to the load balancing, unlike Kireeti's model. As >with some link aggregation methods, the load-balancing uses IPv4/v6 >address hashing, or another technique that maintains order within each >microflow. Given a rich hash in relation to the bundle size, it does not >matter what hashing algorithm each hop uses. > >The benefit: A "best-effort" or "premium" Internet LSP can be configured >with a capacity ten times larger than one's fastest physical link. I >won't suggest that this major benefit extends to "CBR LSPs" of a kind >which don't tolerate burstiness and which defy good load-balancing. > >Recent demos showed that Bora's model works over optical switches in which >all traffic on the fibers in one bundle are switched to as many fibers in >another bundle. I suppose that falls short of the MPLamdaS requirements, >of which I confess ignorance. --Greg W., Avici Systems > >At 05:26 PM 7/10/00 -0400, Lou Berger wrote: >>Bora, >>There is a difference specific to MPLS, i.e., both sides of a link need >>to agree on the label. You only briefly mentioned this key point in your >>mail. I believe the choices open to synchronize labels over >>bundled/bonded links are: >> 1. Allow the receipt of each label over any/all links in the bundle. >> This is essentially the equivalent of what's done for IP. >> This approach just doesn't work for non-packet links (MPLamdaS). >> >> 2. The link is selected algorithmically (per your message) >> Some algorithm would need to be standardized. An algorithmic >> approach is likely to either be artificially limiting (by not >> taking into account allocations or loading) or so complex that >> it's prone to error. >> >> 3. Have the underlying layer signals the link. >> This can be done using some or some lower level signaling protocol >> (such as LMP.) >> >> 4. Have MPLS signaling just provide the link information. >> This is what's documented in the draft. It does mean that signaling >> needs to convey link information, but it allows greater flexibility >> than an algorithmic approach and doesn't require the use of yet >> another signaling protocol to setup each LSP. >> >> Note: In this case, the underlying layer can still pick the link, >> it's just transported by signaling, much like RSVP opaquely >> carries int-serv information. There's no problem if you want to >> use your hash, or if someone else wants to use more dynamic >> information. >> >> Also, the draft doesn't require that routing and IP understand the >> component links (they can operate on aggregated information). >> We can certainly alter the text to make all this more explicit. >> >>It seems to me that much of your objection is really based on that link >>selection is dynamic rather than algorithmic and that the draft isn't >>explicit about routing, IP and even signaling not needing to understand >>the specifics of the component links. Is this correct? >>Lou >> >>At 11:38 AM 7/7/00 -0700, Bora Akyol wrote: >>>George, Yakov, et al., >>> >>>I do not think that this internet draft should be adopted as an MPLS >>>working group document. My primary objection to this document is the fact >>>that bundling of L1/L2 interfaces has nothing specific to do with MPLS. >>>In fact, this is an L2 abstraction that should be completely transparent >>>to MPLS, IP or ISIS. I feel that this particular draft is very focused on >>>MPLS-specific concerns and does not provide a good abstraction of the L2 >>>bundling aspects and also places significant restrictions on what can be >>>done with a bundled link and what kind of members it can have. >>> >>>I personally know of at least one implementation (ours) of bundled links >>>that forms such an abstraction to all upper layer protocols. In this >>>implementation, a heterogeneous group of L1/L2 interfaces are bonded >>>together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP treats the >>>bundled (bonded) interface as just another type of interface. When MPLS >>>RSVP messages are passed over the bundled interface, the labels that are >>>assigned are programmed into all members of the bundled links even though >>>in reality a hash is used so that only one of the members are used (to >>>prevent reordering). Bandwidth management is handled by means of the >>>apriori knowledge of the hash. Also note that this particular >>>implementation is not MLPPP since no additional headers are added to the >>>packets. >>>For MPLS specific concerns, the methods that are used in this approach >>>can be expanded. For IP, this particular approach works very well. >>> >>>If there is interest from the MPLS WG, we (myself and another colleague) >>>would be perfectly willing to author an Internet Draft on this particular >>>bond implementation. The question that I have is what is the proper forum >>>to submit a generalized layer 2 bundling draft in the IETF. It is >>>certainly relevant to MPLS, but it is just as relevant to IP, ISIS, etc. >>>Regards >>>Bora Akyol >>> >>>George Swallow wrote: >>> > > Folks, >>> > > Kireeti and myself would like to ask the MPLS WG to >>> > > accept draft-kompella-mpls-bundle-01.txt as an >>> > > MPLS WG document. >>> > > Yakov. >>> > >>> > Consensus on this will be assessed on 7/12. Opinions should be aired >>> > by then. >>> > ...George Swallow From owner-mpls@UU.NET Mon Jul 10 20:48: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 UAA02577 for ; Mon, 10 Jul 2000 20:48:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixhr04838; Tue, 11 Jul 2000 00:48:55 GMT Received: by mail-control.mail.uu.net id QQixhr17675 for mpls-outgoing; Tue, 11 Jul 2000 00:48: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 QQixhr17670 for ; Tue, 11 Jul 2000 00:48: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 QQixhr24447 for ; Mon, 10 Jul 2000 20:48:11 -0400 (EDT) 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 QQixhr15719 for ; Tue, 11 Jul 2000 00:48:11 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA01587 for mpls@uu.net; Mon, 10 Jul 2000 20:48:10 -0400 (EDT) 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 QQixhr17644 for ; Tue, 11 Jul 2000 00:47:35 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixhr24374 for ; Mon, 10 Jul 2000 20:47:31 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQixhr15461 for ; Tue, 11 Jul 2000 00:47:31 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 RAA02083; Mon, 10 Jul 2000 17:37:58 -0700 (PDT) Message-ID: <396A6C66.D7E4C8B@pluris.com> Date: Mon, 10 Jul 2000 17:37:58 -0700 From: Bora Akyol X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lou Berger CC: George Swallow , mpls@UU.NET Subject: Re: Link Bundling References: <200007052142.RAA14677@lir.cisco.com> <4.3.2.7.2.20000710081826.00b74ec0@mail.labn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit See my comments within: Lou Berger wrote: > Bora, > > There is a difference specific to MPLS, i.e., both sides of a link need to > agree on the label. You only briefly mentioned this key point in your > mail. I believe the choices open to synchronize labels over bundled/bonded > links are: > 1. Allow the receipt of each label over any/all links in the bundle. > This is essentially the equivalent of what's done for IP. > This approach just doesn't work for non-packet links (MPLamdaS). > OK. > > 2. The link is selected algorithmically (per your message) > Some algorithm would need to be standardized. An algorithmic > approach is likely to either be artificially limiting (by not > taking into account allocations or loading) or so complex that > it's prone to error. > I think this is a presumption. OSPF uses a common algorithm and we have seen interoperable, distributed routing computation happen. Also, what I gave was an example, it can easily be extended to support loading of individual link members. > > 3. Have the underlying layer signals the link. > This can be done using some or some lower level signaling protocol > (such as LMP.) > Sure. > > 4. Have MPLS signaling just provide the link information. > This is what's documented in the draft. It does mean that signaling > needs to convey link information, but it allows greater flexibility > than an algorithmic approach and doesn't require the use of yet > another signaling protocol to setup each LSP. > > Note: In this case, the underlying layer can still pick the link, > it's just transported by signaling, much like RSVP opaquely > carries int-serv information. There's no problem if you want to > use your hash, or if someone else wants to use more dynamic > information. > > Also, the draft doesn't require that routing and IP understand the > component links (they can operate on aggregated information). > We can certainly alter the text to make all this more explicit. > > It seems to me that much of your objection is really based on that link > selection is dynamic rather than algorithmic and that the draft isn't > explicit about routing, IP and even signaling not needing to understand the > specifics of the component links. Is this correct? > > Lou > No My objection is based on the fact that this draft does not address the abstraction of physical links into a logical entity that can be used by L3 and above. > > At 11:38 AM 7/7/00 -0700, Bora Akyol wrote: > >George, Yakov, et al., > > > >I do not think that this internet draft should be adopted as an MPLS > >working group document. My primary objection to this document is the fact > >that bundling of L1/L2 interfaces has nothing specific to do with MPLS. > >In fact, this is an L2 abstraction that should be completely transparent > >to MPLS, IP or ISIS. I feel that this particular draft is very focused on > >MPLS-specific concerns and does not provide a good abstraction of the L2 > >bundling aspects and also places significant restrictions on what can be > >done with a bundled link and what kind of members it can have. > > > >I personally know of at least one implementation (ours) of bundled links > >that forms such an abstraction to all upper layer protocols. In this > >implementation, a heterogeneous group of L1/L2 interfaces are bonded > >together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP treats the > >bundled (bonded) interface as just another type of interface. When MPLS > >RSVP messages are passed over the bundled interface, the labels that are > >assigned are programmed into all members of the bundled links even though > >in reality a hash is used so that only one of the members are used (to > >prevent reordering). Bandwidth management is handled by means of the > >apriori knowledge of the hash. Also note that this particular > >implementation is not MLPPP since no additional headers are added to the > >packets. > >For MPLS specific concerns, the methods that are used in this approach > >can be expanded. For IP, this particular approach works very well. > > > >If there is interest from the MPLS WG, we (myself and another colleague) > >would be perfectly willing to author an Internet Draft on this particular > >bond implementation. The question that I have is what is the proper forum > >to submit a generalized layer 2 bundling draft in the IETF. It is > >certainly relevant to MPLS, but it is just as relevant to IP, ISIS, etc. > > > >Regards > > > >Bora Akyol > > > > > >George Swallow wrote: > > > > > > Folks, > > > > > > > > Kireeti and myself would like to ask the MPLS WG to > > > > accept draft-kompella-mpls-bundle-01.txt as an > > > > MPLS WG document. > > > > > > > > Yakov. > > > > > > Consensus on this will be assessed on 7/12. Opinions should be aired > > > by then. > > > > > > ...George > > > > > > ================================================================== > > > George Swallow Cisco Systems (978) 244-8143 > > > 250 Apollo Drive > > > Chelmsford, Ma 01824 From owner-mpls@UU.NET Mon Jul 10 21:01: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 VAA02889 for ; Mon, 10 Jul 2000 21:01:30 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixhs25406; Tue, 11 Jul 2000 01:01:31 GMT Received: by mail-control.mail.uu.net id QQixhs22181 for mpls-outgoing; Tue, 11 Jul 2000 01:00: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 QQixhs21861 for ; Tue, 11 Jul 2000 01:00:54 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixhs02921 for ; Mon, 10 Jul 2000 21:00:43 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQixhs23456 for ; Tue, 11 Jul 2000 01:00:28 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id UAA23658; Mon, 10 Jul 2000 20:00:10 -0500 Message-Id: <4.3.2.7.2.20000710204232.00e0eee0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Jul 2000 21:00:52 -0400 To: Bora Akyol From: Lou Berger Subject: Re: Link Bundling Cc: Lou Berger , George Swallow , mpls@UU.NET In-Reply-To: <396A6C66.D7E4C8B@pluris.com> References: <200007052142.RAA14677@lir.cisco.com> <4.3.2.7.2.20000710081826.00b74ec0@mail.labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Bora, see comments in-line below. At 05:37 PM 7/10/00 -0700, Bora Akyol wrote: >See my comments within: > >Lou Berger wrote: >[...] > > > > 2. The link is selected algorithmically (per your message) > > Some algorithm would need to be standardized. An algorithmic > > approach is likely to either be artificially limiting (by not > > taking into account allocations or loading) or so complex that > > it's prone to error. > > > >I think this is a presumption. OSPF uses a common algorithm and we have seen >interoperable, distributed routing computation happen. Also, what I gave >was an >example, it can easily be extended to support loading of individual link >members. Agreed, it is a presumption. But having two algorithms running in parallel that are each sampling traffic levels to select the link used by an LSP just scares me. Standardizing such an algorithm doesn't make a whole lot of sense to me either. This isn't the same as h-b-h routing, which mostly works when information is out of sync. >[...] > > > > 4. Have MPLS signaling just provide the link information. > > This is what's documented in the draft. It does mean that signaling > > needs to convey link information, but it allows greater flexibility > > than an algorithmic approach and doesn't require the use of yet > > another signaling protocol to setup each LSP. > > > > Note: In this case, the underlying layer can still pick the link, > > it's just transported by signaling, much like RSVP opaquely > > carries int-serv information. There's no problem if you want to > > use your hash, or if someone else wants to use more dynamic > > information. > > > > Also, the draft doesn't require that routing and IP understand the > > component links (they can operate on aggregated information). > > We can certainly alter the text to make all this more explicit. > > > > It seems to me that much of your objection is really based on that link > > selection is dynamic rather than algorithmic and that the draft isn't > > explicit about routing, IP and even signaling not needing to understand the > > specifics of the component links. Is this correct? > > > > Lou > > > >No > >My objection is based on the fact that this draft does not address the >abstraction of physical links into a logical entity that can be used by L3 and >above. You're right. The draft doesn't do this, but nor should it. I think it's neutral on the existence of such an abstraction. It does define how to use such an abstraction (which could be implementation dependent) and provides a vehicle to carry information (link id) that can be used by such an abstraction when setting up an LSP. It also works fine if no abstraction is present. Lou >[...] From owner-mpls@UU.NET Tue Jul 11 06:35: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 GAA24043 for ; Tue, 11 Jul 2000 06:35:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixje20935; Tue, 11 Jul 2000 10:35:33 GMT Received: by mail-control.mail.uu.net id QQixje10011 for mpls-outgoing; Tue, 11 Jul 2000 10:34: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 QQixje10002 for ; Tue, 11 Jul 2000 10:34:42 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixje12088 for ; Tue, 11 Jul 2000 06:34:36 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQixje20312 for ; Tue, 11 Jul 2000 10:34:20 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA29643 for mpls@uu.net; Tue, 11 Jul 2000 06:34:20 -0400 (EDT) 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 QQixje09980 for ; Tue, 11 Jul 2000 10:33: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 QQixje12033 for ; Tue, 11 Jul 2000 06:33:36 -0400 (EDT) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQixje11139 for ; Tue, 11 Jul 2000 10:33:21 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23856; Tue, 11 Jul 2000 06:33:19 -0400 (EDT) Message-Id: <200007111033.GAA23856@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsp-hierarchy-00.txt Date: Tue, 11 Jul 2000 06:33:19 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LSP Hierarchy with MPLS TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-lsp-hierarchy-00.txt Pages : 11 Date : 10-Jul-00 To improve scalability of MPLS TE it may be useful to aggregate TE LSPs. The aggregation is accomplished by (a) an LSR creating a TE LSP, (b) the LSR forming a forwarding adjacency out of that LSP (advertising this LSP as a link into ISIS/OSPF), (c) allowing other LSRs to use forwarding adjacencies for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-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-ietf-mpls-lsp-hierarchy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-hierarchy-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: <20000710152604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-hierarchy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-hierarchy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710152604.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Jul 11 06:35: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 GAA24060 for ; Tue, 11 Jul 2000 06:35:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixje14618; Tue, 11 Jul 2000 10:35:54 GMT Received: by mail-control.mail.uu.net id QQixje10025 for mpls-outgoing; Tue, 11 Jul 2000 10:35: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 QQixje10019 for ; Tue, 11 Jul 2000 10:35: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 QQixje12809 for ; Tue, 11 Jul 2000 06:34:45 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQixje20498 for ; Tue, 11 Jul 2000 10:34:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA29666 for mpls@uu.net; Tue, 11 Jul 2000 06:34:44 -0400 (EDT) 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 QQixje09989 for ; Tue, 11 Jul 2000 10:33:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixje12760 for ; Tue, 11 Jul 2000 06:33:40 -0400 (EDT) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQixje11215 for ; Tue, 11 Jul 2000 10:33: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 GAA23880; Tue, 11 Jul 2000 06:33:24 -0400 (EDT) Message-Id: <200007111033.GAA23880@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsr-mib-05.txt Date: Tue, 11 Jul 2000 06:33:24 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Label Switch Router Management Information Base Using SMIv2 Author(s) : C. Srinivasan, A. Viswanathan, T. Nadeau Filename : draft-ietf-mpls-lsr-mib-05.txt Pages : 54 Date : 10-Jul-00 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling a Multi-Protocol Label Switching (MPLS) [MPLSArch, MPLSFW] Label Switch Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsr-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsr-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000710152629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsr-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsr-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710152629.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Jul 11 08:56: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 IAA28682 for ; Tue, 11 Jul 2000 08:56:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixjn21576; Tue, 11 Jul 2000 12:56:07 GMT Received: by mail-control.mail.uu.net id QQixjn11994 for mpls-outgoing; Tue, 11 Jul 2000 12:55: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 QQixjn11989 for ; Tue, 11 Jul 2000 12:55: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 QQixjn06863 for ; Tue, 11 Jul 2000 08:54:38 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQixjn08397 for ; Tue, 11 Jul 2000 12:54:38 GMT Received: from gwaters-pc.avici.com (gwaters-pc.avici.com [10.1.1.169]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id IAA02328; Tue, 11 Jul 2000 08:54:00 -0400 (EDT) Message-Id: <4.3.1.2.20000711081943.00b6c740@mailhost.avici.com> X-Sender: gwaters@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 11 Jul 2000 08:35:47 -0400 To: Lou Berger From: Greg Waters Subject: Re: Link Bundling Cc: Lou Berger , Bora Akyol , George Swallow , mpls@UU.NET In-Reply-To: <4.3.2.7.2.20000710194056.00baf100@mail.labn.net> References: <4.3.1.2.20000710174453.00b6cc20@mailhost.avici.com> <4.3.2.7.2.20000710081826.00b74ec0@mail.labn.net> <396623BB.5C1282B9@pluris.com> <200007052142.RAA14677@lir.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 07:48 PM 7/10/00 -0400, Lou Berger wrote: >Greg, > You are correct, spreading a single LSP over multiple component > links is not supported in the bundle draft. I agree this could have some > value for best-effort LSPs. (The draft was concerned with TE LSPs.) We > could support such "spreading" by adding a special link value or bit to > indicated that the label should be made available on all PSC (packet) > links of a bundle/bond. (The spreading algorithm need not be > standardized for this case.) >Lou I was talking about TE LSPs--in particular, TE LSPs whose capacity is greater than the fastest physical link. Having that kind of LSP greatly simplifies the scaling and resiliency of TE. You can widen the bundle at any hop without having to thread new LSPs to use it. You can, for example, increase the capacity of an existing LSP without regard to the elements of bundles that it traverses. It seems possible to simplify not only the IGP topology, but also to collapse the strands of TE LSPs, with Bora's bundling model. --Greg W., Avici Systems >At 06:20 PM 7/10/00 -0400, Greg Waters wrote: >>Lou, you're getting warm. You suggest that option (1) is not good for >>MPLamdaS, perhaps because you assume that a given LSP's packets appear on >>a single link during bundled operation? I read you as thinking that a >>label goes to waste on all but one link in the bundle, in option (1). >> >>Bora's model, which I find valuable, is to allow one or more suitable >>IPv4-bearing and IPv6-bearing LSPs to appear simultaneously, >>load-balanced, on all links within a bundle. The traffic volume within >>each LSP is irrelevant to the load balancing, unlike Kireeti's model. As >>with some link aggregation methods, the load-balancing uses IPv4/v6 >>address hashing, or another technique that maintains order within each >>microflow. Given a rich hash in relation to the bundle size, it does not >>matter what hashing algorithm each hop uses. >> >>The benefit: A "best-effort" or "premium" Internet LSP can be configured >>with a capacity ten times larger than one's fastest physical link. I >>won't suggest that this major benefit extends to "CBR LSPs" of a kind >>which don't tolerate burstiness and which defy good load-balancing. >> >>Recent demos showed that Bora's model works over optical switches in >>which all traffic on the fibers in one bundle are switched to as many >>fibers in another bundle. I suppose that falls short of the MPLamdaS >>requirements, of which I confess ignorance. --Greg W., Avici Systems >> >>At 05:26 PM 7/10/00 -0400, Lou Berger wrote: >>>Bora, >>>There is a difference specific to MPLS, i.e., both sides of a link need >>>to agree on the label. You only briefly mentioned this key point in >>>your mail. I believe the choices open to synchronize labels over >>>bundled/bonded links are: >>> 1. Allow the receipt of each label over any/all links in the bundle. >>> This is essentially the equivalent of what's done for IP. >>> This approach just doesn't work for non-packet links (MPLamdaS). >>> >>> 2. The link is selected algorithmically (per your message) >>> Some algorithm would need to be standardized. An algorithmic >>> approach is likely to either be artificially limiting (by not >>> taking into account allocations or loading) or so complex that >>> it's prone to error. >>> >>> 3. Have the underlying layer signals the link. >>> This can be done using some or some lower level signaling protocol >>> (such as LMP.) >>> >>> 4. Have MPLS signaling just provide the link information. >>> This is what's documented in the draft. It does mean that signaling >>> needs to convey link information, but it allows greater flexibility >>> than an algorithmic approach and doesn't require the use of yet >>> another signaling protocol to setup each LSP. >>> >>> Note: In this case, the underlying layer can still pick the link, >>> it's just transported by signaling, much like RSVP opaquely >>> carries int-serv information. There's no problem if you want to >>> use your hash, or if someone else wants to use more dynamic >>> information. >>> >>> Also, the draft doesn't require that routing and IP understand the >>> component links (they can operate on aggregated information). >>> We can certainly alter the text to make all this more explicit. >>> >>>It seems to me that much of your objection is really based on that link >>>selection is dynamic rather than algorithmic and that the draft isn't >>>explicit about routing, IP and even signaling not needing to understand >>>the specifics of the component links. Is this correct? >>>Lou >>> >>>At 11:38 AM 7/7/00 -0700, Bora Akyol wrote: >>>>George, Yakov, et al., >>>> >>>>I do not think that this internet draft should be adopted as an MPLS >>>>working group document. My primary objection to this document is the fact >>>>that bundling of L1/L2 interfaces has nothing specific to do with MPLS. >>>>In fact, this is an L2 abstraction that should be completely transparent >>>>to MPLS, IP or ISIS. I feel that this particular draft is very focused on >>>>MPLS-specific concerns and does not provide a good abstraction of the L2 >>>>bundling aspects and also places significant restrictions on what can be >>>>done with a bundled link and what kind of members it can have. >>>> >>>>I personally know of at least one implementation (ours) of bundled links >>>>that forms such an abstraction to all upper layer protocols. In this >>>>implementation, a heterogeneous group of L1/L2 interfaces are bonded >>>>together at L2 NCP layer such that IP NCP, MPLS NCP, ISIS NCP treats the >>>>bundled (bonded) interface as just another type of interface. When MPLS >>>>RSVP messages are passed over the bundled interface, the labels that are >>>>assigned are programmed into all members of the bundled links even though >>>>in reality a hash is used so that only one of the members are used (to >>>>prevent reordering). Bandwidth management is handled by means of the >>>>apriori knowledge of the hash. Also note that this particular >>>>implementation is not MLPPP since no additional headers are added to the >>>>packets. >>>>For MPLS specific concerns, the methods that are used in this approach >>>>can be expanded. For IP, this particular approach works very well. >>>> >>>>If there is interest from the MPLS WG, we (myself and another colleague) >>>>would be perfectly willing to author an Internet Draft on this particular >>>>bond implementation. The question that I have is what is the proper forum >>>>to submit a generalized layer 2 bundling draft in the IETF. It is >>>>certainly relevant to MPLS, but it is just as relevant to IP, ISIS, etc. >>>>Regards >>>>Bora Akyol >>>> >>>>George Swallow wrote: >>>> > > Folks, >>>> > > Kireeti and myself would like to ask the MPLS WG to >>>> > > accept draft-kompella-mpls-bundle-01.txt as an >>>> > > MPLS WG document. >>>> > > Yakov. >>>> > >>>> > Consensus on this will be assessed on 7/12. Opinions should be aired >>>> > by then. >>>> > ...George Swallow From owner-mpls@UU.NET Tue Jul 11 09:57: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 JAA00811 for ; Tue, 11 Jul 2000 09:57:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixjr08492; Tue, 11 Jul 2000 13:57:31 GMT Received: by mail-control.mail.uu.net id QQixjr29570 for mpls-outgoing; Tue, 11 Jul 2000 13:57: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 QQixjr29563 for ; Tue, 11 Jul 2000 13:56: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 QQixjr21216 for ; Tue, 11 Jul 2000 09:56:26 -0400 (EDT) Received: from smtprch2.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtprch2.nortelnetworks.com [192.135.215.15]) id QQixjr23445 for ; Tue, 11 Jul 2000 13:56:25 GMT Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Tue, 11 Jul 2000 08:50:28 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Jul 2000 08:53:39 -0500 Message-ID: <03E3E0690542D211A1490000F80836F4029F97F9@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'Alex Zinin'" Cc: mpls Subject: RE: draft-ietf-mpls-te-feed-00.txt Date: Tue, 11 Jul 2000 08:53:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEB3F.6A748974" 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_01BFEB3F.6A748974 Content-Type: text/plain; charset="ISO-8859-1" Fair enough, I'll make the changes and reissue a new version of the document. Peter -----Original Message----- From: Alex Zinin [SMTP:azinin@cisco.com] Sent: Monday, July 10, 2000 1:34 PM To: Ashwood-Smith, Peter [CAR:CS57:EXCH] Cc: mpls Subject: Re: draft-ietf-mpls-te-feed-00.txt Peter, You have several places in the document that explicitly speak about LSDB modification. Some examples below. I think this should be changed to something more neutral. > constructed. Eventually this message arrives back at the source > node, where the vector is taken and inserted into the topology > database. This node has just learned from its mistake and is now > When the LDP session that originated a CR-LDP label request receives > a notification that contains feedback TLV's it is recommended that > these bandwidth values overwrite the corresponding values in the > nodes topology database. Doing so permits this node to immediately Thanks, -- Alex Zinin Monday, July 10, 2000, 7:15 AM, Peter Ashwood-Smith wrote: > Alex, > Thanks for the comments. The thing to keep in mind here is that how an > implementation chooses to store the feedback information is not really part > of the draft, and does not need to be standardized. The important point is > that you receive feedback and you use that feedback information in > subsequent computations until you get another LSA. There are a variety of > different ways to accomplish this but probably the easiest is to store > feedback information separately from flooded information. In any case, fed > back information is never re-flooded, only the originator can flood its > bandwidth information. > If however you would prefer that I add a sentence or two to make this > more clear I will be happy to do so if you want to send me something. > Cheers, > Peter > -----Original Message----- > From: Alex Zinin [SMTP:azinin@cisco.com] > Sent: Monday, July 10, 2000 1:59 AM > To: mpls > Subject: draft-ietf-mpls-te-feed-00.txt > Peter, et al. > In your draft you recommend to change the contents > of IGP's LSDB whenever the feedback from the signaling > component is received. I'm afraid it is not quite good. > 1. If the checksum of the LSA/LSP is not recalculated > after the contents were changed, the IGP may report > a fatal error if the checksum is verified before > the next version of the LSA/LSP arrives. > 2. Recalculating the checksum is also wrong, because: > a) only the originating router must do this > b) if this is done by other routers it may affect > LSA/LSP version comparison algo. > Because of the above and because it is a 'bad thing' to > modify link-state PDUs originated by others, I think it > is safer and makes some more sense to say that implementations > must account for a method to link the information provided > by the signaling component to the corresponding elements > of the TE database, instead of overwriting it. > Cheers, > -- > Alex Zinin ------_=_NextPart_001_01BFEB3F.6A748974 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-mpls-te-feed-00.txt

    Fair enough,

    I'll make the = changes and reissue a new version of the document.

    Peter

    -----Original = Message-----
    From:   Alex Zinin = [SMTP:azinin@cisco.com]
    Sent:   Monday, July 10, 2000 1:34 PM
    To:     Ashwood-Smith, Peter [CAR:CS57:EXCH]
    Cc:     mpls
    Subject:       = Re: = draft-ietf-mpls-te-feed-00.txt


    Peter,

    You have several places in the = document that explicitly speak
    about LSDB modification. Some = examples below.
    I think this should be changed to = something more neutral.

    >    constructed. = Eventually this message arrives back at the source
    >    node, where = the vector is taken and inserted into the topology
    >    database. This = node has just learned from its mistake and is now

    >    When the LDP = session that originated a CR-LDP label request receives
    >    a notification = that contains feedback TLV's it is recommended that
    >    these = bandwidth values overwrite the corresponding values in the
    >    nodes topology = database. Doing so permits this node to immediately

    Thanks,

    --
    Alex Zinin


    Monday, July 10, 2000, 7:15 AM, Peter = Ashwood-Smith <petera@nortelnetworks.com> wrote:

    >    Alex,

    >    Thanks for the = comments. The thing to keep in mind here is that how an
    > implementation chooses to store = the feedback information is not really part
    > of the draft, and does not need = to be standardized. The important point is
    > that you receive feedback and = you use that feedback information in
    > subsequent computations until = you get another LSA. There are a variety of
    > different ways to accomplish = this but probably the easiest is to store
    > feedback information separately = from flooded information. In any case, fed
    > back information is never = re-flooded, only the originator can flood its
    > bandwidth information.

    >     If = however you would prefer that I add a sentence or two  to make = this
    > more clear I will be happy to do = so if you want to send me something.

    >     = Cheers,

    >     = Peter

    >         = -----Original Message-----
    >         = From:   Alex Zinin [SMTP:azinin@cisco.com]
    >         = Sent:   Monday, July 10, 2000 1:59 AM
    >         = To:     mpls
    >         = Subject:        = draft-ietf-mpls-te-feed-00.txt


    >         = ;  Peter, et al.

    >         = ;  In your draft you recommend to change the contents
    >         = ;  of IGP's LSDB whenever the feedback from the signaling
    >         = ;  component is received. I'm afraid it is not quite good.

    >         = ;  1. If the checksum of the LSA/LSP is not recalculated
    >         = ;     after the contents were changed, the IGP may = report
    >         = ;     a fatal error if the checksum is verified = before
    >         = ;     the next version of the LSA/LSP = arrives.

    >         = ;  2. Recalculating the checksum is also wrong, because:

    >         = ;      a) only the originating router must do = this

    >         = ;      b) if this is done by other routers it = may affect
    >         = ;         LSA/LSP version = comparison algo.

    >         = ;  Because of the above and because it is a 'bad thing' to
    >         = ;  modify link-state PDUs originated by others, I think it
    >         = ;  is safer and makes some more sense to say that = implementations
    >         = ;  must account for a method to link the information = provided
    >         = ;  by the signaling component to the corresponding elements
    >     &nbs= p;     of the TE database, instead of overwriting = it.

    >         = ;  Cheers,
              =
    >         -- =
    >         = Alex Zinin

------_=_NextPart_001_01BFEB3F.6A748974-- From owner-mpls@UU.NET Tue Jul 11 11:04: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 LAA03281 for ; Tue, 11 Jul 2000 11:04:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixjw05965; Tue, 11 Jul 2000 15:04:07 GMT Received: by mail-control.mail.uu.net id QQixjw24463 for mpls-outgoing; Tue, 11 Jul 2000 15:03: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 QQixjw24286 for ; Tue, 11 Jul 2000 15:03: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 QQixjw06202 for ; Tue, 11 Jul 2000 11:03:05 -0400 (EDT) Received: from xaloc.upc.es by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: xaloc.upc.es [147.83.105.131]) id QQixjw11657 for ; Tue, 11 Jul 2000 15:02:30 GMT Received: from estos.upc.es (caldes.upc.es [147.83.106.78]) by xaloc.upc.es (8.9.1/8.9.1) with ESMTP id PAA20852; Tue, 11 Jul 2000 15:11:42 +0200 (METDST) Message-ID: <396B27F2.76EFAE8@estos.upc.es> Date: Tue, 11 Jul 2000 14:58:11 +0100 From: Juan Diego Otero Organization: UPC (Universitat =?iso-8859-1?Q?Polit=E8cnica?= de Catalunya) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: mpls@UU.NET Subject: Re: MPLS TE and Constraint Based Routing References: <1924.000709@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Alex Zinin wrote: > Rajiv, > > [...] > > You can probably use off-line tools for path computation but sometimes > > the off-line tools do not scale well with the network size > > Can you elaborate on the scaling comment a bit? Alex, I'm not Rajiv but I think the problem is that if there is a server that computates ALL the CBR paths in the network, and this network is quite big, we have two problems: 1. The server has a lot of proccessing work (maybe this is not a big problem). 2. Every device in the network has to inform the server its available resources, and the server has to download the CBR routes to all the routers in the networks. The server links may be congestioned. Cheers!! Diego Otero. From owner-mpls@UU.NET Tue Jul 11 11:27: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 LAA04250 for ; Tue, 11 Jul 2000 11:27:11 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixjx17892; Tue, 11 Jul 2000 15:27:12 GMT Received: by mail-control.mail.uu.net id QQixjx03190 for mpls-outgoing; Tue, 11 Jul 2000 15:26: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 QQixjx03178 for ; Tue, 11 Jul 2000 15:26: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 QQixjx10843 for ; Tue, 11 Jul 2000 11:26:25 -0400 (EDT) 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 QQixjx17102 for ; Tue, 11 Jul 2000 15:26:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA29225 for mpls@uu.net; Tue, 11 Jul 2000 11:26:08 -0400 (EDT) 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 QQixjx02927 for ; Tue, 11 Jul 2000 15:25: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 QQixjx07632 for ; Tue, 11 Jul 2000 11:24:02 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQixjx13021 for ; Tue, 11 Jul 2000 15:24:01 GMT Received: from localhost (ssh.cisco.com [171.69.10.34]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA04666; Tue, 11 Jul 2000 08:23:13 -0700 (PDT) Date: Tue, 11 Jul 2000 08:18:18 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <18346.000711@cisco.com> To: Juan Diego Otero CC: mpls@UU.NET Subject: Re: MPLS TE and Constraint Based Routing In-reply-To: <396B27F2.76EFAE8@estos.upc.es> References: <396B27F2.76EFAE8@estos.upc.es> 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 Juan, Thanks for your comments. See below. > Alex, I'm not Rajiv but I think the problem is that if there is a server that > computates ALL > the CBR paths in the network, and this network is quite big, > we have two problems: > 1. The server has a lot of proccessing work (maybe this is not a big problem). Makes sense to me. Complexity may be really high... depends on how the optimization problem is stated and solved. It shouldn't be a problem, however, since the tool is *off*-line and huge delays are expected. > 2. Every device in the network has to inform the server its available > resources, this does not seem to be an issue to me, we have this working with on-line calculations. > and the server has to download the CBR routes to all the routers > in the networks. Hmmm... I'd say only to head-ends that then use the signaling protocol to install the LSPs. Alex. > The server links may be congestioned. > Cheers!! > Diego Otero. From owner-mpls@UU.NET Tue Jul 11 14:05: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 OAA12664 for ; Tue, 11 Jul 2000 14:05:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixki13427; Tue, 11 Jul 2000 18:05:43 GMT Received: by mail-control.mail.uu.net id QQixki22989 for mpls-outgoing; Tue, 11 Jul 2000 18:05:12 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQixki22984 for ; Tue, 11 Jul 2000 18:05:02 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixki06244 for ; Tue, 11 Jul 2000 14:04:16 -0400 (EDT) Received: from mx2.tellabs.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQixki11415 for ; Tue, 11 Jul 2000 18:04:00 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id NAA04242; Tue, 11 Jul 2000 13:02:35 -0500 (CDT) 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 NAA17471; Tue, 11 Jul 2000 13:02:48 -0500 (CDT) Received: by localhost with Microsoft MAPI; Tue, 11 Jul 2000 14:07:37 -0400 Message-ID: <01BFEB41.5DE60320.Vishal.Sharma@tellabs.com> From: Vishal Sharma Reply-To: "Vishal.Sharma@tellabs.com" To: "'mpls@uu.net'" Cc: "Bora Akyol (E-mail)" , "'neil.2.harrison@bt.com'" , "'dallan@nortelnetworks.com'" , "'GFrank@zaffire.com'" , "'Shahram_Davari@pmc-sierra.com'" , "Ben Mack-Crane (E-mail)" Cc: "Chang Huang (E-mail)" , "Ken Owens (E-mail)" , "Srinivas Makam (E-mail)" Subject: Two new protection/recovery drafts: Comments Date: Tue, 11 Jul 2000 14:07:35 -0400 Organization: Tellabs Research Center X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, We have submitted two drafts on path protection to the Internet Drafts Directory. The first is a revision of the draft that we'd presented in Adelaide, and incorporates comments we received on the list and in private. 1) draft-chang-mpls-path-protecton-01.txt A Path Protection/Restoration Mechanism for MPLS Networks. (This was submitted yesterday, and it may take another day to show up on the IETF drafts repository.) The second is a draft on extensions to RSVP-TE to implement the mechanism described in the above draft. 2) draft-chang-mpls-rsvpte-path-protection-ext-00.txt Extensions to RSVP-TE for MPLS Path Protection Available at: http://search.ietf.org/internet-drafts/draft-chang-mpls-rsvpte-path-protection-ext-00.txt We look forward to receiving further WG feedback on these contributions, as we look towards Pittsburgh. Thanks, -Vishal From owner-mpls@UU.NET Tue Jul 11 14:23: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 OAA13900 for ; Tue, 11 Jul 2000 14:23:30 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixkj24030; Tue, 11 Jul 2000 18:23:21 GMT Received: by mail-control.mail.uu.net id QQixkj24523 for mpls-outgoing; Tue, 11 Jul 2000 18:22: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 QQixkj24507 for ; Tue, 11 Jul 2000 18:22: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 QQixkj14264 for ; Tue, 11 Jul 2000 14:22:39 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQixkj23149 for ; Tue, 11 Jul 2000 18:22:09 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id NAA11252; Tue, 11 Jul 2000 13:21:42 -0500 Message-Id: <4.3.2.7.2.20000711135830.00bb25b0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Jul 2000 14:22:21 -0400 To: Greg Waters From: Lou Berger Subject: Re: Link Bundling Cc: Lou Berger , Bora Akyol , George Swallow , mpls@UU.NET In-Reply-To: <4.3.1.2.20000711081943.00b6c740@mailhost.avici.com> References: <4.3.2.7.2.20000710194056.00baf100@mail.labn.net> <4.3.1.2.20000710174453.00b6cc20@mailhost.avici.com> <4.3.2.7.2.20000710081826.00b74ec0@mail.labn.net> <396623BB.5C1282B9@pluris.com> <200007052142.RAA14677@lir.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 08:35 AM 7/11/00 -0400, Greg Waters wrote: >At 07:48 PM 7/10/00 -0400, Lou Berger wrote: >>Greg, >> You are correct, spreading a single LSP over multiple component >> links is not supported in the bundle draft. I agree this could have >> some value for best-effort LSPs. (The draft was concerned with TE >> LSPs.) We could support such "spreading" by adding a special link value >> or bit to indicated that the label should be made available on all PSC >> (packet) links of a bundle/bond. (The spreading algorithm need not be >> standardized for this case.) >>Lou > >I was talking about TE LSPs--in particular, TE LSPs whose capacity is >greater than the fastest physical link. Having that kind of LSP greatly >simplifies the scaling and resiliency of TE. You can widen the bundle at >any hop without having to thread new LSPs to use it. You can, for >example, increase the capacity of an existing LSP without regard to the >elements of bundles that it traverses. I may be wrong (since I of course can't speak for anyone else) but, I don't think any of us would argue that allowing LSPs to span multiple links is worth investigating. That said, I do feel that we should get the simple, 1 link/LSP, solution out there without having it wait for the harder to standardize, n-links/LSP, solution. >It seems possible to simplify not only the IGP topology, but also to >collapse the strands of TE LSPs, with Bora's bundling model. This statement confuses me. I believe the necessary topology information is the same in either approach. Lou > --Greg W., Avici Systems >[...] From owner-mpls@UU.NET Tue Jul 11 14:30: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 OAA14190 for ; Tue, 11 Jul 2000 14:30:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixkk28984; Tue, 11 Jul 2000 18:30:05 GMT Received: by mail-control.mail.uu.net id QQixkj24944 for mpls-outgoing; Tue, 11 Jul 2000 18:29: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 QQixkj24939 for ; Tue, 11 Jul 2000 18:29:39 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixkj10646 for ; Tue, 11 Jul 2000 14:28:08 -0400 (EDT) Received: from devmail.dev.tivoli.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: devmail.dev.tivoli.com [208.230.244.136]) id QQixkj12567 for ; Tue, 11 Jul 2000 18:27:53 GMT Received: from madev-dns.ma.dev.tivoli.com (madev-dns.ma.dev.tivoli.com [146.84.242.19]) by devmail.dev.tivoli.com (8.9.1/8.8.8) with ESMTP id NAA05366 for ; Tue, 11 Jul 2000 13:27:52 -0500 (CDT) Received: from ptasillo (ptasillo.ma.dev.tivoli.com [146.84.242.70]) by madev-dns.ma.dev.tivoli.com (8.8.8/8.8.8) with SMTP id OAA18887 for ; Tue, 11 Jul 2000 14:29:37 -0400 (EDT) From: "Paul Tasillo" To: Subject: FW: in-segment/out-segment status? Date: Tue, 11 Jul 2000 14:28:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Can someone expain the reasoning behind removing the admin/oper status from the in-segment/out-segment tables in the recent draft of the "MPLS Label Switch Router Management Information Base Using SMIv2"? It would seem that with only status information in the XC table, the granilarity of LSP control/managment very coarse. If you wanted to shut off a LSP between two LSRs, you would set the appropriate XC table value to admin down, but if anyother LSP shared this XC table entry then it would also be shut off. I had thought (perhaps incorrectly) that people might want to know the hop by hop status of LSP and that the status of a given LSP between two LSRs Ra and Rb would depend on the oper/admin status of the out-segment table entry on Ra and the in-segment table entry on Rb. Granted as a whole the LSP won't function unless the XC table entries are also 'up', but hop-by-hop basis the status seems dependant on the status information tied to the ends of the segments (in/out). Thanks in advance, Paul Tasillo Tivoli Systems From owner-mpls@UU.NET Tue Jul 11 14:32: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 OAA14342 for ; Tue, 11 Jul 2000 14:32:06 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixkk17635; Tue, 11 Jul 2000 18:31:59 GMT Received: by mail-control.mail.uu.net id QQixkk25191 for mpls-outgoing; Tue, 11 Jul 2000 18:31: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 QQixkk25148 for ; Tue, 11 Jul 2000 18:31: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 QQixkk16185 for ; Tue, 11 Jul 2000 14:31:16 -0400 (EDT) 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 QQixkk16376 for ; Tue, 11 Jul 2000 18:31:15 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA26795 for mpls@uu.net; Tue, 11 Jul 2000 14:31:15 -0400 (EDT) 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 QQixkk25019 for ; Tue, 11 Jul 2000 18:30: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 QQixkk16082 for ; Tue, 11 Jul 2000 14:30:47 -0400 (EDT) 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 QQixkk15709 for ; Tue, 11 Jul 2000 18:30:45 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA26762; Tue, 11 Jul 2000 11:29:13 -0700 (PDT) Message-Id: <200007111829.LAA26762@omega.cisco.com> To: Lou Berger cc: Greg Waters , Bora Akyol , George Swallow , mpls@UU.NET Subject: Re: Link Bundling In-reply-to: Your message of "Tue, 11 Jul 2000 14:22:21 EDT." <4.3.2.7.2.20000711135830.00bb25b0@mail.labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26759.963340140.1@cisco.com> Date: Tue, 11 Jul 2000 11:29:01 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Lou, > At 08:35 AM 7/11/00 -0400, Greg Waters wrote: > >At 07:48 PM 7/10/00 -0400, Lou Berger wrote: > >>Greg, > >> You are correct, spreading a single LSP over multiple component > >> links is not supported in the bundle draft. I agree this could have > >> some value for best-effort LSPs. (The draft was concerned with TE > >> LSPs.) We could support such "spreading" by adding a special link value > >> or bit to indicated that the label should be made available on all PSC > >> (packet) links of a bundle/bond. (The spreading algorithm need not be > >> standardized for this case.) > >>Lou > > > >I was talking about TE LSPs--in particular, TE LSPs whose capacity is > >greater than the fastest physical link. Having that kind of LSP greatly > >simplifies the scaling and resiliency of TE. You can widen the bundle at > >any hop without having to thread new LSPs to use it. You can, for > >example, increase the capacity of an existing LSP without regard to the > >elements of bundles that it traverses. > > I may be wrong (since I of course can't speak for anyone else) but, I don't > think any of us would argue that allowing LSPs to span multiple links is > worth investigating. That said, I do feel that we should get the simple, 1 > link/LSP, solution out there without having it wait for the harder to > standardize, n-links/LSP, solution. For some types of links (e.g., links between OXCs) n-links/LSP solution is just not feasible (due to the nature of the links). And we certainly need to have a solution for such links. Yakov. From owner-mpls@UU.NET Tue Jul 11 14:53: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 OAA15664 for ; Tue, 11 Jul 2000 14:53:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixkl22123; Tue, 11 Jul 2000 18:53:20 GMT Received: by mail-control.mail.uu.net id QQixkl27314 for mpls-outgoing; Tue, 11 Jul 2000 18:52:59 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 QQixkl27302 for ; Tue, 11 Jul 2000 18:52: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 QQixkl20680 for ; Tue, 11 Jul 2000 14:52:39 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQixkl00181 for ; Tue, 11 Jul 2000 18:52:39 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA06902 for ; Tue, 11 Jul 2000 11:52:51 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA18715 for mpls@uu.net; Tue, 11 Jul 2000 14:52:32 -0400 (EDT) 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 QQixkl26530 for ; Tue, 11 Jul 2000 18:47: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 QQixkl19379 for ; Tue, 11 Jul 2000 14:47:04 -0400 (EDT) Received: from lumen.chromisys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.55.200]) id QQixkl26902 for ; Tue, 11 Jul 2000 18:46:49 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2448.0) id <33V04W45>; Tue, 11 Jul 2000 11:46:48 -0700 Message-ID: From: John Drake To: "'Yakov Rekhter'" , Lou Berger Cc: Greg Waters , Bora Akyol , George Swallow , mpls@UU.NET Subject: RE: Link Bundling Date: Tue, 11 Jul 2000 11:46:44 -0700 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 exactly -----Original Message----- From: Yakov Rekhter [mailto:yakov@cisco.com] Sent: Tuesday, July 11, 2000 11:29 AM To: Lou Berger Cc: Greg Waters; Bora Akyol; George Swallow; mpls@UU.NET Subject: Re: Link Bundling Lou, > At 08:35 AM 7/11/00 -0400, Greg Waters wrote: > >At 07:48 PM 7/10/00 -0400, Lou Berger wrote: > >>Greg, > >> You are correct, spreading a single LSP over multiple component > >> links is not supported in the bundle draft. I agree this could have > >> some value for best-effort LSPs. (The draft was concerned with TE > >> LSPs.) We could support such "spreading" by adding a special link value > >> or bit to indicated that the label should be made available on all PSC > >> (packet) links of a bundle/bond. (The spreading algorithm need not be > >> standardized for this case.) > >>Lou > > > >I was talking about TE LSPs--in particular, TE LSPs whose capacity is > >greater than the fastest physical link. Having that kind of LSP greatly > >simplifies the scaling and resiliency of TE. You can widen the bundle at > >any hop without having to thread new LSPs to use it. You can, for > >example, increase the capacity of an existing LSP without regard to the > >elements of bundles that it traverses. > > I may be wrong (since I of course can't speak for anyone else) but, I don't > think any of us would argue that allowing LSPs to span multiple links is > worth investigating. That said, I do feel that we should get the simple, 1 > link/LSP, solution out there without having it wait for the harder to > standardize, n-links/LSP, solution. For some types of links (e.g., links between OXCs) n-links/LSP solution is just not feasible (due to the nature of the links). And we certainly need to have a solution for such links. Yakov. From owner-mpls@UU.NET Tue Jul 11 14:59: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 OAA15895 for ; Tue, 11 Jul 2000 14:59:19 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixkl01588; Tue, 11 Jul 2000 18:59:13 GMT Received: by mail-control.mail.uu.net id QQixkl27926 for mpls-outgoing; Tue, 11 Jul 2000 18:58:39 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 QQixkl27913 for ; Tue, 11 Jul 2000 18:58:28 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 QQixkl21726 for ; Tue, 11 Jul 2000 14:58:17 -0400 (EDT) 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 QQixkl02675 for ; Tue, 11 Jul 2000 18:57:46 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA01948 for mpls@uu.net; Tue, 11 Jul 2000 14:57:45 -0400 (EDT) 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 QQixkl27780 for ; Tue, 11 Jul 2000 18:57:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixkl16298 for ; Tue, 11 Jul 2000 14:56:32 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQixkl01825 for ; Tue, 11 Jul 2000 18:56:17 GMT Received: from localhost (ssh.cisco.com [171.69.10.34]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA26221; Tue, 11 Jul 2000 11:55:09 -0700 (PDT) Date: Tue, 11 Jul 2000 11:50:13 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <8493.000711@cisco.com> To: Yakov Rekhter CC: Lou Berger , Greg Waters , Bora Akyol , George Swallow , mpls@UU.NET Subject: Re: Link Bundling In-reply-To: <200007111829.LAA26762@omega.cisco.com> References: <200007111829.LAA26762@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >> >I was talking about TE LSPs--in particular, TE LSPs whose capacity is >> >greater than the fastest physical link. Having that kind of LSP greatly >> >simplifies the scaling and resiliency of TE. You can widen the bundle at >> >any hop without having to thread new LSPs to use it. You can, for >> >example, increase the capacity of an existing LSP without regard to the >> >elements of bundles that it traverses. >> >> I may be wrong (since I of course can't speak for anyone else) but, I don't >> think any of us would argue that allowing LSPs to span multiple links is >> worth investigating. That said, I do feel that we should get the simple, 1 >> link/LSP, solution out there without having it wait for the harder to >> standardize, n-links/LSP, solution. > For some types of links (e.g., links between OXCs) n-links/LSP solution > is just not feasible (due to the nature of the links). And we certainly > need to have a solution for such links. As well as the whole thing about LSPs capacity loses its meaning in the optical context... The idea of spanning an LSP among multiple links is elegant, I think. However, the last thing we need to achieve is packet reordering and this means we need a flow-aware mechanism to be implemented on top of MPLS switching engine, which is not a problem per se, but will indeed require some more work. Alex. > Yakov. From owner-mpls@UU.NET Tue Jul 11 15:17: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 PAA16693 for ; Tue, 11 Jul 2000 15:17:02 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixkn12536; Tue, 11 Jul 2000 19:16:54 GMT Received: by mail-control.mail.uu.net id QQixkn11451 for mpls-outgoing; Tue, 11 Jul 2000 19:16: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 QQixkn11428 for ; Tue, 11 Jul 2000 19:16:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixkm19504 for ; Tue, 11 Jul 2000 15:12:56 -0400 (EDT) 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 QQixkm10034 for ; Tue, 11 Jul 2000 19:12:41 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA04494 for mpls@uu.net; Tue, 11 Jul 2000 15:12:40 -0400 (EDT) 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 QQixkm10693 for ; Tue, 11 Jul 2000 19:12:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixkm24380 for ; Tue, 11 Jul 2000 15:11:54 -0400 (EDT) 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 QQixkm09569 for ; Tue, 11 Jul 2000 19:11:38 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA06769; Tue, 11 Jul 2000 15:11:29 -0400 (EDT) Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-185.cisco.com [161.44.134.185]) by bucket.cisco.com (Mirapoint) with ESMTP id AAA60065; Tue, 11 Jul 2000 15:15:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20000711145744.0521f150@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Jul 2000 15:01:28 -0400 To: "Paul Tasillo" , From: "Thomas D. Nadeau" Subject: Re: FW: in-segment/out-segment status? Cc: Cheenu Srinivasan , arun@force10networks.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Paul, >Can someone expain the reasoning behind removing the admin/oper status from >the in-segment/out-segment tables in the recent draft of the "MPLS Label >Switch Router Management Information Base Using SMIv2"? These were removed primarily because of requests from the WG during the two last call periods. The reasoning was that they were not very useful. --Tom From owner-mpls@UU.NET Tue Jul 11 15:23: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 PAA16936 for ; Tue, 11 Jul 2000 15:23:55 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixkn05742; Tue, 11 Jul 2000 19:23:51 GMT Received: by mail-control.mail.uu.net id QQixkn12304 for mpls-outgoing; Tue, 11 Jul 2000 19:23:15 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQixkn12288 for ; Tue, 11 Jul 2000 19:23:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixkn26471 for ; Tue, 11 Jul 2000 15:23:03 -0400 (EDT) Received: from zrtps06s.us.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [47.140.48.50]) id QQixkn15915 for ; Tue, 11 Jul 2000 19:22:28 GMT Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 11 Jul 2000 15:18:18 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Jul 2000 15:18:13 -0400 Message-ID: <6DDA62170439D31185750000F80826AC031CBB58@zmerd004.ca.nortel.com> From: "David Allan" To: Andrew Bender , li.mo@fnc.fujitsu.com Cc: mpls@UU.NET Subject: RE: I-D ACTION:draft-mo-mpls-protection-00.txt Date: Tue, 11 Jul 2000 15:18:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEB6C.C0D13B5A" 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_01BFEB6C.C0D13B5A Content-Type: text/plain Andrew wrote: "If I read this correctly, there are only gains when the working and protect paths incorporate a common node; although this could happen is practice, it is not the preferred alignment." Not entirely true, it is possible to conceive a link or node failure that affects a working path for one LSP and a protection path for another LSP. An argument could be made that an optimal and omnipotent CAC would go beyond simply adding working and protection reservations together and checking against the link capacity. Whether this is a tractable compuation is another question entirely and I would suggest it is not: Such an algorithm would have to consider: - individual LSP failure - link failure - node failure - SRLG failure for every resource in the network that had any association with LSPs that transited the local node, and have the CAC algorithm consider the worst case. So one complication is that for every LSP (working or protection) that transits the local LSR, the computation needs to know all details about the protection counterpart (protection or working respectively). How can it know this? Is there not a massive synchronization problem if more than one protected LSP is being simultaneously routed across the network. (can't compute what has not completed routing yet). I would have to be convinced that "a whole lot of bandwidth" miraculously appeared as a result of this optimization before I considered mechanisms to ensure I could reasonably and usefully compute this optimization. My suspicion is that unless I am doing 1:1 global repair on "everything" (which is not somthing I would do), the bandwidth "just isn't there" and may not be there anyway. later Dave ------_=_NextPart_001_01BFEB6C.C0D13B5A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-mo-mpls-protection-00.txt

Andrew wrote:

"If I read this correctly, there = are only gains when the working and
protect paths incorporate a common = node; although this could happen is
practice, it is not the preferred = alignment."

Not entirely true, = it is possible to conceive a link or node failure that affects a = working path for one LSP and a protection path for another LSP. An = argument could be made that an optimal and omnipotent CAC would go = beyond simply adding working and protection reservations together and = checking against the link capacity.

Whether this is a = tractable compuation is another question entirely and I would suggest = it is not: Such an algorithm would have to consider:

- individual LSP = failure
- link = failure
- node = failure
- SRLG = failure
for every resource = in the network that had any association with LSPs that transited the = local node, and have the CAC algorithm consider the worst case. =

So one complication = is that for every LSP (working or protection) that transits the local = LSR, the computation needs to know all details about the protection = counterpart (protection or working respectively). How can it know this? = Is there not a massive synchronization problem if more than one = protected LSP is being simultaneously routed across the network. (can't = compute what has not completed routing yet).

I would have to be = convinced that "a whole lot of bandwidth" miraculously = appeared as a result of this optimization before I considered = mechanisms to ensure I could reasonably and usefully compute this = optimization. My suspicion is that unless I am doing 1:1 global repair = on "everything" (which is not somthing I would do), the = bandwidth "just isn't there" and may not be there = anyway.

later
Dave

------_=_NextPart_001_01BFEB6C.C0D13B5A-- From owner-mpls@UU.NET Tue Jul 11 20:21: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 UAA23967 for ; Tue, 11 Jul 2000 20:21:09 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixlh22631; Wed, 12 Jul 2000 00:21:03 GMT Received: by mail-control.mail.uu.net id QQixlh02465 for mpls-outgoing; Wed, 12 Jul 2000 00:20: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 QQixlh02456 for ; Wed, 12 Jul 2000 00:20: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 QQixlh10184 for ; Tue, 11 Jul 2000 20:18:50 -0400 (EDT) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQixlh17841 for ; Wed, 12 Jul 2000 00:18:19 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id RAA07579; Tue, 11 Jul 2000 17:18:19 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id RAA07297; Tue, 11 Jul 2000 17:17:22 -0700 (PDT) Date: Tue, 11 Jul 2000 17:17:22 -0700 (PDT) From: Kireeti Kompella Message-Id: <200007120017.RAA07297@kummer.juniper.net> To: jleu@laurelnetworks.com Subject: LSP hierarchy Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Monday, June 26, 2000, 7:43 AM, James R. Leu wrote: > Maybe this isn't a significant issues, but: > In section "4.1.2. Link ID (OSPF only)" it states: > The Link ID is set to the Router ID of the head end of FA-LSP. > Doesn't this conflict with RFC2328 Section 12.4.1. Router-LSAs: > Link type Description Link ID > __________________________________________________ > 1 Point-to-point Neighbor Router ID > link Jim, thanks for pointing this out, this is fixed in the new version; it now reads "tail end of the FA-LSP". Kireeti. From owner-mpls@UU.NET Tue Jul 11 22:27:37 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26403 for ; Tue, 11 Jul 2000 22:27:36 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixlp28928; Wed, 12 Jul 2000 02:27:32 GMT Received: by mail-control.mail.uu.net id QQixlp01609 for mpls-outgoing; Wed, 12 Jul 2000 02:27:09 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQixlp01604 for ; Wed, 12 Jul 2000 02:27:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixlp06389 for ; Tue, 11 Jul 2000 22:26:55 -0400 (EDT) Received: from cms1.etri.re.kr by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [129.254.16.11]) id QQixlp25712 for ; Wed, 12 Jul 2000 02:26:39 GMT Received: from LocalHost (extkang.etri.re.kr [129.254.197.52]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3WKX3ZRB; Wed, 12 Jul 2000 11:15:30 +0900 Message-ID: <011b01bfeba9$cf6f6e10$34c5fe81@etri.re.kr> From: "Sun-Moo Svenna Kang" To: Subject: Question Date: Wed, 12 Jul 2000 11:35:15 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0118_01BFEBF5.3F4032B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Disposition-Notification-To: "Sun-Moo Svenna Kang" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0118_01BFEBF5.3F4032B0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SG93IGNhbiBJIGNoYW5nZSBteSBzdWJzY3JpcHRpb24gZS1tYWlsIGFkZHJlc3MgPw0KDQpUaGFu a3MuDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQpTdW4tTW9vIFN2ZW5uYSBLYW5nLCBQaEQuDQpQcmluY2lwYWwg TWVtYmVyIG9mIFJlc2VhcmNoIFN0YWZmLFRlYW0gTGVhZGVyLCANCk1QTFMgUy9XIFRlYW0sRVRS SShFbGVjdHJvbmljcyBUZWxlY29tbXVuaWNhdGlvbnMgUmVzZWFyY2ggSW5zdGl0dXRlKSwgDQpQ Lk8uQm94IDEwNiwgWXVzb25nLCBUYWVqb24gMzA1LTYwMCwgVGhlIFJlcHVibGljIG9mIEtvcmVh DQpUZWwpICs4Mi00Mi04NjAtNTI5OSwgRmF4KSArODItNDItODYwLTU0NDAsIE1vYmlsZSkgKzgy LTE2LTQwNy02MjcyDQpXZWIpIGh0dHA6Ly9tcGxzMC5ldHJpLnJlLmtyL35ldHhrYW5nDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0K ------=_NextPart_000_0118_01BFEBF5.3F4032B0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MTkuNjMwNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhvdyBjYW4g SSBjaGFuZ2UgbXkgc3Vic2NyaXB0aW9uIGUtbWFpbCANCmFkZHJlc3MmbmJzcDs/PC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRoYW5rcy48L0ZPTlQ+ PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCANCnNpemU9Mj49PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTxCUj5TdW4tTW9vIA0KU3Zlbm5hIEthbmcsIFBoRC48QlI+UHJpbmNpcGFsIE1lbWJlciBvZiBS ZXNlYXJjaCBTdGFmZixUZWFtIExlYWRlciwgPEJSPk1QTFMgDQpTL1cgVGVhbSxFVFJJKEVsZWN0 cm9uaWNzIFRlbGVjb21tdW5pY2F0aW9ucyBSZXNlYXJjaCBJbnN0aXR1dGUpLCA8QlI+UC5PLkJv eCANCjEwNiwgWXVzb25nLCBUYWVqb24gMzA1LTYwMCwgVGhlIFJlcHVibGljIG9mIEtvcmVhPEJS PlRlbCkgKzgyLTQyLTg2MC01Mjk5LCBGYXgpIA0KKzgyLTQyLTg2MC01NDQwLCBNb2JpbGUpICs4 Mi0xNi00MDctNjI3MjxCUj5XZWIpIDxBIA0KaHJlZj0iaHR0cDovL21wbHMwLmV0cmkucmUua3Iv fmV0eGthbmciPmh0dHA6Ly9tcGxzMC5ldHJpLnJlLmtyL35ldHhrYW5nPC9BPjxCUj49PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0118_01BFEBF5.3F4032B0-- From owner-mpls@UU.NET Wed Jul 12 06:36: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 GAA15426 for ; Wed, 12 Jul 2000 06:36:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixmw14333; Wed, 12 Jul 2000 10:36:26 GMT Received: by mail-control.mail.uu.net id QQixmw26618 for mpls-outgoing; Wed, 12 Jul 2000 10:35:50 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQixmw26611 for ; Wed, 12 Jul 2000 10:35:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixmw12681 for ; Wed, 12 Jul 2000 06:33:11 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQixmw14210 for ; Wed, 12 Jul 2000 10:32:56 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA07586 for mpls@uu.net; Wed, 12 Jul 2000 06:32:55 -0400 (EDT) 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 QQixmw26552 for ; Wed, 12 Jul 2000 10:32:29 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixmw02972 for ; Wed, 12 Jul 2000 06:32:12 -0400 (EDT) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQixmw11963 for ; Wed, 12 Jul 2000 10:31:57 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15171; Wed, 12 Jul 2000 06:31:56 -0400 (EDT) Message-Id: <200007121031.GAA15171@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-rsvp-lsp-tunnel-06.txt Date: Wed, 12 Jul 2000 06:31:56 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Extensions to RSVP for LSP Tunnels Author(s) : D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow Filename : draft-ietf-mpls-rsvp-lsp-tunnel-06.txt Pages : 62 Date : 11-Jul-00 This document describes the use of RSVP, including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS. Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in [3]. We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rsvp-lsp-tunnel-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000711135040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-lsp-tunnel-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000711135040.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jul 12 07:45: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 HAA17356 for ; Wed, 12 Jul 2000 07:45:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixnb08310; Wed, 12 Jul 2000 11:45:44 GMT Received: by mail-control.mail.uu.net id QQixnb11371 for mpls-outgoing; Wed, 12 Jul 2000 11:45: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 QQixna11212 for ; Wed, 12 Jul 2000 11:44: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 QQixna18565 for ; Wed, 12 Jul 2000 07:40:38 -0400 (EDT) Received: from xaloc.upc.es by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: xaloc.upc.es [147.83.105.131]) id QQixna16671 for ; Wed, 12 Jul 2000 11:33:49 GMT Received: from estos.upc.es (caldes.upc.es [147.83.106.78]) by xaloc.upc.es (8.9.1/8.9.1) with ESMTP id NAA26467; Wed, 12 Jul 2000 13:31:24 +0200 (METDST) Message-ID: <396C61FF.2338ECE6@estos.upc.es> Date: Wed, 12 Jul 2000 13:18:08 +0100 From: Juan Diego Otero Organization: UPC (Universitat =?iso-8859-1?Q?Polit=E8cnica?= de Catalunya) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MPLS WG CC: jordi@esera.upc.es Subject: Problems with TE LSPs Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi,

I've been trying to establish a TE LSP between 2 Cisco 7200 routers.
 

            ********                ********
            * 7200  *-----------* 7200  *
            ********                ********                

            ----------------------------->
                           TE LSP

I've configured the routers following the configuration example present in
the Cisco document MPLS Traffic Engineering, and I have found some problems.

This is what I get:

****************************************************
7200_3#show interface tunnel 1
Tunnel1 is up, line protocol is down
  Hardware is Tunnel
  Interface is unnumbered. Using address of Loopback0
(17.17.17.17)
  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive set (10 sec)
  Tunnel source 17.17.17.17, destination 11.11.11.11
  Tunnel protocol/transport Label Switching, key disabled,
sequencing disabled
  Checksumming of packets disabled,  fast tunneling enabled
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: fifo
  Output queue 0/0, 3 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     3 packets output, 156 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
**************************************************************

The running config corresponding to the last is this:

**************************************************************
ip cef
mpls traffic-eng tunnels
cns event-service server
!
interface Loopback0
 ip address 17.17.17.17 255.255.255.255
 no ip directed-broadcast
!
interface Tunnel1
 ip unnumbered Loopback0
 no ip directed-broadcast
 tunnel destination 11.11.11.11
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng priority 1 1
 tunnel mpls traffic-eng bandwidth 100
 tunnel mpls traffic-eng path-option 1 explicit identifier 2
************************************************
If somebody has tried something similar, any comment will be very wellcome.

Well, that's all. Thanks a lot.

Diego Otero
 
 
 
 
  From owner-mpls@UU.NET Wed Jul 12 08:28: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 IAA18862 for ; Wed, 12 Jul 2000 08:28:40 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixnd07124; Wed, 12 Jul 2000 12:28:21 GMT Received: by mail-control.mail.uu.net id QQixnd25984 for mpls-outgoing; Wed, 12 Jul 2000 12:27:49 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQixnd25978 for ; Wed, 12 Jul 2000 12:27: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 QQixnd23434 for ; Wed, 12 Jul 2000 08:27:20 -0400 (EDT) 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 QQixnd05079 for ; Wed, 12 Jul 2000 12:27:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA15553 for mpls@uu.net; Wed, 12 Jul 2000 08:27:08 -0400 (EDT) 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 QQixnd25814 for ; Wed, 12 Jul 2000 12:26: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 QQixnd15834 for ; Wed, 12 Jul 2000 08:26:24 -0400 (EDT) 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 QQixnd02287 for ; Wed, 12 Jul 2000 12:25:54 GMT Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id FAA13333; Wed, 12 Jul 2000 05:25:08 -0700 (PDT) Message-ID: <396C6474.672983DE@cisco.com> Date: Wed, 12 Jul 2000 05:28:36 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan Diego Otero CC: MPLS WG , jordi@esera.upc.es Subject: Re: Problems with TE LSPs References: <396C61FF.2338ECE6@estos.upc.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Juan, Please send emails like this to mpls-deployment@cisco.com. This alias is for protocol architecture discussions not for troubleshooting vendor specifc issues or broken configurations. R. > Juan Diego Otero wrote: > > Hi, > > I've been trying to establish a TE LSP between 2 Cisco 7200 routers. > > > ******** ******** > * 7200 *-----------* 7200 * > ******** ******** > > -----------------------------> > TE LSP > > I've configured the routers following the configuration example > present in > the Cisco document MPLS Traffic Engineering, and I have found some > problems. > > This is what I get: > > **************************************************** > 7200_3#show interface tunnel 1 > Tunnel1 is up, line protocol is down > Hardware is Tunnel > Interface is unnumbered. Using address of Loopback0 > (17.17.17.17) > MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation TUNNEL, loopback not set > Keepalive set (10 sec) > Tunnel source 17.17.17.17, destination 11.11.11.11 > Tunnel protocol/transport Label Switching, key disabled, > sequencing disabled > Checksumming of packets disabled, fast tunneling enabled > Last input never, output never, output hang never > Last clearing of "show interface" counters never > Queueing strategy: fifo > Output queue 0/0, 3 drops; input queue 0/75, 0 drops > 5 minute input rate 0 bits/sec, 0 packets/sec > 5 minute output rate 0 bits/sec, 0 packets/sec > 0 packets input, 0 bytes, 0 no buffer > Received 0 broadcasts, 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort > 3 packets output, 156 bytes, 0 underruns > 0 output errors, 0 collisions, 0 interface resets > ************************************************************** > > The running config corresponding to the last is this: > > ************************************************************** > ip cef > mpls traffic-eng tunnels > cns event-service server > ! > interface Loopback0 > ip address 17.17.17.17 255.255.255.255 > no ip directed-broadcast > ! > interface Tunnel1 > ip unnumbered Loopback0 > no ip directed-broadcast > tunnel destination 11.11.11.11 > tunnel mode mpls traffic-eng > tunnel mpls traffic-eng priority 1 1 > tunnel mpls traffic-eng bandwidth 100 > tunnel mpls traffic-eng path-option 1 explicit identifier 2 > ************************************************ > If somebody has tried something similar, any comment will be very > wellcome. > > Well, that's all. Thanks a lot. > > Diego Otero > > > > > From owner-mpls@UU.NET Wed Jul 12 09:35: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 JAA21846 for ; Wed, 12 Jul 2000 09:35:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixni08659; Wed, 12 Jul 2000 13:35:43 GMT Received: by mail-control.mail.uu.net id QQixni12066 for mpls-outgoing; Wed, 12 Jul 2000 13:35: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 QQixni12060 for ; Wed, 12 Jul 2000 13:35: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 QQixni26343 for ; Wed, 12 Jul 2000 09:35:12 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQixni04192 for ; Wed, 12 Jul 2000 13:34:57 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA22978 for ; Wed, 12 Jul 2000 06:35:11 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA21547 for mpls@uu.net; Wed, 12 Jul 2000 09:34:55 -0400 (EDT) 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 QQixnf27734 for ; Wed, 12 Jul 2000 12:48: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 QQixnf26089 for ; Wed, 12 Jul 2000 08:47:50 -0400 (EDT) Received: from ficon-tech.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [12.10.198.190]) id QQixnf22173 for ; Wed, 12 Jul 2000 12:47:46 GMT Received: from globespan.net (acheru.india.ficon-tech.com [172.25.1.113]) by ficon-tech.com (8.9.3/8.9.3) with ESMTP id SAA74472 for ; Wed, 12 Jul 2000 18:16:44 +0530 (IST) (envelope-from acheru@globespan.net) Message-ID: <396C6784.1B855BB9@globespan.net> Date: Wed, 12 Jul 2000 18:11:40 +0530 From: Anup Anil Cheruvathoor Organization: Globespan Inc. X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: mpls@UU.NET Subject: Some questions on VCID procedures. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I Have the following questions vis-a-vis the VCID procedures as defined in draft-ietf-mpls-vcid-atm-04: a) In case of VCID procedure how is the session Negotiation procedure handled. The draft does not talk about this at all. The confusion arises as the ATM optional parameters have to be sent to pass information like Merge capabilty, VC directionality etc. But label ranges are not required to be sent as they do not have end to end significance. So what should be done as part of session negotiation w.r.t to the initialization message? b) In case of VPID procedures, we can have a cases when multiple VP tunnels might be involved. But the VCI values have end to end significance. So they must be negotiated. But it is possible that different VPs might have different VCI ranges, how is this information conveyed during the Session Negotiation procedures as defined by the LDP draft. c) The VCID draft does not explicitly say that VCID should be sent in label request message. In all cases except one VCID Request ID would suffice, other than the outband in which GIT is used. In this case as there is no VCID Request ID, as UNI does not have it, VCID TLV is mandatory. So can we assume that VCID TLV would be passed in this case. So should VCID TLV be sent in all the label requests using VCID procedures. d) No where in the draft is it explicitly told that in the label request , the VCID message ID is passed as an TLV. Is the VCID TLV passed as an optional VCID message TLV as defined in u'r draft and not as the message ID in the label request Message? e) In case of VPID, when does the VPID procedures start as such? after the session gets operational. This would mean till the procedures are not over at both the ends, the LSPs can't be set up. Am I correct? f) In case of VPID procedures, does the VPID proposal Ack arrive in the LDP VC or the VP for which the procedure is being done. Thanks in advance for the reply. Regardx, -Cheru -- Name : Anup Anil Chervathoor E-mail : mailto:acheru@globespan.net Web : www.globespan.net From owner-mpls@UU.NET Wed Jul 12 10:53: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 KAA25699 for ; Wed, 12 Jul 2000 10:53:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixnn07847; Wed, 12 Jul 2000 14:52:57 GMT Received: by mail-control.mail.uu.net id QQixnn29289 for mpls-outgoing; Wed, 12 Jul 2000 14:52: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 QQixnn29264 for ; Wed, 12 Jul 2000 14:52: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 QQixnn10993 for ; Wed, 12 Jul 2000 10:52:12 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQixnn07015 for ; Wed, 12 Jul 2000 14:51:57 GMT Received: from avici.com (swdev23.avici.com [10.1.2.229]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id KAA22881 for ; Wed, 12 Jul 2000 10:51:56 -0400 (EDT) Message-Id: <200007121451.KAA22881@mailhost.avici.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Markus Jork To: mpls@UU.NET Subject: TIME_VALUES in new RSVP-TE draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jul 2000 10:51:55 -0400 Sender: owner-mpls@UU.NET Precedence: bulk in draft-ietf-mpls-rsvp-lsp-tunnel-06.txt: The TIME_VALUES object in the Path and Resv message has now been made optional. Why is that? It's not optional in RFC 2205 for a good reason: it is needed to compute the timeout value for the path/reservation state. Markus From owner-mpls@UU.NET Wed Jul 12 11:11: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 LAA26878 for ; Wed, 12 Jul 2000 11:11:58 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixno22057; Wed, 12 Jul 2000 15:11:47 GMT Received: by mail-control.mail.uu.net id QQixno11562 for mpls-outgoing; Wed, 12 Jul 2000 15:11: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 QQixno11557 for ; Wed, 12 Jul 2000 15:11: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 QQixno19051 for ; Wed, 12 Jul 2000 11:10:10 -0400 (EDT) Received: from tenornetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQixno20488 for ; Wed, 12 Jul 2000 15:09:55 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Pro-8.9.3/Pro-8.9.3) with SMTP id LAA07324 for ; Wed, 12 Jul 2000 11:09:54 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; WED, 12 Jul 2000 11:05:02 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Jul 2000 11:05:02 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E5614F0F4@newman.tenornet.com> From: "Arvind, K" To: mpls@UU.NET Subject: in rsvp-lsp-tunnel-06 draft Date: Wed, 12 Jul 2000 11:04:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk According to the latest version of the draft: ::= | ::= []

We have established an MPLS TE Tunnel between 2
Cisco 7200 routers with RSVP as the signaling protocol.
We've made a RSVP reserve of 100 Kbit/s. I have one question:
if you don't use your BW reserved, or you just use, for
instace 25%, what happens with the unused reserved BW. It
can be used by other traffic flows? It can be used by best-effort
traffic who travels in the same links that the RSVP flows?

Thanks

Diego Otero From owner-mpls@UU.NET Fri Jul 14 08:12: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 IAA05577 for ; Fri, 14 Jul 2000 08:12:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixum06353; Fri, 14 Jul 2000 12:03:25 GMT Received: by mail-control.mail.uu.net id QQixum17484 for mpls-outgoing; Fri, 14 Jul 2000 12:03: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 QQixum17445 for ; Fri, 14 Jul 2000 12:02: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 QQixum13775 for ; Fri, 14 Jul 2000 08:02:37 -0400 (EDT) Received: from xaloc.upc.es by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: xaloc.upc.es [147.83.105.131]) id QQixum01915 for ; Fri, 14 Jul 2000 12:01:54 GMT Received: from estos.upc.es (caldes.upc.es [147.83.106.78]) by xaloc.upc.es (8.9.1/8.9.1) with ESMTP id NAA09467; Fri, 14 Jul 2000 13:51:53 +0200 (METDST) Message-ID: <396F09B3.A645FC64@estos.upc.es> Date: Fri, 14 Jul 2000 13:38:11 +0100 From: Juan Diego Otero Organization: UPC (Universitat =?iso-8859-1?Q?Polit=E8cnica?= de Catalunya) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: markk@sg.ibm.com CC: Shen Gangxiang , "'mpls@UU.NET'" , chun@ce.cnu.ac.kr Subject: Re: MPLS simulator References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit markk@sg.ibm.com wrote: > Hi, > > you can check with Woojik Chun . He mentioned > about a ns-based mpls simulator they worked on a few months back. > not sure whether they are available to the public already.. > > Rgds > -khengkok You can also try with: http://www.isi.edu/nsnam/ns/ns-other.html It is a general network simulator but I think that there are MPLS modules. Cheers! From owner-mpls@UU.NET Fri Jul 14 08:33: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 IAA10810 for ; Fri, 14 Jul 2000 08:33:10 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixun14899; Fri, 14 Jul 2000 12:24:15 GMT Received: by mail-control.mail.uu.net id QQixun28042 for mpls-outgoing; Fri, 14 Jul 2000 12:23:44 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQixun28025 for ; Fri, 14 Jul 2000 12:23:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixun16262 for ; Fri, 14 Jul 2000 08:23:27 -0400 (EDT) Received: from pooh.aist-nara.ac.jp by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: h060.p094.iij4u.or.jp [210.130.94.60]) id QQixun12284 for ; Fri, 14 Jul 2000 12:23:11 GMT Received: from localhost by pooh.aist-nara.ac.jp (8.8.7/2.8Wb) id MAA02481; Fri, 14 Jul 2000 12:23:48 GMT From: Noritoshi Demizu To: mpls@UU.NET Subject: Re: MPLS simulator Date: Fri, 14 Jul 2000 16:28:00 +0900 Message-Id: <20000714162800F.demizu@dd.iij4u.or.jp> References: X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 X-URL: http://infonet.aist-nara.ac.jp/member/nori-d/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 9 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > you can check with Woojik Chun . He mentioned > about a ns-based mpls simulator they worked on a few months back. > not sure whether they are available to the public already.. Gaeil Ahn and Woojik Chun's MPLS Network Simulator (MNS) can be found at http://www.raonet.com/mns/ Best Regards, Noritoshi Demizu From owner-mpls@UU.NET Fri Jul 14 08:43: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 IAA13454 for ; Fri, 14 Jul 2000 08:43:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixuo15824; Fri, 14 Jul 2000 12:34:40 GMT Received: by mail-control.mail.uu.net id QQixuo29310 for mpls-outgoing; Fri, 14 Jul 2000 12:34: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 QQixuo29300 for ; Fri, 14 Jul 2000 12: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 QQixuo13347 for ; Fri, 14 Jul 2000 08:33:47 -0400 (EDT) Received: from xaloc.upc.es by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: xaloc.upc.es [147.83.105.131]) id QQixuo20892 for ; Fri, 14 Jul 2000 12:33:31 GMT Received: from estos.upc.es (caldes.upc.es [147.83.106.78]) by xaloc.upc.es (8.9.1/8.9.1) with ESMTP id NAA09500; Fri, 14 Jul 2000 13:58:31 +0200 (METDST) Message-ID: <396F0B41.194EAC6F@estos.upc.es> Date: Fri, 14 Jul 2000 13:44:49 +0100 From: Juan Diego Otero Organization: UPC (Universitat =?iso-8859-1?Q?Polit=E8cnica?= de Catalunya) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: markk@sg.ibm.com CC: Shen Gangxiang , "'mpls@UU.NET'" , chun@ce.cnu.ac.kr Subject: Re: MPLS simulator References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit markk@sg.ibm.com wrote: > Hi, > > you can check with Woojik Chun . He mentioned > about a ns-based mpls simulator they worked on a few months back. > not sure whether they are available to the public already.. > > Rgds > -khengkok I am sorry, the right link is this: http://www.isi.edu/nsnam/ns/ Cheers, Diego From owner-mpls@UU.NET Fri Jul 14 09:44: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 JAA28064 for ; Fri, 14 Jul 2000 09:44:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixus01426; Fri, 14 Jul 2000 13:35:47 GMT Received: by mail-control.mail.uu.net id QQixus16950 for mpls-outgoing; Fri, 14 Jul 2000 13:35: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 QQixus16941 for ; Fri, 14 Jul 2000 13:35: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 QQixus21687 for ; Fri, 14 Jul 2000 09:35:02 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQixus00849 for ; Fri, 14 Jul 2000 13:35:02 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA10476 for ; Fri, 14 Jul 2000 06:35:10 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA29636 for mpls@uu.net; Fri, 14 Jul 2000 09:34:40 -0400 (EDT) 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 QQixth07077 for ; Fri, 14 Jul 2000 04:16:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixth21312 for ; Fri, 14 Jul 2000 00:16:05 -0400 (EDT) Received: from NOD.RESTON.MCI.NET by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [166.60.6.38]) id QQixth18066 for ; Fri, 14 Jul 2000 04:16:05 GMT Received: from BONI ([166.60.18.132]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JRQKAAQBXM9KMEJ6@shoe.reston.mci.net> for mpls@uu.net; Fri, 14 Jul 2000 00:16:04 EST Date: Fri, 14 Jul 2000 00:15:31 -0500 From: Ron Bonica Subject: RSVP security To: mpls@UU.NET Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Folks, Does anybody see any deficiencies in the current RSVP security model as it relates to MPLS? If so, does anybody think that those deficiencies are addressed by http://search.ietf.org/internet-drafts/draft-ietf-rap-rsvp-newidentity-00.tx t . =========================================== Ronald P. Bonica Ph: 703 886 1681 vBNS Engineering page: 1 888 268 8021 Ashburn, Va. =========================================== Freedom is just another word for "nothing left to lose". (Janis Joplin) From owner-mpls@UU.NET Fri Jul 14 09:44: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 JAA28072 for ; Fri, 14 Jul 2000 09:44:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixus05440; Fri, 14 Jul 2000 13:35:47 GMT Received: by mail-control.mail.uu.net id QQixus16936 for mpls-outgoing; Fri, 14 Jul 2000 13:35: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 QQixus16929 for ; Fri, 14 Jul 2000 13:35: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 QQixus26709 for ; Fri, 14 Jul 2000 09:35:03 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQixus05078 for ; Fri, 14 Jul 2000 13:35:03 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA24815 for ; Fri, 14 Jul 2000 06:35:15 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA29640 for mpls@uu.net; Fri, 14 Jul 2000 09:34:56 -0400 (EDT) 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 QQixtt01324 for ; Fri, 14 Jul 2000 07:27: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 QQixtt13605 for ; Fri, 14 Jul 2000 03:27:32 -0400 (EDT) Received: from pooh.aist-nara.ac.jp by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: h066.p094.iij4u.or.jp [210.130.94.66]) id QQixtt04639 for ; Fri, 14 Jul 2000 07:27:30 GMT Received: from localhost by pooh.aist-nara.ac.jp (8.8.7/2.8Wb) id HAA02116; Fri, 14 Jul 2000 07:28:08 GMT From: Noritoshi Demizu To: mpls@UU.NET Subject: Re: MPLS simulator In-Reply-To: Your message of "Fri, 14 Jul 2000 14:28:17 +0800" References: X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 X-URL: http://infonet.aist-nara.ac.jp/member/nori-d/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000714162800F.demizu@dd.iij4u.or.jp> Date: Fri, 14 Jul 2000 16:28:00 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 9 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > you can check with Woojik Chun . He mentioned > about a ns-based mpls simulator they worked on a few months back. > not sure whether they are available to the public already.. Gaeil Ahn and Woojik Chun's MPLS Network Simulator (MNS) can be found at http://www.raonet.com/mns/ Best Regards, Noritoshi Demizu From owner-mpls@UU.NET Fri Jul 14 09:45: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 JAA28277 for ; Fri, 14 Jul 2000 09:45:09 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixus02276; Fri, 14 Jul 2000 13:36:26 GMT Received: by mail-control.mail.uu.net id QQixus16957 for mpls-outgoing; Fri, 14 Jul 2000 13:35: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 QQixus16943 for ; Fri, 14 Jul 2000 13:35: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 QQixus21621 for ; Fri, 14 Jul 2000 09:34:12 -0400 (EDT) Received: from devmail.dev.tivoli.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: devmail.dev.tivoli.com [208.230.244.136]) id QQixus00208 for ; Fri, 14 Jul 2000 13:33:56 GMT Received: from madev-dns.ma.dev.tivoli.com (madev-dns.ma.dev.tivoli.com [146.84.242.19]) by devmail.dev.tivoli.com (8.9.1/8.8.8) with ESMTP id IAA17449 for ; Fri, 14 Jul 2000 08:33:55 -0500 (CDT) Received: from ptasillo (ptasillo.ma.dev.tivoli.com [146.84.242.70]) by madev-dns.ma.dev.tivoli.com (8.8.8/8.8.8) with SMTP id JAA24567 for ; Fri, 14 Jul 2000 09:35:42 -0400 (EDT) From: "Paul Tasillo" To: Subject: draft-ietf-mpls-lsr-mib-06.txt Date: Fri, 14 Jul 2000 09:34:16 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In draft-ietf-mpls-lsr-mib-06.txt, these sections mention admin/oper status and their roles in the in-segment/out-segment tables, but the status entries have been removed. 7.3. mplsInSegmentTable ... The administrative and operational status objects for this table are used to control packet transmission on this segment. If either the administrative and operational status objects for this table are set to 'down', this implies that packets will not be forwarded. Likewise, if the values are set to 'up' this implies that packets are forwarded. These values are particularly useful in cases where multi-point connections utilize a single cross- connect and the administrator wishes to disable some, but not all of the streams. In these cases, the administrator may set the administrative status object to 'down' on some of the in-segments. 7.5. mplsOutSegmentTable ... The administrative and operational status objects for this table are used to control packet transmission on this segment. If either the administrative and operational status objects are set to 'down', this implies that packets will not be forwarded. Likewise, if the values are set to 'up' this implies that packets are forwarded. These values are particularly useful in cases where multicast connections utilize a single cross-connect and the administrator wishes to disable some, but not all of the streams. In these cases, the administrator may set the administrative status object to 'down' on some of the out-segments. Sould more empahsis be placed on the oper/admin status of the XCTable entries? When a XC entry is down packets will not be forwarded through ANY segments that utilize the XC entry. -Paul Paul Tasillo Tivoli Systems From owner-mpls@UU.NET Fri Jul 14 09:53: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 JAA01256 for ; Fri, 14 Jul 2000 09:53:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixus09216; Fri, 14 Jul 2000 13:44:44 GMT Received: by mail-control.mail.uu.net id QQixus17827 for mpls-outgoing; Fri, 14 Jul 2000 13:44: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 QQixus17814 for ; Fri, 14 Jul 2000 13:44: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 QQixus28300 for ; Fri, 14 Jul 2000 09:43:59 -0400 (EDT) Received: from prue.eim.surrey.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQixus08841 for ; Fri, 14 Jul 2000 13:43:59 GMT Received: from carter-e0.ee.surrey.ac.uk ([131.227.86.16] helo=ee.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13D5kw-00055i-00 for mpls@UU.NET; Fri, 14 Jul 2000 14:43:55 +0100 Message-ID: <396F191B.5BB311DA@ee.surrey.ac.uk> Date: Fri, 14 Jul 2000 14:43:55 +0100 From: "George N. Aggelou" Organization: University of Surrey, Guildford, England X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: MPLS simulator References: <396F0B41.194EAC6F@estos.upc.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Folks, Talking about MPLS simulators, does anyone know any available MPLS model based on MAISIE/PARSEC or C? I am particularly interested in CBR-LDP protocol. Regards, George A. Juan Diego Otero wrote: > > markk@sg.ibm.com wrote: > > > Hi, > > > > you can check with Woojik Chun . He mentioned > > about a ns-based mpls simulator they worked on a few months back. > > not sure whether they are available to the public already.. > > > > Rgds > > -khengkok > > I am sorry, the right link is this: > > http://www.isi.edu/nsnam/ns/ > > Cheers, > > Diego -- *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. George N. Aggelou Research Fellow Centre for Communications Systems Research University of Surrey http://www.ee.surrey.ac.uk/Personal/G.Aggelou *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*. From owner-mpls@UU.NET Fri Jul 14 09:59: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 JAA03118 for ; Fri, 14 Jul 2000 09:59:24 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixut12389; Fri, 14 Jul 2000 13:49:44 GMT Received: by mail-control.mail.uu.net id QQixut18616 for mpls-outgoing; Fri, 14 Jul 2000 13:49: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 QQixut18605 for ; Fri, 14 Jul 2000 13:48: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 QQixut29063 for ; Fri, 14 Jul 2000 09:48:46 -0400 (EDT) From: erosen@cisco.com Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQixut11376 for ; Fri, 14 Jul 2000 13:48:31 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA18951 for ; Fri, 14 Jul 2000 06:48:44 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA29787 for ; Fri, 14 Jul 2000 09:48:29 -0400 (EDT) Date: Fri, 14 Jul 2000 09:48:29 -0400 (EDT) Message-Id: <200007141348.JAA29787@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs Prev-Resent: Fri, 14 Jul 2000 09:48:28 -0400 Prev-Resent: "mpls@uu.net " To: undisclosed-recipients:; Sender: owner-mpls@UU.NET Precedence: bulk From ietf-123-owner@loki.ietf.org Thu Jul 13 10: 53:32 2000 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA22157; Thu, 13 Jul 2000 10:53:31 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA28730; Thu, 13 Jul 2000 07:53:40 -0700 (PDT) Received: from proxy1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with SMTP id e6DErRq21194; Thu, 13 Jul 2000 07:53:27 -0700 (PDT) Received: from (loki.ietf.org [132.151.1.177]) by proxy1.cisco.com with SMTP (MailShield v1.5); Thu, 13 Jul 2000 07:52:49 -0700 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA06096 for ietf-123-outbound.02@ietf.org; Thu, 13 Jul 2000 10:35:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA03716 for ; Thu, 13 Jul 2000 06:28:39 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11340 for ; Thu, 13 Jul 2000 06:28:40 -0400 (EDT) Message-Id: <200007131028.GAA11340@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-farinacci-mpls-multicast-02.txt Date: Thu, 13 Jul 2000 06:28:39 -0400 Sender: nsyracus@cnri.reston.va.us X-SPAM: Yes X-SPAM-REASON: Suspicious TO Address X-SPAM-INFO: http://wwwin.cisco.com/CustAdv/InfoSys/spam X-SMTP-HELO: loki.ietf.org X-SMTP-MAIL-FROM: ietf-123-owner@loki.ietf.org X-SMAP-Received-From: outside X-SMTP-PEER-INFO: loki.ietf.org [132.151.1.177] Resent-To: mpls@uu.net Resent-Date: Fri, 14 Jul 2000 09:48:29 -0400 Resent-From: Eric Rosen --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using PIM to Distribute MPLS Labels for Multicast Routes Author(s) : D. Farinacci, Y. Rekhter, E. Rosen, T. Qian Filename : draft-farinacci-mpls-multicast-02.txt Pages : 15 Date : 12-Jul-00 This document specifies a method of distributing MPLS labels [MPLS- ARCH, MPLS-MUL-FR] for multicast routes. The labels are distributed in the same PIM messages that are used to create the corresponding routes. The method is media-type independent, and therefore works for multi-access/multicast capable LANs, point-to-point links, and NBMA networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-farinacci-mpls-multicast-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-farinacci-mpls-multicast-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-farinacci-mpls-multicast-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000712140602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-farinacci-mpls-multicast-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-farinacci-mpls-multicast-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000712140602.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Jul 14 10:02: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 KAA04115 for ; Fri, 14 Jul 2000 10:02:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixut15150; Fri, 14 Jul 2000 13:53:20 GMT Received: by mail-control.mail.uu.net id QQixut19009 for mpls-outgoing; Fri, 14 Jul 2000 13:52: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 QQixut18976 for ; Fri, 14 Jul 2000 13:52: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 QQixut24497 for ; Fri, 14 Jul 2000 09:51:45 -0400 (EDT) Received: from prue.eim.surrey.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQixut12090 for ; Fri, 14 Jul 2000 13:51:30 GMT Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13D5sE-0005AL-00; Fri, 14 Jul 2000 14:51:26 +0100 Date: Fri, 14 Jul 2000 14:51:23 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: markk@sg.ibm.com cc: mpls@UU.NET Subject: Re: MPLS simulator In-Reply-To: Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 14 Jul 2000 markk@sg.ibm.com wrote: > you can check with Woojik Chun . He mentioned > about a ns-based mpls simulator they worked on a few months back. > not sure whether they are available to the public already.. It's at http://raonet.com/mns/english.html On Fri, 14 Jul 2000 George N. Aggelou wrote: $ Talking about MPLS simulators, does anyone know any available MPLS $ model based on MAISIE/PARSEC or C? zero chance of that, I imagine. L. PGP From owner-mpls@UU.NET Fri Jul 14 10:23: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 KAA09780 for ; Fri, 14 Jul 2000 10:23:02 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixuu20271; Fri, 14 Jul 2000 14:14:17 GMT Received: by mail-control.mail.uu.net id QQixuu01340 for mpls-outgoing; Fri, 14 Jul 2000 14:13:49 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQixuu01322 for ; Fri, 14 Jul 2000 14:13:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixuu27298 for ; Fri, 14 Jul 2000 10:11:04 -0400 (EDT) Received: from bgslc02.TBG.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQixuu19126 for ; Fri, 14 Jul 2000 14:10:48 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id <361ZJ3TF>; Fri, 14 Jul 2000 08:02:02 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE7BAE799@BGSLC02> From: Irwin Lazar To: "'Shen Gangxiang'" , "'mpls@UU.NET'" Subject: RE: MPLS simulator Date: Fri, 14 Jul 2000 08:02:01 -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 See: http://www.mplsrc.com/vendor.shtml -----Original Message----- From: Shen Gangxiang [mailto:EGXShen@ntu.edu.sg] Sent: Friday, July 14, 2000 1:52 AM To: 'mpls@UU.NET' Subject: MPLS simulator Hi, colleagues, Is anyone know some MPLS simulators? If so, please give me some helpful information. Thanks! cheers, Gangxiang Shen From owner-mpls@UU.NET Fri Jul 14 11:04: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 LAA22308 for ; Fri, 14 Jul 2000 11:04:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixux06801; Fri, 14 Jul 2000 14:55:12 GMT Received: by mail-control.mail.uu.net id QQixux05788 for mpls-outgoing; Fri, 14 Jul 2000 14:54: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 QQixux05774 for ; Fri, 14 Jul 2000 14:54: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 QQixux10571 for ; Fri, 14 Jul 2000 10:54:18 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQixux06284 for ; Fri, 14 Jul 2000 14:53:47 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA09022 for mpls@uu.net; Fri, 14 Jul 2000 10:53:46 -0400 (EDT) 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 QQixux05733 for ; Fri, 14 Jul 2000 14:53: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 QQixux04099 for ; Fri, 14 Jul 2000 10:52:25 -0400 (EDT) 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 QQixux05689 for ; Fri, 14 Jul 2000 14:52:10 GMT Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id HAA18609; Fri, 14 Jul 2000 07:51:32 -0700 (PDT) Message-ID: <396F29C5.B8E74E62@cisco.com> Date: Fri, 14 Jul 2000 07:55:01 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan Diego Otero CC: mpls@UU.NET Subject: Re: BW reserve in a TE LSP References: <396F0856.656A382E@estos.upc.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > can be used by other traffic flows? It can be used by best-effort > traffic who travels in the same links that the RSVP flows? All TE reservations are done only in the control plane, nothing is reserved on the interface level. Therefor the answer to both of your questions is: yes. R. > Juan Diego Otero wrote: > > Hi, > > We have established an MPLS TE Tunnel between 2 > Cisco 7200 routers with RSVP as the signaling protocol. > We've made a RSVP reserve of 100 Kbit/s. I have one question: > if you don't use your BW reserved, or you just use, for > instace 25%, what happens with the unused reserved BW. It > can be used by other traffic flows? It can be used by best-effort > traffic who travels in the same links that the RSVP flows? > > Thanks > > Diego Otero From owner-mpls@UU.NET Fri Jul 14 11:31:59 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02467 for ; Fri, 14 Jul 2000 11:31:58 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixuz18784; Fri, 14 Jul 2000 15:23:10 GMT Received: by mail-control.mail.uu.net id QQixuz20340 for mpls-outgoing; Fri, 14 Jul 2000 15:22:50 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQixuz20328 for ; Fri, 14 Jul 2000 15:22: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 QQixuz08839 for ; Fri, 14 Jul 2000 11:21:14 -0400 (EDT) Received: from web5102.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web5102.mail.yahoo.com [216.115.106.72]) id QQixuz17726 for ; Fri, 14 Jul 2000 15:20:58 GMT Message-ID: <20000714152058.11066.qmail@web5102.mail.yahoo.com> Received: from [169.144.16.187] by web5102.mail.yahoo.com; Fri, 14 Jul 2000 08:20:58 PDT Date: Fri, 14 Jul 2000 08:20:58 -0700 (PDT) From: Chatur sharp Subject: Ques. On draft-kompella-mpls-bundle-02.txt To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, It seems to me through out this draft that MPLS-TE protocol is just RSVP-TE, is this assumption correct. For example, section 5.1 says the "the RSVP traffic control module..." There would be no such module in a system running CR-LDP so would than this section not apply ? thanks Arun Punj ===== I am willing to learn, if you care to teach. I am willing to teach, if you care to learn. __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From owner-mpls@UU.NET Fri Jul 14 11:46: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 LAA07842 for ; Fri, 14 Jul 2000 11:46:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixva24219; Fri, 14 Jul 2000 15:37:42 GMT Received: by mail-control.mail.uu.net id QQixva22038 for mpls-outgoing; Fri, 14 Jul 2000 15:37: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 QQixva22028 for ; Fri, 14 Jul 2000 15:37:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixva18441 for ; Fri, 14 Jul 2000 11:36:58 -0400 (EDT) From: Ted44tedT@netscape.net Received: from imo-d02.mx.aol.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: imo-d02.mx.aol.com [205.188.157.34]) id QQixva23919 for ; Fri, 14 Jul 2000 15:36:57 GMT Received: from Ted44tedT@netscape.net by imo-d02.mx.aol.com (mail_out_v27.10.) id 1.2c.71ffb (16240) for ; Fri, 14 Jul 2000 11:36:39 -0400 (EDT) Received: from netscape.com (aimmail08.aim.aol.com [205.188.144.200]) by air-in03.mx.aol.com (v75_b1.4) with ESMTP; Fri, 14 Jul 2000 11:36:39 -0400 Message-ID: <7B902915.246DC5DB.02882A9A@netscape.net> Date: Fri, 14 Jul 2000 11:37:42 -0400 To: mpls@UU.NET Subject: non-RSVP router and LRO X-Mailer: Franklin Webmailer 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I have a question for the non-RSVP router and LRO from draft-mpls-rsvp-lsp-tunnel-06.txt. it says "RSVP is designed to cope gracefully with non-RSVP routers anywhere between senders and receivers. However, obviously, non-RSVP routers cannot convey labels via RSVP. This means that if a router has a neighbor that is known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when sending messages that pass through the non-RSVP routers. The router SHOULD send a PathErr back to the sender, with the error code "Routing problem" and the error value "MPLS being negotiated, but a non-RSVP capable router stands in the path." In my understanding, the upstream node should know the nhop is a non-rsvp router. Then it will stop sending the Path message with LRO and send back the sender a PathErr message. If it is correct, how the upstream node knows the nhop is non-RSVP? If it is not correct, then the router should know the existing of non-rsvp after receiving the phop's path message if one of phops is non-rsvp. Then the router will send back the PathErr message to the sender. Can the non-RSVP router pass the LRO and Path message? Another question is where I can find the list of error code(not value) like "Routing Problem", etc. Thanks Regards, Ted ---------- Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/ From owner-mpls@UU.NET Fri Jul 14 11:52: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 LAA10497 for ; Fri, 14 Jul 2000 11:52:46 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixva00614; Fri, 14 Jul 2000 15:43:50 GMT Received: by mail-control.mail.uu.net id QQixva22683 for mpls-outgoing; Fri, 14 Jul 2000 15:43:23 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQixva22676 for ; Fri, 14 Jul 2000 15:43: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 QQixva12601 for ; Fri, 14 Jul 2000 11:43:04 -0400 (EDT) Received: from malmo.trab.se by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: malmo.trab.se [131.115.48.10]) id QQixva26319 for ; Fri, 14 Jul 2000 15:42:33 GMT Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id e6EFgU917396; Fri, 14 Jul 2000 17:42:30 +0200 (MET DST) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jul 2000 17:42:05 +0200 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D01E7DE99@trab-hermes.haninge.trab.se> From: Olle Pers To: kireeti@juniper.net Cc: mpls@UU.NET Subject: RE: LSP hierarchy comments Date: Fri, 14 Jul 2000 17:42:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, * * Are there interfaces that can switch wavelengths, TDM channels AND * packets? We don't cater to these (yet), as we are not aware of such * interfaces. * * [...] I haven't seen any such things, yet. I intended to ask whether this simple attribute can handle more complex capabilities than the ones described, if and when such capabilities would emerge in the future. (For example, I could imagine a device where the wavelengths on an incoming fiber are being lambda switched, either directly to utgoing fibers, or internally to another circuit board within the same box, where the lambda paths are terminated and their content is TDM switched. If such a device would like to appear as a single node to its routing neighbors, which link mux capability should be advertised for that incoming fiber link?) * * > - which value should we use for IP routers that do not understand MPLS? * > PCS-0? * * Routers that don't understand MPLS should not be advertising * TE links. * The current draft says that the new attribute is "Associated with each link (including forwarding adjacencies)", and I guessed that meant all links in the ISIS/OSPF area. I understand the use of this attribute is to determine "regions" where LSPs of the same "level" are possible. This way an LSR at the edge of such a region can find which node is at the other edge of the region, and correctly set the tunnel endpoint address in the RSVP message. This seems applicable to packet-switched LSPs as well. The LSRs should somehow be able to know where the MPLS-domain ends. They cannot always assume that it covers the entire ISIS/OSPF area. (Maybe there is already some applicable TLV defined for this, that I am not aware of. Or maybe just the lack of a LMC TLV would be sufficient to identify a link as non-MPLS capable.) * > - more important, could there be any problems with having the LSRs advertise * > the capabilities of other nodes, instead of having each router advertise its * > own capabilities? The words "coordinated configuration" can easily make an * > operator think about "manual" and "errors". * * True. We MAY do something about this. Fine. * > - To correctly advertise an FA-LSP, one must identify the "tail end", and * > know which is the "last link". Could there be any problems to agree where * > the LSP ends, if PHP is used at the far end? * * No. Signalling (RSVP/CR-LDP) is always absolutely clear where an LSP * ends. Where labels end is irrelevant. * Fine. * > - The routing aspects cover both ISIS and OSPF, but all the signalling * > examples are for RSVP-TE only. Would there be any principal differences if * > LDP was used instead? * * LDP doesn't fit the bill. Perhaps you mean CR-LDP; we say how both * RSVP and CR-LDP can be used. * Yes, I meant CR-LDP. It was mentioned in the overview section, but never again in the rest of the draft. * * Thanks for your comments! * * Kireeti. * Thanks. Olle From owner-mpls@UU.NET Fri Jul 14 13:43: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 NAA15843 for ; Fri, 14 Jul 2000 13:43:10 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixvi04317; Fri, 14 Jul 2000 17:34:23 GMT Received: by mail-control.mail.uu.net id QQixvi23805 for mpls-outgoing; Fri, 14 Jul 2000 17:34: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 QQixvi23798 for ; Fri, 14 Jul 2000 17:33:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixvi08786 for ; Fri, 14 Jul 2000 13:33:38 -0400 (EDT) Received: from apollo.mctr.umbc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89]) id QQixvi04076 for ; Fri, 14 Jul 2000 17:33:38 GMT Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142]) by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id NAA10562; Fri, 14 Jul 2000 13:33:36 -0400 (EDT) Received: from localhost (ayyangar@localhost) by mercury.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id NAA13424; Fri, 14 Jul 2000 13:37:04 -0400 (EDT) X-Authentication-Warning: mercury.mctr.umbc.edu: ayyangar owned process doing -bs Date: Fri, 14 Jul 2000 13:37:04 -0400 (EDT) From: Arthi Ayyangar X-Sender: ayyangar@mercury.mctr.umbc.edu To: Ted44tedT@netscape.net cc: mpls@UU.NET Subject: Re: non-RSVP router and LRO In-Reply-To: <7B902915.246DC5DB.02882A9A@netscape.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk A non-RSVP router will simply propagate RSVP messages w.o processing them. (ref. RFC 2205) So when a downstream RSVP-capable router receives a Path msg. from this router containing LRO, it detects the presence of a non-RSVP router upstream (from TTL values) and sends a PathErr message upstream. When this reaches the RSVP-capable upstream router, it knows that it's next-hop is a non-RSVP router. So, henceforth it sends PathErr back to the sender if it receives a Path msg. with LRO directed towards that next-hop. -arthi > I have a question for the non-RSVP router and LRO from draft-mpls-rsvp-lsp-tunnel-06.txt. > > it says "RSVP is designed to cope gracefully with non-RSVP routers anywhere > between senders and receivers. However, obviously, non-RSVP routers > cannot convey labels via RSVP. This means that if a router has a > neighbor that is known to not be RSVP capable, the router MUST NOT > advertise the LABEL_REQUEST object when sending messages that pass > through the non-RSVP routers. The router SHOULD send a PathErr back > to the sender, with the error code "Routing problem" and the error > value "MPLS being negotiated, but a non-RSVP capable router stands in > the path." > > In my understanding, the upstream node should know the nhop is a non-rsvp router. Then it will stop sending the Path message with LRO and send back the sender a PathErr message. > > If it is correct, how the upstream node knows the nhop is non-RSVP? > > If it is not correct, then the router should know the existing of non-rsvp after receiving the phop's path message if one of phops is non-rsvp. Then the router will send back the PathErr message to the sender. Can the non-RSVP router pass the LRO and Path message? > > > Another question is where I can find the list of error code(not value) like "Routing Problem", etc. > > > Thanks > > Regards, > Ted > > > ---------- > Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/ > From owner-mpls@UU.NET Fri Jul 14 14:45: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 OAA05185 for ; Fri, 14 Jul 2000 14:45:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixvm27320; Fri, 14 Jul 2000 18:35:16 GMT Received: by mail-control.mail.uu.net id QQixvm08915 for mpls-outgoing; Fri, 14 Jul 2000 18:34: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 QQixvm08905 for ; Fri, 14 Jul 2000 18:34:40 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 QQixvm08676 for ; Fri, 14 Jul 2000 14:34:30 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQixvm24578 for ; Fri, 14 Jul 2000 18:34:29 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id NAA22030; Fri, 14 Jul 2000 13:34:24 -0500 Message-Id: <4.3.2.7.2.20000714135614.00bd1820@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 14:35:21 -0400 To: "Chatterjee, Shash" From: Lou Berger Subject: draft-ashwood-generalized-mpls-signaling- (was Re: Optical MPLS) Cc: "MPLS Mailing-list (E-mail)" In-Reply-To: <758F0C2C951CD411B15300D0B74444650A5CAB@WRNXCHG> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk A number of us just submitted a draft that merges and extends some of the drafts you mention. If you (or anyone else) would like to take a look at it before it comes out in the standard places, it's available at: http://www.labn.net/lberger/docs/draft-ashwood-generalized-mpls-signaling-00.txt Lou At 12:05 PM 7/5/00 -0500, Chatterjee, Shash wrote: >Hello everyone! > >Where can I get a comprehensive list of the MPLS/CR-LDP >optical/lambda-switching drafts? >So far, I have read draft-kompella...,draft-fan..., draft-basak... and >draft-krishnaswamy... Are there any others? Also, are there any other >(potentially non-IETF) documents/mailing-lists where I can learn about the >various standards efforts and issues related to this topic? > >Any pointers on this topic would be very welcome. > >Thanks in advance, >Shash > >Sasvata (Shash) Chatterjee >schatterjee@whiterocknetworks.com >White Rock Networks >Dallas, Texas, USA > From owner-mpls@UU.NET Fri Jul 14 15:38: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 PAA24386 for ; Fri, 14 Jul 2000 15:38:22 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixvp15641; Fri, 14 Jul 2000 19:27:58 GMT Received: by mail-control.mail.uu.net id QQixvp24360 for mpls-outgoing; Fri, 14 Jul 2000 19:27: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 QQixvp24332 for ; Fri, 14 Jul 2000 19:27: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 QQixvp28819 for ; Fri, 14 Jul 2000 15:26:46 -0400 (EDT) From: Ted44tedT@netscape.net Received: from imo-d03.mx.aol.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: imo-d03.mx.aol.com [205.188.157.35]) id QQixvp04868 for ; Fri, 14 Jul 2000 19:26:46 GMT Received: from Ted44tedT@netscape.net by imo-d03.mx.aol.com (mail_out_v27.10.) id t.3.34b0b (16213); Fri, 14 Jul 2000 15:24:55 -0400 (EDT) Received: from netscape.com (aimmail03.aim.aol.com [205.188.144.195]) by air-in01.mx.aol.com (v75_b1.4) with ESMTP; Fri, 14 Jul 2000 15:24:55 -0400 Message-ID: <4AD95886.61627EF8.02882A9A@netscape.net> Date: Fri, 14 Jul 2000 15:24:32 -0400 To: ayyangar@apollo.mctr.umbc.edu Cc: mpls@UU.NET Subject: Re: non-RSVP router and LRO References: X-Mailer: Franklin Webmailer 1.0 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Arthi, Sorry, I thought your explanation is about the other case not the case I mentioned before. The reason is from the draft,section 4.2.5(last 3 lines) "...... This same message SHOULD be sent, if a router receives a LABEL_REQUEST object in a message from a non-RSVP capable router." I think this case is proper with your explanation. Regards, Ted > A non-RSVP router will simply propagate RSVP messages w.o processing them. > (ref. RFC 2205) > So when a downstream RSVP-capable router receives a Path msg. from this > router containing LRO, it detects the presence of a non-RSVP router > upstream (from TTL values) and sends a PathErr message upstream. When this > reaches the RSVP-capable upstream router, it knows that it's next-hop is a > non-RSVP router. So, henceforth it sends PathErr back to the sender if it > receives a Path msg. with LRO directed towards that next-hop. > > -arthi > > > I have a question for the non-RSVP router and LRO from draft-mpls-rsvp-lsp-tunnel-06.txt. > > > > it says "RSVP is designed to cope gracefully with non-RSVP routers anywhere > >    between senders and receivers. However, obviously, non-RSVP routers > >    cannot convey labels via RSVP. This means that if a router has a > >    neighbor that is known to not be RSVP capable, the router MUST NOT > >    advertise the LABEL_REQUEST object when sending messages that pass > >    through the non-RSVP routers.  The router SHOULD send a PathErr back > >    to the sender, with the error code "Routing problem" and the error > >    value "MPLS being negotiated, but a non-RSVP capable router stands in > >    the path." > > > > In my understanding, the upstream node should know the nhop is a non-rsvp router. Then it will stop sending the Path message with LRO and send back the sender a PathErr message. > > > > If it is correct, how the upstream node knows the nhop is non-RSVP? > > > > If it is not correct, then the router should know the existing of non-rsvp after receiving the phop's path message if one of phops is non-rsvp. Then the router will send back the PathErr message to the sender. Can the non-RSVP router pass the LRO and Path message? > > > > > > Another question is where I can find the list of error code(not value) like "Routing Problem", etc. > > > > > > Thanks > > > > Regards, > > Ted > > > > > > ---------- > > Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/ > > > > ---------- Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/ From owner-mpls@UU.NET Fri Jul 14 15:45: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 PAA26601 for ; Fri, 14 Jul 2000 15:45:48 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixvq19989; Fri, 14 Jul 2000 19:37:12 GMT Received: by mail-control.mail.uu.net id QQixvq24919 for mpls-outgoing; Fri, 14 Jul 2000 19:36: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 QQixvq24912 for ; Fri, 14 Jul 2000 19:36: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 QQixvq19623 for ; Fri, 14 Jul 2000 15:35:41 -0400 (EDT) Received: from apollo.mctr.umbc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89]) id QQixvq19200 for ; Fri, 14 Jul 2000 19:35:25 GMT Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142]) by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id PAA12861; Fri, 14 Jul 2000 15:35:24 -0400 (EDT) Received: from localhost (ayyangar@localhost) by mercury.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id PAA13710; Fri, 14 Jul 2000 15:38:52 -0400 (EDT) X-Authentication-Warning: mercury.mctr.umbc.edu: ayyangar owned process doing -bs Date: Fri, 14 Jul 2000 15:38:52 -0400 (EDT) From: Arthi Ayyangar X-Sender: ayyangar@mercury.mctr.umbc.edu To: Ted44tedT@netscape.net cc: mpls@UU.NET Subject: Re: non-RSVP router and LRO In-Reply-To: <4AD95886.61627EF8.02882A9A@netscape.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id PAA26601 Actually, I think your case would follow the case in the bottom half of the paragraph. Once the downstream router knows of a non-RSVP router upstream, it will propagate Patherr upstream. Only then will the upstream know of a non-RSVP next-hop. (The Path msg that downstream receives the first time from a non-RSVP upstream , need not even contain the LRO....doesn't matter) Now that upstream router knows of a non-RSVP next-hop, your case follows. thaanks, -arthi > Sorry, I thought your explanation is about the other case not the case I > mentioned before. > > The reason is from the draft,section 4.2.5(last 3 lines) > > "...... This same message SHOULD be sent, if a router receives a > LABEL_REQUEST object in a message from a non-RSVP capable router." > > I think this case is proper with your explanation. > > > Regards, > > Ted > > > > A non-RSVP router will simply propagate RSVP messages w.o processing them. > > (ref. RFC 2205) > > So when a downstream RSVP-capable router receives a Path msg. from this > > router containing LRO, it detects the presence of a non-RSVP router > > upstream (from TTL values) and sends a PathErr message upstream. When this > > reaches the RSVP-capable upstream router, it knows that it's next-hop is a > > non-RSVP router. So, henceforth it sends PathErr back to the sender if it > > receives a Path msg. with LRO directed towards that next-hop. > > > > -arthi > > > > > I have a question for the non-RSVP router and LRO from draft-mpls-rsvp-lsp-tunnel-06.txt. > > > > > > it says "RSVP is designed to cope gracefully with non-RSVP routers anywhere > > >    between senders and receivers. However, obviously, non-RSVP routers > > >    cannot convey labels via RSVP. This means that if a router has a > > >    neighbor that is known to not be RSVP capable, the router MUST NOT > > >    advertise the LABEL_REQUEST object when sending messages that pass > > >    through the non-RSVP routers.  The router SHOULD send a PathErr back > > >    to the sender, with the error code "Routing problem" and the error > > >    value "MPLS being negotiated, but a non-RSVP capable router stands in > > >    the path." > > > > > > In my understanding, the upstream node should know the nhop is a non-rsvp router. Then it will stop sending the Path message with LRO and send back the sender a PathErr message. > > > > > > If it is correct, how the upstream node knows the nhop is non-RSVP? > > > > > > If it is not correct, then the router should know the existing of non-rsvp after receiving the phop's path message if one of phops is non-rsvp. Then the router will send back the PathErr message to the sender. Can the non-RSVP router pass the LRO and Path message? > > > > > > > > > Another question is where I can find the list of error code(not value) like "Routing Problem", etc. > > > > > > > > > Thanks > > > > > > Regards, > > > Ted > > > > > > > > > ---------- > > > Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/ > > > > > > > > > ---------- > Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/ > From owner-mpls@UU.NET Fri Jul 14 16:10: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 QAA03125 for ; Fri, 14 Jul 2000 16:10:18 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixvr27787; Fri, 14 Jul 2000 19:59:58 GMT Received: by mail-control.mail.uu.net id QQixvr26412 for mpls-outgoing; Fri, 14 Jul 2000 19:59: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 QQixvr26402 for ; Fri, 14 Jul 2000 19:59: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 QQixvr04424 for ; Fri, 14 Jul 2000 15:59:22 -0400 (EDT) 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 QQixvr27264 for ; Fri, 14 Jul 2000 19:59:22 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA22989 for mpls@uu.net; Fri, 14 Jul 2000 15:59:21 -0400 (EDT) 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 QQixvr26352 for ; Fri, 14 Jul 2000 19:58: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 QQixvr23343 for ; Fri, 14 Jul 2000 15:57:41 -0400 (EDT) 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 QQixvr25775 for ; Fri, 14 Jul 2000 19:57:09 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 PAA22696 for ; Fri, 14 Jul 2000 15:57:08 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA16907 for ; Fri, 14 Jul 2000 15:57:08 -0400 (EDT) Message-Id: <200007141957.PAA16907@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Time to set the agenda Date: Fri, 14 Jul 2000 15:57:08 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Please send agenda request for Pittsburg to me. I'll post a draft agenda next Wednesday. Many of you have already sent agenda requests. You need not send them again. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Jul 14 16:22: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 QAA06064 for ; Fri, 14 Jul 2000 16:22:22 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixvs03673; Fri, 14 Jul 2000 20:13:49 GMT Received: by mail-control.mail.uu.net id QQixvs08925 for mpls-outgoing; Fri, 14 Jul 2000 20:13: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 QQixvs08914 for ; Fri, 14 Jul 2000 20:13: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 QQixvs25933 for ; Fri, 14 Jul 2000 16:12:52 -0400 (EDT) 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 QQixvs06836 for ; Fri, 14 Jul 2000 20:12:22 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA25001 for mpls@uu.net; Fri, 14 Jul 2000 16:12:21 -0400 (EDT) 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 QQixvs08796 for ; Fri, 14 Jul 2000 20:11:42 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixvs06688 for ; Fri, 14 Jul 2000 16:11:26 -0400 (EDT) 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 QQixvs02764 for ; Fri, 14 Jul 2000 20:11:10 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA22388; Fri, 14 Jul 2000 13:10:40 -0700 (PDT) Message-Id: <200007142010.NAA22388@omega.cisco.com> To: Bora Akyol cc: mpls@UU.NET Subject: Question on lsp-hierarchy-00.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22386.963605440.1@cisco.com> Date: Fri, 14 Jul 2000 13:10:40 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Bora, > In section 5.2, how does an LSR know when to initiate establishment of a > new FA-LSP vs just establishing a new LSP. Is it told that it is an > aggregating LSR? > > I understand that it may be possible to infer this when it is sitting at > a region/domain boundary, but what happens if it is sitting in the > middle of a plain old ip network? "plain old ip network" may still have some links marked as PSC-x, while others marked as PSC-y (x != y). Yakov. From owner-mpls@UU.NET Fri Jul 14 16:26: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 QAA07392 for ; Fri, 14 Jul 2000 16:26:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixvt04562; Fri, 14 Jul 2000 20:15:47 GMT Received: by mail-control.mail.uu.net id QQixvt09274 for mpls-outgoing; Fri, 14 Jul 2000 20:15: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 QQixvt09260 for ; Fri, 14 Jul 2000 20:15: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 QQixvt26274 for ; Fri, 14 Jul 2000 16:15:14 -0400 (EDT) Received: from apollo.mctr.umbc.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89]) id QQixvt04306 for ; Fri, 14 Jul 2000 20:15:13 GMT Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142]) by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id QAA13607 for ; Fri, 14 Jul 2000 16:15:12 -0400 (EDT) Received: from localhost (ayyangar@localhost) by mercury.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id QAA13832 for ; Fri, 14 Jul 2000 16:18:40 -0400 (EDT) X-Authentication-Warning: mercury.mctr.umbc.edu: ayyangar owned process doing -bs Date: Fri, 14 Jul 2000 16:18:40 -0400 (EDT) From: Arthi Ayyangar X-Sender: ayyangar@mercury.mctr.umbc.edu To: mpls@UU.NET Subject: draft-ietf-mpls-rsvp-lsp-tunnel-06 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Ref. Section 4.8.2: Resource affinities Was there any reason to bring in the constraint information (attribute filters) into the Session Attribute Object ?? Thanks, -arthi From owner-mpls@UU.NET Fri Jul 14 17: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 RAA21092 for ; Fri, 14 Jul 2000 17:07:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixvv20001; Fri, 14 Jul 2000 20:58:27 GMT Received: by mail-control.mail.uu.net id QQixvv12453 for mpls-outgoing; Fri, 14 Jul 2000 20:58: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 QQixvv12446 for ; Fri, 14 Jul 2000 20:57:56 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixvv14004 for ; Fri, 14 Jul 2000 16:57:52 -0400 (EDT) Received: from mailrelay.laurelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laurelnetworks.com [206.67.234.84]) id QQixvv07344 for ; Fri, 14 Jul 2000 20:57:52 GMT Received: from laurel6btlsnsg (laurel-6btlsnsg.laurelnetworks.com [192.168.0.69]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with SMTP id QAA03812; Fri, 14 Jul 2000 16:57:49 -0400 From: "Robert Rennison" To: "Lou Berger" , "Chatterjee, Shash" Cc: "MPLS Mailing-list \(E-mail\)" Subject: RE: draft-ashwood-generalized-mpls-signaling- (was Re: Optical MPLS) Date: Fri, 14 Jul 2000 16:59:43 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.3.2.7.2.20000714135614.00bd1820@mail.labn.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lou et al, I have two minor comments on this well written draft. 1. There is a minor typo in section 3.1.1 for the Generalized Label Request TLV. The description of the TLV encoding for CR-LDP says: "The format of a Generalized Labels (in CR-LDP) is:" Instead it should say. "The format of a Generalized Labels Request (in CR-LDP) is:" I have previously commented to some of you that the similarity between the name of this Generalized Label Request TLV and that of the Generalized Label object/TLV will lead to confusion and errors. 2. In section 3.2.2 Procedures it specifies that: The Generalized Label travels in the upstream direction in MAPPING/Resv messages. Upon first reading it appears that the generalized label _only_ flows in the upstream direction. The next line goes on to discuss what happens in the presence of both a generalized and normal label,and error. It is not mentioned,in this procedures section, that the generalized label is allowed in the downstream direction in the presence of link bundling. Better would be something like: The Generalized Label travels in the upstream direction in MAPPING/Resv messages and optionally in the REQUEST/Path message when in the presence of link bundling. Regards Rob Rennison --------------- Robert Rennison Laurel Networks Ph: (724) 933-7330 Fax: (724) 933-3377 robren@laurelnetworks.com > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Lou > Berger > Sent: Friday, July 14, 2000 2:35 PM > To: Chatterjee, Shash > Cc: MPLS Mailing-list (E-mail) > Subject: draft-ashwood-generalized-mpls-signaling- (was Re: Optical > MPLS) > > > A number of us just submitted a draft that merges and extends some of > the drafts you mention. If you (or anyone else) would like to take a > look at it before it comes out in the standard places, it's available at: > http://www.labn.net/lberger/docs/draft-ashwood-generalized-mpls-si > gnaling-00.txt > > Lou > > At 12:05 PM 7/5/00 -0500, Chatterjee, Shash wrote: > >Hello everyone! > > > >Where can I get a comprehensive list of the MPLS/CR-LDP > >optical/lambda-switching drafts? > >So far, I have read draft-kompella...,draft-fan..., draft-basak... and > >draft-krishnaswamy... Are there any others? Also, are there any other > >(potentially non-IETF) documents/mailing-lists where I can > learn about the > >various standards efforts and issues related to this topic? > > > >Any pointers on this topic would be very welcome. > > > >Thanks in advance, > >Shash > > > >Sasvata (Shash) Chatterjee > >schatterjee@whiterocknetworks.com > >White Rock Networks > >Dallas, Texas, USA > > From owner-mpls@UU.NET Fri Jul 14 17:09: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 RAA21585 for ; Fri, 14 Jul 2000 17:09:12 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixvw09380; Fri, 14 Jul 2000 21:00:28 GMT Received: by mail-control.mail.uu.net id QQixvw12593 for mpls-outgoing; Fri, 14 Jul 2000 21:00: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 QQixvw12504 for ; Fri, 14 Jul 2000 21:00:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixvv03403 for ; Fri, 14 Jul 2000 16:59:36 -0400 (EDT) Received: from force10networks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQixvv20392 for ; Fri, 14 Jul 2000 20:59:05 GMT Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2650.21) id <37V2T9C8>; Fri, 14 Jul 2000 13:59:02 -0700 Message-ID: <05de85b91a3485c4d44b38c68c48cf65396f7f81@force10networks.com> From: Arun Viswanathan To: "'mpls@uu.net'" Cc: "'cheenu@tachion.com'" , "'tnadeau@cisco.com'" Subject: draft-ietf-mpls-te-mib-04.txt Date: Fri, 14 Jul 2000 13:59:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk FYI, a new version of the MPLS TE MIB was submitted today which reflects changes discussed on the list. It should be available shortly on the WG web page. Title : MPLS Traffic Engineering Management Information Base Using SMIv2 Author(s) : Cheenu Srinivasan, Arun Viswanathan, Thomas D. Nadeau Filename : draft-ietf-mpls-te-mib-04.txt Pages : 46 Date : 14-Jul-00 From owner-mpls@UU.NET Fri Jul 14 17:25: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 RAA26355 for ; Fri, 14 Jul 2000 17:25:28 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixvx25980; Fri, 14 Jul 2000 21:16:30 GMT Received: by mail-control.mail.uu.net id QQixvx24908 for mpls-outgoing; Fri, 14 Jul 2000 21:16: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 QQixvx24903 for ; Fri, 14 Jul 2000 21:15:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixvx16728 for ; Fri, 14 Jul 2000 17:15:38 -0400 (EDT) Received: from mailrelay.laurelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laurelnetworks.com [206.67.234.84]) id QQixvx18885 for ; Fri, 14 Jul 2000 21:15:22 GMT Received: from ganeshpc (ganesh-pc.laurelnetworks.com [192.168.0.30]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with SMTP id RAA05099; Fri, 14 Jul 2000 17:15:19 -0400 From: "Ganesh Murugesan" To: "Lou Berger" , "Chatterjee, Shash" Cc: "MPLS Mailing-list \(E-mail\)" Subject: RE: draft-ashwood-generalized-mpls-signaling- (was Re: Optical MPLS) Date: Fri, 14 Jul 2000 17:13:31 -0400 Message-ID: <001d01bfedd8$5d008fe0$8ac6fea9@laurelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <4.3.2.7.2.20000714135614.00bd1820@mail.labn.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lou, I had a few questions on this draft. 3.1.2. Procedures A node processing the Path/REQUEST message containing the Generalized Label Request must verify that the requested parameters can be satisfied by the node and by the outgoing interface. Are we talking about the node generating the Path/Request Message or the one receiving the message. If it is the receiving then shouldn't the interface by incoming interface? 4.2 Procedures (Bidirectional LSP) Terminator nodes process Path/REQUEST messages as usual, with the exception that the upstream label can immediately be used to transport associated data upstream to the initiator Does this mean that the RESV messages flowing upstream will be labeled packets ? Can this be explained? thanks ganesh > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Lou > Berger > Sent: Friday, July 14, 2000 2:35 PM > To: Chatterjee, Shash > Cc: MPLS Mailing-list (E-mail) > Subject: draft-ashwood-generalized-mpls-signaling- (was Re: Optical > MPLS) > > > A number of us just submitted a draft that merges and extends some of > the drafts you mention. If you (or anyone else) would like to take a > look at it before it comes out in the standard places, it's available at: > http://www.labn.net/lberger/docs/draft-ashwood-generalized-mpls-si gnaling-00.txt Lou At 12:05 PM 7/5/00 -0500, Chatterjee, Shash wrote: >Hello everyone! > >Where can I get a comprehensive list of the MPLS/CR-LDP >optical/lambda-switching drafts? >So far, I have read draft-kompella...,draft-fan..., draft-basak... and >draft-krishnaswamy... Are there any others? Also, are there any other >(potentially non-IETF) documents/mailing-lists where I can learn about the >various standards efforts and issues related to this topic? > >Any pointers on this topic would be very welcome. > >Thanks in advance, >Shash > >Sasvata (Shash) Chatterjee >schatterjee@whiterocknetworks.com >White Rock Networks >Dallas, Texas, USA > From owner-mpls@UU.NET Fri Jul 14 18:13: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 SAA05445 for ; Fri, 14 Jul 2000 18:13:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixwa10279; Fri, 14 Jul 2000 22:04:25 GMT Received: by mail-control.mail.uu.net id QQixwa07511 for mpls-outgoing; Fri, 14 Jul 2000 22:04: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 QQixwa07202 for ; Fri, 14 Jul 2000 22:03:54 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixwa12393 for ; Fri, 14 Jul 2000 18:03:33 -0400 (EDT) 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 QQixwa17747 for ; Fri, 14 Jul 2000 22:03:17 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA09193 for mpls@uu.net; Fri, 14 Jul 2000 18:03:17 -0400 (EDT) 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 QQixwa04545 for ; Fri, 14 Jul 2000 22:02: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 QQixwa23045 for ; Fri, 14 Jul 2000 18:02:30 -0400 (EDT) Received: from tnnt3.tachion.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQixwa17356 for ; Fri, 14 Jul 2000 22:02:30 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id <3KNCJQ78>; Fri, 14 Jul 2000 18:05:27 -0400 Message-ID: From: Cheenu Srinivasan To: "'mpls@uu.net'" Cc: "'Arun Viswanathan'" , "'tnadeau@cisco.com'" Subject: RE: draft-ietf-mpls-te-mib-04.txt Date: Fri, 14 Jul 2000 18:05:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEDDF.9DB7C1BE" 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_01BFEDDF.9DB7C1BE Content-Type: text/plain; charset="iso-8859-1" FYI, a new version of the MPLS Packet Classifier MIB was submitted today which reflects changes based on discussions on the list. It should be available shortly on the IETF web page. Title : MPLS Packet Classifier Management Information Base Using SMIv2 Author(s) : Thomas Nadeau, Cheenu Srinivasan, Arun Viswanathan Filename : draft-nadeau-mpls-packet-classifier-mib-01.txt ------_=_NextPart_001_01BFEDDF.9DB7C1BE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-mpls-te-mib-04.txt

        FYI, a new = version of the MPLS Packet Classifier
 MIB was submitted today which reflects changes = based
 on discussions on the list. It should be = available shortly
 on the IETF web page.
 
  = Title           : = MPLS Packet Classifier Management
          &nb= sp;         Information Base = Using SMIv2
  Author(s)       = : Thomas Nadeau, Cheenu Srinivasan,
          &nb= sp;         Arun = Viswanathan
  = Filename        : = draft-nadeau-mpls-packet-classifier-mib-01.txt

------_=_NextPart_001_01BFEDDF.9DB7C1BE-- From owner-mpls@UU.NET Fri Jul 14 19:27: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 TAA17653 for ; Fri, 14 Jul 2000 19:27:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixwf01261; Fri, 14 Jul 2000 23:18:19 GMT Received: by mail-control.mail.uu.net id QQixwf25346 for mpls-outgoing; Fri, 14 Jul 2000 23:18: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 QQixwf25341 for ; Fri, 14 Jul 2000 23:17: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 QQixwf02132 for ; Fri, 14 Jul 2000 19:17:49 -0400 (EDT) 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 QQixwf00738 for ; Fri, 14 Jul 2000 23:17:33 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA15064 for mpls@uu.net; Fri, 14 Jul 2000 19:17:33 -0400 (EDT) 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 QQixwf25316 for ; Fri, 14 Jul 2000 23:17: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 QQixwf21092 for ; Fri, 14 Jul 2000 19:17:03 -0400 (EDT) Received: from tnnt3.tachion.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [198.139.117.130]) id QQixwf00270 for ; Fri, 14 Jul 2000 23:16:47 GMT Received: by TNNT3 with Internet Mail Service (5.5.2650.21) id <3KNCJQ9Q>; Fri, 14 Jul 2000 19:19:45 -0400 Message-ID: From: Cheenu Srinivasan To: "'mpls@uu.net'" Cc: "'Arun Viswanathan'" , "'tnadeau@cisco.com'" Subject: draft-nadeau-mpls-packet-classifier-mib-01.txt Date: Fri, 14 Jul 2000 19:19:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEDE9.FEB74610" 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_01BFEDE9.FEB74610 Content-Type: text/plain; charset="iso-8859-1" Sorry - my previous email about this draft had the wrong title. -- FYI, a new version of the MPLS Packet Classifier MIB was submitted today which reflects changes based on discussions on the list. It should be available shortly on the IETF web page. Title : MPLS Packet Classifier Management Information Base Using SMIv2 Author(s) : Thomas Nadeau, Cheenu Srinivasan, Arun Viswanathan Filename : draft-nadeau-mpls-packet-classifier-mib-01.txt ------_=_NextPart_001_01BFEDE9.FEB74610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-nadeau-mpls-packet-classifier-mib-01.txt

Sorry - my previous email about this draft had the = wrong
title.

--
FYI, a new version of the MPLS Packet = Classifier
MIB was submitted today which reflects changes = based
on discussions on the list. It should be available = shortly
on the IETF web page.
 
  = Title           : = MPLS Packet Classifier Management
          &nb= sp;         Information Base = Using SMIv2
  Author(s)       = : Thomas Nadeau, Cheenu Srinivasan,
          &nb= sp;         Arun = Viswanathan
  = Filename        : = draft-nadeau-mpls-packet-classifier-mib-01.txt
 

------_=_NextPart_001_01BFEDE9.FEB74610-- From owner-mpls@UU.NET Fri Jul 14 19:46: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 TAA20040 for ; Fri, 14 Jul 2000 19:46:55 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixwg12698; Fri, 14 Jul 2000 23:38:10 GMT Received: by mail-control.mail.uu.net id QQixwg26374 for mpls-outgoing; Fri, 14 Jul 2000 23:37: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 QQixwg26363 for ; Fri, 14 Jul 2000 23:37:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQixwg04418 for ; Fri, 14 Jul 2000 19:37:28 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQixwg03430 for ; Fri, 14 Jul 2000 23:37:13 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id SAA26458; Fri, 14 Jul 2000 18:37:03 -0500 Message-Id: <4.3.2.7.2.20000714175223.00d416a0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 19:38:03 -0400 To: "Robert Rennison" From: Lou Berger Subject: RE: draft-ashwood-generalized-mpls-signaling- (was Re: Optical MPLS) Cc: "Lou Berger" , "Chatterjee, Shash" , "MPLS Mailing-list \(E-mail\)" In-Reply-To: References: <4.3.2.7.2.20000714135614.00bd1820@mail.labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Rob, See responses below. At 04:59 PM 7/14/00 -0400, Robert Rennison wrote: >Lou et al, > >I have two minor comments on this well written draft. > >1. > >There is a minor typo in section 3.1.1 for the Generalized Label Request >TLV. > >The description of the TLV encoding for CR-LDP says: > >"The format of a Generalized Labels (in CR-LDP) is:" > >Instead it should say. > >"The format of a Generalized Labels Request (in CR-LDP) is:" Thank you. >I have previously commented to some of you that the similarity between the >name of >this Generalized Label Request TLV and that of the Generalized Label >object/TLV will >lead to confusion and errors. > >2. > >In section 3.2.2 Procedures it specifies that: > > The Generalized Label travels in the upstream direction in > MAPPING/Resv messages. > >Upon first reading it appears that the generalized label _only_ flows in >the upstream direction. The next line goes on to discuss what happens in the >presence of >both a generalized and normal label,and error. It is not mentioned,in this >procedures section, >that the generalized label is allowed in the downstream direction in the >presence of link bundling. I think one of us is confused, perhaps you're talking about suggested label? Thanks for the feedback. Lou >Better would be something like: > > The Generalized Label travels in the upstream direction in > MAPPING/Resv messages and optionally in the REQUEST/Path message when > in the presence of link bundling. > > >Regards > >Rob Rennison >--------------- >Robert Rennison >Laurel Networks >Ph: (724) 933-7330 >Fax: (724) 933-3377 >robren@laurelnetworks.com > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Lou > > Berger > > Sent: Friday, July 14, 2000 2:35 PM > > To: Chatterjee, Shash > > Cc: MPLS Mailing-list (E-mail) > > Subject: draft-ashwood-generalized-mpls-signaling- (was Re: Optical > > MPLS) > > > > > > A number of us just submitted a draft that merges and extends some of > > the drafts you mention. If you (or anyone else) would like to take a > > look at it before it comes out in the standard places, it's available at: > > http://www.labn.net/lberger/docs/draft-ashwood-generalized-mpls-si > > gnaling-00.txt > > > > Lou > > > > At 12:05 PM 7/5/00 -0500, Chatterjee, Shash wrote: > > >Hello everyone! > > > > > >Where can I get a comprehensive list of the MPLS/CR-LDP > > >optical/lambda-switching drafts? > > >So far, I have read draft-kompella...,draft-fan..., draft-basak... and > > >draft-krishnaswamy... Are there any others? Also, are there any other > > >(potentially non-IETF) documents/mailing-lists where I can > > learn about the > > >various standards efforts and issues related to this topic? > > > > > >Any pointers on this topic would be very welcome. > > > > > >Thanks in advance, > > >Shash > > > > > >Sasvata (Shash) Chatterjee > > >schatterjee@whiterocknetworks.com > > >White Rock Networks > > >Dallas, Texas, USA > > > From owner-mpls@UU.NET Fri Jul 14 19:53: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 TAA20769 for ; Fri, 14 Jul 2000 19:53:09 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQixwg16500; Fri, 14 Jul 2000 23:44:17 GMT Received: by mail-control.mail.uu.net id QQixwg26834 for mpls-outgoing; Fri, 14 Jul 2000 23:43: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 QQixwg26829 for ; Fri, 14 Jul 2000 23:43: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 QQixwg23922 for ; Fri, 14 Jul 2000 19:43:24 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQixwg15750 for ; Fri, 14 Jul 2000 23:42:53 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id SAA28163; Fri, 14 Jul 2000 18:42:44 -0500 Message-Id: <4.3.2.7.2.20000714193810.00b9f300@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 19:43:48 -0400 To: "Ganesh Murugesan" From: Lou Berger Subject: RE: draft-ashwood-generalized-mpls-signaling- (was Re: Optical MPLS) Cc: "Lou Berger" , "Chatterjee, Shash" , "MPLS Mailing-list \(E-mail\)" In-Reply-To: <001d01bfedd8$5d008fe0$8ac6fea9@laurelnetworks.com> References: <4.3.2.7.2.20000714135614.00bd1820@mail.labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Ganesh, At 05:13 PM 7/14/00 -0400, Ganesh Murugesan wrote: >Lou, > >I had a few questions on this draft. > >3.1.2. Procedures > > A node processing the Path/REQUEST message containing the Generalized > Label Request must verify that the requested parameters can be > satisfied by the node and by the outgoing interface. > >Are we talking about the node generating the Path/Request Message or the >one receiving the message. If it is the receiving then shouldn't the >interface by incoming interface? My view is that the previous hop verifies that the downstream link is compatible. Certainly a statement that includes both incoming and outgoing interface is accurate as well. >4.2 Procedures (Bidirectional LSP) > > Terminator nodes process Path/REQUEST messages as usual, with the > exception that the upstream label can immediately be used to > transport associated data upstream to the initiator > >Does this mean that the RESV messages flowing upstream will be labeled >packets ? Can this be explained? No. RSVP messages are control messages. They are processed normally. I'll look at rewording, but thing it's pretty close as is. Thanks for the comments, Lou >thanks >ganesh > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Lou > > Berger > > Sent: Friday, July 14, 2000 2:35 PM > > To: Chatterjee, Shash > > Cc: MPLS Mailing-list (E-mail) > > Subject: draft-ashwood-generalized-mpls-signaling- (was Re: Optical > > MPLS) > > > > > > A number of us just submitted a draft that merges and extends some of > > the drafts you mention. If you (or anyone else) would like to take a > > look at it before it comes out in the standard places, it's available at: > > http://www.labn.net/lberger/docs/draft-ashwood-generalized-mpls-si >gnaling-00.txt > >Lou > >At 12:05 PM 7/5/00 -0500, Chatterjee, Shash wrote: > >Hello everyone! > > > >Where can I get a comprehensive list of the MPLS/CR-LDP > >optical/lambda-switching drafts? > >So far, I have read draft-kompella...,draft-fan..., draft-basak... and > >draft-krishnaswamy... Are there any others? Also, are there any other > >(potentially non-IETF) documents/mailing-lists where I can learn about the > >various standards efforts and issues related to this topic? > > > >Any pointers on this topic would be very welcome. > > > >Thanks in advance, > >Shash > > > >Sasvata (Shash) Chatterjee > >schatterjee@whiterocknetworks.com > >White Rock Networks > >Dallas, Texas, USA > > From owner-mpls@UU.NET Sun Jul 16 00:49: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 AAA06408 for ; Sun, 16 Jul 2000 00:49:18 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyat28734; Sun, 16 Jul 2000 04:48:58 GMT Received: by mail-control.mail.uu.net id QQiyat22518 for mpls-outgoing; Sun, 16 Jul 2000 04:48: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 QQiyat22508 for ; Sun, 16 Jul 2000 04:48: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 QQiyat18014 for ; Sun, 16 Jul 2000 00:48:06 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQiyat15268 for ; Sun, 16 Jul 2000 04:47:51 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id VAA12739 for ; Sat, 15 Jul 2000 21:48:05 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id AAA05703 for mpls@uu.net; Sun, 16 Jul 2000 00:47:49 -0400 (EDT) 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 QQixye20900 for ; Sat, 15 Jul 2000 12:00:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQixye24971 for ; Sat, 15 Jul 2000 08:00:15 -0400 (EDT) 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 QQixye07857 for ; Sat, 15 Jul 2000 12:00:14 GMT Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id HAA08155 for ; Sat, 15 Jul 2000 07:53:26 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAAUEDCd_; Sat Jul 15 07:53:20 2000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@uu.net; Sat, 15 Jul 2000 07:59:49 -0400 Received: from newbridge.com ([138.120.49.59]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA166A for ; Sat, 15 Jul 2000 08:00:20 -0400 Message-Id: <3970504B.642BCD14@newbridge.com> Date: Sat, 15 Jul 2000 07:51:40 -0400 From: "HANSEN CHAN" X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mpls@UU.NET Subject: LDP/RSVP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi folks, I heard that there're some live MPLS network deploying LDP at the edge and RSVP at the core. Do it mean that a LSP is established edge to edge, part of it is done by LDP and part of it is done by RSVP? Or it is 3 separate LSPs established separately and somehow was spliced together (like having 3 separate MPLS domains in the same physical network own by one network operator)? What might be the advantage of doing that? Appreciate any insight. Cheers, Hansen From owner-mpls@UU.NET Sun Jul 16 00:49: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 AAA06417 for ; Sun, 16 Jul 2000 00:49:19 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyat15681; Sun, 16 Jul 2000 04:48:58 GMT Received: by mail-control.mail.uu.net id QQiyat22517 for mpls-outgoing; Sun, 16 Jul 2000 04:48: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 QQiyat22506 for ; Sun, 16 Jul 2000 04:48: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 QQiyat15037 for ; Sun, 16 Jul 2000 00:48:03 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiyat27827 for ; Sun, 16 Jul 2000 04:47:48 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id VAA10772 for ; Sat, 15 Jul 2000 21:48:00 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id AAA05697 for mpls@uu.net; Sun, 16 Jul 2000 00:47:46 -0400 (EDT) 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 QQixwr09087 for ; Sat, 15 Jul 2000 02:27: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 QQixwr21096 for ; Fri, 14 Jul 2000 22:27:16 -0400 (EDT) Received: from server.nayna.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 69.35.dsl.popsite.net [64.24.69.35]) id QQixwr13883 for ; Sat, 15 Jul 2000 02:27:16 GMT Received: from hp900 (69.34.dsl.popsite.net [64.24.69.34]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id TAA16111; Fri, 14 Jul 2000 19:24:19 -0700 X-Authentication-Warning: server.nayna.com: Host 69.34.dsl.popsite.net [64.24.69.34] claimed to be hp900 Message-ID: <005c01bfedeb$b273e360$6a80000a@netlab.ohiostate.edu> From: "Raj Jain" To: Cc: Subject: New I-D: IP over Optical Networks - Summary of Issues Date: Fri, 14 Jul 2000 19:31:55 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0059_01BFEDCA.2B2FE8C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0059_01BFEDCA.2B2FE8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit An Internet Draft entitled "IP over Optical Networks: A Summary of Issues," draft-osu-ipo-mpls-issues-00.txt has been submitted to the IETF and it will be available from the repositories in a while. In the mean time, I have placed a copy at: http://www.cis.ohio-state.edu/~jain/ietf/issues.htm This copy has some minor/editorial errors corrected that were noticed after the submission to IETF. Thanks. Raj Jain ----------------------------------------------------------------- Raj Jain Chief Technology Officer Nayna Networks, Inc. 157 Topaz St. Milpitas, CA 95035 Phone: 408-956-8000X309 Fax: 408-956-8730 Email: raj@nayna.com ------=_NextPart_000_0059_01BFEDCA.2B2FE8C0 Content-Type: text/x-vcard; name="Raj Jain.vcf" Content-Disposition: attachment; filename="Raj Jain.vcf" Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Jain;Raj FN:Raj Jain EMAIL;PREF;INTERNET:jain@cis.ohio-state.edu REV:20000714T233155Z END:VCARD ------=_NextPart_000_0059_01BFEDCA.2B2FE8C0-- From owner-mpls@UU.NET Sun Jul 16 02:48: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 CAA05339 for ; Sun, 16 Jul 2000 02:48:11 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiybb03053; Sun, 16 Jul 2000 06:47:49 GMT Received: by mail-control.mail.uu.net id QQiybb21115 for mpls-outgoing; Sun, 16 Jul 2000 06:47: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 QQiybb21110 for ; Sun, 16 Jul 2000 06:47:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiybb28335 for ; Sun, 16 Jul 2000 02:47:15 -0400 (EDT) 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 QQiybb02666 for ; Sun, 16 Jul 2000 06:47:15 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id CAA24791 for mpls@uu.net; Sun, 16 Jul 2000 02:47:14 -0400 (EDT) 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 QQiybb21097 for ; Sun, 16 Jul 2000 06:46: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 QQiybb25787 for ; Sun, 16 Jul 2000 02:46:42 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiybb02255 for ; Sun, 16 Jul 2000 06:46:27 GMT Received: from krakow.cisco.com (krakow.cisco.com [171.69.71.26]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id XAA28924; Sat, 15 Jul 2000 23:46:39 -0700 (PDT) Received: from cisco.com (rraszuk-dsl1.cisco.com [10.19.31.90]) by krakow.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id XAA02437; Sat, 15 Jul 2000 23:46:41 -0700 (PDT) Message-ID: <39715A40.235311B7@cisco.com> Date: Sat, 15 Jul 2000 23:46:24 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: HANSEN CHAN CC: mpls@UU.NET Subject: Re: LDP/RSVP References: <3970504B.642BCD14@newbridge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hansen, Your question is not very clear as you are not indicating what MPLS application(s) are being used in those "live MPLS networks" you are referring to. One of the possible architecture which may use LDP/RSVP in the way you have described could be mpls-vpns with TE tunnels starting/ending either from/on PE or P routers. In that scenario you would still be running LDP in your entire domain. In addition to LDP to benefit from all TE capabilities you can use RSVP to establish tunnels and by running a directed LDP session via those tunnels be able to transport your VPN packets via those tunnels. Second possibility could be establishment of 3 separate TE LSPs and "gluing" them together with LDP by using label stacking capabilities of MPLS. That trick could be used for example to build TE tunnel across multiple IGP areas/levels. R. > HANSEN CHAN wrote: > > Hi folks, > > I heard that there're some live MPLS network deploying LDP at the edge > and RSVP at the core. Do it mean that a LSP is established edge to edge, > part of it is done by LDP and part of it is done by RSVP? Or it is 3 > separate LSPs established separately and somehow was spliced together > (like having 3 separate MPLS domains in the same physical network own by > one network operator)? > > What might be the advantage of doing that? Appreciate any insight. > > Cheers, > Hansen From owner-mpls@UU.NET Sun Jul 16 10:34: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 KAA18860 for ; Sun, 16 Jul 2000 10:34:04 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiycg03696; Sun, 16 Jul 2000 14:33:42 GMT Received: by mail-control.mail.uu.net id QQiycg13082 for mpls-outgoing; Sun, 16 Jul 2000 14:33: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 QQiycg13077 for ; Sun, 16 Jul 2000 14:32:59 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiycg07295 for ; Sun, 16 Jul 2000 10:32:44 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiycg22797 for ; Sun, 16 Jul 2000 14:32:43 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA26201 for ; Sun, 16 Jul 2000 07:32:55 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA07324 for mpls@uu.net; Sun, 16 Jul 2000 10:32:41 -0400 (EDT) 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 QQiybx15266 for ; Sun, 16 Jul 2000 12:15: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 QQiybw25207 for ; Sun, 16 Jul 2000 08:14:54 -0400 (EDT) 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 QQiybw24140 for ; Sun, 16 Jul 2000 12:14:54 GMT Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id IAA12415 for ; Sun, 16 Jul 2000 08:08:04 -0400 (EDT) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdAAARGIMN_; Sun Jul 16 08:07:57 2000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Sun, 16 Jul 2000 08:14:25 -0400 Received: from newbridge.com ([138.120.49.42]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA398D; Sun, 16 Jul 2000 08:14:59 -0400 Message-Id: <3971A537.AACCBF89@newbridge.com> Date: Sun, 16 Jul 2000 08:06:16 -0400 From: "HANSEN CHAN" X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: raszuk@cisco.com, mpls@UU.NET Subject: Re: LDP/RSVP References: <3970504B.642BCD14@newbridge.com> <39715A40.235311B7@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Robert, To my understanding, the application is TE, not IP VPN. Cheers, Hansen Robert Raszuk wrote: > Hansen, > > Your question is not very clear as you are not indicating what MPLS > application(s) are being used in those "live MPLS networks" you are referring > to. > > One of the possible architecture which may use LDP/RSVP in the way you have > described could be mpls-vpns with TE tunnels starting/ending either from/on PE > or P routers. In that scenario you would still be running LDP in your entire > domain. In addition to LDP to benefit from all TE capabilities you can use RSVP > to establish tunnels and by running a directed LDP session via those tunnels be > able to transport your VPN packets via those tunnels. > > Second possibility could be establishment of 3 separate TE LSPs and "gluing" > them together with LDP by using label stacking capabilities of MPLS. That trick > could be used for example to build TE tunnel across multiple IGP areas/levels. > > R. > > > HANSEN CHAN wrote: > > > > Hi folks, > > > > I heard that there're some live MPLS network deploying LDP at the edge > > and RSVP at the core. Do it mean that a LSP is established edge to edge, > > part of it is done by LDP and part of it is done by RSVP? Or it is 3 > > separate LSPs established separately and somehow was spliced together > > (like having 3 separate MPLS domains in the same physical network own by > > one network operator)? > > > > What might be the advantage of doing that? Appreciate any insight. > > > > Cheers, > > Hansen From owner-mpls@UU.NET Sun Jul 16 14:56: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 OAA26199 for ; Sun, 16 Jul 2000 14:56:40 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiycx18161; Sun, 16 Jul 2000 18:56:20 GMT Received: by mail-control.mail.uu.net id QQiycx06469 for mpls-outgoing; Sun, 16 Jul 2000 18:56:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiycx06461 for ; Sun, 16 Jul 2000 18:55: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 QQiycx00019 for ; Sun, 16 Jul 2000 14:55:29 -0400 (EDT) Received: from mailrelay.laurelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laurelnetworks.com [206.67.234.84]) id QQiycx18686 for ; Sun, 16 Jul 2000 18:55:29 GMT Received: from laurel6btlsnsg (laurel-6btlsnsg.laurelnetworks.com [192.168.0.69]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with SMTP id OAA11367; Sun, 16 Jul 2000 14:55:26 -0400 From: "Robert Rennison" To: "Lou Berger" Cc: "Chatterjee, Shash" , "MPLS Mailing-list \(E-mail\)" Subject: RE: draft-ashwood-generalized-mpls-signaling- (was Re: Optical MPLS) Date: Sun, 16 Jul 2000 14:57:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20000714175223.00d416a0@mail.labn.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lou, I believe that any confusion is caused by the following statement in section 3.2.2. "The presence of both a generalized and normal label object in a Path/REQUEST message is a protocol error and should be treated as a malformed message by the recipient." This explicitly states that only the presence of _both_ the generalized and normal label object is a Path/REQUEST message is an error. This did seem like an odd statement, why would you worry about both of the label and generalized label being in the Path/REQUEST message. I therefore inferred that the generalized label could be used in the Path/REQUEST message to hint to the downstream node the upstreams preference, in essence the functionality you have with the separate object called the Suggested Label. I am curious, why did you specify a new TLV, the suggested label, which is identical to that of the generalized label, instead of merely allowing the generalized label to be sent in the downstream direction to achieve this functionality. Error handling procedures perhaps ? There is precedent in other signaling protocols for overloading of the generalized label TLV, consider the mechanism in ATM signaling, whereby the user side of a Q.2931 link was allowed to include the connid info element in the initial SETUP message. This was also the technique used in non-facility associated signalling. Regards. Rob --------------- Robert Rennison Laurel Networks Ph: (724) 933-7330 Fax: (724) 933-3377 robren@laurelnetworks.com From owner-mpls@UU.NET Sun Jul 16 23:53: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 XAA00119 for ; Sun, 16 Jul 2000 23:53:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyeh16319; Mon, 17 Jul 2000 03:53:16 GMT Received: by mail-control.mail.uu.net id QQiyeh10545 for mpls-outgoing; Mon, 17 Jul 2000 03:52: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 QQiyeh10540 for ; Mon, 17 Jul 2000 03:52: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 QQiyeh24473 for ; Sun, 16 Jul 2000 23:52:19 -0400 (EDT) Received: from zrtps06s.us.nortel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [47.140.48.50]) id QQiyeh16032 for ; Mon, 17 Jul 2000 03:52:04 GMT Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Sun, 16 Jul 2000 23:37:55 -0400 Received: by ZRTPD004 with Internet Mail Service (5.5.2650.21) id ; Sun, 16 Jul 2000 23:32:37 -0400 Message-ID: <03E3E0690542D211A1490000F80836F4029F9807@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'Robert Rennison'" , Lou Berger Cc: "Chatterjee, Shash" , "MPLS Mailing-list (E-mail)" Subject: RE: draft-ashwood-generalized-mpls-signaling- (was Re: Optical MP LS) Date: Sun, 16 Jul 2000 23:32:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFEF9F.A6ED2A64" 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_01BFEF9F.A6ED2A64 Content-Type: text/plain; charset="iso-8859-1" I think that's a typo. You should not have a generalized and normal label in a "RESV/Mapping" because it is ambiguous. The suggested label is the mechanism for "hinting" as you say to the downstream neighbor as to a preferred label. As to using a new object for the suggested label. Its just cleaner. The object has the same format, it just has a different type/ctype. Personally I prefer to avoid the use of context to imply meaning where possible. In this case it was trivial to make it concrete so we did. Peter -----Original Message----- From: Robert Rennison [SMTP:robren@laurelnetworks.com] Sent: Sunday, July 16, 2000 2:57 PM To: Lou Berger Cc: Chatterjee, Shash; MPLS Mailing-list (E-mail) Subject: RE: draft-ashwood-generalized-mpls-signaling- (was Re: Optical MPLS) Lou, I believe that any confusion is caused by the following statement in section 3.2.2. "The presence of both a generalized and normal label object in a Path/REQUEST message is a protocol error and should be treated as a malformed message by the recipient." This explicitly states that only the presence of _both_ the generalized and normal label object is a Path/REQUEST message is an error. This did seem like an odd statement, why would you worry about both of the label and generalized label being in the Path/REQUEST message. I therefore inferred that the generalized label could be used in the Path/REQUEST message to hint to the downstream node the upstreams preference, in essence the functionality you have with the separate object called the Suggested Label. I am curious, why did you specify a new TLV, the suggested label, which is identical to that of the generalized label, instead of merely allowing the generalized label to be sent in the downstream direction to achieve this functionality. Error handling procedures perhaps ? There is precedent in other signaling protocols for overloading of the generalized label TLV, consider the mechanism in ATM signaling, whereby the user side of a Q.2931 link was allowed to include the connid info element in the initial SETUP message. This was also the technique used in non-facility associated signalling. Regards. Rob --------------- Robert Rennison Laurel Networks Ph: (724) 933-7330 Fax: (724) 933-3377 robren@laurelnetworks.com ------_=_NextPart_001_01BFEF9F.A6ED2A64 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ashwood-generalized-mpls-signaling- (was Re: Optical = MPLS)

I think that's a typo. You should not = have a generalized and normal label in a "RESV/Mapping" because it is = ambiguous.

The suggested label is the mechanism = for "hinting" as you say to the downstream neighbor as to a preferred = label.

As to using a new object for the = suggested label. Its just cleaner. The object has the same format, it = just has a different type/ctype. Personally I prefer to avoid the use = of context to imply meaning where possible. In this case it was trivial = to make it concrete so we did.

Peter

    -----Original = Message-----
    From:   Robert Rennison = [SMTP:robren@laurelnetworks.com]
    Sent:   Sunday, July 16, 2000 2:57 PM
    To:     Lou Berger
    Cc:     Chatterjee, Shash; MPLS Mailing-list (E-mail)
    Subject:       = RE: = draft-ashwood-generalized-mpls-signaling- (was Re: Optical MPLS)

    Lou,

    I believe that any confusion is  = caused by the following  statement in
    section
    3.2.2.

    "The presence of both a = generalized and normal label object in a
    Path/REQUEST message is a protocol = error and should be treated as a
    malformed message by the = recipient."

    This explicitly states that only the = presence of _both_ the
    generalized and normal label object = is a Path/REQUEST message is an error.

    This did seem like an odd statement, = why would you worry about both of
    the label and generalized label being = in the Path/REQUEST message.

    I therefore inferred that the = generalized label could be used in
    the Path/REQUEST message to hint to = the downstream node the upstreams
    preference, in essence the = functionality you have with the separate object
    called the Suggested Label.

    I am curious, why did you specify a = new TLV, the suggested label, which is
    identical to that of the generalized = label, instead of
    merely allowing the generalized label = to be sent in the downstream direction
    to achieve this functionality. Error = handling procedures perhaps ?

    There is precedent in other signaling = protocols for overloading of the
    generalized label TLV,
     consider the mechanism in ATM = signaling, whereby the user side
    of a Q.2931 link was allowed to = include the connid info element in the
    initial
    SETUP message. This was also the = technique used in non-facility associated
    signalling.

    Regards.

    Rob

    ---------------
    Robert Rennison

    Laurel Networks
    Ph:  (724) 933-7330
    Fax: (724) 933-3377
    robren@laurelnetworks.com


------_=_NextPart_001_01BFEF9F.A6ED2A64-- From owner-mpls@UU.NET Mon Jul 17 06:40: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 GAA25239 for ; Mon, 17 Jul 2000 06:40:45 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyfi11519; Mon, 17 Jul 2000 10:31:13 GMT Received: by mail-control.mail.uu.net id QQiyfi19655 for mpls-outgoing; Mon, 17 Jul 2000 10:30: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 QQiyfi19650 for ; Mon, 17 Jul 2000 10:30: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 QQiyfi06928 for ; Mon, 17 Jul 2000 06:30:29 -0400 (EDT) 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 QQiyfi22111 for ; Mon, 17 Jul 2000 10:30:28 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA25506 for mpls@uu.net; Mon, 17 Jul 2000 06:30:28 -0400 (EDT) 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 QQiyfi19637 for ; Mon, 17 Jul 2000 10:30: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 QQiyfh00583; Mon, 17 Jul 2000 06:29:53 -0400 (EDT) Received: from auemail2.firewall.lucent.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: auemail2.lucent.com [192.11.223.163]) id QQiyfh10902; Mon, 17 Jul 2000 10:29:53 GMT Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA29066; Mon, 17 Jul 2000 06:29:52 -0400 (EDT) Received: from sr0001exch001p.sa.lucent.com (h135-183-8-39.lucent.com [135.183.8.39]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA29003; Mon, 17 Jul 2000 06:29:48 -0400 (EDT) Received: by sr0001exch001p.sa.lucent.com with Internet Mail Service (5.5.2650.21) id <35WPLCYL>; Mon, 17 Jul 2000 13:25:18 +0300 Message-ID: <7B5C7DD03AB8D211A2A10001FA7E11B7037C98FA@sr0001exch002u.sa.lucent.com> From: Hamdan Al Jouir To: mpls-request@UU.NET, mpls@UU.NET Date: Mon, 17 Jul 2000 13:28:25 +0300 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 subscribe From owner-mpls@UU.NET Mon Jul 17 06:44: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 GAA26878 for ; Mon, 17 Jul 2000 06:44:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyfi15224; Mon, 17 Jul 2000 10:43:31 GMT Received: by mail-control.mail.uu.net id QQiyfi20214 for mpls-outgoing; Mon, 17 Jul 2000 10:43:04 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 QQiyfi20209 for ; Mon, 17 Jul 2000 10:42: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 QQiyfi01858 for ; Mon, 17 Jul 2000 06:42:48 -0400 (EDT) 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 QQiyfi01269 for ; Mon, 17 Jul 2000 10:42:47 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA26399 for mpls@uu.net; Mon, 17 Jul 2000 06:42:46 -0400 (EDT) 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 QQiyfi20186 for ; Mon, 17 Jul 2000 10:42: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 QQiyfi08146 for ; Mon, 17 Jul 2000 06:42:13 -0400 (EDT) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQiyfi14814 for ; Mon, 17 Jul 2000 10:42:13 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25905; Mon, 17 Jul 2000 06:42:11 -0400 (EDT) Message-Id: <200007171042.GAA25905@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-hdr-comp-over-ppp-00.txt Date: Mon, 17 Jul 2000 06:42:11 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS/IP Header Compression over PPP Author(s) : L. Berger, J. Jeffords Filename : draft-ietf-mpls-hdr-comp-over-ppp-00.txt Pages : 10 Date : 14-Jul-00 This document describes an option for negotiating the use of MPLS and IP header compression over the Point-to-Point Protocol [STD51]. It defines extensions to the PPP Control Protocol for MPLS [LABELS]. It is based on, and borrows heavily from, IP Header Compression over PPP [RFC2509]. MPLS/IP header compression is defined in [CMPLS] and may be applied to MPLS datagrams transporting IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-hdr-comp-over-ppp-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-ietf-mpls-hdr-comp-over-ppp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-hdr-comp-over-ppp-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: <20000714143816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-hdr-comp-over-ppp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-hdr-comp-over-ppp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714143816.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jul 17 06:44: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 GAA26932 for ; Mon, 17 Jul 2000 06:44:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyfi02311; Mon, 17 Jul 2000 10:44:04 GMT Received: by mail-control.mail.uu.net id QQiyfi20229 for mpls-outgoing; Mon, 17 Jul 2000 10:43: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 QQiyfi20220 for ; Mon, 17 Jul 2000 10:43:35 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyfi08196 for ; Mon, 17 Jul 2000 06:43:23 -0400 (EDT) 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 QQiyfi01547 for ; Mon, 17 Jul 2000 10:43:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA26439 for mpls@uu.net; Mon, 17 Jul 2000 06:43:07 -0400 (EDT) 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 QQiyfi20195 for ; Mon, 17 Jul 2000 10:42: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 QQiyfi08150 for ; Mon, 17 Jul 2000 06:42:18 -0400 (EDT) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQiyfi14782 for ; Mon, 17 Jul 2000 10:42:03 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25822; Mon, 17 Jul 2000 06:42:02 -0400 (EDT) Message-Id: <200007171042.GAA25822@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-diff-ext-06.txt Date: Mon, 17 Jul 2000 06:42:02 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Support of Differentiated Services Author(s) : F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, P. Cheval, R. Krishnan, J. Heinanen Filename : draft-ietf-mpls-diff-ext-06.txt Pages : 52 Date : 14-Jul-00 This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-diff-ext-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-diff-ext-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000714143754.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-diff-ext-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-diff-ext-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714143754.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jul 17 06:44: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 GAA26971 for ; Mon, 17 Jul 2000 06:44:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyfi15631; Mon, 17 Jul 2000 10:44:19 GMT Received: by mail-control.mail.uu.net id QQiyfi20232 for mpls-outgoing; Mon, 17 Jul 2000 10:43: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 QQiyfi20221 for ; Mon, 17 Jul 2000 10:43:35 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyfi08197 for ; Mon, 17 Jul 2000 06:43:23 -0400 (EDT) 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 QQiyfi01548 for ; Mon, 17 Jul 2000 10:43:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA26440 for mpls@uu.net; Mon, 17 Jul 2000 06:43:07 -0400 (EDT) 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 QQiyfi20197 for ; Mon, 17 Jul 2000 10:42: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 QQiyfi01831 for ; Mon, 17 Jul 2000 06:42:23 -0400 (EDT) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQiyfi14800 for ; Mon, 17 Jul 2000 10:42:08 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25888; Mon, 17 Jul 2000 06:42:07 -0400 (EDT) Message-Id: <200007171042.GAA25888@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-hdr-comp-00.txt Date: Mon, 17 Jul 2000 06:42:06 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS/IP Header Compression Author(s) : L. Berger, J. Jeffords Filename : draft-ietf-mpls-hdr-comp-00.txt Pages : 14 Date : 14-Jul-00 This document describes a method for compressing the headers of IP datagrams that are being transported over MPLS. This work extends the existing IP and IP/UDP/RTP header compression techniques, as defined in [RFC2507] and [RFC2508], to operate over and to compress MPLS label stack entries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-hdr-comp-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-ietf-mpls-hdr-comp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-hdr-comp-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: <20000714143804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-hdr-comp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-hdr-comp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714143804.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jul 17 07:22: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 HAA07422 for ; Mon, 17 Jul 2000 07:22:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyfl25172; Mon, 17 Jul 2000 11:21:48 GMT Received: by mail-control.mail.uu.net id QQiyfl03684 for mpls-outgoing; Mon, 17 Jul 2000 11:21:20 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiyfl03679 for ; Mon, 17 Jul 2000 11:21: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 QQiyfl12049 for ; Mon, 17 Jul 2000 07:21:16 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyfl24957 for ; Mon, 17 Jul 2000 11:21:15 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id GAA02490; Mon, 17 Jul 2000 06:20:53 -0500 Message-Id: <4.3.2.7.2.20000717071502.00e35de0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jul 2000 07:21:12 -0400 To: "'Robert Rennison'" From: Lou Berger Subject: RE: draft-ashwood-generalized-mpls-signaling- (was Re: Optical MP LS) Cc: Lou Berger , "Chatterjee, Shash" , "MPLS Mailing-list (E-mail)" , "Peter Ashwood-Smith" In-Reply-To: <03E3E0690542D211A1490000F80836F4029F9807@zcard00f.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk One additional point that makes the different objects a requirement (at least for RSVP): error processing is different for the two objects. Per the draft: Generalized Label Class Num = 19 [of form 0bbbbbbb] [...] In RSVP the Suggested Label uses a new class number (TBD of form 10bbbbbb) and the C-type of the label being suggested. [...] See RFC2205 if unclear on the implication of the two forms. Lou At 11:32 PM 7/16/00 -0400, Peter Ashwood-Smith wrote: >[...] >The suggested label is the mechanism for "hinting" as you say to the >downstream neighbor as to a preferred label. > >As to using a new object for the suggested label. Its just cleaner. The >object has the same format, it just has a different type/ctype. Personally >I prefer to avoid the use of context to imply meaning where possible. In >this case it was trivial to make it concrete so we did. > >Peter >-----Original Message----- From: Robert Rennison >[SMTP:robren@laurelnetworks.com] Sent: Sunday, July 16, 2000 2:57 >PM To: Lou Berger Cc: Chatterjee, Shash; MPLS Mailing-list >(E-mail) Subject: RE: draft-ashwood-generalized-mpls-signaling- >(was Re: Optical MPLS) > >Lou, > >I believe that any confusion is caused by the following statement >in section 3.2.2. > >"The presence of both a generalized and normal label object in >a Path/REQUEST message is a protocol error and should be treated as >a malformed message by the recipient." > >This explicitly states that only the presence of _both_ the generalized >and normal label object is a Path/REQUEST message is an error. > >This did seem like an odd statement, why would you worry about both >of the label and generalized label being in the Path/REQUEST message. > >I therefore inferred that the generalized label could be used in the >Path/REQUEST message to hint to the downstream node the >upstreams preference, in essence the functionality you have with the >separate object called the Suggested Label. > >I am curious, why did you specify a new TLV, the suggested label, which >is identical to that of the generalized label, instead of merely >allowing the generalized label to be sent in the downstream direction to >achieve this functionality. Error handling procedures perhaps ? > >There is precedent in other signaling protocols for overloading of >the generalized label TLV, consider the mechanism in ATM signaling, >whereby the user side of a Q.2931 link was allowed to include the connid >info element in the initial SETUP message. This was also the technique >used in non-facility associated signalling. > >Regards. > >Rob > >--------------- Robert Rennison > >Laurel Networks Ph: (724) 933-7330 Fax: (724) >933-3377 robren@laurelnetworks.com From owner-mpls@UU.NET Mon Jul 17 08:51: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 IAA01129 for ; Mon, 17 Jul 2000 08:51:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyfr08957; Mon, 17 Jul 2000 12:50:31 GMT Received: by mail-control.mail.uu.net id QQiyfr20342 for mpls-outgoing; Mon, 17 Jul 2000 12:50:10 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiyfr20327 for ; Mon, 17 Jul 2000 12:50:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyfr16293 for ; Mon, 17 Jul 2000 08:49:47 -0400 (EDT) From: Ted44tedT@netscape.net Received: from imo-d01.mx.aol.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: imo-d01.mx.aol.com [205.188.157.33]) id QQiyfr21493 for ; Mon, 17 Jul 2000 12:49:16 GMT Received: from Ted44tedT@netscape.net by imo-d01.mx.aol.com (mail_out_v27.12.) id 1.b.790ef (16234) for ; Mon, 17 Jul 2000 08:49:11 -0400 (EDT) Received: from netscape.com (aimmail09.aim.aol.com [205.188.144.201]) by air-in02.mx.aol.com (v75_b1.4) with ESMTP; Mon, 17 Jul 2000 08:49:11 -0400 Message-ID: <3E07B52B.11782F39.02882A9A@netscape.net> Date: Mon, 17 Jul 2000 08:50:42 -0400 To: mpls@UU.NET Subject: Explicit Object X-Mailer: Franklin Webmailer 1.0 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 all, Two questions about ERO: 1. In draft-mpls-rsvp-lsp-tunnel-05.txt, section 4.3.2, it says "Certain operations to be performed along the path can be encoded in the ERO". In draft-mpls-rsvp-lsp-tunnel-06.txt, the operations is not mentioned. My questions is: no operation is allowed in new draft or it's still there but not mentioned? 2. In section 4.3.4.1, 3) it says "Next, the node evaluates the second subobject. If the node is also a part of the abstract node described by the second subobject, then the node deletes the first subobject and continues processing with step 2, above." In my understanding, when a node received a Path message with a ERO, it first check the first subobject in the ERO, if the node is a part of the abstract node described by the fisrt subobject, then the node check the second subobject. If no second subobject, ERO is removed by the node. If there is the second subobject, the node should use the second subobject to replace the first subobj or insert the second subobj before the first subobject. Is that correct? What the semantics of "Next, the node evaluates the second subobject. If the node is also a part of the abstract node described by the second subobject" ? Is the node is that received the ERO with the first subobj? If it is, how is it described by the second subobj? I am appreciate for your answer. Thanks Ted ---------- Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/ From owner-mpls@UU.NET Mon Jul 17 09:38: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 JAA10781 for ; Mon, 17 Jul 2000 09:38:41 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyfu12332; Mon, 17 Jul 2000 13:38:18 GMT Received: by mail-control.mail.uu.net id QQiyfu04472 for mpls-outgoing; Mon, 17 Jul 2000 13:37: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 QQiyfu04458 for ; Mon, 17 Jul 2000 13:37:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyfu23780 for ; Mon, 17 Jul 2000 09:37:02 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQiyfu11432 for ; Mon, 17 Jul 2000 13:37:00 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA24686 for ; Mon, 17 Jul 2000 06:37:13 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA10515 for mpls@uu.net; Mon, 17 Jul 2000 09:36:57 -0400 (EDT) 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 QQiycz18873 for ; Sun, 16 Jul 2000 19:26: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 QQiycz02547 for ; Sun, 16 Jul 2000 15:26:24 -0400 (EDT) Received: from wisbech.cl.cam.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mta1.cl.cam.ac.uk [128.232.0.15]) id QQiycz24837 for ; Sun, 16 Jul 2000 19:26:24 GMT Received: from uridium.cl.cam.ac.uk ([128.232.8.49] helo=cl.cam.ac.uk ident=kaf24) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 13Du3S-0000Ny-00; Sun, 16 Jul 2000 20:26:22 +0100 To: mpls@UU.NET cc: Keir.Fraser@cl.cam.ac.uk Subject: New version of `MPLS for Linux' Date: Sun, 16 Jul 2000 20:26:22 +0100 From: Keir Fraser Message-Id: Sender: owner-mpls@UU.NET Precedence: bulk I've just released a new version (1.1) of my `MPLS for Linux' package. The main changes are: * Forwarded MPLS frames now have the correct protocol type set in `skb->protocol'. * I've added a small patch to Alexei Kuznetsov's iproute2 package to make it `MPLS-aware'. * I've corrected and (slightly) extended the documentation. The distribution now contains a postscript copy of it. Pick up the new version from: http://www.cl.cam.ac.uk/Research/SRG/netos/netx/code/mpls-current.tar.gz I hope this is of interest to some people. The number of downloads of version 1.0 would seem to indicate that it is! Please contact me if you have any questions or problems. -- Keir Fraser (Systems Research Group, University of Cambridge) From owner-mpls@UU.NET Mon Jul 17 10:17: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 KAA26726 for ; Mon, 17 Jul 2000 10:17:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyfx04756; Mon, 17 Jul 2000 14:16:40 GMT Received: by mail-control.mail.uu.net id QQiyfx18542 for mpls-outgoing; Mon, 17 Jul 2000 14:16: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 QQiyfx18485 for ; Mon, 17 Jul 2000 14:15: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 QQiyfx06672 for ; Mon, 17 Jul 2000 10:15:53 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiyfx04242 for ; Mon, 17 Jul 2000 14:15:52 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA28597 for ; Mon, 17 Jul 2000 07:16:05 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA10769 for mpls@uu.net; Mon, 17 Jul 2000 10:15:51 -0400 (EDT) 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 QQiyfw17675 for ; Mon, 17 Jul 2000 14:06: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 QQiyfw05027 for ; Mon, 17 Jul 2000 10:06:49 -0400 (EDT) Received: from viva.vivacenet.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: w005.z208036016.sjc-ca.dsl.cnc.net [208.36.16.5]) id QQiyfw29309 for ; Mon, 17 Jul 2000 14:06:18 GMT Received: from AMALIS.vivacenet.com [206.15.159.236] by viva.vivacenet.com with ESMTP (SMTPD32-5.05) id A2D88BA0300; Mon, 17 Jul 2000 07:06:16 -0700 Message-Id: <4.3.2.7.2.20000717094255.00b8b800@mail.northweb.com> X-Sender: Andy.Malis@viva.vivacenet.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jul 2000 09:44:28 -0400 To: mpls@UU.NET From: "Andrew G. Malis" Subject: Fwd: I-D ACTION:draft-malis-sonet-ces-mpls-00.txt Cc: Andy.Malis@vivacenetworks.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk FYI, for those of you not watching each and every Internet Draft announcement. Cheers, Andy ------- Begin of Forwarded Message ------- Delivered-To: malis@northweb.com To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-malis-sonet-ces-mpls-00.txt Date: Fri, 14 Jul 2000 06:55:40 -0400 Sender: nsyracus@cnri.reston.va.us A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SONET/SDH Circuit Emulation Service Over MPLS (CEM) Author(s) : A. Malis, K. Hsu, A. Vernon, S. Vogelsang Filename : draft-malis-sonet-ces-mpls-00.txt Pages : 7 Date : 13-Jul-00 This document describes a method for providing a SONET circuit emulation service across an MPLS network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-malis-sonet-ces-mpls-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-malis-sonet-ces-mpls-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-malis-sonet-ces-mpls-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <20000713145602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-malis-sonet-ces-mpls-00.txt ------- End of Forwarded Message ------- ________________________________________________________________________ Andrew G. Malis Andy.Malis@vivacenetworks.com phone:408-383-7223 Vivace Networks/2730 Orchard Parkway/San Jose, CA 95134/fax:408-904-4748 http://www.vivacenetworks.com From owner-mpls@UU.NET Mon Jul 17 11:20: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 LAA25356 for ; Mon, 17 Jul 2000 11:20:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiygb28484; Mon, 17 Jul 2000 15:20:19 GMT Received: by mail-control.mail.uu.net id QQiygb04331 for mpls-outgoing; Mon, 17 Jul 2000 15:20:02 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiygb04318 for ; Mon, 17 Jul 2000 15:19: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 QQiygb12226 for ; Mon, 17 Jul 2000 11:19:39 -0400 (EDT) Received: from hd2.dot.net.in by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: hd2.vsnl.net.in [202.54.30.2]) id QQiygb27647 for ; Mon, 17 Jul 2000 15:19:33 GMT Received: from hyd.chiplogic.com ([203.197.20.172]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id UAA27728 for ; Mon, 17 Jul 2000 20:46:11 +0530 (IST) Received: from chiplogic.com ([192.168.2.51]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id SAA01144 for ; Mon, 17 Jul 2000 18:45:13 +0530 Message-ID: <397308CE.2EED997E@chiplogic.com> Date: Mon, 17 Jul 2000 18:53:26 +0530 From: phaneesh Organization: Chiplogic (I) Pvt. Ltd. X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {TLC;RETAIL} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "mpls@UU.NET" Subject: Multiple LDP Sessions Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi, I am reading "draft-ietf-mpls-ldp-mib-05.txt", there in page-7 it is said that, "A row in MplsLdpEntityPeerTable may be related to one or more entries in MplsLdpHelloAdjacencyTable  and one or more entries in MplsLdpSessionTable.". Let us take the case MplsLdpSessionTable & MplsLdpEntityPeerTable. Both the tables are using MplsLdpPeerLdpId as an index. We create one and only one session for each MplsLdpPeerLdpId. The same happens, when we create MplsLdpEntityPeerTable entry. Then it should be one-to-one mapping between MplsLdpSessionTable & MplsLdpEntityPeerTable. I will appreciate any comments on the above. Thanks, Phani. From owner-mpls@UU.NET Mon Jul 17 11:35: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 LAA01886 for ; Mon, 17 Jul 2000 11:35:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiygc11996; Mon, 17 Jul 2000 15:33:52 GMT Received: by mail-control.mail.uu.net id QQiygc05254 for mpls-outgoing; Mon, 17 Jul 2000 15:32: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 QQiygc05249 for ; Mon, 17 Jul 2000 15:32: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 QQiygc14511 for ; Mon, 17 Jul 2000 11:32:02 -0400 (EDT) Received: from thumper.research.telcordia.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: thumper.research.telcordia.com [128.96.41.1]) id QQiygc11121 for ; Mon, 17 Jul 2000 15:31:59 GMT Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6HFVnR15329; Mon, 17 Jul 2000 11:31:49 -0400 (EDT) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id LAA00502; Mon, 17 Jul 2000 11:31:49 -0400 (EDT) Message-Id: <200007171531.LAA00502@monday.research.telcordia.com> Date: Mon, 17 Jul 2000 11:31:49 -0400 (EDT) From: Ritu Chadha Reply-To: Ritu Chadha Subject: Policy Information Model for MPLS Traffic Engineering To: policy@raleigh.ibm.com, mpls@UU.NET Cc: chadha@mailee.research.telcordia.com MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Flink_of_Cows_031_000 X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk --Flink_of_Cows_031_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jtU8Zv8aHhuz564OAhAfRA== FYI: The attached draft was submitted on 7/14/00 and will shortly be available in the IETF Internet Drafts repository. Ritu ============================================================================= Ritu Chadha Senior Scientist Telcordia Technologies (973) 829-4869 (voice) MCC 1J-218R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= --Flink_of_Cows_031_000 Content-Type: TEXT/plain; name="draft-chadha-policy-mpls-te-00.txt"; charset=US-ASCII; x-unix-mode=0664 Content-Description: draft-chadha-policy-mpls-te-00.txt Content-MD5: CN9K/f6K4q3CEppeDwXlDw== Content-Transfer-Encoding: QUOTED-PRINTABLE policy/mpls R. Chadha Internet Draft Huai-An (Paul) Lin Expires January 2001 Telcordia Technologies draft-chadha-policy-mpls-te-00.txt July 2000 Policy Information Model for MPLS Traffic Engineering Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The purpose of this draft is to describe an information model for representing MPLS traffic engineering policies. RFC 2702, "Requirements for Traffic Engineering over MPLS", is used as a basis for determining the types of information that need to be represented in such an information model. The latter document describes the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. The information model described in this draft attempts to capture the information required to enable the functional capabilities described in RFC 2702. This information model could be used by a management system to optimize network performance through the necessary network provisioning actions. An overview of policy-based management is given in this document, along with a description of the relationship of this work to other information models that are being defined in the IETF Policy Framework working group. This is followed by a detailed description of the information model, and a number of examples illustrating its use. Chadha Expires January 2001 1 =0C Policy Information Model for MPLS Traffic Engineering July 2000 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1. Introduction.....................................................3 1.1 Terminology....................................................3 1.2 Purpose of this document and Roadmap...........................4 2. Policy-Enabled MPLS Traffic Engineering..........................5 2.1 Relationship to previous work..................................5 2.2 Overview and Scope of this work................................6 3. Overview of MPLS Traffic Engineering Policy Data Model...........7 3.1 Overview of object classes and their associations..............7 3.2 High-level description of information model...................10 4. Detailed Description of MPLS Traffic Engineering Policy Information Model................................................................14 4.1 Object Class MPLSActivateTTAction.............................14 4.2 Object Class MPLSCreateLSPAction..............................16 4.3 Object Class MPLSDestroyLSPAction.............................16 4.4 Object Class MPLSDestroyTTAction..............................17 4.5 Object Class MPLSModifyTTAction...............................18 4.6 Object Class MPLSAssignLSPAction..............................18 4.7 Object Class MPLSDeassignLSPAction............................20 4.8 Object Class MPLSTrafficTrunk.................................21 4.9 Object Class MPLSRoute........................................25 4.10 Object Class MPLSLSP..........................................29 4.11 Object Class MPLSRouteSpec....................................31 4.12 Object Class MPLSResourceProfile..............................31 4.13 Object Class MPLSResources....................................33 4.14 The association MPLSHopInRoute................................35 4.15 The association MPLSASInRoute.................................36 4.16 The association MPLSSystemResources...........................37 4.17 The association MPLSEndpointResources.........................38 4.18 The association MPLSActiveConnection..........................38 4.19 The association MPLSReverseDirTT..............................40 4.20 The association MPLSEligibleRouteSpec.........................41 4.21 The association MPLSCurrentlyAssignedLSP......................42 4.22 The association MPLSBackupLSP.................................43 4.23 The association MPLSRouteResourceProfile......................44 4.24 The association MPLSRealizes..................................45 4.25 The association MPLSLSPinLSP..................................45 4.26 The association MPLSTrafficProfile............................46 5. Usage Examples..................................................47 5.1 Implementing Olympic Services.................................47 5.2 Creating traffic trunks.......................................54 5.3 Load balancing................................................57 5.4 Implementing Service Level Agreements (SLAs)..................57 6. Security Considerations.........................................58 7. Conclusions.....................................................58 8. References......................................................58 Chadha Expires January 2001 2 =0C Policy Information Model for MPLS Traffic Engineering July 2000 9. Acknowledgments.................................................60 10. Author's Addresses.............................................60 1. Introduction According to [3], Traffic Engineering (TE) is concerned with performance optimization of operational networks. In general, it encompasses the application of technology and scientific principles to the measurement, modeling, characterization, and control of Internet traffic, and the application of such knowledge and techniques to achieve specific performance objectives. The aspects of traffic engineering that are of interest for MPLS are measurement and control. A major goal of Internet traffic engineering is to facilitate efficient and reliable network operations while simultaneously optimizing network resource utilization and traffic performance. Traffic engineering has become an indispensable function in many large autonomous systems because of the high cost of network assets and the commercial and competitive nature of the Internet. These factors emphasize the need for maximal operational efficiency. The concept of MPLS traffic trunks is used extensively in the remainder of this document. According to Li and Rekhter [4], a traffic trunk is an aggregation of traffic flows of the same class which are placed inside a Label Switched Path. Essentially, a traffic trunk is an abstract representation of traffic to which specific characteristics can be associated. It is useful to view traffic trunks as objects that can be routed; that is, the path through which a traffic trunk traverses can be changed. In this respect, traffic trunks are similar to virtual circuits in ATM and Frame Relay networks. It is important, however, to emphasize that there is a fundamental distinction between a traffic trunk and the path, and indeed the LSP, through which it traverses. An LSP is a specification of the label switched path through which the traffic traverses. 1.1 Terminology The following abbreviations are used in this document: AS Autonomous System ATM Asynchronous Transfer Mode CIM Common Information Model CLI Command Line Interface COPS Common Open Policy Service DMTF Distributed Management Task Force FEC Forwarding Equivalence Class LDAP Lightweight Directory Access Protocol LSP Label Switched Path LSR Label Switched Router MAM Maximum Allocation Multiplier Chadha Expires January 2001 3 =0C Policy Information Model for MPLS Traffic Engineering July 2000 MIB Management Information Base MPLS Multi-Protocol Label Switching PCIM Policy Core Information Model PDP Policy Decision Point QoS Quality of Service QPIM QoS Policy Information Model SLA Service Level Agreement SNMP Simple Network Management Protocol TE Traffic Engineering WG Work Group 1.2 Purpose of this document and Roadmap This document presents an object-oriented information model for representing MPLS traffic engineering policy information. The model is based on the Policy Core Information Model [5] currently being jointly developed by the IETF Policy Framework WG and by the Distributed Management Task Force (DMTF) as part of the CIM (Common Information Model) extensions work. Our model defines two hierarchies of object classes: structural classes representing policy information and MPLS-specific objects referenced by these policies; and association classes that indicate how instances of the structural classes are related to each other. Subsequent documents will define mappings of this information model to various concrete implementations, for example, to a directory that uses LDAPv3 as its access protocol. The policy core information model is sufficiently generic to represent policies related to practically anything. Extensions of this model for representing QoS policies are being developed by the IETF Policy Framework WG [6]. The IETF IPSec Policy (ipsp) WG is also working on defining an information model for representing IPSec policies. This document derives object classes from the Policy Core Information Model and also makes use of some object classes from the QoS information model [6]. This document is organized in the following manner: - Section 2 describes the relationship of this work to previous work, provides a general overview of policies and how they are modeled. - Section 3 presents a high-level overview of the classes and associations comprising the Policy Information Model for MPLS Traffic Engineering. - Section 4 presents the detailed specifications for each of the object classes and associations in the data model. - Section 5 provides detailed examples illustrating the use of the Policy Information Model for MPLS Traffic Engineering. Chadha Expires January 2001 4 =0C Policy Information Model for MPLS Traffic Engineering July 2000 2. Policy-Enabled MPLS Traffic Engineering 2.1 Relationship to previous work As described in the Policy Core Information Model (PCIM) [5], policies can be regarded as rules with two basic components: conditions and actions. Conditions are boolean expressions which evaluate to either true or false. Actions represent some concrete action that should be taken by a management system if the conditions in the rule evaluate to true. The policy framework described in PCIM provides an elaborate mechanism for prioritizing policy rules; specifying time periods during which policy rules are applicable; specifying complex boolean conditions using either disjunctive normal form or conjunctive normal form and negations; grouping policies together; specifying reusable conditions and actions; etc. Policies are specified using a declarative rather than a procedural approach, i.e. policies describe the conditions and actions that make up a rule, but do not give a step-by-step description of how to implement the policy. In the QoS Policy Information Model (QPIM) [6], new object classes are defined to model the management and configuration of Diffserv- and RSVP-capable network elements. Apart from QoS-specific information, the model contains a number of concepts that are rather general and can be re-used in a number of different contexts. One such concept is that of variables and constants with well-defined semantics that represent things like IP addresses, port numbers, protocol numbers, etc. These variables are used to describe traffic classifiers in QPIM. Such a representation is also very useful for the information model described in this draft, as there is a need to define the FECs (Forwarding Equivalence Classes) that map to given traffic trunks. Other concepts that are re-used from QPIM are those defining traffic profiles and policing actions (see object classes qosPolicyPRTrfcProf and qosPolicyPRAction in [6]). These are used here for describing the traffic profiles of traffic trunks, and the policing requirements for traffic trunks (including what to do with non-conforming traffic for a given traffic trunk). Earlier Internet drafts ([13, 14]) discuss policy for MPLS. [13] outlines requirements for policy-enabled MPLS and identifies two main categories of MPLS policies: LSP admission policies that map traffic flows onto LSPs, and LSP life cycle policies that affect LSP creation, deletion, configuration and monitoring. The information model presented in the current draft addresses both these categories of policies, excluding any monitoring requirements. In [14], the authors discuss policies for MPLS load balancing. The information model that we present is broader in scope and addresses all aspects of traffic engineering, including load balancing. Chadha Expires January 2001 5 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The information model in this draft builds upon the PCIM model and further refines it by adding new actions that are specific to the domain of MPLS traffic engineering. Actions are included for creating, modifying, and destroying traffic trunks and LSPs, and assigning LSPs to traffic trunks. Also, new object classes and associations are introduced to model MPLS traffic engineering concepts referenced by these actions, such as traffic trunks, route specifications, LSPs and their hops, resources and resource classes, etc. No attempt is made to define new object classes for representing classifier information as this is currently being addressed in QPIM. 2.2 Overview and Scope of this work This information model presented in this draft has been designed to support the functionality outlined in RFC 2702 [3]. The latter document describes the following notions which have been modeled in this document: - Basic traffic engineering attributes of traffic trunks - Basic operations on traffic trunks - Traffic parameter attributes - Generic path selection and management attributes - Resource attributes. This information model currently does not cover modeling of LSP monitoring and operational attributes (such as LSP lifetime, error statistics, etc.). Further, this document does not seek to select mechanisms for performing MPLS traffic engineering; rather, it enables the specification of MPLS traffic engineering policies by defining an information model that attempts to capture the information required to describe such policies. Thus, even though MPLS supports traffic engineering via a number of mechanisms (CR- LDP, RSVP) that allow LSPs to be managed, such mechanisms are not referenced in this information model. This is in conformance with the requirement in [13] that an MPLS policy information model should be independent of the MPLS mechanisms used. The policy actions described in this draft enable the specification of actions that create, modify, and destroy traffic trunks and LSPs; and assign/de-assign LSPs to/from traffic trunks (object classes MPLSActivateTTAction, MPLSCreateLSPAction, MPLSDestroyLSPAction, MPLSDestroyTTAction, MPLSModifyTTAction, MPLSAssignLSPAction, and MPLSDeassignLSPAction). These actions reference and manipulate traffic trunks, LSPs, and related objects and associations. The idea is that a traffic engineering management system would be able to specify policies that result in the manipulation of traffic trunks, LSPs, and related information. The implementation of the policies would be performed by a PDP (Policy Decision Point) (see [7]). The PDP could make use of mechanisms supported by network elements to implement the specified policies; e.g. COPS, SNMP, CLI, etc. Several MIBs have been defined that could be used for implementing such Chadha Expires January 2001 6 =0C Policy Information Model for MPLS Traffic Engineering July 2000 policies, namely the MPLS Traffic Engineering MIB [8] and the MPLS LSR MIB [9], etc. 3. Overview of MPLS Traffic Engineering Policy Data Model 3.1 Overview of object classes and their associations The following figures show some of the new object classes and associations defined for the MPLS Traffic Engineering Policy Information Model. Some of these were briefly mentioned in the previous section. A number of object classes from previously defined information models, namely CIM [10] and QPIM [6], are also shown where necessary to illustrate new associations relating newly defined structural object classes to object classes previously defined in those information models. Object classes belonging to these information models are appropriately marked. A detailed description of the depicted object classes is provided in Section 4 of this document. +-----------------------------+ | qosPolicyPRTrfcProf (QPIM) | +-----------^-----------------+ 0..1| (a) | ---------- *| 0..1| | +-----------v---------v-+ | (b) | MPLSTrafficTrunk <------- | | 0..1 +-^-----------------^--^+ *| *| *| | | | (c) | (d)| |(e) | | | (f) | | | ---------- *| *| *| * | | +-----------------v-----+ * (g)* +-v--v-------------v----+ | | MPLSRouteSpec <---------> MPLSLSP <---- +-----------------------+ +-----------------------+ * Figure 1. Relationships between traffic trunks, LSPs, route specifications, and traffic profiles In Figures 1 and 2, boxes represent object classes and arrows represent associations between the classes. The following associations appear in Figure 1 above: (a) MPLSTrafficProfile (b) MPLSReverseDirTT (c) MPLSEligibleRouteSpec (d) MPLSCurrentlyAssignedLSP (e) MPLSBackupLSP Chadha Expires January 2001 7 =0C Policy Information Model for MPLS Traffic Engineering July 2000 (f) MPLSLSPinLSP (g) MPLSRealizes An association represents a relationship between two classes (e.g. associations (a), (c), (d), (e), and (g) above in Figure 1), or between a class and itself (e.g. associations (b) and (f) in Figure 1). Cardinalities are part of each association; the cardinality of an association indicates how many instances of each class may be related to an instance of the other class. For example, the MPLSBackupLSP association has the cardinality "*" (i.e. "0..n") for both the MPLSTrafficTrunk and the MPLSLSP classes. These ranges are interpreted as follows: - The "*" written next to MPLSTrafficTrunk indicates that an MPLSLSP may be related to no MPLSTrafficTrunk, to one MPLSTrafficTrunk, or to more than one MPLSTrafficTrunk via the MPLSBackupLSP association. In other words, an LSP may be a backup LSP for zero or more traffic trunks. - The "*" written next to MPLSLSP indicates that a MPLSTrafficTrunk may be related to no MPLSLSP, to one MPLSLSP, or to more than one MPLSLSP via the MPLSBackupLSP association. In other words, a traffic trunk may have zero or more backup LSPs. ----------- (h)| | *| | +----------------+ +---------------v--+ | |ComputerSystem | | ProtocolEndpoint <------| | (CIM) | | (CIM) |* +----------- ^---+ +^---------^-------+ *| *| *| (i)| (j)| (k)| 0..1| 0..1| *| +----v-----------v+ +-v------------+ | MPLSResources | | MPLSRoute | +-----------------+ +^----------^--+ *| *| (l)| (m)| *| 0..1| +----------------------v+ +----v----------------+ | AutonomousSystem (CIM)| | MPLSResourceProfile | +-----------------------+ +---------------------+ Figure 2. Relationships between routes, hops, resources, etc. The following associations appear in Figure 2 above: (h) MPLSActiveConnection (i) MPLSSystemResources (j) MPLSEndpointResources (k) MPLSHopInRoute (l) MPLSASInRoute Chadha Expires January 2001 8 =0C Policy Information Model for MPLS Traffic Engineering July 2000 (m) MPLSRouteResourceProfile The inheritance tree for the object classes defined in this document is given below. Apart from the new object classes defined in this document, the tree below contains references to object classes defined in the Policy Core Information Model [5], marked "PCIM" below, and to object classes defined in the Common Information Model [10], marked "CIM" below. For detailed descriptions of these object classes, please see the relevant documents. +--Policy (abstract) (PCIM) | | | +---PolicyAction (PCIM) | | | | | +---MPLSActivateTTAction | | | | | +---MPLSCreateLSPAction | | | | | +---MPLSDestroyLSPAction | | | | | +---MPLSDestroyTTAction | | | | | +---MPLSModifyTTAction | | | | | +---MPLSAssignLSPAction | | | | | +---MPLSDeassignLSPAction | | | +--- MPLSResourceProfile | +--CIM_ManagedSystemElement (abstract) (CIM) | +--CIM_LogicalElement (abstract) (CIM) | +--MPLSResources | +--MPLSTrafficTrunk | +--MPLSRoute (abstract) | +---MPLSRouteSpec | +---MPLSLSP Figure 3. Inheritance Hierarchy for MPLS Policy object classes In CIM, associations are also modeled as classes. For the MPLS Traffic Engineering Policy Information Model, the inheritance hierarchy is shown below: Chadha Expires January 2001 9 =0C Policy Information Model for MPLS Traffic Engineering July 2000 [unrooted] | +---MPLSHopInRoute | +---MPLSASInRoute | +---MPLSSystemResources | +---MPLSEndpointResources | +---ActiveConnection (CIM) | | | +---MPLSActiveConnection | +---MPLSReverseDirTT | +---MPLSEligibleRouteSpec | +---MPLSCurrentlyAssignedLSP | +---MPLSBackupLSP | +---MPLSRouteResourceProfile | +---MPLSRealizes | +---MPLSLSPinLSP | +---MPLSTrafficProfile Figure 4. Inheritance Hierarchy for associations 3.2 High-level description of information model 3.2.1 MPLS Traffic Engineering Policy Actions A number of policy actions are defined for the purpose of enabling a management system to manipulate traffic trunks and LSPs. These actions may reference instances of traffic trunks, LSPs, and route specifications (see definition of route specification in Section 3.2.2). In order to reference such instances, they must first be created and populated; and any related objects and associations must also be instantiated and populated. For example, MPLSActivateTTAction activates a traffic trunk; the property mpTrafficTrunk in this action references an instance of a traffic trunk that is to be activated. Thus before instantiating an instance of MPLSActivateTTAction, one must instantiate an instance of MPLSTrafficTrunk that will be referenced by this action. In addition, all the related object instances and associations must also be instantiated before instantiating this action. RFC 2702 [3] Chadha Expires January 2001 10 =0C Policy Information Model for MPLS Traffic Engineering July 2000 describes the difference between establishing a traffic trunk (which we model by creating an instance of MPLSTrafficTrunk and related classes as described in Section 3.2.1.1) and activating a traffic trunk (which is modeled by the MPLSActivateTTAction). 3.2.1.1 Referencing traffic trunks The following objects may need to be instantiated in order to fully describe a traffic trunk referenced by an action: - Route specifications: Zero or more route specifications (MPLSRouteSpec) can be associated with a traffic trunk to indicate that this is a potential route to which this traffic trunk can be mapped. The association is modeled by the MPLSEligibleRouteSpec association. - Traffic profile: A traffic profile (qosPolicyPRAction) describing the resource requirements of a traffic trunk can be defined for every traffic trunk and associated with the traffic trunk via the MPLSTrafficProfile association. - Assigned LSPs: Any LSPs (MPLSLSP) currently assigned to a traffic trunk can be defined and associated with it via the MPLSCurrentlyAssignedLSP association. - Backup LSPs: Any LSPs (MPLSLSP) that are acting as backup LSPs for a traffic trunk can be defined and associated with it via the MPLSBackupLSP association. - Reverse traffic trunk: If a traffic trunk carrying traffic in the reverse direction exists, it can be associated with a given traffic trunk via the MPLSReverseDirTT association. 3.2.1.2 Referencing LSPs The following objects may need to be instantiated in order to fully describe an LSP referenced by an action: - Route specifications: Zero or more route specifications (MPLSRouteSpec) can be associated with an LSP to indicate that this LSP is an realization of the route specification. The association is modeled by the MPLSRealizes association. - Traffic trunks: Any traffic trunks (MPLSTrafficTrunk) whose traffic is currently being carried by an LSP should be defined and associated with this LSP via the MPLSCurrentlyAssignedLSP association. Further, any traffic trunks for which an LSP is a backup LSP should be associated with this LSP via the MPLSBackupLSP association. Chadha Expires January 2001 11 =0C Policy Information Model for MPLS Traffic Engineering July 2000 - LSP hierarchy: If a hierarchy of LSPs exists, an LSP should be associated with any LSPs contained in or containing it via the MPLSLSPinLSP association. - Resource profile: A resource profile (MPLSResourceProfile) describing the resource profile of an LSP can be defined for every LSP and associated with it via the MPLSRouteResourceProfile association. - Route hops: Every known hop in an LSP is represented by an instance of ProtocolEndpoint (from the CIM information model; see [10]) and is associated with an LSP via the MPLSHopInRoute association. - Autonomous systems in LSP path: If the path of an LSP through an external autonomous system is unknown, this autonomous system is represented by an instance of AutonomousSystem (from the CIM information model; see [10]) and is associated with an LSP via the MPLSASInRoute association. 3.2.1.3 Referencing route specifications The following objects may need to be instantiated in order to fully describe a route specification referenced by an action: - LSPs: Zero or more LSPs (MPLSLSP) can be associated with a route specification to indicate that these LSPs are realizations of the route specification. The association is modeled by the MPLSRealizes association. - Traffic trunks: Traffic trunks (MPLSTrafficTrunk) for which a given route specification is a potential route should be associated with the route specification via the MPLSEligibleRouteSpec association. - Resource profile: A resource profile (MPLSResourceProfile) describing the resource profile of a route specification can be defined for every route specification and associated with it via the MPLSRouteResourceProfile association. - Route hops: Every hop specified for a route specification is represented by an instance of ProtocolEndpoint (from the CIM information model; see [10]) and is associated with a route specification via the MPLSHopInRoute association. - Autonomous systems in route path: If a route specification is to be routed via an specified autonomous sytem, this autonomous system is represented by an instance of AutonomousSystem (from the CIM information model; see [10]) and is associated with a route specification via the MPLSASInRoute association. Chadha Expires January 2001 12 =0C Policy Information Model for MPLS Traffic Engineering July 2000 3.2.2 Traffic trunks, LSPs, and supporting object classes and associations The following object classes and associations are defined. Many of these are referenced by the actions described in the previous section. - Traffic trunk (object class MPLSTrafficTrunk): For a description of a traffic trunk, see the Introduction section of this document, or see RFC 2702 [3] for more details. The attributes of a traffic trunk are described by the properties of this object class. A traffic trunk can be associated with LSPs that are currently carrying its traffic (MPLSCurrentlyAssignedLSP association) and with backup LSPs that are used for backup in fault/congestion scenarios (MPLSBackupLSP association). Eligible routes for this traffic trunk are associated with it via the MPLSEligibleRouteSpec association. If a traffic trunk going in the reverse direction exists, it is associated with this traffic trunk via the MPLSReverseDirTT association. Finally, a traffic profile for this traffic trunk can be represented by the qosPolicyPRTrfcProf object class (reused from QPIM [6]) and associated with the traffic trunk via the MPLSTrafficProfile association. - Abstract route (object class MPLSRoute): This is an abstract object class that represents a route from point A to point B. The route may or may not be realized in the network by an LSP. In other words, a route could either be a specification of a route from one point to another, or it could be an actual LSP that has been set up in the network. A route is associated with all the hops contained in this route. These hops could either be interfaces on LSRs (represented by instances of ProtocolEndpoint, which is an object class defined in the CIM Network Model [10]), or they could be autonomous systems (represented by instances of AutonomousSystem, another object class defined in the CIM Network Model [10]). The associations with these hops are realized via the MPLSHopInRoute and MPLSASInRoute associations, respectively. A route may also be associated with a resource profile (represented by object class MPLSResourceProfile, defined in this draft) which describes the resource profile for this route, i.e. the allowable traffic rates and burst sizes, etc. (MPLSRouteResourceProfile association). - Route specification (object class MPLSRouteSpec): This object class is used to describe a specification of a route from one node to another and is derived from the MPLSRoute object class described above. The difference between an MPLSRouteSpec and an MPLSLSP is that the former is not necessarily a physically created LSP; rather, it is a specification of a route that could be used by a management system to create an actual LSP (for rerouting or backup purposes). Also note that it could be an incomplete specification of a route; e.g. it could specify three hops for a route which actually requires at least four hops, and leave the job of choosing the missing hop to a signaling protocol that sets up the corresponding LSP. Its properties are inherited from MPLSRoute and are a subset of the Chadha Expires January 2001 13 =0C Policy Information Model for MPLS Traffic Engineering July 2000 properties in MPLSLSP. An LSP can be created based on a route specification using the MPLSCreateLSPAction. The typical use of this object class is for a network operator to be able to specify potential MPLS routes in advance and later instantiate them by creating LSPs that use this specification. A route specification can be associated with a traffic trunk to indicate that this is a potential route to which this traffic trunk can be mapped (MPLSEligibleRouteSpec association). - Label-Switched Path (LSP) (object class MPLSLSP): This object class represents an LSP. An LSP can be associated with a route specification in order to indicate that this LSP implements this route specification (MPLSRealizes association). An LSP can also be associated with a traffic trunk if it is currently carrying the traffic for this traffic trunk (via the MPLSCurrentlyAssignedLSP association) or if it is a backup LSP for this traffic trunk (via the MPLSBackupLSP association). An LSP can also be associated with another LSP to indicate a hierarchy of LSPs (MPLSLSPinLSP association). - Resource profile (object class MPLSResourceProfile): This object class represents the resource profile associated with a route, i.e. the allowable traffic rates and burst sizes, etc. - Resources (object class MPLSResources): This object class represents resources associated with LSRs and interfaces on these LSRs, such as buffer resources, etc. (MPLSSystemResources and MPLSEndpointResources associations, respectively). - Links and their resources (association MPLSActiveConnection): The resources associated with a link (e.g. bandwidth, etc.) are represented by properties of the association MPLSActiveConnection. This association is used to relate two instances of ProtocolEndpoint that currently have an active connection between them. Apart from these newly defined object classes and associations, the qosPolicyPRAction object class is reused from QPIM [6] for representing policing actions including actions to be taken for non- conforming traffic. Also, object classes qosPolicySimpleCondition, qosPolicyVariable, and qosPolicyValue and their derived classes from QPIM are used for representing classifier information. 4. Detailed Description of MPLS Traffic Engineering Policy Information Model This section provides a detailed description of all the newly defined object classes and associations in this information model, along with their properties. 4.1 Object Class MPLSActivateTTAction Chadha Expires January 2001 14 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This object class represents a policy action (see [5]) that creates an instance of a traffic trunk by assigning it to a traffic flow (referred to as "activation" of a traffic trunk in [3]). Note that a traffic trunk must first be established or defined by creating an instance of MPLSTrafficTrunk and related objects/associations (see Section 3.2.1.1 for details). RFC 2702 [3] describes the difference between establishing a traffic trunk (which we model by creating an instance of MPLSTrafficTrunk and related classes as described in Section 3.2.1.1) and activating a traffic trunk (which is modeled by the MPLSActivateTTAction). The class definition is as follows: NAME MPLSActivateTTAction DESCRIPTION A class used to describe a policy action that activates a traffic trunk. DERIVED FROM policyAction (defined in [5]) ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk 4.1.1 The property Name Name of the action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string =20 4.1.2 The property mpTrafficTrunk This property contains a reference to an instance of MPLSTrafficTrunk. The semantics are that this policy action assigns the traffic described in the condition portion of the corresponding policy rule to this traffic trunk. The condition portion of the containing policy rule would describe the FECs that are mapped to this traffic trunk by using instances of qosPolicySimpleCondition (from QPIM [6]). Note that the instance of MPLSTrafficTrunk that is referenced can be re-used as it can be referenced by multiple policy actions. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Traffic trunk associated with traffic described in the policy rule to which this action belongs SYNTAX Reference to an MPLSTrafficTrunk Chadha Expires January 2001 15 =0C Policy Information Model for MPLS Traffic Engineering July 2000 4.2 Object Class MPLSCreateLSPAction This class is used to create an LSP. Note that a route specification must first be defined by creating an instance of MPLSRouteSpec and related objects/associations (see Section 3.2.1.3 for details). NAME MPLSCreateLSPAction DESCRIPTION A class that represents an action that creates an MPLS LSP. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpCreateLSP 4.2.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action SYNTAX string =20 4.2.2 The property mpCreateLSP This property contains a reference to an MPLSRouteSpec according to whose specifications an LSP is to be created. The property definition is as follows: NAME mpCreateLSP DESCRIPTION Specification of LSP to be created SYNTAX Reference to an instance of MPLSRouteSpec =20 4.3 Object Class MPLSDestroyLSPAction This class is used to represent the action of tearing down an LSP and reclaiming all the resources allocated to it. NAME MPLSDestroyLSPAction DESCRIPTION A class that represents an action that destroys an LSP. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpLSP 4.3.1 The property Name Chadha Expires January 2001 16 =0C Policy Information Model for MPLS Traffic Engineering July 2000 Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string 4.3.2 The property mpLSP This property is a reference to the instance of MPLSLSP that is to be torn down. The property definition is as follows: NAME mpLSP DESCRIPTION Reference to LSP being destroyed. SYNTAX Reference to an instance of MPLSLSP 4.4 Object Class MPLSDestroyTTAction This class is used to represent the action of tearing down a traffic trunk and reclaiming all the resources allocated to it. This does not mean that the LSP(s) assigned to this trunk will be torn down; rather, such LSPs will have more resources available for carrying alternate traffic. NAME MPLSDestroyTTAction DESCRIPTION A class that represents an action that destroys a traffic trunk. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk 4.4.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string 4.4.2 The property mpTrafficTrunk Chadha Expires January 2001 17 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This property is a reference to the instance of MPLSTrafficTrunk that is to be torn down. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Reference to traffic trunk being destroyed. SYNTAX Reference to an instance of MPLSTrafficTrunk 4.5 Object Class MPLSModifyTTAction This class is used to modify a traffic trunk. Note that the traffic trunk is assumed to have been defined by creating an instance of MPLSTrafficTrunk and related objects/associations (see Section 3.2.1.1 for details). NAME MPLSModifyTTAction DESCRIPTION A class that represents an action that modifies an MPLS traffic trunk. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk 4.5.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action SYNTAX string =20 4.5.2 The property mpTrafficTrunk This property contains a reference to an MPLSTrafficTrunk that is to be modified. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Reference to traffic trunk to be modified SYNTAX Reference to an instance of MPLSTrafficTrunk 4.6 Object Class MPLSAssignLSPAction This class is used to represent the action of assigning an LSP to a traffic trunk. Note that the traffic trunk and LSP are assumed to Chadha Expires January 2001 18 =0C Policy Information Model for MPLS Traffic Engineering July 2000 have been defined by creating instances of MPLSTrafficTrunk and MPLSLSP, respectively, as well as related objects/associations (see Sections 3.2.1.1 and 3.2.1.2 for details). NAME MPLSAssignLSPAction DESCRIPTION A class that represents an action that assigns an LSP to a traffic trunk. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk mpAssignedLSP 4.6.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string 4.6.2 The property mpTrafficTrunk This property contains a reference to an instance of MPLSTrafficTrunk. Note that the instance of MPLSTrafficTrunk that is referenced can be re-used as it can be referenced by multiple policy actions. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Traffic trunk to which an LSP is being assigned SYNTAX Reference to an MPLSTrafficTrunk 4.6.3 The property mpAssignedLSP This property is a reference to an instance of MPLSLSP. The semantics here are that the traffic trunk referenced within this action is to be sent over the referenced LSP. The property definition is as follows: NAME mpAssignedLSP DESCRIPTION Reference to LSP being assigned to a traffic trunk SYNTAX Reference to an instance of MPLSLSP Chadha Expires January 2001 19 =0C Policy Information Model for MPLS Traffic Engineering July 2000 4.7 Object Class MPLSDeassignLSPAction This class is used to represent the action of de-assigning an LSP from a traffic trunk, i.e. if the traffic belonging to a traffic trunk was being sent over a given LSP, this action stops any further traffic from this traffic trunk from being sent over this LSP. Note that the traffic trunk and LSP are assumed to have been defined by creating instances of MPLSTrafficTrunk and MPLSLSP, respectively, as well as related objects/associations (see Sections 3.2.1.1 and 3.2.1.2 for details). NAME MPLSDeassignLSPAction DESCRIPTION A class that represents an action that de-assigns an LSP from a traffic trunk. DERIVED FROM PolicyAction ABSTRACT FALSE PROPERTIES Name mpTrafficTrunk mpDeassignedLSP 4.7.1 The property Name Name for this action. The property definition is as follows: NAME Name DESCRIPTION Name for this action. SYNTAX string 4.7.2 The property mpTrafficTrunk This property contains a reference to an instance of MPLSTrafficTrunk. Note that the instance of MPLSTrafficTrunk that is referenced can be re-used as it can be referenced by multiple policy actions. The property definition is as follows: NAME mpTrafficTrunk DESCRIPTION Traffic trunk for which an LSP is being de-assigned SYNTAX Reference to an MPLSTrafficTrunk 4.7.3 The property mpDeassignedLSP This property is a reference to an instance of MPLSLSP. The semantics here are that the traffic trunk referenced within this Chadha Expires January 2001 20 =0C Policy Information Model for MPLS Traffic Engineering July 2000 action is assumed to be currently transported by the referenced LSP and is no longer to be sent over this LSP. The property definition is as follows: NAME mpDeassignedLSP DESCRIPTION Reference to LSP being de-assigned from a traffic trunk SYNTAX Reference to an instance of MPLSLSP 4.8 Object Class MPLSTrafficTrunk This object class is used to represent an MPLS traffic trunk and its properties. A traffic trunk is an aggregation of traffic flows of the same class which are placed inside an LSP (or more than one LSPs, in the case of load balancing). Essentially, a traffic trunk is an abstract representation of traffic to which specific characteristics can be associated. This class contains properties describing attributes that can be associated with traffic trunks to influence their behavioral characteristics. Several of these attributes are drawn from RFC 2702 [3]. The class definition is as follows: NAME MPLSTrafficTrunk DESCRIPTION A class with several properties for describing an MPLS traffic trunk. DERIVED FROM LogicalElement ABSTRACT FALSE PROPERTIES Name mpResourceClassAffinity mpPreemption mpPriority mpResilience mpTrafficProportion mpReoptimizationFreq 4.8.1 The property Name Name for this traffic trunk. The property definition is as follows: NAME Name DESCRIPTION Name for this traffic trunk. SYNTAX string 4.8.2 The property mpResourceClassAffinity Chadha Expires January 2001 21 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This property represents the resource class affinity attributes (see [3]) associated with a traffic trunk which can be used to specify the class of resources that are to be explicitly included or excluded from the path of the traffic trunk (the property mpResourceClass, which appears in object class MPLSResources and in association MPLSActiveConnection, describes the "class" that a resource belongs to). The mpResourceClassAffinity property contains a list of policy attributes which can be used to impose additional constraints on the path traversed by a given traffic trunk. The resource class affinity property for a traffic trunk contains a string of the form: The "resource-class" parameter in the above identifies a resource class for which an affinity relationship is defined with respect to the traffic trunk. The "affinity" parameter above is a boolean value that indicates the affinity relationship; that is, whether members of the resource class are to be included or excluded from the path of the traffic trunk. The value "true" signifies explicit inclusion, and the value "false" specifies explicit exclusion. If no resource class affinity attributes are specified, then a "don't care" affinity relationship is assumed to hold between the traffic trunk and all resources. That is, there is no requirement to explicitly include or exclude any resources from the traffic trunk's path. This should be the default in practice. Resource class affinity attributes are very useful and powerful constructs because they can be used to implement a variety of policies. For example, they can be used to contain certain traffic trunks within specific topological regions of the network. A "constraint-based routing" framework (see [3]) can be used to compute an LSP for a traffic trunk subject to resource class affinity constraints in the following manner: 1. For explicit inclusion, prune all resources not belonging to the specified classes before performing LSP computation. 2. For explicit exclusion, prune all resources belonging to the specified classes before performing LSP computation. The property definition is as follows: NAME mpResourceClassAffinity DESCRIPTION String containing resource class affinities SYNTAX string 4.8.3 The property mpPreemption Chadha Expires January 2001 22 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The preemption attribute (see [3]) determines whether a traffic trunk can preempt another traffic trunk from a given path, and whether it can be preempted by another traffic trunk. Preemption can used to assure that high priority traffic trunks can always be routed through relatively favorable paths within a differentiated services environment. Preemption can also be used to implement various prioritized restoration policies following fault events. The preemption property can take one of four values, with the following semantics: 1. preemptor-enabled: can preempt lower priority preemptable traffic trunks 2. non-preemptor: cannot preempt other traffic trunks 3. preemptable: can be preempted by higher priority preemptor- enabled traffic trunks 4. non-preemptable: cannot be preempted. It is trivial to see that some of the preempt modes are mutually exclusive. Using the numbering scheme depicted above, the feasible preempt mode combinations for a given traffic trunk are as follows: (1, 3), (1, 4), (2, 3), and (2, 4). The (2, 4) combination should be the default. A traffic trunk, say "A", can preempt another traffic trunk, say "B", only if *all* of the following five conditions hold: 1. "A" has a relatively higher priority than "B" 2. "A" contends for a resource utilized by "B" 3. The resource cannot concurrently accommodate "A" and "B" based on certain decision criteria 4. "A" is preemptor enabled 5. "B" is preemptable. Preemption is not considered a mandatory attribute under the current best effort Internet service model, although it may be useful. However, in a differentiated services scenario, the need for preemption becomes more compelling. Moreover, in the emerging optical internetworking architectures, where some protection and restoration functions may be migrated from the optical layer to data network elements (such as gigabit and terabit label switching routers) to reduce costs, preemptive strategies can be used to reduce the restoration time for high priority traffic trunks under fault conditions. The property definition is as follows: NAME mpPreemption DESCRIPTION Contains preemptability information SYNTAX uint16[] (values from 1 to 4) 4.8.4 The property mpPriority Chadha Expires January 2001 23 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The priority of a traffic trunk is described by this property. The priority property defines the relative importance of traffic trunks. If a constraint-based routing framework is used with MPLS, priorities can be used to determine the order in which path selection is done for traffic trunks at connection establishment and under fault scenarios. Priorities are also important in implementations permitting preemption because they can be used to impose a partial order on the set of traffic trunks according to which preemptive policies can be applied. The priority of a traffic trunk, along with its preemptability information (see the description of the mpPreemption property in the previous section), determines when it will preempt and/or be preempted by other traffic trunks. The property definition is as follows: NAME mpPriority DESCRIPTION Priority for this traffic trunk. SYNTAX uint16 4.8.5 The property mpResilience The mpResilience property indicates the recovery procedure to be applied to traffic trunks whose paths are impacted by faults. More specifically, it contains a boolean value that determines whether the target traffic trunk is to be rerouted or not when segments of its path fail. Note that RFC 2702 [3] discusses extended resilience attributes that could be used to specify detailed actions to be taken when faults occur. The representation of such attributes is left for further study. The property definition is as follows: NAME mpResilience DESCRIPTION If set to true, this traffic trunk should be rerouted in case of failure; if false, it should not. SYNTAX boolean 4.8.6 The property mpTrafficProportion This property is used to indicate the relative proportion of traffic to be carried by parallel traffic trunks. This enables one to perform load distribution across multiple parallel traffic trunks between two nodes. In many practical situations, the aggregate traffic between two nodes may be such that no single link can carry the load. In this case, the only feasible solution is to appropriately divide the aggregate traffic into sub-streams and route the sub-streams through multiple paths between the two nodes. Chadha Expires January 2001 24 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This problem can be addressed by instantiating multiple traffic trunks between the two nodes, such that each traffic trunk carries a proportion of the aggregate traffic. The proportion of traffic carried by each such trunk is specified by the mpTrafficProportion property. The property definition is as follows: NAME mpTrafficProportion DESCRIPTION Proportion of traffic to be carried by this traffic trunk, specified as a percentage from 0 to 100. SYNTAX uint16 4.8.7 The property mpReoptimizationFreq Due to changes in network and traffic characteristics, there may be a need to periodically change the paths of traffic trunks for optimization purposes. This should not be done too frequently as this could adversely affect the stability of the network. This property indicates how often such reoptimization should be performed. The property definition is as follows: NAME mpReoptimizationFreq DESCRIPTION Indicates how frequently reoptimization should be performed for this traffic trunk. If the value of this property is set to zero, this indicates that reoptimization should not be performed. SYNTAX uint16 4.9 Object Class MPLSRoute This object class is used to represent an MPLS route and its properties. An MPLS route is an abstract class with two structural subclasses, MPLSRouteSpec and MPLSLSP, representing a specification of an MPLS route or a concrete LSP respectively. Some of the properties of this class have been drawn from the mplsTunnelTable in the MPLS Traffic Engineering MIB [8]. The class definition is as follows: NAME MPLSRoute DESCRIPTION A class with several properties for describing an MPLS route. DERIVED FROM LogicalElement ABSTRACT true PROPERTIES Name mpIngressIPAddress mpEgressIPAddress Chadha Expires January 2001 25 =0C Policy Information Model for MPLS Traffic Engineering July 2000 mpCOS mpSignalingProtocol mpSetupPriority mpHoldingPriority mpIngressMayReroute mpIsPersistent mpLocalProtectionAvailable mpIsPinned mpOwner mpInstancePriority mpIsAdaptive mpPreference 4.9.1 The property Name The canonical name assigned to the MPLS route. The property definition is as follows: NAME Name DESCRIPTION MPLS route name SYNTAX string 4.9.2 The property mpIngressIPAddress Ingress IP address for this MPLS route. The property definition is as follows: NAME mpIngressIPAddress DESCRIPTION Ingress IP address for this MPLS route. SYNTAX string =20 4.9.3 The property mpEgressIPAddress Egress IP address for this MPLS route. The property definition is as follows: NAME mpEgressIPAddress DESCRIPTION Egress IP address for this MPLS route. SYNTAX string =20 4.9.4 The property mpCOS This property defines the class of service for this MPLS route. This class of service could represent either a DSCP value or a ToS value. Further refinement of this property definition is for further study. Chadha Expires January 2001 26 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The property definition is as follows: NAME mpCOS DESCRIPTION Class of service for MPLS route SYNTAX uint16 DEFAULT VALUE 0 4.9.5 The property mpSignalingProtocol The signaling protocol, if any, used or to be used to set up this MPLS route. The property definition is as follows: NAME mpSignalingProtocol DESCRIPTION Signaling protocol used or to be used to set up this MPLS route. SYNTAX uint16 VALUES none(1), ldp(2), rsvp(3), other(4) =20 4.9.6 The property mpSetupPriority Indicates the setup priority of this MPLS route (see [11] and [12]). The property definition is as follows: NAME mpSetupPriority DESCRIPTION Indicates the setup priority of this MPLS route. SYNTAX uint16 =20 4.9.7 The property mpHoldingPriority Indicates the holding priority for this MPLS route (see [11] and [12]). The property definition is as follows: NAME mpHoldingPriority DESCRIPTION Holding priority for this MPLS route SYNTAX uint16 =20 4.9.8 The property mpIngressMayReroute This flag indicates that the MPLS route ingress node may choose to reroute this MPLS route without tearing it down. The property definition is as follows: Chadha Expires January 2001 27 =0C Policy Information Model for MPLS Traffic Engineering July 2000 NAME mpIngressMayReroute DESCRIPTION Fast reroute enabled SYNTAX boolean 4.9.9 The property mpIsPersistent Indicates whether this MPLS route should be restored automatically after a failure occurs. The property definition is as follows: NAME mpIsPersistent DESCRIPTION Indicates whether this MPLS route is persistent or not SYNTAX boolean =20 4.9.10 The property mpLocalProtectionAvailable This flag permits transit routers to use a local repair mechanism which may result in violation of the explicit routing of this MPLS route. When a fault is detected on an adjacent downstream link or node, a transit router can reroute traffic for fast service restoration. The property definition is as follows: NAME mpLocalProtectionAvailable DESCRIPTION Indicates whether local protection is available SYNTAX boolean =20 4.9.11 The property mpIsPinned This flag indicates whether the loose-routed hops of this MPLS route are to be pinned (see [11]). The property definition is as follows: NAME mpIsPinned DESCRIPTION Indicates whether the route is pinned SYNTAX boolean =20 4.9.12 The property mpOwner Indicates which protocol created/should create this route and is/should be responsible for managing it. The property definition is as follows: Chadha Expires January 2001 28 =0C Policy Information Model for MPLS Traffic Engineering July 2000 NAME mpOwner DESCRIPTION Indicates which protocol created/should create this route and is/should be responsible for managing it. SYNTAX uint16 VALUES snmp (1), ldp (2), rsvp (3),policyAgent (4), other (5) 4.9.13 The property mpInstancePriority This value indicates the priority for this route, with zero indicating the lowest priority. The property definition is as follows: NAME mpInstancePriority DESCRIPTION Route Priority SYNTAX uint16 =20 4.9.14 The property mpIsAdaptive An MPLS route might need to re-route itself (e.g. due to re- optimization, connectivity problems, increase in bandwidth, etc.). If an MPLS route is configured to be adaptive, it (a) maintains existing resources until a new path is set up (b) avoids double-counting for links shared by the old and new paths. The property definition is as follows: NAME mpIsAdaptive DESCRIPTION A boolean indicating whether an MPLS route is adaptive or not. SYNTAX boolean DEFAULT VALUE true 4.9.15 The property mpPreference Multiple MPLS routes may exist between ingress and egress routers; the MPLS route with the lowest preference is used (useful for load balancing). The property definition is as follows: NAME mpPreference DESCRIPTION Preference assigned to an MPLS route. SYNTAX uint16 4.10 Object Class MPLSLSP Chadha Expires January 2001 29 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This object class is used to represent an MPLS LSP and its properties. Instances of this class represent existing LSPs in the network. The class definition is as follows: NAME MPLSLSP DESCRIPTION A class with several properties for describing an MPLS LSP. DERIVED FROM MPLSRoute ABSTRACT FALSE PROPERTIES Name mpAdminStatus mpOperationalStatus mpLevel 4.10.1 The property Name This is the canonical name assigned to the LSP. The name may be the tunnel ID or may be the name used to refer to the LSP on the LSR's console port (see the definition of mplsTunnelName in [8]). This definition may need further refinement in subsequent versions of this document. The property definition is as follows: NAME Name DESCRIPTION Name for this LSP. SYNTAX string 4.10.2 The property mpAdminStatus This property indicates the desired operational status of this LSP. The property definition is as follows: NAME mpAdminStatus DESCRIPTION Administrative status of an LSP. SYNTAX uint16 VALUES up(1), down(2), testing(3) 4.10.3 The property mpOperationalStatus This property indicates the actual operational status of this LSP, which is typically (but is not limited to) a function of the state of individual segments of this LSP. The property definition is as follows: NAME mpOperationalStatus DESCRIPTION Operational status of an LSP. Chadha Expires January 2001 30 =0C Policy Information Model for MPLS Traffic Engineering July 2000 SYNTAX uint16 VALUES up(1), down(2), testing(3), unknown(4), dormant(5), notPresent(6), lowerLayerDown(7) 4.10.4 The property mpLevel This property indicates the nesting level of this LSP. The property definition is as follows: NAME mpLevel DESCRIPTION LSP nesting level. SYNTAX uint16 4.11 Object Class MPLSRouteSpec This object class is used to represent a specification of a potential path for routing an MPLS traffic trunk. The difference between an MPLSRouteSpec and an MPLSLSP is that the former is not necessarily a physically created LSP; rather, it is a specification of a route that could be used by a management system to create an actual LSP (for rerouting or backup purposes). Its properties are inherited from MPLSRoute and are a subset of the properties in MPLSLSP. An LSP can be created based on a route specification using the MPLSCreateLSPAction. The class definition is as follows: NAME MPLSRouteSpec DESCRIPTION A class describing an MPLS route specification. DERIVED FROM MPLSRoute ABSTRACT FALSE 4.12 Object Class MPLSResourceProfile This object class describes bandwidth resources required or used by an MPLS route (recall that an MPLS route is an abstract class and can be instantiated either as an MPLS LSP or as an MPLS route specification). The properties describing these resources form a resource profile and different LSPs/route specifications with the same resource profile can reuse the same instance of this object class via the MPLSRouteResourceProfile association. The properties of this object class are derived from the mplsTunnelResourceTable in the MPLS TE MIB [8]. The class definition is as follows: NAME MPLSResourceProfile DESCRIPTION A class with several properties for Chadha Expires January 2001 31 =0C Policy Information Model for MPLS Traffic Engineering July 2000 describing resources required or used by zero or more MPLS LSPs and/or route specifications. DERIVED FROM Policy ABSTRACT FALSE PROPERTIES Name mpInMaxRate mpInMeanRate mpInMaxBurstSize mpOutMaxrate mpOutMeanRate mpOutMaxBurstSize 4.12.1 The property Name Name of this resource profile. The property definition is as follows: NAME Name DESCRIPTION Name of this resource profile. SYNTAX string =20 4.12.2 The property mpInMaxRate The maximum incoming rate in bits/second. Note that setting mpInMaxRate, mpInMeanRate, and mpInMaxBurstSize to 0 indicates best- effort treatment. The property definition is as follows: NAME mpInMaxRate DESCRIPTION Maximum incoming rate in bits/second. SYNTAX uint16 =20 4.12.3 The property mpInMeanRate The mean incoming rate in bits/second. The property definition is as follows: NAME mpInMeanRate DESCRIPTION Mean incoming rate in bits/second. SYNTAX uint16 =20 4.12.4 The property mpInMaxBurstSize The maximum burst size in bytes. The property definition is as follows: Chadha Expires January 2001 32 =0C Policy Information Model for MPLS Traffic Engineering July 2000 NAME mpInMaxBurstSize DESCRIPTION The maximum burst size in bytes. SYNTAX uint16 =20 4.12.5 The property mpOutMaxrate The maximum outgoing rate in bits/second. Note that setting mpOutMaxRate to 0 indicates best-effort treatment. The property definition is as follows: NAME mpOutMaxrate DESCRIPTION The maximum outgoing rate in bits/second. SYNTAX uint16 =20 4.12.6 The property mpOutMeanRate The mean outgoing rate in bits/second. The property definition is as follows: NAME mpOutMeanRate DESCRIPTION The mean outgoing rate in bits/second. SYNTAX uint16 =20 4.12.7 The property mpOutMaxBurstSize The maximum outgoing burst size in bytes. The property definition is as follows: NAME mpOutMaxBurstSize DESCRIPTION The maximum outgoing burst size in bytes. SYNTAX uint16 4.13 Object Class MPLSResources This class represents resources associated with LSRs and with interfaces on LSRs. The resources described by this class are associated with the corresponding LSRs/interfaces via the MPLSSystemResources and the MPLSEndpointResources associations, respectively. The class definition is as follows: NAME MPLSResources DESCRIPTION Resources associated with LSRs and their interfaces Chadha Expires January 2001 33 =0C Policy Information Model for MPLS Traffic Engineering July 2000 ABSTRACT false DERIVED FROM LogicalElement PROPERTIES Name mpBufferResources mpMaxAllocMultiplier mpResourceClass 4.13.1 The property Name Name for this set of resources. The property definition is as follows: NAME Name DESCRIPTION Name for this set of resources SYNTAX string 4.13.2 The property mpBufferResources Buffer resources for an LSR or an LSR interface. The property definition is as follows: NAME mpBufferResources DESCRIPTION Buffer resources. SYNTAX uint16 4.13.3 The property mpMaxAllocMultiplier The maximum allocation multiplier (MAM) (see [3]) of a resource determines the proportion of the resource that is available for allocation to traffic trunks. This attribute is applicable to buffer resources on LSRs. The value of the MAM can be chosen so that a resource can be under-allocated or over-allocated. A resource is said to be under-allocated if the aggregate demands of all traffic trunks that can be allocated to it are always less than the capacity of the resource. A resource is said to be over-allocated if the aggregate demands of all traffic trunks allocated to it can exceed the capacity of the resource. The property definition is as follows: NAME mpMaxAllocMultiplier DESCRIPTION Proportion of buffer resources that are available for allocation to traffic trunks. SYNTAX uint16 4.13.4 The property mpResourceClass Chadha Expires January 2001 34 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This property describes the "class" that a resource belongs to (see [3]). Thus a resource class can be viewed as a "color" assigned to a resource such that the set of resources with the same "color" conceptually belongs to the same class. Resource classes can be used to implement a variety of policies. From a Traffic Engineering perspective, they can be used to implement many policies with regard to both traffic and resource oriented performance optimization. For example, resource class attributes can be used to apply uniform policies to a set of resources; specify the relative preference of sets of resources for path placement of traffic trunks; explicitly restrict the placement of traffic trunks to specific subsets of resources; etc. In general, a resource can be assigned more than one resource class attribute. For example, all of the OC-48 links in a given network may be assigned a distinguished resource class attribute. The subsets of OC-48 links which exist within a given domain of the network may be assigned additional resource class attributes in order to implement specific containment policies, or to architect the network in a certain manner. The property definition is as follows: NAME mpResourceClass DESCRIPTION Resource class(es) that a resource belongs to. SYNTAX uint16[] 4.14 The association MPLSHopInRoute The association MPLSHopInRoute provides a way to associate hops with MPLSRoutes. Hops are instances of ProtocolEndpoint (from the CIM model [10]) and represent LSR interfaces. The association definition is as follows: NAME MPLSHopInRoute DESCRIPTION Associates hops with MPLSRoutes ABSTRACT false PROPERTIES mpRoute[ref MPLSRoute[0..n]] mpHop[ref ProtocolEndpoint[0..n]] mpIsStrict mpOrder 4.14.1 The reference mpRoute =20 This property contains an object reference to an MPLSRoute with which a number of hops can be associated. The [0..n] cardinality indicates that there may be 0, 1, or more than one MPLSRoutes associated with any given hop, indicating that this hop is contained in all these routes. 4.14.2 The reference mpHop =20 Chadha Expires January 2001 35 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This property contains an object reference to a ProtocolEndpoint (representing an LSR interface) that is a hop for an MPLSRoute. The [0..n] cardinality indicates that there may be 0, 1, or more than one hops associated with any given MPLSRoute. These are all the hops that are included in the route specification. 4.14.3 The property mpIsStrict Denotes whether the referenced hop is routed in a strict or loose fashion. The property definition is as follows: NAME mpIsStrict DESCRIPTION Denotes whether the referenced hop is routed in a strict or loose fashion. SYNTAX boolean =20 4.14.4 The property mpOrder This property indicates the hop sequence, 1..n. The property definition is as follows: NAME mpOrder DESCRIPTION Hop sequence SYNTAX uint16 4.15 The association MPLSASInRoute The association MPLSASInRoute provides a way to associate AS hops with MPLSRoutes. AS hops are instances of AutonomousSystem (from the CIM model [10]) and represent autonomous systems. The association definition is as follows: NAME MPLSASInRoute DESCRIPTION Associates AS hops with MPLSRoutes ABSTRACT false PROPERTIES mpRoute [ref MPLSRoute[0..n]] mpHop[ref AutonomousSystem[0..n]] mpIsStrict mpOrder =20 4.15.1 The reference mpRoute =20 This property contains an object reference to an MPLSRoute with which a number of autonomous system hops can be associated. The [0..n] cardinality indicates that there may be 0, 1, or more than Chadha Expires January 2001 36 =0C Policy Information Model for MPLS Traffic Engineering July 2000 one MPLSRoutes associated with any given AS hop, indicating that this AS hop is contained in all these routes. 4.15.2 The reference mpHop =20 This property contains an object reference to an AutonomousSystem that is a hop for an MPLSRoute. The [0..n] cardinality indicates that there may be 0, 1, or more than one AS hops associated with any given MPLSRoute. These are all the AS hops that are included in the route specification. 4.15.3 The property mpIsStrict Denotes whether the referenced AS hop is routed in a strict or loose fashion. The property definition is as follows: NAME mpIsStrict DESCRIPTION Denotes whether the referenced AS hop is Routed in a strict or loose fashion. SYNTAX boolean =20 4.15.4 The property mpOrder This property indicates the AS hop sequence, 1..n. The property definition is as follows: NAME mpOrder DESCRIPTION AS hop sequence SYNTAX uint16 4.16 The association MPLSSystemResources The association MPLSSystemResources associates a set of resources (object class MPLSResources) with an LSR (modeled by an instance of ComputerSystem as defined in the CIM model [13]). The association definition is as follows: NAME MPLSSystemResources DESCRIPTION Associates MPLS resources with an LSR. ABSTRACT false PROPERTIES mpResources[ref MPLSResources [0..1]] mpLSR [ref ComputerSystem[0..n]] 4.16.1 The reference mpResources Chadha Expires January 2001 37 =0C Policy Information Model for MPLS Traffic Engineering July 2000 =20 This property contains an object reference to an MPLSResources instance to which zero or one ComputerSystems (representing LSRs) can be associated. The [0..1] cardinality indicates that there may be zero or one instances of MPLSResources associated with any given LSR. 4.16.2 The reference mpLSR =20 This property contains an object reference to a ComputerSystem (representing an LSR) that is associated with MPLSResources. The [0..n] cardinality indicates that there may be 0, 1, or more than one LSRs associated with any given MPLSResources instance. These LSRs all have the same resource specifications. 4.17 The association MPLSEndpointResources The association MPLSEndpointResources associates a set of resources (object class MPLSResources) with an interface of an LSR (modeled by an instance of ProtocolEndpoint as defined in the CIM model [10]). The association definition is as follows: NAME MPLSEndpointResources DESCRIPTION Associates MPLS resources with an interface of an LSR. ABSTRACT false PROPERTIES mpResources[ref MPLSResources [0..1]] mpPE [ref ProtocolEndpoint [0..n]] 4.17.1 The reference mpResources =20 This property contains an object reference to an MPLSResources instance to which zero or one ProtocolEndpoints (representing interfaces on LSRs) can be associated. The [0..1] cardinality indicates that there may be zero or one instances of MPLSResources associated with any given LSR interface. 4.17.2 The reference mpPE =20 This property contains an object reference to a ProtocolEndpoint (representing an LSR interface) that is associated with MPLSResources. The [0..n] cardinality indicates that there may be 0, 1, or more than one LSR interfaces associated with any given MPLSResources instance. These LSR interfaces all have the same resource specifications. 4.18 The association MPLSActiveConnection Chadha Expires January 2001 38 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The association MPLSActiveConnection associates a ProtocolEndpoint with another and represents a link between them. Here ProtocolEndpoint (taken from the CIM model [10]) represents an LSR interface. The association definition is as follows: NAME MPLSActiveConnection DESCRIPTION Represents a link between two LSR interfaces ABSTRACT false DERIVED FROM ActiveConnection (from CIM [10]) PROPERTIES mpEndpoint1 [ref ProtocolEndpoint [0..n]] mpEndpoint2 [ref ProtocolEndpoint [0..n]] mpBandwidth mpMaxAllocMultiplier mpResourceClass 4.18.1 The reference mpEndpoint1 =20 This property contains a reference to a ProtocolEndpoint instance (representing an LSR interface) to which zero or more ProtocolEndpoints (also representing LSR interfaces) can be associated, representing a connection between the ProtocolEndpoints. The [0..n] cardinality indicates that there may be zero or more instances of ProtocolEndpoint associated with any given ProtocolEndpoint. 4.18.2 The reference mpEndpoint2 =20 This property contains a reference to a ProtocolEndpoint instance (representing an LSR interface) to which zero or more ProtocolEndpoints (also representing LSR interfaces) can be associated, representing a connection between the ProtocolEndpoints. The [0..n] cardinality indicates that there may be zero or more instances of ProtocolEndpoint associated with any given ProtocolEndpoint. 4.18.3 The property mpBandwidth Bandwidth for the link represented by this connection. The property definition is as follows: NAME mpBandwidth DESCRIPTION Link bandwidth SYNTAX uint16 4.18.4 The property mpMaxAllocMultiplier Chadha Expires January 2001 39 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The maximum allocation multiplier (MAM) (see [3]) of a resource determines the proportion of the resource that is available for allocation to traffic trunks. This attribute is applicable to link bandwidth. The values of the MAM can be chosen so that a resource can be under-allocated or over-allocated. A resource is said to be under-allocated if the aggregate demands of all traffic trunks that can be allocated to it are always less than the capacity of the resource. A resource is said to be over-allocated if the aggregate demands of all traffic trunks allocated to it can exceed the capacity of the resource. The property definition is as follows: NAME mpMaxAllocMultiplier DESCRIPTION Proportion of link bandwidth that is available for allocation. SYNTAX uint16 4.18.5 The property mpResourceClass This property describes the "class" that a resource belongs to. Thus a resource class can be viewed as a "color" assigned to a resource such that the set of resources with the same "color" conceptually belong to the same class. Resource classes can be used to implement a variety of policies. From a Traffic Engineering perspective, they can be used to implement many policies with regard to both traffic and resource oriented performance optimization. For example, resource class attributes can be used to apply uniform policies to a set of resources; specify the relative preference of sets of resources for path placement of traffic trunks; explicitly restrict the placement of traffic trunks to specific subsets of resources; etc. In general, a resource can be assigned more than one resource class attribute. For example, all of the OC-48 links in a given network may be assigned a distinguished resource class attribute. The subsets of OC-48 links which exist within a given domain of the network may be assigned additional resource class attributes in order to implement specific containment policies, or to architect the network in a certain manner. The property definition is as follows: NAME mpResourceClass DESCRIPTION Resource class assigned to this link. SYNTAX uint16[] 4.19 The association MPLSReverseDirTT The association MPLSReverseDirTT associates an MPLS traffic trunk with a traffic trunk going in the reverse direction. Chadha Expires January 2001 40 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The association definition is as follows: NAME MPLSReverseDirTT DESCRIPTION Associates a traffic trunk with another going in the reverse direction. ABSTRACT false PROPERTIES mpTT1 [ref MPLSTrafficTrunk [0..1]] mpTT2 [ref MPLSTrafficTrunk [0..1]] 4.19.1 The reference mpTT1 =20 This property contains an object reference to an MPLSTrafficTrunk instance to which zero or one MPLSTrafficTrunks can be associated. An MPLSReverseDirTT association between two traffic trunks represents the fact that these traffic trunks carry traffic in opposite directions. The [0..1] cardinality indicates that there may be zero or one instances of MPLSTrafficTrunk associated with any given MPLSTrafficTrunk. 4.19.2 The reference mpTT2 =20 This property contains an object reference to an MPLSTrafficTrunk instance to which zero or one MPLSTrafficTrunks can be associated. An MPLSReverseDirTT association between two traffic trunks represents the fact that these traffic trunks carry traffic in opposite directions. The [0..1] cardinality indicates that there may be zero or one instances of MPLSTrafficTrunk associated with any given MPLSTrafficTrunk. 4.20 The association MPLSEligibleRouteSpec The association MPLSEligibleRouteSpec associates a MPLS traffic trunk with a route specification that is a potential route for this traffic trunk. The association definition is as follows: NAME MPLSEligibleRouteSpec DESCRIPTION Associates a traffic trunk with a route specification that is a potential route for this traffic trunk. ABSTRACT false PROPERTIES mpTT [ref MPLSTrafficTrunk [0..n]] mpRoute [ref MPLSRouteSpec [0..n]] mpPreference mpIsMandatory 4.20.1 The reference mpTT =20 Chadha Expires January 2001 41 =0C Policy Information Model for MPLS Traffic Engineering July 2000 This property contains an object reference to an MPLSTrafficTrunk instance associated with an MPLSRouteSpec. The [0..n] cardinality indicates that there may be zero or more instances of MPLSTrafficTrunk associated with any given MPLSRouteSpec; i.e. zero or more traffic trunks may share the same route specification, indicating that this route specification is an eligible route for these traffic trunks. 4.20.2 The reference mpRoute =20 This property contains an object reference to an MPLSRouteSpec that is associated with an MPLSTrafficTrunk. The [0..n] cardinality indicates that there may be 0, 1, or more than one MPLSRouteSpecs associated with any given MPLSTrafficTrunk instance; i.e. any traffic trunk can have multiple eligible route specifications. 4.20.3 The property mpPreference This property represents the preference for the referenced route by the referenced traffic trunk. The property definition is as follows: NAME mpPreference DESCRIPTION Preference for the referenced route for the referenced traffic trunk. SYNTAX uint16 4.20.4 The property mpIsMandatory Indicates whether this is a mandatory route for this traffic trunk or not. The property definition is as follows: NAME mpIsMandatory DESCRIPTION Indicates whether this is a mandatory route for this traffic trunk or not. SYNTAX boolean 4.21 The association MPLSCurrentlyAssignedLSP The association MPLSCurrentlyAssignedLSP associates the LSP to which a traffic trunk is assigned with that traffic trunk. The association definition is as follows: NAME MPLSCurrentlyAssignedLSP DESCRIPTION Associates a traffic trunk with the LSP Chadha Expires January 2001 42 =0C Policy Information Model for MPLS Traffic Engineering July 2000 assigned to it. ABSTRACT false PROPERTIES mpTT [ref MPLSTrafficTrunk [0..n]] mpLSP [ref MPLSLSP [0..n]] 4.21.1 The reference mpTT =20 This property contains an object reference to an MPLSTrafficTrunk instance to which zero or more MPLSLSPs can be associated. An MPLSCurrentlyAssignedLSP association between a traffic trunk and an LSP represents the fact that this LSP is currently carrying the traffic for this traffic trunk. The [0..n] cardinality indicates that there may be zero or more instances of MPLSTrafficTrunk associated with any given MPLSLSP, i.e. an LSP could be carrying traffic for zero or more traffic trunks. 4.21.2 The reference mpLSP =20 This property contains an object reference to an MPLSLSP instance to which zero or more MPLSTrafficTrunks can be associated. An MPLSCurrentlyAssignedLSP association between a traffic trunk and an LSP represents the fact that this LSP is currently carrying the traffic for this traffic trunk. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with any given MPLSTrafficTrunk, i.e. these LSPs are sharing the traffic load for this traffic trunk. 4.22 The association MPLSBackupLSP The association MPLSBackupLSP associates a backup LSP with an MPLS traffic trunk. The idea is that this LSP can be used as a backup for this traffic trunk if necessary. The association definition is as follows: NAME MPLSBackupLSP DESCRIPTION Associates a backup LSP with a traffic trunk. ABSTRACT false PROPERTIES mpTT [ref MPLSTrafficTrunk [0..n]] mpLSP [ref MPLSLSP [0..n]] mpPreference 4.22.1 The reference mpTT =20 This property contains an object reference to an MPLSTrafficTrunk instance with which zero or more MPLSLSPs can be associated. An MPLSBackupLSP association between a traffic trunk and an LSP represents the fact that this LSP is a backup for this traffic trunk and can be used in failure/congestion situations. The [0..n] Chadha Expires January 2001 43 =0C Policy Information Model for MPLS Traffic Engineering July 2000 cardinality indicates that there may be zero or more instances of MPLSTrafficTrunk associated with any given MPLSLSP, i.e. an LSP can be a backup for zero or more traffic trunks. 4.22.2 The reference mpLSP =20 This property contains an object reference to an MPLSLSP instance with which zero or more MPLSTrafficTrunks can be associated. An MPLSBackupLSP association between a traffic trunk and an LSP represents the fact that that this LSP is a backup for this traffic trunk and can be used in failure/congestion situations. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with any given MPLSTrafficTrunk, i.e. there may be zero or more backup LSPs for this traffic trunk. 4.22.3 The property mpPreference This property represents the preference for the referenced backup LSP by the referenced traffic trunk. In other words, an explicit order can be imposed on all the backup LSPs for a traffic trunk to indicate a sequence of backup LSPs ordered from most preferred to least preferred. The property definition is as follows: NAME mpPreference DESCRIPTION Preference for the referenced backup LSP for the referenced traffic trunk. SYNTAX uint16 4.23 The association MPLSRouteResourceProfile The association MPLSRouteResourceProfile associates a resource profile with an MPLS route. The association definition is as follows: NAME MPLSRouteResourceProfile DESCRIPTION Associates a resource profile with an MPLS route. ABSTRACT false PROPERTIES mpResourceProf[ref MPLSResourceProfile [0..1]] mpRoute[ref MPLSRoute [0..n]] 4.23.1 The reference mpResourceProf =20 This property contains an object reference to an MPLSResourceProfile instance associated with an MPLSRoute. The [0..1] cardinality Chadha Expires January 2001 44 =0C Policy Information Model for MPLS Traffic Engineering July 2000 indicates that there may be zero or one instances of MPLSResourceProfile associated with any given MPLSRoute. 4.23.2 The reference mpRoute =20 This property contains an object reference to an MPLSRoute that is associated with an MPLSResourceProfile. The [0..n] cardinality indicates that there may be 0, 1, or more than one MPLSRoutes associated with any given MPLSResourceProfile instance; i.e. zero or more MPLSRoutes can share the same resource profile definition. 4.24 The association MPLSRealizes The association MPLSRealizes associates an LSP with an MPLS route specification (MPLSRouteSpec). Such an association exists if the referenced LSP is an implementation of the referenced route specification. Recall that a route specification could be loosely or strictly specified; an LSP associated to a route specification via the MPLSRealizes association satisfies all the constraints laid down in this route specification. The association definition is as follows: NAME MPLSRealizes DESCRIPTION Associates an LSP with a route specification. ABSTRACT false PROPERTIES mpLSP [ref MPLSLSP [0..n]] mpRouteSpec [ref MPLSRouteSpec [0..n]] 4.24.1 The reference mpLSP =20 This property contains an object reference to an MPLSLSP instance associated with an MPLSRouteSpec. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with any given MPLSRouteSpec; i.e. zero or more LSPs can be a realization of the same route specification. 4.24.2 The reference mpRouteSpec =20 This property contains an object reference to an MPLSRouteSpec that is associated with an MPLSLSP. The [0..n] cardinality indicates that there may be 0, 1, or more than one MPLSRouteSpecs associated with any given MPLSLSP instance; i.e. any LSP can be a realization of have zero or more route specifications. 4.25 The association MPLSLSPinLSP Chadha Expires January 2001 45 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The association MPLSLSPinLSP associates an LSP with another LSP and indicates a hierachical relationship between the two LSPs. The association definition is as follows: NAME MPLSLSPinLSP DESCRIPTION Associates an LSP with another LSP, indicating a hierarchical relationship between the two. ABSTRACT false PROPERTIES mpContainingLSP [ref MPLSLSP [0..n]] mpContainedLSP [ref MPLSLSP [0..n]] 4.25.1 The reference mpContainingLSP =20 This property contains an object reference to an MPLSLSP instance associated with another MPLSLSP. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with other MPLSLSPs via this association, indicating that these LSPs all contain the referenced LSP. 4.25.2 The reference mpContainedLSP =20 This property contains an object reference to an MPLSLSP instance associated with another MPLSLSP. The [0..n] cardinality indicates that there may be zero or more instances of MPLSLSP associated with other MPLSLSPs via this association, indicating that these LSPs are all contained in the referenced LSP. 4.26 The association MPLSTrafficProfile The association MPLSTrafficProfile associates a traffic trunk with a traffic profile, represented by an instance of qosPolicyPRTrfcProf (defined in [6]). This traffic profile describes the characteristics of the traffic carried by the referenced traffic trunk. The association definition is as follows: NAME MPLSTrafficProfile DESCRIPTION Associates a traffic trunk with a traffic profile. ABSTRACT false PROPERTIES mpTT [ref MPLSTrafficTrunk [0..n]] mpTrfcProf[ref qosPolicyPRTrfcProf [0..1]] 4.26.1 The reference mpTT =20 This property contains an object reference to an MPLSTrafficTrunk instance associated with a qosPolicyPRTrfcProf. The [0..n] cardinality indicates that there may be zero or more instances of Chadha Expires January 2001 46 =0C Policy Information Model for MPLS Traffic Engineering July 2000 MPLSTrafficTrunk associated with any given qosPolicyPRTrfcProf; i.e. zero or more traffic trunks can share the same traffic profile specification. 4.26.2 The reference mpTrfcProf =20 This property contains an object reference to a qosPolicyPRTrfcProf that is associated with an MPLSTrafficTrunk. The [0..1] cardinality indicates that there may be zero or one traffic profiles associated with any given traffic trunk. 5. Usage Examples 5.1 Implementing Olympic Services In the following example, the following scenario is depicted: - Manual LSP creation - Manual traffic trunk creation - Manual assignment of LSPs to traffic trunks. This should be contrasted with the example in the next section (Section 5.2), where a traffic trunk is defined in a policy and LSPs are assumed to be created automatically by a traffic engineering system based on traffic trunk route specifications and network status. This example illustrates the use of the information model described in this document for representing policies that govern the assignment of different classes of traffic to different MPLS LSPs. Suppose that an enterprise needs to implement three classes of service, gold, silver, and bronze, between a pair of sites. In this scenario, we assume that traffic is marked using IP precedence (ToS) bits in the IP header as follows: Traffic entitled to gold service is marked with ToS=3D3 Traffic entitled to silver service is marked with ToS=3D2 Traffic entitled to bronze service is marked with ToS=3D1. Let the two sites be IP subnets 10.1.0.0/16 and 10.2.0.0/16, respectively. 5.1.1 MPLS LSP creation The first task is to set up the MPLS LSPs for traffic between these two sites (note that this step could be performed after the step in Section 5.1.2 as well). We will assume that three MPLS LSPs are to be created, each with different bandwidth constraints and different routing, to carry the three different types of service above: Chadha Expires January 2001 47 =0C Policy Information Model for MPLS Traffic Engineering July 2000 MPLS LSP 1: Carries gold service traffic MPLS LSP 2: Carries silver service traffic MPLS LSP 3: Carries bronze service traffic. To represent the creation of these three LSPs, we define one policy rule with three actions: - Each action corresponds to the creation of one LSP and is an instance of MPLSCreateLSPAction. - Each action refers to a route specification (instance of MPLSRouteSpec). - Each route specification is associated with a resource profile (instance of MPLSResourceProfile, association MPLSRouteResourceProfile) - Each route specification is associated with route hops for this route (a hop is an instance of ProtocolEndpoint) via association MPLSHopInRoute. Thus before defining the three policy actions, we need to define the corresponding three route specifications and the associated objects/associations. 5.1.1.1 Creation of route specifications We depict below the objects and associations that are created to represent the route specification for the Gold traffic class. Silver and bronze route specifications and the associated objects and associations are created in a similar manner. The following figure shows the object instances that are created to specify a route specification GoldRouteSpec with resource profile GoldResourceProfile and three hops, GoldHop1, GoldHop2, and GoldHop3. One instance of association MPLSRouteResourceProfile (which associates GoldRouteSpec and GoldResourceProfile) and three instances of association MPLSHopInRoute (which associate GoldRouteSpec with each of GoldHop1, GoldHop2, and GoldHop3) are created. Chadha Expires January 2001 48 =0C Policy Information Model for MPLS Traffic Engineering July 2000 +-----------------------+ | GoldResourceProfile | | (instance of | | MPLSResourceProfile) | +-----------^-----------+ GoldRouteResourceProfile | (instance of | MPLSRouteResourceProfile) | | +-----------v---------v--------+ | GoldRouteSpec (instance of | | MPLSRouteSpec) | +-^-----------------^--------^-+ | | | GoldHop1InRoute | GoldHop2InRoute| | GoldHop3InRoute (instance of | (instance of | | (instance of MPLSHopInRoute) | MPLSHopInRoute)| | MPLSHopInRoute) | | | | | | | | | +---------------v-+ +-----------v-----+ +v----------------+ | GoldHop1 | | GoldHop2 | | GoldHop3 | | (instance of | | (instance of | | (instance of | |ProtocolEndpoint)| |ProtocolEndpoint)| |ProtocolEndpoint)| +-----------------+ +-----------------+ +-----------------+ Figure 5. Gold route specification with resource profile and three hops 5.1.1.2 Creation of LSPs Once route specifications for the gold, silver, and bronze traffic have been created, the actions to create LSPs corresponding to these three route specifications can be instantiated. Assume that the previous step created three route specifications named GoldRouteSpec (see Figure 5 above), SilverRouteSpec, and BronzeRouteSpec, with the obvious semantics. Three actions are then created: Action 1: (instance of MPLSCreateLSPAction) Name: CreateGoldLSP mpCreateLSP: Action 2: (instance of MPLSCreateLSPAction) Name: CreateSilverLSP mpCreateLSP: Action 3: (instance of MPLSCreateLSPAction) Name: CreateBronzeLSP mpCreateLSP: These three actions each reference an instance of an MPLSRouteSpec object, whose creation was discussed above. Chadha Expires January 2001 49 =0C Policy Information Model for MPLS Traffic Engineering July 2000 The result of implementing the policy rule containing these three actions (note that this policy rule would contain no conditions, only Actions 1, 2, 3 described earlier) is to create three instances of MPLSLSP, namely GoldLSP, SilverLSP, and BronzeLSP (say). Each created instance of MPLSLSP will be associated with the hops in its path and with the appropriate resource profile. Note that the hops in each LSP's path could contain new hops that were not specified in the corresponding route specification, if the latter was an incomplete specification of the route to be followed by the LSP. Each instance of MPLSLSP will also be associated with the instance of MPLSRouteSpec that it implements, via the MPLSRealizes association. The figure below shows the MPLSLSP GoldLSP created from the route specification GoldRouteSpec. Here we assume that the LSP has four hops, which include the three hops specified as belonging to the route specification GoldRouteSpec and one additional new hop, GoldHop4. Instances SilverLSP and BronzeLSP have similar associations. Chadha Expires January 2001 50 =0C Policy Information Model for MPLS Traffic Engineering July 2000 +-----------------------+ ------------------> GoldResourceProfile | | | (instance of | | | MPLSResourceProfile) | | +-----------^-----------+ | GoldRouteResourceProfile | | (instance of | | MPLSRouteResourceProfile) | | | | +-----------v---------v--------+ | | GoldRouteSpec (instance of <--------------- | | MPLSRouteSpec | | | +^---------------^---------^---+ | | | | | | | GoldHop1InRoute|GoldHop2InRoute| | GoldHop3InRoute | | (instance of | (instance of | | (instance of | | MPLSHopInRoute)|MPLSHopInRoute)| | MPLSHopInRoute) | | | | | | | | | | | | | | | | | +----------------v+ +-----------v-----+ +v----------------+ | | | GoldHop1 | | GoldHop2 | | GoldHop3 | | | | (instance of | | (instance of | | (instance of | | | |ProtocolEndpoint)| |ProtocolEndpoint)| |ProtocolEndpoint)| | | +-----------------+ +-----------------+ +-----------------+ | | | | | | | GoldHop1InLSP | GoldHop2InLSP | | GoldHop3InLSP | | (instance of | (instance of | | (instance of | | MPLSHopInRoute) | MPLSHopInRoute)| | MPLSHopInRoute)| | | | | | | | | | | | | | | | | +-v----------------v---------v-+ | ------------------> GoldLSP (instance of <--------------- GoldLSPProfile | MPLSLSP | GoldLSPSpec (instance of +--------------^---------------+ (instance of MPLSRouteResourceProfile) | MPLSRealizes) | | | GoldHop4InLSP | (instance of | MPLSHopInRoute) +-----------v--------+ | GoldHop4 | | (instance of | | ProtocolEndpoint) | +--------------------+ Figure 6. Gold LSP and its associations 5.1.2 Policies for traffic trunks Chadha Expires January 2001 51 =0C Policy Information Model for MPLS Traffic Engineering July 2000 Once LSPs have been created for each class of service, the next requirement is to create policies that activate traffic trunks that will be transported on these LSPs (this step could have been performed before the previous one too). The policy rules that are to be created for site 1 are: Policy Rule 1: If (source address is in IP subnet 10.1.0.0/16) and (destination address is in IP subnet 10.2.0.0/16) and (ToS=3D3) then (traffic is assigned to GoldTrunk) Policy Rule 2: If (source address is in IP subnet 10.1.0.0/16) and (destination address is in IP subnet 10.2.0.0/16) and (ToS=3D2) then (traffic is assigned to SilverTrunk) Policy Rule 3: If (source address is in IP subnet 10.1.0.0/16) and (destination address is in IP subnet 10.2.0.0/16) and (ToS=3D1) then (traffic is assigned to BronzeTrunk) The conditions in each of the above three rules can be represented using conditions with variables and values, as described in the Policy Framework QoS Information Model (see [6]). The actions are described using instances of the MPLSActivateTTAction object class, as described in Section 5.1.2.2. To represent the creation of these three traffic trunks, we define three policy rules, each with three conditions and one action: - Each condition is defined to represent the conditions described above using the mechanisms discussed in QPIM [6]. - Each action corresponds to the activation of one traffic trunk and is an instance of MPLSActivateTTAction. - Each action refers to a traffic trunk (instance of MPLSTrafficTrunk). - Each traffic trunk is associated with a traffic profile (instance of qosPolicyPRTrfcProf, association MPLSTrafficProfile). Thus before defining the three policy rules, we need to define the corresponding three traffic trunks and the associated traffic profiles and associations that will be referenced by the three actions of these rules. 5.1.2.1 Creation of traffic trunks We depict below the objects and associations that are created to represent the traffic trunk for the Gold traffic class. Silver and Chadha Expires January 2001 52 =0C Policy Information Model for MPLS Traffic Engineering July 2000 bronze traffic trunks and the associated objects and associations are created in a similar manner. The following figure shows the object instances that are created to specify a traffic trunk GoldTrunk with traffic profile GoldTrafficProfile. An instance of association MPLSTrafficProfile (which associates GoldTrunk and GoldTrafficProfile) is created. +-----------------------+ | GoldTrunk | | (instance of | | MPLSTrafficTrunk) | +-----------^-----------+ GoldTrunkTrafficProfile | (instance of | MPLSTrafficProfile)| | +-----------v---------v-------------+ | GoldTrafficProfile (instance of | | qosPolicyPRTrfcProf | +-^-----------------^--------^------+ Figure 7. Gold traffic trunk and its traffic profile 5.1.2.2 Activation of traffic trunks Once traffic trunks for the gold, silver, and bronze traffic have been defined, the actions to activate these three traffic trunks can be defined. Assume that the previous step created three traffic trunks named GoldTrunk (see Figure 7 above), SilverTrunk, and BronzeTrunk, with the obvious semantics. Three actions are then created: Action 4: (instance of MPLSActivateTTAction) Name: CreateGoldTrunk mpTrafficTrunk: Action 5: (instance of MPLSActivateTTAction) Name: CreateSilverTrunk mpTrafficTrunk: Action 6: (instance of MPLSActivateTTAction) Name: CreateBronzeLSP mpTrafficTrunk: These three actions each reference an instance of an MPLSTrafficTrunk object, whose creation was discussed above and depicted in Figure 7 (for the GoldTrunk object). The three policy rules described at the beginning of Section 5.1.2 each contain one of the above actions (i.e. Policy Rule 1 contains Action 4, Policy Rule 2 contains Action 5, and Policy Rule 3 Chadha Expires January 2001 53 =0C Policy Information Model for MPLS Traffic Engineering July 2000 contains Action 6). Policy Rules 1, 2, and 3 also contain the conditions described earlier. The result of implementing these three policy rules is to activate the three traffic trunks described above. 5.1.3 Assignment of LSPs to traffic trunks The next requirement is to create policies that assign LSPs to the previously activated traffic trunks. The policy rules that are to be created for site 1 are: Policy Rule 4: Send traffic for GoldTrunk over GoldLSP Policy Rule 5: Send traffic for SilverTrunk over SilverLSP Policy Rule 6: Send traffic for BronzeTrunk over BronzeLSP Note that the above policy rules contain no conditions, only actions. The actions are described using instances of the MPLSAssignLSPAction object class. Action 7: Name: AssignGoldLSP mpTrafficTrunk: mpAssignedLSP: GoldLSP Action 8: Name: AssignSilverLSP mpTrafficTrunk: mpAssignedLSP: SilverLSP Action 9: Name: AssignBronzeLSP mpTrafficTrunk: mpAssignedLSP: BronzeLSP The effect of executing these rules is to assign the appropriate LSPs to the desired traffic trunks. 5.2 Creating traffic trunks In this example, we demonstrate the use of policies for activating traffic trunks and related information. A policy is defined that describes the traffic that will belong to this traffic trunk. Associated with the traffic trunk is a traffic profile that describes the resource requirements for this trunk. Also associated with the traffic trunk are one or more route specifications that Chadha Expires January 2001 54 =0C Policy Information Model for MPLS Traffic Engineering July 2000 specify possible ways of routing this traffic trunk through the network. Each such route specification has its hops and its resource requirements specified. The idea is that a traffic engineering module will use these specifications, along with information about the current nodes and links in the network, to perform computations that will yield a decision about which of the above specified route specifications should be used to create LSPs. In other words, not all route specifications will necessarily be used to create LSPs. The number of LSPs actually created to carry a traffic trunk will depend on the network resiliency requirements. Thus backup LSPs could be created in situations where high survivability and high performance is required, whereas backup LSPs may not be created for best-effort traffic. However, in cases of congestion/failures, existing route specifications can be used to create new LSPs to alleviate/remedy the problem. Route specification attributes are used to indicate routing preferences to aid the traffic engineering module in deciding which route specifications should be used to create LSPs. Note that another scenario could be that no route specifications are provided by the policy and the traffic engineering module computes suitable LSPs based on traffic trunk attributes alone. Initially, we assume that the following information is known to the management system: - All the LSRs in the network (instances of ComputerSystem (defined in CIM model [10])) - All the MPLS interfaces on these LSRs (instances of ProtocolEndpoint (defined in CIM model [10])) - All the links between MPLS interfaces on LSRs (instances of MPLSActiveConnection). The network administrator then defines policies for traffic trunks. For example, the following is an example of such a policy: If source address =3D 192.8.0.0/16 AND destination address =3D 128.5.0.0/16 AND ToS=3D3 then Assign this traffic to Traffic Trunk TT1 AND Police TT1 according to its traffic profile and drop all out-of-profile packets. All relevant attributes of TT1 must be specified. Related information such as a traffic profile TP1 for this traffic trunk must also be specified, including all relevant attributes of TP1, so that TP1 can be used for policing the traffic trunk. This is achieved by instantiating an instance of MPLSTrafficTrunk (named TT1), an instance of qosPolicyPRTrfcProf (named TP1), and an instance of association MPLSTrafficProfile relating TT1 to TP1. Further, TT1 could have a number of MPLSRouteSpec instances associated with it using the MPLSEligibleRouteSpec association. Chadha Expires January 2001 55 =0C Policy Information Model for MPLS Traffic Engineering July 2000 These route specifications basically describe possible paths for routing the trunk TT1 through the network. The route specifications can have associations to ProtocolEndpoint instances (association MPLSHopInRoute) that represent LSR interfaces that are hops for the route; the route specifications could also have associations to AutonomousSystem instances (association MPLSASInRoute) that are hops for the route. Thus each route can be loosely or strictly specified. Each MPLSRouteSpec has an MPLSResourceProfile instance associated with it via the MPLSRouteResourceProfile association. The MPLSResourceProfile instance contains information about the resources for this route specification, i.e. the average and maximum traffic rates and burst sizes. The above policy rule is represented using instances of PolicyRule (from [5]), qosPolicySimpleCondition (to represent the "if" portion of the rule), MPLSActivateTTAction (to represent the action of activating this traffic trunk), and qosPolicyPRAction (to represent the policing actions described above. The latter object class (qosPolicyPRAction ) allows the network operator to specify the action to take for non-conforming traffic (e.g. shape, drop, or re- mark). In this case, the action to be taken is to drop all non- conforming traffic. For details about the usage of qosPolicyPRAction, see QPIM [6]. The rule is structured as follows: - PolicyRule represents the policy rule described above and contains three conditions (three instances of qosPolicySimpleCondition) and two actions (instances of MPLSActivateTTAction and qosPolicyPRAction). - The instances of qosPolicySimpleCondition represent the classifier described above, i.e. source address =3D 192.8.0.0/16 AND destination address =3D 128.5.0.0/16 AND ToS=3D3. These conditions are represented using instances of qosPolicyVariable, qosPolicyIPv4AddrValue, and qosPolicyIntegerValue. - The instance of MPLSActivateTTAction contains a reference to TT1, which is associated with TP1 using association MPLSTrafficProfile, as described above. - The instance of qosPolicyPRAction (see [6] for details) contains a reference to TP1 and specifies that non-conforming traffic should be dropped (property qpOutOfProfileAction is set to 1 for DISCARD) - TT1 is associated with one or more MPLSRouteSpecs via the MPLSEligibleRouteSpec association. - Each instance of MPLSRouteSpec may be associated with an instance of MPLSResourceProfile (via the MPLSRouteResourceProfile association) and with hops that could be ProtocolEndpoints or AutonomousSystems (via the MPLSHopInRoute and the MPLSASInRoute associations, respectively). The above rule is processed by the traffic engineering module as described at the beginning of this section. Chadha Expires January 2001 56 =0C Policy Information Model for MPLS Traffic Engineering July 2000 5.3 Load balancing In order to perform load balancing, a traffic stream between two nodes must be assigned to two or more LSPs at the ingress node. Policies can be designed to decide how traffic gets partitioned across LSPs. Assume that a traffic stream is to be load-balanced across two existing LSPs. Possible approaches include: - Define two parallel traffic trunks between the two nodes and assign a different LSP to each traffic trunk. The proportion of the traffic stream to be carried by each traffic trunk is specified by the mpTrafficProportion property of the MPLSTrafficTrunk object class. Thus one could specify that 80% of the traffic is to be carried across the first LSP and 20% across the second. This is the approach referred to in Section 5.6.5 of RFC 2702. - Define one traffic trunk and assign the two LSPs to carry its traffic. This will result in the traffic being shared equally by the two LSPs. From the information modeling perspective, the first option can be implemented by activating two instances of MPLSTrafficTrunk with the value of the property mpTrafficProportion set to 80 for the first trunk and to 20 for the second (using policy action MPLSActivateTTAction as described earlier); and subsequently assigning an LSP to each of these traffic trunks using the MPLSAssignLSPAction as described in the previous example. The second option can be implemented by creating one instance of MPLSTrafficTrunk (using policy action MPLSActivateTTAction); and subsequently assigning two LSPs to this traffic trunk using two instances of the MPLSAssignLSPAction. 5.4 Implementing Service Level Agreements (SLAs) Suppose a service provider has an SLA with a customer that guarantees premium quality of service for that customer during business hours (8:00am to 5:00pm) and best-effort service during non-business hours. Let's say that the service provider wishes to implement this SLA by assigning the customer's traffic during business hours to a certain LSP L1 that carries premium traffic; and by assigning the customer's traffic during non-business hours to another LSP L2 that carries best-effort traffic. Policy rules that model this requirement can be specified as follows: Policy Rule 1: Define and activate traffic trunk for this customer's traffic. qosPolicySimpleConditions: Chadha Expires January 2001 57 =0C Policy Information Model for MPLS Traffic Engineering July 2000 MPLSActivateTTAction: Policy Rule 2: Assign premium LSP L1 for business hours Condition: The time is between 8:00am - 5:00pm Action: Assign LSP L1 to traffic trunk TT1 This policy is modeled as follows: an instance of PolicyTimePeriodCondition (defined in PCIM [5]) is used to model the above condition; and an instance of MPLSAssignLSPAction is used to model the above action. Policy Rule 3: Assign best-effort LSP L2 for non-business hours Condition: The time is between 5:00pm - 8:00am Action: Assign LSP L2 to traffic trunk TT1 This policy is modeled as follows: an instance of PolicyTimePeriodCondition (defined in PCIM [5]) is used to model the above condition; and an instance of MPLSAssignLSPAction is used to model the above action. 6. Security Considerations The security issues inherent in a policy-based management system are those of ensuring that only authorized users are allowed to manipulate policies, since these policies exert a large degree of control over the MPLS network. Such issues must be addressed by the implementation of the policy management system. 7. Conclusions This document provides a draft information model for policy-enabled MPLS network engineering. The authors of this draft would like to propose incorporation of this material into working group drafts in the mpls and/or policy working groups. 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Chadha Expires January 2001 58 =0C Policy Information Model for MPLS Traffic Engineering July 2000 3 Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., McManus, J., "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. 4 Li, T. and Y. Rekhter, "Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998. 5 Moore, B., Ellesson, E. , Strassner, J., "Policy Core Information Model -- Version 1 Specification", Internet Draft draft-ietf- policy-core-info-model-06.txt, May 2000. 6 Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., "Policy Framework QoS Information Model", Internet Draft draft-ietf- policy-qos-info-model-01.txt. 7 Mahon, H., Bernet, Y., Herzog, S., "Requirements for a Policy Management System", Internet Draft draft-ietf-policy-req-01.txt, October 1999. 8 Srinivasan, C., Viswanathan, A., Nadeau, T.D., "MPLS Traffic Engineering Management Information Base Using SMIv2", Internet Draft draft-ietf-mpls-te-mib-03.txt, March 2000. 9 Srinivasan, C., Viswanathan, A., Nadeau, T.D., "MPLS Label Switch Router Management Information Base Using SMIv2", Internet Draft draft-ietf-mpls-lsr-mib-04.txt, April 2000. 10 Distributed Management Task Force, Inc., "Common Information Model (CIM) Schema, version 2.3, March 2000. The components of the CIM v2.3 schema are available via links on the following DMTF web page: http://www.dmtf.org/spec/cims.html 11 Awduche, D.O., Berger, L., Gan, D., Li, T., Srinivasan, V., Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", Internet Draft draft-mpls-rsvp-lsp-tunnel-06.txt, July 2000. 12 Jamoussi, B., Aboul-Magd, O., Andersson, L., Ashwood-Smith, P., Hellstrand, F., Sundell, K., Callon, R., Dantu, R., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Halpern, J., Heinanen, J., Kilty, T., Malis, A., Vaananen, P., Wu, L., "Constraint-Based LSP Setup using LDP", Internet Draft draft-ietf-mpls-cr-ldp-04.txt, July 2000. 13 Wright, S., Herzog, S., Reichmeyer, F., Jaeger, R., "Requirements for Policy Enabled MPLS", Internet Draft draft-wright-policy- mpls-00.txt, March 2000. 14 Wright, S., Reichmeyer, F., Jaeger, R., Gibson, M., "Policy-Based Load-Balancing in Traffic-Engineered MPLS Networks", Internet Draft draft-wright-mpls-te-policy-00.txt, June 2000. Chadha Expires January 2001 59 =0C Policy Information Model for MPLS Traffic Engineering July 2000 9. Acknowledgments Many thanks are due to Tony Bogovic, Ravi Vaidyanathan, and George Mykoniatis for their insights and careful reviews of this material. 10. Author's Addresses Ritu Chadha Telcordia Technologies 445 South Street Morristown NJ 07960 Phone: +1-973-829-4869 Email: chadha@research.telcordia.com Huai-An (Paul) Lin Telcordia Technologies 445 South Street Morristown NJ 07960 Phone: +1-973-829-2412 Email: hlin1@telcordia.com Chadha Expires January 2001 60 =0C Policy Information Model for MPLS Traffic Engineering July 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDIN BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Chadha Expires January 2001 61 =0C --Flink_of_Cows_031_000-- From owner-mpls@UU.NET Mon Jul 17 14:27: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 OAA08444 for ; Mon, 17 Jul 2000 14:27:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiygn20058; Mon, 17 Jul 2000 18:27:19 GMT Received: by mail-control.mail.uu.net id QQiygn23339 for mpls-outgoing; Mon, 17 Jul 2000 18:26:43 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiygn23322 for ; Mon, 17 Jul 2000 18:26: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 QQiygn13203 for ; Mon, 17 Jul 2000 14:26:16 -0400 (EDT) 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 QQiygn19108 for ; Mon, 17 Jul 2000 18:26:15 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA25725 for mpls@uu.net; Mon, 17 Jul 2000 14:26:14 -0400 (EDT) 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 QQiygn23266 for ; Mon, 17 Jul 2000 18:25: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 QQiygn20843 for ; Mon, 17 Jul 2000 14:25:42 -0400 (EDT) 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 QQiygn18227 for ; Mon, 17 Jul 2000 18:25:10 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA11126; Mon, 17 Jul 2000 14:25:09 -0400 (EDT) Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-185.cisco.com [161.44.134.185]) by bucket.cisco.com (Mirapoint) with ESMTP id AAA76297; Mon, 17 Jul 2000 14:30:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20000717115030.01e0aa40@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jul 2000 14:21:49 -0400 To: Ritu Chadha , policy@raleigh.ibm.com, mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: Policy Information Model for MPLS Traffic Engineering Cc: chadha@mailee.research.telcordia.com In-Reply-To: <200007171531.LAA00502@monday.research.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, A few questions about your draft. 1) How does this draft differ from say the use of COPS and the definition of a PIB instead of using the object model? 2) It is not clear to me whether or not it is your intent to make this object model useful for both MPLS network management or just only for off-line TE. It seems from reading your document that your intent is to do both. --Tom From owner-mpls@UU.NET Mon Jul 17 14:53: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 OAA18739 for ; Mon, 17 Jul 2000 14:53:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiygp07912; Mon, 17 Jul 2000 18:51:49 GMT Received: by mail-control.mail.uu.net id QQiygp24866 for mpls-outgoing; Mon, 17 Jul 2000 18:51: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 QQiygp24858 for ; Mon, 17 Jul 2000 18:51: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 QQiygp17409 for ; Mon, 17 Jul 2000 14:51:11 -0400 (EDT) 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 QQiygp10156 for ; Mon, 17 Jul 2000 18:51:10 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA29803 for mpls@uu.net; Mon, 17 Jul 2000 14:51:10 -0400 (EDT) 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 QQiygp24739 for ; Mon, 17 Jul 2000 18:50: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 QQiygp17286 for ; Mon, 17 Jul 2000 14:50:30 -0400 (EDT) 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 QQiygp09525 for ; Mon, 17 Jul 2000 18:50:29 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA14381; Mon, 17 Jul 2000 14:50:21 -0400 (EDT) Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-185.cisco.com [161.44.134.185]) by bucket.cisco.com (Mirapoint) with ESMTP id AAA76378; Mon, 17 Jul 2000 14:55:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20000717144213.01e06010@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jul 2000 14:46:55 -0400 To: kireeti@juniper.net From: "Thomas D. Nadeau" Subject: draft-kompella-mpls-te-mib-00.txt Cc: mpls@UU.NET, cheenu Srinivasan , arun@force10networks.com, swallow@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, I am writing to you today to ask you about draft-kompella-mpls-te-mib-00.txt. Are you aware that there has been an MPLS Traffic Engineering MIB working group document for roughly 2 years now? After giving your document a quick read, it appears to cover most of what is contained in the LSR and TE MIBs. At this point The MPLS LSR MIB has cleared WG Last Call and the TE MIB is getting very close. What are your intentions for this new document? --Tom From owner-mpls@UU.NET Mon Jul 17 15:21: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 PAA27872 for ; Mon, 17 Jul 2000 15:21:45 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiygr20019; Mon, 17 Jul 2000 19:21:18 GMT Received: by mail-control.mail.uu.net id QQiygr08483 for mpls-outgoing; Mon, 17 Jul 2000 19:20:52 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiygr08478 for ; Mon, 17 Jul 2000 19:20: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 QQiygr00346 for ; Mon, 17 Jul 2000 15:20:33 -0400 (EDT) Received: from thumper.research.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: thumper.research.telcordia.com [128.96.41.1]) id QQiygr02969 for ; Mon, 17 Jul 2000 19:20:01 GMT Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6HJJgR28075; Mon, 17 Jul 2000 15:19:42 -0400 (EDT) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id PAA00605; Mon, 17 Jul 2000 15:19:42 -0400 (EDT) Message-Id: <200007171919.PAA00605@monday.research.telcordia.com> Date: Mon, 17 Jul 2000 15:19:42 -0400 (EDT) From: Ritu Chadha Reply-To: Ritu Chadha Subject: Re: Policy Information Model for MPLS Traffic Engineering To: chadha@research.telcordia.com, policy@raleigh.ibm.com, mpls@UU.NET, tnadeau@cisco.com Cc: chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@mailee.research.telcordia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wM0b/lZmaE2caRc51tgWEQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk Tom, >Date: Mon, 17 Jul 2000 14:21:49 -0400 >To: Ritu Chadha , policy@raleigh.ibm.com, >mpls@UU.NET >From: "Thomas D. Nadeau" >Subject: Re: Policy Information Model for MPLS Traffic Engineering >Cc: chadha@research.telcordia.com > > Hi, > > A few questions about your draft. > > 1) How does this draft differ from say the use > of COPS and the definition of a PIB > instead of using the object model? The information model in our draft would be used to describe policies that a PDP would implement, in accordance with the policy framework. The PDP could implement the policies via COPS and appropriate PIBs. Appropriate PIBS could very well be defined based on some of the information presented in our model. > > 2) It is not clear to me whether or not it is your > intent to make this object model useful > for both MPLS network management or just > only for off-line TE. It seems from reading > your document that your intent is to do > both. > That's correct; the intent is to be able to do both. > > --Tom Ritu ============================================================================= Ritu Chadha Senior Scientist Telcordia Technologies (973) 829-4869 (voice) MCC 1J-218R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= From owner-mpls@UU.NET Mon Jul 17 15:38: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 PAA04217 for ; Mon, 17 Jul 2000 15:38:52 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiygs27646; Mon, 17 Jul 2000 19:38:16 GMT Received: by mail-control.mail.uu.net id QQiygs09851 for mpls-outgoing; Mon, 17 Jul 2000 19:37: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 QQiygs09840 for ; Mon, 17 Jul 2000 19:37: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 QQiygs25573 for ; Mon, 17 Jul 2000 15:37:35 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQiygs27157 for ; Mon, 17 Jul 2000 19:37:20 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id MAA02390; Mon, 17 Jul 2000 12:37:10 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id MAA29518; Mon, 17 Jul 2000 12:35:57 -0700 (PDT) Date: Mon, 17 Jul 2000 12:35:57 -0700 (PDT) From: Kireeti Kompella Message-Id: <200007171935.MAA29518@kummer.juniper.net> To: kireeti@juniper.net, tnadeau@cisco.com Subject: Re: draft-kompella-mpls-te-mib-00.txt Cc: arun@force10networks.com, csrinivasan@tachion.com, mpls@UU.NET, swallow@cisco.com Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom, > I am writing to you today to ask you > about draft-kompella-mpls-te-mib-00.txt. Are > you aware that there has been an MPLS Traffic > Engineering MIB working group document for > roughly 2 years now? After giving your > document a quick read, it appears to > cover most of what is contained in the LSR > and TE MIBs. At this point The MPLS LSR MIB > has cleared WG Last Call and the TE MIB is > getting very close. I am aware of the TE/LSR MIBs. I tracked them for a while. The MIB I submitted was *implemented* in Nov 1998, updated in May 1999 to add traps, and has otherwise changed very little. It is being used in several production networks. I have had several favorable comments (and of course some requests for changes), and some have asked me to propose it as an ID. > What are your intentions for this > new document? I have submitted it to the Traffic Engineering WG. Kireeti. From owner-mpls@UU.NET Mon Jul 17 16:17: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 QAA17602 for ; Mon, 17 Jul 2000 16:17:53 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiygv15640; Mon, 17 Jul 2000 20:17:14 GMT Received: by mail-control.mail.uu.net id QQiygv25082 for mpls-outgoing; Mon, 17 Jul 2000 20:16:52 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiygv25048 for ; Mon, 17 Jul 2000 20:16: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 QQiygv10300 for ; Mon, 17 Jul 2000 16:16:35 -0400 (EDT) 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 QQiygv15049 for ; Mon, 17 Jul 2000 20:16:03 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA14879 for mpls@uu.net; Mon, 17 Jul 2000 16:16:03 -0400 (EDT) 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 QQiygv24860 for ; Mon, 17 Jul 2000 20:15: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 QQiygv02348 for ; Mon, 17 Jul 2000 16:15:35 -0400 (EDT) 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 QQiygv14991 for ; Mon, 17 Jul 2000 20:15:35 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA26501; Mon, 17 Jul 2000 16:15:26 -0400 (EDT) Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-185.cisco.com [161.44.134.185]) by bucket.cisco.com (Mirapoint) with ESMTP id AAA76823; Mon, 17 Jul 2000 16:20:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20000717160707.00a94030@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jul 2000 16:11:43 -0400 To: iso@ptl.abk.nec.co.jp, myoshida@ptl.abk.nec.co.jp, brunner@ccrle.nec.de, ak@ccrle.nec.de From: "Thomas D. Nadeau" Subject: draft-isoyama-policy-mpls-info-model-00.txt Cc: mpls@UU.NET, cheenu Srinivasan , arun@force10networks.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, I asked these same questions earlier about another draft which is related to defining an object model for MPLS Policy. A few questions about your draft entitled, "Policy Framework QoS Information Model for MPLS." 1) How does this draft differ from say the use of COPS and the definition of a PIB instead of using the object model? 2) It is not clear to me whether or not it is your intent to make this object model useful for both MPLS network management or just only for off-line TE. It seems from reading your document that your intent is to do both. --Tom From owner-mpls@UU.NET Mon Jul 17 16:29: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 QAA22954 for ; Mon, 17 Jul 2000 16:29:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiygv22198; Mon, 17 Jul 2000 20:28:36 GMT Received: by mail-control.mail.uu.net id QQiygv26947 for mpls-outgoing; Mon, 17 Jul 2000 20:28:12 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiygv26939 for ; Mon, 17 Jul 2000 20:28: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 QQiygv12427 for ; Mon, 17 Jul 2000 16:27:59 -0400 (EDT) From: Ted44tedT@netscape.net Received: from imo-d08.mx.aol.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: imo-d08.mx.aol.com [205.188.157.40]) id QQiygv23782 for ; Mon, 17 Jul 2000 20:27:44 GMT Received: from Ted44tedT@netscape.net by imo-d08.mx.aol.com (mail_out_v27.12.) id c.2e.7cd90 (16226); Mon, 17 Jul 2000 16:27:38 -0400 (EDT) Received: from netscape.com (aimmail09.aim.aol.com [205.188.144.201]) by air-in02.mx.aol.com (v75_b1.4) with ESMTP; Mon, 17 Jul 2000 16:27:38 -0400 Message-ID: <62EECAF0.4D07721A.02882A9A@netscape.net> Date: Mon, 17 Jul 2000 16:29:08 -0400 To: swallow@cisco.com Cc: mpls@UU.NET Subject: questions about ERO X-Mailer: Franklin Webmailer 1.0 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 Georage, I have two questions about ERO: 1. In draft-mpls-rsvp-lsp-tunnel-05.txt, section 4.3.2, it says "Certain operations to be performed along the path can be encoded in the ERO". In draft-mpls-rsvp-lsp-tunnel-06.txt, the operations is not mentioned. My questions is: no operation is allowed in new draft or it's still there but not mentioned? 2. In section 4.3.4.1, 3) it says "Next, the node evaluates the second subobject. If the node is also a part of the abstract node described by the second subobject, then the node deletes the first subobject and continues processing with step 2, above." In my understanding, when a node received a Path message with a ERO, it first check the first subobject in the ERO, if the node is a part of the abstract node described by the fisrt subobject, then the node check the second subobject. If no second subobject, ERO is removed by the node. If there is the second subobject, the node should use the second subobject to replace the first subobj or insert the second subobj before the first subobject. Is that correct? What the semantics of "Next, the node evaluates the second subobject. If the node is also a part of the abstract node described by the second subobject" ? Is the node is that received the ERO with the first subobj? If it is, how is it described by the second subobj? I am appreciate for your answer. Regards, Ted ---------- Get your own FREE, personal Netscape Webmail account today at http://home.netscape.com/webmail/ From owner-mpls@UU.NET Mon Jul 17 16:32:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24715 for ; Mon, 17 Jul 2000 16:32:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiygw24830; Mon, 17 Jul 2000 20:32:27 GMT Received: by mail-control.mail.uu.net id QQiygw27500 for mpls-outgoing; Mon, 17 Jul 2000 20:32: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 QQiygw27467 for ; Mon, 17 Jul 2000 20:32: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 QQiygw05172 for ; Mon, 17 Jul 2000 16:32:01 -0400 (EDT) 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 QQiygw27061 for ; Mon, 17 Jul 2000 20:31:44 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA18251 for mpls@uu.net; Mon, 17 Jul 2000 16:31:43 -0400 (EDT) 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 QQiygw27399 for ; Mon, 17 Jul 2000 20:31: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 QQiygw13260 for ; Mon, 17 Jul 2000 16:31:20 -0400 (EDT) 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 QQiygw26705 for ; Mon, 17 Jul 2000 20:31:19 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA28243; Mon, 17 Jul 2000 16:27:08 -0400 (EDT) Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-185.cisco.com [161.44.134.185]) by bucket.cisco.com (Mirapoint) with ESMTP id AAA76899; Mon, 17 Jul 2000 16:32:21 -0400 (EDT) Message-Id: <4.3.2.7.2.20000717161210.04c6f9b0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jul 2000 16:23:13 -0400 To: Ritu Chadha , chadha@research.telcordia.com, policy@raleigh.ibm.com, mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: Policy Information Model for MPLS Traffic Engineering Cc: chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@mailee.research.telcordia.com In-Reply-To: <200007171919.PAA00605@monday.research.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Ritu, My comments are inline: > > A few questions about your draft. > > > > 1) How does this draft differ from say the use > > of COPS and the definition of a PIB > > instead of using the object model? > >The information model in our draft would be used to describe policies >that a PDP would implement, in accordance with the policy framework. >The PDP could implement the policies via COPS and appropriate PIBs. >Appropriate PIBS could very well be defined based on some of the >information presented in our model. I disagree. This is what the PIB should be used for. The object model you define could very well be done by a proprietary vendor. I don't see the need or advantage to do so in a standard way. What advantages do you see of defining such an object model versus using say, a PIB and COPS to define and implement policy for MPLS? > > 2) It is not clear to me whether or not it is your > > intent to make this object model useful > > for both MPLS network management or just > > only for off-line TE. It seems from reading > > your document that your intent is to do > > both. > > > >That's correct; the intent is to be able to do both. In terms of device management, is it then your assertion that the MIBs will need to be re-aligned to fit in with your object model in order to do device-level management? As I see it, I don't see how the MIBs as they are defined today, fit in with your object model. If anything, I think that the object model should be changed to reflect that which is defined in the MIBs. --Tom From owner-mpls@UU.NET Mon Jul 17 17:08: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 RAA08864 for ; Mon, 17 Jul 2000 17:08:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiygy22849; Mon, 17 Jul 2000 21:07:48 GMT Received: by mail-control.mail.uu.net id QQiygy12306 for mpls-outgoing; Mon, 17 Jul 2000 21:07: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 QQiygy12295 for ; Mon, 17 Jul 2000 21:07: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 QQiygy11119 for ; Mon, 17 Jul 2000 17:06:57 -0400 (EDT) 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 QQiygy22099 for ; Mon, 17 Jul 2000 21:06:56 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA24463 for mpls@uu.net; Mon, 17 Jul 2000 17:06:55 -0400 (EDT) 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 QQiygy12223 for ; Mon, 17 Jul 2000 21:06: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 QQiygy19285 for ; Mon, 17 Jul 2000 17:06:23 -0400 (EDT) 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 QQiygy13960 for ; Mon, 17 Jul 2000 21:05:53 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 RAA03822 for ; Mon, 17 Jul 2000 17:05:52 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA08132 for ; Mon, 17 Jul 2000 17:05:52 -0400 (EDT) Message-Id: <200007172105.RAA08132@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: [Marcia Beaulieu: Re: 48th IETF DRAFT Agenda] Date: Mon, 17 Jul 2000 17:05:52 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk The plan is to have the first session of MPLS Wednesday AM. This conflicts with Diff Serv. I'll make certain that the Diff Serv related drafts are considered on Thursday. ...George ------- Forwarded Message Return-Path: mbeaulie@ietf.org Delivery-Date: Mon, 17 Jul 2000 12:03:34 -0400 Return-Path: mbeaulie@ietf.org Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA03846 for ; Mon, 17 Jul 2000 12:03:33 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA00335 for ; Mon, 17 Jul 2000 09:03:46 -0700 (PDT) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with SMTP id e6HG3WO06808 for ; Mon, 17 Jul 2000 09:03:32 -0700 (PDT) Received: from cnri.reston.va.us (ns.CNRI.Reston.VA.US [132.151.1.1]) by proxy3.cisco.com with SMTP (MailShield v1.5); Mon, 17 Jul 2000 09:03:40 -0700 Received: from ietf.org (cnri-7-182.cnri.reston.va.us [132.151.7.182]) by cnri.reston.va.us (8.9.1a/8.9.1) with ESMTP id MAA04681 for ; Mon, 17 Jul 2000 12:03:27 -0400 (EDT) Message-ID: <39732DB0.F965650A@ietf.org> Date: Mon, 17 Jul 2000 12:00:48 -0400 From: Marcia Beaulieu X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow Subject: Re: 48th IETF DRAFT Agenda References: <200007171541.LAA29161@lir.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-SMTP-HELO: cnri.reston.va.us X-SMTP-MAIL-FROM: mbeaulie@ietf.org X-SMAP-Received-From: outside X-SMTP-PEER-INFO: ns.CNRI.Reston.VA.US [132.151.1.1] WEDNESDAY, August 2, 2000 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP fax Internet Fax WG INT idn Internationalized Domain Names WG * OPS nim Network Information Model BOF RTG mobileip IP Routing for Wireless/Mobile Hosts WG RTG mpls Multiprotocol Label Switching WG SEC pkix Public-Key Infrastructure (X.509) WG TSV avt Audio/Video Transport WG * TSV diffserv Differentiated Services WG THURSDAY, August 3, 2000 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP beep Blocks Extensible Exchange Protocol WG APP webdav WWW Distributed Authoring and Versioning WG INT dnsext DNS Extensions WG OPS rmonmib Remote Network Monitoring WG RTG mpls Multiprotocol Label Switching WG SEC idwg Intrusion Detection Exchange Format WG TSV nat Network Address Translators WG * TSV iptel IP Telephony WG * George Swallow wrote: > Hi - > > > I only see one session for mpls; I believe we had requested two. > > > > - Vijay > > When can we expect a resolution on this. I'd like to know how much > time I have for presentations and folks are getting antsy about travel > arrangements. > > Thanks, > > ...George > > p.s. > > Here's the original request. > > > To: agenda@ietf.org > > Cc: oran, rcoltun@redback.com, vijay@cosinenet.com, swallow > > Subject: Re: 48th IETF: Working Group/BOF Scheduling > > In-reply-to: Your message of "Wed, 24 May 2000 13:32:08 EDT." > > <200005241732.NAA09724@ietf.org> > > Date: Tue, 13 Jun 2000 16:58:32 -0400 > > From: George Swallow > > > > > > We would like to request two slots for MPLS. With the recent interest > > in the MPLS control plane and being back in the US, I would expect > > attendance is in excess of 400. > > > > We would like to avoid scheduling conflicts with: diff-serv, idr, > > ospf, isis, traffic engineering, and IP-Optical (if it gets > > scheduled). > > > > Morning or evening sessions would be nice as I expect a full agenda. > > The extra time would help. > > > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 ------- End of Forwarded Message From owner-mpls@UU.NET Mon Jul 17 17:42: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 RAA27777 for ; Mon, 17 Jul 2000 17:42:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyha19977; Mon, 17 Jul 2000 21:42:00 GMT Received: by mail-control.mail.uu.net id QQiyha16231 for mpls-outgoing; Mon, 17 Jul 2000 21:41: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 QQiyha16217 for ; Mon, 17 Jul 2000 21:41: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 QQiyha16702 for ; Mon, 17 Jul 2000 17:41:05 -0400 (EDT) Received: from brmnj-fw by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [63.89.157.2]) id QQiyha18869 for ; Mon, 17 Jul 2000 21:40:50 GMT Received: by BMAILNJ with Internet Mail Service (5.5.2650.21) id <3VY46J1T>; Mon, 17 Jul 2000 17:33:50 -0400 Message-ID: <6399122981E1D211AB490090271E0AA38B1DEA@BMAILNJ> From: "Francis Reichmeyer (IPHighway MA)" To: "'Thomas D. Nadeau'" , Ritu Chadha , chadha@research.telcordia.com, policy@raleigh.ibm.com, mpls@UU.NET Cc: chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@mailee.research.telcordia.com Subject: RE: Policy Information Model for MPLS Traffic Engineering Date: Mon, 17 Jul 2000 17:33:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I haven't had the chance to read the draft being discussed here yet (still looking for a pointer to it, can anyone help with that? :^). That said, there is something similar going on with Diff Serv/QoS. The Policy Framework WG has specified a QoS Information Model while the RAP WG is working on a Diff Serv/QoS PIB. Along with the QoS Information Model, there is also a LDAP schema, but this is separate from the PIB (as it should be). So, there is some precedent for this "information architecture." Again, I haven't seen the MPLS TE Information Model draft to verify it's at the same (abstraction) level as the QoS Info Model, and there is no MPLS/TE PIB (yet ;^), so I can't say the same relationship applies, but it could. Thanks, -Fran > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, July 17, 2000 4:23 PM > To: Ritu Chadha; chadha@research.telcordia.com; > policy@raleigh.ibm.com; > mpls@UU.NET > Cc: chadha@research.telcordia.com; hlin1@telcordia.com; > mykoniat@mailee.research.telcordia.com > Subject: Re: Policy Information Model for MPLS Traffic Engineering > > > > Hi Ritu, > > My comments are inline: > > > > A few questions about your draft. > > > > > > 1) How does this draft differ from say the use > > > of COPS and the definition of a PIB > > > instead of using the object model? > > > >The information model in our draft would be used to describe policies > >that a PDP would implement, in accordance with the policy framework. > >The PDP could implement the policies via COPS and appropriate PIBs. > >Appropriate PIBS could very well be defined based on some of the > >information presented in our model. > > I disagree. This is what the PIB should be used for. > The object model you define could very well be done by > a proprietary vendor. I don't see the need or advantage > to do so in a standard way. What advantages do you see of > defining such an object model versus using say, a PIB > and COPS to define and implement policy for MPLS? > > > > 2) It is not clear to me whether or not it is your > > > intent to make this object model useful > > > for both MPLS network management or just > > > only for off-line TE. It seems from reading > > > your document that your intent is to do > > > both. > > > > > > >That's correct; the intent is to be able to do both. > > In terms of device management, is it then your > assertion that the MIBs will need to be re-aligned to fit > in with your object model in order to do device-level > management? As I see it, I don't see how the MIBs as they > are defined today, fit in with your object model. If anything, > I think that the object model should be changed to reflect > that which is defined in the MIBs. > > --Tom > > > From owner-mpls@UU.NET Mon Jul 17 17:45:25 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29137 for ; Mon, 17 Jul 2000 17:45:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyhb00663; Mon, 17 Jul 2000 21:45:04 GMT Received: by mail-control.mail.uu.net id QQiyha16447 for mpls-outgoing; Mon, 17 Jul 2000 21:44:31 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiyha16442 for ; Mon, 17 Jul 2000 21:44:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyha17148 for ; Mon, 17 Jul 2000 17:44:20 -0400 (EDT) Received: from thumper.research.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: thumper.research.telcordia.com [128.96.41.1]) id QQiyha21938 for ; Mon, 17 Jul 2000 21:44:20 GMT Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6HLi8R06059; Mon, 17 Jul 2000 17:44:08 -0400 (EDT) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id RAA00652; Mon, 17 Jul 2000 17:44:07 -0400 (EDT) Message-Id: <200007172144.RAA00652@monday.research.telcordia.com> Date: Mon, 17 Jul 2000 17:44:07 -0400 (EDT) From: Ritu Chadha Reply-To: Ritu Chadha Subject: Re: Policy Information Model for MPLS Traffic Engineering To: policy@raleigh.ibm.com, mpls@UU.NET, tnadeau@cisco.com Cc: chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@research.telcordia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yRYjNFJLxZsT1Hlyz0nvXA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk Tom, Comments inline. > Hi Ritu, > > My comments are inline: > >> > A few questions about your draft. >> > >> > 1) How does this draft differ from say the use >> > of COPS and the definition of a PIB >> > instead of using the object model? >> >>The information model in our draft would be used to describe policies >>that a PDP would implement, in accordance with the policy framework. >>The PDP could implement the policies via COPS and appropriate PIBs. >>Appropriate PIBS could very well be defined based on some of the >>information presented in our model. > > I disagree. This is what the PIB should be used for. >The object model you define could very well be done by >a proprietary vendor. I don't see the need or advantage >to do so in a standard way. What advantages do you see of >defining such an object model versus using say, a PIB >and COPS to define and implement policy for MPLS? The definition of such policy information models is the whole raison d'etre of the Policy Framework WG. The following snippet from "Requirements for a Policy Management System", draft-ietf-policy-req-01.txt, summarizes the need for a standardized common information model: "...centralized management leads to the need for a repository; scalability requires a means to commu- nicate the data beyond the repository; abstraction requires a common information model; automation requires the abstraction and components to perform actions based on management data and real-time inputs. Please refer to the above draft for details. The charter of the policy WG states clearly that one must be able to translate high-level policy information into device configuration information. This will require coordination with MIB and PIB development work because, as you correctly point out, ultimately the devices will be configured using COPS/SNMP/etc. A related document ("Policy-Based Load-Balancing in Traffic-Engineered MPLS Networks", draft-wright-mpls-te-policy-00.txt) also aims to provide guidance for the development of a PIB for MPLS based on a policy information model. > >> > 2) It is not clear to me whether or not it is your >> > intent to make this object model useful >> > for both MPLS network management or just >> > only for off-line TE. It seems from reading >> > your document that your intent is to do >> > both. >> > >> >>That's correct; the intent is to be able to do both. > > In terms of device management, is it then your >assertion that the MIBs will need to be re-aligned to fit >in with your object model in order to do device-level >management? As I see it, I don't see how the MIBs as they >are defined today, fit in with your object model. If anything, >I think that the object model should be changed to reflect >that which is defined in the MIBs. No; there should be a way to map from the policy information model to the appropriate MIBs/PIBs, but I don't see a need to re-align the MIBs. I disagree with your statement that current MIBs do not fit in with our object model; we have based some of our LSP model on the MPLS TE MIB as noted in our draft. Since there are currently no MPLS TE PIBs defined, I can't comment on the required re-alignment there. If it turns out that there is a fundamental misalignment and that there is no way to map from our information model to existing MIBs, then we may need to revise our information model. We plan to do this as the relevant MIBs mature and PIBs are defined. > > --Tom > > Ritu From owner-mpls@UU.NET Mon Jul 17 22:17: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 WAA20646 for ; Mon, 17 Jul 2000 22:17:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyht05911; Tue, 18 Jul 2000 02:17:08 GMT Received: by mail-control.mail.uu.net id QQiyht12515 for mpls-outgoing; Tue, 18 Jul 2000 02:16: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 QQiyht12504 for ; Tue, 18 Jul 2000 02:16: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 QQiyht23382 for ; Mon, 17 Jul 2000 22:16:05 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyht01526 for ; Tue, 18 Jul 2000 02:15:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA25618 for mpls@uu.net; Mon, 17 Jul 2000 22:15:34 -0400 (EDT) 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 QQiyht12169 for ; Tue, 18 Jul 2000 02:15: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 QQiyhs01739 for ; Mon, 17 Jul 2000 22:14:59 -0400 (EDT) Received: from brixcorp2.brixnet.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: brixcorp2.brixnet.com [216.91.233.5]) id QQiyhs03901 for ; Tue, 18 Jul 2000 02:14:28 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jul 2000 22:14:28 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB2AECCA@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'phaneesh'" , mpls@UU.NET Subject: RE: Multiple LDP Sessions Date: Mon, 17 Jul 2000 22:14:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA20646 Hello Phani, This issue was addressed in the 06 version of the MIB, which should be out any day now (submitted on Friday 7/14). As you point out the relationship between the Session and Peer tables is not correct. The fix was to have an AUGMENTS relationship between these tables (which indicates a one-to-one mapping). -Joan > -----Original Message----- > From: phaneesh [mailto:phaneesh@chiplogic.com] > Sent: Monday, July 17, 2000 9:23 AM > To: mpls@UU.NET > Subject: Multiple LDP Sessions > > > Hi, > > I am reading "draft-ietf-mpls-ldp-mib-05.txt", there in page-7 it is > said that, "A row in MplsLdpEntityPeerTable may be related to one or > more entries in MplsLdpHelloAdjacencyTable  and one or more entries in > MplsLdpSessionTable.". > > Let us take the case MplsLdpSessionTable & > MplsLdpEntityPeerTable. Both > the tables are using MplsLdpPeerLdpId as an index. We create one and > only one session for each MplsLdpPeerLdpId. The same happens, when we > create MplsLdpEntityPeerTable entry. Then it should be one-to-one > mapping between MplsLdpSessionTable & MplsLdpEntityPeerTable. > > I will appreciate any comments on the above. > > Thanks, > Phani. > From owner-mpls@UU.NET Mon Jul 17 22:39: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 WAA28505 for ; Mon, 17 Jul 2000 22:39:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyhu09123; Tue, 18 Jul 2000 02:38:40 GMT Received: by mail-control.mail.uu.net id QQiyhu15122 for mpls-outgoing; Tue, 18 Jul 2000 02:38:10 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiyhu15112 for ; Tue, 18 Jul 2000 02:38: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 QQiyhu25983 for ; Mon, 17 Jul 2000 22:37:54 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyhu08542 for ; Tue, 18 Jul 2000 02:37:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA27213 for mpls@uu.net; Mon, 17 Jul 2000 22:37:34 -0400 (EDT) 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 QQiyhu15024 for ; Tue, 18 Jul 2000 02:36:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyhu25891 for ; Mon, 17 Jul 2000 22:36:54 -0400 (EDT) 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 QQiyhu21269 for ; Tue, 18 Jul 2000 02:36:53 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA00497; Mon, 17 Jul 2000 22:36:42 -0400 (EDT) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAB01087; Mon, 17 Jul 2000 22:41:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20000717220513.04c86a70@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jul 2000 22:30:29 -0400 To: Ritu Chadha , policy@raleigh.ibm.com, mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: Policy Information Model for MPLS Traffic Engineering Cc: chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@research.telcordia.com In-Reply-To: <200007172144.RAA00652@monday.research.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, >The definition of such policy information models is the >whole raison d'etre of the Policy Framework WG. The following >snippet from "Requirements for a Policy Management System", >draft-ietf-policy-req-01.txt, >summarizes the need for a standardized common information model: I thought that the purpose of the MPLS WG was to define protocols (and MIBs to manage them) not policy, but I may be mistaken here. ;) I can understand holding topological information or such network-wide things, but the inclusion of other information into this standard object model seems redundant, doesn't it? Isn't this why we have the MIBs and PIBs? That is, to define what is manageable, and how some of those managed objects are provisioned via a defined policy? Why should we spend time defining an object model which has basically already been defined for MPLS? --Tom From owner-mpls@UU.NET Tue Jul 18 03:46:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15772 for ; Tue, 18 Jul 2000 03:46:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyip02726; Tue, 18 Jul 2000 07:46:03 GMT Received: by mail-control.mail.uu.net id QQiyip27613 for mpls-outgoing; Tue, 18 Jul 2000 07:45: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 QQiyip27608 for ; Tue, 18 Jul 2000 07:45:32 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 QQiyip26616 for ; Tue, 18 Jul 2000 03:45:25 -0400 (EDT) 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 QQiyio02334 for ; Tue, 18 Jul 2000 07:44:55 GMT Received: from ccrle.nec.de (santiago.berlin.ccrle.nec.de [192.168.100.61]) by tokyo.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id e6I7kxR02083; Tue, 18 Jul 2000 09:46:59 +0200 (CEST) Message-ID: <39740ACC.C1F6AF8D@ccrle.nec.de> Date: Tue, 18 Jul 2000 09:44:12 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: iso@ptl.abk.nec.co.jp, myoshida@ptl.abk.nec.co.jp, ak@ccrle.nec.de, mpls@UU.NET, cheenu Srinivasan , arun@force10networks.com, Juergen Quittek , IETF Policy WG Subject: Re: draft-isoyama-policy-mpls-info-model-00.txt References: <4.3.2.7.2.20000717160707.00a94030@bucket.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thomas, The answer is fairly the same than the one from Chadha. The information model works on a higher-level of abstraction than COPS-PR. The model is used in the policy server (refer to the Policy Framework). The communication between policy server and the network can be implemented via COPS or other means. From the information model point of view, it does not matter if the operation is online or offline, the only thing the model allows is the specification of rules applied to functions. Marcus "Thomas D. Nadeau" wrote: > > Hi, > > I asked these same questions earlier about another > draft which is related to defining an object model for > MPLS Policy. A few questions about your draft entitled, > "Policy Framework QoS Information Model for MPLS." > > 1) How does this draft differ from say the use > of COPS and the definition of a PIB > instead of using the object model? > > 2) It is not clear to me whether or not it is your > intent to make this object model useful > for both MPLS network management or just > only for off-line TE. It seems from reading > your document that your intent is to do > both. > > --Tom -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner New address starting 9/1/2000 Postal Mail: Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 905110 Fax: +49 (0)6221/ 9051155 Address valid until 8/31/2000 Postal Mail: Hardenbergplatz 2 D-10623 Berlin Germany Phone: +49 (0)30/ 25 42 30 17 Fax: +49 (0)30/ 25 42 30 99 From owner-mpls@UU.NET Tue Jul 18 04:20: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 EAA28657 for ; Tue, 18 Jul 2000 04:20:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyir13918; Tue, 18 Jul 2000 08:20:05 GMT Received: by mail-control.mail.uu.net id QQiyir10486 for mpls-outgoing; Tue, 18 Jul 2000 08:19:45 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiyir10480 for ; Tue, 18 Jul 2000 08:19: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 QQiyir29819 for ; Tue, 18 Jul 2000 04:19:17 -0400 (EDT) Received: from tokyo.ccrle.nec.de by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tokyo.ccrle.nec.de [195.37.70.2]) id QQiyir20741 for ; Tue, 18 Jul 2000 08:19:16 GMT Received: from ccrle.nec.de (santiago.berlin.ccrle.nec.de [192.168.100.61]) by tokyo.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id e6I8BER02229; Tue, 18 Jul 2000 10:11:14 +0200 (CEST) Message-ID: <3974107B.46942CE9@ccrle.nec.de> Date: Tue, 18 Jul 2000 10:08:27 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: policy@raleigh.ibm.com, mpls@UU.NET Subject: Re: Policy Information Model for MPLS Traffic Engineering References: <4.3.2.7.2.20000717161210.04c6f9b0@bucket.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tom, A propriatary vendor can still define its own information model, whether it succeeds on the marcket is an other story. But that argument paly agains many many IETF standards. Marcus "Thomas D. Nadeau" wrote: > >The information model in our draft would be used to describe policies > >that a PDP would implement, in accordance with the policy framework. > >The PDP could implement the policies via COPS and appropriate PIBs. > >Appropriate PIBS could very well be defined based on some of the > >information presented in our model. > > I disagree. This is what the PIB should be used for. > The object model you define could very well be done by > a proprietary vendor. I don't see the need or advantage > to do so in a standard way. What advantages do you see of > defining such an object model versus using say, a PIB > and COPS to define and implement policy for MPLS? -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner New address starting 9/1/2000 Postal Mail: Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 905110 Fax: +49 (0)6221/ 9051155 Address valid until 8/31/2000 Postal Mail: Hardenbergplatz 2 D-10623 Berlin Germany Phone: +49 (0)30/ 25 42 30 17 Fax: +49 (0)30/ 25 42 30 99 From owner-mpls@UU.NET Tue Jul 18 04:20: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 EAA28790 for ; Tue, 18 Jul 2000 04:20:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyir21522; Tue, 18 Jul 2000 08:20:18 GMT Received: by mail-control.mail.uu.net id QQiyir10489 for mpls-outgoing; Tue, 18 Jul 2000 08:19:50 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 QQiyir10481 for ; Tue, 18 Jul 2000 08:19: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 QQiyir29823 for ; Tue, 18 Jul 2000 04:19:18 -0400 (EDT) Received: from tokyo.ccrle.nec.de by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tokyo.ccrle.nec.de [195.37.70.2]) id QQiyir20744 for ; Tue, 18 Jul 2000 08:19:17 GMT Received: from ccrle.nec.de (santiago.berlin.ccrle.nec.de [192.168.100.61]) by tokyo.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id e6I8FLR02245; Tue, 18 Jul 2000 10:15:21 +0200 (CEST) Message-ID: <39741172.37D3B9C6@ccrle.nec.de> Date: Tue, 18 Jul 2000 10:12:34 +0200 From: Marcus Brunner Reply-To: brunner@ccrle.nec.de Organization: NEC Europe Ltd X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en,de MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: policy@raleigh.ibm.com, mpls@UU.NET Subject: Re: Policy Information Model for MPLS Traffic Engineering References: <4.3.2.7.2.20000717220513.04c86a70@bucket.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tom, At least our draft (draft-isoyama-policy-mpls-info-model-00.txt) is intend to go into the policy working group. In a later stage, e.g., for the definition of a MPLS PIB, the situation may change. Marcus "Thomas D. Nadeau" wrote: > > Hi, > > >The definition of such policy information models is the > >whole raison d'etre of the Policy Framework WG. The following > >snippet from "Requirements for a Policy Management System", > >draft-ietf-policy-req-01.txt, > >summarizes the need for a standardized common information model: > > I thought that the purpose of the MPLS WG was to define > protocols (and MIBs to manage them) not policy, but I may be > mistaken here. ;) I can understand holding topological information > or such network-wide things, but the inclusion of other information > into this standard object model seems redundant, doesn't it? > Isn't this why we have the MIBs and PIBs? That is, to define > what is manageable, and how some of those managed objects are > provisioned via a defined policy? Why should we spend time > defining an object model which has basically already been > defined for MPLS? > > --Tom -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de WWW: http://www.ccrle.nec.de/ personal home page: http://www.tik.ee.ethz.ch/~brunner New address starting 9/1/2000 Postal Mail: Adenauerplatz 6 D-69115 Heidelberg Germany Phone: +49 (0)6221/ 905110 Fax: +49 (0)6221/ 9051155 Address valid until 8/31/2000 Postal Mail: Hardenbergplatz 2 D-10623 Berlin Germany Phone: +49 (0)30/ 25 42 30 17 Fax: +49 (0)30/ 25 42 30 99 From owner-mpls@UU.NET Tue Jul 18 06:36: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 GAA14386 for ; Tue, 18 Jul 2000 06:36:57 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyja10068; Tue, 18 Jul 2000 10:36:24 GMT Received: by mail-control.mail.uu.net id QQiyja10236 for mpls-outgoing; Tue, 18 Jul 2000 10:36: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 QQiyja10196 for ; Tue, 18 Jul 2000 10:35: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 QQiyja13924 for ; Tue, 18 Jul 2000 06:35:44 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyja09652 for ; Tue, 18 Jul 2000 10:35:43 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA20595 for mpls@uu.net; Tue, 18 Jul 2000 06:35:23 -0400 (EDT) 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 QQiyja10169 for ; Tue, 18 Jul 2000 10:34: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 QQiyja13868 for ; Tue, 18 Jul 2000 06:34:27 -0400 (EDT) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQiyja21384 for ; Tue, 18 Jul 2000 10:33:52 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12857; Tue, 18 Jul 2000 06:33:51 -0400 (EDT) Message-Id: <200007181033.GAA12857@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; CC: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-fujita-mpls-crldp-crankback-01.txt Date: Tue, 18 Jul 2000 06:33:51 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Crankback Routing Extensions for CR-LDP Author(s) : A. Iwata, N. Fujita, G. Ash Filename : draft-fujita-mpls-crldp-crankback-01.txt Pages : 13 Date : 17-Jul-00 This draft proposes crankback routing extensions for CR-LDP signaling. Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that label requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for CR-LDP so that the label request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. Furthermore, the proposed crankback routing schemes can be also applied to end-to-end LSP restoration by indicating the location of the failure link or node. This would significantly improve the recovery ratio for failed LSPs, especially in situations where a large number of setup requests are triggered at the same time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fujita-mpls-crldp-crankback-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-fujita-mpls-crldp-crankback-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-fujita-mpls-crldp-crankback-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000717145602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-fujita-mpls-crldp-crankback-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-fujita-mpls-crldp-crankback-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000717145602.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Jul 18 08:07: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 IAA18270 for ; Tue, 18 Jul 2000 08:07:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyjg22696; Tue, 18 Jul 2000 12:07:03 GMT Received: by mail-control.mail.uu.net id QQiyjg02688 for mpls-outgoing; Tue, 18 Jul 2000 12:06:26 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiyjg02518 for ; Tue, 18 Jul 2000 12:06: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 QQiyjg22963; Tue, 18 Jul 2000 08:06:11 -0400 (EDT) Received: from almso1.proxy.att.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: almso1.att.com [192.128.167.69]) id QQiyjg22223; Tue, 18 Jul 2000 12:05:55 GMT Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id IAA05734; Tue, 18 Jul 2000 08:05:55 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id IAA27887; Tue, 18 Jul 2000 08:04:45 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2650.21) id <335245S6>; Tue, 18 Jul 2000 08:05:54 -0400 Message-ID: <1B08859602C8D211B66F0000C0769CFA01BBDAF0@njc240po03.mt.att.com> From: "Ash, Gerald R (Jerry), ALCOO" To: te-wg@UU.NET Cc: "Ash, Gerald R (Jerry), ALCOO" , "'mpls@UU.NET'" Subject: draft-ash-te-qos-routing-01.txt (TE & QoS Methods for IP-,ATM-,& TDM-Based Multiservice Networks) Date: Tue, 18 Jul 2000 08:05:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk PDF files (with figures) for draft-ash-te-qos-routing-01.txt (TE & QoS Methods for IP-,ATM-,& TDM-Based Multiservice Networks) can be located at: http://www.research.att.com/~jrex/jerry/ The draft has quite a few additions compared to the 00 version, which include o in ANNEX 2 compare network performance with no-TE methods vs. various TE methods o in ANNEX 2 provide more description of event-dependent (EDR) TE methods (in support of the TE Framework Draft) o added ANNEX 5 "Dynamic Traffic Routing" (DTR) to illustrate - IP over optical (IPO) trends - layer 1-3 routing/TE inter-relationships and interactions - advantages of DTR/IPO in terms of network performance, reliability, and efficiency o in ANNEX 6 "Capacity Management Methods" added more design comparisons - single-area flat network vs. multi-area 2-level hierarchical design - fixed-transport-routing vs. dynamic-transport-routing design - separate voice/ISDN design + separate data design vs. integrated voice/ISDN & data design o added Conclusions/Recommendations Sections to MAIN draft and ANNEXes to highlight the BCP recommendations suggested by the draft Comments welcome. Thanks, Jerry Ash ---------------------------------------------------- Gerald R. (Jerry) Ash AT&T Labs Middletown, NJ, USA gash@att.com ---------------------------------------------------- To: IETF-Announce: ; Subject: I-D ACTION:draft-ash-te-qos-routing-01.txt From: Internet-Drafts@ietf.org Date: Mon, 10 Jul 2000 06:32:50 -0400 Reply-to: Internet-Drafts@ietf.org Sender: nsyracus@cnri.reston.va.us A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Traffic Engineering & QoS Methods for IP-,ATM-,& TDMased Multiservice Networks Author(s) : G. Ash Filename : draft-ash-te-qos-routing-01.txt Pages : 10 Date : 07-Jul-00 The draft describes, analyzes, and recommends traffic engineering (TE) methods which control a network's response to traffic demands and other stimuli, such as link failures or node failures. These TE methods include: *traffic management through control of routing functions, which include call routing (number/name translation to routing address), connection routing, QoS resource management, routing table management, and dynamic transport routing. *capacity management through control of network design. *TE operational requirements for traffic management and capacity management, including forecasting, performance monitoring, and short-term network adjustment. These TE methods are recommended for application across network types based on established practice and experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ash-te-qos-routing-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ash-te-qos-routing-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ash-te-qos-routing-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-mpls@UU.NET Tue Jul 18 11:18: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 LAA14952 for ; Tue, 18 Jul 2000 11:18:34 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyjt22926; Tue, 18 Jul 2000 15:18:08 GMT Received: by mail-control.mail.uu.net id QQiyjt27389 for mpls-outgoing; Tue, 18 Jul 2000 15:17:27 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiyjt27369 for ; Tue, 18 Jul 2000 15:17: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 QQiyjt05834 for ; Tue, 18 Jul 2000 11:16:51 -0400 (EDT) Received: from thumper.research.telcordia.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: thumper.research.telcordia.com [128.96.41.1]) id QQiyjt21404 for ; Tue, 18 Jul 2000 15:16:17 GMT Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6IFG2R12822; Tue, 18 Jul 2000 11:16:02 -0400 (EDT) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id LAA01097; Tue, 18 Jul 2000 11:16:01 -0400 (EDT) Message-Id: <200007181516.LAA01097@monday.research.telcordia.com> Date: Tue, 18 Jul 2000 11:16:01 -0400 (EDT) From: Ritu Chadha Reply-To: Ritu Chadha Subject: Re: Policy Information Model for MPLS Traffic Engineering To: policy@raleigh.ibm.com, mpls@UU.NET, tnadeau@cisco.com Cc: chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@research.telcordia.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XCJxrzhEvv1gau5jpMZvGw== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk Tom, > Hi, > >>The definition of such policy information models is the >>whole raison d'etre of the Policy Framework WG. The following >>snippet from "Requirements for a Policy Management System", >>draft-ietf-policy-req-01.txt, >>summarizes the need for a standardized common information model: > > I thought that the purpose of the MPLS WG was to define >protocols (and MIBs to manage them) not policy, but I may be >mistaken here. ;) I can understand holding topological information >or such network-wide things, but the inclusion of other information >into this standard object model seems redundant, doesn't it? >Isn't this why we have the MIBs and PIBs? That is, to define >what is manageable, and how some of those managed objects are >provisioned via a defined policy? Why should we spend time >defining an object model which has basically already been >defined for MPLS? > > --Tom You may be right about this work not belonging to the MPLS WG. It may fit more naturally into the Policy WG. However, I thought it was appropriate to cross-post to both mailing lists because (a) we need to get feedback from the MPLS WG since that's where the subject matter experts are; and (b) there was a discussion about policy at the MPLS meeting in Adelaide where people agreed that MPLS policy work was of interest to this WG (this was during S. Wright's presentation of draft-wright-policy-mpls-00.txt). George Swallow stated that policy and MPLS are two things that have a lot in common and therefore was worth working on. The consensus in the WG seemed to be that contributions in this area should be brought to the MPLS WG. Ritu From owner-mpls@UU.NET Tue Jul 18 11:24: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 LAA18406 for ; Tue, 18 Jul 2000 11:24:56 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyjt27846; Tue, 18 Jul 2000 15:24:29 GMT Received: by mail-control.mail.uu.net id QQiyjt28004 for mpls-outgoing; Tue, 18 Jul 2000 15:23: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 QQiyjt27997 for ; Tue, 18 Jul 2000 15:23: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 QQiyjt23863 for ; Tue, 18 Jul 2000 11:23:15 -0400 (EDT) Received: from brmnj-fw by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [63.89.157.2]) id QQiyjt15597 for ; Tue, 18 Jul 2000 15:23:09 GMT Received: by BMAILNJ with Internet Mail Service (5.5.2650.21) id <3VY46JNS>; Tue, 18 Jul 2000 11:16:00 -0400 Message-ID: <6399122981E1D211AB490090271E0AA38B1DEF@BMAILNJ> From: "Francis Reichmeyer (IPHighway MA)" To: "'Thomas D. Nadeau '" , "'Ritu Chadha '" , "'policy@raleigh.ibm.com '" , "'mpls@UU.NET '" Cc: "'chadha@research.telcordia.com '" , "'hlin1@telcordia.com '" , "'mykoniat@research.telcordia.com '" Subject: RE: Policy Information Model for MPLS Traffic Engineering Date: Tue, 18 Jul 2000 11:15:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Tom, > I thought that the purpose of the MPLS WG was to define >protocols (and MIBs to manage them) not policy, but I may be >mistaken here. ;) From the Adelaide meeting minutes (regarding the presentation made on 'Requirements for Policy Enabled MPLS'): "... Moreover, George Swallow stated that policy and MPLS are two things that have very much in common and much to do with each other, so it is worth working on." I'm not sure that means policy is actually part of the purpose of the WG ;^) but it's worth considering. On a related note, we've submitted a draft on COPS usage for MPLS/TE that should be showing up on the repository any day now (submitted on Friday). It should come out as draft-franr-mpls-cops-00.txt. Looking forward to discussing it, PIBs and maybe even information models, in Pittsburgh. Thanks, -Fran From owner-mpls@UU.NET Tue Jul 18 12:09: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 MAA07401 for ; Tue, 18 Jul 2000 12:09:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyjw10249; Tue, 18 Jul 2000 16:09:07 GMT Received: by mail-control.mail.uu.net id QQiyjw08331 for mpls-outgoing; Tue, 18 Jul 2000 16:08: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 QQiyjw08096 for ; Tue, 18 Jul 2000 16:08:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyjw01875 for ; Tue, 18 Jul 2000 12:07:50 -0400 (EDT) Received: from blsmsgims03.bls.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: iocfirewall2ext.bls.com [139.76.64.4]) id QQiyjw09316 for ; Tue, 18 Jul 2000 16:07:49 GMT Received: from SMTP (blsmsgims03.bls.com [139.76.86.35]) by blsmsgims03.bls.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id PFLH3798; Tue, 18 Jul 2000 12:08:04 -0400 Received: from snt.bellsouth.com ([90.30.215.1]) by 139.76.86.35 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 18 Jul 2000 16:08:04 0000 (GMT) Received: from gf5142_gxsmlg (g0214070 [90.30.214.70]) by snt.bellsouth.com (8.9.1b+Sun/8.9.1) with SMTP id MAA27850; Tue, 18 Jul 2000 12:07:37 -0400 (EDT) From: "Steven Wright" To: "'Ritu Chadha'" , , , Cc: , , Subject: RE: Policy Information Model for MPLS Traffic Engineering Date: Tue, 18 Jul 2000 12:07:34 -0400 Message-ID: <001001bff0d2$49363170$46d61e5a@gf5142_gxsmlg.bst.bls.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200007181516.LAA01097@monday.research.telcordia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sending the information model to both groups seems the right thing to do for now, as both groups need some understanding of the progress of the work. I look forward to some interesting discussions in Pittsburgh on the appropriate scope of mpls working group documents related to the mpls policy topic. my 2c opinion - anything mpls specific belongs in the mpls wg, anything policy generic belongs in the policy wg. crosspost the stuff in the middle until we get some stable (RFC) documents to reference. regards Steven Wright > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Ritu > Chadha > Sent: Tuesday, July 18, 2000 11:16 AM > To: policy@raleigh.ibm.com; mpls@UU.NET; tnadeau@cisco.com > Cc: chadha@research.telcordia.com; hlin1@telcordia.com; > mykoniat@research.telcordia.com > Subject: Re: Policy Information Model for MPLS Traffic Engineering > > > Tom, > > > Hi, > > > >>The definition of such policy information models is the > >>whole raison d'etre of the Policy Framework WG. The following > >>snippet from "Requirements for a Policy Management System", > >>draft-ietf-policy-req-01.txt, > >>summarizes the need for a standardized common information model: > > > > I thought that the purpose of the MPLS WG was to define > >protocols (and MIBs to manage them) not policy, but I may be > >mistaken here. ;) I can understand holding topological information > >or such network-wide things, but the inclusion of other information > >into this standard object model seems redundant, doesn't it? > >Isn't this why we have the MIBs and PIBs? That is, to define > >what is manageable, and how some of those managed objects are > >provisioned via a defined policy? Why should we spend time > >defining an object model which has basically already been > >defined for MPLS? > > > > --Tom > > You may be right about this work not belonging to the MPLS WG. > It may fit more naturally into the Policy WG. However, I thought > it was appropriate to cross-post to both mailing lists because > (a) we need to get feedback from the MPLS WG since that's where the > subject matter experts are; and (b) there was a discussion about > policy at the MPLS meeting in Adelaide where people agreed that > MPLS policy work was of interest to this WG (this was during > S. Wright's presentation of draft-wright-policy-mpls-00.txt). > George Swallow stated that policy and MPLS are two things > that have a lot in common and therefore was worth working on. > The consensus in the WG seemed to be that contributions in > this area should be brought to the MPLS WG. > > Ritu > > > From owner-mpls@UU.NET Tue Jul 18 12:26: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 MAA15356 for ; Tue, 18 Jul 2000 12:26:52 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyjx19368; Tue, 18 Jul 2000 16:26:27 GMT Received: by mail-control.mail.uu.net id QQiyjx14093 for mpls-outgoing; Tue, 18 Jul 2000 16:26: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 QQiyjx14059 for ; Tue, 18 Jul 2000 16:26: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 QQiyjx04725 for ; Tue, 18 Jul 2000 12:25:36 -0400 (EDT) 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 QQiyjx12718 for ; Tue, 18 Jul 2000 16:25:35 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA01111 for mpls@uu.net; Tue, 18 Jul 2000 12:25:35 -0400 (EDT) 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 QQiyjx13973 for ; Tue, 18 Jul 2000 16:25:13 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyjx04647 for ; Tue, 18 Jul 2000 12:24:58 -0400 (EDT) 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 QQiyjx12232 for ; Tue, 18 Jul 2000 16:24:57 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 MAA00976; Tue, 18 Jul 2000 12:24:38 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA25662; Tue, 18 Jul 2000 12:24:38 -0400 (EDT) Message-Id: <200007181624.MAA25662@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Ritu Chadha cc: policy@raleigh.ibm.com, mpls@UU.NET, tnadeau@cisco.com, chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@research.telcordia.com, swallow@cisco.com Subject: Re: Policy Information Model for MPLS Traffic Engineering In-reply-to: Your message of "Tue, 18 Jul 2000 11:16:01 EDT." <200007181516.LAA01097@monday.research.telcordia.com> Date: Tue, 18 Jul 2000 12:24:37 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Ritu - > George Swallow stated that policy and MPLS are two things > that have a lot in common and therefore was worth working on. There's a problem with sound bites. I also said that I didn't think the work belonged in MPLS. > The consensus in the WG seemed to be that contributions in > this area should be brought to the MPLS WG. I didn't agree with this consensus because the request was too general and thus overlaps with other work groups. Though our revised charter is still being worked out with the IESG, there will be no general policy item in it. If specific items are needed in RSVP, LDP and CR-LDP to glue things together, these are appropriate. Given that the MPLS agenda is tight, I would like both draft-chadha-policy-mpls-te-00.txt draft-isoyama-policy-mpls-info-model-00.txt present only in the policy wg. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Jul 18 12: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 MAA22961 for ; Tue, 18 Jul 2000 12:42:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyjy27115; Tue, 18 Jul 2000 16:42:21 GMT Received: by mail-control.mail.uu.net id QQiyjy15005 for mpls-outgoing; Tue, 18 Jul 2000 16:41:49 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiyjy15000 for ; Tue, 18 Jul 2000 16:41:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyjy20380 for ; Tue, 18 Jul 2000 12:41:03 -0400 (EDT) Received: from exchange.sd.osicom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [131.143.32.20]) id QQiyjy25898 for ; Tue, 18 Jul 2000 16:40:46 GMT Received: by EXCHANGE-SD with Internet Mail Service (5.5.2650.21) id <36ABHZ0L>; Tue, 18 Jul 2000 09:39:50 -0700 Message-ID: From: "Fu, James" To: mpls@UU.NET Subject: A new draft. Date: Tue, 18 Jul 2000 09:38:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF0D6.CA14DEA0" 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_01BFF0D6.CA14DEA0 Content-Type: text/plain; charset="iso-8859-1" An Internet Draft entitled "Extensions to RSVP-TE for Bi-directional Optical Path Setup" has been submitted to the IETF. http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt James Fu Sorrento Networks Inc. 9990 Mesa Rim Road San Diego, CA 92121 jfu@sorrentonet.com ------_=_NextPart_001_01BFF0D6.CA14DEA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A new draft.

An Internet Draft entitled = "Extensions to RSVP-TE for = Bi-directional Optical Path Setup" has been submitted to the IETF.

http://www.ietf.org/internet-drafts/draft-sorrento-rsv= p-bi-osp-00.txt


James Fu
Sorrento Networks Inc.
9990 Mesa Rim Road
San Diego, CA  92121

jfu@sorrentonet.com

------_=_NextPart_001_01BFF0D6.CA14DEA0-- From owner-mpls@UU.NET Tue Jul 18 12:54: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 MAA28021 for ; Tue, 18 Jul 2000 12:54:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyjz01527; Tue, 18 Jul 2000 16:53:53 GMT Received: by mail-control.mail.uu.net id QQiyjz16592 for mpls-outgoing; Tue, 18 Jul 2000 16:53: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 QQiyjz16585 for ; Tue, 18 Jul 2000 16:53: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 QQiyjz22354 for ; Tue, 18 Jul 2000 12:52:40 -0400 (EDT) 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 QQiyjz06178 for ; Tue, 18 Jul 2000 16:52:39 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA05966 for mpls@uu.net; Tue, 18 Jul 2000 12:52:39 -0400 (EDT) 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 QQiyjz16385 for ; Tue, 18 Jul 2000 16:52: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 QQiyjz09246 for ; Tue, 18 Jul 2000 12:51:40 -0400 (EDT) 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 QQiyjz05226 for ; Tue, 18 Jul 2000 16:51:24 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 MAA01223; Tue, 18 Jul 2000 12:50:53 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA10416; Tue, 18 Jul 2000 12:50:52 -0400 (EDT) Message-Id: <200007181650.MAA10416@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: "Fu, James" cc: mpls@UU.NET, internet-drafts@ietf.org Subject: Re: draft-sorrento-rsvp-bi-osp-00.txt In-reply-to: Your message of "Tue, 18 Jul 2000 09:38:56 PDT." Date: Tue, 18 Jul 2000 12:50:52 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk James - Using a company name in the title of a draft is inappropriate. The ID editor usually catches these, but this one slipped by since your company name could also be a last name. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Jul 18 13:53: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 NAA21496 for ; Tue, 18 Jul 2000 13:53:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiykd23296; Tue, 18 Jul 2000 17:52:28 GMT Received: by mail-control.mail.uu.net id QQiykd04601 for mpls-outgoing; Tue, 18 Jul 2000 17:51: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 QQiykd04585 for ; Tue, 18 Jul 2000 17:51: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 QQiykd00880 for ; Tue, 18 Jul 2000 13:50:45 -0400 (EDT) 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 QQiykd21663 for ; Tue, 18 Jul 2000 17:50:26 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA15432 for mpls@uu.net; Tue, 18 Jul 2000 13:50:25 -0400 (EDT) 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 QQiykd04482 for ; Tue, 18 Jul 2000 17:49:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiykd17620 for ; Tue, 18 Jul 2000 13:48:11 -0400 (EDT) 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 QQiykd19856 for ; Tue, 18 Jul 2000 17:47:56 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA08889; Tue, 18 Jul 2000 13:47:07 -0400 (EDT) Received: from tnadeau-pc02.cisco.com (ch2-dhcp134-185.cisco.com [161.44.134.185]) by bucket.cisco.com (Mirapoint) with ESMTP id AAB03104; Tue, 18 Jul 2000 13:52:31 -0400 (EDT) Message-Id: <4.3.2.7.2.20000718132846.04ca00a0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jul 2000 13:31:42 -0400 To: George Swallow , Ritu Chadha From: "Thomas D. Nadeau" Subject: Re: Policy Information Model for MPLS Traffic Engineering Cc: policy@raleigh.ibm.com, mpls@UU.NET, chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@research.telcordia.com, Walter Weiss In-Reply-To: <200007181624.MAA25662@lir.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, I just want to add my 2 cents here. First, I agree as I have all along, that this stuff does not belong in the MPLS WG. Second, there is a BOF in Pittsburgh which is designed specifically to coordinate the specification of object models (for policy or otherwise). The BOF is called Network Information Modeling (NIM). You can join the discussion list by sending email to nim-req@ops.ietf.org I believe that Walter Weiss is coordinating the BOF. --Tom > > George Swallow stated that policy and MPLS are two things > > that have a lot in common and therefore was worth working on. > >There's a problem with sound bites. I also said that I didn't think >the work belonged in MPLS. > > > The consensus in the WG seemed to be that contributions in > > this area should be brought to the MPLS WG. > >I didn't agree with this consensus because the request was too general >and thus overlaps with other work groups. Though our revised charter >is still being worked out with the IESG, there will be no general >policy item in it. If specific items are needed in RSVP, LDP and >CR-LDP to glue things together, these are appropriate. > >Given that the MPLS agenda is tight, I would like both > > draft-chadha-policy-mpls-te-00.txt > draft-isoyama-policy-mpls-info-model-00.txt > >present only in the policy wg. > >...George > > >================================================================== >George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Jul 18 14:26: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 OAA02136 for ; Tue, 18 Jul 2000 14:26:00 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiykf14902; Tue, 18 Jul 2000 18:25:25 GMT Received: by mail-control.mail.uu.net id QQiykf20066 for mpls-outgoing; Tue, 18 Jul 2000 18:24:45 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiykf20049 for ; Tue, 18 Jul 2000 18:24: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 QQiykf23533 for ; Tue, 18 Jul 2000 14:16:22 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQiykf15515 for ; Tue, 18 Jul 2000 18:16:03 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA21550 for ; Tue, 18 Jul 2000 11:16:17 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA15379 for mpls@uu.net; Tue, 18 Jul 2000 14:16:01 -0400 (EDT) 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 QQiykc03147 for ; Tue, 18 Jul 2000 17:39: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 QQiykc15699 for ; Tue, 18 Jul 2000 13:36:06 -0400 (EDT) Received: from ctron-dnm.ctron.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ctron-dnm.cabletron.com [12.25.1.120]) id QQiykc10512 for ; Tue, 18 Jul 2000 17:35:50 GMT Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id NAA09306; Tue, 18 Jul 2000 13:36:53 -0400 (EDT) Received: from olympus.ctron.com(134.141.72.253) by ctron-dnm.ctron.com via smap (4.1) id xma009279; Tue, 18 Jul 00 13:36:00 -0400 Received: from enterasys.com ([134.141.150.27]) by olympus.ctron.com (8.8.7/8.8.7) with ESMTP id NAA16629; Tue, 18 Jul 2000 13:31:20 -0400 (EDT) Message-ID: <39749435.ADDE240@enterasys.com> Date: Tue, 18 Jul 2000 13:30:29 -0400 From: David Harrington Organization: Enterasys Networks X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ritu Chadha CC: policy@raleigh.ibm.com, mpls@UU.NET, tnadeau@cisco.com, chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@research.telcordia.com Subject: Re: Policy Information Model for MPLS Traffic Engineering References: <200007181516.LAA01097@monday.research.telcordia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, If you can compare the creation of Policy information models to the creation of SNMP MIBs, the IESG decided a while ago that the technology-specific working groups should produce the corresponding SNMP MIB, preferably with some advice from MIB experts from the O&M area. I think it would make sense that policy information models be handled the same way - created by the content-providers with assistance from the modeling experts. dbh Ritu Chadha wrote: > > Tom, > > > Hi, > > > >>The definition of such policy information models is the > >>whole raison d'etre of the Policy Framework WG. The following > >>snippet from "Requirements for a Policy Management System", > >>draft-ietf-policy-req-01.txt, > >>summarizes the need for a standardized common information model: > > > > I thought that the purpose of the MPLS WG was to define > >protocols (and MIBs to manage them) not policy, but I may be > >mistaken here. ;) I can understand holding topological information > >or such network-wide things, but the inclusion of other information > >into this standard object model seems redundant, doesn't it? > >Isn't this why we have the MIBs and PIBs? That is, to define > >what is manageable, and how some of those managed objects are > >provisioned via a defined policy? Why should we spend time > >defining an object model which has basically already been > >defined for MPLS? > > > > --Tom > > You may be right about this work not belonging to the MPLS WG. > It may fit more naturally into the Policy WG. However, I thought > it was appropriate to cross-post to both mailing lists because > (a) we need to get feedback from the MPLS WG since that's where the > subject matter experts are; and (b) there was a discussion about > policy at the MPLS meeting in Adelaide where people agreed that > MPLS policy work was of interest to this WG (this was during > S. Wright's presentation of draft-wright-policy-mpls-00.txt). > George Swallow stated that policy and MPLS are two things > that have a lot in common and therefore was worth working on. > The consensus in the WG seemed to be that contributions in > this area should be brought to the MPLS WG. > > Ritu -- --- David Harrington Network Management Architect Engineer dbh@enterasys.com Office of the CTO +1 603 337 2614 - voice Enterasys Networks +1 603 332 1524 - fax Rochester NH, USA From owner-mpls@UU.NET Tue Jul 18 15:57: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 PAA16923 for ; Tue, 18 Jul 2000 15:57:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiykl19585; Tue, 18 Jul 2000 19:56:33 GMT Received: by mail-control.mail.uu.net id QQiykl08952 for mpls-outgoing; Tue, 18 Jul 2000 19:55:58 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiykl08947 for ; Tue, 18 Jul 2000 19:55: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 QQiykl15049 for ; Tue, 18 Jul 2000 15:55:36 -0400 (EDT) Received: from rmx306-mta.mail.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: rmx306-mta.mail.com [165.251.48.168]) id QQiykl18370 for ; Tue, 18 Jul 2000 19:55:06 GMT Received: from web576-ec.mail.com (web576-ec.mail.com [165.251.32.76]) by rmx306-mta.mail.com (8.9.3/8.9.3) with SMTP id PAA07564; Tue, 18 Jul 2000 15:55:02 -0400 (EDT) Message-ID: <381232507.963950102156.JavaMail.root@web576-ec.mail.com> Date: Tue, 18 Jul 2000 15:55:01 -0400 (EDT) From: Namita Sinha To: George Swallow Subject: Re: Policy Information Model for MPLS Traffic Engineering CC: mpls@UU.NET, policy@raleigh.ibm.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: mail.com X-Originating-IP: 192.4.8.132 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Is there going to at least be some discussion of this issue at the mpls wg meeting in Pittsburgh? I'm just concerned that if this work disappears into the policy wg, we (i.e. the mpls wg) will not be actively influencing this work and surely we need to buy in to any information model for MPLS TE. Thanks Namita ------Original Message------ From: George Swallow To: Ritu Chadha Sent: July 18, 2000 4:24:37 PM GMT Subject: Re: Policy Information Model for MPLS Traffic Engineering Ritu - > George Swallow stated that policy and MPLS are two things > that have a lot in common and therefore was worth working on. There's a problem with sound bites. I also said that I didn't think the work belonged in MPLS. > The consensus in the WG seemed to be that contributions in > this area should be brought to the MPLS WG. I didn't agree with this consensus because the request was too general and thus overlaps with other work groups. Though our revised charter is still being worked out with the IESG, there will be no general policy item in it. If specific items are needed in RSVP, LDP and CR-LDP to glue things together, these are appropriate. Given that the MPLS agenda is tight, I would like both draft-chadha-policy-mpls-te-00.txt draft-isoyama-policy-mpls-info-model-00.txt present only in the policy wg. ....George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 ----------------------------------------------- FREE! The World's Best Email Address @email.com Reserve your name now at http://www.email.com From owner-mpls@UU.NET Tue Jul 18 16:32: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 QAA04609 for ; Tue, 18 Jul 2000 16:32:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyko20661; Tue, 18 Jul 2000 20:31:58 GMT Received: by mail-control.mail.uu.net id QQiyko22442 for mpls-outgoing; Tue, 18 Jul 2000 20:31: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 QQiyko22433 for ; Tue, 18 Jul 2000 20:31: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 QQiyko21476 for ; Tue, 18 Jul 2000 16:30:48 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyko14680 for ; Tue, 18 Jul 2000 20:30:18 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA12203 for mpls@uu.net; Tue, 18 Jul 2000 16:30:17 -0400 (EDT) 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 QQiykn22375 for ; Tue, 18 Jul 2000 20:29: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 QQiykn06689 for ; Tue, 18 Jul 2000 16:29:36 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiykn14232 for ; Tue, 18 Jul 2000 20:29:36 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 QAA12006; Tue, 18 Jul 2000 16:29:03 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA05293; Tue, 18 Jul 2000 16:29:02 -0400 (EDT) Message-Id: <200007182029.QAA05293@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Namita Sinha cc: George Swallow , mpls@UU.NET, policy@raleigh.ibm.com, swallow@cisco.com Subject: Re: Policy Information Model for MPLS Traffic Engineering In-reply-to: Your message of "Tue, 18 Jul 2000 15:55:01 EDT." <381232507.963950102156.JavaMail.root@web576-ec.mail.com> Date: Tue, 18 Jul 2000 16:29:02 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > Is there going to at least be some discussion of this > issue at the mpls wg meeting in Pittsburgh? > > I'm just concerned that if this work disappears into > the policy wg, we (i.e. the mpls wg) will not be > actively influencing this work and surely we need to > buy in to any information model for MPLS TE. > > Thanks > Namita If you're looking for a more focused group on this, I would suggest starting with the TE WG. Seems to me the requirements for policy should be driven from the application side, not the base technology. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Jul 18 20:56: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 UAA16601 for ; Tue, 18 Jul 2000 20:56:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiylf03144; Wed, 19 Jul 2000 00:56:31 GMT Received: by mail-control.mail.uu.net id QQiylf29876 for mpls-outgoing; Wed, 19 Jul 2000 00:56: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 QQiylf29866 for ; Wed, 19 Jul 2000 00:56: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 QQiylf27661 for ; Tue, 18 Jul 2000 20:56:00 -0400 (EDT) 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 QQiylf26203 for ; Wed, 19 Jul 2000 00:56:00 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA09139 for mpls@uu.net; Tue, 18 Jul 2000 20:55:59 -0400 (EDT) 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 QQiylf29816 for ; Wed, 19 Jul 2000 00:55: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 QQiylf27633 for ; Tue, 18 Jul 2000 20:55:24 -0400 (EDT) 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 QQiylf02574 for ; Wed, 19 Jul 2000 00:55:24 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA26174 for ; Tue, 18 Jul 2000 20:55:24 -0400 (EDT) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAB04872; Tue, 18 Jul 2000 21:00:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20000718205147.053d3f00@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jul 2000 20:52:52 -0400 To: mpls@UU.NET From: "Thomas D. Nadeau" Subject: subscribing to NIM mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi all, I must apologize because in a previous email I presented the incorrect email address to subscribe to the NIM mailing list. Here is the correct address: nim-request@ops.ietf.org You can also use: majordomo@psg.com however, then you need to subscribe to the list explicitly: subscribe NIM From owner-mpls@UU.NET Tue Jul 18 21:05: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 VAA19272 for ; Tue, 18 Jul 2000 21:05:22 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiylg07953; Wed, 19 Jul 2000 01:05:00 GMT Received: by mail-control.mail.uu.net id QQiylg11273 for mpls-outgoing; Wed, 19 Jul 2000 01:04: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 QQiylg11220 for ; Wed, 19 Jul 2000 01:03:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiylg15240 for ; Tue, 18 Jul 2000 21:03:54 -0400 (EDT) Received: from lux.chromisys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged)) id QQiylg00860 for ; Wed, 19 Jul 2000 01:03:53 GMT Received: by LUX with Internet Mail Service (5.5.2448.0) id ; Tue, 18 Jul 2000 18:03:53 -0700 Message-ID: <51DA0AB3D747D311832F005004827CC02CE83E@LUX> From: Jonathan Lang To: "'Fu, James'" , mpls@UU.NET Cc: Jonathan Lang Subject: RE: A new draft. Date: Tue, 18 Jul 2000 18:03:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF11D.346D1876" 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_01BFF11D.346D1876 Content-Type: text/plain; charset="iso-8859-1" James, I read your draft and I'm afraid you have misunderstood the bi-directional approach of draft-lang-mpls-rsvp-oxc-00.txt (updated and included in draft-generalized-signaling-mpls-00.txt). The process of establishing a bi-directional LSP is the same as the establishment of a unidirectional LSP with the exception that an Upstream Label is added to the Path message. (Incidentally, the flow of the Upstream Label is the same as the normal flow of a Label would be for the upstream segment of a bi-directional LSP, except that we have short-circuited sending the Path message upstream -- see example below). Contention may occur for the following reasons: 1) If there is a requirement that the input/output ports for the bi-directional path be tied together (e.g., if they must be on the same physical I/O card). Since these are assigned by different OXCs, contention may occur. The scheme that you have proposed will also have this contention scenario. 2) If two bi-directional LSPs are attempted to be established simultaneously in opposite directions and there are only enough resources for one of the bi-directional LSPs. In this case, one of the LSPs cannot be established along that path. The scheme that you propose avoids this contention, I assume, by resource checking on the Path message and sending a PathError message to the losing LSP. This is also how it is done in draft-lang-mpls-rsvp-oxc-00.txt. On another note, I think overloading the ResvError message for label allocation is a bad idea. Regards, Jonathan Example: downstream -----> upstream <----- (1) RSVP-TE used to establish a bi-directional LSP: +-+-+ Path(Label Request) +-+-+ Path(Label Request) +-+-+ Path(LabelRequest) | | ---------------------------> | | ---------------------------> | | ---------------------------> + + Resv(Label) + + Resv(Label) + + Resv(Label) | | <--------------- | | <--------------- | | <---------------- + A + + B + + C + | | Path(Label Request) | | Path(Label Request) | | Path(LabelRequest) + + <--------------------------- + + <-------------------------- + + <------------------------ | | Resv(Label) | | Resv(Label) | | Resv(Label) +-+-+ --------------------------> +-+-+ --------------------------> +-+-+ ------------------------> (2) bi-directional LSP using draft-lang-mpls-rsvp-oxc.txt +-+-+ Path(Label Request, +-+-+ Path(Label Request) +-+-+ Path(LabelRequest) | | UpstreamLabel) | | UpstreamLabel) | | UpstreamLabel) + + ---------------------------> + + ---------------------------> + + ---------------------------> | | | | | | + A + + B + + C + | | Resv(Label) | | Resv(Label) | | Resv(Label) + + <--------------------------- + + <-------------------------- + + <------------------------ | | | | | | +-+-+ +-+-+ +-+-+ -----Original Message----- From: Fu, James [mailto:jfu@sorrentonet.com] Sent: Tuesday, July 18, 2000 9:39 AM To: mpls@UU.NET Subject: A new draft. An Internet Draft entitled "Extensions to RSVP-TE for Bi-directional Optical Path Setup" has been submitted to the IETF. http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt James Fu Sorrento Networks Inc. 9990 Mesa Rim Road San Diego, CA 92121 jfu@sorrentonet.com ------_=_NextPart_001_01BFF11D.346D1876 Content-Type: text/html; charset="iso-8859-1" A new draft.
James,
  I read your draft and I'm afraid you have misunderstood the bi-directional approach of draft-lang-mpls-rsvp-oxc-00.txt (updated and included in draft-generalized-signaling-mpls-00.txt).   The process of establishing a bi-directional LSP is the same as the establishment of a unidirectional LSP with the exception that an Upstream Label is added to the Path message.  (Incidentally, the flow of the Upstream Label is the same as the normal flow of a Label would be for the upstream segment of a bi-directional LSP, except that we have short-circuited sending the Path message upstream -- see example below).

Contention may occur for the following reasons:
1)  If there is a requirement that the input/output ports for the bi-directional path be tied together (e.g., if they must be on the same physical I/O card).  Since these are assigned by different OXCs, contention may occur.  The scheme that you have proposed will also have this contention scenario.
2)  If two bi-directional LSPs are attempted to be established simultaneously in opposite directions and there are only enough resources for one of the bi-directional LSPs.  In this case, one of the LSPs cannot be established along that path.  The scheme that you propose avoids this contention, I assume, by resource checking on the Path message and sending a PathError message to the losing LSP.  This is also how it is done in draft-lang-mpls-rsvp-oxc-00.txt.

On another note, I think overloading the ResvError message for label allocation is a bad idea.
 
Regards,
Jonathan
 
Example:
 
downstream ----->
upstream    <-----
 
(1)  RSVP-TE used to establish a bi-directional LSP:
 
+-+-+  Path(Label Request) +-+-+  Path(Label Request) +-+-+   Path(LabelRequest)
 |     |  --------------------------->  |     |   --------------------------->  |     |     --------------------------->
+    +  Resv(Label)              +    +   Resv(Label)             +    +   Resv(Label)
 |     |  <---------------               |     |  <---------------               |     |  <----------------           
+ A +                                 + B +                                + C + 
 |     |  Path(Label Request)   |     |  Path(Label Request)  |     |   Path(LabelRequest)
+    +  <---------------------------  +    +  <--------------------------  +    +  <------------------------
 |     |  Resv(Label)                |     |     Resv(Label)            |     |      Resv(Label)
+-+-+  -------------------------->   +-+-+    --------------------------> +-+-+  ------------------------>
 
(2)  bi-directional LSP using draft-lang-mpls-rsvp-oxc.txt
 
+-+-+  Path(Label Request, +-+-+  Path(Label Request) +-+-+   Path(LabelRequest)
 |     |         UpstreamLabel)  |     |        UpstreamLabel)   |     |            UpstreamLabel) 
+    +  --------------------------->  +    +  ---------------------------> +    +  ---------------------------> 
 |     |                                  |     |                                  |     |  
+ A +                                 + B +                                + C + 
 |     |  Resv(Label)               |     |  Resv(Label)                |     |   Resv(Label)               
+    +  <---------------------------  +    +  <--------------------------  +    +  <------------------------
 |     |                                  |     |                                  |     |      
+-+-+                                 +-+-+                                +-+-+  
 
-----Original Message-----
From: Fu, James [mailto:jfu@sorrentonet.com]
Sent: Tuesday, July 18, 2000 9:39 AM
To: mpls@UU.NET
Subject: A new draft.

An Internet Draft entitled "Extensions to RSVP-TE for Bi-directional Optical Path Setup" has been submitted to the IETF.

http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt


James Fu
Sorrento Networks Inc.
9990 Mesa Rim Road
San Diego, CA  92121

jfu@sorrentonet.com

------_=_NextPart_001_01BFF11D.346D1876-- From owner-mpls@UU.NET Tue Jul 18 21:12: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 VAA21375 for ; Tue, 18 Jul 2000 21:12:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiylf21335; Wed, 19 Jul 2000 00:47:15 GMT Received: by mail-control.mail.uu.net id QQiylf29098 for mpls-outgoing; Wed, 19 Jul 2000 00:46: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 QQiylf29085 for ; Wed, 19 Jul 2000 00:46: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 QQiylf13293 for ; Tue, 18 Jul 2000 20:46:33 -0400 (EDT) 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 QQiylf20662 for ; Wed, 19 Jul 2000 00:46:18 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA08063 for mpls@uu.net; Tue, 18 Jul 2000 20:46:17 -0400 (EDT) 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 QQiylf28922 for ; Wed, 19 Jul 2000 00:45: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 QQiylf26608 for ; Tue, 18 Jul 2000 20:45:37 -0400 (EDT) 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 QQiylf20224 for ; Wed, 19 Jul 2000 00:45:37 GMT Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id RAA28739; Tue, 18 Jul 2000 17:45:09 -0700 (PDT) Message-ID: <3974FAE2.4DCA07AF@cisco.com> Date: Tue, 18 Jul 2000 17:48:34 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jen Battle CC: mpls@UU.NET Subject: Re: IGPs for MPLS References: <11A8C5C44A7BD211A7A40000D11BB1B2029618ED@mbsp06.sp.TRW.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jen, Non of the today's IGPs has been changed for MPLS even a bit. The only changes which were done to link state IGPs were to extend OSPF & ISIS to transport the traffic engineering related information for MPLS-TE application. If you are using other MPLS application then traffic eng. you can use any IGP you like: link state or distance vector as the prefix based labels are disctributed by LDP. R. > Jen Battle wrote: > > Hi, > > I am trying to figure out how the IGPs (IS-IS and OSPF) have been changed for MPLS. I assume there have been extensions for these standards to make them more MPLS friendly but I am unable to find any documentation. > > The IGPs seem to have a flat hierarchy which is contrary to the edge/core mentality of MPLS. Has this been altered for MPLS? How are these protocols actually run over MPLS networks? > > Thanks, > Jen > jen.battle@trw.com From owner-mpls@UU.NET Tue Jul 18 22:02: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 WAA07458 for ; Tue, 18 Jul 2000 22:02:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiylk00506; Wed, 19 Jul 2000 02:01:44 GMT Received: by mail-control.mail.uu.net id QQiylk21667 for mpls-outgoing; Wed, 19 Jul 2000 02:01: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 QQiylk21358 for ; Wed, 19 Jul 2000 02:01: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 QQiylk05803 for ; Tue, 18 Jul 2000 22:00:59 -0400 (EDT) Received: from postoffice.opticworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.170.20.5]) id QQiylk29916 for ; Wed, 19 Jul 2000 02:00:29 GMT Received: by POSTOFFICE with Internet Mail Service (5.5.2650.21) id <37K9KDWX>; Tue, 18 Jul 2000 18:57:45 -0700 Message-ID: <5325CE3D64E3D31184B1009027DDD26F010C9085@caems1.opticworks.com> From: Anil Rao To: "'mpls@uu.net'" Subject: Link Id in LMP Date: Tue, 18 Jul 2000 19:00:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Is there a way that we could exchange the Link Ids on the component link using a mechanism other than obtaining by interpreting the information in the component link (as a part of the Test message)? I am not sure if this is possible in all-optical switches where we do not read the message sent out on the component link. -anil. ____________________________________________________________________________ ___ Anil R. Rao ONI Systems, 166 Baypointe Pkwy, San Jose, CA 95134. (408)571-3124 From owner-mpls@UU.NET Tue Jul 18 22:28: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 WAA13208 for ; Tue, 18 Jul 2000 22:28:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiylb06612; Tue, 18 Jul 2000 23:47:33 GMT Received: by mail-control.mail.uu.net id QQiylb12224 for mpls-outgoing; Tue, 18 Jul 2000 23:47: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 QQiylb12219 for ; Tue, 18 Jul 2000 23:47:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiylb06433 for ; Tue, 18 Jul 2000 19:46:59 -0400 (EDT) Received: from mailhub1.trw.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailhub1.TRW.COM [129.193.4.4]) id QQiylb12210 for ; Tue, 18 Jul 2000 23:46:43 GMT Received: from navieg3.TRW.COM by mailhub1.trw.com for mpls@UU.NET; Tue, 18 Jul 2000 16:46:36 -0700 Received: (from SMTP [129.193.4.9]) by navieg3.TRW.COM (NAVIEG 2.1 bld 54) with SMTP id M2000071816463514312 for ; Tue, 18 Jul 2000 16:46:35 -0700 Received: from imssp01.sp.trw.com ([129.4.53.55]) by navieg1.trw.com (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 18 Jul 2000 23:46:35 0000 (GMT) Received: by imssp01.sp.TRW.COM with Internet Mail Service (5.5.2650.21) id <3ZJL2GCM>; Tue, 18 Jul 2000 16:46:33 -0700 Message-Id: <11A8C5C44A7BD211A7A40000D11BB1B2029618ED@mbsp06.sp.TRW.COM> From: Jen Battle To: mpls@UU.NET Subject: IGPs for MPLS Date: Tue, 18 Jul 2000 16:46:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I am trying to figure out how the IGPs (IS-IS and OSPF) have been changed for MPLS. I assume there have been extensions for these standards to make them more MPLS friendly but I am unable to find any documentation. The IGPs seem to have a flat hierarchy which is contrary to the edge/core mentality of MPLS. Has this been altered for MPLS? How are these protocols actually run over MPLS networks? Thanks, Jen jen.battle@trw.com From owner-mpls@UU.NET Wed Jul 19 04:16: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 EAA03822 for ; Wed, 19 Jul 2000 04:16:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiymj28261; Wed, 19 Jul 2000 08:15:42 GMT Received: by mail-control.mail.uu.net id QQiymj14685 for mpls-outgoing; Wed, 19 Jul 2000 08:15: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 QQiymj14533 for ; Wed, 19 Jul 2000 08:15: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 QQiymi06048 for ; Wed, 19 Jul 2000 04:14:56 -0400 (EDT) Received: from csa.iisc.ernet.in by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQiymi07142 for ; Wed, 19 Jul 2000 08:14:38 GMT Received: from topaz.csa.iisc.ernet.in (IDENT:root@topaz.csa.iisc.ernet.in [144.16.67.33]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id NAA22047 for ; Wed, 19 Jul 2000 13:45:08 +0530 Received: from localhost (ytr@localhost) by topaz.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id NAA26952 for ; Wed, 19 Jul 2000 13:44:34 +0530 X-Authentication-Warning: topaz.csa.iisc.ernet.in: ytr owned process doing -bs Date: Wed, 19 Jul 2000 13:44:34 +0530 (IST) From: Ramanjaneyulu Y T To: mpls@UU.NET Subject: LSR down Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Suppose LSP is established between source and destination , and data transmission is taking place through this LSP. If any LSR goes down how MPLS will handle this situation. Regards Ramanajaneyulu Y.T. " A real friend is one who walks in when the rest of the world walks out." ------------------------------------------------------------------------------ Y.T.RAMANJANEYULU | My other mail Ids: E-70,INDIAN INSTITUTE OF SCIENCE | ytr@rediffmail.com BANGALORE - 560012 | kingytr@excite.com PH: 0091 - 080 - 3092622 ( HOSTEL ) | 0091 - 080 - 3092906 ( LAB ) | visit my home page:www2.csa.iisc.ernet.in/~ytr -------------------------------------------------------------------------------- From owner-mpls@UU.NET Wed Jul 19 06:38: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 GAA22946 for ; Wed, 19 Jul 2000 06:38:15 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyms11296; Wed, 19 Jul 2000 10:37:44 GMT Received: by mail-control.mail.uu.net id QQiyms29055 for mpls-outgoing; Wed, 19 Jul 2000 10:37: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 QQiyms29042 for ; Wed, 19 Jul 2000 10:37:00 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyms01251 for ; Wed, 19 Jul 2000 06:36:52 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyms10736 for ; Wed, 19 Jul 2000 10:36:51 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA11632 for mpls@uu.net; Wed, 19 Jul 2000 06:36:50 -0400 (EDT) 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 QQiyms28924 for ; Wed, 19 Jul 2000 10:36:09 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyms19938 for ; Wed, 19 Jul 2000 06:35:53 -0400 (EDT) Received: from ietf.org by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQiyms09995 for ; Wed, 19 Jul 2000 10:35: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 GAA21391; Wed, 19 Jul 2000 06:35:22 -0400 (EDT) Message-Id: <200007191035.GAA21391@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-ldp-mib-06.txt Date: Wed, 19 Jul 2000 06:35:22 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) Author(s) : J. Cucchiara, H. Sjostrand, J. Luciani Filename : draft-ietf-mpls-ldp-mib-06.txt Pages : 84 Date : 18-Jul-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mib-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-ldp-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-ldp-mib-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000718140626.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-ldp-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000718140626.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jul 19 09:33: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 JAA02053 for ; Wed, 19 Jul 2000 09:33:44 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyne06319; Wed, 19 Jul 2000 13:33:07 GMT Received: by mail-control.mail.uu.net id QQiyne19631 for mpls-outgoing; Wed, 19 Jul 2000 13:32: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 QQiyne19626 for ; Wed, 19 Jul 2000 13:32:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyne21701 for ; Wed, 19 Jul 2000 09:32:20 -0400 (EDT) Received: from thumper.research.telcordia.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: thumper.research.telcordia.com [128.96.41.1]) id QQiyne20173 for ; Wed, 19 Jul 2000 13:32:20 GMT Received: from monday.research.telcordia.com (monday [192.4.16.50]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id e6JDVhR03335; Wed, 19 Jul 2000 09:31:43 -0400 (EDT) Received: from monday (monday.research.telcordia.com [192.4.16.50]) by monday.research.telcordia.com (8.8.8/8.8.8) with SMTP id JAA01658; Wed, 19 Jul 2000 09:31:43 -0400 (EDT) Message-Id: <200007191331.JAA01658@monday.research.telcordia.com> Date: Wed, 19 Jul 2000 09:31:43 -0400 (EDT) From: Ritu Chadha Reply-To: Ritu Chadha Subject: Re: Policy Information Model for MPLS Traffic Engineering To: swallow@cisco.com, chadha@research.telcordia.com, tnadeau@cisco.com Cc: policy@raleigh.ibm.com, mpls@UU.NET, chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@research.telcordia.com, wweiss@ellacoya.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NtpeLvHjMBprkX0lKC7xnA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk Unfortunately, the draft agenda released yesterday shows that the NIM BOF clashes with the MPLS meeting on Wed morning... Ritu >X-Sender: tnadeau@bucket.cisco.com >Date: Tue, 18 Jul 2000 13:31:42 -0400 >To: George Swallow , Ritu Chadha >From: "Thomas D. Nadeau" >Subject: Re: Policy Information Model for MPLS Traffic Engineering >Cc: policy@raleigh.ibm.com, mpls@UU.NET, chadha@research.telcordia.com, hlin1@telcordia.com, mykoniat@research.telcordia.com, Walter Weiss >Mime-Version: 1.0 > > > Hi, > > I just want to add my 2 cents here. First, I >agree as I have all along, that this stuff does not belong >in the MPLS WG. Second, there is a BOF in Pittsburgh which >is designed specifically to coordinate the specification >of object models (for policy or otherwise). The BOF >is called Network Information Modeling (NIM). You >can join the discussion list by sending email to >nim-req@ops.ietf.org I believe that Walter Weiss >is coordinating the BOF. > > --Tom > >> > George Swallow stated that policy and MPLS are two things >> > that have a lot in common and therefore was worth working on. >> >>There's a problem with sound bites. I also said that I didn't think >>the work belonged in MPLS. >> >> > The consensus in the WG seemed to be that contributions in >> > this area should be brought to the MPLS WG. >> >>I didn't agree with this consensus because the request was too general >>and thus overlaps with other work groups. Though our revised charter >>is still being worked out with the IESG, there will be no general >>policy item in it. If specific items are needed in RSVP, LDP and >>CR-LDP to glue things together, these are appropriate. >> >>Given that the MPLS agenda is tight, I would like both >> >> draft-chadha-policy-mpls-te-00.txt >> draft-isoyama-policy-mpls-info-model-00.txt >> >>present only in the policy wg. >> >>...George >> >> >>================================================================== >>George Swallow Cisco Systems (978) 244-8143 >> 250 Apollo Drive >> Chelmsford, Ma 01824 > ============================================================================= Ritu Chadha Senior Scientist Telcordia Technologies (973) 829-4869 (voice) MCC 1J-218R (973) 829-5889 (fax) 445 South Street chadha@research.telcordia.com Morristown NJ 07960. ============================================================================= From owner-mpls@UU.NET Wed Jul 19 09:43: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 JAA06088 for ; Wed, 19 Jul 2000 09:43:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyne24992; Wed, 19 Jul 2000 13:43:06 GMT Received: by mail-control.mail.uu.net id QQiyne20268 for mpls-outgoing; Wed, 19 Jul 2000 13:42:32 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiyne20259 for ; Wed, 19 Jul 2000 13:42:19 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyne23342 for ; Wed, 19 Jul 2000 09:42:03 -0400 (EDT) Received: from cad.zju.edu.cn by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [210.32.131.2]) id QQiyne14225 for ; Wed, 19 Jul 2000 13:41:45 GMT Received: from cad.zju.edu.cn ([210.32.131.97]) by cad.zju.edu.cn (Netscape Messaging Server 3.6) with ESMTP id 375 for ; Wed, 19 Jul 2000 21:41:31 +0800 Message-ID: <3975A202.C5BF929C@cad.zju.edu.cn> Date: Wed, 19 Jul 2000 21:41:38 +0900 From: jing shen Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: MPLS list Subject: MPLS and traffic shaping: Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi: I'm a newcomer of MPLS and now reading doc from IETF. I want to know , is there any mechanism provided by MPLS on conditioning traffic through LSR? ( as that provided by ATM) james shen From owner-mpls@UU.NET Wed Jul 19 09:53: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 JAA09911 for ; Wed, 19 Jul 2000 09:53:21 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiynf24128; Wed, 19 Jul 2000 13:52:56 GMT Received: by mail-control.mail.uu.net id QQiynf20990 for mpls-outgoing; Wed, 19 Jul 2000 13:52: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 QQiynf20985 for ; Wed, 19 Jul 2000 13:52: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 QQiynf15319 for ; Wed, 19 Jul 2000 09:52:06 -0400 (EDT) Received: from web5103.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web5103.mail.yahoo.com [216.115.106.73]) id QQiynf22980 for ; Wed, 19 Jul 2000 13:51:50 GMT Message-ID: <20000719135150.3987.qmail@web5103.mail.yahoo.com> Received: from [169.144.16.187] by web5103.mail.yahoo.com; Wed, 19 Jul 2000 06:51:50 PDT Date: Wed, 19 Jul 2000 06:51:50 -0700 (PDT) From: Chatur sharp To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi folks, I have a very simple querry. Consider the scenerio given below L1 L2 LSR1 ---- LSR2----LSR3 The LSR1 and LSR3 are the ingress and egress respectively for an LSP for FEC F. Now when LSR1 gets an unlabelled packet, such that it maps to FEC F then it will label the packet with a label L1 and forward it LSR2 who will in turn forward it to LSR3 with label L2. (LSR2 will swap L1 with L2) Now should will LSR3 do an LPM to determine the interface through which it must forward the packet ? Can it be avoided by choosing appropriate label L2 ? In general, is it always necassary to do LPM at the egress LSR. ( Assuming no PHP ) ? Put differently at the end of a LSP, what is generally done - LPM, or a direct forwarding based on the incoming label. Is there any other forum where I can ask this question. thanks C. ===== I am willing to learn, if you care to teach. I am willing to teach, if you care to learn. __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From owner-mpls@UU.NET Wed Jul 19 10:12: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 KAA17078 for ; Wed, 19 Jul 2000 10:12:06 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyng09078; Wed, 19 Jul 2000 14:11:17 GMT Received: by mail-control.mail.uu.net id QQiyng02876 for mpls-outgoing; Wed, 19 Jul 2000 14:10: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 QQiyng02771 for ; Wed, 19 Jul 2000 14:10: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 QQiyng27913 for ; Wed, 19 Jul 2000 10:09:46 -0400 (EDT) Received: from mailrelay.laurelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laurelnetworks.com [206.67.234.84]) id QQiyng07839 for ; Wed, 19 Jul 2000 14:09:31 GMT Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id KAA01676; Wed, 19 Jul 2000 10:09:30 -0400 Received: (from jleu@localhost) by localhost.laurelnetworks.com (8.9.3/8.9.3) id KAA01232; Wed, 19 Jul 2000 10:09:30 -0400 Date: Wed, 19 Jul 2000 10:09:29 -0400 From: "James R. Leu" To: Chatur sharp Cc: mpls@UU.NET Subject: Re: your mail Message-ID: <20000719100929.A906@laurelnetworks.com> Reply-To: jleu@laurelnetworks.com References: <20000719135150.3987.qmail@web5103.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000719135150.3987.qmail@web5103.mail.yahoo.com>; from chatur_b@yahoo.com on Wed, Jul 19, 2000 at 06:51:50AM -0700 Organization: Laurel Networks Sender: owner-mpls@UU.NET Precedence: bulk Comment below: On Wed, Jul 19, 2000 at 06:51:50AM -0700, Chatur sharp wrote: > Hi folks, > > I have a very simple querry. > > Consider the scenerio given below > > L1 L2 > LSR1 ---- LSR2----LSR3 > > > The LSR1 and LSR3 are the ingress and egress > respectively for an LSP for FEC F. > > Now when LSR1 gets an unlabelled packet, such that > it maps to FEC F then it will label the packet with > a label L1 and forward it LSR2 who will in turn > forward it to LSR3 with label L2. (LSR2 will swap L1 > with L2) > > > Now should will LSR3 do an LPM to determine the > interface through which it must forward the packet ? > > Can it be avoided by choosing appropriate label L2 ? > > In general, is it always necassary to do LPM at > the egress LSR. ( Assuming no PHP ) ? Put differently > at the end of a LSP, what is generally done - LPM, > or a direct forwarding based on the incoming label. > > Is there any other forum where I can ask this > question. Being that LSR3 allocated the label L2 it can attach whatever meaning it wants to L2. It all depends on the qualities of the FEC F, the granularity of the label allocation scheme, and how these are tied together in the forwarding plan. Jim -- James R. Leu Software Engineer Laurel Networks, Inc jleu@laurelnetworks.com From owner-mpls@UU.NET Wed Jul 19 10:32: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 KAA24855 for ; Wed, 19 Jul 2000 10:32:06 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyni18952; Wed, 19 Jul 2000 14:31:31 GMT Received: by mail-control.mail.uu.net id QQiyni04818 for mpls-outgoing; Wed, 19 Jul 2000 14:30: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 QQiyni04813 for ; Wed, 19 Jul 2000 14:30: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 QQiyni22313 for ; Wed, 19 Jul 2000 10:30:29 -0400 (EDT) Received: from alpha.tellium.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQiyni25333 for ; Wed, 19 Jul 2000 14:30:28 GMT Received: from tellium.com (client-151-198-92-104.bellatlantic.net [151.198.92.104] (may be forged)) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e6JENm523950; Wed, 19 Jul 2000 10:23:48 -0400 (EDT) Message-ID: <3975BB8D.CABD6FC8@tellium.com> Date: Wed, 19 Jul 2000 10:30:37 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: FYI:draft-many-ip-optical-framework-01.txt] Content-Type: multipart/mixed; boundary="------------3F24FC68880C80E985D2DA99" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------3F24FC68880C80E985D2DA99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com --------------3F24FC68880C80E985D2DA99 Content-Type: message/rfc822 Content-Disposition: inline Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e6JDZf521303; Wed, 19 Jul 2000 09:35:42 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA12741 for ietf-123-outbound.05@ietf.org; Wed, 19 Jul 2000 09:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA11112 for ; Wed, 19 Jul 2000 06:32:51 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20054 for ; Wed, 19 Jul 2000 06:32:52 -0400 (EDT) Message-Id: <200007191032.GAA20054@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-many-ip-optical-framework-01.txt Date: Wed, 19 Jul 2000 06:32:51 -0400 Sender: nsyracus@cnri.reston.va.us X-Mozilla-Status2: 00000000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP over Optical Networks - A Framework Author(s) : B. Rajagopalan, J. Luciani, D. Awduche, B. Cain, B. Jamoussi Filename : draft-many-ip-optical-framework-01.txt Pages : 35 Date : 18-Jul-00 The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. A consensus is emerging in the industry on utilizing IP-centric protocols for the optical control plane [9, 10], as well as for dynamic bandwidth provisioning for IP services. Also, there has recently been significant activity in defining models for IP transport over optical networks, specifically, the routing and signaling aspects [2,6,7]. This draft attempts to define a framework for IP over Optical networks, considering both the IP control plane for optical networks as well as IP transport over optical networks (together referred to as 'IP over optical networks'). Within this framework, we develop a common set of terms and concepts which allows to discuss these IP over optical technologies in a consistent fashion. Additionally, this draft surveys some architectural frameworks that might be useful and appropriate for the deployment of IP over hybrid optical networks that contain IP routers, WDM multiplexers, and optical cross-connects (OXCs). This document is complementary to the framework of Multiprotocol Lambda Switching proposed in [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-many-ip-optical-framework-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-many-ip-optical-framework-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-many-ip-optical-framework-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000718135435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-many-ip-optical-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-many-ip-optical-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000718135435.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------3F24FC68880C80E985D2DA99-- From owner-mpls@UU.NET Wed Jul 19 12:07: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 MAA04071 for ; Wed, 19 Jul 2000 12:07:00 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyno08236; Wed, 19 Jul 2000 16:06:31 GMT Received: by mail-control.mail.uu.net id QQiyno01702 for mpls-outgoing; Wed, 19 Jul 2000 16:06:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiyno01651 for ; Wed, 19 Jul 2000 16:05:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyno19517 for ; Wed, 19 Jul 2000 12:05:53 -0400 (EDT) Received: from mx2.tellabs.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mx2.tellabs.com [204.68.180.51]) id QQiyno18873 for ; Wed, 19 Jul 2000 16:05:53 GMT Received: from mail.hq.tellabs.com (tlab-138-111-51-100.tellabs.com [138.111.51.100] (may be forged)) by mx2.tellabs.com (8.8.8/8.8.8) with ESMTP id LAA01970; Wed, 19 Jul 2000 11:05:15 -0500 (CDT) Received: from tellabs.com (hdqpcq2150.lisle.tellabs.com [138.111.90.150]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA22335; Wed, 19 Jul 2000 11:05:40 -0500 (CDT) Message-ID: <3975D1D1.C12D1476@tellabs.com> Date: Wed, 19 Jul 2000 11:05:37 -0500 From: Srinivas Makam Organization: Tellabs Operations, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: Ben.Mack-Crane@tellabs.com, srinivas.makam@tellabs.com, Ken.Owens@tellabs.com, jonweil@nortelnetworks.com, loa.andersson@nortelnetworks.com, scivanlar@coreon.net, Vishal.Sharma@tellabs.com, Changcheng.Huang@tellabs.com, Fiffi@nortelnetworks.com, bcain@mirror-image.com, jamoussi@nortelnetworks.com, alchiu@att.com Subject: Revised MPLS recovery framework draft: comments invited References: <396E4D2F.EEDF2E25@tellabs.com> Content-Type: multipart/mixed; boundary="------------80F76F5140F914965C44B710" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------80F76F5140F914965C44B710 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, A revised version of our draft Framework for MPLS-based Recovery draft-makam-mpls-recovery-frmwrk-01.txt is now available on the IETF drafts directory at http://www.ietf.org/internet-drafts/draft-makam-mpls-recovery-frmwrk-01.txt The draft incorporates comments we received from several people on the list. We would be delighted to have further feedback and comments on the new version, so we can move this work forward at Pittsburgh. Thanks, -Vas Makam --------------80F76F5140F914965C44B710 Content-Type: text/x-vcard; charset=us-ascii; name="srinivas.makam.vcf" Content-Description: Card for Srinivas Makam Content-Disposition: attachment; filename="srinivas.makam.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Makam;Srinivas tel;fax:(630) 512-8037 tel;work:(630) 512-7217 x-mozilla-html:TRUE org:DSD;Portfolio Planning adr:;;4951 Indiana Avenue;Lisle;Illinois;60532;USA version:2.1 email;internet:Srinivas.Makam@tellabs.com title:Staff Engineer fn:Srinivas Makam end:vcard --------------80F76F5140F914965C44B710-- From owner-mpls@UU.NET Wed Jul 19 12:11: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 MAA05771 for ; Wed, 19 Jul 2000 12:11:12 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyno23467; Wed, 19 Jul 2000 16:10:46 GMT Received: by mail-control.mail.uu.net id QQiyno06479 for mpls-outgoing; Wed, 19 Jul 2000 16:10: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 QQiyno06332 for ; Wed, 19 Jul 2000 16:10:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyno11935 for ; Wed, 19 Jul 2000 12:09:30 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyno10503 for ; Wed, 19 Jul 2000 16:09:29 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA22798 for mpls@uu.net; Wed, 19 Jul 2000 12:09:28 -0400 (EDT) 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 QQiyno05486 for ; Wed, 19 Jul 2000 16:08: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 QQiyno20146 for ; Wed, 19 Jul 2000 12:08:27 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyno09772 for ; Wed, 19 Jul 2000 16:08:27 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 MAA22482 for ; Wed, 19 Jul 2000 12:08:26 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA25432 for ; Wed, 19 Jul 2000 12:08:26 -0400 (EDT) Message-Id: <200007191608.MAA25432@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Two last calls Date: Wed, 19 Jul 2000 12:08:26 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk This message begins a last calls on: draft-ietf-mpls-diff-ext-06.txt and draft-ietf-mpls-rsvp-lsp-tunnel-06.txt The last calls will end on July 26 midnight GMT. Comment are limited to the deltas between these and their respective prior drafts. With regard to the RSVP-TE draft, the recent comments to the list are accepted as last call comments and need not be repeated. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Jul 19 12:18: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 MAA08751 for ; Wed, 19 Jul 2000 12:18:14 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiynp16558; Wed, 19 Jul 2000 16:17:39 GMT Received: by mail-control.mail.uu.net id QQiynp07722 for mpls-outgoing; Wed, 19 Jul 2000 16:17:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiynp07717 for ; Wed, 19 Jul 2000 16:17:11 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 QQiynp22201 for ; Wed, 19 Jul 2000 12:16:52 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiynp28613 for ; Wed, 19 Jul 2000 16:16:21 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA07457 for ; Wed, 19 Jul 2000 09:16:34 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA18795 for mpls@uu.net; Wed, 19 Jul 2000 12:16:19 -0400 (EDT) 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 QQiynk10982 for ; Wed, 19 Jul 2000 15:03: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 QQiynk28419 for ; Wed, 19 Jul 2000 11:03:02 -0400 (EDT) From: Spencer.Giacalone@predictive.com Received: from athena.predictive.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: athena.predictive.com [208.209.197.197]) id QQiynk04432 for ; Wed, 19 Jul 2000 15:03:02 GMT To: mpls@UU.NET Subject: new draft X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000 Message-ID: Date: Mon, 19 Jun 2000 11:04:17 -0400 X-MIMETrack: Serialize by Router on Athena/Predictive(Release 5.0.4 |June 8, 2000) at 07/19/2000 11:04:19 AM, Serialize complete at 07/19/2000 11:04:19 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk FYI, A new ID was posted a few weeks back. The memo can be found at: http://www.ietf.org/internet-drafts/draft-giacalone-te-optical-next-00.txt An overview is as follows: Abstract This memo defines extensions to OSPFv3 [2] to provide support for Network Engineering. This set of extensions is termed Network Engineering eXTensions for OSPFv3, or NEXT. The term network engineering was chosen to impart NEXT's wide scope of functionality. NEXT is intended to provide holistic and extremely rich state information to OSPFv3 routers. Using this information, various advanced topological and administrative decisions can be made. Please send comments to ospf@discuss.microsoft.com. Overview This document details extensions to OSPFv3 [2] called NEXT. NEXT can be used to add very granular network engineering capabilities to OSPFv3 networks. To accomplish this, NEXT provides a wealth of interface, link, and device capability and state information to OSPFv3, or other protocols. The intent of NEXT is to enable the selection of shortest paths through networks based on sets of advanced network state criteria. Using NEXT, advanced policy decisions can be made, and traffic can be routed or switch traffic with varying qualities of service. NEXT can also assist in building complex fault tolerant networks. NEXT aims to provide a system of unified network state information to satisfy the requirements of numerous existing and developmental protocols. While NEXT builds on functionality presented in other works, it adds many new features, presents new philosophical possibilities, and is intended for use with OSPFv3. NEXT focuses on traffic engineering (TE) [3,4] and Multi Protocol lambda Switching (MPLmS) [5,6], and Protection Wavelength Routing, but is specifically intended to support changing requirements and technologies in the future. A core philosophical premise of NEXT is that it may effect the core topology building process of OSPFv3, or may be used to build separate "shadow" topologies. In the former, NEXT can be used a basis to make sophisticated decisions within OSPFv3. In the later, OSPFv3/NEXT can serve to build repositories of detailed information to enhance supplementary protocols. NEXT supports advanced intra-area and inter-area routing. Since NEXT operates with and depends on OSPFv3, which is essentially network protocol independent, NEXT can be used to enable all networks to become extensively self aware. It is hoped that NEXT will become a focal point for the distribution of advanced network information, enhancing OSPFv3 (and other protocols) while enabling complex deterministic services to be implemented. Note that in addition to allowing existing QOS protocols, such as RSVP, to provide new types of QoS, NEXT can enhance these protocols, by reducing the possibility of "crank-back". Extensions to other protocols to make use of NEXT information may be needed. -Spence From owner-mpls@UU.NET Wed Jul 19 12:40: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 MAA19133 for ; Wed, 19 Jul 2000 12:40:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiynq03932; Wed, 19 Jul 2000 16:40:15 GMT Received: by mail-control.mail.uu.net id QQiynq08936 for mpls-outgoing; Wed, 19 Jul 2000 16:39: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 QQiynq08931 for ; Wed, 19 Jul 2000 16:39: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 QQiynq18364 for ; Wed, 19 Jul 2000 12:39:27 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiynq02646 for ; Wed, 19 Jul 2000 16:39:27 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA29742 for mpls@uu.net; Wed, 19 Jul 2000 12:39:26 -0400 (EDT) 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 QQiynq08915 for ; Wed, 19 Jul 2000 16:39: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 QQiynq18285 for ; Wed, 19 Jul 2000 12:38:57 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQiynq15967 for ; Wed, 19 Jul 2000 16:38:56 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 JAA16524; Wed, 19 Jul 2000 09:38:53 -0700 (PDT) Message-ID: <3975D99C.3269265B@pluris.com> Date: Wed, 19 Jul 2000 09:38:52 -0700 From: Bora Akyol X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow CC: mpls@UU.NET Subject: Re: Two last calls References: <200007191608.MAA25432@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 It would have been very nice to see a diff of the diffserv extensions draft as well. Thanks Bora George Swallow wrote: > This message begins a last calls on: > > draft-ietf-mpls-diff-ext-06.txt and > draft-ietf-mpls-rsvp-lsp-tunnel-06.txt > > The last calls will end on July 26 midnight GMT. Comment are limited > to the deltas between these and their respective prior drafts. > > With regard to the RSVP-TE draft, the recent comments to the list are > accepted as last call comments and need not be repeated. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Jul 19 13:04: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 NAA28767 for ; Wed, 19 Jul 2000 13:04:04 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyns07576; Wed, 19 Jul 2000 17:03:06 GMT Received: by mail-control.mail.uu.net id QQiyns16476 for mpls-outgoing; Wed, 19 Jul 2000 17:02:33 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiyns16469 for ; Wed, 19 Jul 2000 17:02:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyns00513 for ; Wed, 19 Jul 2000 13:02:08 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyns00902 for ; Wed, 19 Jul 2000 17:02:08 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA03947 for mpls@uu.net; Wed, 19 Jul 2000 13:02:07 -0400 (EDT) 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 QQiyns14062 for ; Wed, 19 Jul 2000 17:01: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 QQiyns22592 for ; Wed, 19 Jul 2000 13:01:16 -0400 (EDT) Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQiyns05747 for ; Wed, 19 Jul 2000 17:00:45 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 63C41FB for ; Wed, 19 Jul 2000 19:00:45 +0200 (MET DST) Received: from flefauch-8kcdt.cisco.com (nice-dhcp3.cisco.com [144.254.60.25]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id TAA23114 for ; Wed, 19 Jul 2000 19:00:44 +0200 (MET DST) Message-Id: <200007191700.TAA23114@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 19 Jul 2000 18:57:19 +0200 To: mpls@UU.NET From: Francois Le Faucheur Subject: Re: Two last calls (draft-ietf-mpls-diff-ext-06.txt ) In-Reply-To: <200007191608.MAA25432@lir.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hello, At 12:08 19/07/2000 -0400, George Swallow wrote: >This message begins a last calls on: > > draft-ietf-mpls-diff-ext-06.txt Thanks to everyone who reviewed and commented as part of the first last call, to help us improve this document. To facilitate this last call, here are the details on the resolution of the first last call comments (i.e. on -05.txt): Tunnelling Models ================= o Some concerns were expressed about the stability of the Pipe and Uniform models defined in the Diff-Serv WG: The document defining those two models has since completed Working Group LAst CAll () and is under Area Director Review on its way to the IESG for publication as an Informational RFC. So we feel this is stable material. o There was a discussion on whether both models were necessary for MPLS operations: We concluded from the discussion that : - 1) the Pipe model is necessary for operations in intra-domain operations (e.g. MPLS VPN) and is "simpler" to implement in MPLS (on the pop side) - 2) the Uniform model seems mainly useful for inter-domain operations (which is a lower priority target for our current specification) and for "emulating" operations of a non-MPLS IP network. Also it involves more complex MPLS operations. Based on this we changed the levels of requirement for support of these models: the Pipe model is changed to Mandatory, while the Uniform model is changed to Optional. o one comment that the Uniform Model was not fully specified: I understand this was cleared in the discussion between Shahram and Eric (Shahram, Eric?) o some minor word-smithing in the description of the models to align to proper Diff-Serv terminology (in line with latest adjustment of the Diff-Serv over Tunnel draft). Additional Error Codes ====================== o one possible error situation was not covered by existing Error Codes: one error code and associated Error Handling description was added in both RSVP and LDP. This was resolved in thread "New Error Codes". Multiple pops with PHP ====================== o comment that section 2.6 discussed multiple POPs with PHP which is not a realistic situation. text refering to multiple POPs with PHP has been removed. Outgoing PHB Determination in Router Model ========================================= o comment that text incorrectly referred to the "outgoing PHB Determination" as optional while in reality it is only the Traffic Conditioning stage of the Outgoing PHB Determination which is optional: text corrected accordingly. ECN === o as agreed, ECN section was removed. A short statement on compatibility of the Diff-Serv solution with future ECN support was added to the introduction. Default for Preconfigured EXP<-->PHB mapping ============================================ As suggested, a default for Preconfigured EXP<-->PHB mapping was added. signaling of Diff-Serv tunnelling mode ====================================== o one request to signal Diff-Serv tunnelling model on a per-LSP basis: This had been discussed before on the alias and conclusion was that it was not yet clear that signalling of the tunnelling model was required. Text has been updated to clarify that signaling to set tunneling model on a per-LSP basis is out of the scope of this first version but could be added later if required. signaling of per-PSC bandwidth with E-LSPs ========================================== o one request to signal per-PSC bandwidth with E-LSPs: This had been discussed before in the WG. This additional option would allow bandwidth reservation on a per PSC basis using E-LSPs. However , bandwidth reservation on a per-PSC basis can already be achieved with the existing option set through the use of L-LSPs. The poll to the WG had concluded that it was not worth supporting this additional option in the first version. So no change was made in the draft. LDP Status Codes ================ o Comment that some proposed LDP Status Codes were overlapping with some recently allocated code values in the LDP spec: LDP Status Codes where changed to a separate range in line with allocation rules defined in LDP spec. Other changes ============= - section on ATM specifics and FR specifics: text changed to explain that it is the CLP/DE mapping defined earlier which ensures that the AF requirements for operations with two drop precedence levels are met. - sections on PPP and LAN combined into a single one. Simpler wording used. - removed text which was identical for E-LSPs and L-LSPs in sections 3 and 4 by cross-referencing. - descriptions of Uniform and Pipe models was shortened by removing redundant text - changed wording to more clearly state the relationship between the tunnel models used at different levels of LSP hierarchy - in RSVP section. Use "reservation" only in context of bandwidth reservation. Otherwise use "label request". - in RSVP section, "RSVP Router" was replaced by "LSR" - in RSVP section, removed the value of 26 tentatively proposed for the "Diff-SErv Error" error code since it is pending IANA allocation. - clarification in ascii art for pictures illustrating tunnel models - removed redundant text in description of E-LSPs/L-LSPs between section 1 and sections 3 and 4 - removed a few additional redundancies - added text to introduce the concept of "MPLS Protection" (instead of using the "Fast Restoration") - added terminology section - added IANA section (and corresponding references) - added Copyright statement - minor wording improvements - typos Francois From owner-mpls@UU.NET Wed Jul 19 13: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 NAA20182 for ; Wed, 19 Jul 2000 13:54:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiynv20339; Wed, 19 Jul 2000 17:54:08 GMT Received: by mail-control.mail.uu.net id QQiynv27286 for mpls-outgoing; Wed, 19 Jul 2000 17:53: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 QQiynv27278 for ; Wed, 19 Jul 2000 17:53:29 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiynv01839 for ; Wed, 19 Jul 2000 13:53:18 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQiynv25331 for ; Wed, 19 Jul 2000 17:53:18 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <36QHDLQD>; Wed, 19 Jul 2000 11:00:24 -0700 Message-ID: <4D3F9F2BEC58D4118FCE009027B0A662136029@ICARIAN> From: Eric Gray To: "George Swallow (E-mail)" , "'Vijay Srinivasan'" Cc: "MPLS Mailing List (E-mail)" Subject: Process has been circumvented again Date: Wed, 19 Jul 2000 11:00:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk George/Vijay, I don't recall there being a specific consensus to accept these documents as working group drafts: http://www.ietf.org/internet-drafts/draft-ietf-mpls-hdr-comp-00.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-hdr-comp-over-ppp-00.txt Did I miss it? I noticed that the minutes from Adelaide showed that there was consensus to perform work in this area, but is that the same as accepting these drafts? -- Eric Gray From owner-mpls@UU.NET Wed Jul 19 14:11:58 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27505 for ; Wed, 19 Jul 2000 14:11:58 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiynw02948; Wed, 19 Jul 2000 18:11:28 GMT Received: by mail-control.mail.uu.net id QQiynw10371 for mpls-outgoing; Wed, 19 Jul 2000 18:10: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 QQiynw10353 for ; Wed, 19 Jul 2000 18:10: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 QQiynw12781 for ; Wed, 19 Jul 2000 14:10:19 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiynw09360 for ; Wed, 19 Jul 2000 18:10:18 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id NAA32217; Wed, 19 Jul 2000 13:10:07 -0500 Message-Id: <4.3.2.7.2.20000719140739.00b81ef0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2000 14:10:23 -0400 To: Eric Gray From: Lou Berger Subject: Re: Process has been circumvented again Cc: "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" In-Reply-To: <4D3F9F2BEC58D4118FCE009027B0A662136029@ICARIAN> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Eric, Yes, you missed it. (Sometimes minutes don't capture the fullness of a discussion, oh well...) There was specific agreement in Adelaide to bring these documents into the working group, i.e., to make them WG documents. At least that's what I witnessed. Lou At 11:00 AM 7/19/00 -0700, Eric Gray wrote: >George/Vijay, > > I don't recall there being a specific consensus >to accept these documents as working group drafts: > >http://www.ietf.org/internet-drafts/draft-ietf-mpls-hdr-comp-00.txt >http://www.ietf.org/internet-drafts/draft-ietf-mpls-hdr-comp-over-ppp-00.txt > > > Did I miss it? I noticed that the minutes from >Adelaide showed that there was consensus to perform >work in this area, but is that the same as accepting >these drafts? > >-- >Eric Gray From owner-mpls@UU.NET Wed Jul 19 15:29: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 PAA00688 for ; Wed, 19 Jul 2000 15:29:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyob06985; Wed, 19 Jul 2000 19:28:48 GMT Received: by mail-control.mail.uu.net id QQiyob29992 for mpls-outgoing; Wed, 19 Jul 2000 19:28: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 QQiyob29986 for ; Wed, 19 Jul 2000 19: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 QQiyob26442 for ; Wed, 19 Jul 2000 15:28:08 -0400 (EDT) Received: from exchsrv1.cosinecom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cosinecom.com [63.88.104.16]) id QQiyob05307 for ; Wed, 19 Jul 2000 19:27:37 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id <3Q9YL2Q3>; Wed, 19 Jul 2000 12:27:25 -0700 Message-ID: <7EB7C6B62C4FD41196A80090279A29112D93F9@exchsrv1.cosinecom.com> From: Jay Wang To: "'jshen@cad.zju.edu.cn'" , MPLS list Subject: RE: MPLS and traffic shaping: Date: Wed, 19 Jul 2000 12:27:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="gb2312" Sender: owner-mpls@UU.NET Precedence: bulk James, You probabily will find more information on Traffic Conditioning, or just Traffic Shaping under Diffserv WG. The following documents are good starting points: RFC 2475, 2697, 2698, and ID draft-ietf-diffserv-model-03 - Jay Wang > -----Original Message----- > From: jing shen [mailto:jshen@cad.zju.edu.cn] > Sent: Wednesday, July 19, 2000 5:42 AM > To: MPLS list > Subject: MPLS and traffic shaping: > > > Hi: > > I'm a newcomer of MPLS and now reading doc from IETF. > I want to know , is there any mechanism provided by MPLS on > conditioning > traffic > through LSR? ( as that provided by ATM) > > james shen > From owner-mpls@UU.NET Wed Jul 19 17:02: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 RAA09691 for ; Wed, 19 Jul 2000 17:02:48 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyoi14372; Wed, 19 Jul 2000 21:02:11 GMT Received: by mail-control.mail.uu.net id QQiyoi23279 for mpls-outgoing; Wed, 19 Jul 2000 21:01:52 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiyoi23245 for ; Wed, 19 Jul 2000 21:01: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 QQiyoi12066 for ; Wed, 19 Jul 2000 17:01:40 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiyoi23004 for ; Wed, 19 Jul 2000 21:01:10 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA27482; Wed, 19 Jul 2000 14:01:22 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA19574; Wed, 19 Jul 2000 17:01:08 -0400 (EDT) Message-Id: <200007192101.RAA19574@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Lou Berger cc: Eric Gray , "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" Subject: Re: Process has been circumvented again In-reply-to: Your message of Wed, 19 Jul 2000 14:10:23 -0400. <4.3.2.7.2.20000719140739.00b81ef0@mail.labn.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 19 Jul 2000 17:01:08 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk I wasn't in Adelaide so I can't comment on what might have happened there. But I would be interested in knowing why MPLS header compression is deemed useful. Header compression is generally used only on lower speed links. Are you envisioning the use of MPLS for traffic engineering on low-speed links, or are you worried about supporting VPNs over a low-speed backbone? From owner-mpls@UU.NET Wed Jul 19 17:32: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 RAA19853 for ; Wed, 19 Jul 2000 17:32:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyok05000; Wed, 19 Jul 2000 21:31:44 GMT Received: by mail-control.mail.uu.net id QQiyok04998 for mpls-outgoing; Wed, 19 Jul 2000 21:31:12 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiyok04914 for ; Wed, 19 Jul 2000 21:30: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 QQiyok16537 for ; Wed, 19 Jul 2000 17:30:38 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyok04124 for ; Wed, 19 Jul 2000 21:30:37 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA16644 for mpls@uu.net; Wed, 19 Jul 2000 17:30:36 -0400 (EDT) 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 QQiyoj04751 for ; Wed, 19 Jul 2000 21:29:52 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyoj16273 for ; Wed, 19 Jul 2000 17:29:43 -0400 (EDT) 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 QQiyoj03412 for ; Wed, 19 Jul 2000 21:29:42 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 RAA14703 for ; Wed, 19 Jul 2000 17:29:41 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA08064 for ; Wed, 19 Jul 2000 17:29:41 -0400 (EDT) Message-Id: <200007192129.RAA08064@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Delay in getting out agenda Date: Wed, 19 Jul 2000 17:29:41 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Folks - I'm in the process of resolving where (what WG) some of the drafts should be discussed with our ADs and some other IESG members. So I can't publish an agenda just yet. Also, I haven't seen the following drafts: draft-kompella-mpls-unnumbered-00.txt draft-bala-mpls-optical-uni-signaling-00.txt draft-aboulmagd-mpls-ldp-optical-uni-00.txt draft-paraschiv-mpls-lsp-query-00.txt draft-kankkunen-vompls-fw-01.txt Could the authors: a) verify that they were submitted on time. b) send me a copy. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Jul 19 17:48: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 RAA25501 for ; Wed, 19 Jul 2000 17:48:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyol22260; Wed, 19 Jul 2000 21:48:08 GMT Received: by mail-control.mail.uu.net id QQiyol07119 for mpls-outgoing; Wed, 19 Jul 2000 21:47: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 QQiyol07100 for ; Wed, 19 Jul 2000 21:47:16 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyol11469 for ; Wed, 19 Jul 2000 17:46:59 -0400 (EDT) Received: from alpha.tellium.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQiyol13752 for ; Wed, 19 Jul 2000 21:46:44 GMT Received: from tellium.com (client-151-198-92-104.bellatlantic.net [151.198.92.104] (may be forged)) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e6JLe7517958; Wed, 19 Jul 2000 17:40:13 -0400 (EDT) Message-ID: <397621D1.3EB5C098@tellium.com> Date: Wed, 19 Jul 2000 17:46:57 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: FYI: draft-bala-mpls-optical-uni-signaling-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The following draft has been submitted to internet-drafts. Name: Signaling Requirements at the Optical UNI URL: http://homepages.infoseek.com/~balarajagopalan/unidraft.txt Abstract: This draft considers the optical network service model referred to as the "domain services" model [1]. Under this model, the optical network provides a set of well-defined services to clients (IP and others). The signaling and routing interface between the client and optical networks is referred to as the User-Network Interface (UNI). This draft describes the services provided over the UNI, and the requirements on any signaling protocol used to invoke the services. This draft reflects ongoing work at the Optical Interworking Forum (OIF) and the Optical Domain Service Interconnect (ODSI) coalition on the optical UNI [2]. The relevance of this draft to the IETF is two-fold. First, for the signaling portion of the optical UNI, extensions of two MPLS signaling protocols are presently under consideration in the OIF: RSVP with TE extensions and LDP. The objective of this draft is to guide the adaptation of these protocols for UNI signaling. Second, to harmonize the signaling of UNI originated lightpath requests and peer model lightpath establishment mechanisms [1], alignment between OIF, ODSI and IETF lightpath parameters and signaling functionality is desirable. This draft aims to serve this purpose. The content of this draft is expected to evolve as work progresses on the optical UNI. -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Wed Jul 19 17: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 RAA28090 for ; Wed, 19 Jul 2000 17:55:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyol29998; Wed, 19 Jul 2000 21:55:08 GMT Received: by mail-control.mail.uu.net id QQiyol07532 for mpls-outgoing; Wed, 19 Jul 2000 21:54: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 QQiyol07527 for ; Wed, 19 Jul 2000 21:54:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyol20054 for ; Wed, 19 Jul 2000 17:54:10 -0400 (EDT) Received: from c000.snv.cp.net by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: c000-h000.c000.snv.cp.net [209.228.32.64]) id QQiyol19746 for ; Wed, 19 Jul 2000 21:53:55 GMT Received: (cpmta 19668 invoked from network); 19 Jul 2000 14:53:54 -0700 Received: from dhcp196.altasoft.com (HELO am) (204.242.142.196) by smtp.ipoptical.com (209.228.32.64) with SMTP; 19 Jul 2000 14:53:54 -0700 X-Sent: 19 Jul 2000 21:53:54 GMT From: "alex.mondrus" To: , Subject: RE: new draft Date: Wed, 19 Jul 2000 18:03:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Spencer: What problems are you trying to solve that have not been addressed yet in the previous TE IGP drafts ? Thank you, Alex Mondrus http://www.ipoptical.com -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Spencer.Giacalone@predictive.com Sent: Monday, June 19, 2000 11:04 AM To: mpls@UU.NET Subject: new draft FYI, A new ID was posted a few weeks back. The memo can be found at: http://www.ietf.org/internet-drafts/draft-giacalone-te-optical-next-00.txt An overview is as follows: Abstract This memo defines extensions to OSPFv3 [2] to provide support for Network Engineering. This set of extensions is termed Network Engineering eXTensions for OSPFv3, or NEXT. The term network engineering was chosen to impart NEXT's wide scope of functionality. NEXT is intended to provide holistic and extremely rich state information to OSPFv3 routers. Using this information, various advanced topological and administrative decisions can be made. Please send comments to ospf@discuss.microsoft.com. Overview This document details extensions to OSPFv3 [2] called NEXT. NEXT can be used to add very granular network engineering capabilities to OSPFv3 networks. To accomplish this, NEXT provides a wealth of interface, link, and device capability and state information to OSPFv3, or other protocols. The intent of NEXT is to enable the selection of shortest paths through networks based on sets of advanced network state criteria. Using NEXT, advanced policy decisions can be made, and traffic can be routed or switch traffic with varying qualities of service. NEXT can also assist in building complex fault tolerant networks. NEXT aims to provide a system of unified network state information to satisfy the requirements of numerous existing and developmental protocols. While NEXT builds on functionality presented in other works, it adds many new features, presents new philosophical possibilities, and is intended for use with OSPFv3. NEXT focuses on traffic engineering (TE) [3,4] and Multi Protocol lambda Switching (MPLmS) [5,6], and Protection Wavelength Routing, but is specifically intended to support changing requirements and technologies in the future. A core philosophical premise of NEXT is that it may effect the core topology building process of OSPFv3, or may be used to build separate "shadow" topologies. In the former, NEXT can be used a basis to make sophisticated decisions within OSPFv3. In the later, OSPFv3/NEXT can serve to build repositories of detailed information to enhance supplementary protocols. NEXT supports advanced intra-area and inter-area routing. Since NEXT operates with and depends on OSPFv3, which is essentially network protocol independent, NEXT can be used to enable all networks to become extensively self aware. It is hoped that NEXT will become a focal point for the distribution of advanced network information, enhancing OSPFv3 (and other protocols) while enabling complex deterministic services to be implemented. Note that in addition to allowing existing QOS protocols, such as RSVP, to provide new types of QoS, NEXT can enhance these protocols, by reducing the possibility of "crank-back". Extensions to other protocols to make use of NEXT information may be needed. -Spence From owner-mpls@UU.NET Wed Jul 19 18:03: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 SAA00915 for ; Wed, 19 Jul 2000 18:03:21 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyom08537; Wed, 19 Jul 2000 22:02:21 GMT Received: by mail-control.mail.uu.net id QQiyom11796 for mpls-outgoing; Wed, 19 Jul 2000 22:01: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 QQiyom10803 for ; Wed, 19 Jul 2000 22:01: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 QQiyom21137 for ; Wed, 19 Jul 2000 18:01:04 -0400 (EDT) Received: from exchange.sd.osicom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [131.143.32.20]) id QQiyom06815 for ; Wed, 19 Jul 2000 22:00:46 GMT Received: by exchange.sd.osicom.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jul 2000 14:58:05 -0700 Message-ID: From: "Zhang, Leah" To: "'Jonathan Lang'" , "Fu, James" , mpls@UU.NET Subject: RE: A new draft. Date: Wed, 19 Jul 2000 14:26:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF1CC.4B1EB960" 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_01BFF1CC.4B1EB960 Content-Type: text/plain; charset="iso-8859-1" Jonathan: Thanks very much for your comments. We read your draft very carefully. There are a lot of good thoughts and points in your draft. Please see our response below. James Fu, Dan Guo, Raymond Cheng, Leah Zhang Sorrento Networks Inc. 9990 Mesa Rim Road San Diego, CA 92121 -----Original Message----- From: Jonathan Lang [mailto:jplang@calient.net] Sent: Tuesday, July 18, 2000 6:04 PM To: 'Fu, James'; mpls@UU.NET Cc: Jonathan Lang Subject: RE: A new draft. James, I read your draft and I'm afraid you have misunderstood the bi-directional approach of draft-lang-mpls-rsvp-oxc-00.txt (updated and included in draft-generalized-signaling-mpls-00.txt). The process of establishing a bi-directional LSP is the same as the establishment of a unidirectional LSP with the exception that an Upstream Label is added to the Path message. (Incidentally, the flow of the Upstream Label is the same as the normal flow of a Label would be for the upstream segment of a bi-directional LSP, except that we have short-circuited sending the Path message upstream -- see example below). We understand your approach of assigning Upstream Label in the Path message, and assigning Downstream Label in the Resv message. In your approach, the assignment of Upstream Label and the assignment of Downstream Label is not tied together. We think that to support bi-directional LSP, it is important to do pair-wise assignment (or reservations) at the SAME time. This becomes especially important in the transparent pure optical networks where wavelength continuity is required. Contention may occur for the following reasons: 1) If there is a requirement that the input/output ports for the bi-directional path be tied together (e.g., if they must be on the same physical I/O card). Since these are assigned by different OXCs, contention may occur. The scheme that you have proposed will also have this contention scenario. We admit that we did not consider this requirement at the time we wrote the draft. We defines the contention specifically as two OXCs trying to assign labels for the same link. This contention scenario, though, happens much less often than the contention scenario where two OXCs trying to assign labels for the same link 2) If two bi-directional LSPs are attempted to be established simultaneously in opposite directions and there are only enough resources for one of the bi-directional LSPs. In this case, one of the LSPs cannot be established along that path. The scheme that you propose avoids this contention, I assume, by resource checking on the Path message and sending a PathError message to the losing LSP. This is also how it is done in draft-lang-mpls-rsvp-oxc-00.txt. We agree to this assessment. On another note, I think overloading the ResvError message for label allocation is a bad idea. We are not fond of this solution, too. However, this is a better compromised solution at moment compared with that a new LMP has to be used together with the RSVP extensions. . We are open to any good alternatives and suggestions. To summarize, we think that to support bi-directional LSP (OSP), pair-wise label assignment scheme is better than uni -directional label assignment schemes. This becomes especially important to support wavelength continuity requirement in transparent optical networks. We will modify our draft. A new version will come out soon. Regards, Jonathan Example: downstream -----> upstream <----- (1) RSVP-TE used to establish a bi-directional LSP: +-+-+ Path(Label Request) +-+-+ Path(Label Request) +-+-+ Path(LabelRequest) | | ---------------------------> | | ---------------------------> | | ---------------------------> + + Resv(Label) + + Resv(Label) + + Resv(Label) | | <--------------- | | <--------------- | | <---------------- + A + + B + + C + | | Path(Label Request) | | Path(Label Request) | | Path(LabelRequest) + + <--------------------------- + + <-------------------------- + + <------------------------ | | Resv(Label) | | Resv(Label) | | Resv(Label) +-+-+ --------------------------> +-+-+ --------------------------> +-+-+ ------------------------> (2) bi-directional LSP using draft-lang-mpls-rsvp-oxc.txt +-+-+ Path(Label Request, +-+-+ Path(Label Request) +-+-+ Path(LabelRequest) | | UpstreamLabel) | | UpstreamLabel) | | UpstreamLabel) + + ---------------------------> + + ---------------------------> + + ---------------------------> | | | | | | + A + + B + + C + | | Resv(Label) | | Resv(Label) | | Resv(Label) + + <--------------------------- + + <-------------------------- + + <------------------------ | | | | | | +-+-+ +-+-+ +-+-+ -----Original Message----- From: Fu, James [mailto:jfu@sorrentonet.com] Sent: Tuesday, July 18, 2000 9:39 AM To: mpls@UU.NET Subject: A new draft. An Internet Draft entitled "Extensions to RSVP-TE for Bi-directional Optical Path Setup" has been submitted to the IETF. http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt James Fu Sorrento Networks Inc. 9990 Mesa Rim Road San Diego, CA 92121 jfu@sorrentonet.com ------_=_NextPart_001_01BFF1CC.4B1EB960 Content-Type: text/html; charset="iso-8859-1" A new draft.
Jonathan:
 
   Thanks very much for your comments.  We read your draft very carefully. There are a lot of good thoughts and points in your draft.  Please see our response below.
 
 
James Fu, Dan Guo, Raymond Cheng, Leah Zhang 
 
Sorrento Networks Inc.
9990 Mesa Rim Road
San Diego, CA 92121
 
 
 -----Original Message-----
From: Jonathan Lang [mailto:jplang@calient.net]
Sent: Tuesday, July 18, 2000 6:04 PM
To: 'Fu, James'; mpls@UU.NET
Cc: Jonathan Lang
Subject: RE: A new draft.

James,
  I read your draft and I'm afraid you have misunderstood the bi-directional approach of draft-lang-mpls-rsvp-oxc-00.txt (updated and included in draft-generalized-signaling-mpls-00.txt).   The process of establishing a bi-directional LSP is the same as the establishment of a unidirectional LSP with the exception that an Upstream Label is added to the Path message.  (Incidentally, the flow of the Upstream Label is the same as the normal flow of a Label would be for the upstream segment of a bi-directional LSP, except that we have short-circuited sending the Path message upstream -- see example below).

We understand your approach of assigning Upstream Label in the Path message, and assigning Downstream Label in the Resv message.  In your approach, the assignment of Upstream Label and
the assignment of Downstream Label is not tied together. We think that to support bi-directional LSP, it is important to do pair-wise assignment (or reservations) at the SAME time. This becomes especially 
important in the transparent pure optical networks where wavelength continuity is required.  
 

Contention may occur for the following reasons:
1)  If there is a requirement that the input/output ports for the bi-directional path be tied together (e.g., if they must be on the same physical I/O card).  Since these are assigned by different OXCs, contention may occur.  The scheme that you have proposed will also have this contention scenario.
We admit that we did not consider this requirement at the time we wrote the draft. We defines the
contention specifically as two OXCs trying to assign labels for the same link. This contention scenario, though, happens much less often than the contention scenario where two OXCs trying to assign labels for the same link 
 
 
2)  If two bi-directional LSPs are attempted to be established simultaneously in opposite directions and there are only enough resources for one of the bi-directional LSPs.  In this case, one of the LSPs cannot be established along that path.  The scheme that you propose avoids this contention, I assume, by resource checking on the Path message and sending a PathError message to the losing LSP.  This is also how it is done in draft-lang-mpls-rsvp-oxc-00.txt.
We agree to this assessment.
 

On another note, I think overloading the ResvError message for label allocation is a bad idea.
 
We are not fond of this solution, too. However, this is a better compromised solution at moment compared with that a new LMP has to be used together with the RSVP extensions. . We are open to any good alternatives and suggestions.

To summarize, we think that to support bi-directional LSP (OSP), pair-wise label assignment scheme is better  than uni -directional label assignment schemes. This becomes especially important to support
wavelength continuity requirement in transparent optical networks. We will modify our draft. A new version will come out soon.
 
 
Regards,
Jonathan
 
Example:
 
downstream ----->
upstream    <-----
 
(1)  RSVP-TE used to establish a bi-directional LSP:
 
+-+-+  Path(Label Request) +-+-+  Path(Label Request) +-+-+   Path(LabelRequest)
 |     |  --------------------------->  |     |   --------------------------->  |     |     --------------------------->
+    +  Resv(Label)              +    +   Resv(Label)             +    +   Resv(Label)
 |     |  <---------------               |     |  <---------------               |     |  <----------------           
+ A +                                 + B +                                + C + 
 |     |  Path(Label Request)   |     |  Path(Label Request)  |     |   Path(LabelRequest)
+    +  <---------------------------  +    +  <--------------------------  +    +  <------------------------
 |     |  Resv(Label)                |     |     Resv(Label)            |     |      Resv(Label)
+-+-+  -------------------------->   +-+-+    --------------------------> +-+-+  ------------------------>
 
(2)  bi-directional LSP using draft-lang-mpls-rsvp-oxc.txt
 
+-+-+  Path(Label Request, +-+-+  Path(Label Request) +-+-+   Path(LabelRequest)
 |     |         UpstreamLabel)  |     |        UpstreamLabel)   |     |            UpstreamLabel) 
+    +  --------------------------->  +    +  ---------------------------> +    +  ---------------------------> 
 |     |                                  |     |                                  |     |  
+ A +                                 + B +                                + C + 
 |     |  Resv(Label)               |     |  Resv(Label)                |     |   Resv(Label)               
+    +  <---------------------------  +    +  <--------------------------  +    +  <------------------------
 |     |                                  |     |                                  |     |      
+-+-+                                 +-+-+                                +-+-+  
 
-----Original Message-----
From: Fu, James [mailto:jfu@sorrentonet.com]
Sent: Tuesday, July 18, 2000 9:39 AM
To: mpls@UU.NET
Subject: A new draft.

An Internet Draft entitled "Extensions to RSVP-TE for Bi-directional Optical Path Setup" has been submitted to the IETF.

http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt


James Fu
Sorrento Networks Inc.
9990 Mesa Rim Road
San Diego, CA  92121

jfu@sorrentonet.com

------_=_NextPart_001_01BFF1CC.4B1EB960-- From owner-mpls@UU.NET Wed Jul 19 18:39: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 SAA13270 for ; Wed, 19 Jul 2000 18:39:16 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyoo20035; Wed, 19 Jul 2000 22:38:32 GMT Received: by mail-control.mail.uu.net id QQiyoo23630 for mpls-outgoing; Wed, 19 Jul 2000 22:37: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 QQiyoo23616 for ; Wed, 19 Jul 2000 22:37: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 QQiyoo18374 for ; Wed, 19 Jul 2000 18:37:34 -0400 (EDT) Received: from lux.chromisys.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged)) id QQiyoo19367 for ; Wed, 19 Jul 2000 22:37:33 GMT Received: by LUX with Internet Mail Service (5.5.2448.0) id ; Wed, 19 Jul 2000 15:37:33 -0700 Message-ID: <51DA0AB3D747D311832F005004827CC02CE85C@LUX> From: Jonathan Lang To: "'Zhang, Leah'" , Jonathan Lang , "Fu, James" , mpls@UU.NET Cc: Jonathan Lang Subject: RE: A new draft. Date: Wed, 19 Jul 2000 15:37:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF1D1.ED9DD128" 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_01BFF1D1.ED9DD128 Content-Type: text/plain; charset="iso-8859-1" Zhang, The tying together of the upstream and downstream label can be done using the Suggested Label that is also proposed in draft-lang-mpls-rsvp-oxc-00.txt (updated and included in draft-generalized-signaling-mpls-00.txt). -Jonathan -----Original Message----- From: Zhang, Leah [mailto:leahz@sorrentonet.com] Sent: Wednesday, July 19, 2000 2:27 PM To: 'Jonathan Lang'; Fu, James; mpls@UU.NET Subject: RE: A new draft. Jonathan: Thanks very much for your comments. We read your draft very carefully. There are a lot of good thoughts and points in your draft. Please see our response below. James Fu, Dan Guo, Raymond Cheng, Leah Zhang Sorrento Networks Inc. 9990 Mesa Rim Road San Diego, CA 92121 -----Original Message----- From: Jonathan Lang [mailto:jplang@calient.net] Sent: Tuesday, July 18, 2000 6:04 PM To: 'Fu, James'; mpls@UU.NET Cc: Jonathan Lang Subject: RE: A new draft. James, I read your draft and I'm afraid you have misunderstood the bi-directional approach of draft-lang-mpls-rsvp-oxc-00.txt (updated and included in draft-generalized-signaling-mpls-00.txt). The process of establishing a bi-directional LSP is the same as the establishment of a unidirectional LSP with the exception that an Upstream Label is added to the Path message. (Incidentally, the flow of the Upstream Label is the same as the normal flow of a Label would be for the upstream segment of a bi-directional LSP, except that we have short-circuited sending the Path message upstream -- see example below). We understand your approach of assigning Upstream Label in the Path message, and assigning Downstream Label in the Resv message. In your approach, the assignment of Upstream Label and the assignment of Downstream Label is not tied together. We think that to support bi-directional LSP, it is important to do pair-wise assignment (or reservations) at the SAME time. This becomes especially important in the transparent pure optical networks where wavelength continuity is required. Contention may occur for the following reasons: 1) If there is a requirement that the input/output ports for the bi-directional path be tied together (e.g., if they must be on the same physical I/O card). Since these are assigned by different OXCs, contention may occur. The scheme that you have proposed will also have this contention scenario. We admit that we did not consider this requirement at the time we wrote the draft. We defines the contention specifically as two OXCs trying to assign labels for the same link. This contention scenario, though, happens much less often than the contention scenario where two OXCs trying to assign labels for the same link 2) If two bi-directional LSPs are attempted to be established simultaneously in opposite directions and there are only enough resources for one of the bi-directional LSPs. In this case, one of the LSPs cannot be established along that path. The scheme that you propose avoids this contention, I assume, by resource checking on the Path message and sending a PathError message to the losing LSP. This is also how it is done in draft-lang-mpls-rsvp-oxc-00.txt. We agree to this assessment. On another note, I think overloading the ResvError message for label allocation is a bad idea. We are not fond of this solution, too. However, this is a better compromised solution at moment compared with that a new LMP has to be used together with the RSVP extensions. . We are open to any good alternatives and suggestions. To summarize, we think that to support bi-directional LSP (OSP), pair-wise label assignment scheme is better than uni -directional label assignment schemes. This becomes especially important to support wavelength continuity requirement in transparent optical networks. We will modify our draft. A new version will come out soon. Regards, Jonathan Example: downstream -----> upstream <----- (1) RSVP-TE used to establish a bi-directional LSP: +-+-+ Path(Label Request) +-+-+ Path(Label Request) +-+-+ Path(LabelRequest) | | ---------------------------> | | ---------------------------> | | ---------------------------> + + Resv(Label) + + Resv(Label) + + Resv(Label) | | <--------------- | | <--------------- | | <---------------- + A + + B + + C + | | Path(Label Request) | | Path(Label Request) | | Path(LabelRequest) + + <--------------------------- + + <-------------------------- + + <------------------------ | | Resv(Label) | | Resv(Label) | | Resv(Label) +-+-+ --------------------------> +-+-+ --------------------------> +-+-+ ------------------------> (2) bi-directional LSP using draft-lang-mpls-rsvp-oxc.txt +-+-+ Path(Label Request, +-+-+ Path(Label Request) +-+-+ Path(LabelRequest) | | UpstreamLabel) | | UpstreamLabel) | | UpstreamLabel) + + ---------------------------> + + ---------------------------> + + ---------------------------> | | | | | | + A + + B + + C + | | Resv(Label) | | Resv(Label) | | Resv(Label) + + <--------------------------- + + <-------------------------- + + <------------------------ | | | | | | +-+-+ +-+-+ +-+-+ -----Original Message----- From: Fu, James [mailto:jfu@sorrentonet.com] Sent: Tuesday, July 18, 2000 9:39 AM To: mpls@UU.NET Subject: A new draft. An Internet Draft entitled "Extensions to RSVP-TE for Bi-directional Optical Path Setup" has been submitted to the IETF. http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt James Fu Sorrento Networks Inc. 9990 Mesa Rim Road San Diego, CA 92121 jfu@sorrentonet.com ------_=_NextPart_001_01BFF1D1.ED9DD128 Content-Type: text/html; charset="iso-8859-1" A new draft.

Zhang,

The tying together of the upstream and downstream label can be done using the Suggested Label that is also proposed in draft-lang-mpls-rsvp-oxc-00.txt (updated and included in draft-generalized-signaling-mpls-00.txt).

-Jonathan

-----Original Message-----
From: Zhang, Leah [mailto:leahz@sorrentonet.com]
Sent: Wednesday, July 19, 2000 2:27 PM
To: 'Jonathan Lang'; Fu, James; mpls@UU.NET
Subject: RE: A new draft.

Jonathan:
 
   Thanks very much for your comments.  We read your draft very carefully. There are a lot of good thoughts and points in your draft.  Please see our response below.
 
 
James Fu, Dan Guo, Raymond Cheng, Leah Zhang 
 
Sorrento Networks Inc.
9990 Mesa Rim Road
San Diego, CA 92121
 
 
 -----Original Message-----
From: Jonathan Lang [mailto:jplang@calient.net]
Sent: Tuesday, July 18, 2000 6:04 PM
To: 'Fu, James'; mpls@UU.NET
Cc: Jonathan Lang
Subject: RE: A new draft.

James,
  I read your draft and I'm afraid you have misunderstood the bi-directional approach of draft-lang-mpls-rsvp-oxc-00.txt (updated and included in draft-generalized-signaling-mpls-00.txt).   The process of establishing a bi-directional LSP is the same as the establishment of a unidirectional LSP with the exception that an Upstream Label is added to the Path message.  (Incidentally, the flow of the Upstream Label is the same as the normal flow of a Label would be for the upstream segment of a bi-directional LSP, except that we have short-circuited sending the Path message upstream -- see example below).

We understand your approach of assigning Upstream Label in the Path message, and assigning Downstream Label in the Resv message.  In your approach, the assignment of Upstream Label and
the assignment of Downstream Label is not tied together. We think that to support bi-directional LSP, it is important to do pair-wise assignment (or reservations) at the SAME time. This becomes especially 
important in the transparent pure optical networks where wavelength continuity is required.  
 

Contention may occur for the following reasons:
1)  If there is a requirement that the input/output ports for the bi-directional path be tied together (e.g., if they must be on the same physical I/O card).  Since these are assigned by different OXCs, contention may occur.  The scheme that you have proposed will also have this contention scenario.
We admit that we did not consider this requirement at the time we wrote the draft. We defines the
contention specifically as two OXCs trying to assign labels for the same link. This contention scenario, though, happens much less often than the contention scenario where two OXCs trying to assign labels for the same link 
 
 
2)  If two bi-directional LSPs are attempted to be established simultaneously in opposite directions and there are only enough resources for one of the bi-directional LSPs.  In this case, one of the LSPs cannot be established along that path.  The scheme that you propose avoids this contention, I assume, by resource checking on the Path message and sending a PathError message to the losing LSP.  This is also how it is done in draft-lang-mpls-rsvp-oxc-00.txt.
We agree to this assessment.
 

On another note, I think overloading the ResvError message for label allocation is a bad idea.
 
We are not fond of this solution, too. However, this is a better compromised solution at moment compared with that a new LMP has to be used together with the RSVP extensions. . We are open to any good alternatives and suggestions.

To summarize, we think that to support bi-directional LSP (OSP), pair-wise label assignment scheme is better  than uni -directional label assignment schemes. This becomes especially important to support
wavelength continuity requirement in transparent optical networks. We will modify our draft. A new version will come out soon.
 
 
Regards,
Jonathan
 
Example:
 
downstream ----->
upstream    <-----
 
(1)  RSVP-TE used to establish a bi-directional LSP:
 
+-+-+  Path(Label Request) +-+-+  Path(Label Request) +-+-+   Path(LabelRequest)
 |     |  --------------------------->  |     |   --------------------------->  |     |     --------------------------->
+    +  Resv(Label)              +    +   Resv(Label)             +    +   Resv(Label)
 |     |  <---------------               |     |  <---------------               |     |  <----------------           
+ A +                                 + B +                                + C + 
 |     |  Path(Label Request)   |     |  Path(Label Request)  |     |   Path(LabelRequest)
+    +  <---------------------------  +    +  <--------------------------  +    +  <------------------------
 |     |  Resv(Label)                |     |     Resv(Label)            |     |      Resv(Label)
+-+-+  -------------------------->   +-+-+    --------------------------> +-+-+  ------------------------>
 
(2)  bi-directional LSP using draft-lang-mpls-rsvp-oxc.txt
 
+-+-+  Path(Label Request, +-+-+  Path(Label Request) +-+-+   Path(LabelRequest)
 |     |         UpstreamLabel)  |     |        UpstreamLabel)   |     |            UpstreamLabel) 
+    +  --------------------------->  +    +  ---------------------------> +    +  ---------------------------> 
 |     |                                  |     |                                  |     |  
+ A +                                 + B +                                + C + 
 |     |  Resv(Label)               |     |  Resv(Label)                |     |   Resv(Label)               
+    +  <---------------------------  +    +  <--------------------------  +    +  <------------------------
 |     |                                  |     |                                  |     |      
+-+-+                                 +-+-+                                +-+-+  
 
-----Original Message-----
From: Fu, James [mailto:jfu@sorrentonet.com]
Sent: Tuesday, July 18, 2000 9:39 AM
To: mpls@UU.NET
Subject: A new draft.

An Internet Draft entitled "Extensions to RSVP-TE for Bi-directional Optical Path Setup" has been submitted to the IETF.

http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt


James Fu
Sorrento Networks Inc.
9990 Mesa Rim Road
San Diego, CA  92121

jfu@sorrentonet.com

------_=_NextPart_001_01BFF1D1.ED9DD128-- From owner-mpls@UU.NET Thu Jul 20 00:15: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 AAA10730 for ; Thu, 20 Jul 2000 00:15:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiypk25264; Thu, 20 Jul 2000 04:14:42 GMT Received: by mail-control.mail.uu.net id QQiypk21766 for mpls-outgoing; Thu, 20 Jul 2000 04:14: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 QQiypk21757 for ; Thu, 20 Jul 2000 04:14:23 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiypk01419 for ; Thu, 20 Jul 2000 00:14:04 -0400 (EDT) Received: from mlsw00103.microlandsw.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQiypk00748 for ; Thu, 20 Jul 2000 04:13:32 GMT Received: by MLSW00103 with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Jul 2000 09:49:08 +0530 Message-ID: From: Malathi Sitaraman To: "'erosen@cisco.com'" , Lou Berger Cc: Eric Gray , "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" Subject: RE: Process has been circumvented again Date: Thu, 20 Jul 2000 09:49:08 +0530 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 would like to have all the names & email ids in the MPLS mailing list . Is it possible ? Rgds, Malathi Malathi, Microland, 309/3, J.P Complex, 5th Block, Koramangla, Bangalore - 95 Phone no.s - 5084659 / 61/ 62 email : malathis@microlandsw.com > -----Original Message----- > From: Eric Rosen [SMTP:erosen@cisco.com] > Sent: Wednesday, July 19, 2000 4:01 PM > To: Lou Berger > Cc: Eric Gray; George Swallow (E-mail); 'Vijay Srinivasan'; MPLS Mailing > List (E-mail) > Subject: Re: Process has been circumvented again > > > I wasn't in Adelaide so I can't comment on what might have happened > there. > But I would be interested in knowing why MPLS header compression is > deemed > useful. > > Header compression is generally used only on lower speed links. Are > you > envisioning the use of MPLS for traffic engineering on low-speed links, > or > are you worried about supporting VPNs over a low-speed backbone? From owner-mpls@UU.NET Thu Jul 20 00:16: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 AAA11077 for ; Thu, 20 Jul 2000 00:16:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiypl02814; Thu, 20 Jul 2000 04:15:35 GMT Received: by mail-control.mail.uu.net id QQiypl21971 for mpls-outgoing; Thu, 20 Jul 2000 04:15: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 QQiypl21942 for ; Thu, 20 Jul 2000 04:15: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 QQiypk01461 for ; Thu, 20 Jul 2000 00:14:53 -0400 (EDT) Received: from mlsw00103.microlandsw.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQiypk01676 for ; Thu, 20 Jul 2000 04:14:36 GMT Received: by MLSW00103 with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Jul 2000 09:50:04 +0530 Message-ID: From: Malathi Sitaraman To: "'Jay Wang'" , "'jshen@cad.zju.edu.cn'" , MPLS list Subject: RE: MPLS and traffic shaping: Date: Thu, 20 Jul 2000 09:50:03 +0530 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 would like to have the names & email ids of all those registered in the MPLS mailing list. Is it possible ? Rgds, Malathi Malathi, Microland, 309/3, J.P Complex, 5th Block, Koramangla, Bangalore - 95 Phone no.s - 5084659 / 61/ 62 email : malathis@microlandsw.com > -----Original Message----- > From: Jay Wang [SMTP:jawang@cosinecom.com] > Sent: Wednesday, July 19, 2000 2:27 PM > To: 'jshen@cad.zju.edu.cn'; MPLS list > Subject: RE: MPLS and traffic shaping: > > James, > > You probabily will find more information on Traffic Conditioning, > or just Traffic Shaping under Diffserv WG. The following > documents are good starting points: > > RFC 2475, 2697, 2698, and ID draft-ietf-diffserv-model-03 > > - Jay Wang > > > -----Original Message----- > > From: jing shen [mailto:jshen@cad.zju.edu.cn] > > Sent: Wednesday, July 19, 2000 5:42 AM > > To: MPLS list > > Subject: MPLS and traffic shaping: > > > > > > Hi: > > > > I'm a newcomer of MPLS and now reading doc from IETF. > > I want to know , is there any mechanism provided by MPLS on > > conditioning > > traffic > > through LSR? ( as that provided by ATM) > > > > james shen > > From owner-mpls@UU.NET Thu Jul 20 00:33: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 AAA18303 for ; Thu, 20 Jul 2000 00:33:34 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiypm20834; Thu, 20 Jul 2000 04:33:06 GMT Received: by mail-control.mail.uu.net id QQiypm22977 for mpls-outgoing; Thu, 20 Jul 2000 04:32: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 QQiypm22972 for ; Thu, 20 Jul 2000 04:32: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 QQiypm29310 for ; Thu, 20 Jul 2000 00:32:35 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiypm06262 for ; Thu, 20 Jul 2000 04:32:20 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id AAA17201 for mpls@uu.net; Thu, 20 Jul 2000 00:32:19 -0400 (EDT) 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 QQiypm22959 for ; Thu, 20 Jul 2000 04:32: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 QQiypm29259 for ; Thu, 20 Jul 2000 00:31:51 -0400 (EDT) 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 QQiypm05998 for ; Thu, 20 Jul 2000 04:31:51 GMT Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id VAA04746; Wed, 19 Jul 2000 21:31:36 -0700 (PDT) Message-ID: <39768173.A33F05F3@cisco.com> Date: Wed, 19 Jul 2000 21:34:59 -0700 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Malathi Sitaraman CC: mpls@UU.NET Subject: Re: Process has been circumvented again References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > I would like to have all the names & email ids in the MPLS mailing list . And how much recruters are giving you for one entry these days :) ? > Is it possible ? Sure, but you need to brake into UUNET's listserver first. I don't think anybody will just zip and mail the subscribers list to you. R. > Malathi Sitaraman wrote: > > Hi, > I would like to have all the names & email ids in the MPLS mailing list . Is > it possible ? > > Rgds, > Malathi > > Malathi, > Microland, > 309/3, J.P Complex, > 5th Block, Koramangla, > Bangalore - 95 > Phone no.s - 5084659 / 61/ 62 > > email : malathis@microlandsw.com From owner-mpls@UU.NET Thu Jul 20 01:14: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 BAA05185 for ; Thu, 20 Jul 2000 01:14:45 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiypo01069; Thu, 20 Jul 2000 05:14:18 GMT Received: by mail-control.mail.uu.net id QQiypo06056 for mpls-outgoing; Thu, 20 Jul 2000 05:13: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 QQiypo06049 for ; Thu, 20 Jul 2000 05:13: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 QQiypo07070 for ; Thu, 20 Jul 2000 01:13:25 -0400 (EDT) Received: from sasi.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2] (may be forged)) id QQiypo23620 for ; Thu, 20 Jul 2000 05:12:57 GMT Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id KAA19250 for ; Thu, 20 Jul 2000 10:42:46 +0530 (IST) Received: from pcd75.sasi.com ([10.0.16.75]) by sasi.com; Thu, 20 Jul 2000 10:42:43 +0000 (IST) Received: from localhost (gbnaidu@localhost) by pcd75.sasi.com (8.9.3/8.9.3) with ESMTP id KAA02832; Thu, 20 Jul 2000 10:39:52 +0530 Date: Thu, 20 Jul 2000 10:39:52 +0530 (IST) From: "G.B.Naidu" To: Malathi Sitaraman cc: "'Jay Wang'" , "'jshen@cad.zju.edu.cn'" , MPLS list Subject: RE: MPLS and traffic shaping: In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can we know why do you want to the individual email addresses of all the mailing liste people? If you have some questions relateed to MPLS, post it on the mailing list so that it will be useful for everyone. This list is for MPLS discussion. what do others say? thanks --gb On Thu, 20 Jul 2000, Malathi Sitaraman wrote: > Hi, > I would like to have the names & email ids of all those registered in the > MPLS mailing list. Is it possible ? > > Rgds, > Malathi > > > Malathi, > Microland, > 309/3, J.P Complex, > 5th Block, Koramangla, > Bangalore - 95 > Phone no.s - 5084659 / 61/ 62 > > email : malathis@microlandsw.com > > > > > > > -----Original Message----- > > From: Jay Wang [SMTP:jawang@cosinecom.com] > > Sent: Wednesday, July 19, 2000 2:27 PM > > To: 'jshen@cad.zju.edu.cn'; MPLS list > > Subject: RE: MPLS and traffic shaping: > > > > James, > > > > You probabily will find more information on Traffic Conditioning, > > or just Traffic Shaping under Diffserv WG. The following > > documents are good starting points: > > > > RFC 2475, 2697, 2698, and ID draft-ietf-diffserv-model-03 > > > > - Jay Wang > > > > > -----Original Message----- > > > From: jing shen [mailto:jshen@cad.zju.edu.cn] > > > Sent: Wednesday, July 19, 2000 5:42 AM > > > To: MPLS list > > > Subject: MPLS and traffic shaping: > > > > > > > > > Hi: > > > > > > I'm a newcomer of MPLS and now reading doc from IETF. > > > I want to know , is there any mechanism provided by MPLS on > > > conditioning > > > traffic > > > through LSR? ( as that provided by ATM) > > > > > > james shen > > > > -- Never trust an operating system you don't have sources for. ;-) From owner-mpls@UU.NET Thu Jul 20 01:29: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 BAA14927 for ; Thu, 20 Jul 2000 01:29:22 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiypp11236; Thu, 20 Jul 2000 05:28:58 GMT Received: by mail-control.mail.uu.net id QQiypp07076 for mpls-outgoing; Thu, 20 Jul 2000 05:28:39 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 QQiypp07071 for ; Thu, 20 Jul 2000 05:28: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 QQiypp04961 for ; Thu, 20 Jul 2000 01:28:30 -0400 (EDT) Received: from quantuminc.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: www.quantuminc.com [198.109.164.99]) id QQiypp03601 for ; Thu, 20 Jul 2000 05:28:30 GMT Received: (qmail 66117 invoked by uid 7791); 20 Jul 2000 05:28:30 -0000 Received: from unknown (HELO cse.msu.edu) (100.1.1.67) by 100.1.1.111 with SMTP; 20 Jul 2000 05:28:30 -0000 Message-ID: <39768D5C.7F7A4654@cse.msu.edu> Date: Thu, 20 Jul 2000 01:25:48 -0400 From: Vasu Vuppala Organization: QCI X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: raszuk@cisco.com CC: mpls@UU.NET Subject: Re: Process has been circumvented again Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Robert, --- Robert Raszuk wrote: > > > I would like to have all the names & email ids in the MPLS > mailing list . > > And how much recruters are giving you for one entry these days :) ? :-) :-) > > Is it possible ? > > Sure, but you need to brake into UUNET's listserver first. I don't > think > anybody will just zip and mail the subscribers list to you. well, you do not need to break into anything; you just need to know the right majordomo command. However, Malathi, please do not ask me about it :-) - vasu From owner-mpls@UU.NET Thu Jul 20 01:32: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 BAA17091 for ; Thu, 20 Jul 2000 01:32:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiypq07797; Thu, 20 Jul 2000 05:32:09 GMT Received: by mail-control.mail.uu.net id QQiypq07298 for mpls-outgoing; Thu, 20 Jul 2000 05:31: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 QQiypq07289 for ; Thu, 20 Jul 2000 05:31: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 QQiypq09040 for ; Thu, 20 Jul 2000 01:31:28 -0400 (EDT) Received: from sasi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasi.com.56.164.164.in-addr.arpa [164.164.56.2] (may be forged)) id QQiypq13261 for ; Thu, 20 Jul 2000 05:31:00 GMT Received: from samar (sasi.com [164.164.56.2]) by sasi.com (8.9.3/8.9.3) with SMTP id LAA21275 for ; Thu, 20 Jul 2000 11:00:53 +0530 (IST) Received: from pcd75.sasi.com ([10.0.16.75]) by sasi.com; Thu, 20 Jul 2000 11:00:52 +0000 (IST) Received: from localhost (gbnaidu@localhost) by pcd75.sasi.com (8.9.3/8.9.3) with ESMTP id LAA02847; Thu, 20 Jul 2000 11:00:36 +0530 Date: Thu, 20 Jul 2000 11:00:35 +0530 (IST) From: "G.B.Naidu" To: "James R. Leu" cc: Chatur sharp , mpls@UU.NET Subject: Re: your mail In-Reply-To: <20000719100929.A906@laurelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hey, What is this LPM Chatur is referring to? --gb On Wed, 19 Jul 2000, James R. Leu wrote: > Comment below: > > On Wed, Jul 19, 2000 at 06:51:50AM -0700, Chatur sharp wrote: > > Hi folks, > > > > I have a very simple querry. > > > > Consider the scenerio given below > > > > L1 L2 > > LSR1 ---- LSR2----LSR3 > > > > > > The LSR1 and LSR3 are the ingress and egress > > respectively for an LSP for FEC F. > > > > Now when LSR1 gets an unlabelled packet, such that > > it maps to FEC F then it will label the packet with > > a label L1 and forward it LSR2 who will in turn > > forward it to LSR3 with label L2. (LSR2 will swap L1 > > with L2) > > > > > > Now should will LSR3 do an LPM to determine the > > interface through which it must forward the packet ? > > > > Can it be avoided by choosing appropriate label L2 ? > > > > In general, is it always necassary to do LPM at > > the egress LSR. ( Assuming no PHP ) ? Put differently > > at the end of a LSP, what is generally done - LPM, > > or a direct forwarding based on the incoming label. > > > > Is there any other forum where I can ask this > > question. > > Being that LSR3 allocated the label L2 it can attach whatever > meaning it wants to L2. It all depends on the qualities of the FEC F, > the granularity of the label allocation scheme, and how these are tied > together in the forwarding plan. > > Jim > -- Never trust an operating system you don't have sources for. ;-) From owner-mpls@UU.NET Thu Jul 20 03:36:04 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20271 for ; Thu, 20 Jul 2000 03:36:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiypy06204; Thu, 20 Jul 2000 07:35:30 GMT Received: by mail-control.mail.uu.net id QQiypy06129 for mpls-outgoing; Thu, 20 Jul 2000 07:35: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 QQiypy06121 for ; Thu, 20 Jul 2000 07:35: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 QQiypy18516 for ; Thu, 20 Jul 2000 03:34:55 -0400 (EDT) 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 QQiypy24615 for ; Thu, 20 Jul 2000 07:34:55 GMT Received: by MILES with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Jul 2000 08:34:48 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2A3277@monk.datcon.co.uk> From: Adrian Farrel To: erosen@cisco.com, Lou Berger Cc: Eric Gray , "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" Subject: RE: Process has been circumvented again Date: Thu, 20 Jul 2000 08:34:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Eric, Lou will have a definitive answer, but I think it is most interesting in the VoMPLS world where each packet may be small (16 byte?) and the headers (IP, RTP, MPLS) become very significant. Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Eric Rosen [mailto:erosen@cisco.com] >Sent: Wednesday, July 19, 2000 10:01 PM >To: Lou Berger >Cc: Eric Gray; George Swallow (E-mail); 'Vijay Srinivasan'; >MPLS Mailing >List (E-mail) >Subject: Re: Process has been circumvented again > > > >I wasn't in Adelaide so I can't comment on what might have >happened there. >But I would be interested in knowing why MPLS header >compression is deemed >useful. > >Header compression is generally used only on lower speed >links. Are you >envisioning the use of MPLS for traffic engineering on >low-speed links, or >are you worried about supporting VPNs over a low-speed backbone? > From owner-mpls@UU.NET Thu Jul 20 04:27: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 EAA12294 for ; Thu, 20 Jul 2000 04:27:51 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyqb01929; Thu, 20 Jul 2000 08:27:29 GMT Received: by mail-control.mail.uu.net id QQiyqb20416 for mpls-outgoing; Thu, 20 Jul 2000 08:26: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 QQiyqb20394 for ; Thu, 20 Jul 2000 08:26: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 QQiyqb23647 for ; Thu, 20 Jul 2000 04:26:39 -0400 (EDT) Received: from daewoo.dti.daewoo.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQiyqb00636 for ; Thu, 20 Jul 2000 08:26:24 GMT Received: from daewoo.dti.daewoo.co.kr (neetu [165.133.13.17]) by daewoo.dti.daewoo.co.kr (8.8.8+Sun/8.8.8) with ESMTP id NAA29632 for ; Thu, 20 Jul 2000 13:50:57 -0600 (GMT) Message-ID: <3976B7F4.AB08ADDF@daewoo.dti.daewoo.co.kr> Date: Thu, 20 Jul 2000 13:57:32 +0530 From: Neetu Gupta Reply-To: neetug@daewoo.dti.daewoo.co.kr Organization: Daewoo Telecom X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: mpls@UU.NET Subject: Calculation of Fixed Delay Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I've a question regarding computation of Fixed Delay. For providing QoS, we need end to end latency along the path over which LSP is to be created. Latency includes both fixed and Variable delay. Fixed Delay at a particular node can be set in Minimum Path Latency Field in Adspec object of RSVP Path Message. Fixed delay includes both processing and propagation delay. Suppose MPLS is on ATM, we can get processing delay (of ATM Header and Segmentation and Ressembly ) from the ATM Switch. My question is : How do we calculate the delay in MPLS related processing and propagation delay? By MPLS related processing, I mean the processing at Ingress LER which will do forwarding of unlabelled packet which comes in. There could be requriement for Fragementation also if the MTU sizes don't conform to our requirement. It is also stated in drafts that propagation delay is neglegible as compared to processing delay. But if I wish to include it in my latency calculation then is there any method to do so. Thanx in advance. -neetu From owner-mpls@UU.NET Thu Jul 20 06:57: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 GAA18076 for ; Thu, 20 Jul 2000 06:57:48 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyql13991; Thu, 20 Jul 2000 10:57:09 GMT Received: by mail-control.mail.uu.net id QQiyql20438 for mpls-outgoing; Thu, 20 Jul 2000 10:56:50 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 QQiyql20433 for ; Thu, 20 Jul 2000 10:56:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyql10429 for ; Thu, 20 Jul 2000 06:56:23 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyql13131 for ; Thu, 20 Jul 2000 10:56:23 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA05539 for mpls@uu.net; Thu, 20 Jul 2000 06:56:22 -0400 (EDT) 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 QQiyql20072 for ; Thu, 20 Jul 2000 10:46: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 QQiyql09564 for ; Thu, 20 Jul 2000 06:46:38 -0400 (EDT) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQiyql19725 for ; Thu, 20 Jul 2000 10:46:37 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11855; Thu, 20 Jul 2000 06:46:36 -0400 (EDT) Message-Id: <200007201046.GAA11855@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-te-feed-01.txt Date: Thu, 20 Jul 2000 06:46:36 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : IMPROVING TOPOLOGY DATA BASE ACCURACY WITH LSP FEEDBACK Author(s) : P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki Filename : draft-ietf-mpls-te-feed-01.txt Pages : 12 Date : 19-Jul-00 One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a set of constraints which those links can meet. Bandwidth, for example, is one essential constraint. Since the bandwidth available changes as new LSPs are established and terminated the topology database will develop inconsistencies with respect to the real network. It is not possible to increase the flooding rates arbitrarily to keep the database discrepancies from growing. We propose a new mechanism whereby a source node can learn about the successes or failures of its path selections by receiving feedback from the paths it is attempting. This fed-back information can be incorporated into subsequent route computations, which greatly improves the accuracy of the overall routing solution by significantly reducing the database discrepancies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-te-feed-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-te-feed-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000719141502.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-te-feed-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-te-feed-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000719141502.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Jul 20 07:57: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 HAA19792 for ; Thu, 20 Jul 2000 07:57:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyqp24584; Thu, 20 Jul 2000 11:55:41 GMT Received: by mail-control.mail.uu.net id QQiyqp04918 for mpls-outgoing; Thu, 20 Jul 2000 11:55:10 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiyqp04902 for ; Thu, 20 Jul 2000 11:54:51 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyqp15078 for ; Thu, 20 Jul 2000 07:54:49 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyqp23142 for ; Thu, 20 Jul 2000 11:54:34 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id GAA11271; Thu, 20 Jul 2000 06:54:18 -0500 Message-Id: <4.3.2.7.2.20000720073335.00d85100@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 07:54:20 -0400 To: erosen@cisco.com From: Lou Berger Subject: Re: Process has been circumvented again Cc: Lou Berger , Eric Gray , "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" In-Reply-To: <200007192101.RAA19574@erosen-sun.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk It's intended to enable the use of MPLS (in general) on lower speed links for applications where minimizing overhead is required. In the described scheme MPLS/IP/UDP/RTP headers can be compressed down to 2 or 4 bytes. There was also another scheme presented in Adelaide. IMO both make sense, as the two schemes are useful in different parts of a network. For some reason the slides from our (and all other) presentations didn't make it into the proceedings. If interested, I've posted them at http://www.labn.net/lberger/docs/cmpls-0003.pdf Lou At 05:01 PM 7/19/00 -0400, Eric Rosen wrote: >I wasn't in Adelaide so I can't comment on what might have happened there. >But I would be interested in knowing why MPLS header compression is deemed >useful. > >Header compression is generally used only on lower speed links. Are you >envisioning the use of MPLS for traffic engineering on low-speed links, or >are you worried about supporting VPNs over a low-speed backbone? From owner-mpls@UU.NET Thu Jul 20 08:22: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 IAA02030 for ; Thu, 20 Jul 2000 08:22:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyqr26673; Thu, 20 Jul 2000 12:21:44 GMT Received: by mail-control.mail.uu.net id QQiyqr18044 for mpls-outgoing; Thu, 20 Jul 2000 12:21: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 QQiyqr18034 for ; Thu, 20 Jul 2000 12:21: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 QQiyqr18211 for ; Thu, 20 Jul 2000 08:20:33 -0400 (EDT) Received: from mailrelay.laurelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laurelnetworks.com [206.67.234.84]) id QQiyqr22701 for ; Thu, 20 Jul 2000 12:20:17 GMT Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id IAA03514; Thu, 20 Jul 2000 08:20:16 -0400 Received: (from jleu@localhost) by localhost.laurelnetworks.com (8.9.3/8.9.3) id IAA00878; Thu, 20 Jul 2000 08:20:15 -0400 Date: Thu, 20 Jul 2000 08:20:15 -0400 From: "James R. Leu" To: "G.B.Naidu" Cc: mpls@UU.NET Subject: Re: your mail Message-ID: <20000720082015.A873@laurelnetworks.com> Reply-To: jleu@laurelnetworks.com References: <20000719100929.A906@laurelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from gbnaidu@sasi.com on Thu, Jul 20, 2000 at 11:00:35AM +0530 Organization: Laurel Networks Sender: owner-mpls@UU.NET Precedence: bulk On Thu, Jul 20, 2000 at 11:00:35AM +0530, G.B.Naidu wrote: > > Hey, > > What is this LPM Chatur is referring to? Longest Prefix Match. > > --gb > > On Wed, 19 Jul 2000, James R. Leu wrote: > > > Comment below: > > > > On Wed, Jul 19, 2000 at 06:51:50AM -0700, Chatur sharp wrote: > > > Hi folks, > > > > > > I have a very simple querry. > > > > > > Consider the scenerio given below > > > > > > L1 L2 > > > LSR1 ---- LSR2----LSR3 > > > > > > > > > The LSR1 and LSR3 are the ingress and egress > > > respectively for an LSP for FEC F. > > > > > > Now when LSR1 gets an unlabelled packet, such that > > > it maps to FEC F then it will label the packet with > > > a label L1 and forward it LSR2 who will in turn > > > forward it to LSR3 with label L2. (LSR2 will swap L1 > > > with L2) > > > > > > > > > Now should will LSR3 do an LPM to determine the > > > interface through which it must forward the packet ? > > > > > > Can it be avoided by choosing appropriate label L2 ? > > > > > > In general, is it always necassary to do LPM at > > > the egress LSR. ( Assuming no PHP ) ? Put differently > > > at the end of a LSP, what is generally done - LPM, > > > or a direct forwarding based on the incoming label. > > > > > > Is there any other forum where I can ask this > > > question. > > > > Being that LSR3 allocated the label L2 it can attach whatever > > meaning it wants to L2. It all depends on the qualities of the FEC F, > > the granularity of the label allocation scheme, and how these are tied > > together in the forwarding plan. > > > > Jim > > > > -- > Never trust an operating system you don't have sources for. ;-) -- James R. Leu Software Engineer Laurel Networks, Inc jleu@laurelnetworks.com From owner-mpls@UU.NET Thu Jul 20 08:55: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 IAA19087 for ; Thu, 20 Jul 2000 08:55:14 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyqt01956; Thu, 20 Jul 2000 12:54:13 GMT Received: by mail-control.mail.uu.net id QQiyqt21050 for mpls-outgoing; Thu, 20 Jul 2000 12:53: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 QQiyqt21037 for ; Thu, 20 Jul 2000 12:53: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 QQiyqt24633 for ; Thu, 20 Jul 2000 08:53:24 -0400 (EDT) From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQiyqt19931 for ; Thu, 20 Jul 2000 12:53:22 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id VAA05359 for ; Thu, 20 Jul 2000 21:54:07 +0900 (KST) X-OpenMail-Hops: 3 Date: Thu, 20 Jul 2000 21:55:28 +0900 Message-Id: Subject: mpls-ethernet MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Thu, 20 Jul 2000 21:52:28 +0900" ;Modification-Date="Thu, 20 Jul 2000 21:55:23 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Which draft/RFC I need to refer for mpls with ethernet (like ATM,FR). regards seenu From owner-mpls@UU.NET Thu Jul 20 09:04: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 JAA23863 for ; Thu, 20 Jul 2000 09:04:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyqu13011; Thu, 20 Jul 2000 13:03:40 GMT Received: by mail-control.mail.uu.net id QQiyqu24734 for mpls-outgoing; Thu, 20 Jul 2000 13:03: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 QQiyqu24507 for ; Thu, 20 Jul 2000 13:02: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 QQiyqu26037 for ; Thu, 20 Jul 2000 09:02:47 -0400 (EDT) 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 QQiyqu11677 for ; Thu, 20 Jul 2000 13:02:31 GMT Received: from console (arni.netlabs.net [216.116.143.247]) by www.netlabs.net (8.9.3/8.9.3) with SMTP id JAA22626; Thu, 20 Jul 2000 09:01:48 -0400 (EDT) Message-ID: <002001bff24b$32a92c80$0a01a8c0@itl.ispsoft.com> From: "Arni Raghu" To: , References: Subject: Re: mpls-ethernet Date: Thu, 20 Jul 2000 09:05:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit http://shika.aist-nara.ac.jp/member/nori-d/mlr/id/draft-rosen-mpls-lan-encap s-00.txt hth, A ----- Original Message ----- From: To: Sent: Thursday, July 20, 2000 8:55 AM Subject: mpls-ethernet > Hi, > > Which draft/RFC I need to refer for mpls with ethernet (like ATM,FR). > > regards > seenu > From owner-mpls@UU.NET Thu Jul 20 09:55: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 JAA21106 for ; Thu, 20 Jul 2000 09:55:21 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyqx04824; Thu, 20 Jul 2000 13:53:58 GMT Received: by mail-control.mail.uu.net id QQiyqx08638 for mpls-outgoing; Thu, 20 Jul 2000 13:53:33 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiyqx08633 for ; Thu, 20 Jul 2000 13:53: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 QQiyqx02424 for ; Thu, 20 Jul 2000 09:53:21 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiyqx04200 for ; Thu, 20 Jul 2000 13:53:21 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA04973 for ; Thu, 20 Jul 2000 06:53:34 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA21970 for mpls@uu.net; Thu, 20 Jul 2000 09:53:19 -0400 (EDT) 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 QQiyok05675 for ; Wed, 19 Jul 2000 21:36: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 QQiyok09952 for ; Wed, 19 Jul 2000 17:36:42 -0400 (EDT) From: Spencer.Giacalone@predictive.com Received: from athena.predictive.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: athena.predictive.com [208.209.197.197]) id QQiyok05673 for ; Wed, 19 Jul 2000 21:36:41 GMT To: mpls@UU.NET Subject: new ID X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000 Message-ID: Date: Mon, 19 Jun 2000 17:37:50 -0400 X-MIMETrack: Serialize by Router on Athena/Predictive(Release 5.0.4 |June 8, 2000) at 07/19/2000 05:37:58 PM, Serialize complete at 07/19/2000 05:37:58 PM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk FYI: A new draft has been posted at http://www.ietf.org/internet-drafts/draft-giacalone-te-optical-next-00.txt A description is as: Abstract This memo defines extensions to OSPFv3 [2] to provide support for Network Engineering. This set of extensions is termed Network Engineering eXTensions for OSPFv3, or NEXT. The term network engineering was chosen to impart NEXT's wide scope of functionality. NEXT is intended to provide holistic and extremely rich state information to OSPFv3 routers. Using this information, various advanced topological and administrative decisions can be made. Please send comments to ospf@discuss.microsoft.com. Overview This document details extensions to OSPFv3 [2] called NEXT. NEXT can be used to add very granular network engineering capabilities to OSPFv3 networks. To accomplish this, NEXT provides a wealth of interface, link, and device capability and state information to OSPFv3, or other protocols. The intent of NEXT is to enable the selection of shortest paths through networks based on sets of advanced network state criteria. Using NEXT, advanced policy decisions can be made, and traffic can be routed or switch traffic with varying qualities of service. NEXT can also assist in building complex fault tolerant networks. NEXT aims to provide a system of unified network state information to satisfy the requirements of numerous existing and developmental protocols. While NEXT builds on functionality presented in other works, it adds many new features, presents new philosophical possibilities, and is intended for use with OSPFv3. NEXT focuses on traffic engineering (TE) [3,4] and Multi Protocol lambda Switching (MPLmS) [5,6], and Protection Wavelength Routing, but is specifically intended to support changing requirements and technologies in the future. A core philosophical premise of NEXT is that it may effect the core topology building process of OSPFv3, or may be used to build separate "shadow" topologies. In the former, NEXT can be used a basis to make sophisticated decisions within OSPFv3. In the later, OSPFv3/NEXT can serve to build repositories of detailed information to enhance supplementary protocols. NEXT supports advanced intra-area and inter-area routing. Since NEXT operates with and depends on OSPFv3, which is essentially network protocol independent, NEXT can be used to enable all networks to become extensively self aware. It is hoped that NEXT will become a focal point for the distribution of advanced network information, enhancing OSPFv3 (and other protocols) while enabling complex deterministic services to be implemented. -spence From owner-mpls@UU.NET Thu Jul 20 10:06: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 KAA27517 for ; Thu, 20 Jul 2000 10:06:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyqy13521; Thu, 20 Jul 2000 14:04:58 GMT Received: by mail-control.mail.uu.net id QQiyqy13583 for mpls-outgoing; Thu, 20 Jul 2000 14:04: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 QQiyqy13544 for ; Thu, 20 Jul 2000 14:04: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 QQiyqy04283 for ; Thu, 20 Jul 2000 10:04:16 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiyqy12570 for ; Thu, 20 Jul 2000 14:03:46 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA12936; Thu, 20 Jul 2000 07:03:58 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA22046; Thu, 20 Jul 2000 10:03:44 -0400 (EDT) Message-Id: <200007201403.KAA22046@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: seenu@samsung.co.kr cc: mpls@UU.NET Subject: Re: mpls-ethernet In-reply-to: Your message of Thu, 20 Jul 2000 21:55:28 +0900. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 20 Jul 2000 10:03:43 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk seenu> Which draft/RFC I need to refer for mpls with ethernet (like seenu> ATM,FR). Correct answer is draft-ietf-mpls-label-encaps-07.txt. From owner-mpls@UU.NET Thu Jul 20 10:16:39 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03543 for ; Thu, 20 Jul 2000 10:16:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyqz17168; Thu, 20 Jul 2000 14:15:44 GMT Received: by mail-control.mail.uu.net id QQiyqy20516 for mpls-outgoing; Thu, 20 Jul 2000 14:14: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 QQiyqy20484 for ; Thu, 20 Jul 2000 14:14: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 QQiyqy06113 for ; Thu, 20 Jul 2000 10:14:24 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQiyqy15651 for ; Thu, 20 Jul 2000 14:14:24 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA03052; Thu, 20 Jul 2000 07:14:38 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA22077; Thu, 20 Jul 2000 10:14:22 -0400 (EDT) Message-Id: <200007201414.KAA22077@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Lou Berger , Adrian Farrel cc: Eric Gray , "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" Subject: Re: IP header compression (was "process") In-reply-to: Your message of Thu, 20 Jul 2000 07:54:20 -0400. <4.3.2.7.2.20000720073335.00d85100@mail.labn.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 20 Jul 2000 10:14:22 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Lou> It's intended to enable the use of MPLS (in general) on lower speed Lou> links for applications where minimizing overhead is required. I think that discussion of these drafts should be deferred until someone shows that there is an application which requires that MPLS be run on lower speed links. Adrian> Lou will have a definitive answer Well, I guess not ;-) Adrian> I think it is most interesting in the VoMPLS world where each packet Adrian> may be small (16 byte?) and the headers (IP, RTP, MPLS) become very Adrian> significant. Perhaps. But one needs the confluence of VoIP, MPLS, and low-speed links to make this useful. If we're going to consider putting something on the standards track, I think we should better understand whether it is really needed. From owner-mpls@UU.NET Thu Jul 20 10:21: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 KAA05940 for ; Thu, 20 Jul 2000 10:21:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyqz26065; Thu, 20 Jul 2000 14:20:28 GMT Received: by mail-control.mail.uu.net id QQiyqz21080 for mpls-outgoing; Thu, 20 Jul 2000 14:19: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 QQiyqz21071 for ; Thu, 20 Jul 2000 14:19: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 QQiyqz07081 for ; Thu, 20 Jul 2000 10:19:36 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQiyqz22019 for ; Thu, 20 Jul 2000 14:19:20 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA06580 for ; Thu, 20 Jul 2000 07:19:35 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA22108 for mpls@uu.net; Thu, 20 Jul 2000 10:19:18 -0400 (EDT) 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 QQiyqz20967 for ; Thu, 20 Jul 2000 14:17:10 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyqz08593 for ; Thu, 20 Jul 2000 10:17:03 -0400 (EDT) Received: from xover.hjinc.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQiyqz23249 for ; Thu, 20 Jul 2000 14:17:03 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Jul 2000 10:13:35 -0400 Message-ID: <7BF58A904536D411ADD400508BC97B85046B82@xover1.netplane.com> From: "Kullberg, Alan" To: mpls@UU.NET Subject: question on generalized MPLS signaling Date: Thu, 20 Jul 2000 10:13:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I have been reading draft-ashwood-generalized-mpls-signaling-00.txt and draft-ietf-mpls-lsp-hierarchy-00.txt and have a question. When a bidirectional LSP is being signaled, a label stack may be required in the reverse direction. Can the method described in lsp-hierarchy be applied in the reverse direction? If so, where does the "strict hop subsequence" come from? For RSVP, it could come from a record route object, but for CR-LDP, there is no such record route TLV. Thanks, Alan From owner-mpls@UU.NET Thu Jul 20 10:29: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 KAA09922 for ; Thu, 20 Jul 2000 10:29:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyqz04823; Thu, 20 Jul 2000 14:29:09 GMT Received: by mail-control.mail.uu.net id QQiyqz21545 for mpls-outgoing; Thu, 20 Jul 2000 14:28: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 QQiyqz21540 for ; Thu, 20 Jul 2000 14:28: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 QQiyqz10718 for ; Thu, 20 Jul 2000 10:28:06 -0400 (EDT) Received: from old-callisto.ftel.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: big-relay-1.ftel.co.uk [192.65.220.123]) id QQiyqz02916 for ; Thu, 20 Jul 2000 14:27:50 GMT Received: (from root@localhost) by old-callisto.ftel.co.uk (8.10.1/8.10.1/Revision:1.53/cyrus/yp) id e6KERmE22290; Thu, 20 Jul 2000 15:27:48 +0100 (BST) Received: from ftel.co.uk (kiwi.ftel.co.uk [172.16.13.170]) by old-callisto.ftel.co.uk (8.10.1/8.10.1/Revision:1.53/scanin/yp) with ESMTP id e6KERl322284; Thu, 20 Jul 2000 15:27:47 +0100 (BST) Message-ID: <39770C57.DBDDE5FF@ftel.co.uk> Date: Thu, 20 Jul 2000 15:27:35 +0100 From: Robert M Matheson X-Mailer: Mozilla 4.73 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: Lou Berger , Adrian Farrel , Eric Gray , "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" Subject: Re: IP header compression (was "process") References: <200007201414.KAA22077@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Rosen wrote: > > Adrian> I think it is most interesting in the VoMPLS world where each packet > Adrian> may be small (16 byte?) and the headers (IP, RTP, MPLS) become very > Adrian> significant. > > Perhaps. But one needs the confluence of VoIP, MPLS, and low-speed links to > make this useful. If we're going to consider putting something on the > standards track, I think we should better understand whether it is really > needed. Isn't this equivalent to saying that such header compression would be useful if the use of MPLS extended into the access network? Has this happened yet? Does anyone have a view as to whether it will happen? Robert From owner-mpls@UU.NET Thu Jul 20 10:44:56 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17605 for ; Thu, 20 Jul 2000 10:44:56 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyra15885; Thu, 20 Jul 2000 14:44:15 GMT Received: by mail-control.mail.uu.net id QQiyra22877 for mpls-outgoing; Thu, 20 Jul 2000 14:43: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 QQiyra22870 for ; Thu, 20 Jul 2000 14:43:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyra11575 for ; Thu, 20 Jul 2000 10:43:35 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQiyra23411 for ; Thu, 20 Jul 2000 14:43:35 GMT Received: from tworster ([208.227.99.14]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id KAA06909 for ; Thu, 20 Jul 2000 10:43:31 -0400 (EDT) (envelope-from tom@ennovatenetworks.com) From: "tom worster" To: Subject: mpls-in-ip Date: Thu, 20 Jul 2000 10:43:47 -0400 Message-ID: <006801bff258$ea110110$0340a8c0@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit fyi: until it gets through the editor queue, the -01 of this draft will be available at: http://thefsb.org/i-ds/draft-worster-mpls-in-ip-01.txt http://thefsb.org/i-ds/draft-worster-mpls-in-ip-01.pdf http://thefsb.org/i-ds/draft-worster-mpls-in-ip-01.doc c u fsb From owner-mpls@UU.NET Thu Jul 20 10:49: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 KAA19915 for ; Thu, 20 Jul 2000 10:49:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrb29584; Thu, 20 Jul 2000 14:48:17 GMT Received: by mail-control.mail.uu.net id QQiyrb23450 for mpls-outgoing; Thu, 20 Jul 2000 14:47:52 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiyrb23433 for ; Thu, 20 Jul 2000 14:47: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 QQiyrb12202 for ; Thu, 20 Jul 2000 10:47:32 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiyrb18721 for ; Thu, 20 Jul 2000 14:47:32 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA16828 for ; Thu, 20 Jul 2000 07:47:45 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA22179 for mpls@uu.net; Thu, 20 Jul 2000 10:47:31 -0400 (EDT) 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 QQiyra21865 for ; Thu, 20 Jul 2000 14:33: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 QQiyra11601 for ; Thu, 20 Jul 2000 10:32:45 -0400 (EDT) From: Spencer.Giacalone@predictive.com Received: from athena.predictive.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: athena.predictive.com [208.209.197.197]) id QQiyra09466 for ; Thu, 20 Jul 2000 14:32:14 GMT To: "alex.mondrus" Cc: , Subject: RE: new draft X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000 Message-ID: Date: Tue, 20 Jun 2000 10:33:02 -0400 X-MIMETrack: Serialize by Router on Athena/Predictive(Release 5.0.4 |June 8, 2000) at 07/20/2000 10:33:32 AM, Serialize complete at 07/20/2000 10:33:32 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Alex, Thanks for the question. First, NEXT adds new features. For example, the ability to look a jitter average as a state. Second, it adds the ability to look a node state as you would interface state. For example, system errors as a decay metric. Thirdly, it intends to not only catalog TE type data, but present best paths to other protocols based on sets of TLV metrics. Actually, I'm addressing the specifics of the metric calculation stuff in a separate draft. Forth, it is meant to run with OSPFv3, and uses 'v3s referencing capabilities. Fifth, it combines the ability to support things like wavelength routing and TE in a single unified draft. In addition, NEXT is (or will be ) set up to use as little overhead as possible. Hope this helps, Spence To: , cc: Subject: RE: new draft Spencer: What problems are you trying to solve that have not been addressed yet in the previous TE IGP drafts ? Thank you, Alex Mondrus http://www.ipoptical.com -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Spencer.Giacalone@predictive.com Sent: Monday, June 19, 2000 11:04 AM To: mpls@UU.NET Subject: new draft FYI, A new ID was posted a few weeks back. The memo can be found at: http://www.ietf.org/internet-drafts/draft-giacalone-te-optical-next-00.txt An overview is as follows: Abstract This memo defines extensions to OSPFv3 [2] to provide support for Network Engineering. This set of extensions is termed Network Engineering eXTensions for OSPFv3, or NEXT. The term network engineering was chosen to impart NEXT's wide scope of functionality. NEXT is intended to provide holistic and extremely rich state information to OSPFv3 routers. Using this information, various advanced topological and administrative decisions can be made. Please send comments to ospf@discuss.microsoft.com. Overview This document details extensions to OSPFv3 [2] called NEXT. NEXT can be used to add very granular network engineering capabilities to OSPFv3 networks. To accomplish this, NEXT provides a wealth of interface, link, and device capability and state information to OSPFv3, or other protocols. The intent of NEXT is to enable the selection of shortest paths through networks based on sets of advanced network state criteria. Using NEXT, advanced policy decisions can be made, and traffic can be routed or switch traffic with varying qualities of service. NEXT can also assist in building complex fault tolerant networks. NEXT aims to provide a system of unified network state information to satisfy the requirements of numerous existing and developmental protocols. While NEXT builds on functionality presented in other works, it adds many new features, presents new philosophical possibilities, and is intended for use with OSPFv3. NEXT focuses on traffic engineering (TE) [3,4] and Multi Protocol lambda Switching (MPLmS) [5,6], and Protection Wavelength Routing, but is specifically intended to support changing requirements and technologies in the future. A core philosophical premise of NEXT is that it may effect the core topology building process of OSPFv3, or may be used to build separate "shadow" topologies. In the former, NEXT can be used a basis to make sophisticated decisions within OSPFv3. In the later, OSPFv3/NEXT can serve to build repositories of detailed information to enhance supplementary protocols. NEXT supports advanced intra-area and inter-area routing. Since NEXT operates with and depends on OSPFv3, which is essentially network protocol independent, NEXT can be used to enable all networks to become extensively self aware. It is hoped that NEXT will become a focal point for the distribution of advanced network information, enhancing OSPFv3 (and other protocols) while enabling complex deterministic services to be implemented. Note that in addition to allowing existing QOS protocols, such as RSVP, to provide new types of QoS, NEXT can enhance these protocols, by reducing the possibility of "crank-back". Extensions to other protocols to make use of NEXT information may be needed. -Spence From owner-mpls@UU.NET Thu Jul 20 10:52: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 KAA22072 for ; Thu, 20 Jul 2000 10:52:48 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrb02330; Thu, 20 Jul 2000 14:50:01 GMT Received: by mail-control.mail.uu.net id QQiyrb23653 for mpls-outgoing; Thu, 20 Jul 2000 14:49: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 QQiyrb23640 for ; Thu, 20 Jul 2000 14:49:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyrb14537 for ; Thu, 20 Jul 2000 10:49:07 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyrb00960 for ; Thu, 20 Jul 2000 14:49:06 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id JAA02557; Thu, 20 Jul 2000 09:48:53 -0500 Message-Id: <4.3.2.7.2.20000720104538.00baf3d0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 10:49:15 -0400 To: erosen@cisco.com From: Lou Berger Subject: Re: IP header compression (was "process") Cc: Lou Berger , Adrian Farrel , Eric Gray , "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" In-Reply-To: <200007201414.KAA22077@erosen-sun.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I guess this means we need to repeat some of the discussion that happened in Adelaide in Pittsburgh. I'll ask George for some time... Lou BTW Yes, some are planning to run MPLS at the edge on lower speed links and believe that they need compression. The alternative is to preclude the use of MPLS at the edge. At 10:14 AM 7/20/00 -0400, Eric Rosen wrote: >Lou> It's intended to enable the use of MPLS (in general) on lower speed >Lou> links for applications where minimizing overhead is required. > >I think that discussion of these drafts should be deferred until someone >shows that there is an application which requires that MPLS be run on lower >speed links. > >Adrian> Lou will have a definitive answer > >Well, I guess not ;-) > >Adrian> I think it is most interesting in the VoMPLS world where each packet >Adrian> may be small (16 byte?) and the headers (IP, RTP, MPLS) become very >Adrian> significant. > >Perhaps. But one needs the confluence of VoIP, MPLS, and low-speed links to >make this useful. If we're going to consider putting something on the >standards track, I think we should better understand whether it is really >needed. From owner-mpls@UU.NET Thu Jul 20 11:02: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 LAA27531 for ; Thu, 20 Jul 2000 11:02:04 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrc29910; Thu, 20 Jul 2000 15:00:44 GMT Received: by mail-control.mail.uu.net id QQiyrc24831 for mpls-outgoing; Thu, 20 Jul 2000 15:00: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 QQiyrc24722 for ; Thu, 20 Jul 2000 15:00: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 QQiyrc14528 for ; Thu, 20 Jul 2000 11:00:00 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiyrb14613 for ; Thu, 20 Jul 2000 14:59:29 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA26468; Thu, 20 Jul 2000 07:59:41 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA22225; Thu, 20 Jul 2000 10:59:25 -0400 (EDT) Message-Id: <200007201459.KAA22225@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Robert M Matheson cc: Lou Berger , Adrian Farrel , Eric Gray , "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" Subject: Re: IP header compression (was "process") In-reply-to: Your message of Thu, 20 Jul 2000 15:27:35 +0100. <39770C57.DBDDE5FF@ftel.co.uk> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 20 Jul 2000 10:59:24 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Robert> Isn't this equivalent to saying that such header compression would Robert> be useful if the use of MPLS extended into the access network? Has Robert> this happened yet? Does anyone have a view as to whether it will Robert> happen? These days, the edge rarely consists of the 9.6 kbps lines that were so common when IP header compression was first used. I wonder how common it is even to use IP header compression these days. I would still like to understand better the application which uses low speed links and MPLS. Lou> I guess this means we need to repeat some of the discussion that Lou> happened in Adelaide in Pittsburgh. Or on the mailing list. From owner-mpls@UU.NET Thu Jul 20 11:06:11 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29862 for ; Thu, 20 Jul 2000 11:06:11 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrc22141; Thu, 20 Jul 2000 15:05:25 GMT Received: by mail-control.mail.uu.net id QQiyrc29143 for mpls-outgoing; Thu, 20 Jul 2000 15:04: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 QQiyrc28960 for ; Thu, 20 Jul 2000 15:04: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 QQiyrc15429 for ; Thu, 20 Jul 2000 11:04:30 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQiyrc03511 for ; Thu, 20 Jul 2000 15:04:30 GMT Received: from tworster ([208.227.99.14]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA08221; Thu, 20 Jul 2000 11:04:21 -0400 (EDT) (envelope-from tom@ennovatenetworks.com) From: "tom worster" To: "'Adrian Farrel'" , , "'Lou Berger'" Cc: "'Eric Gray'" , "'George Swallow (E-mail)'" , "'Vijay Srinivasan'" , "'MPLS Mailing List (E-mail)'" Subject: RE: Process has been circumvented again Date: Thu, 20 Jul 2000 11:04:37 -0400 Message-ID: <007a01bff25b$d2c3db60$0340a8c0@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E2A3277@monk.datcon.co.uk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adrian > > Lou will have a definitive answer, but I think it is most > interesting in the > VoMPLS world where each packet may be small (16 byte?) and > the headers (IP, > RTP, MPLS) become very significant. that is one very good example of an app for mpls header compression. eric r's example of "traffic engineering" (i.e. assigning bandwidth and labels to fecs) on low speed access links is also a very interesting app. c u tom From owner-mpls@UU.NET Thu Jul 20 11:06: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 LAA29951 for ; Thu, 20 Jul 2000 11:06:20 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrc21059; Thu, 20 Jul 2000 15:04:42 GMT Received: by mail-control.mail.uu.net id QQiyrc28572 for mpls-outgoing; Thu, 20 Jul 2000 15: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 QQiyrc28506 for ; Thu, 20 Jul 2000 15:04: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 QQiyrc15333 for ; Thu, 20 Jul 2000 11:03:56 -0400 (EDT) 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 QQiyrc02865 for ; Thu, 20 Jul 2000 15:03:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA07404 for mpls@uu.net; Thu, 20 Jul 2000 11:03:40 -0400 (EDT) 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 QQiyrc27917 for ; Thu, 20 Jul 2000 15:03: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 QQiyrc15214 for ; Thu, 20 Jul 2000 11:02:58 -0400 (EDT) Received: from beamer.mchh.siemens.de by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQiyrc02123 for ; Thu, 20 Jul 2000 15:02:42 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA05590; Thu, 20 Jul 2000 17:02:08 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([218.1.68.146]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA15987; Thu, 20 Jul 2000 17:02:16 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2448.0) id ; Thu, 20 Jul 2000 17:02:41 +0200 Message-ID: <3B59676F9ADBD211B5360060086E64EECC01A9@MCHH237E> From: Theimer Thomas To: erosen@cisco.com Cc: "MPLS Mailing List (E-mail)" Subject: RE: IP header compression (was "process") Date: Thu, 20 Jul 2000 17:02:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk A prominent example would be next generation mobile access networks, where mobile base stations are connected to the mobile core network using voice over IP, possibly carried by MPLS. Today, UMTS is based on ATM/AAL2. In the future, this could evolve into VoIP over MPLS with header compression. Bandwidth is clearly limited in mobile access networks. Perhaps someone more familiar with UMTS future releases could comment on this. Thomas > -----Original Message----- > From: Lou Berger [SMTP:lberger@labn.net] > Sent: Thursday, July 20, 2000 4:49 PM > To: erosen@cisco.com > Cc: Lou Berger; Adrian Farrel; Eric Gray; George Swallow (E-mail); 'Vijay Srinivasan'; MPLS Mailing List (E-mail) > Subject: Re: IP header compression (was "process") > > I guess this means we need to repeat some of the discussion that happened > in Adelaide in Pittsburgh. I'll ask George for some time... > > Lou > > BTW Yes, some are planning to run MPLS at the edge on lower speed links and > believe that they need compression. The alternative is to preclude the use > of MPLS at the edge. > > At 10:14 AM 7/20/00 -0400, Eric Rosen wrote: > > >Lou> It's intended to enable the use of MPLS (in general) on lower speed > >Lou> links for applications where minimizing overhead is required. > > > >I think that discussion of these drafts should be deferred until someone > >shows that there is an application which requires that MPLS be run on lower > >speed links. > > > >Adrian> Lou will have a definitive answer > > > >Well, I guess not ;-) > > > >Adrian> I think it is most interesting in the VoMPLS world where each packet > >Adrian> may be small (16 byte?) and the headers (IP, RTP, MPLS) become very > >Adrian> significant. > > > >Perhaps. But one needs the confluence of VoIP, MPLS, and low-speed links to > >make this useful. If we're going to consider putting something on the > >standards track, I think we should better understand whether it is really > >needed. From owner-mpls@UU.NET Thu Jul 20 11:08: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 LAA01132 for ; Thu, 20 Jul 2000 11:08:21 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrc06424; Thu, 20 Jul 2000 15:07:27 GMT Received: by mail-control.mail.uu.net id QQiyrc01090 for mpls-outgoing; Thu, 20 Jul 2000 15:06: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 QQiyrc00891 for ; Thu, 20 Jul 2000 15:06:43 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyrc17892 for ; Thu, 20 Jul 2000 11:06:19 -0400 (EDT) Received: from prue.eim.surrey.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQiyrc23062 for ; Thu, 20 Jul 2000 15:06:04 GMT Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13FHtg-0001X6-00; Thu, 20 Jul 2000 16:06:00 +0100 Date: Thu, 20 Jul 2000 16:05:57 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Eric Rosen cc: "MPLS Mailing List (E-mail)" Subject: Re: IP header compression (was "process") In-Reply-To: <200007201459.KAA22225@erosen-sun.cisco.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 20 Jul 2000, Eric Rosen wrote: > Robert> Isn't this equivalent to saying that such header compression would > Robert> be useful if the use of MPLS extended into the access network? Has > Robert> this happened yet? Does anyone have a view as to whether it will > Robert> happen? > > These days, the edge rarely consists of the 9.6 kbps lines that were so > common when IP header compression was first used. I wonder how common it is > even to use IP header compression these days. Those 9.6kbps links are now wireless 9.6kbps GSM links or links on its descendents, and there's a lot of interest in increasing efficiency of those links. Hence the rohc WG: http://www.ietf.org/html.charters/rohc-charter.html http://www.cdt.luth.se/rohc/ L. PGP From owner-mpls@UU.NET Thu Jul 20 11:19: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 LAA06637 for ; Thu, 20 Jul 2000 11:19:57 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrd08164; Thu, 20 Jul 2000 15:19:02 GMT Received: by mail-control.mail.uu.net id QQiyrd07930 for mpls-outgoing; Thu, 20 Jul 2000 15:18: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 QQiyrd07918 for ; Thu, 20 Jul 2000 15:18: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 QQiyrd17941 for ; Thu, 20 Jul 2000 11:17:55 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyrd06769 for ; Thu, 20 Jul 2000 15:17:54 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id KAA12963; Thu, 20 Jul 2000 10:17:22 -0500 Message-Id: <4.3.2.7.2.20000720111559.00bf4860@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 11:17:45 -0400 To: erosen@cisco.com From: Lou Berger Subject: Re: IP header compression (was "process") Cc: Robert M Matheson , Lou Berger , Adrian Farrel , Eric Gray , "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" In-Reply-To: <200007201459.KAA22225@erosen-sun.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:59 AM 7/20/00 -0400, Eric Rosen wrote: >Robert> Isn't this equivalent to saying that such header compression would >Robert> be useful if the use of MPLS extended into the access network? Has >Robert> this happened yet? Does anyone have a view as to whether it will >Robert> happen? > >These days, the edge rarely consists of the 9.6 kbps lines that were so >common when IP header compression was first used. I wonder how common it is >even to use IP header compression these days. I would still like to >understand better the application which uses low speed links and MPLS. > >Lou> I guess this means we need to repeat some of the discussion that >Lou> happened in Adelaide in Pittsburgh. > >Or on the mailing list. Fine with me, particularly since we've already reach a level of "consensus" at the last WG meeting. Lou From owner-mpls@UU.NET Thu Jul 20 11:32: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 LAA12742 for ; Thu, 20 Jul 2000 11:32:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyre27812; Thu, 20 Jul 2000 15:31:42 GMT Received: by mail-control.mail.uu.net id QQiyre09156 for mpls-outgoing; Thu, 20 Jul 2000 15:31: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 QQiyre09114 for ; Thu, 20 Jul 2000 15:30:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyre20159 for ; Thu, 20 Jul 2000 11:30:48 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQiyre21038 for ; Thu, 20 Jul 2000 15:30:18 GMT Received: from tworster ([208.227.99.14]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA09415; Thu, 20 Jul 2000 11:30:06 -0400 (EDT) (envelope-from tom@ennovatenetworks.com) From: "tom worster" To: Cc: "'Lou Berger'" , "'Adrian Farrel'" , "'Eric Gray'" , "'George Swallow (E-mail)'" , "'Vijay Srinivasan'" , "'MPLS Mailing List (E-mail)'" , "'Robert M Matheson'" Subject: RE: IP header compression (was "process") Date: Thu, 20 Jul 2000 11:30:22 -0400 Message-ID: <008701bff25f$6bb4a900$0340a8c0@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200007201459.KAA22225@erosen-sun.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Eric Rosen > > These days, the edge rarely consists of the 9.6 kbps > lines that were so > common when IP header compression was first used. I wonder > how common it is > even to use IP header compression these days. I would > still like to > understand better the application which uses low speed links and MPLS. yup -- me too. in pittsburgh, hopefully. > Or on the mailing list. that would be jolly good too. c u tom From owner-mpls@UU.NET Thu Jul 20 11:39: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 LAA16163 for ; Thu, 20 Jul 2000 11:39:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyre28330; Thu, 20 Jul 2000 15:38:33 GMT Received: by mail-control.mail.uu.net id QQiyre09564 for mpls-outgoing; Thu, 20 Jul 2000 15:37:55 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 QQiyre09559 for ; Thu, 20 Jul 2000 15:37: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 QQiyre23448 for ; Thu, 20 Jul 2000 11:37:31 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQiyre27418 for ; Thu, 20 Jul 2000 15:37:31 GMT Received: from tworster ([208.227.99.14]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA09728; Thu, 20 Jul 2000 11:36:50 -0400 (EDT) (envelope-from tom@ennovatenetworks.com) From: "tom worster" To: , "'Eric Rosen'" Cc: "'MPLS Mailing List (E-mail)'" Subject: RE: IP header compression Date: Thu, 20 Jul 2000 11:37:06 -0400 Message-ID: <008e01bff260$5cd023f0$0340a8c0@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Lloyd Wood > > Those 9.6kbps links are now wireless 9.6kbps GSM links or links on its > descendents, and there's a lot of interest in increasing efficiency of > those links. descendents such as 3g. which neatly points out the importance of v6 support as a requirement. c u tom From owner-mpls@UU.NET Thu Jul 20 11:49: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 LAA21074 for ; Thu, 20 Jul 2000 11:49:16 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrf18154; Thu, 20 Jul 2000 15:47:50 GMT Received: by mail-control.mail.uu.net id QQiyrf10377 for mpls-outgoing; Thu, 20 Jul 2000 15:47:15 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiyrf10367 for ; Thu, 20 Jul 2000 15:47:11 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 QQiyrf25239 for ; Thu, 20 Jul 2000 11:46:36 -0400 (EDT) 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 QQiyrf16218 for ; Thu, 20 Jul 2000 15:46:20 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA17089 for mpls@uu.net; Thu, 20 Jul 2000 11:46:19 -0400 (EDT) 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 QQiyrf10195 for ; Thu, 20 Jul 2000 15:45: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 QQiyrf25057 for ; Thu, 20 Jul 2000 11:45:26 -0400 (EDT) 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 QQiyrf14748 for ; Thu, 20 Jul 2000 15:45:10 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 LAA16841; Thu, 20 Jul 2000 11:44:59 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA23996; Thu, 20 Jul 2000 11:44:59 -0400 (EDT) Message-Id: <200007201544.LAA23996@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: "tom worster" cc: erosen@cisco.com, "'Lou Berger'" , "'Adrian Farrel'" , "'Eric Gray'" , "'George Swallow (E-mail)'" , "'Vijay Srinivasan'" , "'MPLS Mailing List (E-mail)'" , "'Robert M Matheson'" , swallow@cisco.com Subject: Re: IP header compression (was "process") In-reply-to: Your message of "Thu, 20 Jul 2000 11:30:22 EDT." <008701bff25f$6bb4a900$0340a8c0@tst.ennovatenetworks.com> Date: Thu, 20 Jul 2000 11:44:59 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > yup -- me too. in pittsburgh, hopefully. We can give this a little time if we can't reach consensus on the list. > > Or on the mailing list. > > that would be jolly good too. Preferable. There's already been more discussion than we'll have time for in Pittsburg. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Jul 20 12:12: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 MAA03187 for ; Thu, 20 Jul 2000 12:12:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrg17054; Thu, 20 Jul 2000 16:09:47 GMT Received: by mail-control.mail.uu.net id QQiyrg21866 for mpls-outgoing; Thu, 20 Jul 2000 16:09: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 QQiyrg21835 for ; Thu, 20 Jul 2000 16:08: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 QQiyrg29243 for ; Thu, 20 Jul 2000 12:08:43 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyrg20693 for ; Thu, 20 Jul 2000 16:08:12 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id LAA29828; Thu, 20 Jul 2000 11:07:41 -0500 Message-Id: <4.3.2.7.2.20000720120026.00b7f630@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 12:08:05 -0400 To: "'Zhang, Leah'" From: Lou Berger Subject: RE: A new draft. Cc: Jonathan Lang , "Fu, James" , mpls@UU.NET In-Reply-To: <51DA0AB3D747D311832F005004827CC02CE85C@LUX> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Zhang, Pair-wise/simultaneous label allocation for bidirectional LSPs is supported in draft-generalized-signaling-mpls-00.txt. To achieve pair-wise/simultaneous label allocation for bidirectional LSPs, you'd use label set with just a single element (label). This would required the use of the passed label by the downstream node. Is there anything else covered in your draft that isn't addressed in the generalized draft? Lou At 03:37 PM 7/19/00 -0700, Jonathan Lang wrote: >Zhang, > >The tying together of the upstream and downstream label can be done using >the Suggested Label that is also proposed in >draft-lang-mpls-rsvp-oxc-00.txt (updated and included in >draft-generalized-signaling-mpls-00.txt). > >-Jonathan >>-----Original Message----- >>From: Zhang, Leah [mailto:leahz@sorrentonet.com] >>Sent: Wednesday, July 19, 2000 2:27 PM >>To: 'Jonathan Lang'; Fu, James; mpls@UU.NET >>Subject: RE: A new draft. >> >>Jonathan: >> >> Thanks very much for your comments. We read your draft very >> carefully. There are a lot of good thoughts and points in your >> draft. Please see our response below. >> >> >>James Fu, Dan Guo, Raymond Cheng, Leah Zhang >> >>Sorrento Networks Inc. >>9990 Mesa Rim Road >>San Diego, CA 92121 >> >> >> -----Original Message----- >>From: Jonathan Lang [mailto:jplang@calient.net] >>Sent: Tuesday, July 18, 2000 6:04 PM >>To: 'Fu, James'; mpls@UU.NET >>Cc: Jonathan Lang >>Subject: RE: A new draft. >>James, >> I read your draft and I'm afraid you have misunderstood the >> bi-directional approach of draft-lang-mpls-rsvp-oxc-00.txt (updated and >> included in draft-generalized-signaling-mpls-00.txt). The process of >> establishing a bi-directional LSP is the same as the establishment of a >> unidirectional LSP with the exception that an Upstream Label is added to >> the Path message. (Incidentally, the flow of the Upstream Label is the >> same as the normal flow of a Label would be for the upstream segment of >> a bi-directional LSP, except that we have short-circuited sending the >> Path message upstream -- see example below). >> >>We understand your approach of assigning Upstream Label in the Path >>message, and assigning Downstream Label in the Resv message. In your >>approach, the assignment of Upstream Label and >>the assignment of Downstream Label is not tied together. We think that to >>support bi-directional LSP, it is important to do pair-wise assignment >>(or reservations) at the SAME time. This becomes especially >>important in the transparent pure optical networks where wavelength >>continuity is required. >> >> >>Contention may occur for the following reasons: >>1) If there is a requirement that the input/output ports for the >>bi-directional path be tied together (e.g., if they must be on the same >>physical I/O card). Since these are assigned by different OXCs, >>contention may occur. The scheme that you have proposed will also have >>this contention scenario. >>We admit that we did not consider this requirement at the time we wrote >>the draft. We defines the >>contention specifically as two OXCs trying to assign labels for the same >>link. This contention scenario, though, happens much less often than the >>contention scenario where two OXCs trying to assign labels for the same link >> >> >>2) If two bi-directional LSPs are attempted to be established >>simultaneously in opposite directions and there are only enough resources >>for one of the bi-directional LSPs. In this case, one of the LSPs cannot >>be established along that path. The scheme that you propose avoids this >>contention, I assume, by resource checking on the Path message and >>sending a PathError message to the losing LSP. This is also how it is >>done in draft-lang-mpls-rsvp-oxc-00.txt. >>We agree to this assessment. >> >> >>On another note, I think overloading the ResvError message for label >>allocation is a bad idea. >> >>We are not fond of this solution, too. However, this is a better >>compromised solution at moment compared with that a new LMP has to be >>used together with the RSVP extensions. . We are open to any good >>alternatives and suggestions. >> >>To summarize, we think that to support bi-directional LSP (OSP), >>pair-wise label assignment scheme is better than uni -directional label >>assignment schemes. This becomes especially important to support >>wavelength continuity requirement in transparent optical networks. We >>will modify our draft. A new version will come out soon. >> >> >>Regards, >>Jonathan >> >>Example: >> >>downstream -----> >>upstream <----- >> >>(1) RSVP-TE used to establish a bi-directional LSP: >> >>+-+-+ Path(Label Request) +-+-+ Path(Label Request) >>+-+-+ Path(LabelRequest) >> | | ---------------------------> | | >> ---------------------------> | | ---------------------------> >>+ + Resv(Label) + + Resv(Label) + + >> Resv(Label) >> | | <--------------- | | <--------------- >> | | <---------------- >>+ A + + B >>+ + C + >> | | Path(Label Request) | | Path(Label >> Request) | | Path(LabelRequest) >>+ + <--------------------------- + + <-------------------------- >> + + <------------------------ >> | | Resv(Label) | | Resv(Label) >> | | Resv(Label) >>+-+-+ --------------------------> +-+-+ --------------------------> >>+-+-+ ------------------------> >> >>(2) bi-directional LSP using draft-lang-mpls-rsvp-oxc.txt >> >>+-+-+ Path(Label Request, +-+-+ Path(Label Request) >>+-+-+ Path(LabelRequest) >> | | UpstreamLabel) | | UpstreamLabel) | | >> UpstreamLabel) >>+ + ---------------------------> + + >>---------------------------> + + ---------------------------> >> | | | | >> | | >>+ A + + B >>+ + C + >> | | Resv(Label) | | Resv(Label) >> | | Resv(Label) >>+ + <--------------------------- + + <-------------------------- >> + + <------------------------ >> | | | | >> | | >>+-+-+ +-+-+ >> +-+-+ >> >>>-----Original Message----- >>>From: Fu, James [mailto:jfu@sorrentonet.com] >>>Sent: Tuesday, July 18, 2000 9:39 AM >>>To: mpls@UU.NET >>>Subject: A new draft. >>> >>>An Internet Draft entitled "Extensions to RSVP-TE for Bi-directional >>>Optical Path Setup" has been submitted to the IETF. >>> >>>http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt >>> >>> >>>James Fu >>>Sorrento Networks Inc. >>>9990 Mesa Rim Road >>>San Diego, CA 92121 >>> >>>jfu@sorrentonet.com From owner-mpls@UU.NET Thu Jul 20 12:31: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 MAA12798 for ; Thu, 20 Jul 2000 12:31:41 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrh11551; Thu, 20 Jul 2000 16:29:44 GMT Received: by mail-control.mail.uu.net id QQiyrh24515 for mpls-outgoing; Thu, 20 Jul 2000 16:29: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 QQiyrh24508 for ; Thu, 20 Jul 2000 16:29: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 QQiyrh02495 for ; Thu, 20 Jul 2000 12:29:00 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQiyrh10602 for ; Thu, 20 Jul 2000 16:28:59 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <36QHDNTJ>; Thu, 20 Jul 2000 09:36:07 -0700 Message-ID: <4D3F9F2BEC58D4118FCE009027B0A662136037@ICARIAN> From: Eric Gray To: "'Lou Berger'" , erosen@cisco.com Cc: "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" Subject: RE: IP header compression (was "process") Date: Thu, 20 Jul 2000 09:36:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Lou, I'm not going to let this one slip by. The minutes say that "we" (those who were able to make it to Adelaide) reached a consensus that MPLS header compression is an appropriate work item for the working group. Quoting: "Vijay wanted to gauge the reaction of the MPLS WG on the header compression work, i.e., whether it is an appropriate work item for the group. The upshot was that there was consensus to perform work in that area." This is not the same thing as asking if there is consensus to adopt your draft as a working group draft (and getting it). If you thought the consensus was rather more than that, you should have said something when the minutes came out. :-) Much better to have done it that way than by trying to assert otherwise now. -- Eric Gray > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, July 20, 2000 8:18 AM > To: erosen@cisco.com > Cc: Robert M Matheson; Lou Berger; Adrian Farrel; Eric Gray; George > Swallow (E-mail); 'Vijay Srinivasan'; MPLS Mailing List (E-mail) > Subject: Re: IP header compression (was "process") > > > At 10:59 AM 7/20/00 -0400, Eric Rosen wrote: > >Robert> Isn't this equivalent to saying that such header > compression would > >Robert> be useful if the use of MPLS extended into the > access network? Has > >Robert> this happened yet? Does anyone have a view as to > whether it will > >Robert> happen? > > > >These days, the edge rarely consists of the 9.6 kbps > lines that were so > >common when IP header compression was first used. I wonder > how common it is > >even to use IP header compression these days. I would > still like to > >understand better the application which uses low speed links > and MPLS. > > > >Lou> I guess this means we need to repeat some of the > discussion that > >Lou> happened in Adelaide in Pittsburgh. > > > >Or on the mailing list. > > Fine with me, particularly since we've already reach a level > of "consensus" > at the last WG meeting. > > Lou > From owner-mpls@UU.NET Thu Jul 20 12:50: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 MAA22100 for ; Thu, 20 Jul 2000 12:50:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrj21920; Thu, 20 Jul 2000 16:49:17 GMT Received: by mail-control.mail.uu.net id QQiyrj25781 for mpls-outgoing; Thu, 20 Jul 2000 16:48: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 QQiyrj25763 for ; Thu, 20 Jul 2000 16:48:39 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyrj05620 for ; Thu, 20 Jul 2000 12:48:14 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyrj20934 for ; Thu, 20 Jul 2000 16:48:13 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id LAA10602; Thu, 20 Jul 2000 11:47:50 -0500 Message-Id: <4.3.2.7.2.20000720123550.00b87ae0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 12:47:41 -0400 To: Eric Gray From: Lou Berger Subject: RE: IP header compression (was "process") Cc: "'Lou Berger'" , erosen@cisco.com, "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" In-Reply-To: <4D3F9F2BEC58D4118FCE009027B0A662136037@ICARIAN> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Eric, Your message&issue seem to be procedural. WG procedure is an issue for the chairs, not me. I suggest you take the issue up with them. Lou At 09:36 AM 7/20/00 -0700, Eric Gray wrote: >Lou, > > I'm not going to let this one slip by. > > The minutes say that "we" (those who were >able to make it to Adelaide) reached a consensus >that MPLS header compression is an appropriate >work item for the working group. Quoting: > >"Vijay wanted to gauge the reaction of the MPLS > WG on the header compression work, i.e., whether > it is an appropriate work item for the group. > The upshot was that there was consensus to > perform work in that area." > >This is not the same thing as asking if there is >consensus to adopt your draft as a working group >draft (and getting it). > > If you thought the consensus was rather more >than that, you should have said something when the >minutes came out. :-) Much better to have done it >that way than by trying to assert otherwise now. > >-- >Eric Gray > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Thursday, July 20, 2000 8:18 AM > > To: erosen@cisco.com > > Cc: Robert M Matheson; Lou Berger; Adrian Farrel; Eric Gray; George > > Swallow (E-mail); 'Vijay Srinivasan'; MPLS Mailing List (E-mail) > > Subject: Re: IP header compression (was "process") > > > > > > At 10:59 AM 7/20/00 -0400, Eric Rosen wrote: > > >Robert> Isn't this equivalent to saying that such header > > compression would > > >Robert> be useful if the use of MPLS extended into the > > access network? Has > > >Robert> this happened yet? Does anyone have a view as to > > whether it will > > >Robert> happen? > > > > > >These days, the edge rarely consists of the 9.6 kbps > > lines that were so > > >common when IP header compression was first used. I wonder > > how common it is > > >even to use IP header compression these days. I would > > still like to > > >understand better the application which uses low speed links > > and MPLS. > > > > > >Lou> I guess this means we need to repeat some of the > > discussion that > > >Lou> happened in Adelaide in Pittsburgh. > > > > > >Or on the mailing list. > > > > Fine with me, particularly since we've already reach a level > > of "consensus" > > at the last WG meeting. > > > > Lou > > From owner-mpls@UU.NET Thu Jul 20 13: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 NAA27278 for ; Thu, 20 Jul 2000 13:00:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrj29493; Thu, 20 Jul 2000 16:59:41 GMT Received: by mail-control.mail.uu.net id QQiyrj26317 for mpls-outgoing; Thu, 20 Jul 2000 16:59: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 QQiyrj26311 for ; Thu, 20 Jul 2000 16:59: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 QQiyrj05186 for ; Thu, 20 Jul 2000 12:59:05 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQiyrj28818 for ; Thu, 20 Jul 2000 16:58:49 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <36QHDNVY>; Thu, 20 Jul 2000 10:05:57 -0700 Message-ID: <4D3F9F2BEC58D4118FCE009027B0A662136039@ICARIAN> From: Eric Gray To: "'Lou Berger'" , Eric Gray Cc: "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" Subject: RE: IP header compression (was "process") Date: Thu, 20 Jul 2000 10:05:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Lou, I did, as you well know - since you were copied. :-) You are the one who is making statements on the list that are inconsistent with public information. I am simply trying to correct your assertion - to the same audience, of course. -- Eric Gray > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, July 20, 2000 9:48 AM > To: Eric Gray > Cc: 'Lou Berger'; erosen@cisco.com; George Swallow (E-mail); 'Vijay > Srinivasan'; MPLS Mailing List (E-mail) > Subject: RE: IP header compression (was "process") > > > Eric, > Your message&issue seem to be procedural. WG > procedure is an > issue for the chairs, not me. I suggest you take the issue > up with them. > > Lou > > At 09:36 AM 7/20/00 -0700, Eric Gray wrote: > >Lou, > > > > I'm not going to let this one slip by. > > > > The minutes say that "we" (those who were > >able to make it to Adelaide) reached a consensus > >that MPLS header compression is an appropriate > >work item for the working group. Quoting: > > > >"Vijay wanted to gauge the reaction of the MPLS > > WG on the header compression work, i.e., whether > > it is an appropriate work item for the group. > > The upshot was that there was consensus to > > perform work in that area." > > > >This is not the same thing as asking if there is > >consensus to adopt your draft as a working group > >draft (and getting it). > > > > If you thought the consensus was rather more > >than that, you should have said something when the > >minutes came out. :-) Much better to have done it > >that way than by trying to assert otherwise now. > > > >-- > >Eric Gray > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Thursday, July 20, 2000 8:18 AM > > > To: erosen@cisco.com > > > Cc: Robert M Matheson; Lou Berger; Adrian Farrel; Eric > Gray; George > > > Swallow (E-mail); 'Vijay Srinivasan'; MPLS Mailing List (E-mail) > > > Subject: Re: IP header compression (was "process") > > > > > > > > > At 10:59 AM 7/20/00 -0400, Eric Rosen wrote: > > > >Robert> Isn't this equivalent to saying that such header > > > compression would > > > >Robert> be useful if the use of MPLS extended into the > > > access network? Has > > > >Robert> this happened yet? Does anyone have a view as to > > > whether it will > > > >Robert> happen? > > > > > > > >These days, the edge rarely consists of the 9.6 kbps > > > lines that were so > > > >common when IP header compression was first used. I wonder > > > how common it is > > > >even to use IP header compression these days. I would > > > still like to > > > >understand better the application which uses low speed links > > > and MPLS. > > > > > > > >Lou> I guess this means we need to repeat some of the > > > discussion that > > > >Lou> happened in Adelaide in Pittsburgh. > > > > > > > >Or on the mailing list. > > > > > > Fine with me, particularly since we've already reach a level > > > of "consensus" > > > at the last WG meeting. > > > > > > Lou > > > > From owner-mpls@UU.NET Thu Jul 20 13:14: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 NAA04482 for ; Thu, 20 Jul 2000 13:14:09 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrk09604; Thu, 20 Jul 2000 17:12:39 GMT Received: by mail-control.mail.uu.net id QQiyrk08306 for mpls-outgoing; Thu, 20 Jul 2000 17: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 QQiyrk08298 for ; Thu, 20 Jul 2000 17:12:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyrk07290 for ; Thu, 20 Jul 2000 13:12:08 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyrk08956 for ; Thu, 20 Jul 2000 17:11:52 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id MAA19124; Thu, 20 Jul 2000 12:11:37 -0500 Message-Id: <4.3.2.7.2.20000720130808.00d85ee0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 13:12:03 -0400 To: Eric Gray From: Lou Berger Subject: RE: IP header compression (was "process") Cc: "'Lou Berger'" , Eric Gray , "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" In-Reply-To: <4D3F9F2BEC58D4118FCE009027B0A662136039@ICARIAN> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:05 AM 7/20/00 -0700, Eric Gray wrote: >Lou, > > I did, as you well know - since you were >copied. :-) Eric, Your message was directed to me (on both subject line and in body) and to Eric R. on subject line. Not the chairs. The chairs were on cc'ed. > You are the one who is making statements >on the list that are inconsistent with public >information. I am simply trying to correct your >assertion - to the same audience, of course. Actually, I think my statements *are* consistent with the minutes. The minutes make a statement that can reasonably be interpreted to mean that the 3 drafts covered in the meeting were to be adopted as WG documents. To me that fact that this wasn't spelled out was a matter of style, i.e. how much detail to include in the minutes. Lou >-- >Eric Gray > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Thursday, July 20, 2000 9:48 AM > > To: Eric Gray > > Cc: 'Lou Berger'; erosen@cisco.com; George Swallow (E-mail); 'Vijay > > Srinivasan'; MPLS Mailing List (E-mail) > > Subject: RE: IP header compression (was "process") > > > > > > Eric, > > Your message&issue seem to be procedural. WG > > procedure is an > > issue for the chairs, not me. I suggest you take the issue > > up with them. > > > > Lou > > > > At 09:36 AM 7/20/00 -0700, Eric Gray wrote: > > >Lou, > > > > > > I'm not going to let this one slip by. > > > > > > The minutes say that "we" (those who were > > >able to make it to Adelaide) reached a consensus > > >that MPLS header compression is an appropriate > > >work item for the working group. Quoting: > > > > > >"Vijay wanted to gauge the reaction of the MPLS > > > WG on the header compression work, i.e., whether > > > it is an appropriate work item for the group. > > > The upshot was that there was consensus to > > > perform work in that area." > > > > > >This is not the same thing as asking if there is > > >consensus to adopt your draft as a working group > > >draft (and getting it). > > > > > > If you thought the consensus was rather more > > >than that, you should have said something when the > > >minutes came out. :-) Much better to have done it > > >that way than by trying to assert otherwise now. > > > > > >-- > > >Eric Gray > > > > > > > -----Original Message----- > > > > From: Lou Berger [mailto:lberger@labn.net] > > > > Sent: Thursday, July 20, 2000 8:18 AM > > > > To: erosen@cisco.com > > > > Cc: Robert M Matheson; Lou Berger; Adrian Farrel; Eric > > Gray; George > > > > Swallow (E-mail); 'Vijay Srinivasan'; MPLS Mailing List (E-mail) > > > > Subject: Re: IP header compression (was "process") > > > > > > > > > > > > At 10:59 AM 7/20/00 -0400, Eric Rosen wrote: > > > > >Robert> Isn't this equivalent to saying that such header > > > > compression would > > > > >Robert> be useful if the use of MPLS extended into the > > > > access network? Has > > > > >Robert> this happened yet? Does anyone have a view as to > > > > whether it will > > > > >Robert> happen? > > > > > > > > > >These days, the edge rarely consists of the 9.6 kbps > > > > lines that were so > > > > >common when IP header compression was first used. I wonder > > > > how common it is > > > > >even to use IP header compression these days. I would > > > > still like to > > > > >understand better the application which uses low speed links > > > > and MPLS. > > > > > > > > > >Lou> I guess this means we need to repeat some of the > > > > discussion that > > > > >Lou> happened in Adelaide in Pittsburgh. > > > > > > > > > >Or on the mailing list. > > > > > > > > Fine with me, particularly since we've already reach a level > > > > of "consensus" > > > > at the last WG meeting. > > > > > > > > Lou > > > > > > From owner-mpls@UU.NET Thu Jul 20 13:34: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 NAA15426 for ; Thu, 20 Jul 2000 13:34:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrm01474; Thu, 20 Jul 2000 17:32:52 GMT Received: by mail-control.mail.uu.net id QQiyrm09959 for mpls-outgoing; Thu, 20 Jul 2000 17: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 QQiyrm09954 for ; Thu, 20 Jul 2000 17:32: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 QQiyrm14206 for ; Thu, 20 Jul 2000 13:32:09 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyrm00883 for ; Thu, 20 Jul 2000 17:32:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA06878 for mpls@uu.net; Thu, 20 Jul 2000 13:32:07 -0400 (EDT) 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 QQiyrm09938 for ; Thu, 20 Jul 2000 17:31: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 QQiyrm14086 for ; Thu, 20 Jul 2000 13:31:27 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQiyrm00538 for ; Thu, 20 Jul 2000 17:31:27 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 KAA23625; Thu, 20 Jul 2000 10:30:54 -0700 (PDT) Message-ID: <3977374D.55B6F6F9@pluris.com> Date: Thu, 20 Jul 2000 10:30:53 -0700 From: Bora Akyol X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: tom worster CC: L.Wood@eim.surrey.ac.uk, "'Eric Rosen'" , "'MPLS Mailing List (E-mail)'" Subject: Re: IP header compression References: <008e01bff260$5cd023f0$0340a8c0@tst.ennovatenetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I thought 3G speeds were up to 2Mbps. If they are still at 9.6Kbps then they should named (-1)G. Seriously, why not run IP with VJ compression instead of MPLS all the way to the mobile phones. What else does MPLS buy you? Bora tom worster wrote: > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Lloyd > Wood > > > > Those 9.6kbps links are now wireless 9.6kbps GSM links or links on its > > descendents, and there's a lot of interest in increasing efficiency of > > those links. > > descendents such as 3g. which neatly points out the importance > of v6 support as a requirement. > > c u > tom From owner-mpls@UU.NET Thu Jul 20 13:46: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 NAA21440 for ; Thu, 20 Jul 2000 13:46:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrm19656; Thu, 20 Jul 2000 17:44:48 GMT Received: by mail-control.mail.uu.net id QQiyrm10602 for mpls-outgoing; Thu, 20 Jul 2000 17:44: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 QQiyrm10596 for ; Thu, 20 Jul 2000 17:44:13 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyrm16950 for ; Thu, 20 Jul 2000 13:44:01 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQiyrm18562 for ; Thu, 20 Jul 2000 17:44:00 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <36QHDN5D>; Thu, 20 Jul 2000 10:51:09 -0700 Message-ID: <4D3F9F2BEC58D4118FCE009027B0A66213603B@ICARIAN> From: Eric Gray To: "Lou Berger (E-mail)" Cc: "MPLS Mailing List (E-mail)" Subject: FW: Process has been circumvented again - was IP header compressi on (was "process") Date: Thu, 20 Jul 2000 10:51:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Lou, You have definitely taken this discussion down a path that does not need to be discussed on the list - however, since you started it, here is the message I referred to when I said you were "copied". Now, I think we can stop this particular thread. -- Eric Gray > -----Original Message----- > From: Eric Gray > Sent: Wednesday, July 19, 2000 11:32 AM > To: 'Lou Berger' > Cc: George Swallow (E-mail); 'Vijay Srinivasan'; Eric Gray > Subject: RE: Process has been circumvented again > > > George/Vijay/Lou, > > Off-list observation. > > A key reason for producing minutes is to have a > public (or at least common) record of what is said and > done at a meeting. Taking specific action based on > what you may have heard (or thought you heard :-) at a > meeting that is not part of the common record makes it > a useless effort to record minutes. > > This is important, because - had I known that we > were considering adopting these drafts as working group > documents, I would have been able to prioritize things > in a way that would have allowed me to review and make > comments on them. Essentially, I do no see what gains > you get from compressing the MPLS stack when compared > to the obvious complexity required to support it. > > One tremendously simple modification of one of > the alternatives you considered is to simply define > new PPP and Ethernet code points for MPLS unicast and > multicast encapsulation of compressed IPv4 headers. I > do not see where there is any value in defining a more > complex approach than this. I certainly do not see a > reason to define an approach to compress an MPLS stack > in addition compressing IP headers. > > -- > Eric Gray > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Wednesday, July 19, 2000 11:10 AM > > To: Eric Gray > > Cc: George Swallow (E-mail); 'Vijay Srinivasan'; MPLS Mailing List > > (E-mail) > > Subject: Re: Process has been circumvented again > > > > > > Eric, > > Yes, you missed it. (Sometimes minutes don't capture > > the fullness > > of a discussion, oh well...) There was specific agreement in > > Adelaide to > > bring these documents into the working group, i.e., to make them WG > > documents. At least that's what I witnessed. > > > > Lou > > > > At 11:00 AM 7/19/00 -0700, Eric Gray wrote: > > >George/Vijay, > > > > > > I don't recall there being a specific consensus > > >to accept these documents as working group drafts: > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-mpls-hdr-comp-00.txt > > >http://www.ietf.org/internet-drafts/draft-ietf-mpls-hdr-comp- > over-ppp-00.txt > > > > > > Did I miss it? I noticed that the minutes from > >Adelaide showed that there was consensus to perform > >work in this area, but is that the same as accepting > >these drafts? > > > >-- > >Eric Gray > From owner-mpls@UU.NET Thu Jul 20 13:50: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 NAA23900 for ; Thu, 20 Jul 2000 13:50:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrn26193; Thu, 20 Jul 2000 17:49:27 GMT Received: by mail-control.mail.uu.net id QQiyrn11067 for mpls-outgoing; Thu, 20 Jul 2000 17: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 QQiyrn11053 for ; Thu, 20 Jul 2000 17:48: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 QQiyrn17534 for ; Thu, 20 Jul 2000 13:47:18 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyrn13428 for ; Thu, 20 Jul 2000 17:47:02 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA09884 for mpls@uu.net; Thu, 20 Jul 2000 13:47:01 -0400 (EDT) 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 QQiyrn10984 for ; Thu, 20 Jul 2000 17:46: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 QQiyrn19269 for ; Thu, 20 Jul 2000 13:45:38 -0400 (EDT) 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 QQiyrn20906 for ; Thu, 20 Jul 2000 17:45:37 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 NAA13596 for ; Thu, 20 Jul 2000 13:45:36 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA03085 for ; Thu, 20 Jul 2000 13:45:36 -0400 (EDT) Message-Id: <200007201745.NAA03085@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Last Call on LDP MIB Date: Thu, 20 Jul 2000 13:45:36 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Folks - The authors of the LDP MIB have addressed the issues raised in the previous last call and issued a new draft. draft-ietf-mpls-ldp-mib-06.txt This message initiates a one week last call. Comments are limited to the changes from the previous draft. The last call ends July 27, midnight GMT. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Jul 20 13:50: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 NAA24079 for ; Thu, 20 Jul 2000 13:50:56 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrn15618; Thu, 20 Jul 2000 17:49:42 GMT Received: by mail-control.mail.uu.net id QQiyrn11073 for mpls-outgoing; Thu, 20 Jul 2000 17:49: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 QQiyrn11055 for ; Thu, 20 Jul 2000 17:48:56 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyrn17626 for ; Thu, 20 Jul 2000 13:48:03 -0400 (EDT) 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 QQiyrn14117 for ; Thu, 20 Jul 2000 17:48:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Thu Jul 20 13:47:59 EDT 2000 Received: from dnrc.bell-labs.com (dhcp-6-168.pa.bell-labs.com [135.250.6.168]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA17016; Thu, 20 Jul 2000 13:48:51 -0400 (EDT) Message-ID: <39773C39.B8DBC2C@dnrc.bell-labs.com> Date: Thu, 20 Jul 2000 10:51:53 -0700 From: Grenville Armitage Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lou Berger CC: "George Swallow (E-mail)" , "'Vijay Srinivasan'" , "MPLS Mailing List (E-mail)" Subject: Re: IP header compression (was "process") References: <4.3.2.7.2.20000720130808.00d85ee0@mail.labn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit #define PROCEDURAL_TANGENT Lou Berger wrote: [..] > Actually, I think my statements *are* consistent with the minutes. It is actually more consistent to assert that if the minutes meant *your* specific drafts were being adopted as work items, the minutes would say so. They dont. They should have if it were the case. > The > minutes make a statement that can reasonably be interpreted to mean that > the 3 drafts covered in the meeting were to be adopted as WG documents. I was at the meeting, and the minutes *appear* to confirm my hazy recollection that compression was declared interesting, but no real decision was made to elevate anyone's documents to the status of work item just yet. (Note I'm not making any personal observations on whether I believe the group made the right choice...) > To > me that fact that this wasn't spelled out was a matter of style, i.e. how > much detail to include in the minutes. Hmmm... if minutes are going to be stylistically re-interpreted months down the track, instead of being corrected for precision following the meeting, we might as well not have minutes at all. (Chairs cc'd to indicate this is their thread too) cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mpls@UU.NET Thu Jul 20 13:51: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 NAA24476 for ; Thu, 20 Jul 2000 13:51:41 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrn16442; Thu, 20 Jul 2000 17:50:22 GMT Received: by mail-control.mail.uu.net id QQiyrn11110 for mpls-outgoing; Thu, 20 Jul 2000 17:49:52 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiyrn11092 for ; Thu, 20 Jul 2000 17:49: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 QQiyrn17742 for ; Thu, 20 Jul 2000 13:48:44 -0400 (EDT) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQiyrn14386 for ; Thu, 20 Jul 2000 17:48:24 GMT Received: from tellium.com (client-151-198-92-104.bellatlantic.net [151.198.92.104] (may be forged)) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e6KHfq528157 for ; Thu, 20 Jul 2000 13:41:52 -0400 (EDT) Message-ID: <39773B7D.2E16869A@tellium.com> Date: Thu, 20 Jul 2000 13:48:45 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: mpls@UU.NET Subject: Re: I-D ACTION:draft-ietf-mpls-te-feed-01.txt References: <200007201046.GAA11855@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: I hate to say this, but similar approaches have been described before: See: Competetive Routing of Virtual Circuits in ATM Networks (1995) by S. Plotkin http://troll-w.stanford.edu/plotkin/jsac95.ps and Routing and Admission Control in General Topology Networks (1995) by Gawlick et al. http://troll-w.stanford.edu/plotkin/bigmu.ps Bala Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : IMPROVING TOPOLOGY DATA BASE ACCURACY WITH LSP > FEEDBACK > Author(s) : P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki > Filename : draft-ietf-mpls-te-feed-01.txt > Pages : 12 > Date : 19-Jul-00 > > One key component of traffic engineering is a concept known as > constraint based routing. In constraint based routing a topology > database is maintained on all participating nodes. This database > contains a complete list of all the links in the network that > participate in traffic engineering and for each of these links a set > of constraints which those links can meet. Bandwidth, for example, > is one essential constraint. Since the bandwidth available changes > as new LSPs are established and terminated the topology database > will develop inconsistencies with respect to the real network. It is > not possible to increase the flooding rates arbitrarily to keep the > database discrepancies from growing. We propose a new mechanism > whereby a source node can learn about the successes or failures of > its path selections by receiving feedback from the paths it is > attempting. This fed-back information can be incorporated into > subsequent route computations, which greatly improves the accuracy > of the overall routing solution by significantly reducing the > database discrepancies. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-mpls-te-feed-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mpls-te-feed-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <20000719141502.I-D@ietf.org> -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Thu Jul 20 13:52: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 NAA24806 for ; Thu, 20 Jul 2000 13:52:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrn28859; Thu, 20 Jul 2000 17:51:05 GMT Received: by mail-control.mail.uu.net id QQiyrn11162 for mpls-outgoing; Thu, 20 Jul 2000 17:50: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 QQiyrn11151 for ; Thu, 20 Jul 2000 17:50:28 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 QQiyrn18044 for ; Thu, 20 Jul 2000 13:50:14 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQiyrn27495 for ; Thu, 20 Jul 2000 17:50:13 GMT Received: from tworster ([208.227.99.14]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id NAA15965; Thu, 20 Jul 2000 13:49:41 -0400 (EDT) (envelope-from tom@ennovatenetworks.com) From: "tom worster" To: "'Bora Akyol'" Cc: "'MPLS Mailing List (E-mail)'" Subject: RE: IP header compression Date: Thu, 20 Jul 2000 13:49:57 -0400 Message-ID: <00da01bff272$ebb5b190$0340a8c0@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3977374D.55B6F6F9@pluris.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora Akyol > > I thought 3G speeds were up to 2Mbps. If they are still at > 9.6Kbps then they > should named (-1)G. in 3g it can, and will, change rapidly from one to the other. > Seriously, why not run IP with VJ compression instead of MPLS > all the way to > the mobile phones. What else does MPLS buy you? as i recall: the ip version of 3g needs a tunnel from the serving node down to the terminal. the ones they use in gprs are way clunky for a big high speed network. mpls fits the bill and, as a bonus, has this neat header compression feature built right in. since the tunnel can cross several hops, mpls works better than datalink compression. i don't work on that stuff so don't take my word. maybe there's a 3g expert on the list who can give you a better answer. c u tom From owner-mpls@UU.NET Thu Jul 20 13:57: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 NAA27618 for ; Thu, 20 Jul 2000 13:57:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrn05572; Thu, 20 Jul 2000 17:55:53 GMT Received: by mail-control.mail.uu.net id QQiyrn11531 for mpls-outgoing; Thu, 20 Jul 2000 17:55:29 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiyrn11526 for ; Thu, 20 Jul 2000 17:55:20 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyrn18973 for ; Thu, 20 Jul 2000 13:55:12 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQiyrn19925 for ; Thu, 20 Jul 2000 17:54:42 GMT Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id NAA16263; Thu, 20 Jul 2000 13:54:33 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Lou Berger'" , "'Eric Gray'" Cc: "'Eric Gray'" , "'George Swallow (E-mail)'" , "'Vijay Srinivasan'" , "'MPLS Mailing List (E-mail)'" Subject: RE: IP header compression (was "process") Date: Thu, 20 Jul 2000 13:54:30 -0400 Message-ID: <012801bff273$8ee50dc0$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20000720130808.00d85ee0@mail.labn.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I think this discussion is going in the wrong direction. IP header compression has definitely proved very useful, and is still used in most wireless data devices. For instance CDPD devices use IP header compression, and so do many other wireless (cellular) data systems. The case for using mpls header compression is not that straight forward due to this being a router to router mechanism, though I do know instances where routers were placed on wireless links. In a particular network in China, I used a VSAT 64 kbps common channel to route IP traffic from about 60 cities. Each site had an IP router, a few base stations and a switch. We didn't use any dynamic routing, and we only used static routing/bridging to simplify things, and reduce routing protocol overhead. I am not sure if there are any other situations which require a router to be placed on a slow wireless link. There are two issues: 1) understand technical mechanisms to do MPLS header compression and 2) to justify the need of any one ever using it. I think one can discuss the mechanisms (1) but the final decision to proceed should only be taken after a case can be built for its real use. If you put (2 i.e., utility) ahead of (1 i.e., mechanisms), I think many other IDs in the IETF Internet Draft directory will also fail to meet this criteria. I personally think we can briefly discuss mechanisms for the time being, and freeze things after that unless the authors of the draft can make a convincing case for its usage. Let us have no-confrontation mid-path solution. Cheers, --brijesh Ennovate Networks Inc. > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Lou > Berger > Sent: Thursday, July 20, 2000 1:12 PM > To: Eric Gray > Cc: 'Lou Berger'; Eric Gray; George Swallow (E-mail); 'Vijay > Srinivasan'; MPLS Mailing List (E-mail) > Subject: RE: IP header compression (was "process") > > > > At 10:05 AM 7/20/00 -0700, Eric Gray wrote: > >Lou, > > > > I did, as you well know - since you were > >copied. :-) > > Eric, > Your message was directed to me (on both subject > line and in body) > and to Eric R. on subject line. Not the chairs. The chairs > were on cc'ed. From owner-mpls@UU.NET Thu Jul 20 13:57: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 NAA27770 for ; Thu, 20 Jul 2000 13:57:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrn20872; Thu, 20 Jul 2000 17:56:02 GMT Received: by mail-control.mail.uu.net id QQiyrn11534 for mpls-outgoing; Thu, 20 Jul 2000 17:55:33 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiyrn11524 for ; Thu, 20 Jul 2000 17:55: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 QQiyrn20958 for ; Thu, 20 Jul 2000 13:54:56 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyrn20067 for ; Thu, 20 Jul 2000 17:54:55 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id MAA00828; Thu, 20 Jul 2000 12:54:38 -0500 Message-Id: <4.3.2.7.2.20000720134947.00b88f00@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 13:55:05 -0400 To: Eric Gray From: Lou Berger Subject: Re: FW: Process has been circumvented again - was IP header compressi on (was "process") Cc: "Lou Berger (E-mail)" , "MPLS Mailing List (E-mail)" In-Reply-To: <4D3F9F2BEC58D4118FCE009027B0A66213603B@ICARIAN> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk an interesting interpretation of events, but whatever... We can arm wrestle over it in Pittsburgh;-) Lou At 10:51 AM 7/20/00 -0700, Eric Gray wrote: >Lou, > > You have definitely taken this discussion >down a path that does not need to be discussed >on the list - however, since you started it, here >is the message I referred to when I said you were >"copied". > > Now, I think we can stop this particular >thread. > >-- >Eric Gray > > > -----Original Message----- > > From: Eric Gray > > Sent: Wednesday, July 19, 2000 11:32 AM > > To: 'Lou Berger' > > Cc: George Swallow (E-mail); 'Vijay Srinivasan'; Eric Gray > > Subject: RE: Process has been circumvented again > > > > > > George/Vijay/Lou, > > > > Off-list observation. > > > > A key reason for producing minutes is to have a > > public (or at least common) record of what is said and > > done at a meeting. Taking specific action based on > > what you may have heard (or thought you heard :-) at a > > meeting that is not part of the common record makes it > > a useless effort to record minutes. > > > > This is important, because - had I known that we > > were considering adopting these drafts as working group > > documents, I would have been able to prioritize things > > in a way that would have allowed me to review and make > > comments on them. Essentially, I do no see what gains > > you get from compressing the MPLS stack when compared > > to the obvious complexity required to support it. > > > > One tremendously simple modification of one of > > the alternatives you considered is to simply define > > new PPP and Ethernet code points for MPLS unicast and > > multicast encapsulation of compressed IPv4 headers. I > > do not see where there is any value in defining a more > > complex approach than this. I certainly do not see a > > reason to define an approach to compress an MPLS stack > > in addition compressing IP headers. > > > > -- > > Eric Gray > > > > > -----Original Message----- > > > From: Lou Berger [mailto:lberger@labn.net] > > > Sent: Wednesday, July 19, 2000 11:10 AM > > > To: Eric Gray > > > Cc: George Swallow (E-mail); 'Vijay Srinivasan'; MPLS Mailing List > > > (E-mail) > > > Subject: Re: Process has been circumvented again > > > > > > > > > Eric, > > > Yes, you missed it. (Sometimes minutes don't capture > > > the fullness > > > of a discussion, oh well...) There was specific agreement in > > > Adelaide to > > > bring these documents into the working group, i.e., to make them WG > > > documents. At least that's what I witnessed. > > > > > > Lou > > > > > > At 11:00 AM 7/19/00 -0700, Eric Gray wrote: > > > >George/Vijay, > > > > > > > > I don't recall there being a specific consensus > > > >to accept these documents as working group drafts: > > > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-mpls-hdr-comp-00.txt > > > >http://www.ietf.org/internet-drafts/draft-ietf-mpls-hdr-comp- > > over-ppp-00.txt > > > > > > > > > Did I miss it? I noticed that the minutes from > > >Adelaide showed that there was consensus to perform > > >work in this area, but is that the same as accepting > > >these drafts? > > > > > >-- > > >Eric Gray > > From owner-mpls@UU.NET Thu Jul 20 14:18: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 OAA09212 for ; Thu, 20 Jul 2000 14:18:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrp07454; Thu, 20 Jul 2000 18:17:12 GMT Received: by mail-control.mail.uu.net id QQiyrp24260 for mpls-outgoing; Thu, 20 Jul 2000 18:16:47 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQiyrp24245 for ; Thu, 20 Jul 2000 18: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 QQiyrp24995 for ; Thu, 20 Jul 2000 14:16:28 -0400 (EDT) Received: from mailrelay.laurelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laurelnetworks.com [206.67.234.84]) id QQiyrp24683 for ; Thu, 20 Jul 2000 18:16:27 GMT Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id OAA26925; Thu, 20 Jul 2000 14:16:27 -0400 Received: (from jleu@localhost) by localhost.laurelnetworks.com (8.9.3/8.9.3) id OAA02583; Thu, 20 Jul 2000 14:16:27 -0400 Date: Thu, 20 Jul 2000 14:16:27 -0400 From: "James R. Leu" To: "Kullberg, Alan" Cc: mpls@UU.NET Subject: Re: question on generalized MPLS signaling Message-ID: <20000720141627.C873@laurelnetworks.com> Reply-To: jleu@laurelnetworks.com References: <7BF58A904536D411ADD400508BC97B85046B82@xover1.netplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <7BF58A904536D411ADD400508BC97B85046B82@xover1.netplane.com>; from akullber@netplane.com on Thu, Jul 20, 2000 at 10:13:18AM -0400 Organization: Laurel Networks Sender: owner-mpls@UU.NET Precedence: bulk On Thu, Jul 20, 2000 at 10:13:18AM -0400, Kullberg, Alan wrote: > I have been reading draft-ashwood-generalized-mpls-signaling-00.txt > and draft-ietf-mpls-lsp-hierarchy-00.txt and have a question. When > a bidirectional LSP is being signaled, a label stack may be required > in the reverse direction. Can the method described in lsp-hierarchy > be applied in the reverse direction? If so, where does the "strict hop > subsequence" come from? For RSVP, it could come from a record > route object, but for CR-LDP, there is no such record route TLV. What about the Path Vector TLV? In LDP it is used for loop detection it contains the same info as the RRO. Jim -- James R. Leu Software Engineer Laurel Networks, Inc jleu@laurelnetworks.com From owner-mpls@UU.NET Thu Jul 20 14:19: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 OAA09825 for ; Thu, 20 Jul 2000 14:19:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrp08579; Thu, 20 Jul 2000 18:18:19 GMT Received: by mail-control.mail.uu.net id QQiyrp24447 for mpls-outgoing; Thu, 20 Jul 2000 18:18: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 QQiyrp24428 for ; Thu, 20 Jul 2000 18:17: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 QQiyrp25161 for ; Thu, 20 Jul 2000 14:17:31 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyrp07544 for ; Thu, 20 Jul 2000 18:17:16 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA17037 for mpls@uu.net; Thu, 20 Jul 2000 14:17:15 -0400 (EDT) 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 QQiyrp24265 for ; Thu, 20 Jul 2000 18:16: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 QQiyrp25034 for ; Thu, 20 Jul 2000 14:16:44 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyrp06998 for ; Thu, 20 Jul 2000 18:16:44 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 OAA16869 for ; Thu, 20 Jul 2000 14:16:43 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA28796 for ; Thu, 20 Jul 2000 14:16:43 -0400 (EDT) Message-Id: <200007201816.OAA28796@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Consensus on compression Date: Thu, 20 Jul 2000 14:16:43 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Folks, Since there clearly is confusion over whether consensus over adopting draft-ietf-mpls-hdr-comp-over-ppp-00.txt draft-ietf-mpls-hdr-comp-00.txt and since the minutes don't clearly indicate that there was, then we need to start again. So, lets discuss see if we can reach consensus on the list. If a consensus forms, we'll declare it prior to the meeting. If not, we'll allocate a bit of time to discuss it there. Note that this is not a package deal. The two drafts should be considered independently (and on separate threads). ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Jul 20 14:26: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 OAA12993 for ; Thu, 20 Jul 2000 14:26:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrp01888; Thu, 20 Jul 2000 18:24:44 GMT Received: by mail-control.mail.uu.net id QQiyrp24977 for mpls-outgoing; Thu, 20 Jul 2000 18:24: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 QQiyrp24971 for ; Thu, 20 Jul 2000 18:24: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 QQiyrp26314 for ; Thu, 20 Jul 2000 14:23:07 -0400 (EDT) Received: from zrtps06s.us.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [47.140.48.50]) id QQiyrp00400 for ; Thu, 20 Jul 2000 18:22:53 GMT Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Thu, 20 Jul 2000 14:18:19 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 20 Jul 2000 14:18:18 -0400 Message-ID: <03E3E0690542D211A1490000F80836F4029F9818@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'Bala Rajagopalan'" Cc: mpls@UU.NET Subject: RE: I-D ACTION:draft-ietf-mpls-te-feed-01.txt Date: Thu, 20 Jul 2000 14:18:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF276.DF3D6A30" 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_01BFF276.DF3D6A30 Content-Type: text/plain; charset="iso-8859-1" Just for some context ;) The work presented in this draft is derived from a proprietary path oriented routing protocol implemented in 1992 and currently in wide spread deployment. I proposed a similar mechanism to the ATM/PNNI group 5 years or so ago at a Boston meeting but it got watered down to just a trivial crank-back mechanism. Anyway, I'm sure somebody else built something similar before this but what difference does it make? It's a useful mechanism and works well in MPLS too. ATM predates MPLS but we are still doing MPLS ;) Does anybody have any technical comments on this draft? So far I've only had three comments (two from OSLO) which have been incorporated into this latest draft. Cheers, Peter -----Original Message----- From: Bala Rajagopalan [SMTP:braja@alpha.tellium.com] Sent: Thursday, July 20, 2000 1:49 PM Cc: mpls@UU.NET Subject: Re: I-D ACTION:draft-ietf-mpls-te-feed-01.txt Hello: I hate to say this, but similar approaches have been described before: See: Competetive Routing of Virtual Circuits in ATM Networks (1995) by S. Plotkin http://troll-w.stanford.edu/plotkin/jsac95.ps and Routing and Admission Control in General Topology Networks (1995) by Gawlick et al. http://troll-w.stanford.edu/plotkin/bigmu.ps Bala Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : IMPROVING TOPOLOGY DATA BASE ACCURACY WITH LSP > FEEDBACK > Author(s) : P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki > Filename : draft-ietf-mpls-te-feed-01.txt > Pages : 12 > Date : 19-Jul-00 > > One key component of traffic engineering is a concept known as > constraint based routing. In constraint based routing a topology > database is maintained on all participating nodes. This database > contains a complete list of all the links in the network that > participate in traffic engineering and for each of these links a set > of constraints which those links can meet. Bandwidth, for example, > is one essential constraint. Since the bandwidth available changes > as new LSPs are established and terminated the topology database > will develop inconsistencies with respect to the real network. It is > not possible to increase the flooding rates arbitrarily to keep the > database discrepancies from growing. We propose a new mechanism > whereby a source node can learn about the successes or failures of > its path selections by receiving feedback from the paths it is > attempting. This fed-back information can be incorporated into > subsequent route computations, which greatly improves the accuracy > of the overall routing solution by significantly reducing the > database discrepancies. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-01.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-mpls-te-feed-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mpls-te-feed-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <20000719141502.I-D@ietf.org> -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com ------_=_NextPart_001_01BFF276.DF3D6A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-mpls-te-feed-01.txt

Just for some context ;)

The work presented in this draft is = derived from a proprietary path oriented routing protocol implemented = in 1992 and currently in wide spread deployment.

I proposed a similar mechanism to the = ATM/PNNI group 5 years or so ago at a Boston meeting but it got watered = down to just a trivial crank-back mechanism.

Anyway, I'm sure somebody else built = something similar before this but what difference does it make? It's a = useful mechanism and works well in MPLS too. ATM predates MPLS but we = are still doing MPLS ;)

Does anybody have any technical = comments on this draft? So far I've only had three comments (two from = OSLO) which have been incorporated into this latest draft.

Cheers,

Peter



    -----Original = Message-----
    From:   Bala Rajagopalan = [SMTP:braja@alpha.tellium.com]
    Sent:   Thursday, July 20, 2000 1:49 PM
    Cc:     mpls@UU.NET
    Subject:       = Re: I-D = ACTION:draft-ietf-mpls-te-feed-01.txt


    Hello:

    I hate to say this, but similar = approaches have been described before:

    See: Competetive Routing of Virtual = Circuits in ATM Networks (1995) by S. Plotkin

     http://troll-w.stanford.edu/plotkin/jsac95.ps

    and

    Routing and Admission Control in = General Topology Networks (1995) by Gawlick et al.

     http://troll-w.stanford.edu/plotkin/bigmu.ps

    Bala


    Internet-Drafts@ietf.org wrote:

    > A New Internet-Draft is available = from the on-line Internet-Drafts directories.
    > This draft is a work item of the = Multiprotocol Label Switching Working Group of the IETF.
    >
    >         = Title           : = IMPROVING TOPOLOGY DATA BASE ACCURACY WITH LSP
    >         = ;            = ;      FEEDBACK
    >         = Author(s)       : P. Ashwood-Smith, B. = Jamoussi, D. Fedyk, D. Skalecki
    >     &nbs= p;   Filename        : = draft-ietf-mpls-te-feed-01.txt
    >         = Pages           : = 12
    >         = Date            = : 19-Jul-00
    >
    > One key component of traffic = engineering is a concept known as
    > constraint based routing. In = constraint based routing a topology
    > database is maintained on all = participating nodes. This database
    > contains a complete list of all = the links in the network that
    > participate in traffic = engineering and for each of these links a set
    > of constraints which those links = can meet. Bandwidth, for example,
    > is one essential constraint. = Since the bandwidth available changes
    > as new LSPs are established and = terminated the topology database
    > will develop inconsistencies = with respect to the real network. It is
    > not possible to increase the = flooding rates arbitrarily to keep the
    > database discrepancies from = growing. We propose a new mechanism
    > whereby a source node can learn = about the successes or failures of
    > its path selections by receiving = feedback from the paths it is
    > attempting. This fed-back = information can be incorporated into
    > subsequent route computations, = which greatly improves the accuracy
    > of the overall routing solution = by significantly reducing the
    > database discrepancies.
    >
    > A URL for this Internet-Draft = is:
    > http://www.ietf.org/internet-drafts/draft-ietf-mpls-te= -feed-01.txt
    >
    > Internet-Drafts are also = available by anonymous FTP. Login with the username
    > "anonymous" and a = password of your e-mail address. After logging in,
    > type "cd = internet-drafts" and then
    >         = "get draft-ietf-mpls-te-feed-01.txt".
    >
    > A list of Internet-Drafts = directories can be found in
    > http://www.ietf.org/shadow.html
    > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
    >
    > Internet-Drafts can also be = obtained by e-mail.
    >
    > Send a message to:
    >         = mailserv@ietf.org.
    > In the body type:
    >     &nbs= p;   "FILE = /internet-drafts/draft-ietf-mpls-te-feed-01.txt".
    >
    > NOTE:   The mail = server at ietf.org can return the document in
    >         = MIME-encoded form by using the "mpack" utility.  To use = this
    >         = feature, insert the command "ENCODING mime" before the = "FILE"
    >         = command.  To decode the response(s), you will need = "munpack" or
    >         a = MIME-compliant mail reader.  Different MIME-compliant mail = readers
    >         = exhibit different behavior, especially when dealing with
    >         = "multipart" MIME messages (i.e. documents which have been = split
    >         up = into multiple messages), so check your local documentation on
    >         how = to manipulate these messages.
    >
    >
    > Below is the data which will = enable a MIME compliant mail reader
    > implementation to automatically = retrieve the ASCII version of the
    > Internet-Draft.
    >
    >   = ------------------------------------------------------------------------=
    > Content-Type: text/plain
    > = Content-ID:     = <20000719141502.I-D@ietf.org>

    --

    Bala Rajagopalan
    Tellium, Inc.
    2 Crescent Place
    P.O. Box 901
    Oceanport, NJ 07757-0901
    Tel: (732) 923-4237
    Fax: (732) 923-9804
    Email: braja@tellium.com

------_=_NextPart_001_01BFF276.DF3D6A30-- From owner-mpls@UU.NET Thu Jul 20 14:33: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 OAA16792 for ; Thu, 20 Jul 2000 14:33:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrq08799; Thu, 20 Jul 2000 18:32:28 GMT Received: by mail-control.mail.uu.net id QQiyrq25520 for mpls-outgoing; Thu, 20 Jul 2000 18:31: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 QQiyrq25515 for ; Thu, 20 Jul 2000 18:31:42 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyrq25857 for ; Thu, 20 Jul 2000 14:31:36 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiyrq18569 for ; Thu, 20 Jul 2000 18:31:05 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA07106 for ; Thu, 20 Jul 2000 11:31:18 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA00782 for mpls@uu.net; Thu, 20 Jul 2000 14:31:04 -0400 (EDT) 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 QQiyrp25060 for ; Thu, 20 Jul 2000 18: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 QQiyrp26614 for ; Thu, 20 Jul 2000 14:24:43 -0400 (EDT) Received: from fire.integralaccess.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.160.25.239]) id QQiyrp13521 for ; Thu, 20 Jul 2000 18:24:28 GMT Received: from akankkunen [192.168.1.22] by fire.integralaccess.com (SMTPD32-6.03) id A4A51F0112; Thu, 20 Jul 2000 14:27:49 -0400 From: "Antti Kankkunen" To: , Subject: draft-kankkunen-vompls-fw-01.txt Date: Thu, 20 Jul 2000 14:25:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit FYI A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Voice over MPLS Framework Author(s) : A. Kankkunen, G. Ash, A. Chiu, J. Hopkins, J. Jeffords, F. Le Faucheur, B. Rosen, D. Stacey, A. Yelundur, L. Berger Filename : draft-kankkunen-vompls-fw-01.txt Pages : 58 Date : 19-Jul-00 This document provides a Framework for using MPLS as one underlying technology alternative for transporting VoIP based public voice services. The document defines a reference model for VoIP over MPLS, defines some specific applications for VoIP over MPLS and identifies potential further standardization work that is necessary to support these applications. The annexes of the document discuss the types of requirements that voice services set on the under laying transport infrastructure A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kankkunen-vompls-fw-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kankkunen-vompls-fw-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kankkunen-vompls-fw-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. draft-kankkunen-vompls-fw-01.txt ------------------- Antti Kankkunen Integral Access Inc. 6 Omni Way Chelmsford, MA 01824 Phone: +1 978 256 8833 x 232 Mobile: +1 617 513 2172 Fax: +1 978 256 8077 e-mail: anttik@integralaccess.com From owner-mpls@UU.NET Thu Jul 20 15:07: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 PAA03123 for ; Thu, 20 Jul 2000 15:07:18 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrs16802; Thu, 20 Jul 2000 19:06:06 GMT Received: by mail-control.mail.uu.net id QQiyrs08914 for mpls-outgoing; Thu, 20 Jul 2000 19:05:28 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiyrs08909 for ; Thu, 20 Jul 2000 19:05: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 QQiyrs01832 for ; Thu, 20 Jul 2000 15:05:02 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyrs05757 for ; Thu, 20 Jul 2000 19:04:46 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id OAA24718; Thu, 20 Jul 2000 14:04:26 -0500 Message-Id: <4.3.2.7.2.20000720145607.00dd94e0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 15:04:56 -0400 To: George Swallow From: Lou Berger Subject: Re: Consensus on compression Cc: mpls@UU.NET In-Reply-To: <200007201816.OAA28796@lir.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 02:16 PM 7/20/00 -0400, George Swallow wrote: >Folks, > >Since there clearly is confusion over whether consensus over adopting > > draft-ietf-mpls-hdr-comp-over-ppp-00.txt > draft-ietf-mpls-hdr-comp-00.txt > >and since the minutes don't clearly indicate that there was, then we >need to start again. So, lets discuss see if we can reach consensus >on the list. If a consensus forms, we'll declare it prior to the >meeting. If not, we'll allocate a bit of time to discuss it there. > >Note that this is not a package deal. The two drafts should be >considered independently (and on separate threads). > >...George > > >====================================================================== >George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 I think the enclosed excerpt from the Adelaide meeting minutes accurately summarizes the drafts and presentation (available at http://www.labn.net/lberger/docs/cmpls-0003.pdf). The bit naming issue is resolved in the recently posted rev of the draft. Lou [Source: http://cell.onecall.net/mhonarc/mpls/2000-May/msg00352.html] 'MPLS/IP Header Compression', , Lou Berger Lou Berger began by enumerating the objectives of the MPLS/IP header compression draft. In particular, to enable header compression for MPLS encapsulated traffic and to optimize for maximum compression. He mentioned that end-to-end compression was not a requirement and that it was targeted at 'lower speed' links, where lower speed was not specified but was hardware-specific. He mentioned that the key consideration was whether MPLS headers are compressed. He went on to cover two options: 1) end-to-end with header compression over MPLS, and 2) link-by-link with compression of MPLS/IP headers. Subsequently, he discussed the pros and cons of each approach, concluding that both are reasonable depending on the application. He then outlined the basic approach. That is, it begins with standard IP header compression, then support for compression of MPLS packets is added, where the first draft preserves the standard compression header (2 bytes, 4 bytes when UDP checksums are used, and +1 byte per EXP field change). He stated that it does not increase with more MPLS headers. And, that the second draft, , defines PPP link layer support, which parallels RFC 2509 (IP header compression over PPP). He concluded by highlighting two issues. First, the bit naming collision with draft-koren-avt-crtp-enhace-01.txt, and second, he remarked that it was not clear which IETF working group this work should proceed in. From owner-mpls@UU.NET Thu Jul 20 15:39: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 PAA19256 for ; Thu, 20 Jul 2000 15:39:25 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyru23874; Thu, 20 Jul 2000 19:38:13 GMT Received: by mail-control.mail.uu.net id QQiyru12497 for mpls-outgoing; Thu, 20 Jul 2000 19:37: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 QQiyru12474 for ; Thu, 20 Jul 2000 19:37: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 QQiyru09216 for ; Thu, 20 Jul 2000 15:36:49 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyru21706 for ; Thu, 20 Jul 2000 19:36:34 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA02453 for mpls@uu.net; Thu, 20 Jul 2000 15:36:33 -0400 (EDT) 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 QQiyru12262 for ; Thu, 20 Jul 2000 19:35: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 QQiyru08971 for ; Thu, 20 Jul 2000 15:35:30 -0400 (EDT) Received: from ihemail2.firewall.lucent.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQiyru20573 for ; Thu, 20 Jul 2000 19:35:30 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA25304 for ; Thu, 20 Jul 2000 15:35:30 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id PAA25300 for ; Thu, 20 Jul 2000 15:35:29 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Jul 2000 20:35:28 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C04876F46@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'MPLS Mailing List (E-mail)'" Subject: RE: IP header compression Date: Thu, 20 Jul 2000 20:35:27 +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 > ---------- > From: tom worster[SMTP:tom@ennovatenetworks.com] > Sent: 20 July 2000 18:49 > To: 'Bora Akyol' > Cc: 'MPLS Mailing List (E-mail)' > Subject: RE: IP header compression > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora > Akyol > > > > I thought 3G speeds were up to 2Mbps. If they are still at > > 9.6Kbps then they > > should named (-1)G. > > in 3g it can, and will, change rapidly from one to the other. > > > > Seriously, why not run IP with VJ compression instead of MPLS > > all the way to > > the mobile phones. What else does MPLS buy you? > > as i recall: the ip version of 3g needs a tunnel from the > serving node down to the terminal. the ones they use in > gprs are way clunky for a big high speed network. mpls > fits the bill and, as a bonus, has this neat header > compression feature built right in. since the tunnel > can cross several hops, mpls works better than datalink > compression. > > i don't work on that stuff so don't take my word. maybe > there's a 3g expert on the list who can give you a better > answer. > > > > In UMTS two GTP (GPRS Tunnelling Protocol)tunnels between RNC and SGSN and between SGSN and GGSN (don't care about the names) are concatenated to deliver packets to the radio link to the User Equipment. this is the protocol stack if such tunnels would run over MPLS: MPLS/IP/UDP/GTP/IP If we want to do voice over IP in this system MPLS/IP/UDP/GTP/IP/UDP/RTP The overhead for a voice frame is around 500-600% I would guess we could do something about it. So, let's compress. alessio From owner-mpls@UU.NET Thu Jul 20 15:44: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 PAA21829 for ; Thu, 20 Jul 2000 15:44:41 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyru00600; Thu, 20 Jul 2000 19:43:13 GMT Received: by mail-control.mail.uu.net id QQiyru13079 for mpls-outgoing; Thu, 20 Jul 2000 19:42:31 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiyru13003 for ; Thu, 20 Jul 2000 19:42:18 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyru10296 for ; Thu, 20 Jul 2000 15:41:56 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiyru28571 for ; Thu, 20 Jul 2000 19:41:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA03678 for mpls@uu.net; Thu, 20 Jul 2000 15:41:40 -0400 (EDT) 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 QQiyru12953 for ; Thu, 20 Jul 2000 19:41: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 QQiyru08807 for ; Thu, 20 Jul 2000 15:41:03 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQiyru08860 for ; Thu, 20 Jul 2000 19:40: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 MAA27248; Thu, 20 Jul 2000 12:40:45 -0700 (PDT) Message-ID: <397755BC.BEC178AC@pluris.com> Date: Thu, 20 Jul 2000 12:40:45 -0700 From: Bora Akyol X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Casati, Alessio (Alessio)" CC: "'MPLS Mailing List (E-mail)'" Subject: Re: IP header compression References: <976F7C55E3B2D111A0720008C728549C04876F46@en0060exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Why not run voice just like they do in the current GSM network, and use IP for data. Much cleaner, IMHO. Bora "Casati, Alessio (Alessio)" wrote: > > ---------- > > From: tom worster[SMTP:tom@ennovatenetworks.com] > > Sent: 20 July 2000 18:49 > > To: 'Bora Akyol' > > Cc: 'MPLS Mailing List (E-mail)' > > Subject: RE: IP header compression > > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora > > Akyol > > > > > > I thought 3G speeds were up to 2Mbps. If they are still at > > > 9.6Kbps then they > > > should named (-1)G. > > > > in 3g it can, and will, change rapidly from one to the other. > > > > > > > Seriously, why not run IP with VJ compression instead of MPLS > > > all the way to > > > the mobile phones. What else does MPLS buy you? > > > > as i recall: the ip version of 3g needs a tunnel from the > > serving node down to the terminal. the ones they use in > > gprs are way clunky for a big high speed network. mpls > > fits the bill and, as a bonus, has this neat header > > compression feature built right in. since the tunnel > > can cross several hops, mpls works better than datalink > > compression. > > > > i don't work on that stuff so don't take my word. maybe > > there's a 3g expert on the list who can give you a better > > answer. > > > > > > > > > In UMTS two GTP (GPRS Tunnelling Protocol)tunnels between > RNC and SGSN and between SGSN and GGSN (don't care about the names) > are concatenated to deliver packets to the radio link to > the User Equipment. > > this is the protocol stack if such tunnels would run over MPLS: > > MPLS/IP/UDP/GTP/IP > > If we want to do voice over IP in this system > > MPLS/IP/UDP/GTP/IP/UDP/RTP > > The overhead for a voice frame is around 500-600% > > I would guess we could do something about it. > > So, let's compress. > > alessio From owner-mpls@UU.NET Thu Jul 20 15:49:27 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24242 for ; Thu, 20 Jul 2000 15:49:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrv06580; Thu, 20 Jul 2000 19:48:18 GMT Received: by mail-control.mail.uu.net id QQiyrv13743 for mpls-outgoing; Thu, 20 Jul 2000 19:47: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 QQiyrv13737 for ; Thu, 20 Jul 2000 19:47: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 QQiyrv11223 for ; Thu, 20 Jul 2000 15:47:29 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQiyrv05260 for ; Thu, 20 Jul 2000 19:47:13 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <36QHD3H3>; Thu, 20 Jul 2000 12:54:22 -0700 Message-ID: <4D3F9F2BEC58D4118FCE009027B0A662136040@ICARIAN> From: Eric Gray To: "MPLS Mailing List (E-mail)" Cc: "'George Swallow'" Subject: RE: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Date: Thu, 20 Jul 2000 12:54:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Folks, My technical comments. I do not think the statement - "Since the header following the link layer header is no longer IP, the existing compression techniques will not operate" - which appears in the abstract of the ID entitled "MPLS/IP Header Compression" has been given enough thought. This statement points out that this draft may be setting a precedent for how MPLS works when the link layer needs to indicate that the data frame is not IP (because it is MPLS) and the data encapsulated is not standard IP (because - in this case - it is compressed IP header). Also, it is possible to choose an approach that makes this statement invalid. I do not think that the precedent this draft may set is a good one. While the draft states that the alternative of using IP header compression - as is - over MPLS was considered, I think this option was too quickly dismissed. One of the reasons it was dismissed was that MPLS headers do not carry packet type codes. In making this decision in design of MPLS, we setup a general requirement to define new type codes for applicable link layers WHEN IT IS IMPORTANT FOR AN INTERMEDIATE LSR TO KNOW THE PROTOCOL OF THE DATA PACKET ENCAPSULATED BY MPLS. Hence, if we determine that there is a need for intermediate LSRs to know that the MPLS encapsulated packet uses IP header compression, then we might be justified in defining new link layer discriminators (packet type codes) for such packets when transported over MPLS. This draft fails completely to justify a need for intermediate LSRs to understand that MPLS packets may encapsulate compressed IP headers. In fact, the possibility that there may be intermediate LSRs is not sufficiently explored, since this possibility implies the further possibility of needing to stack additional MPLS labels (this is discussed below). If it is not important for intermediate LSRs to understand that header compression is used, then one very good approach is to define extensions to a signaling protocol such that each end of an LSP will know that the LSP itself is being used to transport IP-header-compressed data packets. This alternative does not appear to have been considered. Yet this is the alternative currently used most often to deal with LSP end-to-end requirements. Such an approach should be straight-forward and should have no impact on LSRs that do not need to support this capability. A second reason for dismissing other approaches was that additional compression efficiency could be obtained by compressing the MPLS shim header as well. I do not see that the potential for compressing one 32 bit word justifies the proposal. Further, I doubt the existence of an application for multiple stacked labels being transported across a low-speed link - thus it does not seem likely that the MPLS shim header will be much larger than 32 bits. Which is a segue into problems with intermediate LSRs: the possible existence of intermediate LSRs means that there might be a need to further encapsulate an MPLS labeled packet by pushing on an additional label. For example, the low-speed link might be carried in an LSP trunk. If an LSR is faced with the need of adding a label to the stack of an MPLS-header-compressed packet, how is this done? Is there an impact if there is a need to further stack labels as the packet is progressed toward the core of a network? I think there is an impact in the current proposal. I also feel certain there is not in either proposal I would make (have made, if you read the above carefully). I believe that - unless the current proposal can provide a means to preclude its use across low-speed links that are transported using LSP trunks - this proposal will have far reaching implications on not-so-slow links. Hence, I feel this draft uses the wrong approach at a very fundamental level and do not feel that it is the approach that the MPLS working group should adopt. -- Eric Gray > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Thursday, July 20, 2000 11:17 AM > To: mpls@UU.NET > Subject: Consensus on compression > > > Folks, > > Since there clearly is confusion over whether consensus over adopting > > draft-ietf-mpls-hdr-comp-over-ppp-00.txt > draft-ietf-mpls-hdr-comp-00.txt > > and since the minutes don't clearly indicate that there was, then we > need to start again. So, lets discuss see if we can reach consensus > on the list. If a consensus forms, we'll declare it prior to the > meeting. If not, we'll allocate a bit of time to discuss it there. > > Note that this is not a package deal. The two drafts should be > considered independently (and on separate threads). > > ...George > > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > > From owner-mpls@UU.NET Thu Jul 20 15:53: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 PAA26268 for ; Thu, 20 Jul 2000 15:53:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrv11630; Thu, 20 Jul 2000 19:52:16 GMT Received: by mail-control.mail.uu.net id QQiyrv14164 for mpls-outgoing; Thu, 20 Jul 2000 19:51:43 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiyrv14150 for ; Thu, 20 Jul 2000 19:51: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 QQiyrv12032 for ; Thu, 20 Jul 2000 15:51:23 -0400 (EDT) Received: from prue.eim.surrey.ac.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: prue.eim.surrey.ac.uk [131.227.76.5]) id QQiyrv10576 for ; Thu, 20 Jul 2000 19:51:23 GMT Received: from petra.ee.surrey.ac.uk ([131.227.88.13] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.03 #1) id 13FMLl-0003ub-00; Thu, 20 Jul 2000 20:51:17 +0100 Date: Thu, 20 Jul 2000 20:51:14 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: L.Wood@eim.surrey.ac.uk To: Bora Akyol cc: "Casati, Alessio (Alessio)" , "'MPLS Mailing List (E-mail)'" Subject: Re: IP header compression In-Reply-To: <397755BC.BEC178AC@pluris.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 20 Jul 2000, Bora Akyol wrote: > Why not run voice just like they do in the current GSM network, and use > IP for data. Much cleaner, IMHO. telco operators have a rather different understanding of what 'use IP for data' means. L. PGP From owner-mpls@UU.NET Thu Jul 20 15:57: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 PAA28194 for ; Thu, 20 Jul 2000 15:57:22 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyrv22060; Thu, 20 Jul 2000 19:55:37 GMT Received: by mail-control.mail.uu.net id QQiyrv14481 for mpls-outgoing; Thu, 20 Jul 2000 19:55: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 QQiyrv14451 for ; Thu, 20 Jul 2000 19:54: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 QQiyrv11300 for ; Thu, 20 Jul 2000 15:54:40 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQiyrv14109 for ; Thu, 20 Jul 2000 19:54:24 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <36QHD32N>; Thu, 20 Jul 2000 13:01:33 -0700 Message-ID: <4D3F9F2BEC58D4118FCE009027B0A662136041@ICARIAN> From: Eric Gray To: "MPLS Mailing List (E-mail)" Cc: "'George Swallow'" Subject: RE: Consensus on compression - draft-ietf-mpls-hdr-comp-over-ppp- 00.txt Date: Thu, 20 Jul 2000 13:01:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Folks, Based on my comments on the other draft, I do not think this draft may be applicable to the problem the two drafts attempt to address. I do not think I need to repeat my comments on the other draft, on this thread, but they may be summarized by saying that I feel that the approach used is fundamentally incorrect. -- Eric Gray > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Thursday, July 20, 2000 11:17 AM > To: mpls@UU.NET > Subject: Consensus on compression > > > Folks, > > Since there clearly is confusion over whether consensus over adopting > > draft-ietf-mpls-hdr-comp-over-ppp-00.txt > draft-ietf-mpls-hdr-comp-00.txt > > and since the minutes don't clearly indicate that there was, then we > need to start again. So, lets discuss see if we can reach consensus > on the list. If a consensus forms, we'll declare it prior to the > meeting. If not, we'll allocate a bit of time to discuss it there. > > Note that this is not a package deal. The two drafts should be > considered independently (and on separate threads). > > ...George > > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > > From owner-mpls@UU.NET Thu Jul 20 17:13: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 RAA06704 for ; Thu, 20 Jul 2000 17:13:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiysa24469; Thu, 20 Jul 2000 21:12:25 GMT Received: by mail-control.mail.uu.net id QQiysa15508 for mpls-outgoing; Thu, 20 Jul 2000 21:11:04 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiysa15425 for ; Thu, 20 Jul 2000 21:10: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 QQiysa24094 for ; Thu, 20 Jul 2000 17:10:17 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiysa22501 for ; Thu, 20 Jul 2000 21:10:02 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id QAA00422; Thu, 20 Jul 2000 16:09:42 -0500 Message-Id: <4.3.2.7.2.20000720160408.00e5b210@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 17:10:17 -0400 To: Eric Gray From: Lou Berger Subject: RE: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Cc: "MPLS Mailing List (E-mail)" , "'George Swallow'" In-Reply-To: <4D3F9F2BEC58D4118FCE009027B0A662136040@ICARIAN> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Eric, I guess I managed to get your attention:-) I'll try to respond to your specific points in-line below. First a couple of general comments: - The draft in question only compresses data between two MPLS nodes. (Just like IP/UDP/RTP compression.) Multinode compression is covered in the -simple draft and is useful when there are different optimization requirement. - It is intended for use on links where per packet transmission overhead is critical. - It is a minor extension to RFC2207/8 and operates basically in the same fashion. At 12:54 PM 7/20/00 -0700, Eric Gray wrote: >Folks, > > My technical comments. > > I do not think the statement - > >"Since the header following the link layer header > is no longer IP, the existing compression techniques > will not operate" > >- which appears in the abstract of the ID entitled >"MPLS/IP Header Compression" has been given enough >thought. I don't see how you can argue with the statement. Current IP header compression [RFC2507, 2508, 2509] relies on the IP header immediately following the PPP header. That's the way it's specified. What's the argument. > This statement points out that this draft may >be setting a precedent for how MPLS works when the >link layer needs to indicate that the data frame is >not IP (because it is MPLS) and the data encapsulated >is not standard IP (because - in this case - it is >compressed IP header). I can't figure out what "precedent" you are referring to. The traffic is standard IP not compressed IP. IP header compression is done one a link by link basis. From the compressing node's perspective the data is standard IP. The draft enables the compressing node to compress the MPLS/IP and other headers (to 2 or 4 bytes). If running MPLS, the current alternative is to send uncompressed MPLS/IP/UDP headers (40 bytes + 4 bytes/mpls hdr). >Also, it is possible to choose >an approach that makes this statement invalid. Again, the earlier statement is one of fact not opinion. > I do not think that the precedent this draft >may set is a good one. Again, what precedent? >While the draft states that >the alternative of using IP header compression - as >is - over MPLS was considered, I think this option >was too quickly dismissed. A minor note, a replacement for rfc2509 would need to be written to enable this. > One of the reasons it was dismissed was that >MPLS headers do not carry packet type codes. In >making this decision in design of MPLS, we setup a >general requirement to define new type codes for >applicable link layers WHEN IT IS IMPORTANT FOR AN >INTERMEDIATE LSR TO KNOW THE PROTOCOL OF THE DATA >PACKET ENCAPSULATED BY MPLS. Hence, if we determine >that there is a need for intermediate LSRs to know >that the MPLS encapsulated packet uses IP header >compression, then we might be justified in defining >new link layer discriminators (packet type codes) >for such packets when transported over MPLS. I don't think you mean intermediate LSR here, next hop or downstream is accurate. (remember such compression is hop-by-hop.) The general comment is still valid, while a bit awkward, we could use link layer types to indicated they type of data being carried within the MPLS stack. As the document states, this issue wasn't the critical one. From the same paragraph in the document: [...] The second and more important reason for not adapting compression to operate over MPLS was simply to gain extra efficiency by enabling the compression of the MPLS label stack. The delta here is from (2 or 4 bytes + 4bytes/mpls header) versus 2 or 4 bytes. > This draft fails completely to justify a need >for intermediate LSRs to understand that MPLS packets >may encapsulate compressed IP headers. Again, I don't get this statement. The proposed compression is hop-by-hop. The compression may be done on a per link basis. Multinode compression is covered in the "-simple" scheme. Yes, each end of the link need to agree on doing compression and needs to understand that it's compressing IP. The justification is 44 bytes compressed to 2 or 4 bytes. I think the draft made this clear. >In fact, the >possibility that there may be intermediate LSRs is >not sufficiently explored, since this possibility >implies the further possibility of needing to stack >additional MPLS labels (this is discussed below). Again, the discussed scheme operates on *single* links only. A compressed header is never seen by a non-supporting nodes. This is how rfc2507 and 2508 operate. > If it is not important for intermediate LSRs >to understand that header compression is used, then >one very good approach is to define extensions to a >signaling protocol such that each end of an LSP will >know that the LSP itself is being used to transport >IP-header-compressed data packets. This alternative >does not appear to have been considered. Yet this >is the alternative currently used most often to deal >with LSP end-to-end requirements. Such an approach >should be straight-forward and should have no impact >on LSRs that do not need to support this capability. This alternative is described in the "-simple" scheme (draft-swallow-mpls-simple-hdr-compress-00.txt.) As mentioned in Adelaide and reflected in the minutes both schemes have their place. > A second reason for dismissing other approaches >was that additional compression efficiency could be >obtained by compressing the MPLS shim header as well. >I do not see that the potential for compressing one >32 bit word justifies the proposal. Further, I doubt >the existence of an application for multiple stacked >labels being transported across a low-speed link - >thus it does not seem likely that the MPLS shim header >will be much larger than 32 bits. I don't everyone would agree with this statement. Think MPLS based access links that support VPNs, as one example. > Which is a segue into problems with intermediate >LSRs: the possible existence of intermediate LSRs means >that there might be a need to further encapsulate an >MPLS labeled packet by pushing on an additional label. Again, "intermediate node" just doesn't apply to this draft. >For example, the low-speed link might be carried in an >LSP trunk. What does this mean? If you mean that at least the PPP header and above is encapsulated, than there's no issue. It's the same issue as handling IP header compression over low-speed links. (BTW how are you planing on doing this?) If you means something else, you have to define what you're talking about. >If an LSR is faced with the need of adding >a label to the stack of an MPLS-header-compressed packet, >how is this done? Is there an impact if there is a >need to further stack labels as the packet is progressed >toward the core of a network? I don't believe these questions apply. Per standard IP header compression the receiving link decompresses the received packet and then forwards a standard, uncompressed packet. The compression process may be repeated on the outgoing interface but this is independent of how the packet was received. > I think there is an impact in the current proposal. >I also feel certain there is not in either proposal I >would make (have made, if you read the above carefully). >I believe that - unless the current proposal can provide >a means to preclude its use across low-speed links that >are transported using LSP trunks - this proposal will >have far reaching implications on not-so-slow links. This single issue should be addressed the same way as when low-speed links carrying compressed IP headers are transported using LSP trunks. Again, I'm also not sure what "low-speed links that are transported using LSP trunks" means. Will you define this? Are you talking about some proprietary approach? > Hence, I feel this draft uses the wrong approach >at a very fundamental level and do not feel that it is >the approach that the MPLS working group should adopt. Given my comments, it seems to me that you had some fundamental misunderstandings of the draft. Furthermore your major objections is too nebulous to respond to in a substantive way. (And as long as whatever solution you propose supports standard IP header compression, per RFCs 2507 and 2508, the presented approach *will* work.) Please respond and elaborate. Thank you, Lou >-- >Eric Gray > > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Thursday, July 20, 2000 11:17 AM > > To: mpls@UU.NET > > Subject: Consensus on compression > > > > > > Folks, > > > > Since there clearly is confusion over whether consensus over adopting > > > > draft-ietf-mpls-hdr-comp-over-ppp-00.txt > > draft-ietf-mpls-hdr-comp-00.txt > > > > and since the minutes don't clearly indicate that there was, then we > > need to start again. So, lets discuss see if we can reach consensus > > on the list. If a consensus forms, we'll declare it prior to the > > meeting. If not, we'll allocate a bit of time to discuss it there. > > > > Note that this is not a package deal. The two drafts should be > > considered independently (and on separate threads). > > > > ...George > > > > > > ====================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > > > > > From owner-mpls@UU.NET Thu Jul 20 21:22: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 VAA19783 for ; Thu, 20 Jul 2000 21:22:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiysq01196; Fri, 21 Jul 2000 01:14:32 GMT Received: by mail-control.mail.uu.net id QQiysq23717 for mpls-outgoing; Fri, 21 Jul 2000 01:13:45 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiysq23704 for ; Fri, 21 Jul 2000 01:13: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 QQiysq24969 for ; Thu, 20 Jul 2000 21:13:23 -0400 (EDT) Received: from exchange.sd.osicom.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [131.143.32.20]) id QQiysq29924 for ; Fri, 21 Jul 2000 01:13:06 GMT Received: by exchange.sd.osicom.com with Internet Mail Service (5.5.2650.21) id ; Thu, 20 Jul 2000 18:12:17 -0700 Message-ID: From: "Guo, Dan" To: "'Lou Berger'" , "Zhang, Leah" Cc: Jonathan Lang , "Fu, James" , mpls@UU.NET Subject: RE: A new draft. Date: Thu, 20 Jul 2000 18:11:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF2B0.B5EA20D0" 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_01BFF2B0.B5EA20D0 Content-Type: text/plain; charset="iso-8859-1" Lou, Janathan and Leah, The new generalized draft (just released) is an excellent piece for our work. To all of us working in this area, it is very helpful. Our draft came out of our practical work. After carefully examining the issues, I feel it may add to the generalized draft in the following aspects - 1. Wavelength continuety issue to MPLS for some types of networks: we feel it is of importance. 2. Contention scenario 2 outlined in Janathon's email: Our approach naturally AVOIDs the problem. The approach by Janathan (as well as in the Generalized draft) is a valid one to RESOLVE contention. The difference is, we are for Contention-avoidance and the other approach (through PathErr) is for Contention-resolution (as result, one node loses and has to start over). Our approach lowers the chance to get into the trap of contention. I also want to raise one point: The contention scenario 2 (outlined by Janathon) occurs NOT because "there are only enough resources for one of the bi-directional LSPs" as mentioned in Janathon's email. It can still happen when there are plenty of resources but two neighboring nodes grab the same link due to not-knowing-each-other's-actions. It is a race condition due to lack of synchronization. 3. Contention scenario 1 outlined in Janathon's email: our approach, at the current form, cannot avoid it. One way is to borrow the idea from Janathon's approach using IP address. There could be other way. we will follow up on this. We incline to change as little as possible to RSVP-TE (ie. not to allocate label in Path msg and change the nature of receiver-initiating in RSVP). This is why we use ResvErr in our draft. Other way (like Confirm, or Path) can be used for this ONE-HOP informing the label allocation. I hope the generalized draft by Janathan/Lou and others can absorb some of points in our drafts. Best regards, Dan -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Thursday, July 20, 2000 9:08 AM To: 'Zhang, Leah' Cc: Jonathan Lang; Fu, James; mpls@UU.NET Subject: RE: A new draft. Zhang, Pair-wise/simultaneous label allocation for bidirectional LSPs is supported in draft-generalized-signaling-mpls-00.txt. To achieve pair-wise/simultaneous label allocation for bidirectional LSPs, you'd use label set with just a single element (label). This would required the use of the passed label by the downstream node. Is there anything else covered in your draft that isn't addressed in the generalized draft? Lou At 03:37 PM 7/19/00 -0700, Jonathan Lang wrote: >Zhang, > >The tying together of the upstream and downstream label can be done using >the Suggested Label that is also proposed in >draft-lang-mpls-rsvp-oxc-00.txt (updated and included in >draft-generalized-signaling-mpls-00.txt). > >-Jonathan >>-----Original Message----- >>From: Zhang, Leah [mailto:leahz@sorrentonet.com] >>Sent: Wednesday, July 19, 2000 2:27 PM >>To: 'Jonathan Lang'; Fu, James; mpls@UU.NET >>Subject: RE: A new draft. >> >>Jonathan: >> >> Thanks very much for your comments. We read your draft very >> carefully. There are a lot of good thoughts and points in your >> draft. Please see our response below. >> >> >>James Fu, Dan Guo, Raymond Cheng, Leah Zhang >> >>Sorrento Networks Inc. >>9990 Mesa Rim Road >>San Diego, CA 92121 >> >> >> -----Original Message----- >>From: Jonathan Lang [mailto:jplang@calient.net] >>Sent: Tuesday, July 18, 2000 6:04 PM >>To: 'Fu, James'; mpls@UU.NET >>Cc: Jonathan Lang >>Subject: RE: A new draft. >>James, >> I read your draft and I'm afraid you have misunderstood the >> bi-directional approach of draft-lang-mpls-rsvp-oxc-00.txt (updated and >> included in draft-generalized-signaling-mpls-00.txt). The process of >> establishing a bi-directional LSP is the same as the establishment of a >> unidirectional LSP with the exception that an Upstream Label is added to >> the Path message. (Incidentally, the flow of the Upstream Label is the >> same as the normal flow of a Label would be for the upstream segment of >> a bi-directional LSP, except that we have short-circuited sending the >> Path message upstream -- see example below). >> >>We understand your approach of assigning Upstream Label in the Path >>message, and assigning Downstream Label in the Resv message. In your >>approach, the assignment of Upstream Label and >>the assignment of Downstream Label is not tied together. We think that to >>support bi-directional LSP, it is important to do pair-wise assignment >>(or reservations) at the SAME time. This becomes especially >>important in the transparent pure optical networks where wavelength >>continuity is required. >> >> >>Contention may occur for the following reasons: >>1) If there is a requirement that the input/output ports for the >>bi-directional path be tied together (e.g., if they must be on the same >>physical I/O card). Since these are assigned by different OXCs, >>contention may occur. The scheme that you have proposed will also have >>this contention scenario. >>We admit that we did not consider this requirement at the time we wrote >>the draft. We defines the >>contention specifically as two OXCs trying to assign labels for the same >>link. This contention scenario, though, happens much less often than the >>contention scenario where two OXCs trying to assign labels for the same link >> >> >>2) If two bi-directional LSPs are attempted to be established >>simultaneously in opposite directions and there are only enough resources >>for one of the bi-directional LSPs. In this case, one of the LSPs cannot >>be established along that path. The scheme that you propose avoids this >>contention, I assume, by resource checking on the Path message and >>sending a PathError message to the losing LSP. This is also how it is >>done in draft-lang-mpls-rsvp-oxc-00.txt. >>We agree to this assessment. >> >> >>On another note, I think overloading the ResvError message for label >>allocation is a bad idea. >> >>We are not fond of this solution, too. However, this is a better >>compromised solution at moment compared with that a new LMP has to be >>used together with the RSVP extensions. . We are open to any good >>alternatives and suggestions. >> >>To summarize, we think that to support bi-directional LSP (OSP), >>pair-wise label assignment scheme is better than uni -directional label >>assignment schemes. This becomes especially important to support >>wavelength continuity requirement in transparent optical networks. We >>will modify our draft. A new version will come out soon. >> >> >>Regards, >>Jonathan >> >>Example: >> >>downstream -----> >>upstream <----- >> >>(1) RSVP-TE used to establish a bi-directional LSP: >> >>+-+-+ Path(Label Request) +-+-+ Path(Label Request) >>+-+-+ Path(LabelRequest) >> | | ---------------------------> | | >> ---------------------------> | | ---------------------------> >>+ + Resv(Label) + + Resv(Label) + + >> Resv(Label) >> | | <--------------- | | <--------------- >> | | <---------------- >>+ A + + B >>+ + C + >> | | Path(Label Request) | | Path(Label >> Request) | | Path(LabelRequest) >>+ + <--------------------------- + + <-------------------------- >> + + <------------------------ >> | | Resv(Label) | | Resv(Label) >> | | Resv(Label) >>+-+-+ --------------------------> +-+-+ --------------------------> >>+-+-+ ------------------------> >> >>(2) bi-directional LSP using draft-lang-mpls-rsvp-oxc.txt >> >>+-+-+ Path(Label Request, +-+-+ Path(Label Request) >>+-+-+ Path(LabelRequest) >> | | UpstreamLabel) | | UpstreamLabel) | | >> UpstreamLabel) >>+ + ---------------------------> + + >>---------------------------> + + ---------------------------> >> | | | | >> | | >>+ A + + B >>+ + C + >> | | Resv(Label) | | Resv(Label) >> | | Resv(Label) >>+ + <--------------------------- + + <-------------------------- >> + + <------------------------ >> | | | | >> | | >>+-+-+ +-+-+ >> +-+-+ >> >>>-----Original Message----- >>>From: Fu, James [mailto:jfu@sorrentonet.com] >>>Sent: Tuesday, July 18, 2000 9:39 AM >>>To: mpls@UU.NET >>>Subject: A new draft. >>> >>>An Internet Draft entitled "Extensions to RSVP-TE for Bi-directional >>>Optical Path Setup" has been submitted to the IETF. >>> >>>ht tp://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt >>> >>> >>>James Fu >>>Sorrento Networks Inc. >>>9990 Mesa Rim Road >>>San Diego, CA 92121 >>> >>>jfu@sorrentonet.com ------_=_NextPart_001_01BFF2B0.B5EA20D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A new draft.

Lou, Janathan and Leah,

The new generalized draft (just released) is an = excellent piece for our work. To all
of us working in this area, it is very helpful. =

Our draft came out of our practical work. After = carefully examining the issues,
I feel it may add to the generalized draft in the = following aspects -

   1. Wavelength continuety issue to MPLS = for some types of networks: we feel
      it is of importance. =

   2. Contention scenario 2 outlined in = Janathon's email:

      Our approach naturally = AVOIDs the problem. 

      The approach by = Janathan (as well as in the Generalized draft) is a valid
      one to RESOLVE = contention.

      The difference is, we = are for Contention-avoidance and the other
      approach (through = PathErr) is for Contention-resolution (as result, one node
      loses and has to = start over). Our approach lowers the chance to get into the
         = trap of  contention.

      I also want to raise = one point: The contention scenario 2 (outlined by
      Janathon) occurs NOT = because "there are only enough resources for one of the
      bi-directional = LSPs" as mentioned in Janathon's email. It can still happen when =
      there are plenty of = resources but two neighboring nodes grab the same link
      due to = not-knowing-each-other's-actions. It is a race condition due to lack = of
      = synchronization.

   3. Contention scenario 1 outlined in = Janathon's email: our approach, at the
      current form, cannot = avoid it. One way is to borrow the idea from Janathon's
      approach using IP = address. There could be other way. we will follow up on this.

We incline to change as little as possible to RSVP-TE = (ie. not to allocate label in Path
msg and change the nature of receiver-initiating in = RSVP). This is why we use ResvErr in our draft. Other way (like = Confirm, or Path) can be used for this ONE-HOP informing the label = allocation.

I hope the generalized draft by Janathan/Lou and = others can absorb some of points in our drafts.

Best regards,

Dan

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]
Sent: Thursday, July 20, 2000 9:08 AM
To: 'Zhang, Leah'
Cc: Jonathan Lang; Fu, James; mpls@UU.NET
Subject: RE: A new draft.


Zhang,
         = Pair-wise/simultaneous label allocation for bidirectional LSPs is =
supported in = draft-generalized-signaling-mpls-00.txt.  To achieve
pair-wise/simultaneous label allocation for = bidirectional LSPs, you'd use
label set with just a single element (label).  = This would required the use
of the passed label by the downstream node.

Is there anything else covered in your draft that = isn't addressed in the
generalized draft?

Lou

At 03:37 PM 7/19/00 -0700, Jonathan Lang = wrote:

>Zhang,
>
>The tying together of the upstream and = downstream label can be done using
>the Suggested Label that is also proposed in =
>draft-lang-mpls-rsvp-oxc-00.txt (updated and = included in
>draft-generalized-signaling-mpls-00.txt).
>
>-Jonathan
>>-----Original Message-----
>>From: Zhang, Leah [mailto:leahz@sorrentonet.com]<= /FONT>
>>Sent: Wednesday, July 19, 2000 2:27 = PM
>>To: 'Jonathan Lang'; Fu, James; = mpls@UU.NET
>>Subject: RE: A new draft.
>>
>>Jonathan:
>>
>>    Thanks very much for your = comments.  We read your draft very
>> carefully. There are a lot of good thoughts = and points in your
>> draft.  Please see our response = below.
>>
>>
>>James Fu, Dan Guo, Raymond Cheng, Leah = Zhang
>>
>>Sorrento Networks Inc.
>>9990 Mesa Rim Road
>>San Diego, CA 92121
>>
>>
>>  -----Original Message-----
>>From: Jonathan Lang [mailto:jplang@calient.net]=
>>Sent: Tuesday, July 18, 2000 6:04 PM
>>To: 'Fu, James'; mpls@UU.NET
>>Cc: Jonathan Lang
>>Subject: RE: A new draft.
>>James,
>>   I read your draft and I'm = afraid you have misunderstood the
>> bi-directional approach of = draft-lang-mpls-rsvp-oxc-00.txt (updated and
>> included in = draft-generalized-signaling-mpls-00.txt).   The process of =
>> establishing a bi-directional LSP is the = same as the establishment of a
>> unidirectional LSP with the exception that = an Upstream Label is added to
>> the Path message.  (Incidentally, the = flow of the Upstream Label is the
>> same as the normal flow of a Label would be = for the upstream segment of
>> a bi-directional LSP, except that we have = short-circuited sending the
>> Path message upstream -- see example = below).
>>
>>We understand your approach of assigning = Upstream Label in the Path
>>message, and assigning Downstream Label in = the Resv message.  In your
>>approach, the assignment of Upstream Label = and
>>the assignment of Downstream Label is not = tied together. We think that to
>>support bi-directional LSP, it is important = to do pair-wise assignment
>>(or reservations) at the SAME time. This = becomes especially
>>important in the transparent pure optical = networks where wavelength
>>continuity is required.
>>
>>
>>Contention may occur for the following = reasons:
>>1)  If there is a requirement that the = input/output ports for the
>>bi-directional path be tied together (e.g., = if they must be on the same
>>physical I/O card).  Since these are = assigned by different OXCs,
>>contention may occur.  The scheme that = you have proposed will also have
>>this contention scenario.
>>We admit that we did not consider this = requirement at the time we wrote
>>the draft. We defines the
>>contention specifically as two OXCs trying = to assign labels for the same
>>link. This contention scenario, though, = happens much less often than the
>>contention scenario where two OXCs trying to = assign labels for the same link
>>
>>
>>2)  If two bi-directional LSPs are = attempted to be established
>>simultaneously in opposite directions and = there are only enough resources
>>for one of the bi-directional LSPs.  In = this case, one of the LSPs cannot
>>be established along that path.  The = scheme that you propose avoids this
>>contention, I assume, by resource checking = on the Path message and
>>sending a PathError message to the losing = LSP.  This is also how it is
>>done in = draft-lang-mpls-rsvp-oxc-00.txt.
>>We agree to this assessment.
>>
>>
>>On another note, I think overloading the = ResvError message for label
>>allocation is a bad idea.
>>
>>We are not fond of this solution, too. = However, this is a better
>>compromised solution at moment compared with = that a new LMP has to be
>>used together with the RSVP extensions. . We = are open to any good
>>alternatives and suggestions.
>>
>>To summarize, we think that to support = bi-directional LSP (OSP),
>>pair-wise label assignment scheme is = better  than uni -directional label
>>assignment schemes. This becomes especially = important to support
>>wavelength continuity requirement in = transparent optical networks. We
>>will modify our draft. A new version will = come out soon.
>>
>>
>>Regards,
>>Jonathan
>>
>>Example:
>>
>>downstream ----->
>>upstream    <-----
>>
>>(1)  RSVP-TE used to establish a = bi-directional LSP:
>>
>>+-+-+  Path(Label Request) +-+-+  = Path(Label Request)
>>+-+-+   Path(LabelRequest)
>>  |     |  = --------------------------->  |     | =
>> --------------------------->  = |     |     = --------------------------->
>>+    +  = Resv(Label)          &= nbsp;   +    +   = Resv(Label)          &= nbsp;  +    +
 >> Resv(Label)
>>  |     |  = <---------------         = ;      |     |  = <---------------
 >>         = |     |  <----------------
>>+ A = +            = ;            = ;         + B
>>+         =             =            + C = +
>>  |     |  = Path(Label Request)   |     |  = Path(Label
>> Request)  |     = |   Path(LabelRequest)
>>+    +  = <---------------------------  +    +  = <--------------------------
 >> +    +  = <------------------------
>>  |     |  = Resv(Label)          &= nbsp;     |     = |     Resv(Label)
>> |     = |      Resv(Label)
>>+-+-+  = -------------------------->   +-+-+    = -------------------------->
>>+-+-+  = ------------------------>
>>
>>(2)  bi-directional LSP using = draft-lang-mpls-rsvp-oxc.txt
>>
>>+-+-+  Path(Label Request, +-+-+  = Path(Label Request)
>>+-+-+   Path(LabelRequest)
>>  |     = |         UpstreamLabel)  = |     |        = UpstreamLabel)   |     |
 >>        &= nbsp;   UpstreamLabel)
>>+    +  = --------------------------->  +    +
>>---------------------------> = +    +  --------------------------->
>>  |     = |            = ;            = ;          = |     |
 >>        &= nbsp;  |     |
>>+ A = +            = ;            = ;         + B
>>+         =             =            + C = +
>>  |     |  = Resv(Label)          &= nbsp;    |     |  Resv(Label) =
>> |     |   = Resv(Label)
>>+    +  = <---------------------------  +    +  = <--------------------------
 >> +    +  = <------------------------
>>  |     = |            = ;            = ;          = |     |
 >>        &= nbsp;  |     |
>>+-+-+        &n= bsp;           &n= bsp;            = +-+-+
 >> +-+-+
>>
>>>-----Original Message-----
>>>From: Fu, James [mailto:jfu@sorrentonet.com]
>>>Sent: Tuesday, July 18, 2000 9:39 = AM
>>>To: mpls@UU.NET
>>>Subject: A new draft.
>>>
>>>An Internet Draft entitled = "Extensions to RSVP-TE for Bi-directional
>>>Optical Path Setup" has been = submitted to the IETF.
>>>
>>><http://www.ietf.org/internet-drafts/draft-sorrento-rsv= p-bi-osp-00.txt>http://www.ietf.org/internet-drafts/draft-sorrento-rsv= p-bi-osp-00.txt

>>>
>>>
>>>James Fu
>>>Sorrento Networks Inc.
>>>9990 Mesa Rim Road
>>>San Diego, CA  92121
>>>
>>>jfu@sorrentonet.com

------_=_NextPart_001_01BFF2B0.B5EA20D0-- From owner-mpls@UU.NET Fri Jul 21 03:07:45 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02228 for ; Fri, 21 Jul 2000 03:07:45 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyto05030; Fri, 21 Jul 2000 07:05:26 GMT Received: by mail-control.mail.uu.net id QQiyto04785 for mpls-outgoing; Fri, 21 Jul 2000 07:04: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 QQiyto04780 for ; Fri, 21 Jul 2000 07:04: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 QQiyto03195 for ; Fri, 21 Jul 2000 03:04:29 -0400 (EDT) From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQiyto03887 for ; Fri, 21 Jul 2000 07:03:59 GMT Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP; Fri, 21 Jul 2000 08:03:33 +0100 Received: by CHQLUBNT02 with Internet Mail Service (5.5.2651.88) id <32D6BZHL>; Fri, 21 Jul 2000 08:03:21 +0100 Message-ID: To: tom@ennovatenetworks.com, mpls@UU.NET Subject: RE: mpls-in-ip Date: Fri, 21 Jul 2000 08:03:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom, Just an observation but......if we allow LSPs (ostensibly a CO entity) to be a client layer of an IP server layer (a CNLS entity) will this not present some *interesting* problems? For example: - I guess IP would also be a client of the LSP.....and in theory one could recurse this relationship many times; - QoS control would be a issue (esp if there was no control over how many times the recursion could exist......this is not just as a single instance, but also in a concatenated sense); - ........and so would defect handling and OAM in general. Have these factors been considered? neil From owner-mpls@UU.NET Fri Jul 21 05:16: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 FAA16274 for ; Fri, 21 Jul 2000 05:16:28 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiytw21372; Fri, 21 Jul 2000 09:14:08 GMT Received: by mail-control.mail.uu.net id QQiytw09532 for mpls-outgoing; Fri, 21 Jul 2000 09:13:48 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiytw09521 for ; Fri, 21 Jul 2000 09:13: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 QQiytw13736 for ; Fri, 21 Jul 2000 05:13:29 -0400 (EDT) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQiytw21515 for ; Fri, 21 Jul 2000 09:13:28 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id CAA15412 for ; Fri, 21 Jul 2000 02:13:28 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id CAA14653 for mpls@uu.net; Fri, 21 Jul 2000 02:12:04 -0700 (PDT) Date: Fri, 21 Jul 2000 02:12:04 -0700 (PDT) From: Kireeti Kompella Message-Id: <200007210912.CAA14653@kummer.juniper.net> To: mpls@UU.NET Subject: New Internet Draft: TE over Unnumbered Links Sender: owner-mpls@UU.NET Precedence: bulk Hi, FYI: we have a new Internet draft for doing TE over unnumbered links. This draft will shortly be sent to the IETF, but may not be posted prior to the coming IETF, so the text follows. Kireeti. ------- Network Working Group Kireeti Kompella Internet Draft Juniper Networks Expiration Date: January 2001 Yakov Rekhter Cisco Systems Traffic Engineering with Unnumbered Links draft-kompella-mpls-unnum-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract Traffic Engineering currently does not take into account unnumbered links. There are two issues: carrying information about unnumbered links in IS-IS and OSPF; and including unnumbered links when signalling. This document addresses these two issues. draft-kompella-mpls-unnum-00.txt [Page 1] Internet Draft draft-kompella-mpls-unnum-00.txt July 2000 3. Overview Traffic Engineering currently does not take into account unnumbered links (i.e., links that do not have IP addresses). However, not numbering links is useful, if not critical, in many environments; the reasons include conserving IP addresses, and reducing management overhead. This document only covers point-to-point links that are unnumbered. There are two issues: carrying Traffic Engineering information about unnumbered links in IS-IS and OSPF (see [ISIS-TE] and [OSPF-TE]); and including unnumbered links when signalling (see [RSVP-TE]). This document proposes a simple means of solving the former (modeled on how OSPF carries unnumbered link information for router link advertisements), and a simple extension to the RSVP Explicit Route Object for the latter. 4. Interface Identifiers If links are not identified by an IP address, they need some other identifier. We assume that each unnumbered link on a Label Switched Router (LSR) is given a unique 16-bit identifier. The scope of this identifier is the LSR to which the link belongs; moreover, the ISIS/OSPF and RSVP modules on an LSR must agree on interface identifiers. A good candidate for the interface identifier is the SNMP IfIndex of the interface. 5. Carrying Unnumbered Links in IS-IS and OSPF In IS-IS, the extended IS reachability TLV contains an IPv4 Interface Address, which normally identifies an IPv4 address for an interface. If the interface being advertised for Traffic Engineering purposes is unnumbered, the IPv4 Interface Address is set to the router ID of the advertising LSR. The extended IS reachability TLV also contains an IPv4 Neighbor Address, which normally identifies an IPv4 address of the neighboring LSR on a link. If the interface being advertised for Traffic Engineering purposes is unnumbered, the first two octets of the IPv4 Neighbor Address are set to zero, and the next two octets are set to the Interface ID of the unnumbered interface. The rest of the Traffic Engineering information remains unchanged. In OSPF, the Link sub-TLV of the Opaque Traffic Engineering TLV contains a Local Interface IP Address, which normally identifies the IPv4 address for an interface. If the interface being advertised for Traffic Engineering purposes is unnumbered, the Local Interface Address is set to the router ID of the advertising LSR. The Link draft-kompella-mpls-unnum-00.txt [Page 2] Internet Draft draft-kompella-mpls-unnum-00.txt July 2000 sub-TLV of the Opaque Traffic Engineering TLV also contains a Remote Interface IP Address, which normally identifies the neighbor's IPv4 address for the interface. If the interface being advertised for Traffic Engineering purposes is unnumbered, the first two octets of the Remote Interface IP Address are set to zero, and the next two octets are set to the Interface ID of the unnumbered interface. The rest of the Traffic Engineering information remains unchanged. 6. Signalling Unnumbered Links in EROs A new subobject of the Explicit Route Object (ERO) is used to signal unnumbered links. This subobject has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Interface ID (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This subobject MUST be strict (i.e., the L bit MUST be 0). The Type is 3 (Unnumbered Interface ID). The Length is 4. The Interface ID is interpreted in the context of the previous node in the path (i.e., the node identified by the previous subobject in the ERO, which MUST identify a unique node), or, if this is the first subobject in the ERO, in the context of the start of the path. The next node in the path is the node at the other end of the interface identified by the Interface ID. 7. Security Considerations This document raises no new security concerns for IS-IS, OSPF or RSVP. 8. References [ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic Engineering", draft-ietf-isis-traffic-01.txt (work in progress) [OSPF-TE] Katz, D., and Yeung, D., "Traffic Engineering Extensions to OSPF", draft-katz-yeung-ospf-traffic-01.txt (work in progress) [RSVP-TE] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan, V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-06.txt (work in progress) draft-kompella-mpls-unnum-00.txt [Page 3] Internet Draft draft-kompella-mpls-unnum-00.txt July 2000 9. Author Information Kireeti Kompella Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043 e-mail: kireeti@juniper.net Yakov Rekhter Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: yakov@cisco.com draft-kompella-mpls-unnum-00.txt [Page 4] From owner-mpls@UU.NET Fri Jul 21 05:31: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 FAA24762 for ; Fri, 21 Jul 2000 05:31:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiytx00323; Fri, 21 Jul 2000 09:29:45 GMT Received: by mail-control.mail.uu.net id QQiytx11311 for mpls-outgoing; Fri, 21 Jul 2000 09:29: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 QQiytx11303 for ; Fri, 21 Jul 2000 09:29: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 QQiytx16807 for ; Fri, 21 Jul 2000 05:28:49 -0400 (EDT) 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 QQiytx08746 for ; Fri, 21 Jul 2000 09:28:33 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA04594 for mpls@uu.net; Fri, 21 Jul 2000 05:28:33 -0400 (EDT) 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 QQiytx11220 for ; Fri, 21 Jul 2000 09:28: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 QQiytx14901 for ; Fri, 21 Jul 2000 05:27:49 -0400 (EDT) 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 QQiytx28862 for ; Fri, 21 Jul 2000 09:27:49 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 554F9180; Fri, 21 Jul 2000 11:27:48 +0200 (MET DST) Received: from flefauch-8kcdt.cisco.com (nice-dhcp3.cisco.com [144.254.60.25]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id LAA06480; Fri, 21 Jul 2000 11:27:46 +0200 (MET DST) Message-Id: <200007210927.LAA06480@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 21 Jul 2000 11:24:20 +0200 To: mpls@UU.NET, ospf@discuss.microsoft.com, isis-wg@juniper.net From: Francois Le Faucheur Subject: Announcing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk FYI: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to IS-IS, OSPF, RSVP and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering Author(s) : F. Le Faucheur, T. Nadeau, A. Chiu, W. Townsend, D. Skalecki Filename : draft-lefaucheur-diff-te-ext-00.txt Pages : 14 Date : 14-Jul-00 A companion document [DIFF-TE-REQTS] defines the requirements for support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. This document proposes corresponding extensions to OSPF, ISIS, RSVP and CR-LDP for support of Traffic Engineering on a per-Class-Type basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lefaucheur-diff-te-ext-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-lefaucheur-diff-te-ext-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-lefaucheur-diff-te-ext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <20000714142705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lefaucheur-diff-te-ext-00.txt Francois From owner-mpls@UU.NET Fri Jul 21 05:51: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 FAA06993 for ; Fri, 21 Jul 2000 05:51:51 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiytz13056; Fri, 21 Jul 2000 09:49:58 GMT Received: by mail-control.mail.uu.net id QQiytz13247 for mpls-outgoing; Fri, 21 Jul 2000 09:49:33 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiytz13233 for ; Fri, 21 Jul 2000 09:49: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 QQiytz16929 for ; Fri, 21 Jul 2000 05:49:10 -0400 (EDT) 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 QQiytz01396 for ; Fri, 21 Jul 2000 09:48:55 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id FAA05902 for mpls@uu.net; Fri, 21 Jul 2000 05:48:54 -0400 (EDT) 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 QQiytz13158 for ; Fri, 21 Jul 2000 09:48: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 QQiytz18575 for ; Fri, 21 Jul 2000 05:48:07 -0400 (EDT) Received: from ogma.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQiytz00542 for ; Fri, 21 Jul 2000 09:48:07 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 554F9180; Fri, 21 Jul 2000 11:27:48 +0200 (MET DST) Received: from flefauch-8kcdt.cisco.com (nice-dhcp3.cisco.com [144.254.60.25]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id LAA06480; Fri, 21 Jul 2000 11:27:46 +0200 (MET DST) Message-Id: <200007210927.LAA06480@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 21 Jul 2000 11:24:20 +0200 To: mpls@UU.NET, ospf@discuss.microsoft.com, isis-wg@juniper.net From: Francois Le Faucheur Subject: Announcing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk FYI: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to IS-IS, OSPF, RSVP and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering Author(s) : F. Le Faucheur, T. Nadeau, A. Chiu, W. Townsend, D. Skalecki Filename : draft-lefaucheur-diff-te-ext-00.txt Pages : 14 Date : 14-Jul-00 A companion document [DIFF-TE-REQTS] defines the requirements for support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. This document proposes corresponding extensions to OSPF, ISIS, RSVP and CR-LDP for support of Traffic Engineering on a per-Class-Type basis. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lefaucheur-diff-te-ext-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-lefaucheur-diff-te-ext-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-lefaucheur-diff-te-ext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <20000714142705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lefaucheur-diff-te-ext-00.txt Francois From owner-mpls@UU.NET Fri Jul 21 09:23: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 JAA11777 for ; Fri, 21 Jul 2000 09:23:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyun12699; Fri, 21 Jul 2000 13:22:01 GMT Received: by mail-control.mail.uu.net id QQiyun17461 for mpls-outgoing; Fri, 21 Jul 2000 13:21: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 QQiyun17410 for ; Fri, 21 Jul 2000 13:21:07 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyun09282 for ; Fri, 21 Jul 2000 09:20:55 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyun10920 for ; Fri, 21 Jul 2000 13:20:40 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id IAA18959; Fri, 21 Jul 2000 08:20:31 -0500 Message-Id: <4.3.2.7.2.20000721090303.00ddb260@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 09:20:55 -0400 To: "Guo, Dan" From: Lou Berger Subject: RE: A new draft. Cc: "'Lou Berger'" , "Zhang, Leah" , Jonathan Lang , "Fu, James" , mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Dan, See in-line comments. At 06:11 PM 7/20/00 -0700, Guo, Dan wrote: >Lou, Janathan and Leah, > >The new generalized draft (just released) is an excellent piece for our >work. To all >of us working in this area, it is very helpful. > >Our draft came out of our practical work. After carefully examining the >issues, >I feel it may add to the generalized draft in the following aspects - > > 1. Wavelength continuety issue to MPLS for some types of networks: we > feel > it is of importance. no argument, lots of others have made the same point. > 2. Contention scenario 2 outlined in Janathon's email: > > Our approach naturally AVOIDs the problem. > > The approach by Janathan (as well as in the Generalized draft) is a > valid > one to RESOLVE contention. > > The difference is, we are for Contention-avoidance and the other > approach (through PathErr) is for Contention-resolution (as result, > one node > loses and has to start over). Our approach lowers the chance to get > into the > trap of contention. > > I also want to raise one point: The contention scenario 2 (outlined by > Janathon) occurs NOT because "there are only enough resources for > one of the > bi-directional LSPs" as mentioned in Janathon's email. It can still > happen when > there are plenty of resources but two neighboring nodes grab the > same link > due to not-knowing-each-other's-actions. It is a race condition due > to lack of > synchronization. As mentioned in my last mail the right solution to cover this case is to use LabelSet. The document should have discussed this in the context of bi-directional LSPs. We can fix this in the next, rev. I think we handle this particular error in a similar fashion (PathErr). When using LabelSet (with a single element) both labels can be allocated on the Path message. If the downstream node finds the label in the LabelSet unacceptable (for contention or any other reason) it responds with a PathErr. > 3. Contention scenario 1 outlined in Janathon's email: our approach, > at the > current form, cannot avoid it. One way is to borrow the idea from > Janathon's > approach using IP address. There could be other way. we will follow > up on this. > >We incline to change as little as possible to RSVP-TE (ie. not to allocate >label in Path >msg and change the nature of receiver-initiating in RSVP). This is why we >use ResvErr in our draft. Other way (like Confirm, or Path) can be used >for this ONE-HOP informing the label allocation. Given the fundamental addition of bi-directional LSPs, I the -generalized approach is cleaner / less complex. >I hope the generalized draft by Janathan/Lou and others can absorb some of >points in our drafts. Absolutely. We'll at least have a draft that better explains different scenarios. (sorry about not doing a better job.) I'm still not sure if there's anything in your draft that is not functionally provided in the -generalized draft. Certainly the -generalized draft uses different mechanisms, but are there any functions that are missing or broken relative to your draft? Thanks, Lou >Best regards, > >Dan > >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net] >Sent: Thursday, July 20, 2000 9:08 AM >To: 'Zhang, Leah' >Cc: Jonathan Lang; Fu, James; mpls@UU.NET >Subject: RE: A new draft. > >Zhang, > Pair-wise/simultaneous label allocation for bidirectional LSPs is >supported in draft-generalized-signaling-mpls-00.txt. To achieve >pair-wise/simultaneous label allocation for bidirectional LSPs, you'd use >label set with just a single element (label). This would required the use >of the passed label by the downstream node. > >Is there anything else covered in your draft that isn't addressed in the >generalized draft? > >Lou > >At 03:37 PM 7/19/00 -0700, Jonathan Lang wrote: > > >Zhang, > > > >The tying together of the upstream and downstream label can be done using > >the Suggested Label that is also proposed in > >draft-lang-mpls-rsvp-oxc-00.txt (updated and included in > >draft-generalized-signaling-mpls-00.txt). > > > >-Jonathan > >>-----Original Message----- > >>From: Zhang, Leah > [mailto:leahz@sorrentonet.com] > >>Sent: Wednesday, July 19, 2000 2:27 PM > >>To: 'Jonathan Lang'; Fu, James; mpls@UU.NET > >>Subject: RE: A new draft. > >> > >>Jonathan: > >> > >> Thanks very much for your comments. We read your draft very > >> carefully. There are a lot of good thoughts and points in your > >> draft. Please see our response below. > >> > >> > >>James Fu, Dan Guo, Raymond Cheng, Leah Zhang > >> > >>Sorrento Networks Inc. > >>9990 Mesa Rim Road > >>San Diego, CA 92121 > >> > >> > >> -----Original Message----- > >>From: Jonathan Lang [mailto:jplang@calient.net] > >>Sent: Tuesday, July 18, 2000 6:04 PM > >>To: 'Fu, James'; mpls@UU.NET > >>Cc: Jonathan Lang > >>Subject: RE: A new draft. > >>James, > >> I read your draft and I'm afraid you have misunderstood the > >> bi-directional approach of draft-lang-mpls-rsvp-oxc-00.txt (updated and > >> included in draft-generalized-signaling-mpls-00.txt). The process of > >> establishing a bi-directional LSP is the same as the establishment of a > >> unidirectional LSP with the exception that an Upstream Label is added to > >> the Path message. (Incidentally, the flow of the Upstream Label is the > >> same as the normal flow of a Label would be for the upstream segment of > >> a bi-directional LSP, except that we have short-circuited sending the > >> Path message upstream -- see example below). > >> > >>We understand your approach of assigning Upstream Label in the Path > >>message, and assigning Downstream Label in the Resv message. In your > >>approach, the assignment of Upstream Label and > >>the assignment of Downstream Label is not tied together. We think that to > >>support bi-directional LSP, it is important to do pair-wise assignment > >>(or reservations) at the SAME time. This becomes especially > >>important in the transparent pure optical networks where wavelength > >>continuity is required. > >> > >> > >>Contention may occur for the following reasons: > >>1) If there is a requirement that the input/output ports for the > >>bi-directional path be tied together (e.g., if they must be on the same > >>physical I/O card). Since these are assigned by different OXCs, > >>contention may occur. The scheme that you have proposed will also have > >>this contention scenario. > >>We admit that we did not consider this requirement at the time we wrote > >>the draft. We defines the > >>contention specifically as two OXCs trying to assign labels for the same > >>link. This contention scenario, though, happens much less often than the > >>contention scenario where two OXCs trying to assign labels for the same > link > >> > >> > >>2) If two bi-directional LSPs are attempted to be established > >>simultaneously in opposite directions and there are only enough resources > >>for one of the bi-directional LSPs. In this case, one of the LSPs cannot > >>be established along that path. The scheme that you propose avoids this > >>contention, I assume, by resource checking on the Path message and > >>sending a PathError message to the losing LSP. This is also how it is > >>done in draft-lang-mpls-rsvp-oxc-00.txt. > >>We agree to this assessment. > >> > >> > >>On another note, I think overloading the ResvError message for label > >>allocation is a bad idea. > >> > >>We are not fond of this solution, too. However, this is a better > >>compromised solution at moment compared with that a new LMP has to be > >>used together with the RSVP extensions. . We are open to any good > >>alternatives and suggestions. > >> > >>To summarize, we think that to support bi-directional LSP (OSP), > >>pair-wise label assignment scheme is better than uni -directional label > >>assignment schemes. This becomes especially important to support > >>wavelength continuity requirement in transparent optical networks. We > >>will modify our draft. A new version will come out soon. > >> > >> > >>Regards, > >>Jonathan > >> > >>Example: > >> > >>downstream -----> > >>upstream <----- > >> > >>(1) RSVP-TE used to establish a bi-directional LSP: > >> > >>+-+-+ Path(Label Request) +-+-+ Path(Label Request) > >>+-+-+ Path(LabelRequest) > >> | | ---------------------------> | | > >> ---------------------------> | | ---------------------------> > >>+ + Resv(Label) + + Resv(Label) + + > >> Resv(Label) > >> | | <--------------- | | <--------------- > >> | | <---------------- > >>+ A + + B > >>+ + C + > >> | | Path(Label Request) | | Path(Label > >> Request) | | Path(LabelRequest) > >>+ + <--------------------------- + + <-------------------------- > >> + + <------------------------ > >> | | Resv(Label) | | Resv(Label) > >> | | Resv(Label) > >>+-+-+ --------------------------> +-+-+ --------------------------> > >>+-+-+ ------------------------> > >> > >>(2) bi-directional LSP using draft-lang-mpls-rsvp-oxc.txt > >> > >>+-+-+ Path(Label Request, +-+-+ Path(Label Request) > >>+-+-+ Path(LabelRequest) > >> | | UpstreamLabel) | | UpstreamLabel) | | > >> UpstreamLabel) > >>+ + ---------------------------> + + > >>---------------------------> + + ---------------------------> > >> | | | | > >> | | > >>+ A + + B > >>+ + C + > >> | | Resv(Label) | | Resv(Label) > >> | | Resv(Label) > >>+ + <--------------------------- + + <-------------------------- > >> + + <------------------------ > >> | | | | > >> | | > >>+-+-+ +-+-+ > >> +-+-+ > >> > >>>-----Original Message----- > >>>From: Fu, James [mailto:jfu@sorrentonet.com] > >>>Sent: Tuesday, July 18, 2000 9:39 AM > >>>To: mpls@UU.NET > >>>Subject: A new draft. > >>> > >>>An Internet Draft entitled "Extensions to RSVP-TE for Bi-directional > >>>Optical Path Setup" has been submitted to the IETF. > >>> > >>>< >http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt>http://www.ietf.org/internet-drafts/draft-sorrento-rsvp-bi-osp-00.txt > > > >>> > >>> > >>>James Fu > >>>Sorrento Networks Inc. > >>>9990 Mesa Rim Road > >>>San Diego, CA 92121 > >>> > >>>jfu@sorrentonet.com From owner-mpls@UU.NET Fri Jul 21 09:27: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 JAA11954 for ; Fri, 21 Jul 2000 09:27:24 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyuk19959; Fri, 21 Jul 2000 12:40:54 GMT Received: by mail-control.mail.uu.net id QQiyuk03354 for mpls-outgoing; Fri, 21 Jul 2000 12:40: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 QQiyuk03334 for ; Fri, 21 Jul 2000 12:40:11 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyuk06150 for ; Fri, 21 Jul 2000 08:40:09 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyuk18185 for ; Fri, 21 Jul 2000 12:39:39 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id HAA05822; Fri, 21 Jul 2000 07:39:35 -0500 Message-Id: <4.3.2.7.2.20000721081804.04148220@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 08:39:19 -0400 To: George Swallow From: Lou Berger Subject: Re: Two last calls (draft-ietf-mpls-diff-ext-06.txt) Cc: mpls@UU.NET In-Reply-To: <200007191608.MAA25432@lir.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk George, I still believe the draft doesn't cover the cases where there are non-DS and DS LSRs in the same network. I raised this issue in February, see list archive for 2/8 - 2/10, and briefly at the last WG session. My understanding from the authors was that they just didn't belive this case was valid and therefore didn't need to be addressed in the draft. Given that draft-lefaucheur-diff-te-reqts-00.txt raises the same issue (in section 3), I think the diff-ext draft should be fixed to allow for non-DS and DS LSRs in the same network. Lou PS As mentioned back on 2/8, I believe one trivial solution is to require the use of the DiffServ Object/TLV for all E-LSPs, where use of preconfigured EXP<-->PHB mappings is indicated by either (pick one) no map parameters or a single map parameter set to all zeros. Another solution is to use the one proposed in draft-lefaucheur-diff-te-ext-00.txt, although it does use a new object that could just be merged with the DiffServ Object. At 12:08 PM 7/19/00 -0400, George Swallow wrote: >This message begins a last calls on: > > draft-ietf-mpls-diff-ext-06.txt and > draft-ietf-mpls-rsvp-lsp-tunnel-06.txt > >The last calls will end on July 26 midnight GMT. Comment are limited >to the deltas between these and their respective prior drafts. > >With regard to the RSVP-TE draft, the recent comments to the list are >accepted as last call comments and need not be repeated. > >...George > >====================================================================== >George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Jul 21 09:36: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 JAA12379 for ; Fri, 21 Jul 2000 09:36:04 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyuo27969; Fri, 21 Jul 2000 13:33:59 GMT Received: by mail-control.mail.uu.net id QQiyuo18790 for mpls-outgoing; Fri, 21 Jul 2000 13:33: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 QQiyuo18783 for ; Fri, 21 Jul 2000 13:33: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 QQiyuo11218 for ; Fri, 21 Jul 2000 09:32:43 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiyuo26333 for ; Fri, 21 Jul 2000 13:32:42 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA03713 for ; Fri, 21 Jul 2000 06:32:55 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA03637 for mpls@uu.net; Fri, 21 Jul 2000 09:32:41 -0400 (EDT) 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 QQiyrp25060 for ; Thu, 20 Jul 2000 18: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 QQiyrp26614 for ; Thu, 20 Jul 2000 14:24:43 -0400 (EDT) Received: from fire.integralaccess.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.160.25.239]) id QQiyrp13521 for ; Thu, 20 Jul 2000 18:24:28 GMT Received: from akankkunen [192.168.1.22] by fire.integralaccess.com (SMTPD32-6.03) id A4A51F0112; Thu, 20 Jul 2000 14:27:49 -0400 From: "Antti Kankkunen" To: , Subject: draft-kankkunen-vompls-fw-01.txt Date: Thu, 20 Jul 2000 14:25:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit FYI A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Voice over MPLS Framework Author(s) : A. Kankkunen, G. Ash, A. Chiu, J. Hopkins, J. Jeffords, F. Le Faucheur, B. Rosen, D. Stacey, A. Yelundur, L. Berger Filename : draft-kankkunen-vompls-fw-01.txt Pages : 58 Date : 19-Jul-00 This document provides a Framework for using MPLS as one underlying technology alternative for transporting VoIP based public voice services. The document defines a reference model for VoIP over MPLS, defines some specific applications for VoIP over MPLS and identifies potential further standardization work that is necessary to support these applications. The annexes of the document discuss the types of requirements that voice services set on the under laying transport infrastructure A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kankkunen-vompls-fw-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kankkunen-vompls-fw-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kankkunen-vompls-fw-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. draft-kankkunen-vompls-fw-01.txt ------------------- Antti Kankkunen Integral Access Inc. 6 Omni Way Chelmsford, MA 01824 Phone: +1 978 256 8833 x 232 Mobile: +1 617 513 2172 Fax: +1 978 256 8077 e-mail: anttik@integralaccess.com From owner-mpls@UU.NET Fri Jul 21 09:37: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 JAA12446 for ; Fri, 21 Jul 2000 09:37:20 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyuo00732; Fri, 21 Jul 2000 13:35:56 GMT Received: by mail-control.mail.uu.net id QQiyuo18944 for mpls-outgoing; Fri, 21 Jul 2000 13:35: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 QQiyuo18919 for ; Fri, 21 Jul 2000 13:35: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 QQiyuo11492 for ; Fri, 21 Jul 2000 09:34:21 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiyuo28556 for ; Fri, 21 Jul 2000 13:34:21 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA04671 for ; Fri, 21 Jul 2000 06:34:34 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA03649 for mpls@uu.net; Fri, 21 Jul 2000 09:34:19 -0400 (EDT) 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 QQiyst27037 for ; Fri, 21 Jul 2000 01:45: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 QQiyss28103 for ; Thu, 20 Jul 2000 21:44:55 -0400 (EDT) Received: from web122.yahoomail.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web122.yahoomail.com [205.180.60.57]) id QQiyss23210 for ; Fri, 21 Jul 2000 01:44:54 GMT Received: (qmail 4203 invoked by uid 60001); 21 Jul 2000 01:44:54 -0000 Message-ID: <20000721014454.4202.qmail@web122.yahoomail.com> Received: from [202.188.184.48] by web122.yahoomail.com; Thu, 20 Jul 2000 18:44:54 PDT Date: Thu, 20 Jul 2000 18:44:54 -0700 (PDT) From: Ho Ee Lock Subject: Questions regarding MPLS To: mpls@UU.NET Cc: eelock@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk I am interested in studying some related works in MPLS. However, there are some questions I am in doubt. Firstly, I wonder whether there are papars out there describing the performance of IP using MPLS switching technologies. I wanted to study MPLS in that line, but I found no references to it. I hope someone can kindly refer me to some useful resource(eg. papers, journals) concerning this matter (if there are any of them, currently). Also, does anybody know about some simulation software that is used to gauge the performance of MPLS available in the Internet? I am looking forward to hearing some responses. I believe it would help me a lot in my research. Thank you. Regards, Ho Ee Lock eelock@yahoo.com __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From owner-mpls@UU.NET Fri Jul 21 11:08: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 LAA19612 for ; Fri, 21 Jul 2000 11:08:33 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyuu05504; Fri, 21 Jul 2000 15:07:11 GMT Received: by mail-control.mail.uu.net id QQiyuu16763 for mpls-outgoing; Fri, 21 Jul 2000 15:06: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 QQiyuu16726 for ; Fri, 21 Jul 2000 15:06: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 QQiyuu00364 for ; Fri, 21 Jul 2000 11:06:22 -0400 (EDT) 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 QQiyuu03917 for ; Fri, 21 Jul 2000 15:06:06 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA06460 for mpls@uu.net; Fri, 21 Jul 2000 11:06:05 -0400 (EDT) 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 QQiyuu15993 for ; Fri, 21 Jul 2000 15:05:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyuu27118 for ; Fri, 21 Jul 2000 11:04:51 -0400 (EDT) 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 QQiyuu02165 for ; Fri, 21 Jul 2000 15:04:50 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 LAA06298 for ; Fri, 21 Jul 2000 11:04:49 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA25889 for ; Fri, 21 Jul 2000 11:04:49 -0400 (EDT) Message-Id: <200007211504.LAA25889@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Status of Drafts Date: Fri, 21 Jul 2000 11:04:49 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk There's now a set of drafts that are ready for publication, save one nagging detail. There are references to the Framework Document which remains incomplete. Given that the Architecture document has captured and expanded on the useful ideas in the Framework document, the IESG has agreed to proceed as follows. Of the following eight drafts, the six starred drafts have references to the framework document. * draft-ietf-mpls-arch-06.txt * draft-ietf-mpls-label-encaps-07.txt * draft-ietf-mpls-ldp-08.txt * draft-ietf-mpls-ldp-applic-01.txt draft-ietf-mpls-atm-04.txt draft-ietf-mpls-fr-06.txt * draft-ietf-mpls-git-uus-04.txt * draft-ietf-mpls-vcid-atm-04.txt I'm requesting that those people with editing responsibility for the starred documents turn new versions (+1) with the references deleted. These should be sent the the ID editor. Please send a note to the Chairs and ADs when this is done. Publication should follow shortly. Thanks! ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Jul 21 11:35: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 LAA00999 for ; Fri, 21 Jul 2000 11:35:55 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyuw19080; Fri, 21 Jul 2000 15:34:30 GMT Received: by mail-control.mail.uu.net id QQiyuw24490 for mpls-outgoing; Fri, 21 Jul 2000 15:33: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 QQiyuw24473 for ; Fri, 21 Jul 2000 15:33:46 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyuw05370 for ; Fri, 21 Jul 2000 11:33:33 -0400 (EDT) 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 QQiyuw09338 for ; Fri, 21 Jul 2000 15:33:17 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jul 2000 16:33:06 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2C9C0F@monk.datcon.co.uk> From: Adrian Farrel To: "Kullberg, Alan" , mpls@UU.NET Subject: RE: question on generalized MPLS signaling Date: Fri, 21 Jul 2000 16:33:06 +0100 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 Alan, This issue becomes "simple" if the bearer tunnel used to carry the bidirectional LSP is also bidirectional. In fact, since one of the requirements of this sort of bidirectional tunnel would appear to be that the reverse path traverses exactly the same series of hops as the forward path, the bearer tunnel MUST itself be bidirectional. Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Kullberg, Alan [mailto:akullber@netplane.com] >Sent: Thursday, July 20, 2000 3:13 PM >To: mpls@UU.NET >Subject: question on generalized MPLS signaling > > >I have been reading draft-ashwood-generalized-mpls-signaling-00.txt >and draft-ietf-mpls-lsp-hierarchy-00.txt and have a question. When >a bidirectional LSP is being signaled, a label stack may be required >in the reverse direction. Can the method described in lsp-hierarchy >be applied in the reverse direction? If so, where does the "strict hop >subsequence" come from? For RSVP, it could come from a record >route object, but for CR-LDP, there is no such record route TLV. > >Thanks, > >Alan > > From owner-mpls@UU.NET Fri Jul 21 11:36:20 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01257 for ; Fri, 21 Jul 2000 11:36:19 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyuw11247; Fri, 21 Jul 2000 15:34:35 GMT Received: by mail-control.mail.uu.net id QQiyuw24506 for mpls-outgoing; Fri, 21 Jul 2000 15:34:06 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiyuw24493 for ; Fri, 21 Jul 2000 15:33: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 QQiyuw02148 for ; Fri, 21 Jul 2000 11:33:27 -0400 (EDT) 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 QQiyuw09522 for ; Fri, 21 Jul 2000 15:33:27 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jul 2000 16:33:15 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2C9C11@monk.datcon.co.uk> From: Adrian Farrel To: lberger@labn.net, petera@nortelnetworks.com Cc: mpls@UU.NET Subject: draft-ashwood-generalized-mpls-signaling-00 Date: Fri, 21 Jul 2000 16:33:13 +0100 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 Peter, Lou, Good draft. Attached a few small questions, a couple of editorial suggestions and a clutch of typos. I hope this helps. Regards, Adrian Questions ========= 1. I know I was shot down last time I suggested this, but that was in the optical discussion before the draft became "generalized"... Given that we can now set up LSPs as downstream on demand, or downstream on demand AND downstream unsolicited at the same time i.e. bidirectional), why don't we allow downstream unsolicited on its own? This would make for a fully generalized solution . The answer before was "There are no applications for this," but I would argue for making this fully generalized while we're at this stage especially since the work is simply to relax the requirement that 'label request' must be present on REQUEST/Path to say that at least one of 'label request', 'label' and 'generalized label' must be present. 2. Is it an issue that you cannot choose at LSP set up whether the LSP will switch a wavelength or the whole fiber? Since this is a property of the link and not of the signaled label, a link's usage for wavelength switching or whole fiber switching cannot be selected dynamically. Is this an issue? 3. Could you explain the "compatibility reasons" why a new c-type is required for a Generalized Label that contains a Waveband Label? I've looked through the archive and can't find any reference - sorry if I wasn't paying attention when this was discussed. 4. Would it be worth prohibiting bidirectional LSP setup where the forward label is of one type and the reverse label of a different type? This would be a bit odd since the resource requirements are the same in both directions. 5. I like the concept of Egress Label in an ERO to support splicing to an existing tunnel. Would now not be a good time to add support for stacking as well? The ERO suboject format would match that of Egress Label, but a new type would be needed. I'm sure there would be many uses in the optical world. Compare with the ER-Hop type of LSPID in CR-LDP. Editorial ========= Section 1, item 3. I think this could usefully mention wavebands up front. Simply add "or waveband"? Section 3.1.3. Need to clarify the description of LSP Encoding Type since currently "transparently passed by transit node" appears to contradict 3.1.2. "forwarded unchanged" might be a better description. Section 3.2.2. Cover bidirectional labels by adding to the end of the first paragraph to say "or downstream in REQUEST/Path messages as specified in section 4.2 for bidirectional LSP set up." Typos ===== Page header shows "Draftraft" 2., para 3, line 1 Strike duplicate "and" 2., para 3, line 2 Read "...is that bandwidth allocation for a non-PSC LSP..." 2., para 6, line 4 For "come" read "comes" 3., para 1 For "such at the ingress" read "such that the ingress" 3.2.1, Link ID, 1st line, For "request" read "requested" -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 From owner-mpls@UU.NET Fri Jul 21 12:01: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 MAA12644 for ; Fri, 21 Jul 2000 12:01:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyux11941; Fri, 21 Jul 2000 15:59:11 GMT Received: by mail-control.mail.uu.net id QQiyux27557 for mpls-outgoing; Fri, 21 Jul 2000 15:58: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 QQiyux27535 for ; Fri, 21 Jul 2000 15: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 QQiyux09815 for ; Fri, 21 Jul 2000 11:58:23 -0400 (EDT) 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 QQiyux10902 for ; Fri, 21 Jul 2000 15:58:23 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA26223 for mpls@uu.net; Fri, 21 Jul 2000 11:58:22 -0400 (EDT) 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 QQiyux27519 for ; Fri, 21 Jul 2000 15:58: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 QQiyux09646 for ; Fri, 21 Jul 2000 11:57:37 -0400 (EDT) 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 QQiyux09685 for ; Fri, 21 Jul 2000 15:57:21 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 IAA13087; Fri, 21 Jul 2000 08:57:15 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jul 2000 08:59:17 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406A2@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Lou Berger'" , George Swallow Cc: mpls@UU.NET Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) Date: Fri, 21 Jul 2000 08:58:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Lou, George, Section 5.6 of the draft focuses ONLY on the Diffserv LSRs. It requires the Diffserv LSRs to ignore the COS field and just use it as an indication of not reserving BW. But this doesn't preclude the use of COS field by non-Diffserv LSRs. Therefore you could still have non Diffserv LSRs in the same network and you can use the COS field for their non-Diffserv behavior. However, this is up to the network operator to make sure that a non-Diffserv LSP spans only non-Diffserv routers. So in summary this draft is not addressing non-Diffserv LSRs, and does not preclude the use of them, provided LSPs are setup properly. Regards, -Shahram >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net] >Sent: Friday, July 21, 2000 8:39 AM >To: George Swallow >Cc: mpls@UU.NET >Subject: Re: Two last calls (draft-ietf-mpls-diff-ext-06.txt) > > >George, > I still believe the draft doesn't cover the cases >where there are >non-DS and DS LSRs in the same network. I raised this issue >in February, >see list archive for 2/8 - 2/10, and briefly at the last WG >session. My >understanding from the authors was that they just didn't >belive this case >was valid and therefore didn't need to be addressed in the >draft. Given >that draft-lefaucheur-diff-te-reqts-00.txt raises the same issue (in >section 3), I think the diff-ext draft should be fixed to >allow for non-DS >and DS LSRs in the same network. > >Lou > >PS As mentioned back on 2/8, I believe one trivial solution is >to require >the use of the DiffServ Object/TLV for all E-LSPs, where use of >preconfigured EXP<-->PHB mappings is indicated by either (pick >one) no map >parameters or a single map parameter set to all zeros. >Another solution is >to use the one proposed in >draft-lefaucheur-diff-te-ext-00.txt, although it >does use a new object that could just be merged with the >DiffServ Object. > >At 12:08 PM 7/19/00 -0400, George Swallow wrote: >>This message begins a last calls on: >> >> draft-ietf-mpls-diff-ext-06.txt and >> draft-ietf-mpls-rsvp-lsp-tunnel-06.txt >> >>The last calls will end on July 26 midnight GMT. Comment are limited >>to the deltas between these and their respective prior drafts. >> >>With regard to the RSVP-TE draft, the recent comments to the list are >>accepted as last call comments and need not be repeated. >> >>...George >> >>====================================================================== >>George Swallow Cisco Systems (978) 244-8143 >> 250 Apollo Drive >> Chelmsford, Ma 01824 > From owner-mpls@UU.NET Fri Jul 21 12:34: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 MAA25397 for ; Fri, 21 Jul 2000 12:34:10 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyva19492; Fri, 21 Jul 2000 16:32:45 GMT Received: by mail-control.mail.uu.net id QQiyva11036 for mpls-outgoing; Fri, 21 Jul 2000 16:32: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 QQiyva11031 for ; Fri, 21 Jul 2000 16:32:11 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 QQiyva12043 for ; Fri, 21 Jul 2000 12:31:55 -0400 (EDT) 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 QQiyva06820 for ; Fri, 21 Jul 2000 16:31:24 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA01327 for mpls@uu.net; Fri, 21 Jul 2000 12:31:23 -0400 (EDT) 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 QQiyva10886 for ; Fri, 21 Jul 2000 16:30: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 QQiyva11792 for ; Fri, 21 Jul 2000 12:30:12 -0400 (EDT) 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 QQiyuz15951 for ; Fri, 21 Jul 2000 16:29:56 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 JAA20606; Fri, 21 Jul 2000 09:29:51 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jul 2000 09:31:53 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406A3@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Lou Berger'" , George Swallow Cc: mpls@UU.NET Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) Date: Fri, 21 Jul 2000 09:31:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Lou, George >PS As mentioned back on 2/8, I believe one trivial solution is >to require >the use of the DiffServ Object/TLV for all E-LSPs, where use of >preconfigured EXP<-->PHB mappings is indicated by either (pick >one) no map >parameters or a single map parameter set to all zeros. >Another solution is >to use the one proposed in >draft-lefaucheur-diff-te-ext-00.txt, although it >does use a new object that could just be merged with the >DiffServ Object. Your solution is ONLY valid if a single LSR could be both a Diffserv LSR and a non-Diffserv LSR. So it could use the presence of Diffserv object to decide what behavior it should have (Diffserv behavior or non-Diffserv behavior).I don't see any benefit in having a single LSR to be both a Diffserv LSR and a non-Diffserv LSR. If the purpose is to support both standardized PHBs and some local behavior that are not standardized, you could always use the Diffserv local-PHBs. Regards, -Shahram From owner-mpls@UU.NET Fri Jul 21 12:40: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 MAA27880 for ; Fri, 21 Jul 2000 12:40:33 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyva26905; Fri, 21 Jul 2000 16:38:34 GMT Received: by mail-control.mail.uu.net id QQiyva11308 for mpls-outgoing; Fri, 21 Jul 2000 16:38: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 QQiyva11303 for ; Fri, 21 Jul 2000 16:38: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 QQiyva12671 for ; Fri, 21 Jul 2000 12:37:05 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyva10336 for ; Fri, 21 Jul 2000 16:36:35 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id LAA20762; Fri, 21 Jul 2000 11:36:21 -0500 Message-Id: <4.3.2.7.2.20000721123501.00c15220@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 12:36:47 -0400 To: Shahram Davari From: Lou Berger Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) Cc: "'Lou Berger'" , George Swallow , mpls@UU.NET In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B406A2@nt-exchange-bby.p mc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Shahram, I thing the issue is the case where an LSP spans DS and non-DS LSRs. Lou At 08:58 AM 7/21/00 -0700, Shahram Davari wrote: >Lou, George, > >Section 5.6 of the draft focuses ONLY on the Diffserv LSRs. It requires the >Diffserv LSRs to ignore the COS field and just use it as an indication of >not reserving BW. > >But this doesn't preclude the use of COS field by non-Diffserv LSRs. >Therefore you could still have non Diffserv LSRs in the same network and you >can use the COS field for their non-Diffserv behavior. However, this is up >to the network operator to make sure that a non-Diffserv LSP spans only >non-Diffserv routers. > >So in summary this draft is not addressing non-Diffserv LSRs, and does not >preclude the use of them, provided LSPs are setup properly. > >Regards, >-Shahram > > > > > >-----Original Message----- > >From: Lou Berger [mailto:lberger@labn.net] > >Sent: Friday, July 21, 2000 8:39 AM > >To: George Swallow > >Cc: mpls@UU.NET > >Subject: Re: Two last calls (draft-ietf-mpls-diff-ext-06.txt) > > > > > >George, > > I still believe the draft doesn't cover the cases > >where there are > >non-DS and DS LSRs in the same network. I raised this issue > >in February, > >see list archive for 2/8 - 2/10, and briefly at the last WG > >session. My > >understanding from the authors was that they just didn't > >belive this case > >was valid and therefore didn't need to be addressed in the > >draft. Given > >that draft-lefaucheur-diff-te-reqts-00.txt raises the same issue (in > >section 3), I think the diff-ext draft should be fixed to > >allow for non-DS > >and DS LSRs in the same network. > > > >Lou > > > >PS As mentioned back on 2/8, I believe one trivial solution is > >to require > >the use of the DiffServ Object/TLV for all E-LSPs, where use of > >preconfigured EXP<-->PHB mappings is indicated by either (pick > >one) no map > >parameters or a single map parameter set to all zeros. > >Another solution is > >to use the one proposed in > >draft-lefaucheur-diff-te-ext-00.txt, although it > >does use a new object that could just be merged with the > >DiffServ Object. > > > >At 12:08 PM 7/19/00 -0400, George Swallow wrote: > >>This message begins a last calls on: > >> > >> draft-ietf-mpls-diff-ext-06.txt and > >> draft-ietf-mpls-rsvp-lsp-tunnel-06.txt > >> > >>The last calls will end on July 26 midnight GMT. Comment are limited > >>to the deltas between these and their respective prior drafts. > >> > >>With regard to the RSVP-TE draft, the recent comments to the list are > >>accepted as last call comments and need not be repeated. > >> > >>...George > >> > >>====================================================================== > >>George Swallow Cisco Systems (978) 244-8143 > >> 250 Apollo Drive > >> Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Fri Jul 21 12:43: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 MAA29379 for ; Fri, 21 Jul 2000 12:43:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyva29504; Fri, 21 Jul 2000 16:40:10 GMT Received: by mail-control.mail.uu.net id QQiyva11411 for mpls-outgoing; Fri, 21 Jul 2000 16:39: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 QQiyva11369 for ; Fri, 21 Jul 2000 16:39:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyva12999 for ; Fri, 21 Jul 2000 12:39:09 -0400 (EDT) Received: from csa.iisc.ernet.in by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQiyva27007 for ; Fri, 21 Jul 2000 16:38:37 GMT Received: from diamond.csa.iisc.ernet.in (IDENT:root@diamond.csa.iisc.ernet.in [144.16.67.28]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id WAA31954; Fri, 21 Jul 2000 22:09:03 +0530 Received: from localhost (ytr@localhost) by diamond.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id WAA23466; Fri, 21 Jul 2000 22:08:35 +0530 X-Authentication-Warning: diamond.csa.iisc.ernet.in: ytr owned process doing -bs Date: Fri, 21 Jul 2000 22:08:34 +0530 (IST) From: Ramanjaneyulu Y T To: Ho Ee Lock cc: mpls@UU.NET Subject: Re: Questions regarding MPLS In-Reply-To: <20000721014454.4202.qmail@web122.yahoomail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id MAA29379 Hi, please refer IEEE magazine on comm., Dec'1999 and Jan 2000 issue for MPLS evolution and QOS routing and MPLS Vs IP Etc. . please go through the following sites to get concepts about MPLS. http://www.mplsrc.com http://raonet.com/mns/ for MPLS simulator. Regards Ramanjaneyulu Y T ------------------------------------------------- On Thu, 20 Jul 2000, Ho Ee Lock wrote: > I am interested in studying some related works > in MPLS. However, there are some questions I am in > doubt. > > Firstly, I wonder whether there are papars out there > describing the performance of IP using MPLS switching > technologies. I wanted to study MPLS in that line, but > I found no references to it. I hope someone can kindly > refer me to some useful resource(eg. papers, journals) > concerning this matter (if there are any of them, > currently). > > Also, does anybody know about some simulation software > that is used to gauge the performance of MPLS > available in the Internet? > > I am looking forward to hearing some responses. I > believe it would help me a lot in my research. > > Thank you. > > Regards, > Ho Ee Lock > eelock@yahoo.com > > > > > __________________________________________________ > Do You Yahoo!? > Get Yahoo! Mail – Free email you can access from anywhere! > http://mail.yahoo.com/ > From owner-mpls@UU.NET Fri Jul 21 12:59: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 MAA06462 for ; Fri, 21 Jul 2000 12:59:34 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvb21726; Fri, 21 Jul 2000 16:57:58 GMT Received: by mail-control.mail.uu.net id QQiyvb12784 for mpls-outgoing; Fri, 21 Jul 2000 16:57: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 QQiyvb12704 for ; Fri, 21 Jul 2000 16:57: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 QQiyvb19265 for ; Fri, 21 Jul 2000 12:57:05 -0400 (EDT) Received: from csa.iisc.ernet.in by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQiyvb19730 for ; Fri, 21 Jul 2000 16:56:32 GMT Received: from diamond.csa.iisc.ernet.in (IDENT:root@diamond.csa.iisc.ernet.in [144.16.67.28]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id WAA32106 for ; Fri, 21 Jul 2000 22:26:59 +0530 Received: from localhost (ytr@localhost) by diamond.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id WAA23549 for ; Fri, 21 Jul 2000 22:26:31 +0530 X-Authentication-Warning: diamond.csa.iisc.ernet.in: ytr owned process doing -bs Date: Fri, 21 Jul 2000 22:26:30 +0530 (IST) From: Ramanjaneyulu Y T cc: mpls@UU.NET Subject: Simulator required In-Reply-To: <20000721014454.4202.qmail@web122.yahoomail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I need MPLS simulator with RSVP ( for label distribution) . If u know any such simulators please respond with URLs . Till now i seen Simulators with LDP ( label distribution). Thankyou Regards YTR From owner-mpls@UU.NET Fri Jul 21 13:01: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 NAA07231 for ; Fri, 21 Jul 2000 13:01:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvb24017; Fri, 21 Jul 2000 16:59:37 GMT Received: by mail-control.mail.uu.net id QQiyvb13037 for mpls-outgoing; Fri, 21 Jul 2000 16:59:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiyvb13031 for ; Fri, 21 Jul 2000 16:59: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 QQiyvb16239 for ; Fri, 21 Jul 2000 12:58:51 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyvb26870 for ; Fri, 21 Jul 2000 16:58:51 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id LAA28192; Fri, 21 Jul 2000 11:58:38 -0500 Message-Id: <4.3.2.7.2.20000721123733.00c9ea00@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 12:59:04 -0400 To: Shahram Davari From: Lou Berger Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) Cc: "'Lou Berger'" , George Swallow , mpls@UU.NET In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B406A3@nt-exchange-bby.p mc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Shahram, see below. At 09:31 AM 7/21/00 -0700, Shahram Davari wrote: >Hi Lou, George > > >PS As mentioned back on 2/8, I believe one trivial solution is > >to require > >the use of the DiffServ Object/TLV for all E-LSPs, where use of > >preconfigured EXP<-->PHB mappings is indicated by either (pick > >one) no map > >parameters or a single map parameter set to all zeros. > >Another solution is > >to use the one proposed in > >draft-lefaucheur-diff-te-ext-00.txt, although it > >does use a new object that could just be merged with the > >DiffServ Object. > >Your solution is ONLY valid if a single LSR could be both a Diffserv LSR and >a non-Diffserv LSR. It works for both cases, i.e., for the cases where a DS LSR can support non-DS LSPs and when it cannot. In the latter case, a PathErr with an appropriate code&value would need to be generated. >So it could use the presence of Diffserv object to >decide what behavior it should have (Diffserv behavior or non-Diffserv >behavior).I don't see any benefit in having a single LSR to be both a >Diffserv LSR and a non-Diffserv LSR. If the purpose is to support both >standardized PHBs and some local behavior that are not standardized, you >could always use the Diffserv local-PHBs. We covered this the last time around. Here's a relevant excerpt: >Date: Wed, 09 Feb 2000 16:57:57 -0500 >To: Shahram Davari >From: Lou Berger >Subject: RE: Announcing draft-ietf-mpls-diff-ext-03.txt >Cc: "'Lou Berger'" , "'Jim Boyle'" , > mpls@UU.NET >Sender: owner-mpls@UU.NET >[...] LB: >> > >> > One (new) point, your implicit mode hijacks existing >> > signaling mechanisms >> > and gives them new meaning. (Now that I think of it, this is >> > a large part >> > of my objection to the current form of the draft.) For >> > non-DS nodes, CoS >> > behavior can be provided by signaling a CoS LSP and not using >> > the EXP bits >> > at all. If that same LSP hits a DS node with the current >> > draft, it will be >> > treated as an E-LSP and the matching traffic will receive the >> > service that >> > matches bits 000. SD: >>First of all you have the same situation in a non-MPLS and Diffserv network. >>Do you plan to add signaling to them too? LB: >No because all traffic is best-effort in a DS network. There would be >some work to resolve conflicts if you were trying to support RSVP on the >same links/data as DS. SD: >>Secondly it is a misconfiguration to use a non-DS node in a Diffserv network >>and it is very unusual to use a DS-node in a Diffserv network that supports >>non-Diffserv behavior too. So why don't we choose the DS-behavior to be a >>default behavior in a Diffserv network, and use another object for signaling >>those rare non-DS LSPs? LB: >So you're suggesting a new object/TLV that says "I'm not diff-serv" rather >than have the new feature say "I'm diff-serv"? I don't get it. We're >talking about few bytes of overhead that you've already defined and are >willing to incur for all L-LSPs and some E-LSPs. We're not talking about >any substantive change in processing or state. SD: >>Remember the only situation that you would use a configured E-LSP is when >>you are sure that all your nodes are configured and can support the required >>PHBs. LB: >this is not correct. With the current definition, as soon as you >configure a node to be a DS node, all established LSPs are E-LSPs or L-LSPs. > >Albeit a corner case for non-green field networks, I think you're >requiring the configuration of all your nodes at the same moment of time >or just not caring about the traffic service levels during reconfig. Do >you view this as acceptable? > >Lou That's it. Lou >Regards, >-Shahram From owner-mpls@UU.NET Fri Jul 21 13:23: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 NAA20263 for ; Fri, 21 Jul 2000 13:23:57 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvd14565; Fri, 21 Jul 2000 17:22:29 GMT Received: by mail-control.mail.uu.net id QQiyvd25803 for mpls-outgoing; Fri, 21 Jul 2000 17:22: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 QQiyvd25794 for ; Fri, 21 Jul 2000 17:21: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 QQiyvd22977 for ; Fri, 21 Jul 2000 13:21:51 -0400 (EDT) Received: from zrtps06s.us.nortel.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [47.140.48.50]) id QQiyvd13801 for ; Fri, 21 Jul 2000 17:21:35 GMT Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Fri, 21 Jul 2000 13:06:57 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 21 Jul 2000 13:06:55 -0400 Message-ID: <03E3E0690542D211A1490000F80836F4029F981F@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'mpls@UU.NET'" Subject: RE: draft-ashwood-generalized-mpls-signaling-00 Date: Fri, 21 Jul 2000 13:06:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF336.0D070290" 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_01BFF336.0D070290 Content-Type: text/plain Thanks Adrian, I have filed away your comments for a future editing session. I personally have no problems with any of your suggestions but I suspect the first one may cause some interesting debate. Might be fun to argue about it in Pittsburgh. Cheers, Peter -----Original Message----- From: Adrian Farrel [SMTP:AF@datcon.co.uk] Sent: Friday, July 21, 2000 11:33 AM To: lberger@labn.net; Ashwood-Smith, Peter [CAR:CS57:EXCH] Cc: mpls@UU.NET Subject: draft-ashwood-generalized-mpls-signaling-00 Peter, Lou, Good draft. Attached a few small questions, a couple of editorial suggestions and a clutch of typos. I hope this helps. Regards, Adrian Questions ========= 1. I know I was shot down last time I suggested this, but that was in the optical discussion before the draft became "generalized"... Given that we can now set up LSPs as downstream on demand, or downstream on demand AND downstream unsolicited at the same time i.e. bidirectional), why don't we allow downstream unsolicited on its own? This would make for a fully generalized solution . The answer before was "There are no applications for this," but I would argue for making this fully generalized while we're at this stage especially since the work is simply to relax the requirement that 'label request' must be present on REQUEST/Path to say that at least one of 'label request', 'label' and 'generalized label' must be present. 2. Is it an issue that you cannot choose at LSP set up whether the LSP will switch a wavelength or the whole fiber? Since this is a property of the link and not of the signaled label, a link's usage for wavelength switching or whole fiber switching cannot be selected dynamically. Is this an issue? 3. Could you explain the "compatibility reasons" why a new c-type is required for a Generalized Label that contains a Waveband Label? I've looked through the archive and can't find any reference - sorry if I wasn't paying attention when this was discussed. 4. Would it be worth prohibiting bidirectional LSP setup where the forward label is of one type and the reverse label of a different type? This would be a bit odd since the resource requirements are the same in both directions. 5. I like the concept of Egress Label in an ERO to support splicing to an existing tunnel. Would now not be a good time to add support for stacking as well? The ERO suboject format would match that of Egress Label, but a new type would be needed. I'm sure there would be many uses in the optical world. Compare with the ER-Hop type of LSPID in CR-LDP. Editorial ========= Section 1, item 3. I think this could usefully mention wavebands up front. Simply add "or waveband"? Section 3.1.3. Need to clarify the description of LSP Encoding Type since currently "transparently passed by transit node" appears to contradict 3.1.2. "forwarded unchanged" might be a better description. Section 3.2.2. Cover bidirectional labels by adding to the end of the first paragraph to say "or downstream in REQUEST/Path messages as specified in section 4.2 for bidirectional LSP set up." Typos ===== Page header shows "Draftraft" 2., para 3, line 1 Strike duplicate "and" 2., para 3, line 2 Read "...is that bandwidth allocation for a non-PSC LSP..." 2., para 6, line 4 For "come" read "comes" 3., para 1 For "such at the ingress" read "such that the ingress" 3.2.1, Link ID, 1st line, For "request" read "requested" -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 ------_=_NextPart_001_01BFF336.0D070290 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-ashwood-generalized-mpls-signaling-00

Thanks Adrian,

     I have filed = away your comments for a future editing session. I personally have no = problems with any of your suggestions but I suspect the first one may = cause some interesting debate. Might be fun to argue about it in = Pittsburgh.

     = Cheers,

     Peter

    -----Original = Message-----
    From:   Adrian Farrel = [SMTP:AF@datcon.co.uk]
    Sent:   Friday, July 21, 2000 11:33 AM
    To:     lberger@labn.net; Ashwood-Smith, Peter = [CAR:CS57:EXCH]
    Cc:     mpls@UU.NET
    Subject:       = draft-ashwood-generalized-mpls-signaling-00

    Peter, Lou,

    Good draft.

    Attached a few small questions, a = couple of editorial suggestions and a
    clutch of typos.

    I hope this helps.

    Regards,
    Adrian

    Questions
    =3D=3D=3D=3D=3D=3D=3D=3D=3D

    1. I know I was shot down last time I = suggested this, but that was
       in the optical = discussion before the draft became "generalized"...
       Given that we can now = set up LSPs as downstream on demand, or
       downstream on demand AND = downstream unsolicited at the same time
       i.e. bidirectional), why = don't we allow downstream unsolicited on
       its own?  This = would make for a fully generalized solution .
       The answer before was = "There are no applications for this," but I
       would argue for making = this fully generalized while we're at this
       stage especially since = the work is simply to relax the requirement
       that 'label request' = must be present on REQUEST/Path to say that at
       least one of 'label = request', 'label' and 'generalized label' must
       be present.

    2. Is it an issue that you cannot = choose at LSP set up whether the LSP
       will switch a wavelength = or the whole fiber?  Since this is a
       property of the link and = not of the signaled label, a link's usage
       for wavelength switching = or whole fiber switching cannot be
       selected = dynamically.  Is this an issue?

    3. Could you explain the = "compatibility reasons" why a new c-type is
       required for a = Generalized Label that contains a Waveband Label?
       I've looked through the = archive and can't find any reference - sorry
       if I wasn't paying = attention when this was discussed.

    4. Would it be worth prohibiting = bidirectional LSP setup where the
       forward label is of one = type and the reverse label of a different
       type?  This would = be a bit odd since the resource requirements are
       the same in both = directions.

    5. I like the concept of Egress Label = in an ERO to support splicing to
       an existing = tunnel.  Would now not be a good time to add support
       for stacking as = well?  The ERO suboject format would match that of
       Egress Label, but a new = type would be needed.  I'm sure there would
       be many uses in the = optical world.

       Compare with the ER-Hop = type of LSPID in CR-LDP.

    Editorial
    =3D=3D=3D=3D=3D=3D=3D=3D=3D

    Section 1, item 3.  I think this = could usefully mention wavebands up front.
    Simply add "or = waveband"?

    Section 3.1.3. Need to clarify the = description of LSP Encoding Type since
    currently "transparently passed = by transit node" appears to contradict
    3.1.2.  "forwarded = unchanged" might be a better description.

    Section 3.2.2. Cover bidirectional = labels by adding to the end of the first
    paragraph to say "or downstream = in REQUEST/Path messages as specified in
    section 4.2 for bidirectional LSP set = up."

    Typos
    =3D=3D=3D=3D=3D

    Page header shows = "Draftraft"

    2., para 3, line 1 Strike duplicate = "and"

    2., para 3, line 2 Read "...is = that bandwidth allocation for a non-PSC
    LSP..."

    2., para 6, line 4 For = "come" read "comes"

    3., para 1  For "such at the = ingress" read "such that the ingress"

    3.2.1, Link ID, 1st line, For = "request" read "requested"

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

------_=_NextPart_001_01BFF336.0D070290-- From owner-mpls@UU.NET Fri Jul 21 13:29: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 NAA24160 for ; Fri, 21 Jul 2000 13:29:45 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvd19201; Fri, 21 Jul 2000 17:28:30 GMT Received: by mail-control.mail.uu.net id QQiyvd26238 for mpls-outgoing; Fri, 21 Jul 2000 17:28: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 QQiyvd26222 for ; Fri, 21 Jul 2000 17:27: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 QQiyvd23789 for ; Fri, 21 Jul 2000 13:27:46 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQiyvd26347 for ; Fri, 21 Jul 2000 17:27:45 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA19686; Fri, 21 Jul 2000 10:27:45 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id KAA15831; Fri, 21 Jul 2000 10:26:20 -0700 (PDT) Date: Fri, 21 Jul 2000 10:26:20 -0700 (PDT) From: Kireeti Kompella Message-Id: <200007211726.KAA15831@kummer.juniper.net> To: kireeti@juniper.net, mjork@avici.com Subject: Re: New Internet Draft: TE over Unnumbered Links Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi Marcus, > you have picked the value 3 for the new "Unnumbered Interface ID" > ERO subobject type. Can you please make that some other value. > draft-ietf-mpls-rsvp-lsp-tunnel-06.txt has just assigned > subobject type 3 to the "Label" subobject. Ah. Okay, I'll change it (to 4). I didn't look at the RRO. > Speaking of RROs, shouldn't the new subobject not also be used > in there? Good point. Lou Berger also raised this point; I'll address this in the next rev. Thanks for the comments! Kireeti. From owner-mpls@UU.NET Fri Jul 21 13:34: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 NAA28056 for ; Fri, 21 Jul 2000 13:34:45 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyve03026; Fri, 21 Jul 2000 17:33:17 GMT Received: by mail-control.mail.uu.net id QQiyve26541 for mpls-outgoing; Fri, 21 Jul 2000 17:32: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 QQiyve26536 for ; Fri, 21 Jul 2000 17:32: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 QQiyve24606 for ; Fri, 21 Jul 2000 13:32:39 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiyve01595 for ; Fri, 21 Jul 2000 17:32:08 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA23101; Fri, 21 Jul 2000 10:32:21 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA04380; Fri, 21 Jul 2000 13:32:06 -0400 (EDT) Message-Id: <200007211732.NAA04380@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Lou Berger cc: Eric Gray , "MPLS Mailing List (E-mail)" , "'George Swallow'" Subject: Re: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt In-reply-to: Your message of Thu, 20 Jul 2000 17:10:17 -0400. <4.3.2.7.2.20000720160408.00e5b210@mail.labn.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Fri, 21 Jul 2000 13:32:06 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk I think the basic question is whether there is a use for a "one hop" compression strategy. Some people have mentioned voice traffic as an application for which compression would be required. If voice packets tend to be very small, then compression might well be significant, even on higher speed lines. However, that does not seem to me to be a good application of a "one hop" compression scheme. It seems much better suited to a scheme which compresses at the LSP ingress and decompresses at the LSP egress, such as is described in draft- swallow-mpls-simple-hdr-compress.txt. So we're back to the case of low speed access lines carrying MPLS traffic in a non-voice application, and I still haven't seen a clear statement of the need. You do hint at one: Lou> Think MPLS based access links that support VPNs, as one example. I'm not aware of a VPN scheme which requires running MPLS over low speed access links. But let me see if I can guess what you might be talking about. One could imagine a piece of Customer Premises Equipment (CPE), a router, which has an ethernet interface (to connect to endusers) and a low speed wireless interface (to connect to the backbone). One could also imagine that when the CPE receives an ethernet packet, it assign it to a VPN according to some criteria. One could also imagine that the CPE maintains an LSP for each VPN, with the next LSP hop being another router which is reached over the wireless interface. If this is the sort of thing you're talking about, then I do see how a "single hop" header compression scheme could be useful. Of course, you could say what you're talking about and save the rest of us the trouble of having to surmise it ;-) I have a little more trouble imagining why a packet on this link would carry more than one label. But perhaps the usefulness of the compression doesn't depend on there being more than one label. Whether this is actually a good solution to the problem of a multi-VPN CPE connected by a slow link to the backbone is something on which I'll reserve judgment. Of course, if I haven't guessed correctly the application you have in mind, then I still don't see the use of the compression. From owner-mpls@UU.NET Fri Jul 21 13:39: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 NAA02018 for ; Fri, 21 Jul 2000 13:39:40 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyve11079; Fri, 21 Jul 2000 17:39:36 GMT Received: by mail-control.mail.uu.net id QQiyve26847 for mpls-outgoing; Fri, 21 Jul 2000 17:38: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 QQiyve26842 for ; Fri, 21 Jul 2000 17:38: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 QQiyve22023 for ; Fri, 21 Jul 2000 13:38:03 -0400 (EDT) Received: from exchange.sd.osicom.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [131.143.32.20]) id QQiyve25993 for ; Fri, 21 Jul 2000 17:37:47 GMT Received: by exchange.sd.osicom.com with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jul 2000 10:36:59 -0700 Message-ID: From: "Guo, Dan" To: "'Lou Berger'" , "Guo, Dan" Cc: "Zhang, Leah" , Jonathan Lang , "Fu, James" , mpls@UU.NET Subject: RE: A new draft. Date: Fri, 21 Jul 2000 10:35:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF33A.45A1BDF0" 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_01BFF33A.45A1BDF0 Content-Type: text/plain; charset="iso-8859-1" Lou, i appreciate/like your kind response (i apologize for mis-spelling Jonathan's name) some comments follow and hope it helps. >> 2. Contention scenario 2 outlined in Janathon's email: >> >> Our approach naturally AVOIDs the problem. >> >> The approach by Janathan (as well as in the Generalized draft) is a >> valid >> one to RESOLVE contention. >> >> The difference is, we are for Contention-avoidance and the other >> approach (through PathErr) is for Contention-resolution (as result, >> one node >> loses and has to start over). Our approach lowers the chance to get >> into the >> trap of contention. >> >> I also want to raise one point: The contention scenario 2 (outlined by >> Janathon) occurs NOT because "there are only enough resources for >> one of the >> bi-directional LSPs" as mentioned in Janathon's email. It can still >> happen when >> there are plenty of resources but two neighboring nodes grab the >> same link >> due to not-knowing-each-other's-actions. It is a race condition due >> to lack of >> synchronization. >As mentioned in my last mail the right solution to cover this case is to >use LabelSet. The document should have discussed this in the context of >bi-directional LSPs. We can fix this in the next, rev. >I think we handle this particular error in a similar fashion >(PathErr). When using LabelSet (with a single element) both labels can be >allocated on the Path message. If the downstream node finds the label in >the LabelSet unacceptable (for contention or any other reason) it responds >with a PathErr. [Dan's comment] when you revise the generalized draft, i hope you study if it is worthwhile to adopt the special way of allocating a pair of labels, detailed in our draft. Conventional Way: 1. Node -----> Node A <----- B Our way: 2. Node Node <----- Node C -----> A B By using way 2 instead way 1, it avoids the contention scenario 2 (see Jonathan's email) and thus avoids those special/unnecessary PathErrs. PathErr will occur only for contention scenario 1 (see Jonathan's email). >>I hope the generalized draft by Janathan/Lou and others can absorb some of >>points in our drafts. >Absolutely. We'll at least have a draft that better explains different >scenarios. (sorry about not doing a better job.) thanks! i think you/others did a terrific job in coordiating things to reach consensus. >I'm still not sure if >there's anything in your draft that is not functionally provided in the >-generalized draft. Certainly the -generalized draft uses different >mechanisms, but are there any functions that are missing or broken relative >to your draft? [Dan's comments] In terms of high-level functions, i agree our draft (draft-sorrento-rsvp-bi-osp-00.txt) provides a subset of functions from your draft. i personally think contention-avoidance (as compared to contention resolution) may be considered as a low-level function. However, as our draft did not avoid the 2nd type of contentions, the value is limited somewhat. We will put some more study. sincerely, Dan ------_=_NextPart_001_01BFF33A.45A1BDF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A new draft.

Lou, i appreciate/like your kind response (i = apologize for mis-spelling Jonathan's name)
some comments follow and hope it helps.

>>    2. Contention scenario 2 = outlined in Janathon's email:
>>
>>       Our = approach naturally AVOIDs the problem.
>>
>>       The = approach by Janathan (as well as in the Generalized draft) is a
>> valid
>>       one to = RESOLVE contention.
>>
>>       The = difference is, we are for Contention-avoidance and the other
>>       = approach (through PathErr) is for Contention-resolution (as result, =
>> one node
>>       loses = and has to start over). Our approach lowers the chance to get
>> into the
>>          = trap of  contention.
>>
>>      I also want = to raise one point: The contention scenario 2 (outlined by
>>      Janathon) = occurs NOT because "there are only enough resources for
>> one of the
>>       = bi-directional LSPs" as mentioned in Janathon's email. It can = still
>> happen when
>>      there are = plenty of resources but two neighboring nodes grab the
>> same link
>>       due to = not-knowing-each-other's-actions. It is a race condition due
>> to lack of
>>       = synchronization.

>As mentioned in my last mail the right solution = to cover this case is to
>use LabelSet.  The document should have = discussed this in the context of
>bi-directional LSPs.  We can fix this in = the next, rev.

>I think we handle this particular error in a = similar fashion
>(PathErr).  When using LabelSet (with a = single element) both labels can be
>allocated on the Path message.  If the = downstream node finds the label in
>the LabelSet unacceptable (for contention or any = other reason) it responds
>with a PathErr.
[Dan's comment]
when you revise the generalized draft, i hope you = study if it is worthwhile
to adopt the special way of allocating a pair of = labels, detailed in our draft.
   Conventional Way:
     = 1.           &nbs= p; Node    -----> Node
          &nb= sp;           = A    <-----  B
   Our way:
     2.   = Node       Node  <----- = Node
          C  = ----->   = A           B

By using way 2 instead way 1, it avoids the = contention scenario 2 (see Jonathan's email)
and thus avoids those special/unnecessary = PathErrs.  PathErr will occur only for
contention scenario 1 (see Jonathan's email). =

>>I hope the generalized draft by Janathan/Lou = and others can absorb some of
>>points in our drafts.

>Absolutely.  We'll at least have a draft = that better explains different
>scenarios.  (sorry about not doing a better = job.) 
thanks! i think you/others did a terrific job in = coordiating things to reach consensus.
 
>I'm still not sure if
>there's anything in your draft that is not = functionally provided in the
>-generalized draft.  Certainly the = -generalized draft uses different
>mechanisms, but are there any functions that are = missing or broken relative
>to your draft?

[Dan's comments]
In terms of high-level functions, i agree our draft = (draft-sorrento-rsvp-bi-osp-00.txt)
 provides a subset of functions from your = draft.
i personally think contention-avoidance (as compared = to contention resolution) may
be considered as a low-level function. However, as = our draft did not avoid the 2nd
type of contentions, the value is limited somewhat. = We will put some more study.

sincerely,
Dan

------_=_NextPart_001_01BFF33A.45A1BDF0-- From owner-mpls@UU.NET Fri Jul 21 13:53: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 NAA11421 for ; Fri, 21 Jul 2000 13:53:54 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvf06806; Fri, 21 Jul 2000 17:53:49 GMT Received: by mail-control.mail.uu.net id QQiyvf28063 for mpls-outgoing; Fri, 21 Jul 2000 17:53: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 QQiyvf28054 for ; Fri, 21 Jul 2000 17:53:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyvf28006 for ; Fri, 21 Jul 2000 13:52:56 -0400 (EDT) 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 QQiyvf05869 for ; Fri, 21 Jul 2000 17:52:30 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA20716 for mpls@uu.net; Fri, 21 Jul 2000 13:52:29 -0400 (EDT) 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 QQiyvf27940 for ; Fri, 21 Jul 2000 17:51: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 QQiyvf27739 for ; Fri, 21 Jul 2000 13:51:14 -0400 (EDT) Received: from postal.redback.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: postal.redback.com [155.53.12.9]) id QQiyvf05050 for ; Fri, 21 Jul 2000 17:51:14 GMT Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id 9DE2E17BC2F; Fri, 21 Jul 2000 10:51:12 -0700 (PDT) Received: (from rahul@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id KAA24610; Fri, 21 Jul 2000 10:50:25 -0700 (PDT) Date: Fri, 21 Jul 2000 10:50:24 -0700 From: Rahul Aggarwal To: Kireeti Kompella Cc: mpls@UU.NET Subject: Re: New Internet Draft: TE over Unnumbered Links Message-ID: <20000721105024.A23393@malt.redback.com> References: <200007210912.CAA14653@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200007210912.CAA14653@kummer.juniper.net> Sender: owner-mpls@UU.NET Precedence: bulk Kireeti, A couple of comments: 1. Maybe there is a need to enhance the semantics of the RSVP_HOP object to work over unnumbered links. The ip address of the previous hop could be set to the router id of the previous hop. 2. This is more of a clarification. Consider: A----------B-----------C Ia Ib Ic The link from B to C is unnumbered. My understanding from the draft is that B will generate the interface id for Ic. (and C for Ib) Is that correct? The ero could be . Since B generated the id for Ic, it will know the outgoing interface to send the path msg to C. C will receive the ero as . Now C needs to check the ero to see if it belongs to the first subobject i.e. Ic. How should this check be done? This goes back to (1) above. thanks, rahul On Fri, Jul 21, 2000 at 02:12:04AM -0700, Kireeti Kompella wrote: > Hi, > > FYI: we have a new Internet draft for doing TE over unnumbered links. > This draft will shortly be sent to the IETF, but may not be posted > prior to the coming IETF, so the text follows. > > Kireeti. > ------- > > > > > > > Network Working Group Kireeti Kompella > Internet Draft Juniper Networks > Expiration Date: January 2001 Yakov Rekhter > Cisco Systems > > > Traffic Engineering with Unnumbered Links > > draft-kompella-mpls-unnum-00.txt > > > 1. Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as ``work in progress.'' > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > > 2. Abstract > > Traffic Engineering currently does not take into account unnumbered > links. There are two issues: carrying information about unnumbered > links in IS-IS and OSPF; and including unnumbered links when > signalling. This document addresses these two issues. > > > > > > > > > > > > > draft-kompella-mpls-unnum-00.txt [Page 1] > > Internet Draft draft-kompella-mpls-unnum-00.txt July 2000 > > > 3. Overview > > Traffic Engineering currently does not take into account unnumbered > links (i.e., links that do not have IP addresses). However, not > numbering links is useful, if not critical, in many environments; the > reasons include conserving IP addresses, and reducing management > overhead. This document only covers point-to-point links that are > unnumbered. > > There are two issues: carrying Traffic Engineering information about > unnumbered links in IS-IS and OSPF (see [ISIS-TE] and [OSPF-TE]); and > including unnumbered links when signalling (see [RSVP-TE]). This > document proposes a simple means of solving the former (modeled on > how OSPF carries unnumbered link information for router link > advertisements), and a simple extension to the RSVP Explicit Route > Object for the latter. > > > 4. Interface Identifiers > > If links are not identified by an IP address, they need some other > identifier. We assume that each unnumbered link on a Label Switched > Router (LSR) is given a unique 16-bit identifier. The scope of this > identifier is the LSR to which the link belongs; moreover, the > ISIS/OSPF and RSVP modules on an LSR must agree on interface > identifiers. A good candidate for the interface identifier is the > SNMP IfIndex of the interface. > > > 5. Carrying Unnumbered Links in IS-IS and OSPF > > In IS-IS, the extended IS reachability TLV contains an IPv4 Interface > Address, which normally identifies an IPv4 address for an interface. > If the interface being advertised for Traffic Engineering purposes is > unnumbered, the IPv4 Interface Address is set to the router ID of the > advertising LSR. The extended IS reachability TLV also contains an > IPv4 Neighbor Address, which normally identifies an IPv4 address of > the neighboring LSR on a link. If the interface being advertised for > Traffic Engineering purposes is unnumbered, the first two octets of > the IPv4 Neighbor Address are set to zero, and the next two octets > are set to the Interface ID of the unnumbered interface. The rest of > the Traffic Engineering information remains unchanged. > > In OSPF, the Link sub-TLV of the Opaque Traffic Engineering TLV > contains a Local Interface IP Address, which normally identifies the > IPv4 address for an interface. If the interface being advertised for > Traffic Engineering purposes is unnumbered, the Local Interface > Address is set to the router ID of the advertising LSR. The Link > > > > draft-kompella-mpls-unnum-00.txt [Page 2] > > Internet Draft draft-kompella-mpls-unnum-00.txt July 2000 > > > sub-TLV of the Opaque Traffic Engineering TLV also contains a Remote > Interface IP Address, which normally identifies the neighbor's IPv4 > address for the interface. If the interface being advertised for > Traffic Engineering purposes is unnumbered, the first two octets of > the Remote Interface IP Address are set to zero, and the next two > octets are set to the Interface ID of the unnumbered interface. The > rest of the Traffic Engineering information remains unchanged. > > > 6. Signalling Unnumbered Links in EROs > > A new subobject of the Explicit Route Object (ERO) is used to signal > unnumbered links. This subobject has the following format: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |L| Type | Length | Interface ID (16 bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > This subobject MUST be strict (i.e., the L bit MUST be 0). The Type > is 3 (Unnumbered Interface ID). The Length is 4. The Interface ID > is interpreted in the context of the previous node in the path (i.e., > the node identified by the previous subobject in the ERO, which MUST > identify a unique node), or, if this is the first subobject in the > ERO, in the context of the start of the path. The next node in the > path is the node at the other end of the interface identified by the > Interface ID. > > > 7. Security Considerations > > This document raises no new security concerns for IS-IS, OSPF or > RSVP. > > > 8. References > > [ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic > Engineering", draft-ietf-isis-traffic-01.txt (work in progress) > > [OSPF-TE] Katz, D., and Yeung, D., "Traffic Engineering Extensions to > OSPF", draft-katz-yeung-ospf-traffic-01.txt (work in progress) > > [RSVP-TE] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan, > V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", > draft-ietf-mpls-rsvp-lsp-tunnel-06.txt (work in progress) > > > > > draft-kompella-mpls-unnum-00.txt [Page 3] > > Internet Draft draft-kompella-mpls-unnum-00.txt July 2000 > > > 9. Author Information > > > Kireeti Kompella > Juniper Networks, Inc. > 385 Ravendale Drive > Mountain View, CA 94043 > e-mail: kireeti@juniper.net > > Yakov Rekhter > Cisco Systems, Inc. > 170 West Tasman Drive > San Jose, CA 95134 > e-mail: yakov@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > draft-kompella-mpls-unnum-00.txt [Page 4] From owner-mpls@UU.NET Fri Jul 21 14:00: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 OAA16605 for ; Fri, 21 Jul 2000 14:00:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvf11587; Fri, 21 Jul 2000 17:59:56 GMT Received: by mail-control.mail.uu.net id QQiyvf28555 for mpls-outgoing; Fri, 21 Jul 2000 17:59: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 QQiyvf28545 for ; Fri, 21 Jul 2000 17:59: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 QQiyvf25076 for ; Fri, 21 Jul 2000 13:58:12 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyvf05341 for ; Fri, 21 Jul 2000 17:57:56 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id MAA15552; Fri, 21 Jul 2000 12:57:47 -0500 Message-Id: <4.3.2.7.2.20000721134504.00bb7580@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 13:58:12 -0400 To: erosen@cisco.com From: Lou Berger Subject: Re: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Cc: Lou Berger , Eric Gray , "MPLS Mailing List (E-mail)" , "'George Swallow'" In-Reply-To: <200007211732.NAA04380@erosen-sun.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Eric, The reason why you'd use the "one hop" approach over simple is that the two compression schemes have vastly different efficiencies. (17 + 4 bytes/label versus 2 or 4 bytes. see slide 11 of my Adelaide presentation.) IMO the "one hop" approach is best suited for those links in the network that are very tightly constrained. This may be on very slow speed links or just "slower" speed links, where "slower" is limited by the hardware being used. I think your characterization below of an application is valid. The VPN example came in on a question of why there would ever be multiple labels. The case I was thinking about is were there is an inner label that indicates VPN and an outer label that indicates an egress. I didn't mean to be evasive, I just didn't think it was that complicated. I've also heard mentioned using label stacking where, as with VPNS, the inner label indicates an application session. Lou At 01:32 PM 7/21/00 -0400, Eric Rosen wrote: >I think the basic question is whether there is a use for a "one hop" >compression strategy. > >Some people have mentioned voice traffic as an application for which >compression would be required. If voice packets tend to be very small, then >compression might well be significant, even on higher speed lines. However, >that does not seem to me to be a good application of a "one hop" compression >scheme. It seems much better suited to a scheme which compresses at the LSP >ingress and decompresses at the LSP egress, such as is described in draft- >swallow-mpls-simple-hdr-compress.txt. > >So we're back to the case of low speed access lines carrying MPLS traffic in >a non-voice application, and I still haven't seen a clear statement of the >need. You do hint at one: > >Lou> Think MPLS based access links that support VPNs, as one example. > >I'm not aware of a VPN scheme which requires running MPLS over low speed >access links. But let me see if I can guess what you might be talking >about. > >One could imagine a piece of Customer Premises Equipment (CPE), a router, >which has an ethernet interface (to connect to endusers) and a low speed >wireless interface (to connect to the backbone). One could also imagine >that when the CPE receives an ethernet packet, it assign it to a VPN >according to some criteria. One could also imagine that the CPE maintains >an LSP for each VPN, with the next LSP hop being another router which is >reached over the wireless interface. > >If this is the sort of thing you're talking about, then I do see how a >"single hop" header compression scheme could be useful. > >Of course, you could say what you're talking about and save the rest of us >the trouble of having to surmise it ;-) > >I have a little more trouble imagining why a packet on this link would carry >more than one label. But perhaps the usefulness of the compression doesn't >depend on there being more than one label. > >Whether this is actually a good solution to the problem of a multi-VPN CPE >connected by a slow link to the backbone is something on which I'll reserve >judgment. > >Of course, if I haven't guessed correctly the application you have in mind, >then I still don't see the use of the compression. From owner-mpls@UU.NET Fri Jul 21 14:14: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 OAA27244 for ; Fri, 21 Jul 2000 14:14:53 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvg21542; Fri, 21 Jul 2000 18:14:48 GMT Received: by mail-control.mail.uu.net id QQiyvg10610 for mpls-outgoing; Fri, 21 Jul 2000 18:14: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 QQiyvg10587 for ; Fri, 21 Jul 2000 18:13:59 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyvg26918 for ; Fri, 21 Jul 2000 14:10:45 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQiyvg17683 for ; Fri, 21 Jul 2000 18:10:29 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA27211; Fri, 21 Jul 2000 11:10:42 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id OAA04508; Fri, 21 Jul 2000 14:10:27 -0400 (EDT) Message-Id: <200007211810.OAA04508@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Lou Berger cc: Eric Gray , "MPLS Mailing List (E-mail)" , "'George Swallow'" Subject: Re: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt In-reply-to: Your message of Fri, 21 Jul 2000 13:58:12 -0400. <4.3.2.7.2.20000721134504.00bb7580@mail.labn.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Fri, 21 Jul 2000 14:10:27 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Lou> The case I was thinking about is were there is an inner label that Lou> indicates VPN and an outer label that indicates an egress. What makes this case problematic is that pushing on these two labels would be a function of the Provider Edge router, which is much less likely than the CPE to be separated by a low speed link from the backbone. If you want your draft to be considered for standards track, I think it should have a much clearer statement of its purpose, maybe even something like "not recommended for use on links faster than 9.6Kb", or something like that. And a clear statement that its use is optional. That way when a potential customer complains that an implementation is not conformant to standards because it doesn't use single hop compression on its gigabit ethernet link, one can just refer the customer back to the document itself. From owner-mpls@UU.NET Fri Jul 21 14:20: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 OAA01263 for ; Fri, 21 Jul 2000 14:20:04 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvh04051; Fri, 21 Jul 2000 18:19:57 GMT Received: by mail-control.mail.uu.net id QQiyvh11248 for mpls-outgoing; Fri, 21 Jul 2000 18:19: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 QQiyvh11233 for ; Fri, 21 Jul 2000 18:19: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 QQiyvh28183 for ; Fri, 21 Jul 2000 14:17:56 -0400 (EDT) Received: from lux.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged)) id QQiyvh24399 for ; Fri, 21 Jul 2000 18:17:26 GMT Received: by LUX with Internet Mail Service (5.5.2448.0) id ; Fri, 21 Jul 2000 11:17:25 -0700 Message-ID: <51DA0AB3D747D311832F005004827CC02CE87F@LUX> From: Jonathan Lang To: "'Guo, Dan'" , "'Lou Berger'" Cc: "Zhang, Leah" , Jonathan Lang , "Fu, James" , mpls@UU.NET Subject: RE: A new draft. Date: Fri, 21 Jul 2000 11:17:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF33F.EB7A2C88" 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_01BFF33F.EB7A2C88 Content-Type: text/plain; charset="iso-8859-1" Dan, For case 2 that I mentioned in a previous email (and referred to in both yours and Lou's email), if there are available resources, contention is always *avoided* with the Upstream Label for bi-directional LSPs outlined in draft-lang-mpls-rsvp-oxc-00.txt and draft-generalized-signaling-mpls-00.txt. I think Lou's suggestion about discussing these issues in Pitts. is a good one. -Jonathan Calient Networks -----Original Message----- From: Guo, Dan [mailto:dguo@sorrentonet.com] Sent: Friday, July 21, 2000 10:36 AM To: 'Lou Berger'; Guo, Dan Cc: Zhang, Leah; Jonathan Lang; Fu, James; mpls@UU.NET Subject: RE: A new draft. Lou, i appreciate/like your kind response (i apologize for mis-spelling Jonathan's name) some comments follow and hope it helps. >> 2. Contention scenario 2 outlined in Janathon's email: >> >> Our approach naturally AVOIDs the problem. >> >> The approach by Janathan (as well as in the Generalized draft) is a >> valid >> one to RESOLVE contention. >> >> The difference is, we are for Contention-avoidance and the other >> approach (through PathErr) is for Contention-resolution (as result, >> one node >> loses and has to start over). Our approach lowers the chance to get >> into the >> trap of contention. >> >> I also want to raise one point: The contention scenario 2 (outlined by >> Janathon) occurs NOT because "there are only enough resources for >> one of the >> bi-directional LSPs" as mentioned in Janathon's email. It can still >> happen when >> there are plenty of resources but two neighboring nodes grab the >> same link >> due to not-knowing-each-other's-actions. It is a race condition due >> to lack of >> synchronization. >As mentioned in my last mail the right solution to cover this case is to >use LabelSet. The document should have discussed this in the context of >bi-directional LSPs. We can fix this in the next, rev. >I think we handle this particular error in a similar fashion >(PathErr). When using LabelSet (with a single element) both labels can be >allocated on the Path message. If the downstream node finds the label in >the LabelSet unacceptable (for contention or any other reason) it responds >with a PathErr. [Dan's comment] when you revise the generalized draft, i hope you study if it is worthwhile to adopt the special way of allocating a pair of labels, detailed in our draft. Conventional Way: 1. Node -----> Node A <----- B Our way: 2. Node Node <----- Node C -----> A B By using way 2 instead way 1, it avoids the contention scenario 2 (see Jonathan's email) and thus avoids those special/unnecessary PathErrs. PathErr will occur only for contention scenario 1 (see Jonathan's email). >>I hope the generalized draft by Janathan/Lou and others can absorb some of >>points in our drafts. >Absolutely. We'll at least have a draft that better explains different >scenarios. (sorry about not doing a better job.) thanks! i think you/others did a terrific job in coordiating things to reach consensus. >I'm still not sure if >there's anything in your draft that is not functionally provided in the >-generalized draft. Certainly the -generalized draft uses different >mechanisms, but are there any functions that are missing or broken relative >to your draft? [Dan's comments] In terms of high-level functions, i agree our draft (draft-sorrento-rsvp-bi-osp-00.txt) provides a subset of functions from your draft. i personally think contention-avoidance (as compared to contention resolution) may be considered as a low-level function. However, as our draft did not avoid the 2nd type of contentions, the value is limited somewhat. We will put some more study. sincerely, Dan ------_=_NextPart_001_01BFF33F.EB7A2C88 Content-Type: text/html; charset="iso-8859-1" RE: A new draft.
Dan,
  For case 2 that I mentioned in a previous email (and referred to in both yours and Lou's email), if there are available resources, contention is always *avoided* with the Upstream Label for bi-directional LSPs outlined in draft-lang-mpls-rsvp-oxc-00.txt and draft-generalized-signaling-mpls-00.txt.  I think Lou's suggestion about discussing these issues in Pitts. is a good one.

-Jonathan

Calient Networks
-----Original Message-----
From: Guo, Dan [mailto:dguo@sorrentonet.com]
Sent: Friday, July 21, 2000 10:36 AM
To: 'Lou Berger'; Guo, Dan
Cc: Zhang, Leah; Jonathan Lang; Fu, James; mpls@UU.NET
Subject: RE: A new draft.

Lou, i appreciate/like your kind response (i apologize for mis-spelling Jonathan's name)
some comments follow and hope it helps.

>>    2. Contention scenario 2 outlined in Janathon's email:
>>
>>       Our approach naturally AVOIDs the problem.
>>
>>       The approach by Janathan (as well as in the Generalized draft) is a
>> valid
>>       one to RESOLVE contention.
>>
>>       The difference is, we are for Contention-avoidance and the other
>>       approach (through PathErr) is for Contention-resolution (as result,
>> one node
>>       loses and has to start over). Our approach lowers the chance to get
>> into the
>>          trap of  contention.
>>
>>      I also want to raise one point: The contention scenario 2 (outlined by
>>      Janathon) occurs NOT because "there are only enough resources for
>> one of the
>>       bi-directional LSPs" as mentioned in Janathon's email. It can still
>> happen when
>>      there are plenty of resources but two neighboring nodes grab the
>> same link
>>       due to not-knowing-each-other's-actions. It is a race condition due
>> to lack of
>>       synchronization.

>As mentioned in my last mail the right solution to cover this case is to
>use LabelSet.  The document should have discussed this in the context of
>bi-directional LSPs.  We can fix this in the next, rev.

>I think we handle this particular error in a similar fashion
>(PathErr).  When using LabelSet (with a single element) both labels can be
>allocated on the Path message.  If the downstream node finds the label in
>the LabelSet unacceptable (for contention or any other reason) it responds
>with a PathErr.
[Dan's comment]
when you revise the generalized draft, i hope you study if it is worthwhile
to adopt the special way of allocating a pair of labels, detailed in our draft.
   Conventional Way:
     1.             Node    -----> Node
                      A    <-----  B
   Our way:
     2.   Node       Node  <----- Node
          C  ----->   A           B

By using way 2 instead way 1, it avoids the contention scenario 2 (see Jonathan's email)
and thus avoids those special/unnecessary PathErrs.  PathErr will occur only for
contention scenario 1 (see Jonathan's email).

>>I hope the generalized draft by Janathan/Lou and others can absorb some of
>>points in our drafts.

>Absolutely.  We'll at least have a draft that better explains different
>scenarios.  (sorry about not doing a better job.) 
thanks! i think you/others did a terrific job in coordiating things to reach consensus.
 
>I'm still not sure if
>there's anything in your draft that is not functionally provided in the
>-generalized draft.  Certainly the -generalized draft uses different
>mechanisms, but are there any functions that are missing or broken relative
>to your draft?

[Dan's comments]
In terms of high-level functions, i agree our draft (draft-sorrento-rsvp-bi-osp-00.txt)
 provides a subset of functions from your draft.
i personally think contention-avoidance (as compared to contention resolution) may
be considered as a low-level function. However, as our draft did not avoid the 2nd
type of contentions, the value is limited somewhat. We will put some more study.

sincerely,
Dan

------_=_NextPart_001_01BFF33F.EB7A2C88-- From owner-mpls@UU.NET Fri Jul 21 14:21: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 OAA02548 for ; Fri, 21 Jul 2000 14:21:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvh28127; Fri, 21 Jul 2000 18:21:21 GMT Received: by mail-control.mail.uu.net id QQiyvh11318 for mpls-outgoing; Fri, 21 Jul 2000 18:20: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 QQiyvh11312 for ; Fri, 21 Jul 2000 18:20: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 QQiyvh02452 for ; Fri, 21 Jul 2000 14:20:37 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyvh05021 for ; Fri, 21 Jul 2000 18:20:36 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id NAA23246; Fri, 21 Jul 2000 13:20:22 -0500 Message-Id: <4.3.2.7.2.20000721140452.040ea9b0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 14:20:50 -0400 To: Adrian Farrel From: Lou Berger Subject: Re: draft-ashwood-generalized-mpls-signaling-00 Cc: lberger@labn.net, petera@nortelnetworks.com, mpls@UU.NET In-Reply-To: <6DEA508A9A0ED31192E80000F6CC176E2C9C11@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Adrian, Thank you for your usual quality comments. See below for some responses. Lou At 04:33 PM 7/21/00 +0100, Adrian Farrel wrote: >Peter, Lou, > >Good draft. > >Attached a few small questions, a couple of editorial suggestions and a >clutch of typos. > >I hope this helps. > >Regards, >Adrian > >Questions >========= > >1. I know I was shot down last time I suggested this, but that was > in the optical discussion before the draft became "generalized"... > Given that we can now set up LSPs as downstream on demand, or > downstream on demand AND downstream unsolicited at the same time > i.e. bidirectional), why don't we allow downstream unsolicited on > its own? This would make for a fully generalized solution . > The answer before was "There are no applications for this," but I > would argue for making this fully generalized while we're at this > stage especially since the work is simply to relax the requirement > that 'label request' must be present on REQUEST/Path to say that at > least one of 'label request', 'label' and 'generalized label' must > be present. I still think understanding a use for this makes sense before considering adding it. What application are you thinking about? Also, in the bidirectional case, I completely don't see the point. What am I missing? >2. Is it an issue that you cannot choose at LSP set up whether the LSP > will switch a wavelength or the whole fiber? Since this is a > property of the link and not of the signaled label, a link's usage > for wavelength switching or whole fiber switching cannot be > selected dynamically. Is this an issue? I don't think I understand the question. Perhaps we should just talk about this one face-to-face in Pittsburgh. >3. Could you explain the "compatibility reasons" why a new c-type is > required for a Generalized Label that contains a Waveband Label? > I've looked through the archive and can't find any reference - sorry > if I wasn't paying attention when this was discussed. It allows nodes that don't support waveband switching to respond with an appropriate error message. The message falls out of previously specified signaling behavior. For RSVP the relevant behavior is defined in RFC2205, under handling of "Unknown C-Type for Known Class". >4. Would it be worth prohibiting bidirectional LSP setup where the > forward label is of one type and the reverse label of a different > type? This would be a bit odd since the resource requirements are > the same in both directions. I'm not sure how you could signal setting up different label types in each direction. Do you see a way? >5. I like the concept of Egress Label in an ERO to support splicing to > an existing tunnel. Would now not be a good time to add support > for stacking as well? Again, I think this should be driven by application. If you've got one, lets talk about it. > The ERO suboject format would match that of > Egress Label, but a new type would be needed. I'm sure there would > be many uses in the optical world. > > Compare with the ER-Hop type of LSPID in CR-LDP. [Rest of original message delete, looked good to me.] Thanks again, Lou From owner-mpls@UU.NET Fri Jul 21 14:29: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 OAA09812 for ; Fri, 21 Jul 2000 14:29:53 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvh06373; Fri, 21 Jul 2000 18:29:47 GMT Received: by mail-control.mail.uu.net id QQiyvh11860 for mpls-outgoing; Fri, 21 Jul 2000 18:29:25 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiyvh11855 for ; Fri, 21 Jul 2000 18:29: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 QQiyvh03938 for ; Fri, 21 Jul 2000 14:29:00 -0400 (EDT) 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 QQiyvh13971 for ; Fri, 21 Jul 2000 18:28:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA02783 for mpls@uu.net; Fri, 21 Jul 2000 14:28:39 -0400 (EDT) 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 QQiyvh11807 for ; Fri, 21 Jul 2000 18:28:15 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyvh03739 for ; Fri, 21 Jul 2000 14:27:57 -0400 (EDT) Received: from yarilo.pluris.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQiyvh13194 for ; Fri, 21 Jul 2000 18:27:57 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 LAA01553; Fri, 21 Jul 2000 11:27:44 -0700 (PDT) Message-ID: <3978961F.E4FC032B@pluris.com> Date: Fri, 21 Jul 2000 11:27:43 -0700 From: Bora Akyol X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: erosen@cisco.com CC: Lou Berger , Eric Gray , "MPLS Mailing List (E-mail)" , "'George Swallow'" Subject: Re: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt References: <200007211732.NAA04380@erosen-sun.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I for one think that the one hop strategy is unacceptable especially if this continues "one hopping" through to the core routers. If the access box terminates the one hop compression and then sends normal MPLS packets then this is OK; otherwise, this is a major change in the architecture and should be avoided at all costs. Bora Eric Rosen wrote: > I think the basic question is whether there is a use for a "one hop" > compression strategy. > > Some people have mentioned voice traffic as an application for which > compression would be required. If voice packets tend to be very small, then > compression might well be significant, even on higher speed lines. However, > that does not seem to me to be a good application of a "one hop" compression > scheme. It seems much better suited to a scheme which compresses at the LSP > ingress and decompresses at the LSP egress, such as is described in draft- > swallow-mpls-simple-hdr-compress.txt. > > So we're back to the case of low speed access lines carrying MPLS traffic in > a non-voice application, and I still haven't seen a clear statement of the > need. You do hint at one: > > Lou> Think MPLS based access links that support VPNs, as one example. > > I'm not aware of a VPN scheme which requires running MPLS over low speed > access links. But let me see if I can guess what you might be talking > about. > > One could imagine a piece of Customer Premises Equipment (CPE), a router, > which has an ethernet interface (to connect to endusers) and a low speed > wireless interface (to connect to the backbone). One could also imagine > that when the CPE receives an ethernet packet, it assign it to a VPN > according to some criteria. One could also imagine that the CPE maintains > an LSP for each VPN, with the next LSP hop being another router which is > reached over the wireless interface. > > If this is the sort of thing you're talking about, then I do see how a > "single hop" header compression scheme could be useful. > > Of course, you could say what you're talking about and save the rest of us > the trouble of having to surmise it ;-) > > I have a little more trouble imagining why a packet on this link would carry > more than one label. But perhaps the usefulness of the compression doesn't > depend on there being more than one label. > > Whether this is actually a good solution to the problem of a multi-VPN CPE > connected by a slow link to the backbone is something on which I'll reserve > judgment. > > Of course, if I haven't guessed correctly the application you have in mind, > then I still don't see the use of the compression. From owner-mpls@UU.NET Fri Jul 21 14:39: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 OAA18265 for ; Fri, 21 Jul 2000 14:39:09 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvi14456; Fri, 21 Jul 2000 18:39:01 GMT Received: by mail-control.mail.uu.net id QQiyvi12510 for mpls-outgoing; Fri, 21 Jul 2000 18:38: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 QQiyvi12503 for ; Fri, 21 Jul 2000 18:38: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 QQiyvi05617 for ; Fri, 21 Jul 2000 14:38:19 -0400 (EDT) Received: from mail01.gmu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail01.gmu.edu [129.174.0.6]) id QQiyvi13589 for ; Fri, 21 Jul 2000 18:38:04 GMT Received: from thinkpad ([129.174.247.2]) by mail01.gmu.edu (Netscape Messaging Server 4.1) with ESMTP id FY293F00.VZG; Fri, 21 Jul 2000 14:38:03 -0400 Message-ID: <001501bff343$095b4cc0$dcfe1ac7@gmu.edu> From: "Lichung Chang" To: "Ramanjaneyulu Y T" Cc: References: Subject: Re: Simulator required Date: Fri, 21 Jul 2000 14:39:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ramanjaneyulu, Please check http://www.antd.nist.gov/itg/nistswitch/. Lichung ----- Original Message ----- From: Ramanjaneyulu Y T Cc: Sent: Friday, July 21, 2000 12:56 PM Subject: Simulator required > Hi, > > I need MPLS simulator with RSVP ( for label distribution) . If u know > any such simulators please respond with URLs . Till now i seen Simulators > with LDP ( label distribution). > > Thankyou > > Regards > YTR > > > > From owner-mpls@UU.NET Fri Jul 21 14:46: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 OAA24725 for ; Fri, 21 Jul 2000 14:46:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvj20764; Fri, 21 Jul 2000 18:46:07 GMT Received: by mail-control.mail.uu.net id QQiyvj13007 for mpls-outgoing; Fri, 21 Jul 2000 18:45: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 QQiyvj13002 for ; Fri, 21 Jul 2000 18:45: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 QQiyvj06769 for ; Fri, 21 Jul 2000 14:45:25 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyvj20168 for ; Fri, 21 Jul 2000 18:45:24 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id NAA31059; Fri, 21 Jul 2000 13:45:04 -0500 Message-Id: <4.3.2.7.2.20000721142258.00bafca0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 14:45:33 -0400 To: erosen@cisco.com From: Lou Berger Subject: Re: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Cc: Lou Berger , Eric Gray , "MPLS Mailing List (E-mail)" , "'George Swallow'" In-Reply-To: <200007211810.OAA04508@erosen-sun.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I have 0 issue with narrowing the scope. I suggest some alternate wording below. Lou At 02:10 PM 7/21/00 -0400, Eric Rosen wrote: >Lou> The case I was thinking about is were there is an inner label that >Lou> indicates VPN and an outer label that indicates an egress. > >What makes this case problematic is that pushing on these two labels would >be a function of the Provider Edge router, which is much less likely than >the CPE to be separated by a low speed link from the backbone. > >If you want your draft to be considered for standards track, I think it >should have a much clearer statement of its purpose, maybe even something >like "not recommended for use on links faster than 9.6Kb", or something like >that. How about "recommended for use on links where IP Header Compression [RFC2507, 2508] is, or can be used." >And a clear statement that its use is optional. 100% agreed. Again, just like IP Header Compression. >That way when a >potential customer complains that an implementation is not conformant to >standards because it doesn't use single hop compression on its gigabit >ethernet link, one can just refer the customer back to the document itself. From owner-mpls@UU.NET Fri Jul 21 14:50: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 OAA28275 for ; Fri, 21 Jul 2000 14:50:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvj09222; Fri, 21 Jul 2000 18:50:00 GMT Received: by mail-control.mail.uu.net id QQiyvj13251 for mpls-outgoing; Fri, 21 Jul 2000 18:49: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 QQiyvj13246 for ; Fri, 21 Jul 2000 18:49: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 QQiyvj07479 for ; Fri, 21 Jul 2000 14:49:14 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyvj08229 for ; Fri, 21 Jul 2000 18:49:14 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id NAA32268; Fri, 21 Jul 2000 13:49:00 -0500 Message-Id: <4.3.2.7.2.20000721144613.00d35a00@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 14:49:26 -0400 To: Bora Akyol From: Lou Berger Subject: Re: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Cc: erosen@cisco.com, Lou Berger , Eric Gray , "MPLS Mailing List (E-mail)" , "'George Swallow'" In-Reply-To: <3978961F.E4FC032B@pluris.com> References: <200007211732.NAA04380@erosen-sun.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Bora, It works just like standard IP header compression. (It is after all, just a minor extension to it.) "[...]the access box terminates the one hop compression and then sends normal MPLS packets [...]" is what is documented. Just like in normal IP header compression, a decompressor could compress on the outgoing link, but this isn't the norm. Lou At 11:27 AM 7/21/00 -0700, Bora Akyol wrote: >I for one think that the one hop strategy is unacceptable especially if this >continues "one hopping" through to the core routers. If the access box >terminates the one hop compression and then sends normal MPLS packets then >this >is OK; otherwise, this is a major change in the architecture and should be >avoided at all costs. > >Bora > > >Eric Rosen wrote: > > > I think the basic question is whether there is a use for a > "one hop" > > compression strategy. > > > > Some people have mentioned voice traffic as an > application for which > > compression would be required. If voice packets tend to be very small, > then > > compression might well be significant, even on higher speed > lines. However, > > that does not seem to me to be a good application of a "one hop" > compression > > scheme. It seems much better suited to a scheme which compresses at > the LSP > > ingress and decompresses at the LSP egress, such as is described in > draft- > > swallow-mpls-simple-hdr-compress.txt. > > > > So we're back to the case of low speed access lines carrying MPLS > traffic in > > a non-voice application, and I still haven't seen a clear statement > of the > > need. You do hint at one: > > > > Lou> Think MPLS based access links that support VPNs, as one example. > > > > I'm not aware of a VPN scheme which requires running MPLS over low > speed > > access links. But let me see if I can guess what you might be > talking > > about. > > > > One could imagine a piece of Customer Premises Equipment (CPE), a > router, > > which has an ethernet interface (to connect to endusers) and a low > speed > > wireless interface (to connect to the backbone). One could also > imagine > > that when the CPE receives an ethernet packet, it assign it to > a VPN > > according to some criteria. One could also imagine that the CPE > maintains > > an LSP for each VPN, with the next LSP hop being another > router which is > > reached over the wireless interface. > > > > If this is the sort of thing you're talking about, then I do > see how a > > "single hop" header compression scheme could be useful. > > > > Of course, you could say what you're talking about and save the rest > of us > > the trouble of having to surmise it ;-) > > > > I have a little more trouble imagining why a packet on this link would > carry > > more than one label. But perhaps the usefulness of the compression > doesn't > > depend on there being more than one label. > > > > Whether this is actually a good solution to the problem of a > multi-VPN CPE > > connected by a slow link to the backbone is something on which I'll > reserve > > judgment. > > > > Of course, if I haven't guessed correctly the application you have in > mind, > > then I still don't see the use of the compression. From owner-mpls@UU.NET Fri Jul 21 14:52: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 OAA00413 for ; Fri, 21 Jul 2000 14:52:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvj12642; Fri, 21 Jul 2000 18:52:32 GMT Received: by mail-control.mail.uu.net id QQiyvj13424 for mpls-outgoing; Fri, 21 Jul 2000 18:52:06 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQiyvj13386 for ; Fri, 21 Jul 2000 18:51: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 QQiyvj07943 for ; Fri, 21 Jul 2000 14:51:39 -0400 (EDT) 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 QQiyvj11470 for ; Fri, 21 Jul 2000 18:51:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA10550 for mpls@uu.net; Fri, 21 Jul 2000 14:51:38 -0400 (EDT) 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 QQiyvj13325 for ; Fri, 21 Jul 2000 18: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 QQiyvj07875 for ; Fri, 21 Jul 2000 14:51:16 -0400 (EDT) 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 QQiyvj10371 for ; Fri, 21 Jul 2000 18:50:46 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 LAA23103; Fri, 21 Jul 2000 11:50:42 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jul 2000 11:52:44 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406A4@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Lou Berger'" , Shahram Davari Cc: George Swallow , mpls@UU.NET Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) Date: Fri, 21 Jul 2000 11:52:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Lou, Let me explain my solution to your problem with an example. Assume we have an LSP that spans LSR1 (Diffserv LSR) and LSR2 (non-Diffserv LSR). Now assume that in the RSVP message we set COS=COS1 and no Diffserv object. Since the LSP is spanning a Diffserv LSR and a non-Diffserv LSR, the LER (Label Edge Router) must be a Diffserv and a non-Diffserv edge LSR. Now assume that the LER sets the EXP field of all packets to EXP=EXP1 (indicating a local PHB) in such a way that both EXP1 and COS1 indicate the same local behavior to the LSR1 and LSR2 respectively: EXP=EXP1 COS=COS1 O----------O----------O------ LER LSR1 LSR2 LSR1 will ignore the COS field and will behave according to pre-configured behavior of EXP1, and LSR2 will ignore the EXP field and behave according to COS1. Since we have designed the EXP1 and COS1 behaviors to be the same, then we will have a consistent behavior throughout the LSP. If the LER sets the EXP to a wrong value (i.e., a value that does not match COS1), then this is a configuration problem, which pretty much exist in all Diffserv networks. Does this make sense? Regards, -Shahram >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net] >Sent: Friday, July 21, 2000 12:59 PM >To: Shahram Davari >Cc: 'Lou Berger'; George Swallow; mpls@UU.NET >Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) > > >Shahram, > see below. > >At 09:31 AM 7/21/00 -0700, Shahram Davari wrote: >>Hi Lou, George >> >> >PS As mentioned back on 2/8, I believe one trivial solution is >> >to require >> >the use of the DiffServ Object/TLV for all E-LSPs, where use of >> >preconfigured EXP<-->PHB mappings is indicated by either (pick >> >one) no map >> >parameters or a single map parameter set to all zeros. >> >Another solution is >> >to use the one proposed in >> >draft-lefaucheur-diff-te-ext-00.txt, although it >> >does use a new object that could just be merged with the >> >DiffServ Object. >> >>Your solution is ONLY valid if a single LSR could be both a >Diffserv LSR and >>a non-Diffserv LSR. > >It works for both cases, i.e., for the cases where a DS LSR >can support >non-DS LSPs and when it cannot. In the latter case, a PathErr with an >appropriate code&value would need to be generated. > >>So it could use the presence of Diffserv object to >>decide what behavior it should have (Diffserv behavior or non-Diffserv >>behavior).I don't see any benefit in having a single LSR to be both a >>Diffserv LSR and a non-Diffserv LSR. If the purpose is to support both >>standardized PHBs and some local behavior that are not >standardized, you >>could always use the Diffserv local-PHBs. > >We covered this the last time around. Here's a relevant excerpt: > > >>Date: Wed, 09 Feb 2000 16:57:57 -0500 >>To: Shahram Davari >>From: Lou Berger >>Subject: RE: Announcing draft-ietf-mpls-diff-ext-03.txt >>Cc: "'Lou Berger'" , "'Jim Boyle'" >, >> mpls@UU.NET >>Sender: owner-mpls@UU.NET >>[...] > >LB: > > >>> > >>> > One (new) point, your implicit mode hijacks existing >>> > signaling mechanisms >>> > and gives them new meaning. (Now that I think of it, this is >>> > a large part >>> > of my objection to the current form of the draft.) For >>> > non-DS nodes, CoS >>> > behavior can be provided by signaling a CoS LSP and not using >>> > the EXP bits >>> > at all. If that same LSP hits a DS node with the current >>> > draft, it will be >>> > treated as an E-LSP and the matching traffic will receive the >>> > service that >>> > matches bits 000. > >SD: > >>>First of all you have the same situation in a non-MPLS and >Diffserv network. >>>Do you plan to add signaling to them too? > >LB: > >>No because all traffic is best-effort in a DS network. There >would be >>some work to resolve conflicts if you were trying to support >RSVP on the >>same links/data as DS. > >SD: > >>>Secondly it is a misconfiguration to use a non-DS node in a >Diffserv network >>>and it is very unusual to use a DS-node in a Diffserv >network that supports >>>non-Diffserv behavior too. So why don't we choose the >DS-behavior to be a >>>default behavior in a Diffserv network, and use another >object for signaling >>>those rare non-DS LSPs? > >LB: > >>So you're suggesting a new object/TLV that says "I'm not >diff-serv" rather >>than have the new feature say "I'm diff-serv"? I don't get >it. We're >>talking about few bytes of overhead that you've already >defined and are >>willing to incur for all L-LSPs and some E-LSPs. We're not >talking about >>any substantive change in processing or state. > >SD: > >>>Remember the only situation that you would use a configured >E-LSP is when >>>you are sure that all your nodes are configured and can >support the required >>>PHBs. > >LB: > >>this is not correct. With the current definition, as soon as you >>configure a node to be a DS node, all established LSPs are >E-LSPs or L-LSPs. >> >>Albeit a corner case for non-green field networks, I think you're >>requiring the configuration of all your nodes at the same >moment of time >>or just not caring about the traffic service levels during >reconfig. Do >>you view this as acceptable? >> >>Lou > >That's it. > >Lou > >>Regards, >>-Shahram > From owner-mpls@UU.NET Fri Jul 21 15:03: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 PAA10556 for ; Fri, 21 Jul 2000 15:03:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvk26274; Fri, 21 Jul 2000 19:03:04 GMT Received: by mail-control.mail.uu.net id QQiyvk20228 for mpls-outgoing; Fri, 21 Jul 2000 19:02: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 QQiyvk20131 for ; Fri, 21 Jul 2000 19:02:18 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyvj05398 for ; Fri, 21 Jul 2000 14:59:13 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyvj21041 for ; Fri, 21 Jul 2000 18:58:42 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id NAA02764; Fri, 21 Jul 2000 13:58:24 -0500 Message-Id: <4.3.2.7.2.20000721145447.00c93960@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 14:58:53 -0400 To: Shahram Davari From: Lou Berger Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) Cc: "'Lou Berger'" , Shahram Davari , George Swallow , mpls@UU.NET In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B406A4@nt-exchange-bby.p mc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Your example looks fine. Now consider the case where the ingress/LER doesn't support MPLS DS. It uses COS1, and sets the EXP bit to 000. The LSR1 will treat the packets with EXP0, probably DF, while LSR2 will provide COS1 service. So the introduction of a DS capable transit node can reduce the service seen by an existing non-DS edge. This is the problem. Lou At 11:52 AM 7/21/00 -0700, Shahram Davari wrote: >Lou, > >Let me explain my solution to your problem with an example. Assume we have >an LSP that spans LSR1 (Diffserv LSR) and LSR2 (non-Diffserv LSR). Now >assume that in the RSVP message we set COS=COS1 and no Diffserv object. >Since the LSP is spanning a Diffserv LSR and a non-Diffserv LSR, the LER >(Label Edge Router) must be a Diffserv and a non-Diffserv edge LSR. Now >assume that the LER sets the EXP field of all packets to EXP=EXP1 >(indicating a local PHB) in such a way that both EXP1 and COS1 indicate the >same local behavior to the LSR1 and LSR2 respectively: > > > EXP=EXP1 COS=COS1 > O----------O----------O------ > LER LSR1 LSR2 > > >LSR1 will ignore the COS field and will behave according to pre-configured >behavior of EXP1, and LSR2 will ignore the EXP field and behave according to >COS1. Since we have designed the EXP1 and COS1 behaviors to be the same, >then we will have a consistent behavior throughout the LSP. > >If the LER sets the EXP to a wrong value (i.e., a value that does not match >COS1), then this is a configuration problem, which pretty much exist in all >Diffserv networks. > >Does this make sense? > >Regards, >-Shahram > > >-----Original Message----- > >From: Lou Berger [mailto:lberger@labn.net] > >Sent: Friday, July 21, 2000 12:59 PM > >To: Shahram Davari > >Cc: 'Lou Berger'; George Swallow; mpls@UU.NET > >Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) > > > > > >Shahram, > > see below. > > > >At 09:31 AM 7/21/00 -0700, Shahram Davari wrote: > >>Hi Lou, George > >> > >> >PS As mentioned back on 2/8, I believe one trivial solution is > >> >to require > >> >the use of the DiffServ Object/TLV for all E-LSPs, where use of > >> >preconfigured EXP<-->PHB mappings is indicated by either (pick > >> >one) no map > >> >parameters or a single map parameter set to all zeros. > >> >Another solution is > >> >to use the one proposed in > >> >draft-lefaucheur-diff-te-ext-00.txt, although it > >> >does use a new object that could just be merged with the > >> >DiffServ Object. > >> > >>Your solution is ONLY valid if a single LSR could be both a > >Diffserv LSR and > >>a non-Diffserv LSR. > > > >It works for both cases, i.e., for the cases where a DS LSR > >can support > >non-DS LSPs and when it cannot. In the latter case, a PathErr with an > >appropriate code&value would need to be generated. > > > >>So it could use the presence of Diffserv object to > >>decide what behavior it should have (Diffserv behavior or non-Diffserv > >>behavior).I don't see any benefit in having a single LSR to be both a > >>Diffserv LSR and a non-Diffserv LSR. If the purpose is to support both > >>standardized PHBs and some local behavior that are not > >standardized, you > >>could always use the Diffserv local-PHBs. > > > >We covered this the last time around. Here's a relevant excerpt: > > > > > >>Date: Wed, 09 Feb 2000 16:57:57 -0500 > >>To: Shahram Davari > >>From: Lou Berger > >>Subject: RE: Announcing draft-ietf-mpls-diff-ext-03.txt > >>Cc: "'Lou Berger'" , "'Jim Boyle'" > >, > >> mpls@UU.NET > >>Sender: owner-mpls@UU.NET > >>[...] > > > >LB: > > > > > >>> > > >>> > One (new) point, your implicit mode hijacks existing > >>> > signaling mechanisms > >>> > and gives them new meaning. (Now that I think of it, this is > >>> > a large part > >>> > of my objection to the current form of the draft.) For > >>> > non-DS nodes, CoS > >>> > behavior can be provided by signaling a CoS LSP and not using > >>> > the EXP bits > >>> > at all. If that same LSP hits a DS node with the current > >>> > draft, it will be > >>> > treated as an E-LSP and the matching traffic will receive the > >>> > service that > >>> > matches bits 000. > > > >SD: > > > >>>First of all you have the same situation in a non-MPLS and > >Diffserv network. > >>>Do you plan to add signaling to them too? > > > >LB: > > > >>No because all traffic is best-effort in a DS network. There > >would be > >>some work to resolve conflicts if you were trying to support > >RSVP on the > >>same links/data as DS. > > > >SD: > > > >>>Secondly it is a misconfiguration to use a non-DS node in a > >Diffserv network > >>>and it is very unusual to use a DS-node in a Diffserv > >network that supports > >>>non-Diffserv behavior too. So why don't we choose the > >DS-behavior to be a > >>>default behavior in a Diffserv network, and use another > >object for signaling > >>>those rare non-DS LSPs? > > > >LB: > > > >>So you're suggesting a new object/TLV that says "I'm not > >diff-serv" rather > >>than have the new feature say "I'm diff-serv"? I don't get > >it. We're > >>talking about few bytes of overhead that you've already > >defined and are > >>willing to incur for all L-LSPs and some E-LSPs. We're not > >talking about > >>any substantive change in processing or state. > > > >SD: > > > >>>Remember the only situation that you would use a configured > >E-LSP is when > >>>you are sure that all your nodes are configured and can > >support the required > >>>PHBs. > > > >LB: > > > >>this is not correct. With the current definition, as soon as you > >>configure a node to be a DS node, all established LSPs are > >E-LSPs or L-LSPs. > >> > >>Albeit a corner case for non-green field networks, I think you're > >>requiring the configuration of all your nodes at the same > >moment of time > >>or just not caring about the traffic service levels during > >reconfig. Do > >>you view this as acceptable? > >> > >>Lou > > > >That's it. > > > >Lou > > > >>Regards, > >>-Shahram > > From owner-mpls@UU.NET Fri Jul 21 15:21: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 PAA00658 for ; Fri, 21 Jul 2000 15:21:06 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvl17302; Fri, 21 Jul 2000 19:20:57 GMT Received: by mail-control.mail.uu.net id QQiyvl26284 for mpls-outgoing; Fri, 21 Jul 2000 19:20: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 QQiyvl26274 for ; Fri, 21 Jul 2000 19:20: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 QQiyvl08099 for ; Fri, 21 Jul 2000 15:16:21 -0400 (EDT) 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 QQiyvl11485 for ; Fri, 21 Jul 2000 19:15:50 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA18222 for mpls@uu.net; Fri, 21 Jul 2000 15:15:50 -0400 (EDT) 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 QQiyvl26030 for ; Fri, 21 Jul 2000 19:15: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 QQiyvk07466 for ; Fri, 21 Jul 2000 15:11:26 -0400 (EDT) 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 QQiyvk06284 for ; Fri, 21 Jul 2000 19:11:25 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 MAA27545; Fri, 21 Jul 2000 12:11:22 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jul 2000 12:13:24 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406A5@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'Lou Berger'" , Shahram Davari Cc: Shahram Davari , George Swallow , mpls@UU.NET Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) Date: Fri, 21 Jul 2000 12:13:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Lou, What you are saying is that, you want an LSP to span both Diffserv and non-Diffserv LSRs, but you don't want to use Diffserv edge LSR. I don't think your assumption that the edge LSR of a Diffserv network being a non-Diffserv LSR is a valid assumption. Therefore I don't think anybody can argue about the fact that : If you have Diffserv nodes in the network, the edge routers must support Diffserv. Regards, -Shahram >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net] >Sent: Friday, July 21, 2000 2:59 PM >To: Shahram Davari >Cc: 'Lou Berger'; Shahram Davari; George Swallow; mpls@UU.NET >Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) > > >Your example looks fine. > >Now consider the case where the ingress/LER doesn't support >MPLS DS. It >uses COS1, and sets the EXP bit to 000. The LSR1 will treat >the packets >with EXP0, probably DF, while LSR2 will provide COS1 service. > >So the introduction of a DS capable transit node can reduce >the service >seen by an existing non-DS edge. This is the problem. > >Lou > > >At 11:52 AM 7/21/00 -0700, Shahram Davari wrote: >>Lou, >> >>Let me explain my solution to your problem with an example. >Assume we have >>an LSP that spans LSR1 (Diffserv LSR) and LSR2 (non-Diffserv LSR). Now >>assume that in the RSVP message we set COS=COS1 and no >Diffserv object. >>Since the LSP is spanning a Diffserv LSR and a non-Diffserv >LSR, the LER >>(Label Edge Router) must be a Diffserv and a non-Diffserv >edge LSR. Now >>assume that the LER sets the EXP field of all packets to EXP=EXP1 >>(indicating a local PHB) in such a way that both EXP1 and >COS1 indicate the >>same local behavior to the LSR1 and LSR2 respectively: >> >> >> EXP=EXP1 COS=COS1 >> O----------O----------O------ >> LER LSR1 LSR2 >> >> >>LSR1 will ignore the COS field and will behave according to >pre-configured >>behavior of EXP1, and LSR2 will ignore the EXP field and >behave according to >>COS1. Since we have designed the EXP1 and COS1 behaviors to >be the same, >>then we will have a consistent behavior throughout the LSP. >> >>If the LER sets the EXP to a wrong value (i.e., a value that >does not match >>COS1), then this is a configuration problem, which pretty >much exist in all >>Diffserv networks. >> >>Does this make sense? >> >>Regards, >>-Shahram >> >> >-----Original Message----- >> >From: Lou Berger [mailto:lberger@labn.net] >> >Sent: Friday, July 21, 2000 12:59 PM >> >To: Shahram Davari >> >Cc: 'Lou Berger'; George Swallow; mpls@UU.NET >> >Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) >> > >> > >> >Shahram, >> > see below. >> > >> >At 09:31 AM 7/21/00 -0700, Shahram Davari wrote: >> >>Hi Lou, George >> >> >> >> >PS As mentioned back on 2/8, I believe one trivial solution is >> >> >to require >> >> >the use of the DiffServ Object/TLV for all E-LSPs, where use of >> >> >preconfigured EXP<-->PHB mappings is indicated by either (pick >> >> >one) no map >> >> >parameters or a single map parameter set to all zeros. >> >> >Another solution is >> >> >to use the one proposed in >> >> >draft-lefaucheur-diff-te-ext-00.txt, although it >> >> >does use a new object that could just be merged with the >> >> >DiffServ Object. >> >> >> >>Your solution is ONLY valid if a single LSR could be both a >> >Diffserv LSR and >> >>a non-Diffserv LSR. >> > >> >It works for both cases, i.e., for the cases where a DS LSR >> >can support >> >non-DS LSPs and when it cannot. In the latter case, a >PathErr with an >> >appropriate code&value would need to be generated. >> > >> >>So it could use the presence of Diffserv object to >> >>decide what behavior it should have (Diffserv behavior or >non-Diffserv >> >>behavior).I don't see any benefit in having a single LSR >to be both a >> >>Diffserv LSR and a non-Diffserv LSR. If the purpose is to >support both >> >>standardized PHBs and some local behavior that are not >> >standardized, you >> >>could always use the Diffserv local-PHBs. >> > >> >We covered this the last time around. Here's a relevant excerpt: >> > >> > >> >>Date: Wed, 09 Feb 2000 16:57:57 -0500 >> >>To: Shahram Davari >> >>From: Lou Berger >> >>Subject: RE: Announcing draft-ietf-mpls-diff-ext-03.txt >> >>Cc: "'Lou Berger'" , "'Jim Boyle'" >> >, >> >> mpls@UU.NET >> >>Sender: owner-mpls@UU.NET >> >>[...] >> > >> >LB: >> > >> > >> >>> > >> >>> > One (new) point, your implicit mode hijacks existing >> >>> > signaling mechanisms >> >>> > and gives them new meaning. (Now that I think of it, this is >> >>> > a large part >> >>> > of my objection to the current form of the draft.) For >> >>> > non-DS nodes, CoS >> >>> > behavior can be provided by signaling a CoS LSP and not using >> >>> > the EXP bits >> >>> > at all. If that same LSP hits a DS node with the current >> >>> > draft, it will be >> >>> > treated as an E-LSP and the matching traffic will receive the >> >>> > service that >> >>> > matches bits 000. >> > >> >SD: >> > >> >>>First of all you have the same situation in a non-MPLS and >> >Diffserv network. >> >>>Do you plan to add signaling to them too? >> > >> >LB: >> > >> >>No because all traffic is best-effort in a DS network. There >> >would be >> >>some work to resolve conflicts if you were trying to support >> >RSVP on the >> >>same links/data as DS. >> > >> >SD: >> > >> >>>Secondly it is a misconfiguration to use a non-DS node in a >> >Diffserv network >> >>>and it is very unusual to use a DS-node in a Diffserv >> >network that supports >> >>>non-Diffserv behavior too. So why don't we choose the >> >DS-behavior to be a >> >>>default behavior in a Diffserv network, and use another >> >object for signaling >> >>>those rare non-DS LSPs? >> > >> >LB: >> > >> >>So you're suggesting a new object/TLV that says "I'm not >> >diff-serv" rather >> >>than have the new feature say "I'm diff-serv"? I don't get >> >it. We're >> >>talking about few bytes of overhead that you've already >> >defined and are >> >>willing to incur for all L-LSPs and some E-LSPs. We're not >> >talking about >> >>any substantive change in processing or state. >> > >> >SD: >> > >> >>>Remember the only situation that you would use a configured >> >E-LSP is when >> >>>you are sure that all your nodes are configured and can >> >support the required >> >>>PHBs. >> > >> >LB: >> > >> >>this is not correct. With the current definition, as soon as you >> >>configure a node to be a DS node, all established LSPs are >> >E-LSPs or L-LSPs. >> >> >> >>Albeit a corner case for non-green field networks, I think you're >> >>requiring the configuration of all your nodes at the same >> >moment of time >> >>or just not caring about the traffic service levels during >> >reconfig. Do >> >>you view this as acceptable? >> >> >> >>Lou >> > >> >That's it. >> > >> >Lou >> > >> >>Regards, >> >>-Shahram >> > > From owner-mpls@UU.NET Fri Jul 21 15:21: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 PAA00661 for ; Fri, 21 Jul 2000 15:21:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvl21404; Fri, 21 Jul 2000 19:20:57 GMT Received: by mail-control.mail.uu.net id QQiyvl26279 for mpls-outgoing; Fri, 21 Jul 2000 19:20:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQiyvl26270 for ; Fri, 21 Jul 2000 19:20: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 QQiyvl08371 for ; Fri, 21 Jul 2000 15:18:11 -0400 (EDT) Received: from ennovatenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ennovatenetworks.com [208.227.99.254]) id QQiyvl19112 for ; Fri, 21 Jul 2000 19:18:11 GMT Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id PAA02238; Fri, 21 Jul 2000 15:17:34 -0400 (EDT) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'Bora Akyol'" , Cc: "'Lou Berger'" , "'Eric Gray'" , "'MPLS Mailing List (E-mail)'" , "'George Swallow'" Subject: RE: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Date: Fri, 21 Jul 2000 15:17:31 -0400 Message-ID: <007a01bff348$520027c0$d001010a@tst.ennovatenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <3978961F.E4FC032B@pluris.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora Akyol writes: > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Bora > Akyol > I for one think that the one hop strategy is unacceptable > especially if this > continues "one hopping" through to the core routers. If the access box > terminates the one hop compression and then sends normal MPLS > packets then this > is OK; Based on my experience of implementing and using IP header compression over slow (19.2 Kbps and 14.4 Kbps) wireless links, implementing header compression schemes even on a single hop are a big pain as header compression requires synchronized session states at both ends of a link. If the sessions are short, or too many sessions are multiplexed over multiple slow links controlled by a single box, processing overheads of header compressions are non-trivial. In these situations, operators and the devices may find better throughput by disabling header compression all together at both ends. In short, contrary to the popular myth, header compression is not always useful over slow links. Cheers, --brijesh Ennovate Networks Inc. >otherwise, this is a major change in the architecture > and should be > avoided at all costs. > > From owner-mpls@UU.NET Fri Jul 21 15:23: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 PAA02673 for ; Fri, 21 Jul 2000 15:23:02 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvl23523; Fri, 21 Jul 2000 19:22:57 GMT Received: by mail-control.mail.uu.net id QQiyvl26407 for mpls-outgoing; Fri, 21 Jul 2000 19:22: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 QQiyvl26396 for ; Fri, 21 Jul 2000 19:22: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 QQiyvl12999 for ; Fri, 21 Jul 2000 15:22:02 -0400 (EDT) Received: from mason2.gmu.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mason2.gmu.edu [129.174.1.11]) id QQiyvl22583 for ; Fri, 21 Jul 2000 19:22:02 GMT Received: from localhost (rpapneja@localhost) by mason2.gmu.edu (8.8.8/8.8.8) with ESMTP id PAA02298; Fri, 21 Jul 2000 15:22:01 -0400 (EDT) Date: Fri, 21 Jul 2000 15:22:00 -0400 (EDT) From: Rajiv Papneja X-Sender: rpapneja@mason2.gmu.edu To: Ho Ee Lock cc: mpls@UU.NET Subject: Re: Questions regarding MPLS In-Reply-To: <20000721014454.4202.qmail@web122.yahoomail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id PAA02673 Hi Lock, You can look for some papers on MPLS in the IEEE Communication Magazine, Dec. 1999 issue which had MPLS as special feature topic. There are two more references related to Traffic Partitioning in MPLS which might be of interest to you. These are as follows 1) E. Dinan, D. Awduche and B. Jabbari "Optimal traffic partitioning in MPLS networks," IFIP Networking 2000, Paris, France, May 2000. 2) E. Dinan, D. Awduche and B. Jabbari "Analytical framework for dynamic partitioning in MPLS networks," Proceedings of the IEEE International Conference on Communications, ICC 2000, New Orleans, LA, June 18-22, 2000. I hope this may help you. Take care Rajiv Papneja On Thu, 20 Jul 2000, Ho Ee Lock wrote: > I am interested in studying some related works > in MPLS. However, there are some questions I am in > doubt. > > Firstly, I wonder whether there are papars out there > describing the performance of IP using MPLS switching > technologies. I wanted to study MPLS in that line, but > I found no references to it. I hope someone can kindly > refer me to some useful resource(eg. papers, journals) > concerning this matter (if there are any of them, > currently). > > Also, does anybody know about some simulation software > that is used to gauge the performance of MPLS > available in the Internet? > > I am looking forward to hearing some responses. I > believe it would help me a lot in my research. > > Thank you. > > Regards, > Ho Ee Lock > eelock@yahoo.com > > > > > __________________________________________________ > Do You Yahoo!? > Get Yahoo! Mail – Free email you can access from anywhere! > http://mail.yahoo.com/ > > ******************************** Rajiv Papneja (GRA) Advanced Internet Laboratory George Mason University, G10, Johnson Center, Fairfax, VA 22030-4444 Tel: 703.993.4700 email: rpapneja@osf1.gmu.edu ******************************** From owner-mpls@UU.NET Fri Jul 21 15:25: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 PAA04547 for ; Fri, 21 Jul 2000 15:25:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvl25712; Fri, 21 Jul 2000 19:25:00 GMT Received: by mail-control.mail.uu.net id QQiyvl26566 for mpls-outgoing; Fri, 21 Jul 2000 19: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 QQiyvl26552 for ; Fri, 21 Jul 2000 19:24:04 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQiyvl13333 for ; Fri, 21 Jul 2000 15:23:55 -0400 (EDT) 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 QQiyvl20789 for ; Fri, 21 Jul 2000 19:23:38 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA19805 for mpls@uu.net; Fri, 21 Jul 2000 15:23:36 -0400 (EDT) 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 QQiyvl26424 for ; Fri, 21 Jul 2000 19:23: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 QQiyvl13087 for ; Fri, 21 Jul 2000 15:22:40 -0400 (EDT) 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 QQiyvl23185 for ; Fri, 21 Jul 2000 19:22:39 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 MAA29977 for ; Fri, 21 Jul 2000 12:22:38 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jul 2000 12:24:41 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406A7@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'mpls@UU.net'" Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) Date: Fri, 21 Jul 2000 12:24:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi all, Just as a classifier, what Lou Berger is referring to as "non-Diffserv LSR" is an LSR that does support differentiated queuing and scheduling (as indicated by some COS field) just it doesn't interpret the MPLS header's EXP bits in the current MPLS-diffserv manner. He is NOT referring to an LSR that is incapable of providing differentiated queuing and scheduling to packets . Regards, Shahram Shahram Davari Systems Engineer Product Research PMC-Sierra, Inc. (Ottawa) 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3, Canada Phone: +1 (613) 271-4018 Fax : +1 (613) 271-7007 From owner-mpls@UU.NET Fri Jul 21 15:36: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 PAA15154 for ; Fri, 21 Jul 2000 15:36:48 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvm06171; Fri, 21 Jul 2000 19:36:42 GMT Received: by mail-control.mail.uu.net id QQiyvm27458 for mpls-outgoing; Fri, 21 Jul 2000 19:36: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 QQiyvm27437 for ; Fri, 21 Jul 2000 19:36: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 QQiyvm10965 for ; Fri, 21 Jul 2000 15:34:19 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQiyvm03543 for ; Fri, 21 Jul 2000 19:34:19 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id OAA14301; Fri, 21 Jul 2000 14:34:07 -0500 Message-Id: <4.3.2.7.2.20000721152734.00ccd970@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 15:34:36 -0400 To: Shahram Davari From: Lou Berger Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) Cc: "'Lou Berger'" , Shahram Davari , Shahram Davari , George Swallow , mpls@UU.NET In-Reply-To: <336ECDAFDF7DD311B9E30090277AEE4101B406A5@nt-exchange-bby.p mc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Shahram, See below. At 12:13 PM 7/21/00 -0700, Shahram Davari wrote: >Lou, > >What you are saying is that, you want an LSP to span both Diffserv and >non-Diffserv LSRs, but you don't want to use Diffserv edge LSR. More precisely the edge LSR doesn't do MPLS DS, it may do IP DS. >I don't think your assumption that the edge LSR of a Diffserv network being >a non-Diffserv LSR is a valid assumption. Right, we disagree. >Therefore I don't think anybody >can argue about the fact that : > >If you have Diffserv nodes in the network, the edge routers must support >Diffserv. Again, I think the issues here are mainly related to transition. I think the following from draft-lefaucheur-diff-te-reqts-00.txt captures the issue. We identify the following backward compatibility requirements for the RSVP/CR-LDP extensions: - operations in heterogeneous environments need to be supported for smooth migration, where some LSRs are Diff-Serv-TE-capable (as defined in this specification) while some other LSRs are not Diff-Serv-TE-capable (i.e. support (aggregate) TE only) and - in heterogeneous environments, the solution needs to ensure that a non-Diff-Serv-TE-capable LSR would reject establishment of a Class-Type N (N=1,2,3) LSP. Note that the latter issue isn't addressed by your example but is in my proposal. Lou >Regards, >-Shahram > > > >-----Original Message----- > >From: Lou Berger [mailto:lberger@labn.net] > >Sent: Friday, July 21, 2000 2:59 PM > >To: Shahram Davari > >Cc: 'Lou Berger'; Shahram Davari; George Swallow; mpls@UU.NET > >Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) > > > > > >Your example looks fine. > > > >Now consider the case where the ingress/LER doesn't support > >MPLS DS. It > >uses COS1, and sets the EXP bit to 000. The LSR1 will treat > >the packets > >with EXP0, probably DF, while LSR2 will provide COS1 service. > > > >So the introduction of a DS capable transit node can reduce > >the service > >seen by an existing non-DS edge. This is the problem. > > > >Lou > > > > > >At 11:52 AM 7/21/00 -0700, Shahram Davari wrote: > >>Lou, > >> > >>Let me explain my solution to your problem with an example. > >Assume we have > >>an LSP that spans LSR1 (Diffserv LSR) and LSR2 (non-Diffserv LSR). Now > >>assume that in the RSVP message we set COS=COS1 and no > >Diffserv object. > >>Since the LSP is spanning a Diffserv LSR and a non-Diffserv > >LSR, the LER > >>(Label Edge Router) must be a Diffserv and a non-Diffserv > >edge LSR. Now > >>assume that the LER sets the EXP field of all packets to EXP=EXP1 > >>(indicating a local PHB) in such a way that both EXP1 and > >COS1 indicate the > >>same local behavior to the LSR1 and LSR2 respectively: > >> > >> > >> EXP=EXP1 COS=COS1 > >> O----------O----------O------ > >> LER LSR1 LSR2 > >> > >> > >>LSR1 will ignore the COS field and will behave according to > >pre-configured > >>behavior of EXP1, and LSR2 will ignore the EXP field and > >behave according to > >>COS1. Since we have designed the EXP1 and COS1 behaviors to > >be the same, > >>then we will have a consistent behavior throughout the LSP. > >> > >>If the LER sets the EXP to a wrong value (i.e., a value that > >does not match > >>COS1), then this is a configuration problem, which pretty > >much exist in all > >>Diffserv networks. > >> > >>Does this make sense? > >> > >>Regards, > >>-Shahram > >> > >> >-----Original Message----- > >> >From: Lou Berger [mailto:lberger@labn.net] > >> >Sent: Friday, July 21, 2000 12:59 PM > >> >To: Shahram Davari > >> >Cc: 'Lou Berger'; George Swallow; mpls@UU.NET > >> >Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) > >> > > >> > > >> >Shahram, > >> > see below. > >> > > >> >At 09:31 AM 7/21/00 -0700, Shahram Davari wrote: > >> >>Hi Lou, George > >> >> > >> >> >PS As mentioned back on 2/8, I believe one trivial solution is > >> >> >to require > >> >> >the use of the DiffServ Object/TLV for all E-LSPs, where use of > >> >> >preconfigured EXP<-->PHB mappings is indicated by either (pick > >> >> >one) no map > >> >> >parameters or a single map parameter set to all zeros. > >> >> >Another solution is > >> >> >to use the one proposed in > >> >> >draft-lefaucheur-diff-te-ext-00.txt, although it > >> >> >does use a new object that could just be merged with the > >> >> >DiffServ Object. > >> >> > >> >>Your solution is ONLY valid if a single LSR could be both a > >> >Diffserv LSR and > >> >>a non-Diffserv LSR. > >> > > >> >It works for both cases, i.e., for the cases where a DS LSR > >> >can support > >> >non-DS LSPs and when it cannot. In the latter case, a > >PathErr with an > >> >appropriate code&value would need to be generated. > >> > > >> >>So it could use the presence of Diffserv object to > >> >>decide what behavior it should have (Diffserv behavior or > >non-Diffserv > >> >>behavior).I don't see any benefit in having a single LSR > >to be both a > >> >>Diffserv LSR and a non-Diffserv LSR. If the purpose is to > >support both > >> >>standardized PHBs and some local behavior that are not > >> >standardized, you > >> >>could always use the Diffserv local-PHBs. > >> > > >> >We covered this the last time around. Here's a relevant excerpt: > >> > > >> > > >> >>Date: Wed, 09 Feb 2000 16:57:57 -0500 > >> >>To: Shahram Davari > >> >>From: Lou Berger > >> >>Subject: RE: Announcing draft-ietf-mpls-diff-ext-03.txt > >> >>Cc: "'Lou Berger'" , "'Jim Boyle'" > >> >, > >> >> mpls@UU.NET > >> >>Sender: owner-mpls@UU.NET > >> >>[...] > >> > > >> >LB: > >> > > >> > > >> >>> > > >> >>> > One (new) point, your implicit mode hijacks existing > >> >>> > signaling mechanisms > >> >>> > and gives them new meaning. (Now that I think of it, this is > >> >>> > a large part > >> >>> > of my objection to the current form of the draft.) For > >> >>> > non-DS nodes, CoS > >> >>> > behavior can be provided by signaling a CoS LSP and not using > >> >>> > the EXP bits > >> >>> > at all. If that same LSP hits a DS node with the current > >> >>> > draft, it will be > >> >>> > treated as an E-LSP and the matching traffic will receive the > >> >>> > service that > >> >>> > matches bits 000. > >> > > >> >SD: > >> > > >> >>>First of all you have the same situation in a non-MPLS and > >> >Diffserv network. > >> >>>Do you plan to add signaling to them too? > >> > > >> >LB: > >> > > >> >>No because all traffic is best-effort in a DS network. There > >> >would be > >> >>some work to resolve conflicts if you were trying to support > >> >RSVP on the > >> >>same links/data as DS. > >> > > >> >SD: > >> > > >> >>>Secondly it is a misconfiguration to use a non-DS node in a > >> >Diffserv network > >> >>>and it is very unusual to use a DS-node in a Diffserv > >> >network that supports > >> >>>non-Diffserv behavior too. So why don't we choose the > >> >DS-behavior to be a > >> >>>default behavior in a Diffserv network, and use another > >> >object for signaling > >> >>>those rare non-DS LSPs? > >> > > >> >LB: > >> > > >> >>So you're suggesting a new object/TLV that says "I'm not > >> >diff-serv" rather > >> >>than have the new feature say "I'm diff-serv"? I don't get > >> >it. We're > >> >>talking about few bytes of overhead that you've already > >> >defined and are > >> >>willing to incur for all L-LSPs and some E-LSPs. We're not > >> >talking about > >> >>any substantive change in processing or state. > >> > > >> >SD: > >> > > >> >>>Remember the only situation that you would use a configured > >> >E-LSP is when > >> >>>you are sure that all your nodes are configured and can > >> >support the required > >> >>>PHBs. > >> > > >> >LB: > >> > > >> >>this is not correct. With the current definition, as soon as you > >> >>configure a node to be a DS node, all established LSPs are > >> >E-LSPs or L-LSPs. > >> >> > >> >>Albeit a corner case for non-green field networks, I think you're > >> >>requiring the configuration of all your nodes at the same > >> >moment of time > >> >>or just not caring about the traffic service levels during > >> >reconfig. Do > >> >>you view this as acceptable? > >> >> > >> >>Lou > >> > > >> >That's it. > >> > > >> >Lou > >> > > >> >>Regards, > >> >>-Shahram > >> > > > From owner-mpls@UU.NET Fri Jul 21 16:07: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 QAA15079 for ; Fri, 21 Jul 2000 16:07:31 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvo29515; Fri, 21 Jul 2000 20:07:25 GMT Received: by mail-control.mail.uu.net id QQiyvo10494 for mpls-outgoing; Fri, 21 Jul 2000 20:06: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 QQiyvo10451 for ; Fri, 21 Jul 2000 20:06: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 QQiyvo15129 for ; Fri, 21 Jul 2000 16:06:20 -0400 (EDT) Received: from mailrelay.laurelnetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laurelnetworks.com [206.67.234.84]) id QQiyvo28283 for ; Fri, 21 Jul 2000 20:06:04 GMT Received: from ganeshpc (ganesh-pc.laurelnetworks.com [192.168.0.30]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with SMTP id QAA12507; Fri, 21 Jul 2000 16:06:03 -0400 From: "Ganesh Murugesan" To: "Kireeti Kompella" , Cc: "Ganesh Murugesan" Subject: RE: New Internet Draft: TE over Unnumbered Links Date: Fri, 21 Jul 2000 16:01:34 -0400 Message-ID: <007401bff34e$7868dc80$8ac6fea9@laurelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <200007210912.CAA14653@kummer.juniper.net> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, I had a few questions/comments on the TE over Unnumbered Links draft 1) At the ingress, when a node uses the unnumbered link for ERO computation, how does it know about the tail-end of the link. It seems the local address and a local index passed in OSPF/ISIS would be insufficient in path computation. Don't we need the router Id of the remote end of the link, in addition to some sort of index for the outgoing interface (like the SNMP IFIndex suggested) at the head-end of the link. Your document says in section 6 "The next node in the path is the node at the other end of the interface" At the ingress of the LSP, how would one compute the next node with the available igp information. 2) Shouldn't the length field value be 2 instead of 4 (2 octets). 3) And what would the RSVP HOP object look like on the RESV/PATH message sent on the unnumbered link? thanks ganesh From owner-mpls@UU.NET Fri Jul 21 17:25: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 RAA06835 for ; Fri, 21 Jul 2000 17:25:04 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyvt10251; Fri, 21 Jul 2000 21:24:55 GMT Received: by mail-control.mail.uu.net id QQiyvt27256 for mpls-outgoing; Fri, 21 Jul 2000 21:24: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 QQiyvt27251 for ; Fri, 21 Jul 2000 21:24:28 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiyvt01936 for ; Fri, 21 Jul 2000 17:24:05 -0400 (EDT) Received: from lux.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged)) id QQiyvt09102 for ; Fri, 21 Jul 2000 21:23:50 GMT Received: by LUX with Internet Mail Service (5.5.2448.0) id ; Fri, 21 Jul 2000 14:23:46 -0700 Message-ID: <51DA0AB3D747D311832F005004827CC02CE884@LUX> From: Jonathan Lang To: "'mpls@UU.net'" Subject: FW: I-D ACTION:draft-lang-mpls-lmp-01.txt Date: Fri, 21 Jul 2000 14:23:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFF359.F445E626" 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_01BFF359.F445E626 Content-Type: text/plain; charset="iso-8859-1" Hello, FYI. The next version of LMP is available from the on-line Internet-Drafts directories. -Jonathan Calient Networks -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, July 20, 2000 3:45 AM Subject: I-D ACTION:draft-lang-mpls-lmp-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Link Management Protocol (LMP) Author(s) : J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter, L. Berger, D. Saha, D. Basak, H. Sandick Filename : draft-lang-mpls-lmp-01.txt Pages : 33 Date : 19-Jul-00 Future networks will consist of photonic switches, optical crossconnects, and routers that may be configured with bundled links consisting of a number of user component links and an associated control channel. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and will be used for both link provisioning and fault isolation. A unique feature of LMP is that it is able to isolate faults in both opaque and transparent networks, independent of the encoding scheme used for the component links. LMP will be used to maintain control channel connectivity, verify component link connectivity, and isolate link, fiber, or channel failures within the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lang-mpls-lmp-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lang-mpls-lmp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-lang-mpls-lmp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01BFF359.F445E626 Content-Type: message/rfc822 To: Subject: Date: Fri, 21 Jul 2000 14:23:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BFF359.F445E626" ------_=_NextPart_002_01BFF359.F445E626 Content-Type: text/plain ------_=_NextPart_002_01BFF359.F445E626 Content-Type: application/octet-stream; name="ATT13953.txt" Content-Disposition: attachment; filename="ATT13953.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000719141150.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lang-mpls-lmp-01.txt ------_=_NextPart_002_01BFF359.F445E626 Content-Type: message/external-body; site="internet-drafts"; dir="draft-lang-mpls-lmp-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01BFF359.F445E626-- ------_=_NextPart_000_01BFF359.F445E626-- From owner-mpls@UU.NET Fri Jul 21 18:16: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 SAA26446 for ; Fri, 21 Jul 2000 18:16:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiyul07453; Fri, 21 Jul 2000 12:54:21 GMT Received: by mail-control.mail.uu.net id QQiyul04362 for mpls-outgoing; Fri, 21 Jul 2000 12:53: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 QQiyul04357 for ; Fri, 21 Jul 2000 12:53: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 QQiyul07941 for ; Fri, 21 Jul 2000 08:53:27 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQiyul03051 for ; Fri, 21 Jul 2000 12:52:57 GMT Received: from avici.com (swdev23.avici.com [10.1.2.229]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id IAA04314; Fri, 21 Jul 2000 08:52:52 -0400 (EDT) Message-Id: <200007211252.IAA04314@mailhost.avici.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Markus Jork To: Kireeti Kompella Cc: mpls@UU.NET Subject: Re: New Internet Draft: TE over Unnumbered Links In-reply-to: Your message of "Fri, 21 Jul 2000 02:12:04 PDT." <200007210912.CAA14653@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Jul 2000 08:52:50 -0400 Sender: owner-mpls@UU.NET Precedence: bulk Kireeti, you have picked the value 3 for the new "Unnumbered Interface ID" ERO subobject type. Can you please make that some other value. draft-ietf-mpls-rsvp-lsp-tunnel-06.txt has just assigned subobject type 3 to the "Label" subobject. That is only used in RROs but we should maintain the uniqueness of subtypes across EROs and RROs. Speaking of RROs, shouldn't the new subobject not also be used in there? Markus From owner-mpls@UU.NET Fri Jul 21 21:42: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 VAA04430 for ; Fri, 21 Jul 2000 21:42:30 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiywk28528; Sat, 22 Jul 2000 01:42:24 GMT Received: by mail-control.mail.uu.net id QQiywk28196 for mpls-outgoing; Sat, 22 Jul 2000 01:42: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 QQiywk28189 for ; Sat, 22 Jul 2000 01:41: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 QQiywk22265 for ; Fri, 21 Jul 2000 21:41:33 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQiywk07027 for ; Sat, 22 Jul 2000 01:41:18 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <36QHDRH5>; Fri, 21 Jul 2000 18:48:24 -0700 Message-ID: <4D3F9F2BEC58D4118FCE009027B0A662136060@ICARIAN> From: Eric Gray To: "'Lou Berger'" Cc: "MPLS Mailing List (E-mail)" Subject: RE: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Date: Fri, 21 Jul 2000 18:48:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Lou, Sorry it took me so long to get back to you. Please see below. > [...] > > > > I do not think the statement - > > > > "Since the header following the link layer header > > is no longer IP, the existing compression techniques > > will not operate" > > > >- which appears in the abstract of the ID entitled > >"MPLS/IP Header Compression" has been given enough > >thought. > > I don't see how you can argue with the statement. Current IP header > compression [RFC2507, 2508, 2509] relies on the IP header immediately > following the PPP header. That's the way it's specified. > What's the argument. Semantics. If you are talking about a single link compression, then you are already assuming you know for certain that the header following the bottom of stack label is an IP header - like this ----------- ------------ ----------- ------------- | L2 Header | MPLS Stack | IP Header | Packet Data | ----------- ------------ ----------- ------------- So, you know you can cut it like this ----------- | ------------ | ----------- | ------------- | L2 Header | | | MPLS Stack | | | IP Header | | | Packet Data | ----------- | ------------ | ----------- | ------------- Then you can apply the same compression techniques to the IP header and change the discriminator value in the L2 Header to get ------------ | ------------ | ------ | ------------- | L2 Header' | | | MPLS Stack | | | IPH' | | | Packet Data | ------------ | ------------ | ------ | ------------- where L2 Header-prime includes a discriminator for compressed IP header in MPLS and IPH-prime is the compressed IP header. Glomming it back together gets you this ------------ ------------ ------ ------------- | L2 Header' | MPLS Stack | IPH' | Packet Data | ------------ ------------ ------ ------------- Certainly the existing compression technique works. > > > This statement points out that this draft may > >be setting a precedent for how MPLS works when the > >link layer needs to indicate that the data frame is > >not IP (because it is MPLS) and the data encapsulated > >is not standard IP (because - in this case - it is > >compressed IP header). > > I can't figure out what "precedent" you are referring to. > That's okay. > > The traffic is standard IP not compressed IP. Yes. And your point is? Surely you are NOT going to give me a hard time for omitting a word... > > [...] > > > Also, it is possible to choose an approach that > > makes this statement invalid. > > Again, the earlier statement is one of fact not opinion. I think I have shown that this "fact" is not true. I have described an approach that shows that the existing compression technique will operate. You have to do a tiny bit more work, but you have to do that much in your scheme as well. > > [...] > > > While the draft states that the alternative of > > using IP header compression - as is - over MPLS > > was considered, I think this option was too > > quickly dismissed. > > A minor note, a replacement for rfc2509 would need > to be written to enable this. Actually, one of your drafts could - with very minor modification - perform this 'replacement' task. It could also serve to describe the simplistic approach to using already defined IP header compression over uncompressed MPLS shim header. Or, it could be merged with the -simple draft. > > > One of the reasons it was dismissed was that > >MPLS headers do not carry packet type codes. In > >making this decision in design of MPLS, we setup a > >general requirement to define new type codes for > >applicable link layers WHEN IT IS IMPORTANT FOR AN > >INTERMEDIATE LSR TO KNOW THE PROTOCOL OF THE DATA > >PACKET ENCAPSULATED BY MPLS. Hence, if we determine > >that there is a need for intermediate LSRs to know > >that the MPLS encapsulated packet uses IP header > >compression, then we might be justified in defining > >new link layer discriminators (packet type codes) > >for such packets when transported over MPLS. > > I don't think you mean intermediate LSR here, next hop or > downstream is accurate. (remember such compression is > hop-by-hop.) I'm thinking in generalities. Suppose a 'low speed' link of the future is an LSP. Where do you go with this approach then? Answer, you probably don't. I like to think it's a good idea to think "no future, no present" when it comes to developing standards. > > The general comment is still valid, while a bit awkward, > we could use link layer types to indicated they type of > data being carried within the MPLS stack. As the document > states, this issue wasn't the critical one. From the same > paragraph in the document: > > [...] The second and more important reason for not > adapting compression to operate over MPLS was simply > to gain extra efficiency by enabling the compression > of the MPLS label stack. > > The delta here is from (2 or 4 bytes + 4bytes/mpls header) > versus 2 or 4 bytes. If you assume that there is one MPLS label in the shim header, then the difference is simply 4 bytes. The actual size of the compressed IP header is not 2 or 4 bytes, but (according to RFC 2507) actually 4-7 bytes. I assume that all the same extra values have to be carried when the MPLS header and the IP header are compressed together (although I might have to add a nibble, at least, for the EXT field), so the delta should be more like 8-15 bytes verses 4-8 bytes. This delta is not so stark as the 2-4 verses 6-8 - at least when expressed as a percentage. If you assume more than one MPLS label, then the delta becomes more pronounced. But how likely is this? > > [...] > > > A second reason for dismissing other approaches > >was that additional compression efficiency could be > >obtained by compressing the MPLS shim header as well. > >I do not see that the potential for compressing one > >32 bit word justifies the proposal. Further, I doubt > >the existence of an application for multiple stacked > >labels being transported across a low-speed link - > >thus it does not seem likely that the MPLS shim header > >will be much larger than 32 bits. > > I don't everyone would agree with this statement. But, apparently, the question does come up. :-) > > [...] > > Thank you, > Lou > > [...] Have a nice weekend! -- From owner-mpls@UU.NET Sat Jul 22 21:18: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 VAA01774 for ; Sat, 22 Jul 2000 21:18:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizab21953; Sun, 23 Jul 2000 01:18:34 GMT Received: by mail-control.mail.uu.net id QQizab10166 for mpls-outgoing; Sun, 23 Jul 2000 01:18:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQizab10155 for ; Sun, 23 Jul 2000 01:17: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 QQizab18806 for ; Sat, 22 Jul 2000 21:17:47 -0400 (EDT) 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 QQizab21013 for ; Sun, 23 Jul 2000 01:17:47 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA13033 for mpls@uu.net; Sat, 22 Jul 2000 21:17:46 -0400 (EDT) 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 QQizab10127 for ; Sun, 23 Jul 2000 01:17: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 QQizab11156 for ; Sat, 22 Jul 2000 21:17:00 -0400 (EDT) Received: from ce-nfs-1.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQizab12768 for ; Sun, 23 Jul 2000 01:16:59 GMT Received: from sj-dial-1-209.cisco.com (sj-dial-1-209.cisco.com [171.68.179.210]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA06622 for ; Sat, 22 Jul 2000 18:16:57 -0700 (PDT) Date: Sat, 22 Jul 2000 16:15:52 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Alex Zinin Organization: Cisco Systems X-Priority: 3 (Normal) Message-ID: <1677.000722@cisco.com> To: "'mpls@UU.net'" Subject: Flooding optimization ID Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Speaking about OXC-based networks, link bundling, etc., the draft below may be interesting. I was submitted to the directories, but hasn't shown up so far. http://www.employees.org/~azinin/draft-ietf-zinin-flood-opt-00.txt Authors: Alex Zinin, Mike Shand. Abstract: The flooding algorithm is one of the most important parts of any link state routing protocol. It ensures that all routers within a link state domain converge on the same topological information within a finite period of time. To ensure reliability, typical implementations of the flooding algorithm send new information via all interfaces other than the one the new piece of information was received on. This redundancy is necessary to guarantee that flooding is performed reliably, but implies considerable overhead of utilized bandwidth and CPU time if neighboring routers are connected with more than one link. This document describes a method that reduces this overhead. -- Alex Zinin From owner-mpls@UU.NET Sun Jul 23 08:59: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 IAA19579 for ; Sun, 23 Jul 2000 08:59:44 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizbv27854; Sun, 23 Jul 2000 12:59:33 GMT Received: by mail-control.mail.uu.net id QQizbv19584 for mpls-outgoing; Sun, 23 Jul 2000 12:59: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 QQizbv19579 for ; Sun, 23 Jul 2000 12:59: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 QQizbv17011 for ; Sun, 23 Jul 2000 08:58:51 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQizbv14504 for ; Sun, 23 Jul 2000 12:58:50 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id HAA06064; Sun, 23 Jul 2000 07:58:46 -0500 Message-Id: <4.3.2.7.2.20000723080511.00b80de0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 23 Jul 2000 08:58:46 -0400 To: Eric Gray From: Lou Berger Subject: RE: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Cc: "'Lou Berger'" , "MPLS Mailing List (E-mail)" In-Reply-To: <4D3F9F2BEC58D4118FCE009027B0A662136060@ICARIAN> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Eric, I'm not sure where we are right now in the discussion. One issue is consensus: I think we have or are close to having general consensus, at least on the list, that "one hop" (using Eric R's terminology) compression has it's place, albeit a very narrow one. Another issue is specific approach: In the "one-hop" case maximizing efficiency is paramount so the inclusion of one or more MPLS in the compressed header is appropriate. I'll also responded to your specific points below, although I'm less sure there's general interest in the details. Lou At 06:48 PM 7/21/00 -0700, Eric Gray wrote: >Lou, > > Sorry it took me so long to get back to you. >Please see below. > > > [...] > > > > > > I do not think the statement - > > > > > > "Since the header following the link layer header > > > is no longer IP, the existing compression techniques > > > will not operate" > > > > > >- which appears in the abstract of the ID entitled > > >"MPLS/IP Header Compression" has been given enough > > >thought. > > > > I don't see how you can argue with the statement. Current IP header > > compression [RFC2507, 2508, 2509] relies on the IP header immediately > > following the PPP header. That's the way it's specified. > > What's the argument. > >Semantics. I disagree. There current RFCs just don't work when MPLS is used, they only cover the case where the IP header follows the link layer (PPP in the RFC2209 case). There is no argument. Yes, there are different ways to adapt the specs to work when there is an MPLS label stack present. As you pointed out in an earlier mail, we even mentioned this in the draft. > If you are talking about a single link >compression, then you are already assuming you know >for certain that the header following the bottom of >stack label is an IP header - like this > > ----------- ------------ ----------- ------------- > | L2 Header | MPLS Stack | IP Header | Packet Data | > ----------- ------------ ----------- ------------- > >So, you know you can cut it like this > > ----------- | ------------ | ----------- | ------------- > | L2 Header | | | MPLS Stack | | | IP Header | | | Packet Data | > ----------- | ------------ | ----------- | ------------- > >Then you can apply the same compression techniques to >the IP header and change the discriminator value in >the L2 Header to get > > ------------ | ------------ | ------ | ------------- > | L2 Header' | | | MPLS Stack | | | IPH' | | | Packet Data | > ------------ | ------------ | ------ | ------------- > >where L2 Header-prime includes a discriminator for >compressed IP header in MPLS and IPH-prime is the >compressed IP header. Glomming it back together >gets you this > > ------------ ------------ ------ ------------- > | L2 Header' | MPLS Stack | IPH' | Packet Data | > ------------ ------------ ------ ------------- > >Certainly the existing compression technique works. Right, again we briefly referenced this possibility in the draft. As the draft says: Other methods for supporting IP and IP/UDP/RTP header compression over MPLS are possible and some where considered. One alternative worth noting is adapting the existing header compression techniques to operate directly over MPLS without any MPLS header compression. [...] The second and more important reason for not adapting compression to operate over MPLS was simply to gain extra efficiency by enabling the compression of the MPLS label stack. > > > > > > > The traffic is standard IP not compressed IP. > >Yes. And your point is? Surely you are NOT going >to give me a hard time for omitting a word... Your point appeared to be based on the premise that "compressed IP" was being transported. I accept that this was a typo. Point dropped. > > > > [...] > > > > > Also, it is possible to choose an approach that > > > makes this statement invalid. > > > > Again, the earlier statement is one of fact not opinion. > >I think I have shown that this "fact" is not true. >I have described an approach that shows that the >existing compression technique will operate. You >have to do a tiny bit more work, but you have to >do that much in your scheme as well. Here's the text in question: 1. Introduction IP and IP/UDP/RTP header compression, which is defined in [RFC2507] and [RFC2508], reduces header overhead and is particularly useful on lower speed links. The current header compression definition relies on IP datagrams being carried directly over a link layer protocol, such as PPP [STD51]. With the introduction of MPLS [LABELS], one or more MPLS headers, which are called label stack entries, may be present between the IP and link layer headers. Since the header following the link layer header is no longer IP, the existing compression techniques will not operate. The "existing compression techniques" as specified in published RFCs won't work. Period. Yes 2508 and 2507 can be applied without modification, but 2509 cannot. I included all three in "existing compression techniques" as they are commonly used together. Is your point simply that I should have added "RFC2509 in particular" to the last sentence? If so, sure point taken and we can add that clause. > > > > [...] > > > > > While the draft states that the alternative of > > > using IP header compression - as is - over MPLS > > > was considered, I think this option was too > > > quickly dismissed. > > > > A minor note, a replacement for rfc2509 would need > > to be written to enable this. > >Actually, one of your drafts could - with very minor >modification - perform this 'replacement' task. Ahh, violent agreement. > It >could also serve to describe the simplistic approach >to using already defined IP header compression over >uncompressed MPLS shim header. Or, it could be merged >with the -simple draft. They're two disjoint compression schemes. Why have a spec that covers two topics, each of which may be independently implemented. > > > > > One of the reasons it was dismissed was that > > >MPLS headers do not carry packet type codes. In > > >making this decision in design of MPLS, we setup a > > >general requirement to define new type codes for > > >applicable link layers WHEN IT IS IMPORTANT FOR AN > > >INTERMEDIATE LSR TO KNOW THE PROTOCOL OF THE DATA > > >PACKET ENCAPSULATED BY MPLS. Hence, if we determine > > >that there is a need for intermediate LSRs to know > > >that the MPLS encapsulated packet uses IP header > > >compression, then we might be justified in defining > > >new link layer discriminators (packet type codes) > > >for such packets when transported over MPLS. > > > > I don't think you mean intermediate LSR here, next hop or > > downstream is accurate. (remember such compression is > > hop-by-hop.) > >I'm thinking in generalities. Suppose a 'low speed' >link of the future is an LSP. Where do you go with >this approach then? Answer, you probably don't. I >like to think it's a good idea to think "no future, >no present" when it comes to developing standards. Again, as long as this "low-speed" link transport mechanism can support IP and IP header compression, there won't be an issue. > > > > The general comment is still valid, while a bit awkward, > > we could use link layer types to indicated they type of > > data being carried within the MPLS stack. As the document > > states, this issue wasn't the critical one. From the same > > paragraph in the document: > > > > [...] The second and more important reason for not > > adapting compression to operate over MPLS was simply > > to gain extra efficiency by enabling the compression > > of the MPLS label stack. > > > > The delta here is from (2 or 4 bytes + 4bytes/mpls header) > > versus 2 or 4 bytes. > >If you assume that there is one MPLS label in the shim header, >then the difference is simply 4 bytes. Right, but I think this is too limiting an assumption. >The actual size of the >compressed IP header is not 2 or 4 bytes, but (according to RFC >2507) actually 4-7 bytes. it's: 2 bytes for MPLS/IP/UDP/RTP when UDP checksums aren't used 4 bytes for MPLS/IP/UDP/RTP when UDP checksums are used I believe it's 7 for MPLS/IP/TCP but would need to check. >I assume that all the same extra >values have to be carried when the MPLS header and the IP header >are compressed together (although I might have to add a nibble, >at least, for the EXT field), This is already covered in the draft. > so the delta should be more like >8-15 bytes verses 4-8 bytes. This delta is not so stark as the >2-4 verses 6-8 - at least when expressed as a percentage. I believe the numbers I stated are correct. Certainly there are mixes of traffic that result in MPLS/IP or just IP header compression being less (or even not) useful. >If you assume more than one MPLS label, then the delta becomes >more pronounced. But how likely is this? Some envision two or more labels as the norm. (as discussed in another thread.) > > > > [...] > > > > > A second reason for dismissing other approaches > > >was that additional compression efficiency could be > > >obtained by compressing the MPLS shim header as well. > > >I do not see that the potential for compressing one > > >32 bit word justifies the proposal. Further, I doubt > > >the existence of an application for multiple stacked > > >labels being transported across a low-speed link - > > >thus it does not seem likely that the MPLS shim header > > >will be much larger than 32 bits. > > > > I don't everyone would agree with this statement. > >But, apparently, the question does come up. :-) > agreed. Lou From owner-mpls@UU.NET Sun Jul 23 14:42: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 OAA12570 for ; Sun, 23 Jul 2000 14:42:47 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizcs21759; Sun, 23 Jul 2000 18:42:42 GMT Received: by mail-control.mail.uu.net id QQizcs14504 for mpls-outgoing; Sun, 23 Jul 2000 18:42: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 QQizcs14497 for ; Sun, 23 Jul 2000 18:42: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 QQizcs17674 for ; Sun, 23 Jul 2000 14:42:02 -0400 (EDT) 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 QQizcs11940 for ; Sun, 23 Jul 2000 18:42:02 GMT Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by crufty; Sun Jul 23 14:40:18 EDT 2000 Received: from dnrc.bell-labs.com (ex-vpn68.pa.bell-labs.com [135.250.1.68]) by zubin.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA09487; Sun, 23 Jul 2000 14:41:13 -0400 (EDT) Message-ID: <397B3D1E.BF84276D@dnrc.bell-labs.com> Date: Sun, 23 Jul 2000 11:44:46 -0700 From: Grenville Armitage Organization: Bell Labs Research Silicon Valley X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lou Berger CC: Eric Gray , "MPLS Mailing List (E-mail)" Subject: Re: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt References: <4.3.2.7.2.20000723080511.00b80de0@mail.labn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lou Berger wrote: [..] > I'll also responded to your specific points below, although I'm less sure > there's general interest in the details. Details speak to the question of whether your draft (as totally new work) is preferable to developing a diff to some existing compression approaches. Please do post your evaluations to the list, even if only for archival purposes. cheers, gja ________________________________________________________________________ Grenville Armitage http://members.home.net/garmitage/ Bell Labs Research Silicon Valley From owner-mpls@UU.NET Sun Jul 23 14:53: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 OAA15062 for ; Sun, 23 Jul 2000 14:53:37 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizct27712; Sun, 23 Jul 2000 18:53:30 GMT Received: by mail-control.mail.uu.net id QQizct15129 for mpls-outgoing; Sun, 23 Jul 2000 18:53: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 QQizct15124 for ; Sun, 23 Jul 2000 18:53: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 QQizct18671 for ; Sun, 23 Jul 2000 14:53:07 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQizct19066 for ; Sun, 23 Jul 2000 18:52:52 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id NAA09246; Sun, 23 Jul 2000 13:52:39 -0500 Message-Id: <4.3.2.7.2.20000723144705.00b8c710@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 23 Jul 2000 14:52:43 -0400 To: Grenville Armitage From: Lou Berger Subject: Re: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Cc: Lou Berger , Eric Gray , "MPLS Mailing List (E-mail)" In-Reply-To: <397B3D1E.BF84276D@dnrc.bell-labs.com> References: <4.3.2.7.2.20000723080511.00b80de0@mail.labn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Grenville, The draft *is* a diff/extension to the existing IP (rfc2507) and IP/UDP/RTP (rfc2508) header compression schemes. And draft-ietf-mpls-hdr-comp-over-ppp is a minor diff/extension to rfc2509. Lou PS The "-simple" approach is a totally new one. This is appropriate as draft-ietf-mpls-hdr-comp- and the 2507/8 are "one-hop" based, while "-simple" is multi-hop. At 11:44 AM 7/23/00 -0700, Grenville Armitage wrote: >Lou Berger wrote: > [..] > > I'll also responded to your specific points below, although I'm less sure > > there's general interest in the details. > >Details speak to the question of whether your draft (as totally new >work) is preferable to developing a diff to some existing compression >approaches. Please do post your evaluations to the list, even if only >for archival purposes. > >cheers, >gja >________________________________________________________________________ >Grenville Armitage http://members.home.net/garmitage/ >Bell Labs Research Silicon Valley From owner-mpls@UU.NET Mon Jul 24 06:39: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 GAA09796 for ; Mon, 24 Jul 2000 06:39:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizfe15472; Mon, 24 Jul 2000 10:39:29 GMT Received: by mail-control.mail.uu.net id QQizfe03654 for mpls-outgoing; Mon, 24 Jul 2000 10:39: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 QQizfe03649 for ; Mon, 24 Jul 2000 10:38: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 QQizfe26407 for ; Mon, 24 Jul 2000 06:38:55 -0400 (EDT) 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 QQizfe29180 for ; Mon, 24 Jul 2000 10:38:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA26110 for mpls@uu.net; Mon, 24 Jul 2000 06:38:54 -0400 (EDT) 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 QQizfe03636 for ; Mon, 24 Jul 2000 10:38:25 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizfe14240 for ; Mon, 24 Jul 2000 06:38:00 -0400 (EDT) Received: from ietf.org by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQizfe28547 for ; Mon, 24 Jul 2000 10:37:44 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08974; Mon, 24 Jul 2000 06:37:44 -0400 (EDT) Message-Id: <200007241037.GAA08974@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-te-mib-04.txt Date: Mon, 24 Jul 2000 06:37:43 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Traffic Engineering Management Information Base Using SMIv2 Author(s) : C. Srinivasan, A. Viswanathan, T. Nadeau Filename : draft-ietf-mpls-te-mib-04.txt Pages : 46 Date : 21-Jul-00 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multi-Protocol Label Switching (MPLS) [MPLSArch] [MPLSFW] based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-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-te-mib-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-te-mib-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: <20000721172241.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-te-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-te-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721172241.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jul 24 08:56: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 IAA19369 for ; Mon, 24 Jul 2000 08:56:20 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizfn07741; Mon, 24 Jul 2000 12:56:10 GMT Received: by mail-control.mail.uu.net id QQizfn03274 for mpls-outgoing; Mon, 24 Jul 2000 12:55: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 QQizfn03268 for ; Mon, 24 Jul 2000 12:55: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 QQizfn13245 for ; Mon, 24 Jul 2000 08:55:28 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQizfn06942 for ; Mon, 24 Jul 2000 12:54:58 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA03863 for mpls@uu.net; Mon, 24 Jul 2000 08:54:57 -0400 (EDT) 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 QQizfn03240 for ; Mon, 24 Jul 2000 12:54: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 QQizfn13134 for ; Mon, 24 Jul 2000 08:54:16 -0400 (EDT) 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 QQizfn20483 for ; Mon, 24 Jul 2000 12:54:15 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 OAA10443; Mon, 24 Jul 2000 14:50:13 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([218.1.68.146]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA19457; Mon, 24 Jul 2000 14:50:20 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2448.0) id ; Mon, 24 Jul 2000 14:50:45 +0200 Message-ID: <3B59676F9ADBD211B5360060086E64EECC01B7@MCHH237E> From: Theimer Thomas To: "'Lou Berger'" Cc: Eric Gray , erosen@cisco.com, "MPLS Mailing List (E-mail)" , "'George Swallow'" Subject: RE: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Date: Mon, 24 Jul 2000 14:50:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Lou, I just wanted to point out that there is another proposal on the table for end-end compression with MPLS that doesn't even require any changes to existing header compression mechanisms. All that is needed is carrying PPP over MPLS. You can then run any header compression offered by PPP end-end over MPLS (be it RFC 2508/2509 or robust HC or any other scheme). You can even run header compression over non-PPP links (e.g. Ethernet) if they can support MPLS. The proposal is described in draft-theimer-tcrtp-mpls-00.txt. Its efficiency is much better than the "simple" end-end compression, but it is of course much more complex to process. However, since the compression is done very close to the source, this may still be acceptable (anyway, if the source is connected to the bottleneck link, it makes no difference if compression is one-hop or end-end). One might even link the state of VoIP calls to the compression context if desired. Eric's issue with not knowing higher layer protocols is also a non-issue with end-end compression. My interpretation of this "consensus" thread is that there is more support for end-end compression than there is for one-hop compression with MPLS. Please correct me if I'm way off here. Thomas > -----Original Message----- > From: Lou Berger [SMTP:lberger@labn.net] > Sent: Friday, July 21, 2000 7:58 PM > To: erosen@cisco.com > Cc: Lou Berger; Eric Gray; MPLS Mailing List (E-mail); 'George Swallow' > Subject: Re: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt > > Eric, > The reason why you'd use the "one hop" approach over simple is > that the two compression schemes have vastly different efficiencies. (17 + > 4 bytes/label versus 2 or 4 bytes. see slide 11 of my Adelaide > presentation.) IMO the "one hop" approach is best suited for those links in > the network that are very tightly constrained. This may be on very slow > speed links or just "slower" speed links, where "slower" is limited by the > hardware being used. > > I think your characterization below of an application is valid. The VPN > example came in on a question of why there would ever be multiple > labels. The case I was thinking about is were there is an inner label that > indicates VPN and an outer label that indicates an egress. I didn't mean > to be evasive, I just didn't think it was that complicated. I've also > heard mentioned using label stacking where, as with VPNS, the inner label > indicates an application session. > > Lou > > At 01:32 PM 7/21/00 -0400, Eric Rosen wrote: > > >I think the basic question is whether there is a use for a "one hop" > >compression strategy. > > > >Some people have mentioned voice traffic as an application for which > >compression would be required. If voice packets tend to be very small, then > >compression might well be significant, even on higher speed lines. However, > >that does not seem to me to be a good application of a "one hop" compression > >scheme. It seems much better suited to a scheme which compresses at the LSP > >ingress and decompresses at the LSP egress, such as is described in draft- > >swallow-mpls-simple-hdr-compress.txt. > > > >So we're back to the case of low speed access lines carrying MPLS traffic in > >a non-voice application, and I still haven't seen a clear statement of the > >need. You do hint at one: > > > >Lou> Think MPLS based access links that support VPNs, as one example. > > > >I'm not aware of a VPN scheme which requires running MPLS over low speed > >access links. But let me see if I can guess what you might be talking > >about. > > > >One could imagine a piece of Customer Premises Equipment (CPE), a router, > >which has an ethernet interface (to connect to endusers) and a low speed > >wireless interface (to connect to the backbone). One could also imagine > >that when the CPE receives an ethernet packet, it assign it to a VPN> > >according to some criteria. One could also imagine that the CPE maintains > >an LSP for each VPN, with the next LSP hop being another router which is > >reached over the wireless interface. > > > >If this is the sort of thing you're talking about, then I do see how a > >"single hop" header compression scheme could be useful. > > > >Of course, you could say what you're talking about and save the rest of us > >the trouble of having to surmise it ;-) > > > >I have a little more trouble imagining why a packet on this link would carry > >more than one label. But perhaps the usefulness of the compression doesn't > >depend on there being more than one label. > > > >Whether this is actually a good solution to the problem of a multi-VPN CPE > >connected by a slow link to the backbone is something on which I'll reserve > >judgment. > > > >Of course, if I haven't guessed correctly the application you have in mind, > >then I still don't see the use of the compression. From owner-mpls@UU.NET Mon Jul 24 09: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 JAA25303 for ; Mon, 24 Jul 2000 09:34:49 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizfq20596; Mon, 24 Jul 2000 13:34:43 GMT Received: by mail-control.mail.uu.net id QQizfq17064 for mpls-outgoing; Mon, 24 Jul 2000 13: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 QQizfq17051 for ; Mon, 24 Jul 2000 13:33: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 QQizfq06532 for ; Mon, 24 Jul 2000 09:33:11 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQizfq04469 for ; Mon, 24 Jul 2000 13:32:56 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA07605 for ; Mon, 24 Jul 2000 06:33:10 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA13727 for mpls@uu.net; Mon, 24 Jul 2000 09:32:54 -0400 (EDT) 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 QQiywk28200 for ; Sat, 22 Jul 2000 01:42: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 QQiywk22290 for ; Fri, 21 Jul 2000 21:41:59 -0400 (EDT) Received: from rip.psg.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQiywk07518 for ; Sat, 22 Jul 2000 01:41:59 GMT Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 13FoIe-0008Xk-00; Fri, 21 Jul 2000 18:41:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Markus Jork Cc: Kireeti Kompella , mpls@UU.NET Subject: Re: New Internet Draft: TE over Unnumbered Links References: <200007210912.CAA14653@kummer.juniper.net> <200007211252.IAA04314@mailhost.avici.com> Message-Id: Date: Fri, 21 Jul 2000 18:41:56 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > you have picked the value 3 for the new "Unnumbered Interface ID" > ERO subobject type. Can you please make that some other value. > draft-ietf-mpls-rsvp-lsp-tunnel-06.txt has just assigned > subobject type 3 to the "Label" subobject. That is only used > in RROs but we should maintain the uniqueness of subtypes across > EROs and RROs. i suspect you all need iana considerations sections and have iana assign the number space. randy From owner-mpls@UU.NET Mon Jul 24 10:10: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 KAA02550 for ; Mon, 24 Jul 2000 10:10:21 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizfs03909; Mon, 24 Jul 2000 14:10:03 GMT Received: by mail-control.mail.uu.net id QQizfs00287 for mpls-outgoing; Mon, 24 Jul 2000 14:09: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 QQizfs00282 for ; Mon, 24 Jul 2000 14:09: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 QQizfs27040 for ; Mon, 24 Jul 2000 10:09:26 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQizfs02913 for ; Mon, 24 Jul 2000 14:09:11 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id IAA01216; Mon, 24 Jul 2000 08:55:45 -0500 Message-Id: <4.3.2.7.2.20000724091207.00bc3cd0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 09:55:51 -0400 To: Theimer Thomas , George Swallow , Vijay Srinivasan From: Lou Berger Subject: RE: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Cc: "'Lou Berger'" , Eric Gray , erosen@cisco.com, "MPLS Mailing List (E-mail)" In-Reply-To: <3B59676F9ADBD211B5360060086E64EECC01B7@MCHH237E> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Thomas, Thanks for pointing this out, I hadn't noticed it. As you say in your message, this proposal brings in more of the tradeoffs considered in the -simple draft. Some of us had talked about this approach. I think the simple draft captures some of the rational behind not following the approach you propose. Sophisticated header compression techniques rely on feedback to achieve resynchronization. When packets are lost, the compressor and decompressor must resynchronize. For an application such as voice over IP in the wide-area, the time necessary to achieve such resynchronization may be longer than the voice application can tolerate. Another consideration is the bandwidth verses processing trade-off. In many prospective environments it may be desirable to trade a small amount of compression efficiency for a less processing intense (and thus more scalable) compression technique. For example, a voice gateway may be called upon to compress and decompress many flows. We propose a simple header compression technique which requires no resynchronization and a relatively light per packet processing load. More generally, given that IP header compression has been found to be useful both in the one-hop cases and now in the multi-hop case, I think we should be open to both approaches for MPLS. There are many different ways that, and places where, folks are envisioning using compression. In terms of consensus I think we have: (a) that one-hop and multi-hop compression are things that the WG should address (from Adelaide.) (b) that some would like to see an approach that maximizes compression (from Adelaide and list.) (c) That some would like to see an approach that operates multi-hop/end-to-end and is more scalable (from Adelaide and list.) (d) (Lou's interpretation of list comments) That the proposed one-hop solution is acceptable as long as its usage is well constrained. (My proposal is "recommended for use on links where IP Header Compression [RFC2507, 2508] is, or can be used" or "not recommend for use on links where IP Header Compression [RFC2507, 2508] could not or would not be used" depending on if the groups wants it in the positive or negative form.) I don't think we've made much headway, beyond Adelaide on the multi-hop approach. At this point, I think some in-session time would be useful in gauging consensus. Vijay, George, Oh WG chairs, is there a chance of getting some time? If you think we're close / have some consensus (and don't need to discuss this next week), could you tell us what it is! Thanks, Lou At 02:50 PM 7/24/00 +0200, Theimer Thomas wrote: >Lou, > >I just wanted to point out that there is another proposal on the table for >end-end compression with MPLS that doesn't even require any changes to >existing header compression mechanisms. All that is needed is carrying PPP >over MPLS. You can then run any header compression offered by PPP end-end >over MPLS (be it RFC 2508/2509 or robust HC or any other scheme). You can >even run header compression over non-PPP links (e.g. Ethernet) if they can >support MPLS. > >The proposal is described in draft-theimer-tcrtp-mpls-00.txt. Its >efficiency is much better than the "simple" end-end compression, but it is >of course much more complex to process. However, since the compression is >done very close to the source, this may still be acceptable (anyway, if >the source is connected to the bottleneck link, it makes no difference if >compression is one-hop or end-end). One might even link the state of VoIP >calls to the compression context if desired. Eric's issue with not knowing >higher layer protocols is also a non-issue with end-end compression. > >My interpretation of this "consensus" thread is that there is more support >for end-end compression than there is for one-hop compression with MPLS. >Please correct me if I'm way off here. > >Thomas > > -----Original Message----- > > From: Lou Berger [SMTP:lberger@labn.net] > > Sent: Friday, July 21, 2000 7:58 PM > > To: erosen@cisco.com > > Cc: Lou Berger; Eric Gray; MPLS Mailing List (E-mail); 'George Swallow' > > Subject: Re: Consensus on compression - > draft-ietf-mpls-hdr-comp-00.txt > > > > Eric, > > The reason why you'd use the "one hop" approach over simple is > > that the two compression schemes have vastly different > efficiencies. (17 + > > 4 bytes/label versus 2 or 4 bytes. see slide 11 of my Adelaide > > presentation.) IMO the "one hop" approach is best suited for those > links in > > the network that are very tightly constrained. This may be on very slow > > speed links or just "slower" speed links, where "slower" is limited by the > > hardware being used. > > > > I think your characterization below of an application is valid. The VPN > > example came in on a question of why there would ever be multiple > > labels. The case I was thinking about is were there is an inner label > that > > indicates VPN and an outer label that indicates an egress. I didn't mean > > to be evasive, I just didn't think it was that complicated. I've also > > heard mentioned using label stacking where, as with VPNS, the inner label > > indicates an application session. > > > > Lou > > > > At 01:32 PM 7/21/00 -0400, Eric Rosen wrote: > > > > >I think the basic question is whether there is a use for a > "one hop" > > >compression strategy. > > > > > >Some people have mentioned voice traffic as an > application for which > > >compression would be required. If voice packets tend to be very > small, then > > >compression might well be significant, even on higher speed > lines. However, > > >that does not seem to me to be a good application of a "one hop" > compression > > >scheme. It seems much better suited to a scheme which compresses at > the LSP > > >ingress and decompresses at the LSP egress, such as is described in > draft- > > >swallow-mpls-simple-hdr-compress.txt. > > > > > >So we're back to the case of low speed access lines carrying MPLS > traffic in > > >a non-voice application, and I still haven't seen a clear statement > of the > > >need. You do hint at one: > > > > > >Lou> Think MPLS based access links that support VPNs, as one example. > > > > > >I'm not aware of a VPN scheme which requires running MPLS over low > speed > > >access links. But let me see if I can guess what you might be > talking > > >about. > > > > > >One could imagine a piece of Customer Premises Equipment (CPE), a > router, > > >which has an ethernet interface (to connect to endusers) and a low > speed > > >wireless interface (to connect to the backbone). One could also > imagine > > >that when the CPE receives an ethernet packet, it assign it to > a VPN> > > >according to some criteria. One could also imagine that the CPE > maintains > > >an LSP for each VPN, with the next LSP hop being another > router which is > > >reached over the wireless interface. > > > > > >If this is the sort of thing you're talking about, then I do > see how a > > >"single hop" header compression scheme could be useful. > > > > > >Of course, you could say what you're talking about and save the rest > of us > > >the trouble of having to surmise it ;-) > > > > > >I have a little more trouble imagining why a packet on this link would > carry > > >more than one label. But perhaps the usefulness of the compression > doesn't > > >depend on there being more than one label. > > > > > >Whether this is actually a good solution to the problem of a > multi-VPN CPE > > >connected by a slow link to the backbone is something on which I'll > reserve > > >judgment. > > > > > >Of course, if I haven't guessed correctly the application you have in > mind, > > >then I still don't see the use of the compression. From owner-mpls@UU.NET Mon Jul 24 10:59: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 KAA13389 for ; Mon, 24 Jul 2000 10:59:06 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizfv24940; Mon, 24 Jul 2000 14:58:36 GMT Received: by mail-control.mail.uu.net id QQizfv03526 for mpls-outgoing; Mon, 24 Jul 2000 14:58: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 QQizfv03519 for ; Mon, 24 Jul 2000 14:58:12 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizfv22718 for ; Mon, 24 Jul 2000 10:56:49 -0400 (EDT) Received: from web5305.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web5305.mail.yahoo.com [216.115.106.114]) id QQizfv23234 for ; Mon, 24 Jul 2000 14:56:34 GMT Message-ID: <20000724145633.23114.qmail@web5305.mail.yahoo.com> Received: from [192.32.148.69] by web5305.mail.yahoo.com; Mon, 24 Jul 2000 07:56:33 PDT Date: Mon, 24 Jul 2000 07:56:33 -0700 (PDT) From: Pratik Shah Subject: Free MPLS RSVP-TE or CR-LDP implementations ?? To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi there.. Can any one guide me to a free source of either RSVP-TE or CR-LDP MPLS implementation.... Thanks, Pratik. __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From owner-mpls@UU.NET Mon Jul 24 11:44: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 LAA29258 for ; Mon, 24 Jul 2000 11:44:05 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizfx17962; Mon, 24 Jul 2000 15:28:26 GMT Received: by mail-control.mail.uu.net id QQizfx18104 for mpls-outgoing; Mon, 24 Jul 2000 15:27: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 QQizfx18074 for ; Mon, 24 Jul 2000 15:27: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 QQizfx27696 for ; Mon, 24 Jul 2000 11:25:26 -0400 (EDT) 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 QQizfx15623 for ; Mon, 24 Jul 2000 15:25:25 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA25152 for mpls@uu.net; Mon, 24 Jul 2000 11:25:25 -0400 (EDT) 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 QQizfx17678 for ; Mon, 24 Jul 2000 15:24: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 QQizfx11366 for ; Mon, 24 Jul 2000 11:24:00 -0400 (EDT) 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 QQizfx29412 for ; Mon, 24 Jul 2000 15:23:44 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id E4D24104; Mon, 24 Jul 2000 17:23:43 +0200 (MET DST) Received: from flefauch-8kcdt.cisco.com (nice-dhcp3.cisco.com [144.254.60.25]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id RAA00638; Mon, 24 Jul 2000 17:23:38 +0200 (MET DST) Message-Id: <200007241523.RAA00638@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 24 Jul 2000 17:19:24 +0200 To: Lou Berger From: Francois Le Faucheur Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) Cc: Shahram Davari , "'Lou Berger'" , mpls@UU.NET In-Reply-To: <4.3.2.7.2.20000721152734.00ccd970@mail.labn.net> References: <336ECDAFDF7DD311B9E30090277AEE4101B406A5@nt-exchange-bby.p mc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Lou, > >Again, I think the issues here are mainly related to transition. I think >the following from draft-lefaucheur-diff-te-reqts-00.txt captures the issue. > We identify the following backward compatibility requirements for > the RSVP/CR-LDP extensions: > - operations in heterogeneous environments need to be supported > for smooth migration, where some LSRs are Diff-Serv-TE-capable > (as defined in this specification) while some other LSRs are not > Diff-Serv-TE-capable (i.e. support (aggregate) TE only) >and > - in heterogeneous environments, the solution needs to ensure that > a non-Diff-Serv-TE-capable LSR would reject establishment of a > Class-Type N (N=1,2,3) LSP. > >Note that the latter issue isn't addressed by your example but is in my >proposal. > As Shahram pointed out earlier, your transition concern does not relate to "non-Diff-Serv LSRs" (non-DS-LSRs) , but rather relate to "LSRs which are Diff-Serv capable but do so in a pre-Diff-Ext manner i.e. use non-zero-COS signaling". The question we are facing here is about backward compatibility with a pre-Diff-Ext method to support Diff-Serv, not with devices which did not support DS. So, the backward compatibility requirements you quote for non-DS-capable nodes don't directly relate to this particular migration issue. My view is that: - clearly, the COS Service defined in rsvp-te is essential so that LSPs can be signaled without bandwidth reservation. - However, the use of non-zero COS field in the COS Flow_Spec/Sender_Tspec for support of Diff-Serv is pretty much superseeded by the Diff-ext specification. - the ability to allow introduction of Diff-Serv without changing anything in the signaling (ie use Preconfigured mapping E-LSPs) simplifies migration from true-non-DS-LSRs to Diff-Serv operations, which is the most important migration scenario. So this should be retained. Cheers Francois >Lou > > >>Regards, >>-Shahram >> >> >> >-----Original Message----- >> >From: Lou Berger [mailto:lberger@labn.net] >> >Sent: Friday, July 21, 2000 2:59 PM >> >To: Shahram Davari >> >Cc: 'Lou Berger'; Shahram Davari; George Swallow; mpls@UU.NET >> >Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) >> > >> > >> >Your example looks fine. >> > >> >Now consider the case where the ingress/LER doesn't support >> >MPLS DS. It >> >uses COS1, and sets the EXP bit to 000. The LSR1 will treat >> >the packets >> >with EXP0, probably DF, while LSR2 will provide COS1 service. >> > >> >So the introduction of a DS capable transit node can reduce >> >the service >> >seen by an existing non-DS edge. This is the problem. >> > >> >Lou >> > >> > >> >At 11:52 AM 7/21/00 -0700, Shahram Davari wrote: >> >>Lou, >> >> >> >>Let me explain my solution to your problem with an example. >> >Assume we have >> >>an LSP that spans LSR1 (Diffserv LSR) and LSR2 (non-Diffserv LSR). Now >> >>assume that in the RSVP message we set COS=COS1 and no >> >Diffserv object. >> >>Since the LSP is spanning a Diffserv LSR and a non-Diffserv >> >LSR, the LER >> >>(Label Edge Router) must be a Diffserv and a non-Diffserv >> >edge LSR. Now >> >>assume that the LER sets the EXP field of all packets to EXP=EXP1 >> >>(indicating a local PHB) in such a way that both EXP1 and >> >COS1 indicate the >> >>same local behavior to the LSR1 and LSR2 respectively: >> >> >> >> >> >> EXP=EXP1 COS=COS1 >> >> O----------O----------O------ >> >> LER LSR1 LSR2 >> >> >> >> >> >>LSR1 will ignore the COS field and will behave according to >> >pre-configured >> >>behavior of EXP1, and LSR2 will ignore the EXP field and >> >behave according to >> >>COS1. Since we have designed the EXP1 and COS1 behaviors to >> >be the same, >> >>then we will have a consistent behavior throughout the LSP. >> >> >> >>If the LER sets the EXP to a wrong value (i.e., a value that >> >does not match >> >>COS1), then this is a configuration problem, which pretty >> >much exist in all >> >>Diffserv networks. >> >> >> >>Does this make sense? >> >> >> >>Regards, >> >>-Shahram >> >> >> >> >-----Original Message----- >> >> >From: Lou Berger [mailto:lberger@labn.net] >> >> >Sent: Friday, July 21, 2000 12:59 PM >> >> >To: Shahram Davari >> >> >Cc: 'Lou Berger'; George Swallow; mpls@UU.NET >> >> >Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) >> >> > >> >> > >> >> >Shahram, >> >> > see below. >> >> > >> >> >At 09:31 AM 7/21/00 -0700, Shahram Davari wrote: >> >> >>Hi Lou, George >> >> >> >> >> >> >PS As mentioned back on 2/8, I believe one trivial solution is >> >> >> >to require >> >> >> >the use of the DiffServ Object/TLV for all E-LSPs, where use of >> >> >> >preconfigured EXP<-->PHB mappings is indicated by either (pick >> >> >> >one) no map >> >> >> >parameters or a single map parameter set to all zeros. >> >> >> >Another solution is >> >> >> >to use the one proposed in >> >> >> >draft-lefaucheur-diff-te-ext-00.txt, although it >> >> >> >does use a new object that could just be merged with the >> >> >> >DiffServ Object. >> >> >> >> >> >>Your solution is ONLY valid if a single LSR could be both a >> >> >Diffserv LSR and >> >> >>a non-Diffserv LSR. >> >> > >> >> >It works for both cases, i.e., for the cases where a DS LSR >> >> >can support >> >> >non-DS LSPs and when it cannot. In the latter case, a >> >PathErr with an >> >> >appropriate code&value would need to be generated. >> >> > >> >> >>So it could use the presence of Diffserv object to >> >> >>decide what behavior it should have (Diffserv behavior or >> >non-Diffserv >> >> >>behavior).I don't see any benefit in having a single LSR >> >to be both a >> >> >>Diffserv LSR and a non-Diffserv LSR. If the purpose is to >> >support both >> >> >>standardized PHBs and some local behavior that are not >> >> >standardized, you >> >> >>could always use the Diffserv local-PHBs. >> >> > >> >> >We covered this the last time around. Here's a relevant excerpt: >> >> > >> >> > >> >> >>Date: Wed, 09 Feb 2000 16:57:57 -0500 >> >> >>To: Shahram Davari >> >> >>From: Lou Berger >> >> >>Subject: RE: Announcing draft-ietf-mpls-diff-ext-03.txt >> >> >>Cc: "'Lou Berger'" , "'Jim Boyle'" >> >> >, >> >> >> mpls@UU.NET >> >> >>Sender: owner-mpls@UU.NET >> >> >>[...] >> >> > >> >> >LB: >> >> > >> >> > >> >> >>> > >> >> >>> > One (new) point, your implicit mode hijacks existing >> >> >>> > signaling mechanisms >> >> >>> > and gives them new meaning. (Now that I think of it, this is >> >> >>> > a large part >> >> >>> > of my objection to the current form of the draft.) For >> >> >>> > non-DS nodes, CoS >> >> >>> > behavior can be provided by signaling a CoS LSP and not using >> >> >>> > the EXP bits >> >> >>> > at all. If that same LSP hits a DS node with the current >> >> >>> > draft, it will be >> >> >>> > treated as an E-LSP and the matching traffic will receive the >> >> >>> > service that >> >> >>> > matches bits 000. >> >> > >> >> >SD: >> >> > >> >> >>>First of all you have the same situation in a non-MPLS and >> >> >Diffserv network. >> >> >>>Do you plan to add signaling to them too? >> >> > >> >> >LB: >> >> > >> >> >>No because all traffic is best-effort in a DS network. There >> >> >would be >> >> >>some work to resolve conflicts if you were trying to support >> >> >RSVP on the >> >> >>same links/data as DS. >> >> > >> >> >SD: >> >> > >> >> >>>Secondly it is a misconfiguration to use a non-DS node in a >> >> >Diffserv network >> >> >>>and it is very unusual to use a DS-node in a Diffserv >> >> >network that supports >> >> >>>non-Diffserv behavior too. So why don't we choose the >> >> >DS-behavior to be a >> >> >>>default behavior in a Diffserv network, and use another >> >> >object for signaling >> >> >>>those rare non-DS LSPs? >> >> > >> >> >LB: >> >> > >> >> >>So you're suggesting a new object/TLV that says "I'm not >> >> >diff-serv" rather >> >> >>than have the new feature say "I'm diff-serv"? I don't get >> >> >it. We're >> >> >>talking about few bytes of overhead that you've already >> >> >defined and are >> >> >>willing to incur for all L-LSPs and some E-LSPs. We're not >> >> >talking about >> >> >>any substantive change in processing or state. >> >> > >> >> >SD: >> >> > >> >> >>>Remember the only situation that you would use a configured >> >> >E-LSP is when >> >> >>>you are sure that all your nodes are configured and can >> >> >support the required >> >> >>>PHBs. >> >> > >> >> >LB: >> >> > >> >> >>this is not correct. With the current definition, as soon as you >> >> >>configure a node to be a DS node, all established LSPs are >> >> >E-LSPs or L-LSPs. >> >> >> >> >> >>Albeit a corner case for non-green field networks, I think you're >> >> >>requiring the configuration of all your nodes at the same >> >> >moment of time >> >> >>or just not caring about the traffic service levels during >> >> >reconfig. Do >> >> >>you view this as acceptable? >> >> >> >> >> >>Lou >> >> > >> >> >That's it. >> >> > >> >> >Lou >> >> > >> >> >>Regards, >> >> >>-Shahram >> >> > >> > > _________________________________________________________________ Francois Le Faucheur Development Engineer, IOS Layer 3 Services Cisco Systems Office Phone: +33 4 92 96 75 64 Home Office Phone: +33 4 92 94 00 78 Mobile : +33 6 89 108 159 Vmail: +33 1 58 04 62 66 Fax: +33 4 92 96 79 08 Email: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Mon Jul 24 12:08: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 MAA06625 for ; Mon, 24 Jul 2000 12:08:16 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizga17005; Mon, 24 Jul 2000 16:05:53 GMT Received: by mail-control.mail.uu.net id QQizga03139 for mpls-outgoing; Mon, 24 Jul 2000 16:05: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 QQizga03105 for ; Mon, 24 Jul 2000 16:05: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 QQizga04852 for ; Mon, 24 Jul 2000 12:04:29 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQizga29115 for ; Mon, 24 Jul 2000 16:04:28 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id LAA13548; Mon, 24 Jul 2000 11:04:05 -0500 Message-Id: <4.3.2.7.2.20000724114230.00d42730@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 12:04:13 -0400 To: Francois Le Faucheur From: Lou Berger Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) Cc: Lou Berger , Shahram Davari , mpls@UU.NET In-Reply-To: <200007241523.RAA00638@europe.cisco.com> References: <4.3.2.7.2.20000721152734.00ccd970@mail.labn.net> <336ECDAFDF7DD311B9E30090277AEE4101B406A5@nt-exchange-bby.p mc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Francois, At 05:19 PM 7/24/00 +0200, Francois Le Faucheur wrote: >Lou, > > > > >Again, I think the issues here are mainly related to transition. I think > >the following from draft-lefaucheur-diff-te-reqts-00.txt captures the issue. > > We identify the following backward compatibility requirements for > > the RSVP/CR-LDP extensions: > > - operations in heterogeneous environments need to be supported > > for smooth migration, where some LSRs are Diff-Serv-TE-capable > > (as defined in this specification) while some other LSRs are not > > Diff-Serv-TE-capable (i.e. support (aggregate) TE only) > >and > > - in heterogeneous environments, the solution needs to ensure that > > a non-Diff-Serv-TE-capable LSR would reject establishment of a > > Class-Type N (N=1,2,3) LSP. > > > >Note that the latter issue isn't addressed by your example but is in my > >proposal. > > > >As Shahram pointed out earlier, your transition concern does not relate to >"non-Diff-Serv LSRs" (non-DS-LSRs) , but rather relate to "LSRs which are >Diff-Serv capable but do so in a pre-Diff-Ext manner i.e. use non-zero-COS >signaling". This was just one example. I think the real issues is with LSRs that are providing different classes of LSPs using the CoS/QoS semantics (defined elsewhere) loosing service as those LSPs transit MPLS-DS nodes. This includes both LSRs that know nothing of DS and those that have only a limited knowledge of DS. > The question we are facing here is about backward compatibility with a > pre-Diff-Ext method to support Diff-Serv, not with devices which did not > support DS. So, the backward compatibility requirements you quote for > non-DS-capable nodes don't directly relate to this particular migration issue. This is a special case, not the general one. If you'd like to take this special case off the table, that's fine with me. When/if we address the general case, I expect this special case will be taken care of as well. >My view is that: > - clearly, the COS Service defined in rsvp-te is essential so > that LSPs can be signaled without bandwidth reservation. > - However, the use of non-zero COS field in the COS > Flow_Spec/Sender_Tspec for support of Diff-Serv is pretty much > superseeded by the Diff-ext specification. No argument. The main issue for this case is transition. > - the ability to allow introduction of Diff-Serv without changing > anything in the signaling (ie use Preconfigured mapping E-LSPs) > simplifies migration from true-non-DS-LSRs to Diff-Serv operations, which > is the most important migration scenario. So this should be retained. I like the concept, the only problem is that as I understand the document, service will be degraded in the case where CoS/CL/GS is being signaled by a non-DS LER when the EXP bits are not set according to the preconfigured EXP map. How about including an "SHOULD" level option that allows a MPLS-DS LSR to treat LSPs signaled without the DIFFSERV object as non-DS LSPs? I think this would address this issue. (BTW which heterogeneity and transition issues are you addressing with the objects proposed in your new draft?) Thanks, Lou >Cheers > >Francois > > >Lou > > > > > >>Regards, > >>-Shahram > >> > >> > >> >-----Original Message----- > >> >From: Lou Berger [mailto:lberger@labn.net] > >> >Sent: Friday, July 21, 2000 2:59 PM > >> >To: Shahram Davari > >> >Cc: 'Lou Berger'; Shahram Davari; George Swallow; mpls@UU.NET > >> >Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) > >> > > >> > > >> >Your example looks fine. > >> > > >> >Now consider the case where the ingress/LER doesn't support > >> >MPLS DS. It > >> >uses COS1, and sets the EXP bit to 000. The LSR1 will treat > >> >the packets > >> >with EXP0, probably DF, while LSR2 will provide COS1 service. > >> > > >> >So the introduction of a DS capable transit node can reduce > >> >the service > >> >seen by an existing non-DS edge. This is the problem. > >> > > >> >Lou > >> > > >> > > >> >At 11:52 AM 7/21/00 -0700, Shahram Davari wrote: > >> >>Lou, > >> >> > >> >>Let me explain my solution to your problem with an example. > >> >Assume we have > >> >>an LSP that spans LSR1 (Diffserv LSR) and LSR2 (non-Diffserv LSR). Now > >> >>assume that in the RSVP message we set COS=COS1 and no > >> >Diffserv object. > >> >>Since the LSP is spanning a Diffserv LSR and a non-Diffserv > >> >LSR, the LER > >> >>(Label Edge Router) must be a Diffserv and a non-Diffserv > >> >edge LSR. Now > >> >>assume that the LER sets the EXP field of all packets to EXP=EXP1 > >> >>(indicating a local PHB) in such a way that both EXP1 and > >> >COS1 indicate the > >> >>same local behavior to the LSR1 and LSR2 respectively: > >> >> > >> >> > >> >> EXP=EXP1 COS=COS1 > >> >> O----------O----------O------ > >> >> LER LSR1 LSR2 > >> >> > >> >> > >> >>LSR1 will ignore the COS field and will behave according to > >> >pre-configured > >> >>behavior of EXP1, and LSR2 will ignore the EXP field and > >> >behave according to > >> >>COS1. Since we have designed the EXP1 and COS1 behaviors to > >> >be the same, > >> >>then we will have a consistent behavior throughout the LSP. > >> >> > >> >>If the LER sets the EXP to a wrong value (i.e., a value that > >> >does not match > >> >>COS1), then this is a configuration problem, which pretty > >> >much exist in all > >> >>Diffserv networks. > >> >> > >> >>Does this make sense? > >> >> > >> >>Regards, > >> >>-Shahram > >> >> > >> >> >-----Original Message----- > >> >> >From: Lou Berger [mailto:lberger@labn.net] > >> >> >Sent: Friday, July 21, 2000 12:59 PM > >> >> >To: Shahram Davari > >> >> >Cc: 'Lou Berger'; George Swallow; mpls@UU.NET > >> >> >Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) > >> >> > > >> >> > > >> >> >Shahram, > >> >> > see below. > >> >> > > >> >> >At 09:31 AM 7/21/00 -0700, Shahram Davari wrote: > >> >> >>Hi Lou, George > >> >> >> > >> >> >> >PS As mentioned back on 2/8, I believe one trivial solution is > >> >> >> >to require > >> >> >> >the use of the DiffServ Object/TLV for all E-LSPs, where use of > >> >> >> >preconfigured EXP<-->PHB mappings is indicated by either (pick > >> >> >> >one) no map > >> >> >> >parameters or a single map parameter set to all zeros. > >> >> >> >Another solution is > >> >> >> >to use the one proposed in > >> >> >> >draft-lefaucheur-diff-te-ext-00.txt, although it > >> >> >> >does use a new object that could just be merged with the > >> >> >> >DiffServ Object. > >> >> >> > >> >> >>Your solution is ONLY valid if a single LSR could be both a > >> >> >Diffserv LSR and > >> >> >>a non-Diffserv LSR. > >> >> > > >> >> >It works for both cases, i.e., for the cases where a DS LSR > >> >> >can support > >> >> >non-DS LSPs and when it cannot. In the latter case, a > >> >PathErr with an > >> >> >appropriate code&value would need to be generated. > >> >> > > >> >> >>So it could use the presence of Diffserv object to > >> >> >>decide what behavior it should have (Diffserv behavior or > >> >non-Diffserv > >> >> >>behavior).I don't see any benefit in having a single LSR > >> >to be both a > >> >> >>Diffserv LSR and a non-Diffserv LSR. If the purpose is to > >> >support both > >> >> >>standardized PHBs and some local behavior that are not > >> >> >standardized, you > >> >> >>could always use the Diffserv local-PHBs. > >> >> > > >> >> >We covered this the last time around. Here's a relevant excerpt: > >> >> > > >> >> > > >> >> >>Date: Wed, 09 Feb 2000 16:57:57 -0500 > >> >> >>To: Shahram Davari > >> >> >>From: Lou Berger > >> >> >>Subject: RE: Announcing draft-ietf-mpls-diff-ext-03.txt > >> >> >>Cc: "'Lou Berger'" , "'Jim Boyle'" > >> >> >, > >> >> >> mpls@UU.NET > >> >> >>Sender: owner-mpls@UU.NET > >> >> >>[...] > >> >> > > >> >> >LB: > >> >> > > >> >> > > >> >> >>> > > >> >> >>> > One (new) point, your implicit mode hijacks existing > >> >> >>> > signaling mechanisms > >> >> >>> > and gives them new meaning. (Now that I think of it, this is > >> >> >>> > a large part > >> >> >>> > of my objection to the current form of the draft.) For > >> >> >>> > non-DS nodes, CoS > >> >> >>> > behavior can be provided by signaling a CoS LSP and not using > >> >> >>> > the EXP bits > >> >> >>> > at all. If that same LSP hits a DS node with the current > >> >> >>> > draft, it will be > >> >> >>> > treated as an E-LSP and the matching traffic will receive the > >> >> >>> > service that > >> >> >>> > matches bits 000. > >> >> > > >> >> >SD: > >> >> > > >> >> >>>First of all you have the same situation in a non-MPLS and > >> >> >Diffserv network. > >> >> >>>Do you plan to add signaling to them too? > >> >> > > >> >> >LB: > >> >> > > >> >> >>No because all traffic is best-effort in a DS network. There > >> >> >would be > >> >> >>some work to resolve conflicts if you were trying to support > >> >> >RSVP on the > >> >> >>same links/data as DS. > >> >> > > >> >> >SD: > >> >> > > >> >> >>>Secondly it is a misconfiguration to use a non-DS node in a > >> >> >Diffserv network > >> >> >>>and it is very unusual to use a DS-node in a Diffserv > >> >> >network that supports > >> >> >>>non-Diffserv behavior too. So why don't we choose the > >> >> >DS-behavior to be a > >> >> >>>default behavior in a Diffserv network, and use another > >> >> >object for signaling > >> >> >>>those rare non-DS LSPs? > >> >> > > >> >> >LB: > >> >> > > >> >> >>So you're suggesting a new object/TLV that says "I'm not > >> >> >diff-serv" rather > >> >> >>than have the new feature say "I'm diff-serv"? I don't get > >> >> >it. We're > >> >> >>talking about few bytes of overhead that you've already > >> >> >defined and are > >> >> >>willing to incur for all L-LSPs and some E-LSPs. We're not > >> >> >talking about > >> >> >>any substantive change in processing or state. > >> >> > > >> >> >SD: > >> >> > > >> >> >>>Remember the only situation that you would use a configured > >> >> >E-LSP is when > >> >> >>>you are sure that all your nodes are configured and can > >> >> >support the required > >> >> >>>PHBs. > >> >> > > >> >> >LB: > >> >> > > >> >> >>this is not correct. With the current definition, as soon as you > >> >> >>configure a node to be a DS node, all established LSPs are > >> >> >E-LSPs or L-LSPs. > >> >> >> > >> >> >>Albeit a corner case for non-green field networks, I think you're > >> >> >>requiring the configuration of all your nodes at the same > >> >> >moment of time > >> >> >>or just not caring about the traffic service levels during > >> >> >reconfig. Do > >> >> >>you view this as acceptable? > >> >> >> > >> >> >>Lou > >> >> > > >> >> >That's it. > >> >> > > >> >> >Lou > >> >> > > >> >> >>Regards, > >> >> >>-Shahram > >> >> > > >> > > > > >_________________________________________________________________ >Francois Le Faucheur >Development Engineer, IOS Layer 3 Services >Cisco Systems >Office Phone: +33 4 92 96 75 64 >Home Office Phone: +33 4 92 94 00 78 >Mobile : +33 6 89 108 159 >Vmail: +33 1 58 04 62 66 >Fax: +33 4 92 96 79 08 >Email: flefauch@cisco.com >_________________________________________________________________ >Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France >_________________________________________________________________ From owner-mpls@UU.NET Mon Jul 24 12:12:20 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07850 for ; Mon, 24 Jul 2000 12:12:20 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizga22196; Mon, 24 Jul 2000 16:12:06 GMT Received: by mail-control.mail.uu.net id QQizga04033 for mpls-outgoing; Mon, 24 Jul 2000 16:11:15 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQizga03978 for ; Mon, 24 Jul 2000 16:11: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 QQizga05779 for ; Mon, 24 Jul 2000 12:09:55 -0400 (EDT) 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 QQizga20409 for ; Mon, 24 Jul 2000 16:09:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA01053 for mpls@uu.net; Mon, 24 Jul 2000 12:02:46 -0400 (EDT) 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 QQizga26777 for ; Mon, 24 Jul 2000 16:02: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 QQizfz03851 for ; Mon, 24 Jul 2000 11:59:03 -0400 (EDT) Received: from beamer.mchh.siemens.de by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQizfz25291 for ; Mon, 24 Jul 2000 15:59:03 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA26293; Mon, 24 Jul 2000 17:58:26 +0200 (MET DST) Received: from mchh201e.demchh201e.icn.siemens.de ([218.1.68.104]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA24551; Mon, 24 Jul 2000 17:58:31 +0200 (MET DST) Received: by MCHH201E with Internet Mail Service (5.5.2448.0) id ; Mon, 24 Jul 2000 17:58:57 +0200 Message-ID: <3B59676F9ADBD211B5360060086E64EECC01BC@MCHH237E> From: Theimer Thomas To: "'Lou Berger'" Cc: George Swallow , "MPLS Mailing List (E-mail)" Subject: RE: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Date: Mon, 24 Jul 2000 17:58:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Lou, I agree that there are some tradeoffs to be made regarding complexity and bandwidth efficiency. My take on this is: - if you can do header compression for the link connected to a voice gateway, complexity is the same for one-hop or end-end compression, if you use the same compression technique. So you can also do end-end compression without adding more complexity. - as you said, packet loss is a problem for current RTP header compression. My assumption was that the LSP carrying voice can be constrained such that packet loss is virtually eliminated, so the problem does not occur. Isn't that one of the reasons for putting voice onto MPLS in the first place ? Assuming that packet loss is sufficiently rare, a larger round trip delay (read: more RTP packets lost due to context mismatch) should not be too critical. A voice gateway could also do some intelligent things to fill the gaps when packets are lost, so the voice application may not even notice any difference. - if packet loss cannot be eliminated, use a more robust header compression scheme to be defined by ROHC folks. - if that still doesn't work, or you can't tolerate the complexity, use simple header compression. I guess we can now argue if the above assumptions are reasonable or if simple header compression is the only way to make this work. Thomas > -----Original Message----- > Lou Berger [SMTP:lberger@labn.net] wrote: > Thomas, > Thanks for pointing this out, I hadn't noticed it. As you say in > your message, this proposal brings in more of the tradeoffs considered in > the -simple draft. Some of us had talked about this approach. I think the > simple draft captures some of the rational behind not following the > approach you propose. > > Sophisticated header compression techniques rely on feedback to > achieve resynchronization. When packets are lost, the compressor and > decompressor must resynchronize. For an application such as voice > over IP in the wide-area, the time necessary to achieve such > resynchronization may be longer than the voice application can > tolerate. > > Another consideration is the bandwidth verses processing trade-off. > In many prospective environments it may be desirable to trade a small > amount of compression efficiency for a less processing intense (and > thus more scalable) compression technique. For example, a voice > gateway may be called upon to compress and decompress many flows. > > We propose a simple header compression technique which requires no > resynchronization and a relatively light per packet processing load. > > More generally, given that IP header compression has been found to be > useful both in the one-hop cases and now in the multi-hop case, I think we > should be open to both approaches for MPLS. There are many different ways > that, and places where, folks are envisioning using compression. > > In terms of consensus I think we have: > > (a) that one-hop and multi-hop compression are things that the WG should > address (from Adelaide.) > > (b) that some would like to see an approach that maximizes compression > (from Adelaide and list.) > > (c) That some would like to see an approach that operates > multi-hop/end-to-end and is more scalable (from Adelaide and list.) > > (d) (Lou's interpretation of list comments) That the proposed one-hop > solution is acceptable as long as its usage is well constrained. > (My proposal is "recommended for use on links where IP Header Compression > [RFC2507, 2508] is, or can be used" or "not recommend for use on links > where IP Header Compression [RFC2507, 2508] could not or would not be used" > depending on if the groups wants it in the positive or negative form.) > > I don't think we've made much headway, beyond Adelaide on the multi-hop > approach. > > At this point, I think some in-session time would be useful in gauging > consensus. > > > > Vijay, George, > > Oh WG chairs, is there a chance of getting some time? > > If you think we're close / have some consensus (and don't need to discuss > this next week), could you tell us what it is! > > Thanks, > Lou > > At 02:50 PM 7/24/00 +0200, Theimer Thomas wrote: > >Lou, > > > >I just wanted to point out that there is another proposal on the table for > >end-end compression with MPLS that doesn't even require any changes to > >existing header compression mechanisms. All that is needed is carrying PPP > >over MPLS. You can then run any header compression offered by PPP end-end > >over MPLS (be it RFC 2508/2509 or robust HC or any other scheme). You can > >even run header compression over non-PPP links (e.g. Ethernet) if they can > >support MPLS. > > > >The proposal is described in draft-theimer-tcrtp-mpls-00.txt. Its > >efficiency is much better than the "simple" end-end compression, but it is > >of course much more complex to process. However, since the compression is > >done very close to the source, this may still be acceptable (anyway, if > >the source is connected to the bottleneck link, it makes no difference if > >compression is one-hop or end-end). One might even link the state of VoIP > >calls to the compression context if desired. Eric's issue with not knowing > >higher layer protocols is also a non-issue with end-end compression. > > > >My interpretation of this "consensus" thread is that there is more support > >for end-end compression than there is for one-hop compression with MPLS. > >Please correct me if I'm way off here. > > > >Thomas From owner-mpls@UU.NET Mon Jul 24 12:20: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 MAA10273 for ; Mon, 24 Jul 2000 12:20:51 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizgb10586; Mon, 24 Jul 2000 16:20:17 GMT Received: by mail-control.mail.uu.net id QQizgb05031 for mpls-outgoing; Mon, 24 Jul 2000 16:19: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 QQizgb05026 for ; Mon, 24 Jul 2000 16:19: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 QQizgb21346 for ; Mon, 24 Jul 2000 12:19:35 -0400 (EDT) Received: from griffin.host4u.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: griffin.host4u.net [209.150.128.163]) id QQizgb09944 for ; Mon, 24 Jul 2000 16:19:35 GMT Received: from toy.labn.net (jgateadsl.cais.net [205.252.5.196]) by griffin.host4u.net (8.8.5/8.8.5) with ESMTP id LAA17125; Mon, 24 Jul 2000 11:13:01 -0500 Message-Id: <4.3.2.7.2.20000724120952.00bb8ef0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 12:13:08 -0400 To: Theimer Thomas From: Lou Berger Subject: RE: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Cc: "'Lou Berger'" , George Swallow , "MPLS Mailing List (E-mail)" In-Reply-To: <3B59676F9ADBD211B5360060086E64EECC01BC@MCHH237E> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Thomas, Sounds like a great starting place for an in-session discussion. I suspect the answer is going to be that different assumptions are valid for different networks, thus we'll need different (or a set of) solutions. (Just like for IP header compression.) Even if we don't get onto the agenda we should figure out someway to have some of this discussion next week. Lou PS I'm out of the office the rest of the week, so my response time will likely be slow. At 05:58 PM 7/24/00 +0200, Theimer Thomas wrote: >Lou, > >I agree that there are some tradeoffs to be made regarding complexity and >bandwidth efficiency. My take on this is: > >- if you can do header compression for the link connected to a voice >gateway, complexity is the same for one-hop or end-end compression, if you >use the same compression technique. So you can also do end-end compression >without adding more complexity. > >- as you said, packet loss is a problem for current RTP header >compression. My assumption was that the LSP carrying voice can be >constrained such that packet loss is virtually eliminated, so the problem >does not occur. Isn't that one of the reasons for putting voice onto MPLS >in the first place ? Assuming that packet loss is sufficiently rare, a >larger round trip delay (read: more RTP packets lost due to context >mismatch) should not be too critical. A voice gateway could also do some >intelligent things to fill the gaps when packets are lost, so the voice >application may not even notice any difference. > >- if packet loss cannot be eliminated, use a more robust header >compression scheme to be defined by ROHC folks. > >- if that still doesn't work, or you can't tolerate the complexity, use >simple header compression. > >I guess we can now argue if the above assumptions are reasonable or if >simple header compression is the only way to make this work. > >Thomas > > > -----Original Message----- > > Lou Berger [SMTP:lberger@labn.net] wrote: > > Thomas, > > Thanks for pointing this out, I hadn't noticed it. As you say in > > your message, this proposal brings in more of the tradeoffs considered in > > the -simple draft. Some of us had talked about this approach. I think > the > > simple draft captures some of the rational behind not following the > > approach you propose. > > > > Sophisticated header compression techniques rely on feedback to > > achieve resynchronization. When packets are lost, the compressor and > > decompressor must resynchronize. For an application such as voice > > over IP in the wide-area, the time necessary to achieve such > > resynchronization may be longer than the voice application can > > tolerate. > > > > Another consideration is the bandwidth verses processing trade-off. > > In many prospective environments it may be desirable to trade a small > > amount of compression efficiency for a less processing intense (and > > thus more scalable) compression technique. For example, a voice > > gateway may be called upon to compress and decompress many flows. > > > > We propose a simple header compression technique which requires no > > resynchronization and a relatively light per packet processing load. > > > > More generally, given that IP header compression has been found to be > > useful both in the one-hop cases and now in the multi-hop case, I think we > > should be open to both approaches for MPLS. There are many different ways > > that, and places where, folks are envisioning using compression. > > > > In terms of consensus I think we have: > > > > (a) that one-hop and multi-hop compression are things that the WG should > > address (from Adelaide.) > > > > (b) that some would like to see an approach that maximizes compression > > (from Adelaide and list.) > > > > (c) That some would like to see an approach that operates > > multi-hop/end-to-end and is more scalable (from Adelaide and list.) > > > > (d) (Lou's interpretation of list comments) That the proposed one-hop > > solution is acceptable as long as its usage is well constrained. > > (My proposal is "recommended for use on links where IP Header Compression > > [RFC2507, 2508] is, or can be used" or "not recommend for use on links > > where IP Header Compression [RFC2507, 2508] could not or would not be > used" > > depending on if the groups wants it in the positive or negative form.) > > > > I don't think we've made much headway, beyond Adelaide on the multi-hop > > approach. > > > > At this point, I think some in-session time would be useful in gauging > > consensus. > > > > > > > > Vijay, George, > > > > Oh WG chairs, is there a chance of getting some time? > > > > If you think we're close / have some consensus (and don't need to discuss > > this next week), could you tell us what it is! > > > > Thanks, > > Lou > > > > At 02:50 PM 7/24/00 +0200, Theimer Thomas wrote: > > >Lou, > > > > > >I just wanted to point out that there is another proposal on the table > for > > >end-end compression with MPLS that doesn't even require any changes to > > >existing header compression mechanisms. All that is needed is carrying > PPP > > >over MPLS. You can then run any header compression offered by PPP end-end > > >over MPLS (be it RFC 2508/2509 or robust HC or any other scheme). You can > > >even run header compression over non-PPP links (e.g. Ethernet) if they > can > > >support MPLS. > > > > > >The proposal is described in draft-theimer-tcrtp-mpls-00.txt. Its > > >efficiency is much better than the "simple" end-end compression, but > it is > > >of course much more complex to process. However, since the compression is > > >done very close to the source, this may still be acceptable (anyway, if > > >the source is connected to the bottleneck link, it makes no difference if > > >compression is one-hop or end-end). One might even link the state of VoIP > > >calls to the compression context if desired. Eric's issue with not > knowing > > >higher layer protocols is also a non-issue with end-end compression. > > > > > >My interpretation of this "consensus" thread is that there is more > support > > >for end-end compression than there is for one-hop compression with MPLS. > > >Please correct me if I'm way off here. > > > > > >Thomas From owner-mpls@UU.NET Mon Jul 24 12:30: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 MAA13525 for ; Mon, 24 Jul 2000 12:30:06 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizgb05643; Mon, 24 Jul 2000 16:29:41 GMT Received: by mail-control.mail.uu.net id QQizgb06142 for mpls-outgoing; Mon, 24 Jul 2000 16:29:10 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQizgb06130 for ; Mon, 24 Jul 2000 16: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 QQizgb08766 for ; Mon, 24 Jul 2000 12:28:36 -0400 (EDT) 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 QQizgb16174 for ; Mon, 24 Jul 2000 16:28:20 GMT Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 24 Jul 2000 17:27:58 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2C9C35@monk.datcon.co.uk> From: Adrian Farrel To: Kireeti Kompella , tnadeau@cisco.com Cc: arun@force10networks.com, csrinivasan@tachion.com, mpls@UU.NET, swallow@cisco.com Subject: RE: draft-kompella-mpls-te-mib-00.txt Date: Mon, 24 Jul 2000 17:27:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Kireeti, I must say that the arrival of your draft for a TE MIB worries me conflicting as it does with the work that the WG has been pursuing for the last couple of years. Could you comment on what function your draft offers over and above the WG draft? Are you proposing this - in place of the WG efforts - in parallel to the WG efforts so that we end up with a choice of MIBs - as a way of getting your functional additions incorporated into the WG MIBs? Regards, Adrian -- Adrian Farrel mailto:af@datcon.co.uk Network Convergence Group Data Connection Ltd., Chester, UK http://www.datcon.co.uk/ Tel: +44 (0) 1244 313440 Fax: +44 (0) 1244 312422 >-----Original Message----- >From: Kireeti Kompella [mailto:kireeti@juniper.net] >Sent: Monday, July 17, 2000 8:36 PM >To: kireeti@juniper.net; tnadeau@cisco.com >Cc: arun@force10networks.com; csrinivasan@tachion.com; mpls@UU.NET; >swallow@cisco.com >Subject: Re: draft-kompella-mpls-te-mib-00.txt > > >Hi Tom, > >> I am writing to you today to ask you >> about draft-kompella-mpls-te-mib-00.txt. Are >> you aware that there has been an MPLS Traffic >> Engineering MIB working group document for >> roughly 2 years now? After giving your >> document a quick read, it appears to >> cover most of what is contained in the LSR >> and TE MIBs. At this point The MPLS LSR MIB >> has cleared WG Last Call and the TE MIB is >> getting very close. > >I am aware of the TE/LSR MIBs. I tracked them for a while. >The MIB I submitted was *implemented* in Nov 1998, updated in >May 1999 to add traps, and has otherwise changed very little. >It is being used in several production networks. I have had >several favorable comments (and of course some requests for >changes), and some have asked me to propose it as an ID. > >> What are your intentions for this >> new document? > >I have submitted it to the Traffic Engineering WG. > >Kireeti. > From owner-mpls@UU.NET Mon Jul 24 13:00: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 NAA23863 for ; Mon, 24 Jul 2000 13:00:30 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizgd27987; Mon, 24 Jul 2000 16:59:43 GMT Received: by mail-control.mail.uu.net id QQizgd09092 for mpls-outgoing; Mon, 24 Jul 2000 16:59:10 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQizgd09084 for ; Mon, 24 Jul 2000 16:59:06 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizgd28796 for ; Mon, 24 Jul 2000 12:58:55 -0400 (EDT) Received: from jasmine1.ad.jasminenetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQizgd27315 for ; Mon, 24 Jul 2000 16:58:54 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2650.21) id <392LG46K>; Mon, 24 Jul 2000 09:58:47 -0700 Message-ID: From: Bharadwaj Kalahasti To: "'Pratik Shah'" , mpls@UU.NET Subject: RE: Free MPLS RSVP-TE or CR-LDP implementations ?? Date: Mon, 24 Jul 2000 09:58:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Pratik, You can get the free CR-LDP implementation on the Nortel Networks site. It is a good implementation. Here is the site URL, http://www.nortelnetworks.com/products/announcements/mpls/source/index.html. Thanks, Regards, Bharadwaj Kalahasti, Ph: 408-350-3049, e-mail: bharadwa@JasmineNetworks.com. -----Original Message----- From: Pratik Shah [mailto:pms_tech@yahoo.com] Sent: Monday, July 24, 2000 7:57 AM To: mpls@UU.NET Subject: Free MPLS RSVP-TE or CR-LDP implementations ?? Hi there.. Can any one guide me to a free source of either RSVP-TE or CR-LDP MPLS implementation.... Thanks, Pratik. __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ From owner-mpls@UU.NET Mon Jul 24 13:08: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 NAA26515 for ; Mon, 24 Jul 2000 13:08:35 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizge04623; Mon, 24 Jul 2000 17:08:13 GMT Received: by mail-control.mail.uu.net id QQizge21068 for mpls-outgoing; Mon, 24 Jul 2000 17:07: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 QQizge21004 for ; Mon, 24 Jul 2000 17:07: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 QQizge00244 for ; Mon, 24 Jul 2000 13:06:55 -0400 (EDT) Received: from mailrelay.laurelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laurelnetworks.com [206.67.234.84]) id QQizge03626 for ; Mon, 24 Jul 2000 17:06:54 GMT Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id NAA12712; Mon, 24 Jul 2000 13:06:54 -0400 Received: (from jleu@localhost) by localhost.laurelnetworks.com (8.9.3/8.9.3) id NAA09093; Mon, 24 Jul 2000 13:06:54 -0400 Date: Mon, 24 Jul 2000 13:06:53 -0400 From: "James R. Leu" To: Bharadwaj Kalahasti Cc: "'Pratik Shah'" , mpls@UU.NET Subject: Re: Free MPLS RSVP-TE or CR-LDP implementations ?? Message-ID: <20000724130653.A3029@laurelnetworks.com> Reply-To: jleu@laurelnetworks.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from bharadwa@JasmineNetworks.com on Mon, Jul 24, 2000 at 09:58:47AM -0700 Organization: Laurel Networks Sender: owner-mpls@UU.NET Precedence: bulk There is an implementation of RSVP-TE for FreeBSD (w/MPLS forwarding plane): http://www.antd.nist.gov/itg/nistswitch/ There is an impementation of LDP for Linux (w/MPLS forwarding plane): http://nero.doit.wisc.edu/mpls-linux/ There is another MPLS forwarding plane implementation for Linux: http://www.cl.cam.ac.uk/Research/SRG/netos/netx/code/ I hope this helps, Jim -- James R. Leu Software Engineer Laurel Networks, Inc jleu@laurelnetworks.com On Mon, Jul 24, 2000 at 09:58:47AM -0700, Bharadwaj Kalahasti wrote: > Hi Pratik, > You can get the free CR-LDP implementation on the Nortel Networks site. > It is a good implementation. > > Here is the site URL, > http://www.nortelnetworks.com/products/announcements/mpls/source/index.html. > Thanks, > Regards, > Bharadwaj Kalahasti, > Ph: 408-350-3049, > e-mail: bharadwa@JasmineNetworks.com. > > > -----Original Message----- > From: Pratik Shah [mailto:pms_tech@yahoo.com] > Sent: Monday, July 24, 2000 7:57 AM > To: mpls@UU.NET > Subject: Free MPLS RSVP-TE or CR-LDP implementations ?? > > > Hi there.. > > Can any one guide me to a free source of either > RSVP-TE or CR-LDP MPLS implementation.... > > Thanks, > > Pratik. > > __________________________________________________ > Do You Yahoo!? > Get Yahoo! Mail - Free email you can access from anywhere! > http://mail.yahoo.com/ From owner-mpls@UU.NET Mon Jul 24 16:49: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 QAA02398 for ; Mon, 24 Jul 2000 16:49:41 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizgt23533; Mon, 24 Jul 2000 20:49:27 GMT Received: by mail-control.mail.uu.net id QQizgt19321 for mpls-outgoing; Mon, 24 Jul 2000 20:49:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQizgt19310 for ; Mon, 24 Jul 2000 20:48: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 QQizgt22865 for ; Mon, 24 Jul 2000 16:46:59 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQizgt10138 for ; Mon, 24 Jul 2000 20:46:44 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA26261 for ; Mon, 24 Jul 2000 13:46:58 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA15120 for mpls@uu.net; Mon, 24 Jul 2000 16:46:42 -0400 (EDT) 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 QQizgs17918 for ; Mon, 24 Jul 2000 20:39: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 QQizgs21377 for ; Mon, 24 Jul 2000 16:37:34 -0400 (EDT) Received: from newmail6.rediffmail.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [202.54.124.180]) id QQizgs03291 for ; Mon, 24 Jul 2000 20:37:18 GMT Received: (qmail 13079 invoked by uid 510); 24 Jul 2000 20:36:03 -0000 Date: 24 Jul 2000 20:36:03 -0000 Message-ID: <20000724203603.13078.qmail@newmail6.rediffmail.com> MIME-Version: 1.0 To: "mpls@UU.NET" Subject: CR-LDP drafts CC: "raovrn@rediffmail.com" From: "Vadlamani rao" Content-ID: Content-type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have the following questions on CR-LDP drafts and the MIBs ? 1) What are the differences between cr-ldp-04.txt and the previous one (03.txt) in terms of functionality ? 2) Further, the TE MIB (draft-ietf-mpls-te-mib-04.txt) refers to cr-ldp-01.txt in the mplsTeMIB MODULE-IDENTITY description part whereas in other places of the MIB, reference to cr-ldp-03.txt ? It is not consistent in the draft. If there are any changes (as per 1) ), how it impacts the MIB ? I would appreciate if someone answers these questions. Thanks in advance, Regards Rao (raovrn@rediffmail.com) _________________________________________________ Get Your Free Email At, http://www.rediffmail.com Partcipate in crazy Re.1 auctions at http://www.rediff.com/auctions From owner-mpls@UU.NET Mon Jul 24 20:48: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 UAA25567 for ; Mon, 24 Jul 2000 20:48:48 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizhj09681; Tue, 25 Jul 2000 00:48:34 GMT Received: by mail-control.mail.uu.net id QQizhj25176 for mpls-outgoing; Tue, 25 Jul 2000 00:48: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 QQizhj25171 for ; Tue, 25 Jul 2000 00:48:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQizhj12394 for ; Mon, 24 Jul 2000 20:48:09 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQizhj00239 for ; Tue, 25 Jul 2000 00:48:09 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA07688 for mpls@uu.net; Mon, 24 Jul 2000 20:48:08 -0400 (EDT) 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 QQizhj25142 for ; Tue, 25 Jul 2000 00:47: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 QQizhj23934 for ; Mon, 24 Jul 2000 20:47:45 -0400 (EDT) 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 QQizhj09111 for ; Tue, 25 Jul 2000 00:47:44 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA14879; Mon, 24 Jul 2000 20:47:44 -0400 (EDT) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAG03535; Mon, 24 Jul 2000 20:54:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20000724204722.04f83f00@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 20:48:51 -0400 To: "Vadlamani rao" , "mpls@UU.NET" From: "Thomas D. Nadeau" Subject: Re: CR-LDP drafts Cc: "raovrn@rediffmail.com" In-Reply-To: <20000724203603.13078.qmail@newmail6.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >2) Further, the TE MIB (draft-ietf-mpls-te-mib-04.txt) refers to >cr-ldp-01.txt in the mplsTeMIB MODULE-IDENTITY description part whereas in >other places of the MIB, reference to cr-ldp-03.txt ? It is not consistent >in the draft. This was an oversight on our part, and will be corrected in the next draft. >If there are any changes (as per 1) ), how it impacts the MIB ? Not sure. I personally haven't read the new draft. Would any of the draft's authors care to look over the MIB and comment? --Tom From owner-mpls@UU.NET Mon Jul 24 21:10: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 VAA02738 for ; Mon, 24 Jul 2000 21:10:04 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizhk22332; Tue, 25 Jul 2000 01:09:51 GMT Received: by mail-control.mail.uu.net id QQizhk08027 for mpls-outgoing; Tue, 25 Jul 2000 01:09: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 QQizhk08015 for ; Tue, 25 Jul 2000 01:09: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 QQizhk26152 for ; Mon, 24 Jul 2000 21:08:55 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQizhk13193 for ; Tue, 25 Jul 2000 01:08:40 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA09558 for mpls@uu.net; Mon, 24 Jul 2000 21:08:39 -0400 (EDT) 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 QQizhk07815 for ; Tue, 25 Jul 2000 01:08: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 QQizhk14603 for ; Mon, 24 Jul 2000 21:07:59 -0400 (EDT) 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 QQizhk21092 for ; Tue, 25 Jul 2000 01:07:59 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.131.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA16260; Mon, 24 Jul 2000 21:07:58 -0400 (EDT) Received: from tnadeau-pc02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAG03592; Mon, 24 Jul 2000 21:14:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20000724205519.04f7b380@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 21:09:00 -0400 To: Randy Bush , Adrian Farrel From: "Thomas D. Nadeau" Subject: RE: draft-kompella-mpls-te-mib-00.txt Cc: Kireeti Kompella , arun@force10networks.com, csrinivasan@tachion.com, mpls@UU.NET, swallow@cisco.com In-Reply-To: References: <6DEA508A9A0ED31192E80000F6CC176E2C9C35@monk.datcon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Randy, > > Could you comment on what function your draft offers over and above the WG > > draft? > >as far as i can tell, simplicity while retaining the useful function. and i >am a big simplicity fan. I am personally a fan of not reinventing the wheel. As far as I can tell, this new draft really just duplicates at best, a subset of the efforts that the MPLS WG has been making on its own TE/LSR drafts for the past 2 years. In fact, the MPLS WG has recently come to a consensus to close the MPLS-LSR-MIB draft and bring it to the IESG. The MPLS-TE-MIB is still under development in the MPLS WG and we welcome input on its continued progress. --Tom From owner-mpls@UU.NET Mon Jul 24 21:18: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 VAA05479 for ; Mon, 24 Jul 2000 21:18:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizhl27448; Tue, 25 Jul 2000 01:18:05 GMT Received: by mail-control.mail.uu.net id QQizhl09004 for mpls-outgoing; Tue, 25 Jul 2000 01:17: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 QQizhl08993 for ; Tue, 25 Jul 2000 01:17: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 QQizhl26843 for ; Mon, 24 Jul 2000 21:16:06 -0400 (EDT) Received: from red.juniper.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQizhl17621 for ; Tue, 25 Jul 2000 01:15:36 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id SAA00850; Mon, 24 Jul 2000 18:15:05 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id SAA26748; Mon, 24 Jul 2000 18:13:31 -0700 (PDT) Date: Mon, 24 Jul 2000 18:13:31 -0700 (PDT) From: Kireeti Kompella Message-Id: <200007250113.SAA26748@kummer.juniper.net> To: mjork@avici.com, rbush@bainbridge.verio.net Subject: Re: New Internet Draft: TE over Unnumbered Links Cc: kireeti@juniper.net, mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk > i suspect you all need iana considerations sections and have iana > assign the number space. Good point. I'll add IANA considerations in the next rev. Thanks, Kireeti. From owner-mpls@UU.NET Mon Jul 24 21: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 VAA16123 for ; Mon, 24 Jul 2000 21:52:41 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizhn10119; Tue, 25 Jul 2000 01:52:26 GMT Received: by mail-control.mail.uu.net id QQizhn12061 for mpls-outgoing; Tue, 25 Jul 2000 01:52: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 QQizhn12055 for ; Tue, 25 Jul 2000 01:52:03 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizhn19809 for ; Mon, 24 Jul 2000 21:51:59 -0400 (EDT) Received: from sj-msg-core-1.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQizhn17773 for ; Tue, 25 Jul 2000 01:51:58 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA22590 for ; Mon, 24 Jul 2000 18:52:12 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id VAA00422 for mpls@uu.net; Mon, 24 Jul 2000 21:51:56 -0400 (EDT) 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 QQizhh23526 for ; Tue, 25 Jul 2000 00:28:15 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQizhh09871 for ; Mon, 24 Jul 2000 20:28:09 -0400 (EDT) Received: from roam.psg.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: roam.psg.com [147.28.4.2]) id QQizhh17948 for ; Tue, 25 Jul 2000 00:28:08 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 13GsY1-0006SS-00; Mon, 24 Jul 2000 17:26:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Adrian Farrel Cc: Kireeti Kompella , tnadeau@cisco.com, arun@force10networks.com, csrinivasan@tachion.com, mpls@UU.NET, swallow@cisco.com Subject: RE: draft-kompella-mpls-te-mib-00.txt References: <6DEA508A9A0ED31192E80000F6CC176E2C9C35@monk.datcon.co.uk> Message-Id: Date: Mon, 24 Jul 2000 17:26:13 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Could you comment on what function your draft offers over and above the WG > draft? as far as i can tell, simplicity while retaining the useful function. and i am a big simplicity fan. and perhaps, as this is a te mib, the tewg, which is in o&M should be the forum to bash it? randy From owner-mpls@UU.NET Tue Jul 25 04:59:59 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01841 for ; Tue, 25 Jul 2000 04:59:58 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizip19905; Tue, 25 Jul 2000 08:59:35 GMT Received: by mail-control.mail.uu.net id QQizip06719 for mpls-outgoing; Tue, 25 Jul 2000 08:59: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 QQizip06708 for ; Tue, 25 Jul 2000 08:58: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 QQizip17531 for ; Tue, 25 Jul 2000 04:58:28 -0400 (EDT) Received: from red.juniper.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQizip00217 for ; Tue, 25 Jul 2000 08:58:13 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id BAA23264; Tue, 25 Jul 2000 01:58:12 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id BAA27610; Tue, 25 Jul 2000 01:56:37 -0700 (PDT) Date: Tue, 25 Jul 2000 01:56:37 -0700 (PDT) From: Kireeti Kompella Message-Id: <200007250856.BAA27610@kummer.juniper.net> To: kireeti@juniper.net, rahul@redback.com Subject: Re: New Internet Draft: TE over Unnumbered Links Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi Rahul, > A couple of comments: > > 1. Maybe there is a need to enhance the semantics of the RSVP_HOP object > to work over unnumbered links. The ip address of the previous hop > could be set to the router id of the previous hop. In our first pass at this draft, the ERO subobject included both a router ID (of the PHOP) and the interface index. We then decided that just the interface index is sufficient; see below. > 2. This is more of a clarification. Consider: > A----------B-----------C > Ia Ib Ic > > The link from B to C is unnumbered. My understanding from the draft is > that B will generate the interface id for Ic. (and C for Ib) Is that correct? B will indeed generate the interface id Ic, but C has nothing to do with Ib (as I see your picture). > The ero could be . Since B generated the id for Ic, it will know the > outgoing interface to send the path msg to C. > C will receive the ero as . Now C needs to check the ero to see if > it belongs to the first subobject i.e. Ic. How should this check be done? > This goes back to (1) above. I assume that C can tell which LSR it got the path msg from (i.e., B). C then looks to see in its TE link state database if B is advertising a link to C with index Ic. (I will add this to the next rev.) One could be more paranoid and add a router ID to the unnumbered ERO subobject. Then the check is: a) does the router ID of the LSR sending the path msg match the router ID in the subobject? AND b) if so, is that LSR advertising a link to me with the index in the subobject (Ic)? This approach is slightly more likely to catch errors because there are two checks. Suppose for example A sent the first Path message to D (by mistake) AND D didn't catch this error. Suppose also that D has an unnumbered link to C with index Ic (same as B's). Now, when C gets the path msg from D (without the router ID), it will erroneously accept it. However, for this to happen: A made a mistake; D missed the mistake; and D had the same ifindex to C as B did. Thanks for your comments! Kireeti. From owner-mpls@UU.NET Tue Jul 25 07:55: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 HAA16899 for ; Tue, 25 Jul 2000 07:55:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizjb14322; Tue, 25 Jul 2000 11:54:38 GMT Received: by mail-control.mail.uu.net id QQizjb25420 for mpls-outgoing; Tue, 25 Jul 2000 11:54:15 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQizjb25415 for ; Tue, 25 Jul 2000 11:54:13 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQizjb05559 for ; Tue, 25 Jul 2000 07:53:47 -0400 (EDT) Received: from ind.alcatel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: postal.xylan.com [208.8.0.248]) id QQizjb03149 for ; Tue, 25 Jul 2000 11:53:32 GMT Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id EAA18424 for ; Tue, 25 Jul 2000 04:53:31 -0700 (PDT) X-Origination-Site: Received: from k2.indc.xylan.com (indc.xylan.com [10.148.12.1]) by mailhub.ind.alcatel.com (8.8.8+Sun/8.8.8 (mailhub 3.2 [HUB])) with ESMTP id EAA02736; Tue, 25 Jul 2000 04:53:16 -0700 (PDT) Received: from ind.alcatel.com (mickey [10.148.16.18]) by k2.indc.xylan.com (8.8.8+Sun/8.8.8 (India 2.0 [SPOOL])) with ESMTP id EAA04690; Tue, 25 Jul 2000 04:53:13 -0700 (PDT) Message-ID: <397D7FA8.F707F26@ind.alcatel.com> Date: Tue, 25 Jul 2000 17:23:12 +0530 From: Pramoda Nallur Reply-To: Pramoda.Nallur@ind.alcatel.com Organization: Alcatel Internetworking Division, INDIA X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: Dilip.Pandit@ind.alcatel.com, Kishore Rao , Pramoda Nallur , Manu.Prakash@ind.alcatel.com Subject: Reg. MPLS-RSVP LSP Tunnels... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a query on setting up RSVP MPLS LSPs in an ATM network. [ Topology Driven LSP Setup Scenario ] Suppose the network configuration is as follows : S--A--LER1---LSR---LER2--B--R where, S --> Sender(RSVP aware) R --> Receiver(RSVP aware) A, B --> Legacy IP Routers LER1, LER2 and LSR --> MPLS-RSVP ATM switches. An LSP setup is initiated from LER1 with FEC=(S,R). The RSVP-TE PATH msg (with Sender=S, Session = Sess_R) creates an RSVP Session, Sess_R at LER1, LSR and LER2. The Egress LER2 responds with a RSVP-TE RESV msg reserving resources and sets up an LSP via LSR to LER1. After the LSP is setup, the RSVP-TE PATH msgs from LER1 and RSVP-TE RESV msgs from LER2 periodically refresh the RSVP reservation state on all nodes along the LSP. Suppose, Sender S sends an RSVP PATH msg to R (with Session = Sess_R). 1. Will this PATH msg take the unlabelled path OR will it get switched onto the LSP at LER1 ? 2. Also, how are the resulting RESV msgs from R propagated back to S ? 3. If these PATH and RESV msgs take the unlabelled path, will this result in resource allocation again along all nodes traversed by the LSP ? The "RSVP-TE: Extensions to RSVP for LSP Tunnels" (draft-ietf-mpls-rsvp-lsp-tunnel-06.txt) does not mention how the above should be handled. Any comments on this ? - Pramoda Nallur From owner-mpls@UU.NET Tue Jul 25 09:01: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 JAA06496 for ; Tue, 25 Jul 2000 09:01:03 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizjg25433; Tue, 25 Jul 2000 13:00:45 GMT Received: by mail-control.mail.uu.net id QQizjg12351 for mpls-outgoing; Tue, 25 Jul 2000 13:00:15 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQizjg11735 for ; Tue, 25 Jul 2000 13:00:07 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQizjg09413 for ; Tue, 25 Jul 2000 09:00:03 -0400 (EDT) Received: from alvin.loniis.spb.su by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: gw1.loniis.spb.su [195.201.37.253]) id QQizjf16523 for ; Tue, 25 Jul 2000 12:59:55 GMT Received: from inser.loniis.spb.su (inser.loniis.spb.su [195.201.37.61]) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id e6PCxrW21562 for ; Tue, 25 Jul 2000 16:59:53 +0400 (MSD) Received: from af.ten.loniis.int ([192.168.10.65]) by inser.loniis.spb.su (8.9.3/8.9.3) with SMTP id QAA16331 for ; Tue, 25 Jul 2000 16:59:51 +0400 (MSD) Message-ID: <000e01bff638$2a3856c0$410aa8c0@ten.loniis.int> From: "Andrey Philippov" To: Subject: MPOA and MPLS interaction Date: Tue, 25 Jul 2000 16:59:26 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01BFF659.B0682240" 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 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000B_01BFF659.B0682240 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, all I have one question: How two networks can interoperate, in following case - one network use a = MPOA as a basic technology to transfer IP traffic over ATM, second = network - MPLS technology. Regards, Andrey ------=_NextPart_000_000B_01BFF659.B0682240 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi, all
 
I have one question:
 
How two networks can interoperate, in = following=20 case - one network use a MPOA as a basic technology to = transfer IP=20 traffic over ATM, second network - MPLS technology.
 
Regards, Andrey
 
 
 
------=_NextPart_000_000B_01BFF659.B0682240-- From owner-mpls@UU.NET Tue Jul 25 09:20: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 JAA13124 for ; Tue, 25 Jul 2000 09:20:40 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizjh09246; Tue, 25 Jul 2000 13:20:19 GMT Received: by mail-control.mail.uu.net id QQizjh23227 for mpls-outgoing; Tue, 25 Jul 2000 13:19:59 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 QQizjh23217 for ; Tue, 25 Jul 2000 13:19: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 QQizjh12537 for ; Tue, 25 Jul 2000 09:19:31 -0400 (EDT) Received: from iol.unh.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mars.iol.unh.edu [132.177.121.222]) id QQizjh08315 for ; Tue, 25 Jul 2000 13:19:16 GMT Received: from localhost (jzou@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id JAA25515; Tue, 25 Jul 2000 09:19:08 -0400 (EDT) Date: Tue, 25 Jul 2000 09:19:08 -0400 From: Jie Zou To: Pramoda Nallur cc: mpls@UU.NET, Dilip.Pandit@ind.alcatel.com, Kishore Rao , Manu.Prakash@ind.alcatel.com Subject: Re: Reg. MPLS-RSVP LSP Tunnels... In-Reply-To: <397D7FA8.F707F26@ind.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I hope the following can answer a part of questions. According the darft, if A or B is a non-RSVP router, it can't convey labels via RSVP path. And it's neighber who knows it's non-RSVP router should send a PathErr back to the sender. If A or B is an RSVP router but doesn't recognize the LRO, it should send a PathErr toward the sender. If A or B is an RSVP router and recognize the LRO but not C_TYPE also sends a PathErr toward the sender. Else the Path msg should pass A and B toward the receiver and vice verse the Resv msg should pass the B and A toward the sender. Regards, ----------------------------------------------------- Jie Zou (603)862-4212(Office) MPLS Consortium IOL, UNH (603)868-2983(Home) ----------------------------------------------------- On Tue, 25 Jul 2000, Pramoda Nallur wrote: > Hi, > > I have a query on setting up RSVP MPLS LSPs in an ATM network. > [ Topology Driven LSP Setup Scenario ] > > Suppose the network configuration is as follows : > > S--A--LER1---LSR---LER2--B--R > > where, > S --> Sender(RSVP aware) > R --> Receiver(RSVP aware) > A, B --> Legacy IP Routers > LER1, LER2 and LSR --> MPLS-RSVP ATM switches. > > An LSP setup is initiated from LER1 with FEC=(S,R). > > The RSVP-TE PATH msg (with Sender=S, Session = Sess_R) creates an > RSVP Session, Sess_R at LER1, LSR and LER2. The Egress LER2 responds with a > > RSVP-TE RESV msg reserving resources and sets up an LSP via LSR to LER1. > > After the LSP is setup, the RSVP-TE PATH msgs from LER1 and RSVP-TE RESV > msgs > from LER2 periodically refresh the RSVP reservation state on all nodes > along the LSP. > > Suppose, Sender S sends an RSVP PATH msg to R (with Session = Sess_R). > > 1. Will this PATH msg take the unlabelled path OR will it get switched > onto the LSP at LER1 ? > > 2. Also, how are the resulting RESV msgs from R propagated back to S ? > > 3. If these PATH and RESV msgs take the unlabelled path, will this result > in > resource allocation again along all nodes traversed by the LSP ? > > > The "RSVP-TE: Extensions to RSVP for LSP Tunnels" > (draft-ietf-mpls-rsvp-lsp-tunnel-06.txt) > does not mention how the above should be handled. > > Any comments on this ? > > - Pramoda Nallur > From owner-mpls@UU.NET Tue Jul 25 09:42: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 JAA18959 for ; Tue, 25 Jul 2000 09:42:30 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizji14931; Tue, 25 Jul 2000 13:42:15 GMT Received: by mail-control.mail.uu.net id QQizji24928 for mpls-outgoing; Tue, 25 Jul 2000 13:41: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 QQizji24917 for ; Tue, 25 Jul 2000 13:41:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizji19649 for ; Tue, 25 Jul 2000 09:38:19 -0400 (EDT) From: Ted44tedT@netscape.net Received: from imo-d03.mx.aol.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: imo-d03.mx.aol.com [205.188.157.35]) id QQizji22315 for ; Tue, 25 Jul 2000 13:38:03 GMT Received: from Ted44tedT@netscape.net by imo-d03.mx.aol.com (mail_out_v27.12.) id 1.3.506c1 (16229) for ; Tue, 25 Jul 2000 09:38:02 -0400 (EDT) Received: from netscape.com (aimmail01.aim.aol.com [205.188.144.193]) by air-in02.mx.aol.com (v75_b1.4) with ESMTP; Tue, 25 Jul 2000 09:38:02 -0400 Message-ID: <3A34A6BF.5E16033D.02882A9A@netscape.net> Date: Tue, 25 Jul 2000 09:36:42 -0400 To: mpls@UU.NET X-Mailer: Franklin Webmailer 1.0 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, Quick question: How can I get all tutorials on website www.nanog.org like mpls etc.? Thanks in advance Regards, Ted ---------- Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ From owner-mpls@UU.NET Tue Jul 25 09: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 JAA19720 for ; Tue, 25 Jul 2000 09:45:38 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizjj17139; Tue, 25 Jul 2000 13:45:17 GMT Received: by mail-control.mail.uu.net id QQizji25091 for mpls-outgoing; Tue, 25 Jul 2000 13:44: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 QQizji25083 for ; Tue, 25 Jul 2000 13:44: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 QQizji20262 for ; Tue, 25 Jul 2000 09:41:52 -0400 (EDT) Received: from mailhost.avici.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQizji25300 for ; Tue, 25 Jul 2000 13:41:51 GMT Received: from avici.com (swdev23.avici.com [10.1.2.229]) by mailhost.avici.com (8.8.5/8.8.4) with ESMTP id JAA09842; Tue, 25 Jul 2000 09:41:46 -0400 (EDT) Message-Id: <200007251341.JAA09842@mailhost.avici.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Markus Jork To: Kireeti Kompella cc: rahul@redback.com, mpls@UU.NET Subject: Re: New Internet Draft: TE over Unnumbered Links In-reply-to: Your message of "Tue, 25 Jul 2000 01:56:37 PDT." <200007250856.BAA27610@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Jul 2000 09:41:45 -0400 Sender: owner-mpls@UU.NET Precedence: bulk Kireeti/Rahul, now you are confusing me. I thought the draft was pretty clear (although too concise). [...] > In our first pass at this draft, the ERO subobject included both a > router ID (of the PHOP) and the interface index. We then decided > that just the interface index is sufficient; see below. > > > 2. This is more of a clarification. Consider: > > A----------B-----------C > > Ia Ib Ic > > > > The link from B to C is unnumbered. My understanding from the draft is > > that B will generate the interface id for Ic. (and C for Ib) Is that > > correct? > > B will indeed generate the interface id Ic, but C has nothing to do > with Ib (as I see your picture). > > > The ero could be . Since B generated the id for Ic, it will know the > > outgoing interface to send the path msg to C. > I thought it works like this: A----------B----------C---------D A1 B1 Ib Ic A-B is a numbered link, B-C and C-D are unnumbered. A1 and B1 are the interface addresses, Ib and Ic are the interface IDs and A, B, C and D are the router IDs. Then, the ERO sent by A would be: B1 Ib C Ic D (or replace B1 with B) Router B would then forward this ERO: C Ic D Router C would then forward this ERO: D This should work just fine and I thought it's what the draft says. Every router can verify whether it's the first subobject in the ERO and knows where to go next. The only problem is filling in the RRO in the Resv message going back. One alternative is to make router C add "C Ic" to the RRO. It would know Ic from the LIH in the NHOP object of the Resv message. The other alternative is to make router C add "Ib C" to the RRO. It would have to look up Ib in the link state database. The second alternative is probably the right thing to do. Markus > > C will receive the ero as . Now C needs to check the ero to see if > > it belongs to the first subobject i.e. Ic. How should this check be done? > > This goes back to (1) above. > > I assume that C can tell which LSR it got the path msg from (i.e., B). > C then looks to see in its TE link state database if B is advertising > a link to C with index Ic. (I will add this to the next rev.) > > One could be more paranoid and add a router ID to the unnumbered ERO > subobject. Then the check is: a) does the router ID of the LSR sending > the path msg match the router ID in the subobject? AND b) if so, is > that LSR advertising a link to me with the index in the subobject (Ic)? > This approach is slightly more likely to catch errors because there are > two checks. Suppose for example A sent the first Path message to D (by > mistake) AND D didn't catch this error. Suppose also that D has an > unnumbered link to C with index Ic (same as B's). > > Now, when C gets the path msg from D (without the router ID), it will > erroneously accept it. However, for this to happen: A made a mistake; > D missed the mistake; and D had the same ifindex to C as B did. > > Thanks for your comments! > > Kireeti. > From owner-mpls@UU.NET Tue Jul 25 10:32: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 KAA06318 for ; Tue, 25 Jul 2000 10:32:57 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizjm21185; Tue, 25 Jul 2000 14:32:46 GMT Received: by mail-control.mail.uu.net id QQizjm09819 for mpls-outgoing; Tue, 25 Jul 2000 14:32:23 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQizjm09803 for ; Tue, 25 Jul 2000 14:32:13 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizjm28472 for ; Tue, 25 Jul 2000 10:31:23 -0400 (EDT) Received: from mail.erlangtech.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: www.erlangtech.com [209.145.148.2]) id QQizjm03413 for ; Tue, 25 Jul 2000 14:31:07 GMT Received: from erlangtech.com ([64.19.21.122]) by mail.erlangtech.com (8.9.3/8.9.3) with ESMTP id JAA29609; Tue, 25 Jul 2000 09:25:59 -0500 Message-ID: <397DA457.69DCE609@erlangtech.com> Date: Tue, 25 Jul 2000 09:29:44 -0500 From: Nasser Yazdani Reply-To: nassery@erlangtech.com X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MPLS Subject: A question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, does anybody knows how to map the DiffServ classes (64 classes) into the MPLS exp. fields (8 classes). Thanks, Regards, -- Nasser From owner-mpls@UU.NET Tue Jul 25 10:43: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 KAA10218 for ; Tue, 25 Jul 2000 10:43:39 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizjm29213; Tue, 25 Jul 2000 14:43:21 GMT Received: by mail-control.mail.uu.net id QQizjm10969 for mpls-outgoing; Tue, 25 Jul 2000 14:42: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 QQizjm10933 for ; Tue, 25 Jul 2000 14:42: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 QQizjm27062 for ; Tue, 25 Jul 2000 10:42:06 -0400 (EDT) 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 QQizjm11667 for ; Tue, 25 Jul 2000 14:42:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA02412 for mpls@uu.net; Tue, 25 Jul 2000 10:42:05 -0400 (EDT) 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 QQizjm10871 for ; Tue, 25 Jul 2000 14:41:32 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizjm00080 for ; Tue, 25 Jul 2000 10:40:44 -0400 (EDT) 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 QQizjm10302 for ; Tue, 25 Jul 2000 14:40:28 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 HAA02980 for ; Tue, 25 Jul 2000 07:40:27 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jul 2000 07:42:36 -0700 Message-ID: <336ECDAFDF7DD311B9E30090277AEE4101B406B5@nt-exchange-bby.pmc-sierra.bc.ca> From: Shahram Davari To: "'mpls@UU.net'" Subject: MPLS+ICMP Date: Tue, 25 Jul 2000 07:42:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Does anybody have the following draft, which is expired: draft-ietf-mpls-icmp-02.txt Thanks, Shahram Davari Systems Engineer Product Research PMC-Sierra, Inc. (Ottawa) 555 Legget drive, Suit 834, Tower B, Ottawa, ON K2K 2X3, Canada Phone: +1 (613) 271-4018 Fax : +1 (613) 271-7007 From owner-mpls@UU.NET Tue Jul 25 11:33:30 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29094 for ; Tue, 25 Jul 2000 11:33:30 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizjq05060; Tue, 25 Jul 2000 15:33:15 GMT Received: by mail-control.mail.uu.net id QQizjq27921 for mpls-outgoing; Tue, 25 Jul 2000 15:32:22 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 QQizjq27916 for ; Tue, 25 Jul 2000 15:32:16 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQizjq06199 for ; Tue, 25 Jul 2000 11:32:06 -0400 (EDT) Received: from NOD.RESTON.MCI.NET by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [166.60.6.38]) id QQizjq04072 for ; Tue, 25 Jul 2000 15:32:05 GMT Received: from BONI ([166.60.14.229]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JS6L39D9US9N44UG@shoe.reston.mci.net> for mpls@UU.NET; Tue, 25 Jul 2000 11:32:05 EST Date: Tue, 25 Jul 2000 11:31:35 -0500 From: Ron Bonica Subject: RE: MPLS+ICMP In-reply-to: <336ECDAFDF7DD311B9E30090277AEE4101B406B5@nt-exchange-bby.pmc-sierra.bc.ca> To: Shahram Davari , "'mpls@UU.net'" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/mixed; boundary="Boundary_(ID_M4UYp9+K7OP+TJPfPMmV/Q)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_M4UYp9+K7OP+TJPfPMmV/Q) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Shahram, A copy of the draft is attached. Note that that there is a small problem on the figure in Section 6.4. The text in the figure does not match the text in the section. The text in the figure should read "Additional Bytes of Message Body". George, Vijay, Is there anything that I need to do to progress this draft or at least unexpire it. It has already passed WG last call. Ron > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram > Davari > Sent: Tuesday, July 25, 2000 9:43 AM > To: 'mpls@UU.net' > Subject: MPLS+ICMP > > > Hi, > > Does anybody have the following draft, which is expired: > > draft-ietf-mpls-icmp-02.txt > > Thanks, > > Shahram Davari > Systems Engineer > Product Research > PMC-Sierra, Inc. (Ottawa) > 555 Legget drive, > Suit 834, Tower B, > Ottawa, ON K2K 2X3, Canada > Phone: +1 (613) 271-4018 > Fax : +1 (613) 271-7007 > > > > --Boundary_(ID_M4UYp9+K7OP+TJPfPMmV/Q) Content-type: text/plain; name=draft-ietf-mpls-icmp-01.txt.txt Content-disposition: attachment; filename=draft-ietf-mpls-icmp-01.txt.txt Content-Transfer-Encoding: 7BIT MPLS Working Group R.Bonica Internet Draft MCIWorldCom Document: draft-ietf-mpls-icmp-01.txt D.Tappan Cisco Systems D.Gan Juniper Networks December 1999 ICMP Extensions for MultiProtocol Label Switching Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC-2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The current memo proposes extensions to ICMP that permit Label Switching Routers to append MPLS information to ICMP messages. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 3. Introduction Routers and destination hosts use the Internet Control Message Protocol (ICMP) [RFC-792] to convey control information to source hosts. Network operators use this information to diagnose routing problems. Bonica, Tappan, Hwa Draft-Expires May 2000 1 ICMP Extensions for MPLS December 1999 When a router receives an undeliverable IP datagram, it can send an ICMP message to the host that originated the datagram. The ICMP message indicates why the datagram could not be delivered. It also contains the IP header and leading payload octets of the "original datagram". In this document, the term "original datagram" refers to the datagram to which the ICMP message is a response. MPLS Label Switching Routers (LSR) also use ICMP to convey control information to source hosts. Sections 2.3 and 2.4 of [ENCODE] describe the interaction between MPLS and ICMP. When an LSR receives an undeliverable MPLS encapsulated datagram, it removes the entire MPLS label stack, exposing the previously encapsulated IP datagram. The LSR then submits the IP datagram to a network-forwarding module for error processing. Error processing can include ICMP message generation. The ICMP message indicates why the original datagram could not be delivered. It also contains the IP header and leading octets of the original datagram. The ICMP message, however, includes no information regarding the MPLS label stack that encapsulated the original datagram when it arrived at the LSR. This omission is significant because the LSR would have routed the original datagram based upon information contained by the MPLS label stack. The current memo proposes extensions to ICMP that permit an LSR to append MPLS label stack information to ICMP messages. ICMP messages regarding MPLS encapsulated datagrams SHOULD include the MPLS label stack, as it arrived at the router that is sending the ICMP message. The ICMP message MUST also include the IP header and leading payload octets of the original datagram. Network operators will use this information to diagnose routing problems. 4. Motivation ICMP extensions defined in the current memo support enhancements to TRACEROUTE. The enhanced TRACEROUTE, like older implementations, indicates which nodes the original datagram visited en route to its ultimate destination. It differs from older implementations in that it also indicates the original datagrams MPLS encapsulation status as it arrived at each node. Figure 1 contains sample output from an enhanced TRACEROUTE implementation. Bonica,Tappan,Gan Draft-Expires May 2000 2 ICMP Extensions for MPLS December 1999 >Traceroute 166.45.2.74 traceroute to 166.45.2.74, 30 hops max, 40 byte packets 1 166.45.5.1 1.281 ms 1.103 ms 1.096 ms 2 166.45.4.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2001 mplsExpBits1=0 3 166.45.3.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2002 mplsExpBits1=0 4 166.45.6.1 1.281 ms 1.103 ms 1.096 ms mplsLabel1=2003 mplsExpBits1=0 5 166.45.2.1 1.281 ms 1.103 ms 1.096 ms 6 166.45.2.74 1.281 ms 1.103 ms 1.096 ms Figure 1. Enhanced TRACEROUTE sample output 5. Disclaimer The current memo does not define the general relationship between ICMP and MPLS. Sections 2.3 and 2.4 of [ENCODE] define this relationship. Specifically, this document defers to [ENCODE] with respect to the following issues: - conditions upon which an LSR emits ICMP messages - handling of ICMP messages bound for hosts that are identified by private addresses The current memo does not define encapsulation specific TTL manipulation procedures. It defers to Section 10 of [MPLSATM] and Section 5.4 of [MPLSFRAME] in this matter. When encapsulation specific TTL manipulation procedures defeat the basic TRACEROUTE mechanism, they will also defeat enhanced TRACEROUTE implementations. The current memo does not address extensions to ICMPv6. These should be addressed in a separate draft. 6. Formal Syntax This section defines a data structure that an LSR can append to selected ICMP messages. The data structure contains the MPLS label stack that encapsulated the original datagram when it arrived at the LSR. The data structure defined herein can be appended to the following ICMP message types: Bonica,Tappan,Gan Draft-Expires May 2000 3 ICMP Extensions for MPLS December 1999 1) Destination Unreachable 2) Time Exceeded 3) Parameter Problem 4) Source Quench 5) Redirect According to RFC-792, the final field contained by each of these ICMP message types reflects the IP header and leading 64 bits of the original datagram. [RFC-1812] recommends that this final field be extended to include as much of the original datagram as possible. When an LSR appends the data structure defined herein to an ICMP message, the final field of the ICMP message body MUST contain the first 128 octets of the original datagram. At least 20 of these 128 octets represent the IP header of the original datagram. If the original datagram was shorter than 128 octets, the final field MUST be padded with 0's. When an LSR appends the data structure defined herein to an ICMP message, the ICMP "total length" MUST be equal to the data structure length plus 156. The first octet of the data structure must be displaced 156 octets from the beginning of the ICMP message. The data structure defined in this section consists of a common header followed by object instances. Each object instance consists of an object header plus contents. Currently, two object classes are defined. One object class contains an entire MPLS label stack, formatted exactly as it was when it arrived at the LSR that sends the ICMP message. The other contains some portion of the original datagram that could not be included in the final field of the ICMP message body (i.e., the octet 129 and beyond). Both object classes are optional. In the future, additional object classes may be defined. 6.1 Common Header 0 1 2 3 +-------------+-------------+-------------+-------------+ | Vers | (Reserved) | Checksum | +-------------+-------------+-------------+-------------+ The fields in the common header are as follows: Bonica,Tappan,Gan Draft-Expires May 2000 4 ICMP Extensions for MPLS December 1999 Vers: 4 bits ICMP extension version number. This is version 2. Checksum: 16 bits The one's complement of the one's complement sum of the data structure, with the checksum field replaced by zero for the purpose of computing the checksum. An all-zero value means that no checksum was transmitted. If the checksum field contains a value other than described above, the ICMP message does not include the extensions described in this memo. This, however, does not imply that the ICMP message is malformed. It may be in strict compliance with RFC-1812. Reserved: Must be set to 0. 6.2 Object Header Every object consists of one or more 32-bit words with a one-word header, with the following format: +-------------+-------------+-------------+-------------+ | Length | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | | // (Object contents) // | | | +-------------+-------------+-------------+-------------+ An object header has the following fields: Length: 16 bits Length of the object, measured in octets, including the object header and object contents. Class-Num: 8 bits Identifies object class. C-Type: 8 bits Identifies object sub-type. Bonica,Tappan,Gan Draft-Expires May 2000 5 ICMP Extensions for MPLS December 1999 6.3 MPLS Stack Entry Object Class A single instance of the MPLS Entry Object class represents the entire MPLS label stack, formatted exactly as it was when it arrived at the LSR that sends the ICMP message In the illustration below, octets 0-3 depict the first member of the MPLS label stack. Each remaining member of the MPLS label stack is represented by another 4 octets that share the same format. Syntax follows: MPLS Stack Entry Class = 1, C-Type = 1. 0 1 2 3 +-------------+-------------+-------------+-------------+ | Label |EXP |S| TTL | +-------------+-------------+-------------+-------------+ | | | // Remaining MPLS Stack Entries // | | | +-------------+-------------+-------------+-------------+ Label: 20 bits Exp: Experimental Use, 3 bits S: Bottom of Stack, 1 bit TTL: Time to Live, 8 bits 6.4 Extended Payload Object Class An instance of the Extended Payload Object class represents some portion of the original datagram that could not be fit in the final field of the ICMP message body (i.e., octets beyond 128). Syntax follows: MPLS Stack Entry Class = 2, C-Type = 1. 0 1 2 3 +-------------+-------------+-------------+-------------+ | | | // Remaining MPLS Stack Entries // | | | +-------------+-------------+-------------+-------------+ Bonica,Tappan,Gan Draft-Expires May 2000 6 ICMP Extensions for MPLS December 1999 7. Backward Compatibility ICMP extensions proposed in this document MUST be backward compatible with the syntax described in RFC-792. Extensions proposed in this memo MUST NOT change or deprecate any field defined in RFC- 792. The extensions defined herein are in keeping with the spirit, if not the letter of RFC-1812. In order to support IP-in-IP tunneling, RFC- 1812 extends the final field of selected ICMP messages to include a greater portion of the original datagram. Unfortunately, it extends this field to a variable length without adding a length attribute. This memo binds the length of that final field to an arbitrarily large value (128 octets). Fixing the length of that field facilitates extension of the ICMP message. An additional object is provided through which octets 129 and beyond can be appended to the ICMP message. As few datagrams contain L3 or L4 header information beyond octet 128, it is unlikely that the extensions described herein will disable any applications that rely upon RFC-1812 style ICMP messages. 8. Security Considerations This memo presents no security considerations beyond those already presented by current ICMP applications (e.g., traceroute). 9. References [ARCH], Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", Internet Draft , August, 1999 [ENCODE], Rosen, E., Rekhter, Y., Tappan, D, Farinacci, D., Fedorkow, G., Li, T., Conta, A., "MPLS Stack Encoding", Internet Draft, , September 1999. [FRAME], Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G., and A. Viswanathan, "A Framework for Multiprotocol Label Switching", Internet Draft , September 1999. [MPLSATM], Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G, "MPLS using ATM VC Switching", , November, 1998. Bonica,Tappan,Gan Draft-Expires May 2000 7 ICMP Extensions for MPLS December 1999 [MPLSFRAME], Conta, A., Doolan, P., Malis, A., "Use of Label Switching on Frame Relay Networks", , November, 1998. [RFC-792], Postel, J., "Internet Control Message Protocol", RFC 792, ISI, September 1981. [RFC-1812], Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC-2026], Bradner, S., "Internet Standards Process Revision 3", RFC 2026, Harvard University, October 1996. [RFC-2119], Bradner, S,, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997 10. Acknowledgments Thanks to Yakov Rekhter and Mike Heard for their contributions to this memo. 11. Author's Addresses Ronald P. Bonica MCI WorldCom 22001 Loudoun County Pkwy Ashburn, Virginia, 20147 Phone: 703 886 1681 Email: rbonica@mci.net Daniel C. Tappan Cisco Systems 250 Apollo Drive Chelmsford, Massachusetts, 01824 Email: tappan@cisco.com Der-Hwa Gan Juniper Networks 385 Ravendale Drive Mountain View, California 94043 Email: dhg@juniper.net Bonica,Tappan,Gan Draft-Expires May 2000 8 ICMP Extensions for MPLS December 1999 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Bonica,Tappan,Gan Draft-Expires May 2000 9 --Boundary_(ID_M4UYp9+K7OP+TJPfPMmV/Q)-- From owner-mpls@UU.NET Tue Jul 25 12:03: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 MAA08885 for ; Tue, 25 Jul 2000 12:03:44 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizjs10161; Tue, 25 Jul 2000 16:03:26 GMT Received: by mail-control.mail.uu.net id QQizjs07589 for mpls-outgoing; Tue, 25 Jul 2000 16:02: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 QQizjs06050 for ; Tue, 25 Jul 2000 16:02:28 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 QQizjs10938 for ; Tue, 25 Jul 2000 12:02:26 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQizjs09412 for ; Tue, 25 Jul 2000 16:02:25 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA10887 for ; Tue, 25 Jul 2000 09:02:41 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA00876 for mpls@uu.net; Tue, 25 Jul 2000 12:02:24 -0400 (EDT) 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 QQizjn11846 for ; Tue, 25 Jul 2000 14:48: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 QQizjn28288 for ; Tue, 25 Jul 2000 10:48:53 -0400 (EDT) Received: from www0u.netaddress.usa.net by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: www0u.netaddress.usa.net [204.68.24.50]) id QQizjn03517 for ; Tue, 25 Jul 2000 14:48:53 GMT Received: (qmail 3011 invoked by uid 60001); 25 Jul 2000 14:48:52 -0000 Message-ID: <20000725144852.3010.qmail@www0u.netaddress.usa.net> Received: from 204.68.24.50 by www0u for [203.197.178.232] via web-mailer(34WB1.4.03) on Tue Jul 25 14:48:52 GMT 2000 Date: 25 Jul 00 07:48:52 PDT From: Jahaapanah Alampanah To: mpls@UU.NET Subject: Re: Reg. MPLS-RSVP LSP Tunnels... X-Mailer: USANET web-mailer (34WB1.4.03) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA08885 Hi Jie, If I understand Nallur's problem statement correctly, its got to do with aggregation of RSVP micro flows into LSP Tunnels setup by MPLS-RSVP. I guess, Routers A and B are RSVP(2205 only) aware and S and R are the end-hosts of a microflow. Hence there's no chance of receiving LROs in PATH messages generated from S. Aggregation of millions of RSVP micro-flows has been mooted in the Applicability Statement draft for RSVP LSP Tunnels. However, I too am not sure of an answer to this problem. Stating it in different words, the problem statement goes like this: An RSVP-LSP-Tunnel has already been established between LER1 and LER2. Now a micro-flow RSVP PATH message from S arrives at LER1. We want this micro-flow to take the LSP. So if we just tunnel this PATH message into the LSP, and make it reach end-host R, the problem is how do we transport the RESV message from R back to S through the same LSP since this is uni-directional? I hope Nallur agrees with this re-statement! All comments are welcome. -Jah -----Original Message----- From: Jie Zou To: Pramoda Nallur Cc: mpls@UU.NET ; Dilip.Pandit@ind.alcatel.com ; Kishore Rao ; Manu.Prakash@ind.alcatel.com Date: Tuesday, July 25, 2000 6:49 PM Subject: Re: Reg. MPLS-RSVP LSP Tunnels... > >I hope the following can answer a part of questions. > >According the darft, if A or B is a non-RSVP router, it can't convey >labels via RSVP path. And it's neighber who knows it's non-RSVP >router should send a PathErr back to the sender. > >If A or B is an RSVP router but doesn't recognize the LRO, it should >send a PathErr toward the sender. > >If A or B is an RSVP router and recognize the LRO but not C_TYPE also >sends a PathErr toward the sender. > >Else the Path msg should pass A and B toward the receiver and >vice verse the Resv msg should pass the B and A toward the sender. > > >Regards, > >----------------------------------------------------- >Jie Zou (603)862-4212(Office) >MPLS Consortium >IOL, UNH (603)868-2983(Home) >----------------------------------------------------- > >On Tue, 25 Jul 2000, Pramoda Nallur wrote: > >> Hi, >> >> I have a query on setting up RSVP MPLS LSPs in an ATM network. >> [ Topology Driven LSP Setup Scenario ] >> >> Suppose the network configuration is as follows : >> >> S--A--LER1---LSR---LER2--B--R >> >> where, >> S --> Sender(RSVP aware) >> R --> Receiver(RSVP aware) >> A, B --> Legacy IP Routers >> LER1, LER2 and LSR --> MPLS-RSVP ATM switches. >> >> An LSP setup is initiated from LER1 with FEC=(S,R). >> >> The RSVP-TE PATH msg (with Sender=S, Session = Sess_R) creates an >> RSVP Session, Sess_R at LER1, LSR and LER2. The Egress LER2 responds with a >> >> RSVP-TE RESV msg reserving resources and sets up an LSP via LSR to LER1. >> >> After the LSP is setup, the RSVP-TE PATH msgs from LER1 and RSVP-TE RESV >> msgs >> from LER2 periodically refresh the RSVP reservation state on all nodes >> along the LSP. >> >> Suppose, Sender S sends an RSVP PATH msg to R (with Session = Sess_R). >> >> 1. Will this PATH msg take the unlabelled path OR will it get switched >> onto the LSP at LER1 ? >> >> 2. Also, how are the resulting RESV msgs from R propagated back to S ? >> >> 3. If these PATH and RESV msgs take the unlabelled path, will this result >> in >> resource allocation again along all nodes traversed by the LSP ? >> >> >> The "RSVP-TE: Extensions to RSVP for LSP Tunnels" >> (draft-ietf-mpls-rsvp-lsp-tunnel-06.txt) >> does not mention how the above should be handled. >> >> Any comments on this ? >> >> - Pramoda Nallur >> > > > ____________________________________________________________________ Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com. From owner-mpls@UU.NET Tue Jul 25 12:03: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 MAA09014 for ; Tue, 25 Jul 2000 12:03:55 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizjs26722; Tue, 25 Jul 2000 16:03:42 GMT Received: by mail-control.mail.uu.net id QQizjs09750 for mpls-outgoing; Tue, 25 Jul 2000 16:03:06 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQizjs07661 for ; Tue, 25 Jul 2000 16:02: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 QQizjs10972 for ; Tue, 25 Jul 2000 12:02:42 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQizjs09271 for ; Tue, 25 Jul 2000 16:02:11 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA10726 for ; Tue, 25 Jul 2000 09:02:27 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id MAA00872 for mpls@uu.net; Tue, 25 Jul 2000 12:02:09 -0400 (EDT) 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 QQizgs17918 for ; Mon, 24 Jul 2000 20:39: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 QQizgs21377 for ; Mon, 24 Jul 2000 16:37:34 -0400 (EDT) Received: from newmail6.rediffmail.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: [202.54.124.180]) id QQizgs03291 for ; Mon, 24 Jul 2000 20:37:18 GMT Received: (qmail 13079 invoked by uid 510); 24 Jul 2000 20:36:03 -0000 Date: 24 Jul 2000 20:36:03 -0000 Message-ID: <20000724203603.13078.qmail@newmail6.rediffmail.com> MIME-Version: 1.0 To: "mpls@UU.NET" Subject: CR-LDP drafts CC: "raovrn@rediffmail.com" From: "Vadlamani rao" Content-ID: Content-type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have the following questions on CR-LDP drafts and the MIBs ? 1) What are the differences between cr-ldp-04.txt and the previous one (03.txt) in terms of functionality ? 2) Further, the TE MIB (draft-ietf-mpls-te-mib-04.txt) refers to cr-ldp-01.txt in the mplsTeMIB MODULE-IDENTITY description part whereas in other places of the MIB, reference to cr-ldp-03.txt ? It is not consistent in the draft. If there are any changes (as per 1) ), how it impacts the MIB ? I would appreciate if someone answers these questions. Thanks in advance, Regards Rao (raovrn@rediffmail.com) _________________________________________________ Get Your Free Email At, http://www.rediffmail.com Partcipate in crazy Re.1 auctions at http://www.rediff.com/auctions From owner-mpls@UU.NET Tue Jul 25 12:14: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 MAA12455 for ; Tue, 25 Jul 2000 12:14:08 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizjs06868; Tue, 25 Jul 2000 16:13:53 GMT Received: by mail-control.mail.uu.net id QQizjs11721 for mpls-outgoing; Tue, 25 Jul 2000 16: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 QQizjs11713 for ; Tue, 25 Jul 2000 16:13: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 QQizjs15815 for ; Tue, 25 Jul 2000 12:12:46 -0400 (EDT) Received: from ind.alcatel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: postal.xylan.com [208.8.0.248]) id QQizjs05582 for ; Tue, 25 Jul 2000 16:12:45 GMT Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id JAA24654; Tue, 25 Jul 2000 09:12:29 -0700 (PDT) X-Origination-Site: Received: from k2.indc.xylan.com (indc.xylan.com [10.148.12.1]) by mailhub.ind.alcatel.com (8.8.8+Sun/8.8.8 (mailhub 3.2 [HUB])) with ESMTP id JAA21283; Tue, 25 Jul 2000 09:12:25 -0700 (PDT) Received: from ind.alcatel.com (mickey [10.148.16.18]) by k2.indc.xylan.com (8.8.8+Sun/8.8.8 (India 2.0 [SPOOL])) with ESMTP id JAA11411; Tue, 25 Jul 2000 09:12:22 -0700 (PDT) Message-ID: <397DBC65.E59E0B4C@ind.alcatel.com> Date: Tue, 25 Jul 2000 21:42:21 +0530 From: Pramoda Nallur Reply-To: Pramoda.Nallur@ind.alcatel.com Organization: Alcatel Internetworking Division, INDIA X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jahaapanah Alampanah CC: mpls@UU.NET Subject: Re: Reg. MPLS-RSVP LSP Tunnels... References: <20000725144852.3010.qmail@www0u.netaddress.usa.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jah, Jahaapanah Alampanah wrote: > Hi Jie, > > If I understand Nallur's problem statement > correctly, its got to do with aggregation > of RSVP micro flows into LSP Tunnels > setup by MPLS-RSVP. > > > An RSVP-LSP-Tunnel has already been established > between LER1 and LER2. Now a micro-flow RSVP > PATH message from S arrives at LER1. We want > this micro-flow to take the LSP. So if we just > tunnel this PATH message into the LSP, and > make it reach end-host R, the problem is > how do we transport the RESV message from R > back to S through the same LSP since this > is uni-directional? > You are right in your understanding. But, the question is, should the micro-flow PATH message be tunelled into the LSP at all ? - Pramoda. > > I hope Nallur agrees with this re-statement! > > All comments are welcome. > > -Jah > > -----Original Message----- > From: Jie Zou > To: Pramoda Nallur > Cc: mpls@UU.NET ; Dilip.Pandit@ind.alcatel.com > ; Kishore Rao ; > Manu.Prakash@ind.alcatel.com > Date: Tuesday, July 25, 2000 6:49 PM > Subject: Re: Reg. MPLS-RSVP LSP Tunnels... > > > > >I hope the following can answer a part of questions. > > > >According the darft, if A or B is a non-RSVP router, it can't convey > >labels via RSVP path. And it's neighber who knows it's non-RSVP > >router should send a PathErr back to the sender. > > > >If A or B is an RSVP router but doesn't recognize the LRO, it should > >send a PathErr toward the sender. > > > >If A or B is an RSVP router and recognize the LRO but not C_TYPE also > >sends a PathErr toward the sender. > > > >Else the Path msg should pass A and B toward the receiver and > >vice verse the Resv msg should pass the B and A toward the sender. > > > > > >Regards, > > > >----------------------------------------------------- > >Jie Zou (603)862-4212(Office) > >MPLS Consortium > >IOL, UNH (603)868-2983(Home) > >----------------------------------------------------- > > > >On Tue, 25 Jul 2000, Pramoda Nallur wrote: > > > >> Hi, > >> > >> I have a query on setting up RSVP MPLS LSPs in an ATM network. > >> [ Topology Driven LSP Setup Scenario ] > >> > >> Suppose the network configuration is as follows : > >> > >> S--A--LER1---LSR---LER2--B--R > >> > >> where, > >> S --> Sender(RSVP aware) > >> R --> Receiver(RSVP aware) > >> A, B --> Legacy IP Routers > >> LER1, LER2 and LSR --> MPLS-RSVP ATM switches. > >> > >> An LSP setup is initiated from LER1 with FEC=(S,R). > >> > >> The RSVP-TE PATH msg (with Sender=S, Session = Sess_R) creates an > >> RSVP Session, Sess_R at LER1, LSR and LER2. The Egress LER2 responds with > a > >> > >> RSVP-TE RESV msg reserving resources and sets up an LSP via LSR to LER1. > >> > >> After the LSP is setup, the RSVP-TE PATH msgs from LER1 and RSVP-TE RESV > >> msgs > >> from LER2 periodically refresh the RSVP reservation state on all nodes > >> along the LSP. > >> > >> Suppose, Sender S sends an RSVP PATH msg to R (with Session = Sess_R). > >> > >> 1. Will this PATH msg take the unlabelled path OR will it get switched > >> onto the LSP at LER1 ? > >> > >> 2. Also, how are the resulting RESV msgs from R propagated back to S ? > >> > >> 3. If these PATH and RESV msgs take the unlabelled path, will this result > >> in > >> resource allocation again along all nodes traversed by the LSP ? > >> > >> > >> The "RSVP-TE: Extensions to RSVP for LSP Tunnels" > >> (draft-ietf-mpls-rsvp-lsp-tunnel-06.txt) > >> does not mention how the above should be handled. > >> > >> Any comments on this ? > >> > >> - Pramoda Nallur > >> > > > > > > > > ____________________________________________________________________ > Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com. From owner-mpls@UU.NET Tue Jul 25 12:14: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 MAA12599 for ; Tue, 25 Jul 2000 12:14:43 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizjs07776; Tue, 25 Jul 2000 16:14:32 GMT Received: by mail-control.mail.uu.net id QQizjs11754 for mpls-outgoing; Tue, 25 Jul 2000 16:14: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 QQizjs11740 for ; Tue, 25 Jul 2000 16:13: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 QQizjs16000 for ; Tue, 25 Jul 2000 12:13:19 -0400 (EDT) From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQizjs06247 for ; Tue, 25 Jul 2000 16:13:18 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id BAA02172 for ; Wed, 26 Jul 2000 01:13:50 +0900 (KST) X-OpenMail-Hops: 3 Date: Tue, 25 Jul 2000 22:58:04 +0900 Message-Id: Subject: mpls on ethernet MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Tue, 25 Jul 2000 22:53:09 +0900" ;Modification-Date="Tue, 25 Jul 2000 22:57:52 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi, I am new to the mpls and have the following doubts. If any of u , have implemented this pls help me. For implementing mpls on ethernet : which part of ethernet frame can be used as LABEL. and which part of PPP frame can be used as LABEL, in case implementing mpls on PPP. How exactly I need to procede. Any references /suggestions pls..... regards seenu From owner-mpls@UU.NET Tue Jul 25 12:40: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 MAA21572 for ; Tue, 25 Jul 2000 12:40:06 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizju27601; Tue, 25 Jul 2000 16:39:49 GMT Received: by mail-control.mail.uu.net id QQizju13384 for mpls-outgoing; Tue, 25 Jul 2000 16:39:24 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQizju13379 for ; Tue, 25 Jul 2000 16:39: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 QQizju20385 for ; Tue, 25 Jul 2000 12:38:59 -0400 (EDT) Received: from mailrelay.laurelnetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: laurelnetworks.com [206.67.234.84]) id QQizju06076 for ; Tue, 25 Jul 2000 16:38:58 GMT Received: from localhost.laurelnetworks.com (IDENT:root@jleu-laptop.laurelnetworks.com [192.168.0.110]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id MAA04272; Tue, 25 Jul 2000 12:38:58 -0400 Received: (from jleu@localhost) by localhost.laurelnetworks.com (8.9.3/8.9.3) id MAA01900; Tue, 25 Jul 2000 12:38:57 -0400 Date: Tue, 25 Jul 2000 12:38:56 -0400 From: "James R. Leu" To: seenu@samsung.co.kr Cc: mpls@UU.NET Subject: Re: mpls on ethernet Message-ID: <20000725123856.A884@laurelnetworks.com> Reply-To: jleu@laurelnetworks.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from seenu@samsung.co.kr on Tue, Jul 25, 2000 at 10:58:04PM +0900 Organization: Laurel Networks Sender: owner-mpls@UU.NET Precedence: bulk On Tue, Jul 25, 2000 at 10:58:04PM +0900, seenu@samsung.co.kr wrote: > Hi, > > I am new to the mpls and have the following doubts. > If any of u , have implemented this pls help me. ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-07.txt > For implementing mpls on ethernet : > > which part of ethernet frame can be used as LABEL. It's not in the frame. Read the above and it will explain. > and which part of PPP frame can be used as LABEL, in case implementing mpls on PPP. > > How exactly I need to procede. > Any references /suggestions pls..... > > regards > seenu If your looking for example implementation of MPLS forwarding take a look at: FreeBSD: http://www.antd.nist.gov/itg/nistswitch/ Linux: http://nero.doit.wisc.edu/mpls-linux/ http://www.cl.cam.ac.uk/Research/SRG/netos/netx/code/ Jim -- James R. Leu Software Engineer Laurel Networks, Inc jleu@laurelnetworks.com From owner-mpls@UU.NET Tue Jul 25 13: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 NAA06822 for ; Tue, 25 Jul 2000 13:33:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizjy07220; Tue, 25 Jul 2000 17:33:19 GMT Received: by mail-control.mail.uu.net id QQizjy29167 for mpls-outgoing; Tue, 25 Jul 2000 17:32: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 QQizjy29150 for ; Tue, 25 Jul 2000 17:32:37 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizjy26476 for ; Tue, 25 Jul 2000 13:32:32 -0400 (EDT) Received: from icarian.ZAFFIRE.COM by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: ATHM-64-232-xxx-132.home.net [64.232.69.132] (may be forged)) id QQizjy11357 for ; Tue, 25 Jul 2000 17:32:31 GMT Received: by ICARIAN with Internet Mail Service (5.5.2650.21) id <36QHD4VL>; Tue, 25 Jul 2000 10:39:48 -0700 Message-ID: <4D3F9F2BEC58D4118FCE009027B0A662136063@ICARIAN> From: Eric Gray To: "'Lou Berger'" , Grenville Armitage Cc: Eric Gray , "MPLS Mailing List (E-mail)" Subject: RE: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Date: Tue, 25 Jul 2000 10:39:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Lou, > [...] > > PS The "-simple" approach is a totally new one. This is > appropriate as > draft-ietf-mpls-hdr-comp- and the 2507/8 are "one-hop" based, while > "-simple" is multi-hop. Hmmm. I think there is plenty of work afoot that leans toward treating an LSP as one hop. Indeed, part of the issue with your approach is the fact that "one-hop" is a bit of a stretchy notion... > > [...] From owner-mpls@UU.NET Tue Jul 25 13:56: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 NAA13054 for ; Tue, 25 Jul 2000 13:56:28 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizjz24433; Tue, 25 Jul 2000 17:56:00 GMT Received: by mail-control.mail.uu.net id QQizjz02247 for mpls-outgoing; Tue, 25 Jul 2000 17:55: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 QQizjz02239 for ; Tue, 25 Jul 2000 17:55:22 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizjz02112 for ; Tue, 25 Jul 2000 13:54:33 -0400 (EDT) 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 QQizjz26587 for ; Tue, 25 Jul 2000 17:54:33 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA05896 for mpls@uu.net; Tue, 25 Jul 2000 13:54:32 -0400 (EDT) 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 QQizjz02185 for ; Tue, 25 Jul 2000 17:54: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 QQizjz01943 for ; Tue, 25 Jul 2000 13:53:29 -0400 (EDT) Received: from postal.redback.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: postal.redback.com [155.53.12.9]) id QQizjz22518 for ; Tue, 25 Jul 2000 17:53:28 GMT Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id 2D8C617BC34; Tue, 25 Jul 2000 10:53:28 -0700 (PDT) Received: (from rahul@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id KAA00487; Tue, 25 Jul 2000 10:52:42 -0700 (PDT) Date: Tue, 25 Jul 2000 10:52:42 -0700 From: Rahul Aggarwal To: Kireeti Kompella Cc: rahul@redback.com, mpls@UU.NET Subject: Re: New Internet Draft: TE over Unnumbered Links Message-ID: <20000725105242.A29870@malt.redback.com> References: <200007250856.BAA27610@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200007250856.BAA27610@kummer.juniper.net> Sender: owner-mpls@UU.NET Precedence: bulk Kireeti, Thanks for the response. First of all the approach in the draft is pretty slick. I have a few inline comments regarding some of the assumptions: On Tue, Jul 25, 2000 at 01:56:37AM -0700, Kireeti Kompella wrote: > Hi Rahul, > > > A couple of comments: > > > > 1. Maybe there is a need to enhance the semantics of the RSVP_HOP object > > to work over unnumbered links. The ip address of the previous hop > > could be set to the router id of the previous hop. > > In our first pass at this draft, the ERO subobject included both a > router ID (of the PHOP) and the interface index. We then decided > that just the interface index is sufficient; see below. I think there still is a need to enhance the semantics of the RSVP_HOP object. Please see below. > > > 2. This is more of a clarification. Consider: > > A----------B-----------C > > Ia Ib Ic > > > > The link from B to C is unnumbered. My understanding from the draft is > > that B will generate the interface id for Ic. (and C for Ib) Is that correct? > > B will indeed generate the interface id Ic, but C has nothing to do > with Ib (as I see your picture). Yes. The picture should have been: A----------B-----------C Ia Ib Ib1 Ic Now C will generate the interface id Ib1. > > > The ero could be . Since B generated the id for Ic, it will know the > > outgoing interface to send the path msg to C. > > > C will receive the ero as . Now C needs to check the ero to see if > > it belongs to the first subobject i.e. Ic. How should this check be done? > > This goes back to (1) above. > > I assume that C can tell which LSR it got the path msg from (i.e., B). Here is where the RSVP_HOP object is required. As per the RSVP spec B when sending the path msg to C will set the source ip address to the sender's address (i.e A's address). Hence there is no way for C to tell which LSR it got the path msg from. If the RSVP_HOP object gives the router id of the PHOP, things work fine. I am curious to know how you do this. I can think of other ways, but none of them will hold in all cases. > C then looks to see in its TE link state database if B is advertising > a link to C with index Ic. (I will add this to the next rev.) This is what I assumed. Sounds fine. > > One could be more paranoid and add a router ID to the unnumbered ERO > subobject. Then the check is: a) does the router ID of the LSR sending > the path msg match the router ID in the subobject? AND b) if so, is Goes back to the previous point. How does C know the router id of the LSR sending the path msg? > that LSR advertising a link to me with the index in the subobject (Ic)? > This approach is slightly more likely to catch errors because there are > two checks. Suppose for example A sent the first Path message to D (by > mistake) AND D didn't catch this error. Suppose also that D has an > unnumbered link to C with index Ic (same as B's). > > Now, when C gets the path msg from D (without the router ID), it will > erroneously accept it. However, for this to happen: A made a mistake; > D missed the mistake; and D had the same ifindex to C as B did. The situation does sound contrived, but I guess it can happen. I would be in favor of adding a router id to the ERO subobject. Thanks, rahul From owner-mpls@UU.NET Tue Jul 25 14:19: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 OAA20513 for ; Tue, 25 Jul 2000 14:19:01 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizkb13981; Tue, 25 Jul 2000 18:18:47 GMT Received: by mail-control.mail.uu.net id QQizkb15825 for mpls-outgoing; Tue, 25 Jul 2000 18:18: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 QQizkb15820 for ; Tue, 25 Jul 2000 18:18: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 QQizkb05861 for ; Tue, 25 Jul 2000 14:15:06 -0400 (EDT) Received: from csa.iisc.ernet.in by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQizka11040 for ; Tue, 25 Jul 2000 18:14:48 GMT Received: from sapphire.csa.iisc.ernet.in (IDENT:root@sapphire.csa.iisc.ernet.in [144.16.67.31]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id XAA00858 for ; Tue, 25 Jul 2000 23:45:04 +0530 Received: from localhost (ytr@localhost) by sapphire.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id XAA02890 for ; Tue, 25 Jul 2000 23:44:41 +0530 X-Authentication-Warning: sapphire.csa.iisc.ernet.in: ytr owned process doing -bs Date: Tue, 25 Jul 2000 23:44:41 +0530 (IST) From: Ramanjaneyulu Y T To: mpls@UU.NET Subject: RSVP VS LDP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I got one basic doubt in MPLS. For label distribution MPLS uses RSVP or LDP. Suppose some one uses RSVP for label distribution, Is LDP required to maintain path info., like node is alive or not or LSP is up or down?. I guess the above tasks can also achievd with RSVP without LDP. If so please suggest some reading material. Thanking you. Regards Ramanjaneyulu Y.T. " A real friend is one who walks in when the rest of the world walks out." ------------------------------------------------------------------------------ Y.T.RAMANJANEYULU | My other mail Ids: E-70,INDIAN INSTITUTE OF SCIENCE | ytr@rediffmail.com BANGALORE - 560012 | kingytr@excite.com PH: 0091 - 080 - 3092622 ( HOSTEL ) | 0091 - 080 - 3092906 ( LAB ) | visit my home page:www2.csa.iisc.ernet.in/~ytr -------------------------------------------------------------------------------- From owner-mpls@UU.NET Tue Jul 25 14:20: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 OAA21036 for ; Tue, 25 Jul 2000 14:20:32 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizkb15350; Tue, 25 Jul 2000 18:20:19 GMT Received: by mail-control.mail.uu.net id QQizkb15959 for mpls-outgoing; Tue, 25 Jul 2000 18:19: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 QQizkb15941 for ; Tue, 25 Jul 2000 18:19: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 QQizkb06339 for ; Tue, 25 Jul 2000 14:17:52 -0400 (EDT) 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 QQizkb13211 for ; Tue, 25 Jul 2000 18:17:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id OAA10761 for mpls@uu.net; Tue, 25 Jul 2000 14:17:51 -0400 (EDT) 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 QQizkb15758 for ; Tue, 25 Jul 2000 18:17:19 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQizka05603 for ; Tue, 25 Jul 2000 14:13:39 -0400 (EDT) Received: from postal.redback.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: postal.redback.com [155.53.12.9]) id QQizka08264 for ; Tue, 25 Jul 2000 18:13:39 GMT Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id D029F17BC28; Tue, 25 Jul 2000 11:13:38 -0700 (PDT) Received: (from rahul@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id LAA00748; Tue, 25 Jul 2000 11:12:53 -0700 (PDT) Date: Tue, 25 Jul 2000 11:12:53 -0700 From: Rahul Aggarwal To: Markus Jork Cc: Kireeti Kompella , rahul@redback.com, mpls@UU.NET Subject: Re: New Internet Draft: TE over Unnumbered Links Message-ID: <20000725111253.A490@malt.redback.com> References: <200007250856.BAA27610@kummer.juniper.net> <200007251341.JAA09842@mailhost.avici.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200007251341.JAA09842@mailhost.avici.com> Sender: owner-mpls@UU.NET Precedence: bulk Markus, On Tue, Jul 25, 2000 at 09:41:45AM -0400, Markus Jork wrote: > Kireeti/Rahul, > > now you are confusing me. I thought the draft was pretty clear > (although too concise). > > > I thought it works like this: > > A----------B----------C---------D > A1 B1 Ib Ic > > A-B is a numbered link, B-C and C-D are unnumbered. > A1 and B1 are the interface addresses, Ib and Ic are the interface IDs > and A, B, C and D are the router IDs. > > Then, the ERO sent by A would be: > B1 Ib C Ic D (or replace B1 with B) > Router B would then forward this ERO: > C Ic D > Router C would then forward this ERO: > D > > This should work just fine and I thought it's what the draft says. > Every router can verify whether it's the first subobject in the ERO > and knows where to go next. There could be different ways of generating EROs. Your approach is one of them. The earlier mails were considering the case where the ERO has the incoming interface index and not the outgoing interface index. And there is still the case described by Kireeti where A could erroneously send the ERO to some other router D. > > The only problem is filling in the RRO in the Resv message > going back. One alternative is to make router C add "C Ic" > to the RRO. It would know Ic from the LIH in the NHOP object of > the Resv message. The other alternative is to make router C add Interesting use of LIH ! I think it is overloading LIH semantics.. > "Ib C" to the RRO. It would have to look up Ib in the link state > database. The second alternative is probably the right thing to do. If you were to use the ERO format as described by you, I would prefer the second approach. > > Markus > > > > > C will receive the ero as . Now C needs to check the ero to see if > > > it belongs to the first subobject i.e. Ic. How should this check be done? > > > This goes back to (1) above. > > > > I assume that C can tell which LSR it got the path msg from (i.e., B). > > C then looks to see in its TE link state database if B is advertising > > a link to C with index Ic. (I will add this to the next rev.) > > > > One could be more paranoid and add a router ID to the unnumbered ERO > > subobject. Then the check is: a) does the router ID of the LSR sending > > the path msg match the router ID in the subobject? AND b) if so, is > > that LSR advertising a link to me with the index in the subobject (Ic)? > > This approach is slightly more likely to catch errors because there are > > two checks. Suppose for example A sent the first Path message to D (by > > mistake) AND D didn't catch this error. Suppose also that D has an > > unnumbered link to C with index Ic (same as B's). > > > > Now, when C gets the path msg from D (without the router ID), it will > > erroneously accept it. However, for this to happen: A made a mistake; > > D missed the mistake; and D had the same ifindex to C as B did. > > > > Thanks for your comments! > > > > Kireeti. > > > > From owner-mpls@UU.NET Tue Jul 25 14:21: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 OAA21283 for ; Tue, 25 Jul 2000 14:21:22 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizkb14199; Tue, 25 Jul 2000 18:21:08 GMT Received: by mail-control.mail.uu.net id QQizkb16029 for mpls-outgoing; Tue, 25 Jul 2000 18:20: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 QQizkb16015 for ; Tue, 25 Jul 2000 18:20: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 QQizkb04689 for ; Tue, 25 Jul 2000 14:20:08 -0400 (EDT) Received: from csa.iisc.ernet.in by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQizkb12896 for ; Tue, 25 Jul 2000 18:19:50 GMT Received: from sapphire.csa.iisc.ernet.in (IDENT:root@sapphire.csa.iisc.ernet.in [144.16.67.31]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id XAA00897 for ; Tue, 25 Jul 2000 23:50:10 +0530 Received: from localhost (ytr@localhost) by sapphire.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id XAA02907 for ; Tue, 25 Jul 2000 23:49:47 +0530 X-Authentication-Warning: sapphire.csa.iisc.ernet.in: ytr owned process doing -bs Date: Tue, 25 Jul 2000 23:49:46 +0530 (IST) From: Ramanjaneyulu Y T To: mpls@UU.NET Subject: MPLS stuff Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, one more question. Is there any other source to find MPLS related documents other than the following one. http://www.ietf.org/html.charters/mpls-charter.html If so please suggest URLs . Thanking you Regards Ramanjaneyulu Y.T. " A real friend is one who walks in when the rest of the world walks out." ------------------------------------------------------------------------------ Y.T.RAMANJANEYULU | My other mail Ids: E-70,INDIAN INSTITUTE OF SCIENCE | ytr@rediffmail.com BANGALORE - 560012 | kingytr@excite.com PH: 0091 - 080 - 3092622 ( HOSTEL ) | 0091 - 080 - 3092906 ( LAB ) | visit my home page:www2.csa.iisc.ernet.in/~ytr -------------------------------------------------------------------------------- From owner-mpls@UU.NET Tue Jul 25 14:45: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 OAA27787 for ; Tue, 25 Jul 2000 14:45:33 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizkd03663; Tue, 25 Jul 2000 18:45:21 GMT Received: by mail-control.mail.uu.net id QQizkc18594 for mpls-outgoing; Tue, 25 Jul 2000 18:44: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 QQizkc18586 for ; Tue, 25 Jul 2000 18:44: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 QQizkc10857 for ; Tue, 25 Jul 2000 14:43:05 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQizkc00682 for ; Tue, 25 Jul 2000 18:42:50 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA05078; Tue, 25 Jul 2000 14:42:37 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA16870; Tue, 25 Jul 2000 14:42:37 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jul 2000 14:42:38 -0400 Message-ID: From: "Banerjee, Gargi" To: "'Ramanjaneyulu Y T'" Cc: "'mpls@UU.NET'" Subject: RE: MPLS stuff Date: Tue, 25 Jul 2000 14:42:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, The folllowing sites have useful information on MPLS: 1. http://www.mplsrc.com/ 2. http://infonet.aist-nara.ac.jp/member/nori-d/mlr/ Also let me try to answer your question on RSVP and LDP. These are both signaling approaches for setting up label switched paths or LSPs. 1. RSVP is a soft-state receiver oriented approach. The original protocol runs over UDP and could reserve resources for a session, along a path from the receiver to the sender. This usually required session state to be stored in each intermediate RSVP-capable router. Using RSVP as the signaling protocol for MPLS has the advantage that you can take advantage of the reservation procedure in RSVP and extend it [http://search.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-06.t xt] to work also as a label distribution protocol in MPLS. 2. LDP is only a label distribution protocol and has no reservation functions. However CR-LDP is an extension to LDP [http://search.ietf.org/internet-drafts/draft-ietf-mpls-cr-ldp-04.txt] which supports reservation of resources, explicit path signaling etc. 3. Thus functionality wise both CR-LDP and RSVP are quite similar-though in operational aspects they may be very diffrent. 4. Normally, you would choose one or the other as your signaling protocol in MPLS. Hope this helps, Gargi -----Original Message----- From: Ramanjaneyulu Y T [mailto:ytr@csa.iisc.ernet.in] Sent: Tuesday, July 25, 2000 2:20 PM To: mpls@UU.NET Subject: MPLS stuff Hi, one more question. Is there any other source to find MPLS related documents other than the following one. http://www.ietf.org/html.charters/mpls-charter.html If so please suggest URLs . Thanking you Regards Ramanjaneyulu Y.T. " A real friend is one who walks in when the rest of the world walks out." ---------------------------------------------------------------------------- -- Y.T.RAMANJANEYULU | My other mail Ids: E-70,INDIAN INSTITUTE OF SCIENCE | ytr@rediffmail.com BANGALORE - 560012 | kingytr@excite.com PH: 0091 - 080 - 3092622 ( HOSTEL ) | 0091 - 080 - 3092906 ( LAB ) | visit my home page:www2.csa.iisc.ernet.in/~ytr ---------------------------------------------------------------------------- ---- From owner-mpls@UU.NET Tue Jul 25 15:27: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 PAA10134 for ; Tue, 25 Jul 2000 15:27:55 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizkf08215; Tue, 25 Jul 2000 19:27:34 GMT Received: by mail-control.mail.uu.net id QQizkf04576 for mpls-outgoing; Tue, 25 Jul 2000 19:27: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 QQizkf04550 for ; Tue, 25 Jul 2000 19:26:59 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizkf19564 for ; Tue, 25 Jul 2000 15:26:55 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQizkf11253 for ; Tue, 25 Jul 2000 19:26:24 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA08385 for ; Tue, 25 Jul 2000 12:26:40 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA01667 for mpls@uu.net; Tue, 25 Jul 2000 15:26:23 -0400 (EDT) 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 QQizkb17005 for ; Tue, 25 Jul 2000 18:27: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 QQizkb06081 for ; Tue, 25 Jul 2000 14:27:09 -0400 (EDT) Received: from backin5.merit.edu by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: backin5.merit.edu [198.108.60.28]) id QQizkb18830 for ; Tue, 25 Jul 2000 18:26:39 GMT Received: by backin5.merit.edu (Postfix, from userid 8935) id 688EC7E50B; Tue, 25 Jul 2000 14:26:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by backin5.merit.edu (Postfix) with ESMTP id 52FD529A83; Tue, 25 Jul 2000 14:26:35 -0400 (EDT) Date: Tue, 25 Jul 2000 14:26:35 -0400 (EDT) From: "Susan R. Harris" To: mpls@UU.NET Cc: nanog-support@merit.edu Subject: Re: FW: In-Reply-To: <5B3F16B2DB67D1119A0D00805F312AA21F644A70@RED-MSG-58> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Greetings - you'll find the tutorials linked off the agenda page for each individual conference. Susan R. Harris, Ph.D. Merit Network/Univ. of Mich. (734) 936-2100 > -----Original Message----- > From: Ted44tedT@netscape.net [mailto:Ted44tedT@netscape.net] > Sent: Tuesday, July 25, 2000 6:37 AM > To: mpls@UU.NET > Subject: > > > Hi, > > Quick question: > > How can I get all tutorials on website www.nanog.org like mpls etc.? > > > Thanks in advance > > Regards, > > Ted > > ---------- > Get your own FREE, personal Netscape Webmail account today at > http://webmail.netscape.com/ > From owner-mpls@UU.NET Tue Jul 25 15:28: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 PAA10514 for ; Tue, 25 Jul 2000 15:28:57 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizkf13338; Tue, 25 Jul 2000 19:28:40 GMT Received: by mail-control.mail.uu.net id QQizkf04677 for mpls-outgoing; Tue, 25 Jul 2000 19:28:13 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQizkf04670 for ; Tue, 25 Jul 2000 19:28: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 QQizkf20967 for ; Tue, 25 Jul 2000 15:26:32 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQizkf11364 for ; Tue, 25 Jul 2000 19:26:32 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA08442 for ; Tue, 25 Jul 2000 12:26:47 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA01671 for mpls@uu.net; Tue, 25 Jul 2000 15:26:29 -0400 (EDT) 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 QQizkb17373 for ; Tue, 25 Jul 2000 18:29: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 QQizkb07926 for ; Tue, 25 Jul 2000 14:26:23 -0400 (EDT) Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQizkb18281 for ; Tue, 25 Jul 2000 18:25:53 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jul 2000 14:22:15 -0400 Message-ID: <87009604743AD411B1F600508BA0F959040B55@xover.hjinc.com> From: "Sanford, Bill" To: "'Ramanjaneyulu Y T'" Cc: mpls@UU.NET Subject: RE: MPLS stuff Date: Tue, 25 Jul 2000 14:22:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Maybe you could start with www.mplsrc.com Bill > -----Original Message----- > From: Ramanjaneyulu Y T [mailto:ytr@csa.iisc.ernet.in] > Sent: Tuesday, July 25, 2000 2:20 PM > To: mpls@UU.NET > Subject: MPLS stuff > > > Hi, > > one more question. Is there any other source to find MPLS related > documents other than the following one. > > http://www.ietf.org/html.charters/mpls-charter.html > > If so please suggest URLs . > Thanking you > > > Regards > Ramanjaneyulu Y.T. > > " A real friend is one who walks in when the rest of the world walks > out." > > -------------------------------------------------------------- > ---------------- > Y.T.RAMANJANEYULU | My other mail Ids: > E-70,INDIAN INSTITUTE OF SCIENCE | ytr@rediffmail.com > BANGALORE - 560012 | kingytr@excite.com > PH: 0091 - 080 - 3092622 ( HOSTEL ) | > 0091 - 080 - 3092906 ( LAB ) | > visit my home page:www2.csa.iisc.ernet.in/~ytr > -------------------------------------------------------------- > ------------------ > From owner-mpls@UU.NET Tue Jul 25 16:25: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 QAA25438 for ; Tue, 25 Jul 2000 16:25:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizkj22303; Tue, 25 Jul 2000 20:25:18 GMT Received: by mail-control.mail.uu.net id QQizkj19759 for mpls-outgoing; Tue, 25 Jul 2000 20:24:54 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQizkj19754 for ; Tue, 25 Jul 2000 20:24: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 QQizkj00280 for ; Tue, 25 Jul 2000 16:23:45 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQizkj21372 for ; Tue, 25 Jul 2000 20:23:30 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA23031; Tue, 25 Jul 2000 13:23:45 -0700 (PDT) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA02037; Tue, 25 Jul 2000 16:23:28 -0400 (EDT) Message-Id: <200007252023.QAA02037@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: mpls@UU.NET Subject: Tunneling MPLS through IP Reply-to: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Tue, 25 Jul 2000 16:23:27 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk The issue of tunneling MPLS packets through an IP-but-not-MPLS backbone has started to attract some interest, judging from draft-worster-mpls-in-ip and draft-rekhter-mpls-over-gre. I believe that tunneling MPLS through GRE is in fact legal and standard as things stand right now. Draft-rekhter-mpls-over-gre provides some explica- tion of how to do it, but doesn't really propose anything which isn't already standard. Draft-worster-mpls-in-ip proposes a way to tunnel MPLS through IP with less overhead. In some cases of tunneling, MPLS will really need to go through GRE. Suppose, for example, two routers are "connected" via a GRE tunnel, which they treat as an interface. Many different kinds of packets may go through that interface. If MPLS packets need to go through that interface, then they will go inside GRE packets, just like all the other packets that go through that interface. Having to use a different encapsulation for MPLS than for all the other tunneled packets would just be a complication. There may be cases though where there is no particular reason to choose GRE over anything else, and where minimizing overhead is deemed important. I don't have any really strong objection to the use of draft-worster-mpls-in- ip for such cases. (I thought about raising the ritual "do we really need another tunneling protocol?" issue, but this would only give rise to the ritual "no other tunneling protocol is good enough for the particular application we're focused on now" response.) I do think though if draft-worster-mpls-in-ip is to advance, it needs to make it clear that what it is describing is just one of a number of standard tunneling techniques. From owner-mpls@UU.NET Tue Jul 25 17:40: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 RAA15763 for ; Tue, 25 Jul 2000 17:40:27 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizko17645; Tue, 25 Jul 2000 21:40:08 GMT Received: by mail-control.mail.uu.net id QQizko05163 for mpls-outgoing; Tue, 25 Jul 2000 21:39: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 QQizko05158 for ; Tue, 25 Jul 2000 21:39:41 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQizko11899 for ; Tue, 25 Jul 2000 17:38:22 -0400 (EDT) Received: from web2006.mail.yahoo.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web2006.mail.yahoo.com [128.11.68.206]) id QQizko12258 for ; Tue, 25 Jul 2000 21:38:21 GMT Received: (qmail 28491 invoked by uid 60001); 25 Jul 2000 21:38:21 -0000 Message-ID: <20000725213821.28490.qmail@web2006.mail.yahoo.com> Received: from [208.36.16.4] by web2006.mail.yahoo.com; Tue, 25 Jul 2000 14:38:21 PDT Date: Tue, 25 Jul 2000 14:38:21 -0700 (PDT) From: Vivek Venkatraman Subject: IGPs and 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 have a few questions regarding IGPs (e.g., OSPF) and MPLS TE and would appreciate any answers. 1. When an LSP is established and IGP traffic engineering is being performed, should the LSP be informed as a (logical) Router link and/or a TE LSA link into OSPF? If not, how is traffic engineering for IGP destinations performed, is it completely internal to the Ingress node? 2. If the available/unreseved bandwidth or some other TE parameter on a link changes when a new LSP is established, should the change be made known immediately to OSPF and OSPF originate a new TE LSA? 3. Should CSPF path computations occur as a result of an updated TE LSA or are they done only when a new LSP is to be setup or existing LSPs optimized etc.? 4. Should a LSP be specifically designated as an FA-LSP (draft-kompella-lsp-hierarchy-00.txt) or can any LSP established function as an FA-LSP if the LSP is advertised into OSPF? 5. Sec 4.2 of draft-kompella-lsp-hierarchy-00.txt mentions how a FA-LSP/forwarding adjacency can be restricted to allow its usage only for MPLS TE LSPs. So, is there an Internet draft which defines how an LSP should be advertised as a regular LSA into OSPF? Vivek __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From owner-mpls@UU.NET Tue Jul 25 20:57:50 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11857 for ; Tue, 25 Jul 2000 20:57:50 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizlb17473; Wed, 26 Jul 2000 00:57:31 GMT Received: by mail-control.mail.uu.net id QQizlb21425 for mpls-outgoing; Wed, 26 Jul 2000 00:57: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 QQizlb21420 for ; Wed, 26 Jul 2000 00:56: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 QQizlb05344 for ; Tue, 25 Jul 2000 20:56:46 -0400 (EDT) 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 QQizlb17239 for ; Wed, 26 Jul 2000 00:56:31 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA10021 for mpls@uu.net; Tue, 25 Jul 2000 20:56:30 -0400 (EDT) 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 QQizlb21359 for ; Wed, 26 Jul 2000 00:55:47 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizlb06184 for ; Tue, 25 Jul 2000 20:55:44 -0400 (EDT) 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 QQizlb16774 for ; Wed, 26 Jul 2000 00:55:44 GMT Received: from jlawrenc-pc.cisco.com (dhcp-71-56-188.cisco.com [171.71.56.188]) by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA22897 for ; Tue, 25 Jul 2000 17:55:42 -0700 (PDT) Message-Id: <4.3.1.2.20000726024646.00ad93c0@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 26 Jul 2000 10:55:26 +1000 To: mpls@UU.NET From: Jeremy Lawrence Subject: Re: Status of Drafts In-Reply-To: <200007211504.LAA25889@lir.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk At 11:04 07/21/2000 -0400, George Swallow wrote: >There's now a set of drafts that are ready for publication, save one >nagging detail. There are references to the Framework Document which >remains incomplete. Given that the Architecture document has captured >and expanded on the useful ideas in the Framework document, the IESG >has agreed to proceed as follows. [...] This reminds me of a discrepancy between draft-ietf-mpls-arch-06.txt and draft-ietf-mpls-framework-05.txt, which becomes more important if the framework document is to dropped as a reference. Specifically, there are several inaccuracies in draft-ietf-mpls-arch-06.txt, in "3.26.3.2. Interoperation: VC Merge, VP Merge, and Non-Merge", which were corrected in the equivalent section of the framework document, but not the architecture document. Correct section 3.26.3.2 text would read as follows (this is from the framework document, section 4.2.2, with some typos corrected). If it is too late for these to go into draft-ietf-mpls-arch-06.txt before it goes to Proposed Standard then that's ok: in that case, consider this as the first comment to be addressed in the rev up to Draft Standard. (It's not urgent, as the details of VP merging have not been pursued lately.) ------ 3.26.3.2. Interoperation: VC Merge, VP Merge, and Non-Merge The interoperation of the various forms of merging over ATM is most easily described by first describing the interoperation of VC merge with non-merge. In the case where VC merge and non-merge nodes are interconnected the forwarding of cells is based in all cases on a VC (ie, the concatenation of the VPI and VCI). For each node, if an upstream neighbor is doing VC merge then that upstream neighbor requires only a single outgoing VPI/VCI for a particular FEC (this is analogous to the requirement for a single label in the case of operation over frame media). If the upstream neighbor is not doing merge, then it will require a single outgoing VPI/VCI per FEC for itself (assuming that it can be an ingress node), plus enough outgoing VPI/VCIs to map to incoming VPI/VCIs to pass to its upstream neighbors. The number required will be determined by allowing the upstream nodes to request additional VPI/VCIs from their downstream neighbors. A similar method is possible to support nodes which perform VP merge. In this case the VP merge node, rather than requesting a single VPI/VCI or a number of VPI/VCIs from its downstream neighbor, instead may request a single VP (identified by a VPI). Furthermore, suppose that a non-VP-merge node is downstream from two different VP merge nodes. This node may need to request one VPI/VCI (for traffic originating from itself) plus two VPs (one for each upstream node). An alternative method is possible, which requires no support of VP switching and VP labels on nodes which do not support VP merge. In this method, the VP merge node does not request VPs from the downstream node. It does request a number of VPI/VCIs, one per source node in the group of nodes which use VP merge. In order to support all of VP merge, VC merge, and non-merge, it is therefore necessary to allow upstream nodes to request a zero or more VC identifiers (consisting of a VPI/VCI). In addition, it is useful to allow upstream nodes to request zero or more VPs (identified by VPIs). VP merge nodes would therefore request one VP, or in the event where this is not supported, the VP merge node(s) would request several VCs. VC merge nodes would request only a single VPI/VCI per destination (since they can merge all upstream traffic into a single VC). Non-VP-merge nodes would pass on any requests that they get from above, plus request a VPI/VCI for traffic that they originate (if they can be ingress nodes). However, non-VP-merge nodes which can only do VC forwarding (and not VP forwarding) will need to know which VCIs are used within each VP in order to install the correct VCs in its forwarding table. This limitation is likely to apply to most on non-ATM LSRs; most ATM NICs can terminate VP connections only as numerous individual VC connections. A detailed description of how this could work can be found in [ATMVP]. Alternatively, the non-VP-merge nodes could issue only VC identifiers, as described above. ------ Jeremy Lawrence From owner-mpls@UU.NET Tue Jul 25 21:07: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 VAA14178 for ; Tue, 25 Jul 2000 21:07:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizlc23900; Wed, 26 Jul 2000 01:07:16 GMT Received: by mail-control.mail.uu.net id QQizlc03161 for mpls-outgoing; Wed, 26 Jul 2000 01:06: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 QQizlc03132 for ; Wed, 26 Jul 2000 01:06: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 QQizlc07384 for ; Tue, 25 Jul 2000 21:06:31 -0400 (EDT) Received: from lux.chromisys.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 193.140.adsl6.netlojix.net [207.71.200.140] (may be forged)) id QQizlc23270 for ; Wed, 26 Jul 2000 01:06:30 GMT Received: by LUX with Internet Mail Service (5.5.2448.0) id ; Tue, 25 Jul 2000 18:06:30 -0700 Message-ID: <51DA0AB3D747D311832F005004827CC02CE8E2@LUX> From: Jonathan Lang To: "Bala Rajagopalan (E-mail)" , "'mpls@uu.net'" Cc: Jonathan Lang Subject: FW: draft-bala-mpls-optical-uni-signaling-00.txt Date: Tue, 25 Jul 2000 18:06:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Bala, In reading this draft (draft-bala-mpls-optical-uni-signaling-00.txt), I came to the conclusion that a lot of people will assume these are OIF APPROVED concepts/requirements for the optical UNI. Since I attend the Signaling and Architecture groups of the OIF, I am only aware that the UNI signaling requirements are a Work In Progress and nothing has been APPROVED yet. I am concerned that as the draft stands, it gives the impression that these are APPROVED requirements. The draft needs to be modified to explicitly state that "not all of the concepts/requirements have been approved by the OIF". Furthermore, once the requirements are APPROVED by the OIF, they should probably be communicated through a formal liaison from the OIF to the IETF. Regards, Jonathan Calient Networks From owner-mpls@UU.NET Tue Jul 25 22:17: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 WAA04902 for ; Tue, 25 Jul 2000 22:17:07 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizlh07724; Wed, 26 Jul 2000 02:16:51 GMT Received: by mail-control.mail.uu.net id QQizlh18311 for mpls-outgoing; Wed, 26 Jul 2000 02:16:15 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache03.uu.net [153.39.7.42]) id QQizlh18227 for ; Wed, 26 Jul 2000 02:16: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 QQizlh13559 for ; Tue, 25 Jul 2000 22:15:42 -0400 (EDT) Received: from gateway.ntu.edu.sg by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [155.69.1.127]) id QQizlh00680 for ; Wed, 26 Jul 2000 02:15:25 GMT Received: by gateway.ntu.edu.sg with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 10:15:15 +0800 Message-ID: <9985F17605D2D21192D80008C75DE4BE01FDCF27@exchange4.ntu.edu.sg> From: Shen Gangxiang To: "'seenu@samsung.co.kr'" , mpls@UU.NET Subject: RE: mpls on ethernet Date: Wed, 26 Jul 2000 10:15:05 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I doubt why we need MPLS on ethernet. Does the cureent protocol for ethernet is not good enough? regards, Gangxiang -----Original Message----- From: seenu@samsung.co.kr [mailto:seenu@samsung.co.kr] Sent: Tuesday, July 25, 2000 9:58 PM To: mpls@UU.NET Subject: mpls on ethernet Hi, I am new to the mpls and have the following doubts. If any of u , have implemented this pls help me. For implementing mpls on ethernet : which part of ethernet frame can be used as LABEL. and which part of PPP frame can be used as LABEL, in case implementing mpls on PPP. How exactly I need to procede. Any references /suggestions pls..... regards seenu From owner-mpls@UU.NET Tue Jul 25 22:54: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 WAA14299 for ; Tue, 25 Jul 2000 22:54:45 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizlj24302; Wed, 26 Jul 2000 02:54:26 GMT Received: by mail-control.mail.uu.net id QQizlj20544 for mpls-outgoing; Wed, 26 Jul 2000 02:53: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 QQizlj20537 for ; Wed, 26 Jul 2000 02:53:45 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQizlj17617 for ; Tue, 25 Jul 2000 22:53:25 -0400 (EDT) Received: from fep9.mail.ozemail.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: fep9.mail.ozemail.net [203.2.192.103]) id QQizlj00046 for ; Wed, 26 Jul 2000 02:53:21 GMT Received: from stl006.ozemail.com.au (mail.internal.ozemail.com.au [203.108.14.42]) by fep9.mail.ozemail.net (8.9.0/8.6.12) with ESMTP id MAA26591; Wed, 26 Jul 2000 12:53:09 +1000 (EST) Received: by mail.internal.ozemail.com.au with Internet Mail Service (5.5.2650.21) id <3T9PFD6M>; Wed, 26 Jul 2000 12:55:35 +1000 Message-ID: <8FE2FC44AB31D311BF1D0000F806E19C04212527@mail-is.internal.ozemail.com.au> From: Abraham Kim To: "'Shen Gangxiang'" , "'seenu@samsung.co.kr'" , mpls@UU.NET Subject: RE: mpls on ethernet Date: Wed, 26 Jul 2000 12:53:08 +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 "For implementing mpls on ethernet?" Or, is the point "EMULATING MPLS on Ethernet"? __________________________________ Abraham Kim -----Original Message----- From: seenu@samsung.co.kr [mailto:seenu@samsung.co.kr] Sent: Tuesday, July 25, 2000 9:58 PM To: mpls@UU.NET Subject: mpls on ethernet Hi, I am new to the mpls and have the following doubts. If any of u , have implemented this pls help me. For implementing mpls on ethernet : which part of ethernet frame can be used as LABEL. and which part of PPP frame can be used as LABEL, in case implementing mpls on PPP. How exactly I need to procede. Any references /suggestions pls..... regards seenu From owner-mpls@UU.NET Tue Jul 25 23:53: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 XAA00508 for ; Tue, 25 Jul 2000 23:53:42 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizln06125; Wed, 26 Jul 2000 03:53:10 GMT Received: by mail-control.mail.uu.net id QQizln05001 for mpls-outgoing; Wed, 26 Jul 2000 03:52: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 QQizln04996 for ; Wed, 26 Jul 2000 03:52: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 QQizln25205 for ; Tue, 25 Jul 2000 23:52:27 -0400 (EDT) Received: from alpha.tellium.com by wodc7mr1.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQizln05604 for ; Wed, 26 Jul 2000 03:52:26 GMT Received: from tellium.com (client-151-198-92-212.bellatlantic.net [151.198.92.212] (may be forged)) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e6Q3jm504003; Tue, 25 Jul 2000 23:45:48 -0400 (EDT) Message-ID: <397E603F.DED369D2@tellium.com> Date: Tue, 25 Jul 2000 23:51:27 -0400 From: Bala Rajagopalan X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lang CC: "Bala Rajagopalan (E-mail)" , "'mpls@uu.net'" Subject: Re: FW: draft-bala-mpls-optical-uni-signaling-00.txt References: <51DA0AB3D747D311832F005004827CC02CE8E2@LUX> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: You are absolutely right. The abstract states that the draft relates to ongoing work and that the draft will evolve as work progresses in OIF. In any case, the disclaimer you state is very true. We'll include it in the next version. Regards, Bala Jonathan Lang wrote: > Bala, > In reading this draft (draft-bala-mpls-optical-uni-signaling-00.txt), I > came to the conclusion that a lot of people will assume these are OIF > APPROVED concepts/requirements for the optical UNI. Since I attend the > Signaling and Architecture groups of the OIF, I am only aware that the UNI > signaling requirements are a Work In Progress and nothing has been APPROVED > yet. > I am concerned that as the draft stands, it gives the impression that > these are APPROVED requirements. > The draft needs to be modified to explicitly state that "not all of the > concepts/requirements have been approved by the OIF". Furthermore, once the > requirements are APPROVED by the OIF, they should probably be communicated > through a formal liaison from the OIF to the IETF. > > Regards, > Jonathan > > Calient Networks > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/ms-tnef > Encoding: base64 -- Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com From owner-mpls@UU.NET Wed Jul 26 00:40: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 AAA11677 for ; Wed, 26 Jul 2000 00:39:59 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizlq05528; Wed, 26 Jul 2000 04:39:41 GMT Received: by mail-control.mail.uu.net id QQizlq18533 for mpls-outgoing; Wed, 26 Jul 2000 04:39: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 QQizlq18528 for ; Wed, 26 Jul 2000 04:39: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 QQizlq02830 for ; Wed, 26 Jul 2000 00:38:56 -0400 (EDT) Received: from tahoe.allegronetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tahoe.allegronetworks.com [206.14.65.10]) id QQizlq04852 for ; Wed, 26 Jul 2000 04:38:55 GMT Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Jul 2000 21:38:55 -0700 Message-ID: From: Prosenjit Pal To: "'mpls@UU.NET '" Cc: "'Pramoda Nallur '" Subject: RE: Reg. MPLS-RSVP LSP Tunnels... Date: Tue, 25 Jul 2000 21:38:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF6BB.6462B150" 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_01BFF6BB.6462B150 Content-Type: text/plain; charset="iso-8859-1" Hi Pramoda, You can aggregate two RSVP microflows and share the same LSP for both dataflow by selecting appropriate reservation style. But for signaling, RSVP PATH message needs to be processed at each hop in the path and needs to go to RSVP module at each node. Same is the story with RSVP RESV message. So why do you want to use an LSP to send PATH and RESV message, in the given topology? Thanks, Prosenjit Pal -----Original Message----- From: Pramoda Nallur To: Jahaapanah Alampanah Cc: mpls@UU.NET Sent: 7/25/00 9:12 AM Subject: Re: Reg. MPLS-RSVP LSP Tunnels... Jah, Jahaapanah Alampanah wrote: > Hi Jie, > > If I understand Nallur's problem statement > correctly, its got to do with aggregation > of RSVP micro flows into LSP Tunnels > setup by MPLS-RSVP. > > > An RSVP-LSP-Tunnel has already been established > between LER1 and LER2. Now a micro-flow RSVP > PATH message from S arrives at LER1. We want > this micro-flow to take the LSP. So if we just > tunnel this PATH message into the LSP, and > make it reach end-host R, the problem is > how do we transport the RESV message from R > back to S through the same LSP since this > is uni-directional? > You are right in your understanding. But, the question is, should the micro-flow PATH message be tunelled into the LSP at all ? - Pramoda. > > I hope Nallur agrees with this re-statement! > > All comments are welcome. > > -Jah > > -----Original Message----- > From: Jie Zou > To: Pramoda Nallur > Cc: mpls@UU.NET ; Dilip.Pandit@ind.alcatel.com > ; Kishore Rao ; > Manu.Prakash@ind.alcatel.com > Date: Tuesday, July 25, 2000 6:49 PM > Subject: Re: Reg. MPLS-RSVP LSP Tunnels... > > > > >I hope the following can answer a part of questions. > > > >According the darft, if A or B is a non-RSVP router, it can't convey > >labels via RSVP path. And it's neighber who knows it's non-RSVP > >router should send a PathErr back to the sender. > > > >If A or B is an RSVP router but doesn't recognize the LRO, it should > >send a PathErr toward the sender. > > > >If A or B is an RSVP router and recognize the LRO but not C_TYPE also > >sends a PathErr toward the sender. > > > >Else the Path msg should pass A and B toward the receiver and > >vice verse the Resv msg should pass the B and A toward the sender. > > > > > >Regards, > > > >----------------------------------------------------- > >Jie Zou (603)862-4212(Office) > >MPLS Consortium > >IOL, UNH (603)868-2983(Home) > >----------------------------------------------------- > > > >On Tue, 25 Jul 2000, Pramoda Nallur wrote: > > > >> Hi, > >> > >> I have a query on setting up RSVP MPLS LSPs in an ATM network. > >> [ Topology Driven LSP Setup Scenario ] > >> > >> Suppose the network configuration is as follows : > >> > >> S--A--LER1---LSR---LER2--B--R > >> > >> where, > >> S --> Sender(RSVP aware) > >> R --> Receiver(RSVP aware) > >> A, B --> Legacy IP Routers > >> LER1, LER2 and LSR --> MPLS-RSVP ATM switches. > >> > >> An LSP setup is initiated from LER1 with FEC=(S,R). > >> > >> The RSVP-TE PATH msg (with Sender=S, Session = Sess_R) creates an > >> RSVP Session, Sess_R at LER1, LSR and LER2. The Egress LER2 responds with > a > >> > >> RSVP-TE RESV msg reserving resources and sets up an LSP via LSR to LER1. > >> > >> After the LSP is setup, the RSVP-TE PATH msgs from LER1 and RSVP-TE RESV > >> msgs > >> from LER2 periodically refresh the RSVP reservation state on all nodes > >> along the LSP. > >> > >> Suppose, Sender S sends an RSVP PATH msg to R (with Session = Sess_R). > >> > >> 1. Will this PATH msg take the unlabelled path OR will it get switched > >> onto the LSP at LER1 ? > >> > >> 2. Also, how are the resulting RESV msgs from R propagated back to S ? > >> > >> 3. If these PATH and RESV msgs take the unlabelled path, will this result > >> in > >> resource allocation again along all nodes traversed by the LSP ? > >> > >> > >> The "RSVP-TE: Extensions to RSVP for LSP Tunnels" > >> (draft-ietf-mpls-rsvp-lsp-tunnel-06.txt) > >> does not mention how the above should be handled. > >> > >> Any comments on this ? > >> > >> - Pramoda Nallur > >> > > > > > > > > ____________________________________________________________________ > Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com. ------_=_NextPart_001_01BFF6BB.6462B150 Content-Type: text/html; charset="iso-8859-1" RE: Reg. MPLS-RSVP LSP Tunnels...

Hi Pramoda,

   You can aggregate two RSVP microflows and share the
same LSP for both dataflow by selecting appropriate
reservation style. But for signaling, RSVP PATH message
needs to be processed at each hop in the path and needs
to go to RSVP module at each node. Same is the story with
RSVP RESV message. So why do you want to use an LSP to
send PATH and RESV message, in the given topology?

Thanks,
Prosenjit Pal

-----Original Message-----
From: Pramoda Nallur
To: Jahaapanah Alampanah
Cc: mpls@UU.NET
Sent: 7/25/00 9:12 AM
Subject: Re: Reg. MPLS-RSVP LSP Tunnels...

Jah,

Jahaapanah Alampanah wrote:

> Hi Jie,
>
> If I understand Nallur's problem statement
> correctly, its got to do with aggregation
> of RSVP micro flows into LSP Tunnels
> setup by MPLS-RSVP.
>
>
> An RSVP-LSP-Tunnel has already been established
> between LER1 and LER2. Now a micro-flow RSVP
> PATH message from S arrives at LER1. We want
> this micro-flow to take the LSP. So if we just
> tunnel this PATH message into the LSP, and
> make it reach end-host R, the problem is
> how do we transport the RESV message from R
> back to S through the same LSP since this
> is uni-directional?
>

You are right in your understanding. But, the question is, should the
micro-flow PATH message
be tunelled into the LSP at all ?

- Pramoda.

>
> I hope Nallur agrees with this re-statement!
>
> All comments are welcome.
>
> -Jah
>
> -----Original Message-----
> From: Jie Zou <jzou@mars.iol.unh.edu>
> To: Pramoda Nallur <Pramoda.Nallur@ind.alcatel.com>
> Cc: mpls@UU.NET <mpls@UU.NET>; Dilip.Pandit@ind.alcatel.com
> <Dilip.Pandit@ind.alcatel.com>; Kishore Rao <kishore>;
> Manu.Prakash@ind.alcatel.com <Manu.Prakash@ind.alcatel.com>
> Date: Tuesday, July 25, 2000 6:49 PM
> Subject: Re: Reg. MPLS-RSVP LSP Tunnels...
>
> >
> >I hope the following can answer a part of questions.
> >
> >According the darft, if A or B is a non-RSVP router, it can't convey
> >labels via RSVP path. And it's neighber who knows it's non-RSVP
> >router should send a PathErr back to the sender.
> >
> >If A or B is an RSVP router but doesn't recognize the LRO, it should
> >send a PathErr toward the sender.
> >
> >If A or B is an RSVP router and recognize the LRO but not C_TYPE also
> >sends a PathErr toward the sender.
> >
> >Else the Path msg should pass A and B toward the receiver and
> >vice verse the Resv msg should pass the B and A toward the sender.
> >
> >
> >Regards,
> >
> >-----------------------------------------------------
> >Jie Zou (603)862-4212(Office)
> >MPLS Consortium
> >IOL, UNH (603)868-2983(Home)
> >-----------------------------------------------------
> >
> >On Tue, 25 Jul 2000, Pramoda Nallur wrote:
> >
> >> Hi,
> >>
> >> I have a query on setting up RSVP MPLS LSPs in an ATM network.
> >> [ Topology Driven LSP Setup Scenario ]
> >>
> >> Suppose the network configuration is as follows :
> >>
> >>     S--A--LER1---LSR---LER2--B--R
> >>
> >> where,
> >>     S                   --> Sender(RSVP aware)
> >>     R                   --> Receiver(RSVP aware)
> >>     A, B                --> Legacy IP Routers
> >>     LER1, LER2 and LSR  --> MPLS-RSVP ATM switches.
> >>
> >> An LSP setup is initiated from LER1 with FEC=(S,R).
> >>
> >> The RSVP-TE PATH msg (with Sender=S, Session = Sess_R) creates an
> >> RSVP Session, Sess_R at LER1, LSR and LER2. The Egress LER2
responds with
> a
> >>
> >> RSVP-TE RESV msg reserving resources and sets up an LSP via LSR to
LER1.
> >>
> >> After the LSP is setup, the RSVP-TE PATH msgs from LER1 and RSVP-TE
RESV
> >> msgs
> >> from LER2 periodically refresh the RSVP reservation state on all
nodes
> >> along the LSP.
> >>
> >> Suppose, Sender S sends an RSVP PATH msg to R (with Session =
Sess_R).
> >>
> >>  1. Will this PATH msg take the unlabelled path OR will it get
switched
> >> onto the LSP at LER1 ?
> >>
> >>  2. Also, how are the resulting RESV msgs from R propagated back to
S ?
> >>
> >>  3. If these PATH and RESV msgs take the unlabelled path, will this
result
> >> in
> >>     resource allocation again along all nodes traversed by the LSP
?
> >>
> >>
> >> The "RSVP-TE: Extensions to RSVP for LSP Tunnels"
> >> (draft-ietf-mpls-rsvp-lsp-tunnel-06.txt)
> >> does not mention how the above should be handled.
> >>
> >> Any comments on this ?
> >>
> >> - Pramoda Nallur
> >>
> >
> >
> >
>
> ____________________________________________________________________
> Get your own FREE, personal Netscape WebMail account today at
http://webmail.netscape.com.

------_=_NextPart_001_01BFF6BB.6462B150-- From owner-mpls@UU.NET Wed Jul 26 03:56: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 DAA25246 for ; Wed, 26 Jul 2000 03:56:47 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizmd02992; Wed, 26 Jul 2000 07:56:08 GMT Received: by mail-control.mail.uu.net id QQizmd02608 for mpls-outgoing; Wed, 26 Jul 2000 07:55: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 QQizmd02603 for ; Wed, 26 Jul 2000 07:55:33 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQizmd27591 for ; Wed, 26 Jul 2000 03:55:26 -0400 (EDT) Received: from ind.alcatel.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: postal.xylan.com [208.8.0.248]) id QQizmd01854 for ; Wed, 26 Jul 2000 07:55:21 GMT Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id AAA26935; Wed, 26 Jul 2000 00:55:19 -0700 (PDT) X-Origination-Site: Received: from k2.indc.xylan.com (indc.xylan.com [10.148.12.1]) by mailhub.ind.alcatel.com (8.8.8+Sun/8.8.8 (mailhub 3.2 [HUB])) with ESMTP id AAA19398; Wed, 26 Jul 2000 00:55:10 -0700 (PDT) Received: from ind.alcatel.com (mickey [10.148.16.18]) by k2.indc.xylan.com (8.8.8+Sun/8.8.8 (India 2.0 [SPOOL])) with ESMTP id AAA09506; Wed, 26 Jul 2000 00:55:01 -0700 (PDT) Message-ID: <397E9954.3D4A4F57@ind.alcatel.com> Date: Wed, 26 Jul 2000 13:25:00 +0530 From: Pramoda Nallur Reply-To: Pramoda.Nallur@ind.alcatel.com Organization: Alcatel Internetworking Division, INDIA X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Prosenjit Pal CC: "'mpls@UU.NET '" Subject: Re: Reg. MPLS-RSVP LSP Tunnels... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Prosenjit, > Hi Pramoda, > > You can aggregate two RSVP microflows and share the > same LSP for both dataflow by selecting appropriate > reservation style. But for signaling, RSVP PATH message > needs to be processed at each hop in the path and needs > to go to RSVP module at each node. Same is the story with > RSVP RESV message. So why do you want to use an LSP to > send PATH and RESV message, in the given topology? > Agreed that you can aggregate the two dataflows onto the same LSP, based on the reservation style. The point was that if the RSVP PATH/RESV messages (for the microflow) are processed at each hop along the path, you could be reserving resources twice - once when you set up the LSP and again due to the microflow RSVP messages. (Note that the reservations for the LSP would anyway be periodically refreshed by the ingress LER1.) - Pramoda. > > Thanks, > Prosenjit Pal > > -----Original Message----- > From: Pramoda Nallur > To: Jahaapanah Alampanah > Cc: mpls@UU.NET > Sent: 7/25/00 9:12 AM > Subject: Re: Reg. MPLS-RSVP LSP Tunnels... > > Jah, > > Jahaapanah Alampanah wrote: > > > Hi Jie, > > > > If I understand Nallur's problem statement > > correctly, its got to do with aggregation > > of RSVP micro flows into LSP Tunnels > > setup by MPLS-RSVP. > > > > > > An RSVP-LSP-Tunnel has already been established > > between LER1 and LER2. Now a micro-flow RSVP > > PATH message from S arrives at LER1. We want > > this micro-flow to take the LSP. So if we just > > tunnel this PATH message into the LSP, and > > make it reach end-host R, the problem is > > how do we transport the RESV message from R > > back to S through the same LSP since this > > is uni-directional? > > > > You are right in your understanding. But, the question is, should the > micro-flow PATH message > be tunelled into the LSP at all ? > > - Pramoda. > > > > > I hope Nallur agrees with this re-statement! > > > > All comments are welcome. > > > > -Jah > > > > -----Original Message----- > > From: Jie Zou > > To: Pramoda Nallur > > Cc: mpls@UU.NET ; Dilip.Pandit@ind.alcatel.com > > ; Kishore Rao ; > > Manu.Prakash@ind.alcatel.com > > Date: Tuesday, July 25, 2000 6:49 PM > > Subject: Re: Reg. MPLS-RSVP LSP Tunnels... > > > > > > > >I hope the following can answer a part of questions. > > > > > >According the darft, if A or B is a non-RSVP router, it can't convey > > >labels via RSVP path. And it's neighber who knows it's non-RSVP > > >router should send a PathErr back to the sender. > > > > > >If A or B is an RSVP router but doesn't recognize the LRO, it should > > >send a PathErr toward the sender. > > > > > >If A or B is an RSVP router and recognize the LRO but not C_TYPE also > > >sends a PathErr toward the sender. > > > > > >Else the Path msg should pass A and B toward the receiver and > > >vice verse the Resv msg should pass the B and A toward the sender. > > > > > > > > >Regards, > > > > > >----------------------------------------------------- > > >Jie Zou (603)862-4212(Office) > > >MPLS Consortium > > >IOL, UNH (603)868-2983(Home) > > >----------------------------------------------------- > > > > > >On Tue, 25 Jul 2000, Pramoda Nallur wrote: > > > > > >> Hi, > > >> > > >> I have a query on setting up RSVP MPLS LSPs in an ATM network. > > >> [ Topology Driven LSP Setup Scenario ] > > >> > > >> Suppose the network configuration is as follows : > > >> > > >> S--A--LER1---LSR---LER2--B--R > > >> > > >> where, > > >> S --> Sender(RSVP aware) > > >> R --> Receiver(RSVP aware) > > >> A, B --> Legacy IP Routers > > >> LER1, LER2 and LSR --> MPLS-RSVP ATM switches. > > >> > > >> An LSP setup is initiated from LER1 with FEC=(S,R). > > >> > > >> The RSVP-TE PATH msg (with Sender=S, Session = Sess_R) creates an > > >> RSVP Session, Sess_R at LER1, LSR and LER2. The Egress LER2 > responds with > > a > > >> > > >> RSVP-TE RESV msg reserving resources and sets up an LSP via LSR to > LER1. > > >> > > >> After the LSP is setup, the RSVP-TE PATH msgs from LER1 and RSVP-TE > RESV > > >> msgs > > >> from LER2 periodically refresh the RSVP reservation state on all > nodes > > >> along the LSP. > > >> > > >> Suppose, Sender S sends an RSVP PATH msg to R (with Session = > Sess_R). > > >> > > >> 1. Will this PATH msg take the unlabelled path OR will it get > switched > > >> onto the LSP at LER1 ? > > >> > > >> 2. Also, how are the resulting RESV msgs from R propagated back to > S ? > > >> > > >> 3. If these PATH and RESV msgs take the unlabelled path, will this > result > > >> in > > >> resource allocation again along all nodes traversed by the LSP > ? > > >> > > >> > > >> The "RSVP-TE: Extensions to RSVP for LSP Tunnels" > > >> (draft-ietf-mpls-rsvp-lsp-tunnel-06.txt) > > >> does not mention how the above should be handled. > > >> > > >> Any comments on this ? > > >> > > >> - Pramoda Nallur > > >> From owner-mpls@UU.NET Wed Jul 26 04:12: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 EAA28686 for ; Wed, 26 Jul 2000 04:12:19 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizme12460; Wed, 26 Jul 2000 08:11:58 GMT Received: by mail-control.mail.uu.net id QQizme14608 for mpls-outgoing; Wed, 26 Jul 2000 08:11: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 QQizme14603 for ; Wed, 26 Jul 2000 08:11: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 QQizme24669 for ; Wed, 26 Jul 2000 04:11:20 -0400 (EDT) Received: from tahoe.allegronetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: tahoe.allegronetworks.com [206.14.65.10]) id QQizme11843 for ; Wed, 26 Jul 2000 08:11:05 GMT Received: by tahoe.allegronetworks.com with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 01:11:04 -0700 Message-ID: From: Prosenjit Pal To: "'Nasser Yazdani '" , "'MPLS '" Subject: RE: A question Date: Wed, 26 Jul 2000 01:10:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF6D9.079BCB50" 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_01BFF6D9.079BCB50 Content-Type: text/plain; charset="iso-8859-1" Hi Nasser, Please refer to the following documents: 1. RFC2474 2. RFC2597 3. RFC2598 4. http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-06.txt Among 64 possible codepoints there are categories: 1. 64 possible DSCPs are classified into 3 pools : 32 of them (xxxxx0) are in Standards Action pool. 2. Among those 32 values, 8 of them (xxx000) are defined as Class Selector Code Points. 3. Some of the DSCPs are clubbed to form a group of PHB like Assured Forwarding PHB group. Again mapping DSCPs to EXP field can be either through configuration or through signaling. Depending on the type of LSP (i.e. L-LSP or E-LSP), EXP field can indicate scheduling treatment and/or drop precedence. Again these mappings can differ from one diff-serv domain to another. Hope it helps. Thanks, Prosenjit Pal -----Original Message----- From: Nasser Yazdani To: MPLS Sent: 7/25/00 7:29 AM Subject: A question Hi, does anybody knows how to map the DiffServ classes (64 classes) into the MPLS exp. fields (8 classes). Thanks, Regards, -- Nasser ------_=_NextPart_001_01BFF6D9.079BCB50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A question

Hi Nasser,

    Please refer to the following = documents:
1. RFC2474
2. RFC2597
3. RFC2598
4. http://www.ietf.org/internet-drafts/draft-ietf-mpls-di= ff-ext-06.txt

    Among 64 possible codepoints there = are categories:

1. 64 possible DSCPs are classified into 3 pools : 32 = of them
(xxxxx0) are in Standards Action pool.
2. Among those 32 values, 8 of them (xxx000) are = defined as
Class Selector Code Points.
3. Some of the DSCPs are clubbed to form a group of = PHB like
Assured Forwarding PHB group.

   Again mapping DSCPs to EXP field can be = either through
configuration or through signaling. Depending on the = type of
LSP (i.e. L-LSP or E-LSP), EXP field can indicate = scheduling
treatment and/or drop precedence. Again these = mappings can
differ from one diff-serv domain to another.

Hope it helps.

Thanks,
Prosenjit Pal

-----Original Message-----
From: Nasser Yazdani
To: MPLS
Sent: 7/25/00 7:29 AM
Subject: A question

Hi,

does anybody knows how to map the DiffServ classes = (64 classes) into the
MPLS exp. fields (8 classes). Thanks,

Regards,

-- Nasser

------_=_NextPart_001_01BFF6D9.079BCB50-- From owner-mpls@UU.NET Wed Jul 26 06:59: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 GAA06171 for ; Wed, 26 Jul 2000 06:59:13 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizmp20813; Wed, 26 Jul 2000 10:58:51 GMT Received: by mail-control.mail.uu.net id QQizmp16256 for mpls-outgoing; Wed, 26 Jul 2000 10:58:32 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQizmp16251 for ; Wed, 26 Jul 2000 10:58:27 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQizmp09227 for ; Wed, 26 Jul 2000 06:58:18 -0400 (EDT) From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQizmp20362 for ; Wed, 26 Jul 2000 10:58:18 GMT Received: from chqlubnt02.lon.bt.com by marvin (local) with ESMTP; Wed, 26 Jul 2000 11:57:58 +0100 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2651.88) id ; Wed, 26 Jul 2000 11:57:44 +0100 Message-ID: To: EGray@zaffire.com, lberger@labn.net, gja@dnrc.bell-labs.com Cc: mpls@UU.NET Subject: RE: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt Date: Wed, 26 Jul 2000 11:57:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > > PS The "-simple" approach is a totally new one. This is > > appropriate as > > draft-ietf-mpls-hdr-comp- and the 2507/8 are "one-hop" based, while > > "-simple" is multi-hop. > > Hmmm. I think there is plenty of work afoot that > leans toward treating an LSP as one hop. Indeed, > part of the issue with your approach is the fact > that "one-hop" is a bit of a stretchy notion... > [Harrison,N,Neil,INC1 X] I have no question in my mind that an LSP is '1-hop'. This is an obvious client/server layer relationship. In a more strict architectural sense "a client layer link = server layer trail".......this is indeed how one builds the topology of a client layer network from a server layer. This relationship recurses across all layers, starting from the 'duct'. Failure to appreciate (and adhere) to this fundamental principle will cause all sorts of downstream problems....many of which I have already observed cropping up in several areas such as DiffServ and the notion of a single control-plane across all layers (but the details are not for discussion here). From owner-mpls@UU.NET Wed Jul 26 08:02: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 IAA20718 for ; Wed, 26 Jul 2000 08:02:26 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizmu19084; Wed, 26 Jul 2000 12:02:05 GMT Received: by mail-control.mail.uu.net id QQizmu07540 for mpls-outgoing; Wed, 26 Jul 2000 12:01: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 QQizmu07391 for ; Wed, 26 Jul 2000 12:01: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 QQizmu15863; Wed, 26 Jul 2000 08:01:17 -0400 (EDT) Received: from exchange01.iirltd.co.uk by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [193.133.64.178]) id QQizmu18202; Wed, 26 Jul 2000 12:01:02 GMT Received: by exchange01.iirltd.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 13:01:09 +0100 Message-ID: From: sarah jones To: Richard Cooper Subject: MPLS Date: Wed, 26 Jul 2000 13:01:04 +0100 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 Hello, I am the producer of the IIR telecoms transmission conference and I have recently completed the programme for an MPLS conference running the 25th -28th Septemebr in London. As a member of the MPLS working party I thought that you might be interested to look at the completed programme www.iir-conferences.com/mpls If you have any feedback please let me know. Kind Regards Sarah Jones Senior Conference Producer, Transmission Events IIR Telecoms & Technology 0044 20 7915 5146 0044 20 7915 5001 From owner-mpls@UU.NET Wed Jul 26 09:44:47 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13345 for ; Wed, 26 Jul 2000 09:44:47 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizna04570; Wed, 26 Jul 2000 13:44:21 GMT Received: by mail-control.mail.uu.net id QQizna00139 for mpls-outgoing; Wed, 26 Jul 2000 13:43:29 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQizna00133 for ; Wed, 26 Jul 2000 13:43:22 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQizna08331 for ; Wed, 26 Jul 2000 09:42:59 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQizna04338 for ; Wed, 26 Jul 2000 13:42:57 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA28263 for mpls@uu.net; Wed, 26 Jul 2000 09:42:57 -0400 (EDT) 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 QQizna00117 for ; Wed, 26 Jul 2000 13:42:37 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizna08231 for ; Wed, 26 Jul 2000 09:42:28 -0400 (EDT) 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 QQizna02379 for ; Wed, 26 Jul 2000 13:42:12 GMT Received: from localhost (yakov@localhost) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id GAA17288; Wed, 26 Jul 2000 06:41:39 -0700 (PDT) Message-Id: <200007261341.GAA17288@omega.cisco.com> To: Rahul Aggarwal cc: Markus Jork , Kireeti Kompella , mpls@UU.NET Subject: Re: New Internet Draft: TE over Unnumbered Links In-reply-to: Your message of "Tue, 25 Jul 2000 11:12:53 PDT." <20000725111253.A490@malt.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17286.964618899.1@cisco.com> Date: Wed, 26 Jul 2000 06:41:39 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Rahul, Just to clarify, the ERO carries the *outgoing* interface index, not the *incoming* interface index (we'll clarify this in the next revision of the Internet Draft). Yakov. > Markus, > > On Tue, Jul 25, 2000 at 09:41:45AM -0400, Markus Jork wrote: > > Kireeti/Rahul, > > > > now you are confusing me. I thought the draft was pretty clear > > (although too concise). > > > > > > I thought it works like this: > > > > A----------B----------C---------D > > A1 B1 Ib Ic > > > > A-B is a numbered link, B-C and C-D are unnumbered. > > A1 and B1 are the interface addresses, Ib and Ic are the interface IDs > > and A, B, C and D are the router IDs. > > > > Then, the ERO sent by A would be: > > B1 Ib C Ic D (or replace B1 with B) > > Router B would then forward this ERO: > > C Ic D > > Router C would then forward this ERO: > > D > > > > This should work just fine and I thought it's what the draft says. > > Every router can verify whether it's the first subobject in the ERO > > and knows where to go next. > > There could be different ways of generating EROs. Your approach is one of the m. > The earlier mails were considering the case where the ERO has the incoming > interface index and not the outgoing interface index. And there is still > the case described by Kireeti where A could erroneously send the ERO to > some other router D. > > > > > The only problem is filling in the RRO in the Resv message > > going back. One alternative is to make router C add "C Ic" > > to the RRO. It would know Ic from the LIH in the NHOP object of > > the Resv message. The other alternative is to make router C add > > Interesting use of LIH ! I think it is overloading LIH semantics.. > > > "Ib C" to the RRO. It would have to look up Ib in the link state > > database. The second alternative is probably the right thing to do. > > If you were to use the ERO format as described by you, I would prefer the > second approach. > > > > > Markus > > > > > > > > C will receive the ero as . Now C needs to check the ero to see if > > > > it belongs to the first subobject i.e. Ic. How should this check be don e? > > > > This goes back to (1) above. > > > > > > I assume that C can tell which LSR it got the path msg from (i.e., B). > > > C then looks to see in its TE link state database if B is advertising > > > a link to C with index Ic. (I will add this to the next rev.) > > > > > > One could be more paranoid and add a router ID to the unnumbered ERO > > > subobject. Then the check is: a) does the router ID of the LSR sending > > > the path msg match the router ID in the subobject? AND b) if so, is > > > that LSR advertising a link to me with the index in the subobject (Ic)? > > > This approach is slightly more likely to catch errors because there are > > > two checks. Suppose for example A sent the first Path message to D (by > > > mistake) AND D didn't catch this error. Suppose also that D has an > > > unnumbered link to C with index Ic (same as B's). > > > > > > Now, when C gets the path msg from D (without the router ID), it will > > > erroneously accept it. However, for this to happen: A made a mistake; > > > D missed the mistake; and D had the same ifindex to C as B did. > > > > > > Thanks for your comments! > > > > > > Kireeti. > > > > > > > > > From owner-mpls@UU.NET Wed Jul 26 09:54: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 JAA14926 for ; Wed, 26 Jul 2000 09:54:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiznb14109; Wed, 26 Jul 2000 13:53:50 GMT Received: by mail-control.mail.uu.net id QQiznb00968 for mpls-outgoing; Wed, 26 Jul 2000 13:53:15 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: intcache02.uu.net [153.39.50.42]) id QQiznb00963 for ; Wed, 26 Jul 2000 13:53: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 QQiznb10683 for ; Wed, 26 Jul 2000 09:52:52 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQiznb12983 for ; Wed, 26 Jul 2000 13:52:37 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA00082 for mpls@uu.net; Wed, 26 Jul 2000 09:52:36 -0400 (EDT) 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 QQiznb00939 for ; Wed, 26 Jul 2000 13:52:13 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiznb02841 for ; Wed, 26 Jul 2000 09:51:52 -0400 (EDT) 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 QQiznb12308 for ; Wed, 26 Jul 2000 13:51:51 GMT Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Wed, 26 Jul 2000 14:45:55 +0100 Received: from zvb1c002.corpemea.baynetworks.com ([141.251.160.82]) by zhard00m.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 3VQ5PLSL; Wed, 26 Jul 2000 14:43:58 +0100 Received: from nortelnetworks.com (LANDERSS [141.251.192.188]) by zvb1c002.corpemea.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id PVWB2WSV; Wed, 26 Jul 2000 15:43:57 +0200 Message-ID: <397EEB5E.B3D948A1@nortelnetworks.com> Date: Wed, 26 Jul 2000 15:45:02 +0200 X-Sybari-Space: 00000000 00000000 00000000 From: "Loa Andersson" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: tom@ennovatenetworks.com, mpls@UU.NET Subject: Re: mpls-in-ip References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Neil and Tom, we been touching this before, but it is my view that LSPs (in the vanilla sense) are CL, ER-LSPs loosely routed are also CL, it takes certain measures ER routed and pinned down, to make them look and behave as CO entities. It might be argued that those CO look alikes are the only LSPs we want, but that is another story. /Loa neil.2.harrison@bt.com wrote: > > Hi Tom, > > Just an observation but......if we allow LSPs (ostensibly a CO entity) to be > a client layer of an IP server layer (a CNLS entity) will this not present > some *interesting* problems? For example: > - I guess IP would also be a client of the LSP.....and in theory one > could recurse this relationship many times; > - QoS control would be a issue (esp if there was no control over how > many times the recursion could exist......this is not just as a single > instance, but also in a concatenated sense); > - ........and so would defect handling and OAM in general. > > Have these factors been considered? > > neil -- Loa Andersson Director Routing Architecture Lab, EMEA St Eriksgatan 115A, PO Box 6701 113 85 Stockholm, Sweden phone: +46 8 50 88 36 34, mobile + 46 70 522 78 34 e-mail: loa.andersson@nortelnetworks.com From owner-mpls@UU.NET Wed Jul 26 11:00: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 LAA23972 for ; Wed, 26 Jul 2000 11:00:17 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiznf05272; Wed, 26 Jul 2000 14:59:48 GMT Received: by mail-control.mail.uu.net id QQiznf16295 for mpls-outgoing; Wed, 26 Jul 2000 14:59: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 QQiznf16285 for ; Wed, 26 Jul 2000 14:59: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 QQiznf22945 for ; Wed, 26 Jul 2000 10:58:53 -0400 (EDT) Received: from sol.extremenetworks.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sol.extremenetworks.com [216.52.8.2]) id QQiznf04442 for ; Wed, 26 Jul 2000 14:58:52 GMT Received: by SOL with Internet Mail Service (5.5.2650.21) id <3M496P5S>; Wed, 26 Jul 2000 07:59:03 -0700 Message-ID: <808F64DDB492D3119D3C00508B5D8D73599C84@SOL> From: Rana Dayal To: "'mpls@UU.NET'" Subject: MPLS Labels and VLAN Tags coexistence Date: Wed, 26 Jul 2000 07:59:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Is it OK to have both an IEEE VLAN Tag and MPLS labels in the same Ethernet frame? This would mean that the first Ethertype value would indicate that the VLAN tag was present and then MPLS would be indicated by the second Ethertype. Thanks, Rana From owner-mpls@UU.NET Wed Jul 26 11:02: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 LAA24354 for ; Wed, 26 Jul 2000 11:02:46 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizng14922; Wed, 26 Jul 2000 15:02:18 GMT Received: by mail-control.mail.uu.net id QQizng22078 for mpls-outgoing; Wed, 26 Jul 2000 15:01:39 GMT Received: from gen2.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen2.ffx.ops.us.uu.net [153.39.50.41]) id QQizng21562 for ; Wed, 26 Jul 2000 15:01: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 QQizng23624 for ; Wed, 26 Jul 2000 11:01:29 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQizng06634 for ; Wed, 26 Jul 2000 15:00:59 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA23247 for ; Wed, 26 Jul 2000 08:01:14 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA04946 for mpls@uu.net; Wed, 26 Jul 2000 11:00:57 -0400 (EDT) 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 QQizkr19018 for ; Tue, 25 Jul 2000 22:22: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 QQizkr17674 for ; Tue, 25 Jul 2000 18:22:25 -0400 (EDT) Received: from alpha.tellium.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQizkr17357 for ; Tue, 25 Jul 2000 22:22:24 GMT Received: from hotmail.com (client-151-198-92-141.bellatlantic.net [151.198.92.141] (may be forged)) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e6PMFed03148; Tue, 25 Jul 2000 18:15:40 -0400 (EDT) Message-ID: <397E150D.3BA298D4@hotmail.com> Date: Tue, 25 Jul 2000 18:30:37 -0400 From: Vasanthi Reply-To: tvasanthi@hotmail.com X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ramanjaneyulu Y T CC: mpls@UU.NET Subject: Re: RSVP VS LDP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, No. You don't have to use LDP to maintain the path/node state. RSVP is a soft-state protocol and the PATH/RESERVE exchanges are your tool to maintain path state. You can refer to RFC 2205 to understand how RSVP works. -Vasanthi Ramanjaneyulu Y T wrote: > Hi, > > I got one basic doubt in MPLS. For label distribution MPLS uses RSVP or > LDP. Suppose some one uses RSVP for label distribution, Is LDP required to > maintain path info., like node is alive or not or LSP is up or down?. I > guess the above tasks can also achievd with RSVP without LDP. If so > please suggest some reading material. > > Thanking you. > > Regards > Ramanjaneyulu Y.T. > > " A real friend is one who walks in when the rest of the world walks > out." > ------------------------------------------------------------------------------ > Y.T.RAMANJANEYULU | My other mail Ids: > E-70,INDIAN INSTITUTE OF SCIENCE | ytr@rediffmail.com > BANGALORE - 560012 | kingytr@excite.com > PH: 0091 - 080 - 3092622 ( HOSTEL ) | > 0091 - 080 - 3092906 ( LAB ) | > visit my home page:www2.csa.iisc.ernet.in/~ytr > -------------------------------------------------------------------------------- From owner-mpls@UU.NET Wed Jul 26 11:03: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 LAA24517 for ; Wed, 26 Jul 2000 11:03:51 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizng08762; Wed, 26 Jul 2000 15:03:22 GMT Received: by mail-control.mail.uu.net id QQizng24473 for mpls-outgoing; Wed, 26 Jul 2000 15:02: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 QQizng24419 for ; Wed, 26 Jul 2000 15:02: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 QQizng15916 for ; Wed, 26 Jul 2000 11:02:41 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQizng07616 for ; Wed, 26 Jul 2000 15:02:10 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA24463 for ; Wed, 26 Jul 2000 08:02:25 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA04959 for mpls@uu.net; Wed, 26 Jul 2000 11:02:08 -0400 (EDT) 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 QQizmz29040 for ; Wed, 26 Jul 2000 13:23: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 QQizmz26969 for ; Wed, 26 Jul 2000 09:22:54 -0400 (EDT) Received: from xover.hjinc.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQizmz19500 for ; Wed, 26 Jul 2000 13:22:54 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 09:19:16 -0400 Message-ID: <87009604743AD411B1F600508BA0F959040B57@xover.hjinc.com> From: "Sanford, Bill" To: "'mpls@uu.net'" Subject: EXPLICIT_ROUTE object too big for PATH or RESV message Date: Wed, 26 Jul 2000 09:19:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk In section 4.3.4.2. of draft-ietf-mpls-rsvp-lsp-tunnel-06.txt "After selecting a next hop, the node MAY alter the explicit route in the following ways. If, as part of executing the algorithm in section 4.3.4.1, the EXPLICIT_ROUTE object is removed, the node MAY add a new EXPLICIT_ROUTE object. Otherwise, if the node is a member of the abstract node for the first subobject, a series of subobjects MAY be inserted before the first subobject or MAY replace the first subobject. Each subobject in this series MUST denote an abstract node that is a subset of the current abstract node. Alternately, if the first subobject is a loose subobject, an arbitrary series of subobjects MAY be inserted prior to the first subobject." ***** I didn't see in the spec where if you have an EXPLICIT_ROUTE object and it is to big to fit into the PATH or RESV message, how it is handled. What happens when the first hop is loose, and a series of subobjects are inserted before the first subobject? Do we drop the message and return and error or does it get dropped and keep going? Bill From owner-mpls@UU.NET Wed Jul 26 11:04: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 LAA24586 for ; Wed, 26 Jul 2000 11:04:18 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizng16565; Wed, 26 Jul 2000 15:03:41 GMT Received: by mail-control.mail.uu.net id QQizng24598 for mpls-outgoing; Wed, 26 Jul 2000 15:03:03 GMT Received: from gen3.ffx.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: gen3.ffx.ops.us.uu.net [153.39.7.41]) id QQizng22933 for ; Wed, 26 Jul 2000 15:02: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 QQizng15851 for ; Wed, 26 Jul 2000 11:02:17 -0400 (EDT) Received: from sj-msg-core-2.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQizng07279 for ; Wed, 26 Jul 2000 15:01:46 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA24061 for ; Wed, 26 Jul 2000 08:02:01 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA04955 for mpls@uu.net; Wed, 26 Jul 2000 11:01:45 -0400 (EDT) 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 QQizlu03134 for ; Wed, 26 Jul 2000 05:41:40 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizlu04751 for ; Wed, 26 Jul 2000 01:41:08 -0400 (EDT) Received: from web704.mail.yahoo.com by wodc7mr2.ffx.ops.us.uu.net with SMTP (peer crosschecked as: web704.mail.yahoo.com [128.11.23.24]) id QQizlu29474 for ; Wed, 26 Jul 2000 05:41:08 GMT Received: (qmail 28262 invoked by uid 60001); 26 Jul 2000 05:41:36 -0000 Message-ID: <20000726054136.28261.qmail@web704.mail.yahoo.com> Received: from [203.197.178.227] by web704.mail.yahoo.com; Tue, 25 Jul 2000 22:41:36 PDT Date: Tue, 25 Jul 2000 22:41:36 -0700 (PDT) From: Kishore Rao Subject: RE: Reg. MPLS-RSVP LSP Tunnels... To: ppal@allegronetworks.com Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Pal, I guess Pramoda's worry is : Sending the PATH and RESV messages on the unlabelled path could result in additional resources being reserved along the path of the LSP apart from the ones reserved for the LSP, which is not desirable since the data flows would get mapped to the LSP and hence use the resources allocated for the LSP. The extra resources reserved would be unused. Hence the suggestion of sending RSVP control messages on the LSP, right Pramoda ? Regds Kishore Hi Pramoda, You can aggregate two RSVP microflows and share the same LSP for both dataflow by selecting appropriate reservation style. But for signaling, RSVP PATH message needs to be processed at each hop in the path and needs to go to RSVP module at each node. Same is the story with RSVP RESV message. So why do you want to use an LSP to send PATH and RESV message, in the given topology? Thanks, Prosenjit Pal -----Original Message----- From: Pramoda Nallur To: Jahaapanah Alampanah Cc: mpls@UU.NET Sent: 7/25/00 9:12 AM Subject: Re: Reg. MPLS-RSVP LSP Tunnels... Jah, Jahaapanah Alampanah wrote: > Hi Jie, > > If I understand Nallur's problem statement > correctly, its got to do with aggregation > of RSVP micro flows into LSP Tunnels > setup by MPLS-RSVP. > > > An RSVP-LSP-Tunnel has already been established > between LER1 and LER2. Now a micro-flow RSVP > PATH message from S arrives at LER1. We want > this micro-flow to take the LSP. So if we just > tunnel this PATH message into the LSP, and > make it reach end-host R, the problem is > how do we transport the RESV message from R > back to S through the same LSP since this > is uni-directional? > You are right in your understanding. But, the question is, should the micro-flow PATH message be tunelled into the LSP at all ? - Pramoda. > > I hope Nallur agrees with this re-statement! > > All comments are welcome. > > -Jah > > -----Original Message----- > From: Jie Zou > To: Pramoda Nallur > Cc: mpls@UU.NET ; Dilip.Pandit@ind.alcatel.com > ; Kishore Rao ; > Manu.Prakash@ind.alcatel.com > Date: Tuesday, July 25, 2000 6:49 PM > Subject: Re: Reg. MPLS-RSVP LSP Tunnels... > > > > >I hope the following can answer a part of questions. > > > >According the darft, if A or B is a non-RSVP router, it can't convey > >labels via RSVP path. And it's neighber who knows it's non-RSVP > >router should send a PathErr back to the sender. > > > >If A or B is an RSVP router but doesn't recognize the LRO, it should > >send a PathErr toward the sender. > > > >If A or B is an RSVP router and recognize the LRO but not C_TYPE also > >sends a PathErr toward the sender. > > > >Else the Path msg should pass A and B toward the receiver and > >vice verse the Resv msg should pass the B and A toward the sender. > > > > > >Regards, > > > >----------------------------------------------------- > >Jie Zou (603)862-4212(Office) > >MPLS Consortium > >IOL, UNH (603)868-2983(Home) > >----------------------------------------------------- > > > >On Tue, 25 Jul 2000, Pramoda Nallur wrote: > > > >> Hi, > >> > >> I have a query on setting up RSVP MPLS LSPs in an ATM network. > >> [ Topology Driven LSP Setup Scenario ] > >> > >> Suppose the network configuration is as follows : > >> > >> S--A--LER1---LSR---LER2--B--R > >> > >> where, > >> S --> Sender(RSVP aware) > >> R --> Receiver(RSVP aware) > >> A, B --> Legacy IP Routers > >> LER1, LER2 and LSR --> MPLS-RSVP ATM switches. > >> > >> An LSP setup is initiated from LER1 with FEC=(S,R). > >> > >> The RSVP-TE PATH msg (with Sender=S, Session = Sess_R) creates an > >> RSVP Session, Sess_R at LER1, LSR and LER2. The Egress LER2 responds with > a > >> > >> RSVP-TE RESV msg reserving resources and sets up an LSP via LSR to LER1. > >> > >> After the LSP is setup, the RSVP-TE PATH msgs from LER1 and RSVP-TE RESV > >> msgs > >> from LER2 periodically refresh the RSVP reservation state on all nodes > >> along the LSP. > >> > >> Suppose, Sender S sends an RSVP PATH msg to R (with Session = Sess_R). > >> > >> 1. Will this PATH msg take the unlabelled path OR will it get switched > >> onto the LSP at LER1 ? > >> > >> 2. Also, how are the resulting RESV msgs from R propagated back to S ? > >> > >> 3. If these PATH and RESV msgs take the unlabelled path, will this result > >> in > >> resource allocation again along all nodes traversed by the LSP ? > >> > >> > >> The "RSVP-TE: Extensions to RSVP for LSP Tunnels" > >> (draft-ietf-mpls-rsvp-lsp-tunnel-06.txt) > >> does not mention how the above should be handled. > >> > >> Any comments on this ? > >> > >> - Pramoda Nallur > >> > > > > > > > > ____________________________________________________________________ > Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape __________________________________________________ Do You Yahoo!? Get Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com/ From owner-mpls@UU.NET Wed Jul 26 11:56:20 2000 Received: from wodc7-2.corprelay.mail.uu.net (wodc7-2.corprelay.mail.uu.net [192.48.96.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09696 for ; Wed, 26 Jul 2000 11:56:20 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiznj05981; Wed, 26 Jul 2000 15:56:03 GMT Received: by mail-control.mail.uu.net id QQiznj01639 for mpls-outgoing; Wed, 26 Jul 2000 15:55: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 QQiznj01634 for ; Wed, 26 Jul 2000 15:55: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 QQiznj03737 for ; Wed, 26 Jul 2000 11:55:14 -0400 (EDT) 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 QQiznj05187 for ; Wed, 26 Jul 2000 15:55:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA21959 for mpls@uu.net; Wed, 26 Jul 2000 11:55:13 -0400 (EDT) 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 QQiznj01612 for ; Wed, 26 Jul 2000 15: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 QQiznj03623 for ; Wed, 26 Jul 2000 11:54:30 -0400 (EDT) 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 QQiznj19773 for ; Wed, 26 Jul 2000 15:54:14 GMT Received: from europe.cisco.com (europe.cisco.com [144.254.52.73]) by ogma.cisco.com (Postfix) with ESMTP id 73B686F1; Wed, 26 Jul 2000 17:48:47 +0200 (MET DST) Received: from flefauch-8kcdt.cisco.com (nice-dhcp3.cisco.com [144.254.60.25]) by europe.cisco.com (8.8.8+Sun/8.8.8) with SMTP id RAA00405; Wed, 26 Jul 2000 17:48:44 +0200 (MET DST) Message-Id: <200007261548.RAA00405@europe.cisco.com> X-Sender: flefauch@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Wed, 26 Jul 2000 17:45:23 +0200 To: Lou Berger From: Francois Le Faucheur Subject: RE: Two last calls (draft-ietf-mpls-diff-ext-06.txt) Cc: Francois Le Faucheur , Lou Berger , Shahram Davari , mpls@UU.NET In-Reply-To: <4.3.2.7.2.20000724114230.00d42730@mail.labn.net> References: <200007241523.RAA00638@europe.cisco.com> <4.3.2.7.2.20000721152734.00ccd970@mail.labn.net> <336ECDAFDF7DD311B9E30090277AEE4101B406A5@nt-exchange-bby.p mc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Lou, At 12:04 24/07/2000 -0400, Lou Berger wrote: > >How about including an "SHOULD" level option that allows a MPLS-DS LSR to >treat LSPs signaled without the DIFFSERV object as non-DS LSPs? I think >this would address this issue. > Just to be sure I understand the proposal: The text would say that when there is RSVP signaling without the Diff-Serv object, the LSR SHOULD (instead of MUST) interpret this as a request for an "E-LSP using Preconfigured EXP<-->PHB Mapping". (which would imply that if there's a really good reason to do otherwise - eg. to maintain some pre-Diff-Ext QoS support - then you could do so). If that's the proposal, that works for me. >(BTW which heterogeneity and transition issues are you addressing with the >objects proposed in your new draft?) > The new draft focuses on Diff-Serv-aware Traffic Engineering whereby different bandwidth constraints can be applied to different Diff-Serv Classes. This involves advertising more than one "unreserved bandwidth" information in IGPs and using the appropriate one for path computation for each Diff-Serv Class. Also, it involves performing admission control over different bandwidth pools at LSP set-up. The transition situation we focused on is when migrating from existing TE (which we refer to as "Aggregate TE") to "Diff-Serv-awrae-TE". More precisely , the migration situation involves a mix of: - "old" LSRs which are Diff-Serv capable and (Aggregate) TE capable (ie support a single bandwidth constraint, aka single bandwidth pool, aka compute the same route regardless of the Diff-Serv Class transported) - "new" LSRs which are Diff-Serv capable and Diff-Serv-aware-TE capable (ie support a multiple bandwidth constraints, aka multiple bandwidth pools, aka may compute different routes depending on the Diff-Serv Class transported). Note that we are not proposing new objects just to address this transition issue. Rather we are saying that the new objects/procedures that get defined for Diff-Serv-aware-TE MUST satisfy this migration goal. Hope that clarifies thanks Francois >Thanks, >Lou _________________________________________________________________ Francois Le Faucheur Development Engineer, IOS Layer 3 Services Cisco Systems Office Phone: +33 4 92 96 75 64 Home Office Phone: +33 4 92 94 00 78 Mobile : +33 6 89 108 159 Vmail: +33 1 58 04 62 66 Fax: +33 4 92 96 79 08 Email: flefauch@cisco.com _________________________________________________________________ Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France _________________________________________________________________ From owner-mpls@UU.NET Wed Jul 26 12:54: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 MAA20007 for ; Wed, 26 Jul 2000 12:54:33 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiznn04610; Wed, 26 Jul 2000 16:53:52 GMT Received: by mail-control.mail.uu.net id QQiznn17022 for mpls-outgoing; Wed, 26 Jul 2000 16:53: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 QQiznn16997 for ; Wed, 26 Jul 2000 16:53: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 QQiznn05353 for ; Wed, 26 Jul 2000 12:53:17 -0400 (EDT) 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 QQiznn27169 for ; Wed, 26 Jul 2000 16:53:16 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA00898 for mpls@uu.net; Wed, 26 Jul 2000 12:53:16 -0400 (EDT) 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 QQiznn16901 for ; Wed, 26 Jul 2000 16:52: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 QQiznn13741 for ; Wed, 26 Jul 2000 12:52:30 -0400 (EDT) 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 QQiznn25814 for ; Wed, 26 Jul 2000 16:52:00 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 MAA05375; Wed, 26 Jul 2000 12:51:59 -0400 (EDT) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA10441; Wed, 26 Jul 2000 12:51:58 -0400 (EDT) Message-Id: <200007261651.MAA10441@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Ron Bonica cc: Shahram Davari , "'mpls@UU.net'" , swallow@cisco.com Subject: Re: MPLS+ICMP In-reply-to: Your message of "Tue, 25 Jul 2000 11:31:35 CDT." Date: Wed, 26 Jul 2000 12:51:58 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Ron - Why don't you fix your small problem with the figure and resubmit it. That will kill two birds... Note that the blackout period is in effect (can't remember if they lift it at the beginning or end of the IETF meeting - you can find out by submitting it Monday). Rob has been holding off on this one until the base set gets approved. As soon as the RFCs are issued, this and a few others will go to IESG last call. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Jul 26 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 NAA23536 for ; Wed, 26 Jul 2000 13:10:56 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizno14273; Wed, 26 Jul 2000 17:10:33 GMT Received: by mail-control.mail.uu.net id QQizno29201 for mpls-outgoing; Wed, 26 Jul 2000 17:09: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 QQizno29196 for ; Wed, 26 Jul 2000 17:09: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 QQizno16555 for ; Wed, 26 Jul 2000 13:09:22 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQizno15145 for ; Wed, 26 Jul 2000 17:09:21 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA04039 for mpls@uu.net; Wed, 26 Jul 2000 13:09:21 -0400 (EDT) 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 QQizno29175 for ; Wed, 26 Jul 2000 17:08: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 QQizno16415 for ; Wed, 26 Jul 2000 13:08:39 -0400 (EDT) Received: from hawk.CrescentNetworks.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [208.177.194.54]) id QQizno12321 for ; Wed, 26 Jul 2000 17:08:39 GMT Received: from crescentnetworks.com (langille.in.crescentnets.com [192.168.29.105]) by hawk.CrescentNetworks.com (8.9.3/8.9.3) with ESMTP id NAA27269; Wed, 26 Jul 2000 13:08:34 -0400 (EDT) Message-ID: <397F1C45.283C1BAA@crescentnetworks.com> Date: Wed, 26 Jul 2000 13:13:41 -0400 From: Paul Langille Organization: Crescent Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Rana Dayal CC: "'mpls@UU.NET'" Subject: Re: MPLS Labels and VLAN Tags coexistence References: <808F64DDB492D3119D3C00508B5D8D73599C84@SOL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Rana Rana Dayal wrote: > Is it OK to have both an IEEE VLAN Tag and MPLS labels in the same Ethernet > frame? Yes. > This would mean that the first Ethertype value would indicate that > the VLAN tag was present and then MPLS would be indicated by the second > Ethertype. Yes, correct. (Check out section 5 of draft-ietf-mpls-label-encaps-07.txt.) Paul > > > Thanks, > Rana -- Paul Langille e-mail: langille@crescentnetworks.com Crescent Networks phone: (978) 244-9002 x244 201 Riverneck Road fax: (978) 244-9211 Chelmsford, MA 01824 From owner-mpls@UU.NET Wed Jul 26 13:14: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 NAA24291 for ; Wed, 26 Jul 2000 13:14:29 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizno18163; Wed, 26 Jul 2000 17:14:11 GMT Received: by mail-control.mail.uu.net id QQizno29514 for mpls-outgoing; Wed, 26 Jul 2000 17: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 QQizno29509 for ; Wed, 26 Jul 2000 17:13: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 QQizno17236 for ; Wed, 26 Jul 2000 13:13:16 -0400 (EDT) Received: from pilgrim.cisco.com by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQizno18143 for ; Wed, 26 Jul 2000 17:13:15 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA05029 for mpls@uu.net; Wed, 26 Jul 2000 13:13:14 -0400 (EDT) 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 QQizno29458 for ; Wed, 26 Jul 2000 17:12: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 QQizno08588 for ; Wed, 26 Jul 2000 13:12:18 -0400 (EDT) Received: from postal.redback.com by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: postal.redback.com [155.53.12.9]) id QQizno15732 for ; Wed, 26 Jul 2000 17:11:47 GMT Received: from malt.redback.com (malt.redback.com [155.53.12.41]) by postal.redback.com (Postfix) with ESMTP id 5B88017BC05; Wed, 26 Jul 2000 10:11:47 -0700 (PDT) Received: (from rahul@localhost) by malt.redback.com (8.9.3-LCCHA/8.9.3/null redback solaris client) id KAA16811; Wed, 26 Jul 2000 10:11:02 -0700 (PDT) Date: Wed, 26 Jul 2000 10:11:01 -0700 From: Rahul Aggarwal To: Yakov Rekhter Cc: Rahul Aggarwal , Markus Jork , Kireeti Kompella , mpls@UU.NET Subject: Re: New Internet Draft: TE over Unnumbered Links Message-ID: <20000726101101.A16592@malt.redback.com> References: <20000725111253.A490@malt.redback.com> <200007261341.GAA17288@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200007261341.GAA17288@omega.cisco.com> Sender: owner-mpls@UU.NET Precedence: bulk Yakov, I don't see why this needs to be specified. RSVP-TE draft does not impose any restrictions on the ERO format. Hence it could carry the outgoing interface index or the incoming. Thus there should be no need to specify this for the unnumbered case either. And going from the email exchange with Kireeti, the *incoming* interface index works just fine too. Just to be clear on terminology. I refer to Ib1 as the incoming and Ib2 as the outgoing interface index. A----------B----------C---------D Ib1 Ib2 Ic thanks, rahul On Wed, Jul 26, 2000 at 06:41:39AM -0700, Yakov Rekhter wrote: > Rahul, > > Just to clarify, the ERO carries the *outgoing* interface index, > not the *incoming* interface index (we'll clarify this in the next > revision of the Internet Draft). > > Yakov. > > > Markus, > > > > On Tue, Jul 25, 2000 at 09:41:45AM -0400, Markus Jork wrote: > > > Kireeti/Rahul, > > > > > > now you are confusing me. I thought the draft was pretty clear > > > (although too concise). > > > > > > > > > I thought it works like this: > > > > > > A----------B----------C---------D > > > A1 B1 Ib Ic > > > > > > A-B is a numbered link, B-C and C-D are unnumbered. > > > A1 and B1 are the interface addresses, Ib and Ic are the interface IDs > > > and A, B, C and D are the router IDs. > > > > > > Then, the ERO sent by A would be: > > > B1 Ib C Ic D (or replace B1 with B) > > > Router B would then forward this ERO: > > > C Ic D > > > Router C would then forward this ERO: > > > D > > > > > > This should work just fine and I thought it's what the draft says. > > > Every router can verify whether it's the first subobject in the ERO > > > and knows where to go next. > > > > There could be different ways of generating EROs. Your approach is one of the > m. > > The earlier mails were considering the case where the ERO has the incoming > > interface index and not the outgoing interface index. And there is still > > the case described by Kireeti where A could erroneously send the ERO to > > some other router D. > > > > > > > > The only problem is filling in the RRO in the Resv message > > > going back. One alternative is to make router C add "C Ic" > > > to the RRO. It would know Ic from the LIH in the NHOP object of > > > the Resv message. The other alternative is to make router C add > > > > Interesting use of LIH ! I think it is overloading LIH semantics.. > > > > > "Ib C" to the RRO. It would have to look up Ib in the link state > > > database. The second alternative is probably the right thing to do. > > > > If you were to use the ERO format as described by you, I would prefer the > > second approach. > > > > > > > > Markus > > > > > > > > > > > C will receive the ero as . Now C needs to check the ero to see if > > > > > it belongs to the first subobject i.e. Ic. How should this check be don > e? > > > > > This goes back to (1) above. > > > > > > > > I assume that C can tell which LSR it got the path msg from (i.e., B). > > > > C then looks to see in its TE link state database if B is advertising > > > > a link to C with index Ic. (I will add this to the next rev.) > > > > > > > > One could be more paranoid and add a router ID to the unnumbered ERO > > > > subobject. Then the check is: a) does the router ID of the LSR sending > > > > the path msg match the router ID in the subobject? AND b) if so, is > > > > that LSR advertising a link to me with the index in the subobject (Ic)? > > > > This approach is slightly more likely to catch errors because there are > > > > two checks. Suppose for example A sent the first Path message to D (by > > > > mistake) AND D didn't catch this error. Suppose also that D has an > > > > unnumbered link to C with index Ic (same as B's). > > > > > > > > Now, when C gets the path msg from D (without the router ID), it will > > > > erroneously accept it. However, for this to happen: A made a mistake; > > > > D missed the mistake; and D had the same ifindex to C as B did. > > > > > > > > Thanks for your comments! > > > > > > > > Kireeti. > > > > > > > > > > > > > > > From owner-mpls@UU.NET Wed Jul 26 13:14:51 2000 Received: from wodc7-1.corprelay.mail.uu.net (wodc7-1.corprelay.mail.uu.net [192.48.96.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24378 for ; Wed, 26 Jul 2000 13:14:51 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQizno19031; Wed, 26 Jul 2000 17:14:32 GMT Received: by mail-control.mail.uu.net id QQizno29536 for mpls-outgoing; Wed, 26 Jul 2000 17:13: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 QQizno29531 for ; Wed, 26 Jul 2000 17:13:56 GMT Received: from wodc7-2.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-2.corprelay.mail.uu.net [192.48.96.69]) id QQizno17300 for ; Wed, 26 Jul 2000 13:13:52 -0400 (EDT) Received: from apollo.mctr.umbc.edu by wodc7mr2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89]) id QQizno17520 for ; Wed, 26 Jul 2000 17:13:37 GMT Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142]) by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id NAA08984; Wed, 26 Jul 2000 13:13:36 -0400 (EDT) Received: from localhost (ayyangar@localhost) by mercury.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id NAA03120; Wed, 26 Jul 2000 13:17:13 -0400 (EDT) X-Authentication-Warning: mercury.mctr.umbc.edu: ayyangar owned process doing -bs Date: Wed, 26 Jul 2000 13:17:12 -0400 (EDT) From: Arthi Ayyangar X-Sender: ayyangar@mercury.mctr.umbc.edu To: Pramoda Nallur cc: Prosenjit Pal , "'mpls@UU.NET '" Subject: Re: Reg. MPLS-RSVP LSP Tunnels... In-Reply-To: <397E9954.3D4A4F57@ind.alcatel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk You may want to look at Section 2. of draft-baker-rsvp-aggregation-01.txt ( Aggregation of RSVP for IPv4 and IPv6 Reservations). That should answer your question. -arthi From owner-mpls@UU.NET Wed Jul 26 15:48: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 PAA26086 for ; Wed, 26 Jul 2000 15:48:44 -0400 (EDT) Received: from mail-control.mail.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQiznz13516; Wed, 26 Jul 2000 19:48:14 GMT Received: by mail-control.mail.uu.net id QQiznz02563 for mpls-outgoing; Wed, 26 Jul 2000 19:47: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 QQiznz02556 for ; Wed, 26 Jul 2000 19:47:05 GMT Received: from wodc7-1.corprelay.mail.uu.net by gen2.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7-1.corprelay.mail.uu.net [192.48.96.68]) id QQiznz19986 for ; Wed, 26 Jul 2000 15:46:46 -0400 (EDT) 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 QQiznz12161 for ; Wed, 26 Jul 2000 19:46:45 GMT Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 20:46:29 +0100 Message-ID: <6DEA508A9A0ED31192E80000F6CC176E2C9C99@monk.datcon.co.uk> From: Adrian Farrel To: swallow@cisco.com Cc: mpls@UU.NET Subject: Comments on draft-ietf-mpls-rsvp-lsp-tunnel-06 Date: Wed, 26 Jul 2000 20:46:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk George, A couple of questions and some minor editorial thoughts. Sorry if I'm revisiting old ground - if so please simply reply "see archive". Hope this is of use. Regards, Adrian Questions ========= 4.4.1.3 Recorded Label Subobject I can see how this is useful information for NM. Is the label completely useful without knowing the label space from which the label comes? This would be exposed as an interface index or a magic value for the global label space. This could easily be added to the subobject to give... 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Contents of Label Object | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ with the following text Interface Identifier The interface index that identifies the label space from which this label comes. A value of zero (0) indicates that the label comes from the global label space. 4.4.2 RRO Applicability The text inherited from the previous draft says that an RRO can be converted to an ERO "with minor changes". This has now been broken by the addition of the Label subobject. It would be unfortunate (but perhaps necessary?) to require that the RRO is parsed when pinning a session path. The alternative would appear to be to allow the Label object to be present but ignored in the ERO. 4.5 Processing RRO The text here describes adding the Label Record subobject whenever the SESSION_ATTRIBUTE indicate Label_Recording. Of course, this is typically only possible on the reverse path. Thus the RRO on he forward path need not include the LR subobject. 4.5 Processing RRO Can we allow for nodes that don't support adding Label Record subobjects? Or is this covered in "SHOULD"? Editorial ========= 2.6 Step 2. If DF bit not set step a) Would it be clearer (and no less accurate :-) to replace "the value of the parameter" with "M"? 3.2 Expanding leads to (optionally) two instances of for a single and