From owner-mpls@UU.NET Fri Dec 1 04:11:45 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08509 for ; Fri, 1 Dec 2000 04:11:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrqy07135; Fri, 1 Dec 2000 09:10:31 GMT Received: by mail-control.mail.uu.net id QQjrqy13176 for mpls-outgoing; Fri, 1 Dec 2000 09:10:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrqy13144 for ; Fri, 1 Dec 2000 09:10:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrqy12552 for ; Fri, 1 Dec 2000 09:09:18 GMT Received: from Yellow.japan-telecom.co.jp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: Yellow.japan-telecom.co.jp [210.146.35.35]) id QQjrqy16775 for ; Fri, 1 Dec 2000 09:09:17 GMT Received: from japan-telecom.co.jp (localhost [127.0.0.1]) by Yellow.japan-telecom.co.jp (3.7W-Yellow) with ESMTP id SAA09682; Fri, 1 Dec 2000 18:05:28 +0900 (JST) Received: (from root@localhost) by japan-telecom.co.jp (3.7W-SP340201) id SAA09974; Fri, 1 Dec 2000 18:09:19 +0900 (JST) Received: from unknown [172.18.84.49] by SP340201.japan-telecom.co.jp with SMTP id UAA09971 ; Fri, 1 Dec 2000 18:09:18 +0900 Message-ID: <00cb01c05b77$c2c99300$315412ac@pc3k6002> From: "Satoru Matsushima" To: Cc: Subject: Processing the MPLS TTL Date: Fri, 1 Dec 2000 18:19:08 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, According to draft-ietf-mpls-label-encaps-08.txt, > 2.4.3. IP-dependent rules > We define the "IP TTL" field to be the value of the IPv4 TTL field, > or the value of the IPv6 Hop Limit field, whichever is applicable. > > When an IP packet is first labeled, the TTL field of the label stack > entry MUST BE set to the value of the IP TTL field. (If the IP TTL > field needs to be decremented, as part of the IP processing, it is > assumed that this has already been done.) > > When a label is popped, and the resulting label stack is empty, then > the value of the IP TTL field SHOULD BE replaced with the outgoing > TTL value, as defined above. In IPv4 this also requires modification > of the IP header checksum. but this section had continue following. > It is recognized that there may be situations where a network > administration prefers to decrement the IPv4 TTL by one as it > traverses an MPLS domain, instead of decrementing the IPv4 TTL by the > number of LSP hops within the domain. I think that is very useful for VPNs, but this section had not consider this situations. Could somebody tell me the behavior of "ingress|egress LSR/LER" on this situations? Thanks in advance. -- Satoru Matsushima From owner-mpls@UU.NET Fri Dec 1 04:54:20 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01157 for ; Fri, 1 Dec 2000 04:54:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrrb06402; Fri, 1 Dec 2000 09:53:17 GMT Received: by mail-control.mail.uu.net id QQjrrb17068 for mpls-outgoing; Fri, 1 Dec 2000 09:52:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrrb17063 for ; Fri, 1 Dec 2000 09:52:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrrb24464 for ; Fri, 1 Dec 2000 09:52:09 GMT Received: from beamer.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQjrrb02946 for ; Fri, 1 Dec 2000 09:52:08 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 KAA10293; Fri, 1 Dec 2000 10:51:33 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA10604; Fri, 1 Dec 2000 10:52:06 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 10:52:04 +0100 Message-ID: From: Hummel Heinrich To: "'George Swallow'" , "Dawkins, Spencer" Cc: mpls@UU.NET Subject: AW: New MPLS charter Date: Fri, 1 Dec 2000 10:51:56 +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 Georg, you wrote"...we can define new ways of carrying labels where new kinds of link layers may emerge out of the Optical work". Let me think in this direction: Let me call all so far defined LSPs "User Plane LSPs" because they transmit user data (in such a way that no transit-LSR will evaluate the IP Header of the user data packets). We may define as well "Control Plane LSPs": They should transmit only messages for establishing/terminating User Plane LSPs. Hereby the "Control Plane" labels should only be used to determine the next hop( = replacement of the longest prefix match mechanism). Each transit-LSR should evaluate the IP Header and even the entire "Control Plane" packet =MPLS-message like RSVP-PATH or a CRLDP-LABEL_REQUEST,... Remains the question how and when to install the NHLFEs of the "Control Plane" labels: Well, BGP4, PIM, LDP-unsolicited downstream may be used to install them. The benefit: The establishing of User Plane LSPs by means of RSVP resp. LDP-downstream-on-demand, can be done almost as fast as transmitting user data by the User Plane LSP. Another goal: Studying and specifying the case where a Control Plane LSP and any of its associated User Plane LSPs only share the common endpoints but not the route between these endpoints. What do you think ? Heinrich Hummel Siemens AG heinrich.hummel@icn.siemens.de --------------------------------------------------------------------- > Spencer - > > The way I read that (and I would like to be wrong on this, but doubt > that I am) is we can define new ways of carrying labels where new > kinds of link layers may emerge out of the Optical work. Also I don't > really anticipate any need in that area, since we already have an > encapsulation over PPP and PPP is likely to be defined over any thing > that emerges out of the optical work. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Dec 1 06:38:08 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28895 for ; Fri, 1 Dec 2000 06:38:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrri19330; Fri, 1 Dec 2000 11:37:05 GMT Received: by mail-control.mail.uu.net id QQjrri19333 for mpls-outgoing; Fri, 1 Dec 2000 11:36:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrri19251 for ; Fri, 1 Dec 2000 11:36:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrri05090 for ; Fri, 1 Dec 2000 11:33:59 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrri27792 for ; Fri, 1 Dec 2000 11:33:59 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA15185 for mpls@uu.net; Fri, 1 Dec 2000 06:33:58 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrri19073 for ; Fri, 1 Dec 2000 11:33:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrri03304 for ; Fri, 1 Dec 2000 11:33:37 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjrri16936 for ; Fri, 1 Dec 2000 11:33: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 GAA25524; Fri, 1 Dec 2000 06:32:34 -0500 (EST) Message-Id: <200012011132.GAA25524@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-lmp-01.txt Date: Fri, 01 Dec 2000 06:32:34 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Link Management Protocol (LMP) Author(s) : J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter, L. Berger, B. Rajagopalan, D. Basak, H. Sandick, A. Zinin, A. Banerjee Filename : draft-ietf-mpls-lmp-01.txt Pages : 51 Date : 30-Nov-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-ietf-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-ietf-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-ietf-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 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: <20001130115149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lmp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lmp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130115149.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Dec 1 08:22:06 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24883 for ; Fri, 1 Dec 2000 08:22:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrrp07056; Fri, 1 Dec 2000 13:20:48 GMT Received: by mail-control.mail.uu.net id QQjrrp21796 for mpls-outgoing; Fri, 1 Dec 2000 13:20:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrrp21791 for ; Fri, 1 Dec 2000 13:20:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrrp26297 for ; Fri, 1 Dec 2000 13:20:05 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrrp15467 for ; Fri, 1 Dec 2000 13:20:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA21509 for mpls@uu.net; Fri, 1 Dec 2000 08:20:04 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrrp21744 for ; Fri, 1 Dec 2000 13:19:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrrp23674 for ; Fri, 1 Dec 2000 13:18:48 GMT Received: from procyon.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjrrp04235 for ; Fri, 1 Dec 2000 13:18:48 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id FAA06032; Fri, 1 Dec 2000 05:14:34 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 05:14:34 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AAC@BBY1EXM01> From: Shahram Davari To: "'Hummel Heinrich'" , "'George Swallow'" , "Dawkins, Spencer" Cc: mpls@UU.NET Subject: RE: New MPLS charter Date: Fri, 1 Dec 2000 05:14:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hummel, What is a control-plane label? Control-plane messages are not sent as labeled packets, rather they are sent as IP packets. Yours, -Shahram > -----Original Message----- > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > Sent: Friday, December 01, 2000 4:52 AM > To: 'George Swallow'; Dawkins, Spencer > Cc: mpls@UU.NET > Subject: AW: New MPLS charter > > > Georg, > > you wrote"...we can define new ways of carrying labels where > new kinds of link layers may emerge out of the Optical work". > Let me think in this direction: > Let me call all so far defined LSPs "User Plane LSPs" because > they transmit user data (in such a way that no transit-LSR will > evaluate the IP Header of the user data packets). > We may define as well "Control Plane LSPs": They should > transmit only messages for establishing/terminating User Plane LSPs. > Hereby the "Control Plane" labels should only be used to > determine the next hop( = replacement of the longest prefix > match mechanism). > Each transit-LSR should evaluate the IP Header and even the entire > "Control Plane" packet =MPLS-message like RSVP-PATH or a > CRLDP-LABEL_REQUEST,... > Remains the question how and when to install the NHLFEs of > the "Control Plane" labels: Well, BGP4, PIM, LDP-unsolicited > downstream may be used to install them. > > The benefit: The establishing of User Plane LSPs by means of > RSVP resp. LDP-downstream-on-demand, can be done > almost as fast as transmitting user data by the User Plane LSP. > > Another goal: > Studying and specifying the case where a Control Plane LSP > and any of its associated User Plane LSPs only share > the common endpoints but not the route between these endpoints. > > > What do you think ? > > Heinrich Hummel > Siemens AG > heinrich.hummel@icn.siemens.de > > > > --------------------------------------------------------------------- > > Spencer - > > > > The way I read that (and I would like to be wrong on this, but doubt > > that I am) is we can define new ways of carrying labels where new > > kinds of link layers may emerge out of the Optical work. > Also I don't > > really anticipate any need in that area, since we already have an > > encapsulation over PPP and PPP is likely to be defined over > any thing > > that emerges out of the optical work. > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > From owner-mpls@UU.NET Fri Dec 1 08:25:19 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26362 for ; Fri, 1 Dec 2000 08:25:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrrp07974; Fri, 1 Dec 2000 13:23:56 GMT Received: by mail-control.mail.uu.net id QQjrrp22174 for mpls-outgoing; Fri, 1 Dec 2000 13:23:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrrp22159 for ; Fri, 1 Dec 2000 13:23:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrrp06537 for ; Fri, 1 Dec 2000 13:22:56 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrrp06619 for ; Fri, 1 Dec 2000 13:22:56 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA21810 for mpls@uu.net; Fri, 1 Dec 2000 08:22:55 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrrp22057 for ; Fri, 1 Dec 2000 13:22:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrrp02969 for ; Fri, 1 Dec 2000 13:22:18 GMT Received: from procyon.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjrrp09288 for ; Fri, 1 Dec 2000 13:22:17 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id FAA07418 for ; Fri, 1 Dec 2000 05:22:16 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 05:22:16 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AAD@BBY1EXM01> From: Shahram Davari To: "'mpls@uu.net'" Subject: Remote peering Date: Fri, 1 Dec 2000 05:22:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi all, Could somebody please explain how LDP, CR-LDP, RSVP-TE could piggyback the remote peering information. Yours, Shahram Davari Systems Engineer Product Research Group PMC-Sierra, Inc. (Ottawa) Phone: (613) 271-4018 Fax: (613) 271-7007 From owner-mpls@UU.NET Fri Dec 1 08:43:49 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04797 for ; Fri, 1 Dec 2000 08:43:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrrq06369; Fri, 1 Dec 2000 13:42:23 GMT Received: by mail-control.mail.uu.net id QQjrrq23883 for mpls-outgoing; Fri, 1 Dec 2000 13:41:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrrq23877 for ; Fri, 1 Dec 2000 13:41:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrrq29551 for ; Fri, 1 Dec 2000 13:40:43 GMT Received: from beamer.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQjrrq03931 for ; Fri, 1 Dec 2000 13:40:42 GMT Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA09064; Fri, 1 Dec 2000 14:40:03 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA24847; Fri, 1 Dec 2000 14:40:36 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 14:40:35 +0100 Message-ID: From: Hummel Heinrich To: "'Shahram Davari'" , Hummel Heinrich , "'George Swallow'" , "Dawkins, Spencer" Cc: mpls@UU.NET Subject: AW: New MPLS charter Date: Fri, 1 Dec 2000 14:40:14 +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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA04797 Shahram, A label that pilots the packet (which is e.g. a Label_Request message) to the next hop router rather than by longest prefix match. To make it clear: Such kind of label hasn't been specified by any MPLS protocol yet ! You are absolutely right: So far, Control-plane messages are not sent as labeled packets, rather they are sent as IP packets. Yours, Heinrich > -----Urspr> üngliche Nachricht----- > Von: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > Gesendet am: Freitag, 1. Dezember 2000 14:15 > An: 'Hummel Heinrich'; 'George Swallow'; Dawkins, Spencer > Cc: mpls@UU.NET > Betreff: RE: New MPLS charter > > Hummel, > > What is a control-plane label? Control-plane messages are not sent as labeled packets, rather they are sent as IP packets. > > Yours, > -Shahram > > > -----Original Message----- > > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > > Sent: Friday, December 01, 2000 4:52 AM > > To: 'George Swallow'; Dawkins, Spencer > > Cc: mpls@UU.NET > > Subject: AW: New MPLS charter > > > > > > Georg, > > > > you wrote"...we can define new ways of carrying labels where > > new kinds of link layers may emerge out of the Optical work". > > Let me think in this direction: > > Let me call all so far defined LSPs "User Plane LSPs" because > > they transmit user data (in such a way that no transit-LSR will > > evaluate the IP Header of the user data packets). > > We may define as well "Control Plane LSPs": They should > > transmit only messages for establishing/terminating User Plane LSPs. > > Hereby the "Control Plane" labels should only be used to > > determine the next hop( = replacement of the longest prefix > > match mechanism). > > Each transit-LSR should evaluate the IP Header and even the entire > > "Control Plane" packet =MPLS-message like RSVP-PATH or a > > CRLDP-LABEL_REQUEST,... > > Remains the question how and when to install the NHLFEs of > > the "Control Plane" labels: Well, BGP4, PIM, LDP-unsolicited > > downstream may be used to install them. > > > > The benefit: The establishing of User Plane LSPs by means of > > RSVP resp. LDP-downstream-on-demand, can be done > > almost as fast as transmitting user data by the User Plane LSP. > > > > Another goal: > > Studying and specifying the case where a Control Plane LSP > > and any of its associated User Plane LSPs only share > > the common endpoints but not the route between these endpoints. > > > > > > What do you think ? > > > > Heinrich Hummel > > Siemens AG > > heinrich.hummel@icn.siemens.de > > > > > > > > --------------------------------------------------------------------- > > > Spencer - > > > > > > The way I read that (and I would like to be wrong on this, but doubt > > > that I am) is we can define new ways of carrying labels where new > > > kinds of link layers may emerge out of the Optical work. > > Also I don't > > > really anticipate any need in that area, since we already have an > > > encapsulation over PPP and PPP is likely to be defined over > > any thing > > > that emerges out of the optical work. > > > > > > ...George > > > > > > ================================================================== > > > George Swallow Cisco Systems (978) 244-8143 > > > 250 Apollo Drive > > > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Fri Dec 1 08:57:50 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11453 for ; Fri, 1 Dec 2000 08:57:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrrr25804; Fri, 1 Dec 2000 13:56:44 GMT Received: by mail-control.mail.uu.net id QQjrrr25336 for mpls-outgoing; Fri, 1 Dec 2000 13:56:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrrr25321 for ; Fri, 1 Dec 2000 13:56:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrrr15702 for ; Fri, 1 Dec 2000 13:55:16 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrrr23738 for ; Fri, 1 Dec 2000 13:55:16 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA25278 for mpls@uu.net; Fri, 1 Dec 2000 08:55:15 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrrr25169 for ; Fri, 1 Dec 2000 13:54:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrrr11115 for ; Fri, 1 Dec 2000 13:53:41 GMT Received: from procyon.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjrrr18887 for ; Fri, 1 Dec 2000 13:53:41 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id FAA12304; Fri, 1 Dec 2000 05:50:28 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 05:50:28 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AAE@BBY1EXM01> From: Shahram Davari To: "'Hummel Heinrich'" , "'George Swallow'" , "Dawkins, Spencer" Cc: mpls@UU.NET Subject: RE: New MPLS charter Date: Fri, 1 Dec 2000 05:50:25 -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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA11453 Hummel, What is wrong with the longest prefix match? besides how do you setup the labels for the control plane? Yours, -Shahram > -----Original Message----- > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > Sent: Friday, December 01, 2000 8:40 AM > To: Shahram Davari; Hummel Heinrich; 'George Swallow'; > Dawkins, Spencer > Cc: mpls@UU.NET > Subject: AW: New MPLS charter > > > Shahram, > A label that pilots the packet (which is e.g. a Label_Request > message) to the next hop router rather than by longest prefix match. > > To make it clear: > > Such kind of label hasn't been specified by any MPLS protocol yet ! > You are absolutely right: So far, Control-plane messages are > not sent as labeled packets, rather they are sent as IP packets. > > > Yours, > Heinrich > > -----Urspr> üngliche Nachricht----- > > Von: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > > Gesendet am: Freitag, 1. Dezember 2000 14:15 > > An: 'Hummel Heinrich'; 'George Swallow'; Dawkins, Spencer > > Cc: mpls@UU.NET > > Betreff: RE: New MPLS charter > > > > Hummel, > > > > What is a control-plane label? Control-plane messages are > not sent as labeled packets, rather they are sent as IP packets. > > > > Yours, > > -Shahram > > > > > -----Original Message----- > > > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > > > Sent: Friday, December 01, 2000 4:52 AM > > > To: 'George Swallow'; Dawkins, Spencer > > > Cc: mpls@UU.NET > > > Subject: AW: New MPLS charter > > > > > > > > > Georg, > > > > > > you wrote"...we can define new ways of carrying labels where > > > new kinds of link layers may emerge out of the Optical work". > > > Let me think in this direction: > > > Let me call all so far defined LSPs "User Plane LSPs" because > > > they transmit user data (in such a way that no transit-LSR will > > > evaluate the IP Header of the user data packets). > > > We may define as well "Control Plane LSPs": They should > > > transmit only messages for establishing/terminating User > Plane LSPs. > > > Hereby the "Control Plane" labels should only be used to > > > determine the next hop( = replacement of the longest prefix > > > match mechanism). > > > Each transit-LSR should evaluate the IP Header and even the entire > > > "Control Plane" packet =MPLS-message like RSVP-PATH or a > > > CRLDP-LABEL_REQUEST,... > > > Remains the question how and when to install the NHLFEs of > > > the "Control Plane" labels: Well, BGP4, PIM, LDP-unsolicited > > > downstream may be used to install them. > > > > > > The benefit: The establishing of User Plane LSPs by means of > > > RSVP resp. LDP-downstream-on-demand, can be done > > > almost as fast as transmitting user data by the User Plane LSP. > > > > > > Another goal: > > > Studying and specifying the case where a Control Plane LSP > > > and any of its associated User Plane LSPs only share > > > the common endpoints but not the route between these endpoints. > > > > > > > > > What do you think ? > > > > > > Heinrich Hummel > > > Siemens AG > > > heinrich.hummel@icn.siemens.de > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > Spencer - > > > > > > > > The way I read that (and I would like to be wrong on > this, but doubt > > > > that I am) is we can define new ways of carrying labels > where new > > > > kinds of link layers may emerge out of the Optical work. > > > Also I don't > > > > really anticipate any need in that area, since we > already have an > > > > encapsulation over PPP and PPP is likely to be defined over > > > any thing > > > > that emerges out of the optical work. > > > > > > > > ...George > > > > > > > > > ================================================================== > > > > George Swallow Cisco Systems > (978) 244-8143 > > > > 250 Apollo Drive > > > > Chelmsford, Ma 01824 > > > > From owner-mpls@UU.NET Fri Dec 1 09:10:24 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17314 for ; Fri, 1 Dec 2000 09:10:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrrs13445; Fri, 1 Dec 2000 14:09:17 GMT Received: by mail-control.mail.uu.net id QQjrrs07972 for mpls-outgoing; Fri, 1 Dec 2000 14:08:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrrs07963 for ; Fri, 1 Dec 2000 14:08:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrrs26789 for ; Fri, 1 Dec 2000 14:08:20 GMT Received: from mx4.tellabs.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx4.tellabs.com [204.68.180.54]) id QQjrrs08785 for ; Fri, 1 Dec 2000 14:08:19 GMT Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx4.tellabs.com (Mirapoint) with ESMTP id AAI11287; Fri, 1 Dec 2000 08:08:10 -0600 (CST) Received: from tellabs.com (dhcp-90-120.lisle.tellabs.com [138.111.90.120]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA09318; Fri, 1 Dec 2000 08:08:09 -0600 (CST) Message-ID: <3A27B046.52FE3E4A@tellabs.com> Date: Fri, 01 Dec 2000 08:05:58 -0600 From: Ben Mack-Crane X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: akyol@pluris.com CC: swallow@cisco.com, Spencer.DAWKINS@fnc.fujitsu.com, mpls@UU.NET Subject: Re: New MPLS charter References: <3A26FED6.627F1884@pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora, A proposed charter that is under consideration has been posted on the IETF Announcement mailing list. I have copied the message below (cut and paste from the archive). Regards, Ben WG Review: Common Control and Measurement Planes (coma) To: IETF-Announce: ; Subject: WG Review: Common Control and Measurement Planes (coma) From: The IESG Date: Mon, 20 Nov 2000 15:53:47 -0500 cc: new-work@ietf.org Reply-to: iesg@ietf.org Sender: scoya@cnri.reston.va.us A new IETF working group has been proposed in the IETF. The IESG has not made any determination as yet. The following Description was submitted, and is provided for informational purposes only: Common Control and Measurement Planes (coma) -------------------------------------------- Current Status: Proposed Working Group Organizational Overview The CoMa working group coordinates the work within the IETF towards defining a common control plane and a separate common measurement plane for ISP and SP core tunnel technologies. The purpose of the group, besides specifying the common control and the common measurement protocols, is to ensure that inputs and requirements from the MPLS, IPO, PPVPN and TE working groups (and future ones that may be formed on related topics) are completely taken into account, and that those working groups (and future related others) produce results that make best, cleanest use of the commonalities in control and the commonalities in measurement. Description of the Working Group: Over the last few years the need for common control and status protocols for representing and manipulating layer 1 and 2 resources has become more urgent. Particularly pressing is the need to accommodate switched optical networks where the intermediate switches, while controllable via IP-based protocols, are transparent above the physical layer to the data traffic flowing through them. From a control perspective, there is the need to perform such network engineering functions as traffic engineering, provisioning path protection and restoration, and path preemption in a common way across both physical and tunneled technologies. Common measurement is Independent of the actual control regime. It requires the ability to report on the status and properties of he subcomponent parts of a network (e.g. lambdas, fibers, PVCs, switch ports, optical cross connects) to elements such as external servers, the routing plane, or a database, and to report on the properties and liveness status of paths currently instantiated. This working group will tackle the problem of creating both the common control and common measurement planes for tunnels and phyical paths. It will deal with the technology-independent control and measurement aspects of traffic engineering, protection/restoration, and tunnel operation. It will define protocol support for resource sharing and preemption. It will ensure that the control and measurement protocols are capable of operation both within and across administrative boundaries. Both intra-domain and inter-domain scopes are important, and CoMa will design with both scopes in mind, however the working group may determine that intra-domain protocols require faster development than those that cross administrative boundaries. Specific tasks for the working group include the following: - Define a single control protocol and a single measurement protocol such that they are independent of each other. This allows the measurement protocol to be used by multiple consumers, including layer 3 routing protocols, centralized path computation servers, and passive path and resource monitoring devices, among others. Similarly, it allows the control protocol to use knowledge obtained by means other than the measurement protocol. Existing IETF protocols should be used as the basis for both protocols to every extent possible. - Define the control protocol and the measurement protocol such that they support multiple tunnel and physical path technologies (e.g. O-O and O-E-O optical switches, MPLS, GRE) using input from technology-specific working groups such as MPLS, IPO, etc. - Define and incorporate into the control and measurement protocols those network resource properties that are common across technologies. For properties which are technology-specific (e.g. wavelength-dependent dispersion of fiber paths) give guidance to the technology-specific group(s) for how to incorporate their parameters into the protocols. - Define how the properties of network resources gathered by the measurement protocol can be distributed in layer 3 routing protocols, such as OSPF and ISIS. This includes recommended methods for aggregation and summarization of data as needed for scalability. - Define the relationship between layer 3 routing protocols and the common control protocol for establishing and maintaining paths. - Using input from the TE working group, ensure that the control and measurement protocols provide both the information and the control functions adequate to support the traffic provisioning and engineering operations of service providers. - Ensure that multi-layer path protection and restoration functions are achievable using the defined control and measurement protocols, either separately or in combination. - Define protocol support for path measurement and liveness monitoring, including considerations of what the currency of the measure data needs to be, how much overhead can be tolerated for such measurement, and how the measurements impact various control mechanisms (including, but not limited to the common control protocol). Working Group Organization In doing this work, the WG will work closely with the following other WGs and constituencies: - Engage SPs to further refine service requirements from a Service Provider perspective and to ensure that such a protocol can work reasonably with existing management and provisioning systems. - Jointly develop any enhancements or modifications to the traffic engineering aspects of control plane operation with the TE working group - Jointly progress any IGP metrics/parameters with the ISIS and OSPF WGs - Accommodate technology specific input from the IPO WG, and other tunnel technologies as needed (e.g. GRE). In addition, The CoMA WG should ensure good communication with other standards bodies such as the ITU-T, and interoperability forums such as the OIF and ODSI engaged in IP/optical control plane work. But as is generally true with IETF working groups, formal liaison planning will be done by the IAB, and the communications flow about technical work will be on a technical and individual contributor basis otherwise. akyol@pluris.com wrote: > > So is there a charter for the new COMA working group, or a mailing list. > > Bora > > George Swallow wrote: > > > Spencer - > > > > The way I read that (and I would like to be wrong on this, but doubt > > that I am) is we can define new ways of carrying labels where new > > kinds of link layers may emerge out of the Optical work. Also I don't > > really anticipate any need in that area, since we already have an > > encapsulation over PPP and PPP is likely to be defined over any thing > > that emerges out of the optical work. > > > > ...George > > > > ================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Dec 1 09:25:09 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18564 for ; Fri, 1 Dec 2000 09:25:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrrt02630; Fri, 1 Dec 2000 14:23:11 GMT Received: by mail-control.mail.uu.net id QQjrrt09657 for mpls-outgoing; Fri, 1 Dec 2000 14:22:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrrt09634 for ; Fri, 1 Dec 2000 14:22:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrrt01411 for ; Fri, 1 Dec 2000 14:21:10 GMT Received: from beamer.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQjrrt26100 for ; Fri, 1 Dec 2000 14:21:04 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 PAA14604; Fri, 1 Dec 2000 15:20:29 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA25627; Fri, 1 Dec 2000 15:21:02 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 15:21:02 +0100 Message-ID: From: Hummel Heinrich To: "'Shahram Davari'" , Hummel Heinrich , "'George Swallow'" , "Dawkins, Spencer" Cc: mpls@UU.NET Subject: AW: New MPLS charter Date: Fri, 1 Dec 2000 15:20:40 +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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA18564 Shahram, Well why was label switching invented in the first place? Obviously, longest prefix match is slower than looking up the next interface and the next label based on an incoming label. Certainly, the profit is bigger when thousands of user packets are forwarded by label switching compared with one single "Label-Request"- packet being label-switched. However, there may be good reasons for fast path establishment as well:(optical !) path restoration, path rerouting,etc. I did not say that the existing way, i.e. forwarding an LSP-establishment message like a classic IP packet, shall be replaced, but there should be space for both methods ! I mentioned several protocols where to setup labels for the control plane: Particularly BGP4 and LDP(unsolicited downstream mode). Maybe OSPF too. Of course, it would take some study to find out the details and also how to differentiate these new animals from the existing ones:-) Heinrich > Hummel, > > What is wrong with the longest prefix match? besides how do you setup the labels for the control plane? > > Yours, > -Shahram > > > -----Original Message----- > > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > > Sent: Friday, December 01, 2000 8:40 AM > > To: Shahram Davari; Hummel Heinrich; 'George Swallow'; > > Dawkins, Spencer > > Cc: mpls@UU.NET > > Subject: AW: New MPLS charter > > > > > > Shahram, > > A label that pilots the packet (which is e.g. a Label_Request > > message) to the next hop router rather than by longest prefix match. > > > > To make it clear: > > > > Such kind of label hasn't been specified by any MPLS protocol yet ! > > You are absolutely right: So far, Control-plane messages are > > not sent as labeled packets, rather they are sent as IP packets. > > > > > > Yours, > > Heinrich > > > -----Urspr> > üngliche Nachricht----- > > > Von: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > > > Gesendet am: Freitag, 1. Dezember 2000 14:15 > > > An: 'Hummel Heinrich'; 'George Swallow'; Dawkins, Spencer > > > Cc: mpls@UU.NET > > > Betreff: RE: New MPLS charter > > > > > > Hummel, > > > > > > What is a control-plane label? Control-plane messages are > > not sent as labeled packets, rather they are sent as IP packets. > > > > > > Yours, > > > -Shahram > > > > > > > -----Original Message----- > > > > From: Hummel Heinrich [mailto:Heinrich.Hummel@icn.siemens.de] > > > > Sent: Friday, December 01, 2000 4:52 AM > > > > To: 'George Swallow'; Dawkins, Spencer > > > > Cc: mpls@UU.NET > > > > Subject: AW: New MPLS charter > > > > > > > > > > > > Georg, > > > > > > > > you wrote"...we can define new ways of carrying labels where > > > > new kinds of link layers may emerge out of the Optical work". > > > > Let me think in this direction: > > > > Let me call all so far defined LSPs "User Plane LSPs" because > > > > they transmit user data (in such a way that no transit-LSR will > > > > evaluate the IP Header of the user data packets). > > > > We may define as well "Control Plane LSPs": They should > > > > transmit only messages for establishing/terminating User > > Plane LSPs. > > > > Hereby the "Control Plane" labels should only be used to > > > > determine the next hop( = replacement of the longest prefix > > > > match mechanism). > > > > Each transit-LSR should evaluate the IP Header and even the entire > > > > "Control Plane" packet =MPLS-message like RSVP-PATH or a > > > > CRLDP-LABEL_REQUEST,... > > > > Remains the question how and when to install the NHLFEs of > > > > the "Control Plane" labels: Well, BGP4, PIM, LDP-unsolicited > > > > downstream may be used to install them. > > > > > > > > The benefit: The establishing of User Plane LSPs by means of > > > > RSVP resp. LDP-downstream-on-demand, can be done > > > > almost as fast as transmitting user data by the User Plane LSP.> > > > > > > > > Another goal: > > > > Studying and specifying the case where a Control Plane LSP > > > > and any of its associated User Plane LSPs only share > > > > the common endpoints but not the route between these endpoints. > > > > > > > > > > > > What do you think ? > > > > > > > > Heinrich Hummel > > > > Siemens AG > > > > heinrich.hummel@icn.siemens.de > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > Spencer - > > > > > > > > > > The way I read that (and I would like to be wrong on > > this, but doubt > > > > > that I am) is we can define new ways of carrying labels > > where new > > > > > kinds of link layers may emerge out of the Optical work. > > > > Also I don't > > > > > really anticipate any need in that area, since we > > already have an > > > > > encapsulation over PPP and PPP is likely to be defined over > > > > any thing > > > > > that emerges out of the optical work. > > > > > > > > > > ...George > > > > > > > > > > > > ================================================================== > > > > > George Swallow Cisco Systems > > (978) 244-8143 > > > > > 250 Apollo Drive > > > > > Chelmsford, Ma 01824 > > > > > > From owner-mpls@UU.NET Fri Dec 1 09:40:25 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19105 for ; Fri, 1 Dec 2000 09:40:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrru25541; Fri, 1 Dec 2000 14:39:26 GMT Received: by mail-control.mail.uu.net id QQjrru11296 for mpls-outgoing; Fri, 1 Dec 2000 14:38:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrru11286 for ; Fri, 1 Dec 2000 14:38:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrru17177 for ; Fri, 1 Dec 2000 14:36:19 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrru16999 for ; Fri, 1 Dec 2000 14:36:17 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA00735 for mpls@uu.net; Fri, 1 Dec 2000 09:36:17 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrru10885 for ; Fri, 1 Dec 2000 14:35:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrru14628 for ; Fri, 1 Dec 2000 14:35:27 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjrru28668 for ; Fri, 1 Dec 2000 14:35:26 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id GAA20000; Fri, 1 Dec 2000 06:32:08 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 06:32:08 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AB1@BBY1EXM01> From: Shahram Davari To: "'Hummel Heinrich'" , "'George Swallow'" , "Dawkins, Spencer" Cc: mpls@UU.NET Subject: RE: New MPLS charter Date: Fri, 1 Dec 2000 06:32: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 Hummel, > Shahram, > Well why was label switching invented in the first place? > Obviously, longest prefix match is slower than looking up the > next interface and the next label based on an incoming label. Although at the beginning of MPLS development it was believed that longest prefix match is slow and label switching will improve it, but future developments showed otherwise. In fact very good algorithms became available that could do a maximum of 3 lookups to do the longest prefix match. So the benefits of MPLS with regard to fast lookup diminished. > I mentioned several protocols where to setup labels for > the control plane: Particularly BGP4 and LDP(unsolicited > downstream mode). But you still need IP to transport BGP, LDP, ..., don't you? Yours, -Shahram From owner-mpls@UU.NET Fri Dec 1 09:52:35 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19472 for ; Fri, 1 Dec 2000 09:52:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrrv12594; Fri, 1 Dec 2000 14:51:21 GMT Received: by mail-control.mail.uu.net id QQjrrv12826 for mpls-outgoing; Fri, 1 Dec 2000 14:50:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrrv12821 for ; Fri, 1 Dec 2000 14:50:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrrv25443 for ; Fri, 1 Dec 2000 14:48:45 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjrrv08748 for ; Fri, 1 Dec 2000 14:48:44 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA26674 for ; Fri, 1 Dec 2000 06:48:45 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA24719 for mpls@uu.net; Fri, 1 Dec 2000 09:48:43 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrrl05377 for ; Fri, 1 Dec 2000 12:29:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrrl19449 for ; Fri, 1 Dec 2000 12:28:01 GMT Received: from internal.nci.com.au by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: internal.nci.com.au [203.38.215.137]) id QQjrrl06927 for ; Fri, 1 Dec 2000 12:27:59 GMT Received: from w95vmware.ns.com (ppp1.nci.com.au [172.30.0.161]) by internal.nci.com.au (8.9.3/8.9.3) with SMTP id WAA09586; Fri, 1 Dec 2000 22:54:50 +1030 Message-Id: <3.0.6.32.20001201230044.0099ca90@203.16.214.248> X-Sender: ns@203.16.214.248 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 01 Dec 2000 23:00:44 +1000 To: landerss@nortelnetworks.com, rhthomas@cisco.com From: Richard Sharpe Subject: LDP Dissector for Ethereal Cc: mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have just done a preliminary LDP dissector for Ethereal. It is available in the CVS tree and should be in the next release of Ethereal. I have been given a trace (of unknown provenance) that raises a question about alignment of TLVs. The draft I was working from (draft-ietf-mpls-ldp-11.txt) says that there are no alignment for TLVs, but the trace I have clearly shows TLVs being aligned on 4-byte boundaries. I have added a hack that skips the padding so I can continue to decode TLVs OK, but was wondering if there was any move towards allowing padding. Regards ------- Richard Sharpe, sharpe@ns.aus.com Samba (Team member, www.samba.org), Ethereal (Team member, www.zing.org) Contributing author, SAMS Teach Yourself Samba in 24 Hours Author, Special Edition, Using Samba From owner-mpls@UU.NET Fri Dec 1 10:13:02 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20058 for ; Fri, 1 Dec 2000 10:13:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrrw07903; Fri, 1 Dec 2000 15:11:36 GMT Received: by mail-control.mail.uu.net id QQjrrw26311 for mpls-outgoing; Fri, 1 Dec 2000 15:11:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrrw26257 for ; Fri, 1 Dec 2000 15:10:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrrw29830 for ; Fri, 1 Dec 2000 15:07:39 GMT Received: from beamer.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQjrrw02072 for ; Fri, 1 Dec 2000 15:07:38 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA20397; Fri, 1 Dec 2000 16:07:03 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA10469; Fri, 1 Dec 2000 16:07:37 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 16:07:37 +0100 Message-ID: From: Hummel Heinrich To: "'Shahram Davari'" , Hummel Heinrich , "'George Swallow'" , "Dawkins, Spencer" Cc: mpls@UU.NET Subject: AW: New MPLS charter Date: Fri, 1 Dec 2000 16:07:16 +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 > Shahram, > > Although at the beginning of MPLS development it was believed that longest prefix match is slow and label switching will improve it, but future developments showed otherwise. In fact very good algorithms became available that could do a maximum of 3 lookups to do the longest prefix match. So the benefits of MPLS with regard to fast lookup diminished. Good point. And I also believe that the existing label transport within BGP4 is an excellent move in the same direction that I am thinking. Give me some time to think about other good reasons. Routing is a large area, maybe anybody else find new reasons to do so !? :-) > > > I mentioned several protocols where to setup labels for > > the control plane: Particularly BGP4 and LDP(unsolicited > > downstream mode). > > But you still need IP to transport BGP, LDP, ..., don't you? Sure. > Yours, and have a good weekend > Heinrich From owner-mpls@UU.NET Fri Dec 1 10:23:42 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20446 for ; Fri, 1 Dec 2000 10:23:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrrx25819; Fri, 1 Dec 2000 15:21:02 GMT Received: by mail-control.mail.uu.net id QQjrrx27491 for mpls-outgoing; Fri, 1 Dec 2000 15:20:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrrx27483 for ; Fri, 1 Dec 2000 15:20:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrrx27829 for ; Fri, 1 Dec 2000 15:19:15 GMT Received: from ihemail2.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQjrrx23125 for ; Fri, 1 Dec 2000 15:19:14 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 KAA03928 for ; Fri, 1 Dec 2000 10:19:14 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA03921; Fri, 1 Dec 2000 10:19:14 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA05745; Fri, 1 Dec 2000 10:19:09 -0500 (EST) Message-ID: <3A27C169.E607791D@lucent.com> Date: Fri, 01 Dec 2000 10:19:05 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lang CC: "'mpls@uu.net'" Subject: Re: draft-ietf-mpls-lmp-01.txt References: <51DA0AB3D747D311832F005004827CC02CF0E2@lux.chromisys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan, Good work. I have no major concerns on other issues except the control channel management. First, it's not only control "channels", it's control "NETWORK". The control network has many strong requirement regarding reliability, security, performance and scalability. It has to be managed and operated as a "network" not a collection of individual control channels. Control channel "management" (as mechanisms used by BGP, LDP, etc.) actually only provide health check of the control "session" between neighbors. It's not as fast as low layer protocols. Again, the control "network" should take care of all requirements and can do much better. Control channel(session) "management" only serves as an add-on checking. Regarding your statement "Each bundled link is identified as described in [KRB00] and each bundled link MUST have an associated control channel". Is this a product specific requirement? In order for LMP to be a generic protocol, as I have said many times, control network should be considered independent of transport network. There should be no assumption of any correlation between these two networks. Back off a step, would you give me your reasons for this requirement? Why node level control session is not enough? A NE can have tens of bundles, too many control sessions hurt scalability and are not necessary. Regards, Yangguang > > *Separated out the functionality into a base core set (Control channel > management & Link property correlation procedure) and an extended set of > *negotiable* procedures (Test & Fault isolation procedure). The optional > procedures are negotiated as part of the generalized Config message > exchange. > > *Updated the link finite state machine (FSM) - now separated into an FSM for > the control channel and an FSM for the data-bearing links. From owner-mpls@UU.NET Fri Dec 1 10:24:46 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20510 for ; Fri, 1 Dec 2000 10:24:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrrx25513; Fri, 1 Dec 2000 15:23:24 GMT Received: by mail-control.mail.uu.net id QQjrrx27754 for mpls-outgoing; Fri, 1 Dec 2000 15:23:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrrx27715 for ; Fri, 1 Dec 2000 15:22:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrrx14578 for ; Fri, 1 Dec 2000 15:21:54 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrrx27332 for ; Fri, 1 Dec 2000 15:21:54 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA07866 for mpls@uu.net; Fri, 1 Dec 2000 10:21:53 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrrx27503 for ; Fri, 1 Dec 2000 15:20:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrrx02485 for ; Fri, 1 Dec 2000 15:17:58 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrrx29302 for ; Fri, 1 Dec 2000 15:17: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 KAA07131; Fri, 1 Dec 2000 10:17:56 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA12601; Fri, 1 Dec 2000 10:17:55 -0500 (EST) Message-Id: <200012011517.KAA12601@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Shahram Davari cc: "'Hummel Heinrich'" , "'George Swallow'" , "Dawkins, Spencer" , mpls@UU.NET, swallow@cisco.com Subject: Re: New MPLS charter In-reply-to: Your message of "Fri, 01 Dec 2000 06:32:05 PST." <9DC5E2ABE65BD54CA9088DA3194461D6010C9AB1@BBY1EXM01> Date: Fri, 01 Dec 2000 10:17:55 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Shahram - Small correction > Although at the beginning of MPLS development it was believed by some people who weren't paying close attention to advances in datastructures and ASIC designs that could take advantage of them > that > longest prefix match is slow and label switching will improve it, but > future developments showed otherwise. In fact very good algorithms > became available that could do a maximum of 3 lookups to do the > longest prefix match. So the benefits of MPLS with regard to fast > lookup diminished. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Dec 1 12:44:29 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29980 for ; Fri, 1 Dec 2000 12:44:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrsg18245; Fri, 1 Dec 2000 17:43:22 GMT Received: by mail-control.mail.uu.net id QQjrsg05387 for mpls-outgoing; Fri, 1 Dec 2000 17:42:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrsg05373 for ; Fri, 1 Dec 2000 17:42:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrsg11863 for ; Fri, 1 Dec 2000 17:40:31 GMT Received: from motgate.mot.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: motgate.mot.com [129.188.136.100]) id QQjrsg21750 for ; Fri, 1 Dec 2000 17:40:31 GMT Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA09434 for ; Fri, 1 Dec 2000 10:40:31 -0700 (MST)] Received: [from il02exb01.comm.mot.com (il02exb01.comm.mot.com [145.1.204.17]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA28249 for ; Fri, 1 Dec 2000 10:37:44 -0700 (MST)] Received: by il02exb01.comm.mot.com with Internet Mail Service (5.5.2651.58) id ; Fri, 1 Dec 2000 11:40:30 -0600 Message-ID: <01FAF65DEA16D4119B95009027E78F3149D8DE@il02exm26.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'mpls'" Subject: Multicast and MPLS Date: Fri, 1 Dec 2000 11:40:30 -0600 X-MS-TNEF-Correlator: <01FAF65DEA16D4119B95009027E78F3149D8DE@il02exm26.comm.mot.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C05BBD.CC4319B0" 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_01C05BBD.CC4319B0 Content-Type: text/plain; charset="iso-8859-1" All, I am new to this mailing list. Please pardon me if this question has been asked several times before. I see a lot of activity on this list about defining the charter and several new drafts in the areas of MPLS and RSVP and optical networks and so on. I was wondering about the status of IP multicast in MPLS. I have looked at several drafts that were out in this area, but have noticed that almost all of them have expired either late last year or sometime this year. I don't see any of these drafts refreshed or any new drafts in this area. Is multicast not in the current radar screen of this working group? Is the San Diego IETF even going to touch upon this area at all? Thanks for any pointers. Vidya ------_=_NextPart_000_01C05BBD.CC4319B0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+Ih8RAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0AcMAAEACwAoAB4ABQA6AQEggAMADgAAANAHDAAB AAsAKAAdAAUAOQEBCYABACEAAAAxMzFDRUY5RUE1QzdENDExOUJDRDAwOTAyN0U3OEYzMQA9BwEE gAEAEwAAAE11bHRpY2FzdCBhbmQgTVBMUwBlBgENgAQAAgAAAAIAAgABA5AGABAIAAAyAAAAAgFx AAEAAAAWAAAAAcBbvcv520VJpcegEdS9ZwAQpMVj/gAAAwDeP69vAAADAAiACCAGAAAAAADAAAAA AAAARgAAAABShQAA8BMAAB4ACYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADguNQAL AAqACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAMAC4AIIAYAAAAAAMAAAAAAAABGAAAAAAGF AAAAAAAACwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAALABSACCAGAAAAAADAAAAAAAAA RgAAAAAOhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAVgAggBgAAAAAA wAAAAAAAAEYAAAAAEYUAAAAAAAADABeACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4AJoAI IAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeACeACCAGAAAAAADAAAAAAAAARgAA AAA3hQAAAQAAAAEAAAAAAAAAHgAogAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAA AAsARIALIAYAAAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwBFgAsgBgAAAAAAwAAAAAAAAEYAAAAA BYgAAAAAAAACAQkQAQAAAH4CAAB6AgAAXwMAAExaRnWzsXKAAwAKAHJjcGcxMjUWMgD4C2BuDhAw MzNPAfcCpAPjAgBjaArAc7BldDAgBxMCgH0KgZJ2CJB3awuAZDQMYB5jAFALAwu1EWBsbCwDCqIK gEkgYW0gbqkH0XRvFPBoBAAgAMATAxALgGcgFbBzdC6gIFBsZWERICALAt8CIBVwFrAGkBUkcQpQ FiBuaRcREPAEIGIJ4RSAc+prCYAgESB2BJAHQBTw/wdzGMACEAlwFkAUcBEgFrDqYRXwbwVAbxeA ANAYMPkSIHR5G4ADoBUzFgIUgP0G4HUFQAEBC4AVwhUwFrB9EOJ0BJAUgBKAGWcUwmT/GbABgAQg C4AeAwrAFoEbghhNUEwF8B7SUlNWOlAew28FMA3gH2N0d30FsGsEIB7TFRACIBqyd/8YkSMQEoAG cRXRHSQeEhYgKGF0dSDzSSIAbXX+bCKCHPEgQSFCGrIQ8BmQ/RtBbxkyJeAZZx/VFTAooX53BJAW sB1CIEMVUSCyLPcYsB1RJ+NuG2AN4BlBKcP/B0AEYBzyE+Abgh4RFKAn4/BleHBpCXEuUBwQHiDf BcALYB6QL0Ec8XkWgAXA/wWxI7AHgBnyFSQv8hqyFwH2JyiyGxFuHDEtoxahH9X/CXADUAeQHiAi QR6yHDAfnv8q9RZAFBQUFRVhJqcsESA2nmMIcAlwAjAzoGFkCsH/BPEY0i2TFVEjEhXCCcAIYDxw PxrAKaIWsAYRIESFCJBnFRBJRVRGLlB/GZADoDwwHdMVEQhgEOAgXzsQHFYgsiiSLVE/NlpU/RDw biNBGnEyYz4AC4AekQRzLhQUVmlkeWELFBQR4QBC4AAAHgBwAAEAAAATAAAATXVsdGljYXN0IGFu ZCBNUExTAAALAAIAAQAAAAMA/T/kBAAAQAA5ALAZQ8y9W8ABAwDxPwkEAAAeADFAAQAAAAcAAABD Vk4wNjUAAAMAGkAAAAAAHgAwQAEAAAAHAAAAQ1ZOMDY1AAADABlAAAAAAAMAJgAAAAAAAwA2AAAA AAALAPIQAQAAAAMAgBD/////AgFHAAEAAAAwAAAAYz1VUzthPSA7cD1tb3Q7bD1JTDAyRVhNMjYt MDAxMjAxMTc0MDMwWi0zNDAxNDcAAgH5PwEAAABHAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAA AAAAAC9PPU1PVC9PVT1MTVBTSUwwMi9DTj1SRUNJUElFTlRTL0NOPUNWTjA2NQAAHgD4PwEAAAAX AAAATmFyYXlhbmFuIFZpZHlhLUNWTjA2NQAAHgA4QAEAAAAHAAAAQ1ZOMDY1AAACAfs/AQAAAEcA AAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TU9UL09VPUxNUFNJTDAyL0NOPVJFQ0lQ SUVOVFMvQ049Q1ZOMDY1AAAeAPo/AQAAABcAAABOYXJheWFuYW4gVmlkeWEtQ1ZOMDY1AAAeADlA AQAAAAcAAABDVk4wNjUAAEAABzCZ+jvMvVvAAUAACDBC+BPMvVvAAR4APQABAAAAAQAAAAAAAAAe AB0OAQAAABMAAABNdWx0aWNhc3QgYW5kIE1QTFMAAB4ANRABAAAAQAAAADwwMUZBRjY1REVBMTZE NDExOUI5NTAwOTAyN0U3OEYzMTQ5RDhERUBpbDAyZXhtMjYuY29tbS5tb3QuY29tPgALACkAAAAA AAsAIwAAAAAAAwAGELvM9wwDAAcQNgIAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABBTEws SUFNTkVXVE9USElTTUFJTElOR0xJU1RQTEVBU0VQQVJET05NRUlGVEhJU1FVRVNUSU9OSEFTQkVF TkFTS0VEU0VWRVJBTFRJTUVTQkVGT1JFSVNFRUFMT1RPRkFDVElWAAAAAAIBfwABAAAAQAAAADww MUZBRjY1REVBMTZENDExOUI5NTAwOTAyN0U3OEYzMTQ5RDhERUBpbDAyZXhtMjYuY29tbS5tb3Qu Y29tPgBntA== ------_=_NextPart_000_01C05BBD.CC4319B0-- From owner-mpls@UU.NET Fri Dec 1 13:01:33 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04362 for ; Fri, 1 Dec 2000 13:01:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrsh11614; Fri, 1 Dec 2000 17:59:59 GMT Received: by mail-control.mail.uu.net id QQjrsh06709 for mpls-outgoing; Fri, 1 Dec 2000 17:59:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrsh06697 for ; Fri, 1 Dec 2000 17:59:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrsh08385 for ; Fri, 1 Dec 2000 17:58:39 GMT Received: from dnsmx1pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQjrsh09645 for ; Fri, 1 Dec 2000 17:58:39 GMT Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id MAA03169 for ; Fri, 1 Dec 2000 12:56:18 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852569A8.00628192 ; Fri, 1 Dec 2000 12:55:56 -0500 X-Lotus-FromDomain: TELCORDIA From: "Hong Liao" To: mpls@UU.NET Message-ID: <852569A8.0062812E.00@notes949.cc.telcordia.com> Date: Fri, 1 Dec 2000 12:54:36 -0500 Subject: ospf support mpls Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hello, Is there someone who can tell me that there is any RFC or draft which describes ospf that supports mpls? Thanks, Julia From owner-mpls@UU.NET Fri Dec 1 17:35:45 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12477 for ; Fri, 1 Dec 2000 17:35:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrta01737; Fri, 1 Dec 2000 22:34:27 GMT Received: by mail-control.mail.uu.net id QQjrta29849 for mpls-outgoing; Fri, 1 Dec 2000 22:33:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrta29842 for ; Fri, 1 Dec 2000 22:33:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrta07096 for ; Fri, 1 Dec 2000 22:33:01 GMT Received: from mailbox.photonex.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.100.64.227]) id QQjrta13424 for ; Fri, 1 Dec 2000 22:33:01 GMT Received: from PEAR.photonex.com ([192.168.1.224]) by mailbox.photonex.com (Switch-2.0.6/Switch-2.0.6) with ESMTP id eB1MVvX16988; Fri, 1 Dec 2000 17:31:57 -0500 (EST) Message-Id: <5.0.0.25.2.20001201171923.038bf7b8@mailbox> X-Sender: fredette@mailbox X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 01 Dec 2000 17:33:29 -0500 To: George Swallow , vijay@cosinecom.com, Rob Coltun , oran@cisco.com From: "Andre N. Fredette" Subject: Re: New MPLS Charter? Cc: mpls@UU.NET In-Reply-To: <200011301441.JAA20900@lir.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I've seen a couple of opinions posted on how things might get sorted out. Are any of you working to sort out what goes where, and what this means for the upcoming meeting? Thanks, Andre At 09:41 AM 11/30/2000 -0500, George Swallow wrote: >Rob - > >It would have been nice if someone had pointed it out to me. > >This goes further toward shutting down MPLS than anything we discussed >in the past. > >If it is to be taken literally then *none* of the drafts into this >meeting belong in MPLS. > >Please let us know how to proceed. > >...George > >cc: mpls@uu.net > >================================================================== >George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Dec 1 20:21:44 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24743 for ; Fri, 1 Dec 2000 20:21:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrtl00785; Sat, 2 Dec 2000 01:20:52 GMT Received: by mail-control.mail.uu.net id QQjrtl19118 for mpls-outgoing; Sat, 2 Dec 2000 01:20:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrtl19082 for ; Sat, 2 Dec 2000 01:20:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrtl20062 for ; Sat, 2 Dec 2000 01:20:06 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjrtl21643 for ; Sat, 2 Dec 2000 01:20:05 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id UAA17984 for mpls@uu.net; Fri, 1 Dec 2000 20:20:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrtl19054 for ; Sat, 2 Dec 2000 01:19:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrtl16164 for ; Sat, 2 Dec 2000 01:18:51 GMT Received: from ce-nfs-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ce-nfs-1.cisco.com [171.68.202.251]) id QQjrtl13235 for ; Sat, 2 Dec 2000 01:18:50 GMT Received: from vjorge-dsl4.cisco.com (vjorge-dsl4.cisco.com [10.21.134.165]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA16947; Fri, 1 Dec 2000 17:18:45 -0800 (PST) Date: Fri, 1 Dec 2000 17:10:51 -0800 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: <13715.001201@cisco.com> To: Yangguang Xu CC: Jonathan Lang , "'mpls@uu.net'" Subject: Re: draft-ietf-mpls-lmp-01.txt In-reply-To: <3A27C169.E607791D@lucent.com> References: <3A27C169.E607791D@lucent.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 Yangguang, I'll take the liberty to answer your questions below. > Jonathan, > Good work. I have no major concerns on other issues except the control channel > management. > First, it's not only control "channels", it's control "NETWORK". The control > network has many strong requirement regarding reliability, security, performance > and scalability. It has to be managed and operated as a "network" not a > collection of individual control channels. The notion of the control channel does not substitute the notion of the control network. In fact, the control channel between two NEs uses the control network for transport services, i.e. LMP messages associated with control channels and bundles are delivered in IP packets. > Control channel "management" (as mechanisms used by BGP, LDP, etc.) actually > only provide health check of the control "session" between neighbors. It's not > as fast as low layer protocols. Again, the control "network" should take care of > all requirements and can do much better. Control channel(session) "management" > only serves as an add-on checking. In cases where the control channel spans more than one link, the health check and survival of the control network is insured by IGP protocols (OSPF/ISIS). In cases where LMP CC is between directly connected nodes, LMP Hello process helps faster detection of unreachable neighbors. > Regarding your statement "Each bundled link is identified as described in > [KRB00] and each bundled link MUST have an associated control channel". Is this > a product specific requirement? Which part are you referring to? > In order for LMP to be a generic protocol, as I > have said many times, control network should be considered independent of > transport network. There should be no assumption of any correlation between > these two networks. Back off a step, would you give me your reasons for this > requirement? Why node level control session is not enough? A NE can have tens of > bundles, too many control sessions hurt scalability and are not necessary. LMP assumes (and it is in the spec, I believe) that more than one bundle can be assigned to a single control channel, so there may be a single control channel between two NEs and it can be used to manage all component links. Hope this helps. Alex. > Regards, > Yangguang >> >> *Separated out the functionality into a base core set (Control channel >> management & Link property correlation procedure) and an extended set of >> *negotiable* procedures (Test & Fault isolation procedure). The optional >> procedures are negotiated as part of the generalized Config message >> exchange. >> >> *Updated the link finite state machine (FSM) - now separated into an FSM for >> the control channel and an FSM for the data-bearing links. From owner-mpls@UU.NET Fri Dec 1 22:36:34 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20070 for ; Fri, 1 Dec 2000 22:36:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrtu08773; Sat, 2 Dec 2000 03:35:26 GMT Received: by mail-control.mail.uu.net id QQjrtu22859 for mpls-outgoing; Sat, 2 Dec 2000 03:34:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrtu22847 for ; Sat, 2 Dec 2000 03:34:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrtu04117 for ; Sat, 2 Dec 2000 03:33:06 GMT Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQjrtu22170 for ; Sat, 2 Dec 2000 03:33:05 GMT Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 1 Dec 2000 22:32:53 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YB9MVD4D; Fri, 1 Dec 2000 22:32:52 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id W6NCNC60; Fri, 1 Dec 2000 22:32:55 -0500 Message-ID: <3A286D63.2C150F35@americasm01.nt.com> Date: Fri, 01 Dec 2000 22:32:51 -0500 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: New MPLS Charter? References: <200011301441.JAA20900@lir.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I can see how a literal interpretation of item 3) could cause problems. Being pragmatic let me suggest that we insert an indication that both implicit and explicit labels are part of the charter. I believe the literal interpretation that George is referring to is "explicit labels" and indeed if we are limited to explicit labels GMPLS is homeless. I am sure that is not the intention of the wording because it clearly talks about implicit label switching like wavlength and space so simply adding the words "implicit and explicit" should solve the problem. Cheers, Peter Ashwood-Smith > Rob - > > It would have been nice if someone had pointed it out to me. > > This goes further toward shutting down MPLS than anything we discussed > in the past. > > If it is to be taken literally then *none* of the drafts into this > meeting belong in MPLS. > > Please let us know how to proceed. > > ...George From owner-mpls@UU.NET Sat Dec 2 05:45:40 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14175 for ; Sat, 2 Dec 2000 05:45:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjruw11310; Sat, 2 Dec 2000 10:33:36 GMT Received: by mail-control.mail.uu.net id QQjruw15853 for mpls-outgoing; Sat, 2 Dec 2000 10:33:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjruw15847 for ; Sat, 2 Dec 2000 10:33:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjruw20857 for ; Sat, 2 Dec 2000 10:32:40 GMT Received: from relay2.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQjruw09879 for ; Sat, 2 Dec 2000 10:32:39 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.10.1) with SMTP id eB2ATAk08603; Sat, 2 Dec 2000 11:29:23 +0100 (MET) Received: from alcatel.be ([138.203.253.219]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569A9.0039D288; Sat, 2 Dec 2000 11:31:35 +0100 Message-ID: <3A28CE8B.754AA1A3@alcatel.be> Date: Sat, 02 Dec 2000 11:27:23 +0100 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.7 [nl] (Win98; U) X-Accept-Language: nl MIME-Version: 1.0 To: Satoru Matsushima CC: mpls@UU.NET, mpls-wg@janog.gr.jp Subject: Re: Processing the MPLS TTL References: <00cb01c05b77$c2c99300$315412ac@pc3k6002> Content-Type: multipart/alternative; boundary="------------DAE954C5CE2DC3C2881690BE" Sender: owner-mpls@UU.NET Precedence: bulk --------------DAE954C5CE2DC3C2881690BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Satoru, Please find included some information on the question you raised: > Could somebody tell me the behavior of "ingress|egress LSR/LER" on > this situations? > ** Ingress LSR: In this case the ingress LSR has to use for the MPLS header a TTL that is large enough to reach the egress LSR (that is, the TTL should not expire in the middle of the LSP). ** Egress LSR: At the egress LSR the TTL in the MPLS header is not copied into the IP header of the packet. Instead the TTL as is in the IP header is used. This 'TTL behavior' is -for the TTL aspect- similar to the 'TTL behavior' for IP over IP tunnels as defined in section 3.1 of RFC 2003 ('IP within IP'). Kind regards, Francis. -------------- ******************** *Extract from RFC 2003* ******************** 3.1. IP Header Fields and Handling The fields in the outer IP header are set by the encapsulator as follows: .... Time to Live The Time To Live (TTL) field in the outer IP header is set to a value appropriate for delivery of the encapsulated datagram to the tunnel exit point. ... When encapsulating a datagram, the TTL in the inner IP header is decremented by one if the tunneling is being done as part of forwarding the datagram; otherwise, the inner header TTL is not changed during encapsulation. If the resulting TTL in the inner IP header is 0, the datagram is discarded and an ICMP Time Exceeded message SHOULD be returned to the sender. An encapsulator MUST NOT encapsulate a datagram with TTL = 0. The TTL in the inner IP header is not changed when decapsulating. If, after decapsulation, the inner datagram has TTL = 0, the decapsulator MUST discard the datagram. If, after decapsulation, the decapsulator forwards the datagram to one of its network interfaces, it will decrement the TTL as a result of doing normal IP forwarding. See also Section 4.4. ... -------------- Satoru Matsushima schreef: > Hi all, > > According to draft-ietf-mpls-label-encaps-08.txt, > > > 2.4.3. IP-dependent rules > > > We define the "IP TTL" field to be the value of the IPv4 TTL field, > > or the value of the IPv6 Hop Limit field, whichever is applicable. > > > > When an IP packet is first labeled, the TTL field of the label stack > > entry MUST BE set to the value of the IP TTL field. (If the IP TTL > > field needs to be decremented, as part of the IP processing, it is > > assumed that this has already been done.) > > > > When a label is popped, and the resulting label stack is empty, then > > the value of the IP TTL field SHOULD BE replaced with the outgoing > > TTL value, as defined above. In IPv4 this also requires modification > > of the IP header checksum. > > but this section had continue following. > > > It is recognized that there may be situations where a network > > administration prefers to decrement the IPv4 TTL by one as it > > traverses an MPLS domain, instead of decrementing the IPv4 TTL by the > > number of LSP hops within the domain. > > I think that is very useful for VPNs, but this section had not consider > this situations. > > Could somebody tell me the behavior of "ingress|egress LSR/LER" on > this situations? > > Thanks in advance. > > -- > Satoru Matsushima --------------DAE954C5CE2DC3C2881690BE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hi Satoru,

Please find included some information on the question you raised: 

Could somebody tell me the behavior of "ingress|egress LSR/LER" on
  this situations?


** Ingress LSR:
In this case the ingress LSR has to use for the MPLS header a TTL that is large enough to reach the egress LSR (that is, the TTL should not expire in the middle of the LSP).

** Egress LSR:
At the egress LSR the TTL in the MPLS header is not copied into the IP header of the packet. Instead the TTL as is in the IP header is used.

This 'TTL behavior' is -for the TTL aspect- similar to the 'TTL behavior' for IP over IP tunnels as defined in section 3.1 of RFC 2003 ('IP within IP').

Kind regards,

    Francis.

--------------

        ********************
        *Extract from RFC 2003*
        ********************

3.1. IP Header Fields and Handling

   The fields in the outer IP header are set by the encapsulator as
   follows:

      ....

      Time to Live

         The Time To Live (TTL) field in the outer IP header is set to a
         value appropriate for delivery of the encapsulated datagram to
         the tunnel exit point.

    ...

   When encapsulating a datagram, the TTL in the inner IP header is
   decremented by one if the tunneling is being done as part of
   forwarding the datagram; otherwise, the inner header TTL is not
   changed during encapsulation.  If the resulting TTL in the inner IP
   header is 0, the datagram is discarded and an ICMP Time Exceeded
   message SHOULD be returned to the sender.  An encapsulator MUST NOT
   encapsulate a datagram with TTL = 0.

   The TTL in the inner IP header is not changed when decapsulating.
   If, after decapsulation, the inner datagram has TTL = 0, the
   decapsulator MUST discard the datagram.  If, after decapsulation, the
   decapsulator forwards the datagram to one of its network interfaces,
   it will decrement the TTL as a result of doing normal IP forwarding.
   See also Section 4.4.

    ...

--------------

Satoru Matsushima schreef:

Hi all,

According to draft-ietf-mpls-label-encaps-08.txt,

> 2.4.3. IP-dependent rules

>   We define the "IP TTL" field to be the value of the IPv4 TTL field,
>   or the value of the IPv6 Hop Limit field, whichever is applicable.
>
>   When an IP packet is first labeled, the TTL field of the label stack
>   entry MUST BE set to the value of the IP TTL field.  (If the IP TTL
>   field needs to be decremented, as part of the IP processing, it is
>   assumed that this has already been done.)
>
>   When a label is popped, and the resulting label stack is empty, then
>   the value of the IP TTL field SHOULD BE replaced with the outgoing
>   TTL value, as defined above.  In IPv4 this also requires modification
>   of the IP header checksum.

but this section had continue following.

>   It is recognized that there may be situations where a network
>   administration prefers to decrement the IPv4 TTL by one as it
>   traverses an MPLS domain, instead of decrementing the IPv4 TTL by the
>   number of LSP hops within the domain.

I think that is very useful for VPNs, but this section had not consider
this situations.

Could somebody tell me the behavior of "ingress|egress LSR/LER" on
this situations?

Thanks in advance.

--
Satoru Matsushima

--------------DAE954C5CE2DC3C2881690BE-- From owner-mpls@UU.NET Sat Dec 2 11:01:11 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28665 for ; Sat, 2 Dec 2000 11:01:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrvs01899; Sat, 2 Dec 2000 16:00:02 GMT Received: by mail-control.mail.uu.net id QQjrvr08507 for mpls-outgoing; Sat, 2 Dec 2000 15:59:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrvr08499 for ; Sat, 2 Dec 2000 15:59:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrvr01317 for ; Sat, 2 Dec 2000 15:58:10 GMT Received: from mail.hamdard.net.pk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.135.57.5]) id QQjrvr17369 for ; Sat, 2 Dec 2000 15:58:08 GMT Received: from faisal-s ([203.135.57.163]) by mail.hamdard.net.pk (8.9.3/8.9.3) with SMTP id UAA28426 for ; Sat, 2 Dec 2000 20:56:17 +0500 Message-ID: <000801c05c79$12ab7a80$a33987cb@faisal-s> From: "Faisal S. Naik" To: "mpls uunet" Subject: MPLS header Date: Sat, 2 Dec 2000 21:00:58 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello friends, can anyone point me to link where i can get some information specific to the fields of MPLS header.. i.e. what each field in the header is doing? regards, Faisal From owner-mpls@UU.NET Sat Dec 2 11:20:12 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02595 for ; Sat, 2 Dec 2000 11:20:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrvt26980; Sat, 2 Dec 2000 16:19:15 GMT Received: by mail-control.mail.uu.net id QQjrvt21908 for mpls-outgoing; Sat, 2 Dec 2000 16:18:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrvt21897 for ; Sat, 2 Dec 2000 16:18:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrvt00845 for ; Sat, 2 Dec 2000 16:17:38 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjrvt24665 for ; Sat, 2 Dec 2000 16:17:32 GMT Received: from babbage.csa.iisc.ernet.in (IDENT:root@babbage.csa.iisc.ernet.in [144.16.67.36]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id VAA13555 for ; Sat, 2 Dec 2000 21:44:41 +0530 Received: from localhost (prasanna@localhost) by babbage.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id VAA25979 for ; Sat, 2 Dec 2000 21:47:28 +0530 X-Authentication-Warning: babbage.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Sat, 2 Dec 2000 21:47:28 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Query about handling Non RSVP neighbours in RSVP-TE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I am eager to know the following as it was not clear to me from the draft. This is one of the paragrph from the draft 07.txt 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." This same message SHOULD be sent, if a router receives a LABEL_REQUEST object in a message from a non-RSVP capable router. See [1] for a description of how a downstream router can determine the presence of non-RSVP routers. Does it mean that if we find a non RSVP hop in between we should stop propogating Path mesages forward or does it mean that when we forward the path message it should not contain Label Request Object. If the latter is the correct option, then how can we acheive a proper setting up of an LSP. Because if we dont put Label Request Object in Path message there wont be any Label Object in Resv Message and if this haapens the we have failed to distribute labels to all the nodes along the path. So i think the first option is the correct one ?? Please let me know if i am wrong.... Thanx in advance Pras From owner-mpls@UU.NET Sat Dec 2 14:00:33 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24968 for ; Sat, 2 Dec 2000 14:00:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrwd26509; Sat, 2 Dec 2000 18:56:04 GMT Received: by mail-control.mail.uu.net id QQjrwd26732 for mpls-outgoing; Sat, 2 Dec 2000 18:55:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrwd26726 for ; Sat, 2 Dec 2000 18:55:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjrwd05558 for ; Sat, 2 Dec 2000 18:55:27 GMT Received: from harrier.prod.itd.earthlink.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: harrier.prod.itd.earthlink.net [207.217.121.12]) id QQjrwd12536 for ; Sat, 2 Dec 2000 18:55:26 GMT Received: from am (1Cust199.tnt15.tco2.da.uu.net [63.38.134.199]) by harrier.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id KAA14930; Sat, 2 Dec 2000 10:55:04 -0800 (PST) From: "Alex Mondrus" To: "Faisal S. Naik" , "mpls uunet" Subject: RE: MPLS header Date: Sat, 2 Dec 2000 14:10:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <000801c05c79$12ab7a80$a33987cb@faisal-s> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA24968 Faisal: You should review the following document http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-08.txt Alex Mondrus http://www.ipoptical.com From owner-mpls@UU.NET Sat Dec 2 14:43:32 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29715 for ; Sat, 2 Dec 2000 14:43:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrwg15855; Sat, 2 Dec 2000 19:42:35 GMT Received: by mail-control.mail.uu.net id QQjrwg12338 for mpls-outgoing; Sat, 2 Dec 2000 19:42:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrwg12331 for ; Sat, 2 Dec 2000 19:41:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrwg29232 for ; Sat, 2 Dec 2000 19:41:43 GMT Received: from mail.hamdard.net.pk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.135.57.5]) id QQjrwg00040 for ; Sat, 2 Dec 2000 19:41:41 GMT Received: from faisal-s ([203.135.57.199]) by mail.hamdard.net.pk (8.9.3/8.9.3) with SMTP id AAA29366 for ; Sun, 3 Dec 2000 00:39:50 +0500 Message-ID: <051d01c05c98$4d0791e0$c73987cb@faisal-s> From: "Faisal S. Naik" To: "mpls uunet" Subject: favour Date: Sun, 3 Dec 2000 00:44:33 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hello friends, can anyone give me a favour and get me this document, if it is not a big one to ask for? http://www.computer.org/proceedings/ic3n/9014/90140561abs.htm Thanks for it in advance. Regards, Faisal From owner-mpls@UU.NET Sun Dec 3 02:15:30 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18680 for ; Sun, 3 Dec 2000 02:15:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrya14792; Sun, 3 Dec 2000 07:14:31 GMT Received: by mail-control.mail.uu.net id QQjrya25400 for mpls-outgoing; Sun, 3 Dec 2000 07:14:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrya25384 for ; Sun, 3 Dec 2000 07:13:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrya19707 for ; Sun, 3 Dec 2000 07:13:48 GMT Received: from relay2.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQjrya19375 for ; Sun, 3 Dec 2000 07:13:47 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.10.1) with SMTP id eB37ADF29220; Sun, 3 Dec 2000 08:10:22 +0100 (MET) Received: from alcatel.be ([138.203.253.203]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569AA.00279D2A; Sun, 3 Dec 2000 08:12:41 +0100 Message-ID: <3A29F16C.A9CE8EF1@alcatel.be> Date: Sun, 03 Dec 2000 08:08:28 +0100 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.7 [nl] (Win98; U) X-Accept-Language: nl MIME-Version: 1.0 To: "Faisal S. Naik" CC: mpls uunet Subject: Re: MPLS header References: <000801c05c79$12ab7a80$a33987cb@faisal-s> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Faisal, For the MPLS SHIM header you can check out the draft-ietf-mpls-label-encaps-08.txt Kind regards, Francis. -------------- "Faisal S. Naik" schreef: > Hello friends, > can anyone point me to link where i can get some information specific to the > fields of MPLS header.. i.e. what each field in the header is doing? > regards, > Faisal From owner-mpls@UU.NET Sun Dec 3 07:21:40 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29238 for ; Sun, 3 Dec 2000 07:21:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjryv09495; Sun, 3 Dec 2000 12:20:41 GMT Received: by mail-control.mail.uu.net id QQjryv16972 for mpls-outgoing; Sun, 3 Dec 2000 12:20:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjryv16948 for ; Sun, 3 Dec 2000 12:19:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjryv02193 for ; Sun, 3 Dec 2000 12:18:38 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjryv12563 for ; Sun, 3 Dec 2000 12:18:35 GMT Received: from babbage.csa.iisc.ernet.in (IDENT:root@babbage.csa.iisc.ernet.in [144.16.67.36]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id RAA18714 for ; Sun, 3 Dec 2000 17:45:44 +0530 Received: from localhost (prasanna@localhost) by babbage.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id RAA07977 for ; Sun, 3 Dec 2000 17:48:32 +0530 X-Authentication-Warning: babbage.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Sun, 3 Dec 2000 17:48:32 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Question about L3PID in Label Request Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I want to know where i can get the standard ethertype values for specifying the L3PID in the Label Request Object ?? Please direct me to the appropriate document which specifies the values. Thanx in advance Pras From owner-mpls@UU.NET Sun Dec 3 08:33:32 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20462 for ; Sun, 3 Dec 2000 08:33:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrza22239; Sun, 3 Dec 2000 13:32:42 GMT Received: by mail-control.mail.uu.net id QQjrza04111 for mpls-outgoing; Sun, 3 Dec 2000 13:32:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjrza04100 for ; Sun, 3 Dec 2000 13:32:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjrza21776 for ; Sun, 3 Dec 2000 13:31:16 GMT Received: from blount.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: blount.mail.mindspring.net [207.69.200.226]) id QQjrza29259 for ; Sun, 3 Dec 2000 13:31:16 GMT Received: from mindspring.com (user-2ive3at.dialup.mindspring.com [165.247.13.93]) by blount.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id IAA18713; Sun, 3 Dec 2000 08:27:29 -0500 (EST) Message-ID: <3A2A4AA1.D1A100CB@mindspring.com> Date: Sun, 03 Dec 2000 08:29:05 -0500 From: Eric Gray Reply-To: ewgray@mindspring.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ashwood-Smith CC: mpls@UU.NET Subject: Re: New MPLS Charter? References: <200011301441.JAA20900@lir.cisco.com> <3A286D63.2C150F35@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Peter, The problem with including "implicit" labels in the MPLS working group charter is that doing so may defeat the intent of getting the charter down to a manageable size. GMPLS may be generic in its intent, but I think we all know that the focus remains on MPL(ambda)S. If the idea is to break up the charter into manageable chunks, MPL(ambda)S might be better off in the IPO working group. This is especially true, if MPL(ambda)S includes TDM time-slot assignment "label", optical waveband and optical fiber switching: if these are included, the delta between MPL(ambda)S and GMPLS is very small. As far as GMPLS is concerned, IMHO, we need to make a philosophical distinction as to whether GMPLS is intended to be a generalized use of MPLS signaling or an attempt generalize MPLS signaling. The distinction is a subtle one, but I think it's at the root of whether or not we (as individuals) feel GMPLS belongs in the MPLS working group. If it is intended to be a generalized use of MPLS signaling, then it should probably find a home elsewhere. If it is intended that MPLS signaling itself should be generalized, then it should be done in the MPLS working group. Again, IMHO, we should not try to generalize the set of protocols that apply to anything using MPLS - that seems like a rat-hole and contributes to a general atmosphere of FUD. -- Eric Gray Peter Ashwood-Smith wrote: > I can see how a literal interpretation of item 3) could cause problems. > Being pragmatic let me suggest that we insert an indication that both implicit > and explicit labels are part of the charter. > > I believe the literal interpretation that George is referring to is > "explicit labels" and indeed if we are limited to explicit labels GMPLS > is homeless. I am sure that is not the intention of the wording because > it clearly talks about implicit label switching like wavlength and space > so simply adding the words "implicit and explicit" should solve the problem. > > Cheers, > > Peter Ashwood-Smith > > > Rob - > > > > It would have been nice if someone had pointed it out to me. > > > > This goes further toward shutting down MPLS than anything we discussed > > in the past. > > > > If it is to be taken literally then *none* of the drafts into this > > meeting belong in MPLS. > > > > Please let us know how to proceed. > > > > ...George From owner-mpls@UU.NET Sun Dec 3 11:35:52 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13427 for ; Sun, 3 Dec 2000 11:35:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjrzm15333; Sun, 3 Dec 2000 16:31:11 GMT Received: by mail-control.mail.uu.net id QQjrzm22387 for mpls-outgoing; Sun, 3 Dec 2000 16:30:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjrzm22380 for ; Sun, 3 Dec 2000 16:30:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjrzl18175 for ; Sun, 3 Dec 2000 16:29:45 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjrzl23132 for ; Sun, 3 Dec 2000 16:29:42 GMT Received: from babbage.csa.iisc.ernet.in (IDENT:root@babbage.csa.iisc.ernet.in [144.16.67.36]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id VAA19564 for ; Sun, 3 Dec 2000 21:56:46 +0530 Received: from localhost (prasanna@localhost) by babbage.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id VAA11484; Sun, 3 Dec 2000 21:59:31 +0530 X-Authentication-Warning: babbage.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Sun, 3 Dec 2000 21:59:31 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Query regarding Path Err for RRO being too large for MTU. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I am unable to understand the use of the follwowing . Can somebody explain me this?? If the newly added subobject causes the RRO to be too big to fit in a Path (or Resv) message, the RRO object SHALL be dropped from the message and message processing continues as normal. A PathErr (or ResvErr) message SHOULD be sent back to the sender (or receiver). An error code of "Notify" and an error value of "RRO too large for MTU" is used. If the receiver receives such a ResvErr, it SHOULD send a PathErr message with error code of "Notify" and an error value of "RRO notification". A sender receiving either of these error values SHOULD remove the RRO from the Path message. ------------ Uptill this it is fine. But what about the following?? Nodes SHOULD resend the above PathErr or ResvErr message each n seconds where n is the greater of 15 and the refresh interval for the associated Path or RESV message. The node MAY apply limits and/or back-off timers to limit the number of messages sent. Why is this refreshing of PathErr required? and if its required then to what point of time we should stop sending these messages. ????? Please let me know.. thanx in advance Pras From owner-mpls@UU.NET Sun Dec 3 17:54:24 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10130 for ; Sun, 3 Dec 2000 17:54:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsal20561; Sun, 3 Dec 2000 22:53:03 GMT Received: by mail-control.mail.uu.net id QQjsal25652 for mpls-outgoing; Sun, 3 Dec 2000 22:52:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsal25646 for ; Sun, 3 Dec 2000 22:52:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsal04865 for ; Sun, 3 Dec 2000 22:52:37 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjsal19921 for ; Sun, 3 Dec 2000 22:52:36 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA21620 for mpls@uu.net; Sun, 3 Dec 2000 17:52:36 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsal25637 for ; Sun, 3 Dec 2000 22:52:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsal02267 for ; Sun, 3 Dec 2000 22:51:47 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjsal16004 for ; Sun, 3 Dec 2000 22:51:46 GMT Received: from localhost (yakov@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA21378; Sun, 3 Dec 2000 14:47:24 -0800 (PST) Message-Id: <200012032247.OAA21378@cisco.com> To: ewgray@mindspring.com cc: Peter Ashwood-Smith , mpls@UU.NET Subject: Re: New MPLS Charter? In-reply-to: Your message of "Sun, 03 Dec 2000 08:29:05 EST." <3A2A4AA1.D1A100CB@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21376.975883644.1@cisco.com> Date: Sun, 03 Dec 2000 14:47:24 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Eric, > The problem with including "implicit" labels in > the MPLS working group charter is that doing so > may defeat the intent of getting the charter down to > a manageable size. GMPLS may be generic in its > intent, but I think we all know that the focus remains > on MPL(ambda)S. If the idea is to break up the > charter into manageable chunks, MPL(ambda)S > might be better off in the IPO working group. This > is especially true, if MPL(ambda)S includes TDM > time-slot assignment "label", optical waveband and > optical fiber switching: if these are included, the delta > between MPL(ambda)S and GMPLS is very small. > > As far as GMPLS is concerned, IMHO, we > need to make a philosophical distinction as to > whether GMPLS is intended to be a generalized > use of MPLS signaling or an attempt generalize > MPLS signaling. The distinction is a subtle one, > but I think it's at the root of whether or not we > (as individuals) feel GMPLS belongs in the MPLS > working group. If it is intended to be a generalized > use of MPLS signaling, then it should probably > find a home elsewhere. If it is intended that MPLS > signaling itself should be generalized, then it should > be done in the MPLS working group. Would you consider draft-ashwood-generalized-mpls-signaling-01.txt as a generalized use of MPLS signalling, or as an attempt to generalize MPLS signalling ? Yakov. From owner-mpls@UU.NET Sun Dec 3 18:36:19 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19987 for ; Sun, 3 Dec 2000 18:36:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsao19095; Sun, 3 Dec 2000 23:34:56 GMT Received: by mail-control.mail.uu.net id QQjsao09838 for mpls-outgoing; Sun, 3 Dec 2000 23:34:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsao09833 for ; Sun, 3 Dec 2000 23:34:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsao13998 for ; Sun, 3 Dec 2000 23:34:14 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjsao18190 for ; Sun, 3 Dec 2000 23:34:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA23311 for mpls@uu.net; Sun, 3 Dec 2000 18:34:13 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsao09820 for ; Sun, 3 Dec 2000 23:34:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsao14659 for ; Sun, 3 Dec 2000 23:33:43 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjsao17735 for ; Sun, 3 Dec 2000 23:33:43 GMT Received: from bulkrate.cisco.com (bulkrate.cisco.com [171.71.160.24]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA05256; Sun, 3 Dec 2000 15:33:48 -0800 (PST) Received: from jlawrenc-pc.cisco.com (dhcp-64-104-219-210.cisco.com [64.104.219.210]) by bulkrate.cisco.com (Mirapoint) with ESMTP id ABF24680; Sun, 3 Dec 2000 15:33:39 -0800 (PST) Message-Id: <4.3.2.7.2.20001204102355.00af1b70@bulkrate.cisco.com> X-Sender: jlawrenc@bulkrate.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Dec 2000 10:32:38 +1100 To: "Hong Liao" From: Jeremy Lawrence Subject: Re: ospf support mpls Cc: mpls@UU.NET In-Reply-To: <852569A8.0062812E.00@notes949.cc.telcordia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Julia, >Is there someone who can tell me that there is any RFC or draft which describes >ospf that supports mpls? I'm not sure if this is the answer to your question, but any standards-track OSPF version will support MPLS, in the sense that LDP will work in conjunction with any interior gateway routing protocol, without requiring any modification to the protocol. There is also "Traffic Engineering Extensions to OSPF" http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-03.txt Jeremy Lawrence From owner-mpls@UU.NET Sun Dec 3 19:35:45 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05916 for ; Sun, 3 Dec 2000 19:35:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsas11878; Mon, 4 Dec 2000 00:34:41 GMT Received: by mail-control.mail.uu.net id QQjsas25188 for mpls-outgoing; Mon, 4 Dec 2000 00:34:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsas25183 for ; Mon, 4 Dec 2000 00:34:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsas20082 for ; Mon, 4 Dec 2000 00:33:19 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjsas10048 for ; Mon, 4 Dec 2000 00:33:13 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id TAA25538 for mpls@uu.net; Sun, 3 Dec 2000 19:33:13 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsas25159 for ; Mon, 4 Dec 2000 00:32:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsas14871 for ; Mon, 4 Dec 2000 00:31:37 GMT Received: from nero.doit.wisc.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQjsas04457 for ; Mon, 4 Dec 2000 00:31:36 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id SAA26708; Sun, 3 Dec 2000 18:31:10 -0600 Date: Sun, 3 Dec 2000 18:31:10 -0600 From: "James R. Leu" To: Francis Arts Cc: Satoru Matsushima , mpls@UU.NET, mpls-wg@janog.gr.jp Subject: Re: Processing the MPLS TTL Message-ID: <20001203183110.B26628@doit.wisc.edu> Reply-To: jleu@mindspring.com References: <00cb01c05b77$c2c99300$315412ac@pc3k6002> <3A28CE8B.754AA1A3@alcatel.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A28CE8B.754AA1A3@alcatel.be>; from francis.arts@alcatel.be on Sat, Dec 02, 2000 at 11:27:23AM +0100 Organization: none Sender: owner-mpls@UU.NET Precedence: bulk Section 2.4.3. "IP-dependent rules" of draft-ietf-mpls-label-encaps-08.txt contradicts what you're saying. Did you get your info from a different draft? Jim On Sat, Dec 02, 2000 at 11:27:23AM +0100, Francis Arts wrote: > > Hi Satoru, > > Please find included some information on the question you raised: > > > Could somebody tell me the behavior of "ingress|egress LSR/LER" on > > this situations? > > > > ** Ingress LSR: > In this case the ingress LSR has to use for the MPLS header a TTL that is > large enough to reach the egress LSR (that is, the TTL should not expire in > the middle of the LSP). > > ** Egress LSR: > At the egress LSR the TTL in the MPLS header is not copied into the IP header > of the packet. Instead the TTL as is in the IP header is used. > > This 'TTL behavior' is -for the TTL aspect- similar to the 'TTL behavior' for > IP over IP tunnels as defined in section 3.1 of RFC 2003 ('IP within IP'). > > Kind regards, > > Francis. > > -------------- > > ******************** > *Extract from RFC 2003* > ******************** > > 3.1. IP Header Fields and Handling > > The fields in the outer IP header are set by the encapsulator as > follows: > > .... > > Time to Live > > The Time To Live (TTL) field in the outer IP header is set to a > value appropriate for delivery of the encapsulated datagram to > the tunnel exit point. > > ... > > When encapsulating a datagram, the TTL in the inner IP header is > decremented by one if the tunneling is being done as part of > forwarding the datagram; otherwise, the inner header TTL is not > changed during encapsulation. If the resulting TTL in the inner IP > header is 0, the datagram is discarded and an ICMP Time Exceeded > message SHOULD be returned to the sender. An encapsulator MUST NOT > encapsulate a datagram with TTL = 0. > > The TTL in the inner IP header is not changed when decapsulating. > If, after decapsulation, the inner datagram has TTL = 0, the > decapsulator MUST discard the datagram. If, after decapsulation, the > decapsulator forwards the datagram to one of its network interfaces, > it will decrement the TTL as a result of doing normal IP forwarding. > See also Section 4.4. > > ... > > -------------- > > Satoru Matsushima schreef: > > > Hi all, > > > > According to draft-ietf-mpls-label-encaps-08.txt, > > > > > 2.4.3. IP-dependent rules > > > > > We define the "IP TTL" field to be the value of the IPv4 TTL field, > > > or the value of the IPv6 Hop Limit field, whichever is applicable. > > > > > > When an IP packet is first labeled, the TTL field of the label stack > > > entry MUST BE set to the value of the IP TTL field. (If the IP TTL > > > field needs to be decremented, as part of the IP processing, it is > > > assumed that this has already been done.) > > > > > > When a label is popped, and the resulting label stack is empty, then > > > the value of the IP TTL field SHOULD BE replaced with the outgoing > > > TTL value, as defined above. In IPv4 this also requires modification > > > of the IP header checksum. > > > > but this section had continue following. > > > > > It is recognized that there may be situations where a network > > > administration prefers to decrement the IPv4 TTL by one as it > > > traverses an MPLS domain, instead of decrementing the IPv4 TTL by the > > > number of LSP hops within the domain. > > > > I think that is very useful for VPNs, but this section had not consider > > this situations. > > > > Could somebody tell me the behavior of "ingress|egress LSR/LER" on > > this situations? > > > > Thanks in advance. > > > > -- > > Satoru Matsushima -- James R. Leu From owner-mpls@UU.NET Sun Dec 3 20:16:27 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19120 for ; Sun, 3 Dec 2000 20:16:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsav29356; Mon, 4 Dec 2000 01:15:12 GMT Received: by mail-control.mail.uu.net id QQjsau09183 for mpls-outgoing; Mon, 4 Dec 2000 01:14:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsau09178 for ; Mon, 4 Dec 2000 01:14:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsau27985 for ; Mon, 4 Dec 2000 01:13:54 GMT Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQjsau27637 for ; Mon, 4 Dec 2000 01:13:54 GMT Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Sun, 3 Dec 2000 20:13:37 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YFYQKJK6; Sun, 3 Dec 2000 20:13:39 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YFZDNY8D; Sun, 3 Dec 2000 20:13:38 -0500 Message-ID: <3A2AEFC0.83AB40CF@americasm01.nt.com> Date: Sun, 03 Dec 2000 20:13:36 -0500 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: New MPLS Charter? References: <200012032247.OAA21378@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yakov Rekhter wrote: > > Eric, > > > The problem with including "implicit" labels in > > the MPLS working group charter is that doing so > > may defeat the intent of getting the charter down to > > a manageable size. GMPLS may be generic in its > > intent, but I think we all know that the focus remains > > on MPL(ambda)S. I do not believe the focus is on Lambda switching. Most devices today are doing either spacial switching with mirrors or bubbles or some other physical device, or TDM switching with SONET. The Lambda stuff is done with a DWDM infront of a space switch, at least to the best of my knowledge. As a result there is a great deal of interest in TDM and Spacial switching right now. > > If the idea is to break up the > > charter into manageable chunks, MPL(ambda)S > > might be better off in the IPO working group. This > > is especially true, if MPL(ambda)S includes TDM > > time-slot assignment "label", optical waveband and > > optical fiber switching: if these are included, the delta > > between MPL(ambda)S and GMPLS is very small. If we need more time to discuss the various things going on in MPLS then let's have another WG meeting. Its kind of frustrating doing almost the same thing several times in different groups. I recall the traffic engineering stuff being duplicated and would hate to see us do the same things with GMPLS. > > As far as GMPLS is concerned, IMHO, we > > need to make a philosophical distinction as to > > whether GMPLS is intended to be a generalized > > use of MPLS signaling or an attempt generalize > > MPLS signaling. The distinction is a subtle one, > > but I think it's at the root of whether or not we > > (as individuals) feel GMPLS belongs in the MPLS > > working group. If it is intended to be a generalized > > use of MPLS signaling, then it should probably > > find a home elsewhere. If it is intended that MPLS > > signaling itself should be generalized, then it should > > be done in the MPLS working group. Call me naive, but I have always felt that a path, no matter what the characteristics of the switches that create that path, is controllable by a single signaling and routing protocol and that only minor differences are required to deal with the differences in switching technology. As such I see GMPLS as an attempt to generalize MPLS signaling, not something that you piggy back on existing MPLS signaling. Anyway, my simplistic view of things looks like this: - a place to discuss signaling for all layer 1&2 switches. (G)MPLS-WG - a place to discuss routing OSPF & ISIS-WG - a place to discuss traffic engineering TE-WG - a place to discuss applications of (G)MPLS - a place to discuss peculiarities of different layer 1&2 technologies, IPO+other standards bodies Cheers, Peter From owner-mpls@UU.NET Sun Dec 3 23:48:33 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01204 for ; Sun, 3 Dec 2000 23:48:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsbj26528; Mon, 4 Dec 2000 04:47:10 GMT Received: by mail-control.mail.uu.net id QQjsbj22495 for mpls-outgoing; Mon, 4 Dec 2000 04:46:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsbj22489 for ; Mon, 4 Dec 2000 04:46:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsbj28173 for ; Mon, 4 Dec 2000 04:46:19 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjsbj25359 for ; Mon, 4 Dec 2000 04:46:17 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 04 Dec 2000 10:19:51 +0530 Received: from prabakarts (prabakarts.future.futsoft.com [10.0.6.29]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id eB4AHd232683; Mon, 4 Dec 2000 15:47:39 +0530 Received: by localhost with Microsoft MAPI; Mon, 4 Dec 2000 10:07:07 +0530 Message-Id: <01C05DD9.F5C52BC0.prabakarts@future.futsoft.com> From: Prabakar T S Reply-To: "prabakarts@future.futsoft.com" To: "'Gaitonde Anandprasanna'" , "mpls@uu.net" Cc: "'prabakarts@future.futsoft.com'" Subject: RE: Question about L3PID in Label Request Date: Mon, 4 Dec 2000 10:07:06 +0530 Organization: FSPL X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pras, Refer RFC-1700 (ASSIGNED NUMBERS) - Pg: 168: (eg: for Internet IP - Ipv4, L3Pid value is 0x0800). ----------------------------------------------------------- Prabakaran TS. Senior Software Engineer, Future Software Ltd, 480-481 Mount Road, Nandanam, Chennai - 600 035. Ph : 433 05 50 - Extn : 363. ----------------------------------------------------------- -----Original Message----- From: Gaitonde Anandprasanna [SMTP:prasanna@csa.iisc.ernet.in] Sent: Sunday, December 03, 2000 5:49 PM To: mpls@uu.net Subject: Question about L3PID in Label Request I want to know where i can get the standard ethertype values for specifying the L3PID in the Label Request Object ?? Please direct me to the appropriate document which specifies the values. Thanx in advance Pras From owner-mpls@UU.NET Mon Dec 4 00:05:19 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04147 for ; Mon, 4 Dec 2000 00:05:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsbk22950; Mon, 4 Dec 2000 05:04:06 GMT Received: by mail-control.mail.uu.net id QQjsbk04004 for mpls-outgoing; Mon, 4 Dec 2000 05:03:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsbk03981 for ; Mon, 4 Dec 2000 05:03:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsbk14688 for ; Mon, 4 Dec 2000 05:03:01 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjsbk17760 for ; Mon, 4 Dec 2000 05:02:59 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 04 Dec 2000 10:36:42 +0530 Received: from prabakarts (prabakarts.future.futsoft.com [10.0.6.29]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id eB4AYV202154; Mon, 4 Dec 2000 16:04:31 +0530 Received: by localhost with Microsoft MAPI; Mon, 4 Dec 2000 10:23:59 +0530 Message-Id: <01C05DDC.50F07CA0.prabakarts@future.futsoft.com> From: Prabakar T S Reply-To: "prabakarts@future.futsoft.com" To: "'Gaitonde Anandprasanna'" , "mpls@uu.net" Cc: "'prabakarts@future.futsoft.com'" Subject: RE: Query regarding Path Err for RRO being too large for MTU. Date: Mon, 4 Dec 2000 10:23:59 +0530 Organization: FSPL 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 Pl, find the inlined comment. ----------------------------------------------------------- Prabakaran TS. Senior Software Engineer, Future Software Ltd, 480-481 Mount Road, Nandanam, Chennai - 600 035. Ph : 433 05 50 - Extn : 363. ----------------------------------------------------------- -----Original Message----- From: Gaitonde Anandprasanna [SMTP:prasanna@csa.iisc.ernet.in] Sent: Sunday, December 03, 2000 10:00 PM To: mpls@uu.net Subject: Query regarding Path Err for RRO being too large for MTU. I am unable to understand the use of the follwowing . Can somebody explain me this?? If the newly added subobject causes the RRO to be too big to fit in a Path (or Resv) message, the RRO object SHALL be dropped from the message and message processing continues as normal. A PathErr (or ResvErr) message SHOULD be sent back to the sender (or receiver). An error code of "Notify" and an error value of "RRO too large for MTU" is used. If the receiver receives such a ResvErr, it SHOULD send a PathErr message with error code of "Notify" and an error value of "RRO notification". A sender receiving either of these error values SHOULD remove the RRO from the Path message. ------------ Uptill this it is fine. But what about the following?? Nodes SHOULD resend the above PathErr or ResvErr message each n seconds where n is the greater of 15 and the refresh interval for the associated Path or RESV message. The node MAY apply limits and/or back-off timers to limit the number of messages sent. Why is this refreshing of PathErr required? and if its required then to what point of time we should stop sending these messages. ????? [Prabakaran TS] >>The limits and/or back-off timer is used to ensure that the Sender responds to the >>PathErr Message Sent, within certain time. >>If no response from Sender, then PathErr is again transmitted. This message >>Re-Transmission happens till, either when Sender responds with PathMsg with out RRO >>or When back-off time and/or limits crosses threshold value. Please let me know.. thanx in advance Pras From owner-mpls@UU.NET Mon Dec 4 00:33:44 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08337 for ; Mon, 4 Dec 2000 00:33:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsbm23103; Mon, 4 Dec 2000 05:31:46 GMT Received: by mail-control.mail.uu.net id QQjsbm05791 for mpls-outgoing; Mon, 4 Dec 2000 05:31:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsbm05786 for ; Mon, 4 Dec 2000 05:31:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsbm10313 for ; Mon, 4 Dec 2000 05:30:49 GMT Received: from satoru.prism by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [143.90.128.193]) id QQjsbm04710 for ; Mon, 4 Dec 2000 05:30:48 GMT Received: from localhost (localhost [127.0.0.1]) by satoru.prism (8.11.1/8.11.1) with ESMTP id eB45Sn000489; Mon, 4 Dec 2000 14:29:05 +0900 (JST) (envelope-from satoru@japan-telecom.co.jp) To: francis.arts@alcatel.be Cc: satoru@japan-telecom.co.jp, mpls@UU.NET, mpls-wg@janog.gr.jp Subject: Re: Processing the MPLS TTL In-Reply-To: <3A28CE8B.754AA1A3@alcatel.be> References: <00cb01c05b77$c2c99300$315412ac@pc3k6002> <3A28CE8B.754AA1A3@alcatel.be> X-Mailer: Mew version 1.94.1 on XEmacs 21.1 (Capitol Reef) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20001204142848P.satoru@japan-telecom.co.jp> Date: Mon, 04 Dec 2000 14:28:48 +0900 From: "S.Matsushima" X-Dispatcher: imput version 20000228(IM140) Lines: 123 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Francis, Thanks for your reply. > Please find included some information on the question you raised: > > > Could somebody tell me the behavior of "ingress|egress LSR/LER" on > > this situations? > > > > ** Ingress LSR: > In this case the ingress LSR has to use for the MPLS header a TTL that is > large enough to reach the egress LSR (that is, the TTL should not expire in > the middle of the LSP). > > ** Egress LSR: > At the egress LSR the TTL in the MPLS header is not copied into the IP header > of the packet. Instead the TTL as is in the IP header is used. > > This 'TTL behavior' is -for the TTL aspect- similar to the 'TTL behavior' for > IP over IP tunnels as defined in section 3.1 of RFC 2003 ('IP within IP'). In this case, it is right if it works as network devices. But MPLS-LSP does not work as well as network devices. Thus basically, MPLS TTL was set to the value of th IP TTL at the ingress LER, and IP TTL was set to the value of MPLS TTL at the egress LSR/LER. This is basically situations. But Section 2.4.3. "IP-dependent rules" was recognized that there are situations where a network administration prefers to decrement the IPv4 TTL by one as it traverses an MPLS domain. As a result, the MPLS domain has two situations. If the MPLS domain really has two situations and be mixed, how can the egress LSR/LER distinguish these two situations? I think it is desirable that these situations should be more described by "draft-ietf-mpls-label-encaps-08.txt" regards. -- Satoru Matsushima > > ******************** > *Extract from RFC 2003* > ******************** > > 3.1. IP Header Fields and Handling > > The fields in the outer IP header are set by the encapsulator as > follows: > > .... > > Time to Live > > The Time To Live (TTL) field in the outer IP header is set to a > value appropriate for delivery of the encapsulated datagram to > the tunnel exit point. > > ... > > When encapsulating a datagram, the TTL in the inner IP header is > decremented by one if the tunneling is being done as part of > forwarding the datagram; otherwise, the inner header TTL is not > changed during encapsulation. If the resulting TTL in the inner IP > header is 0, the datagram is discarded and an ICMP Time Exceeded > message SHOULD be returned to the sender. An encapsulator MUST NOT > encapsulate a datagram with TTL = 0. > > The TTL in the inner IP header is not changed when decapsulating. > If, after decapsulation, the inner datagram has TTL = 0, the > decapsulator MUST discard the datagram. If, after decapsulation, the > decapsulator forwards the datagram to one of its network interfaces, > it will decrement the TTL as a result of doing normal IP forwarding. > See also Section 4.4. > > ... > > -------------- > > Satoru Matsushima schreef: > > > Hi all, > > > > According to draft-ietf-mpls-label-encaps-08.txt, > > > > > 2.4.3. IP-dependent rules > > > > > We define the "IP TTL" field to be the value of the IPv4 TTL field, > > > or the value of the IPv6 Hop Limit field, whichever is applicable. > > > > > > When an IP packet is first labeled, the TTL field of the label stack > > > entry MUST BE set to the value of the IP TTL field. (If the IP TTL > > > field needs to be decremented, as part of the IP processing, it is > > > assumed that this has already been done.) > > > > > > When a label is popped, and the resulting label stack is empty, then > > > the value of the IP TTL field SHOULD BE replaced with the outgoing > > > TTL value, as defined above. In IPv4 this also requires modification > > > of the IP header checksum. > > > > but this section had continue following. > > > > > It is recognized that there may be situations where a network > > > administration prefers to decrement the IPv4 TTL by one as it > > > traverses an MPLS domain, instead of decrementing the IPv4 TTL by the > > > number of LSP hops within the domain. > > > > I think that is very useful for VPNs, but this section had not consider > > this situations. > > > > Could somebody tell me the behavior of "ingress|egress LSR/LER" on > > this situations? > > > > Thanks in advance. > > > > -- > > Satoru Matsushima From owner-mpls@UU.NET Mon Dec 4 01:11:32 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17349 for ; Mon, 4 Dec 2000 01:11:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsbo08010; Mon, 4 Dec 2000 06:09:54 GMT Received: by mail-control.mail.uu.net id QQjsbo18590 for mpls-outgoing; Mon, 4 Dec 2000 06:09:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsbo18585 for ; Mon, 4 Dec 2000 06:09:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsbo04102 for ; Mon, 4 Dec 2000 06:07:31 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjsbo03678 for ; Mon, 4 Dec 2000 06:07:30 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id BAA10063 for mpls@uu.net; Mon, 4 Dec 2000 01:07:30 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsbo18415 for ; Mon, 4 Dec 2000 06:07:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsbo02479 for ; Mon, 4 Dec 2000 06:07:00 GMT Received: from relay2.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQjsbo09940 for ; Mon, 4 Dec 2000 06:07:00 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.10.1) with SMTP id eB463vR06816; Mon, 4 Dec 2000 07:03:58 +0100 (MET) Received: from sh.bel.alcatel.be ([138.203.195.108]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569AB.00218E12; Mon, 4 Dec 2000 07:06:30 +0100 Message-ID: <3A2B3469.7C5BB731@sh.bel.alcatel.be> Date: Mon, 04 Dec 2000 07:06:33 +0100 From: francis arts vh624 8492 Organization: Alcatel Telecom X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jleu@mindspring.com CC: Francis Arts , Satoru Matsushima , mpls@UU.NET, mpls-wg@janog.gr.jp Subject: Re: Processing the MPLS TTL References: <00cb01c05b77$c2c99300$315412ac@pc3k6002> <3A28CE8B.754AA1A3@alcatel.be> <20001203183110.B26628@doit.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jim, I agree that section 2.4.3 indeed indicates that "when a label is popped, and the resulting label stack is empty, then the value of the IP TTL field SHOULD BE replaced with the outgoing TTL value". However, the last paragraph of section 2.4.3 also states that 'it is recognized that there may be situations where a network administration prefers to decrement the IPv4 TTL by one as it traverses an MPLS domain, instead of decrementing the IPv4 TTL by the number of LSP hops within the domain." So if one would use the latter approach, the TTL is not meant to be copied from the MPLS header into the IP header in the LSP egress node. Kind regards, Francis. ------------- "James R. Leu" wrote: > Section 2.4.3. "IP-dependent rules" of draft-ietf-mpls-label-encaps-08.txt > contradicts what you're saying. Did you get your info from a different draft? > > Jim > > On Sat, Dec 02, 2000 at 11:27:23AM +0100, Francis Arts wrote: > > > > Hi Satoru, > > > > Please find included some information on the question you raised: > > > > > Could somebody tell me the behavior of "ingress|egress LSR/LER" on > > > this situations? > > > > > > > ** Ingress LSR: > > In this case the ingress LSR has to use for the MPLS header a TTL that is > > large enough to reach the egress LSR (that is, the TTL should not expire in > > the middle of the LSP). > > > > ** Egress LSR: > > At the egress LSR the TTL in the MPLS header is not copied into the IP header > > of the packet. Instead the TTL as is in the IP header is used. > > > > This 'TTL behavior' is -for the TTL aspect- similar to the 'TTL behavior' for > > IP over IP tunnels as defined in section 3.1 of RFC 2003 ('IP within IP'). > > > > Kind regards, > > > > Francis. > > > > -------------- > > > > ******************** > > *Extract from RFC 2003* > > ******************** > > > > 3.1. IP Header Fields and Handling > > > > The fields in the outer IP header are set by the encapsulator as > > follows: > > > > .... > > > > Time to Live > > > > The Time To Live (TTL) field in the outer IP header is set to a > > value appropriate for delivery of the encapsulated datagram to > > the tunnel exit point. > > > > ... > > > > When encapsulating a datagram, the TTL in the inner IP header is > > decremented by one if the tunneling is being done as part of > > forwarding the datagram; otherwise, the inner header TTL is not > > changed during encapsulation. If the resulting TTL in the inner IP > > header is 0, the datagram is discarded and an ICMP Time Exceeded > > message SHOULD be returned to the sender. An encapsulator MUST NOT > > encapsulate a datagram with TTL = 0. > > > > The TTL in the inner IP header is not changed when decapsulating. > > If, after decapsulation, the inner datagram has TTL = 0, the > > decapsulator MUST discard the datagram. If, after decapsulation, the > > decapsulator forwards the datagram to one of its network interfaces, > > it will decrement the TTL as a result of doing normal IP forwarding. > > See also Section 4.4. > > > > ... > > > > -------------- > > > > Satoru Matsushima schreef: > > > > > Hi all, > > > > > > According to draft-ietf-mpls-label-encaps-08.txt, > > > > > > > 2.4.3. IP-dependent rules > > > > > > > We define the "IP TTL" field to be the value of the IPv4 TTL field, > > > > or the value of the IPv6 Hop Limit field, whichever is applicable. > > > > > > > > When an IP packet is first labeled, the TTL field of the label stack > > > > entry MUST BE set to the value of the IP TTL field. (If the IP TTL > > > > field needs to be decremented, as part of the IP processing, it is > > > > assumed that this has already been done.) > > > > > > > > When a label is popped, and the resulting label stack is empty, then > > > > the value of the IP TTL field SHOULD BE replaced with the outgoing > > > > TTL value, as defined above. In IPv4 this also requires modification > > > > of the IP header checksum. > > > > > > but this section had continue following. > > > > > > > It is recognized that there may be situations where a network > > > > administration prefers to decrement the IPv4 TTL by one as it > > > > traverses an MPLS domain, instead of decrementing the IPv4 TTL by the > > > > number of LSP hops within the domain. > > > > > > I think that is very useful for VPNs, but this section had not consider > > > this situations. > > > > > > Could somebody tell me the behavior of "ingress|egress LSR/LER" on > > > this situations? > > > > > > Thanks in advance. > > > > > > -- > > > Satoru Matsushima > > -- > James R. Leu From owner-mpls@UU.NET Mon Dec 4 02:59:21 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02506 for ; Mon, 4 Dec 2000 02:59:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsbv04161; Mon, 4 Dec 2000 07:56:58 GMT Received: by mail-control.mail.uu.net id QQjsbv04140 for mpls-outgoing; Mon, 4 Dec 2000 07:56:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsbv04133 for ; Mon, 4 Dec 2000 07:56:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsbv10192 for ; Mon, 4 Dec 2000 07:56:13 GMT Received: from chonnam.chonnam.ac.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: chonnam.chonnam.ac.kr [168.131.33.5]) id QQjsbv04231 for ; Mon, 4 Dec 2000 07:56:11 GMT Received: from yojiny (pc85079.chonnam.ac.kr [168.131.85.79] (may be forged)) by chonnam.chonnam.ac.kr (8.10.0/8.10.0) with SMTP id eB47cmc23014 for ; Mon, 4 Dec 2000 16:38:49 +0900 Message-ID: <001a01c05dc7$f0b458c0$4f5583a8@chonnam.ac.kr> Reply-To: "yojiny" From: "yojiny" To: Subject: in topology-driven how is ospf work? Date: Mon, 4 Dec 2000 16:58:07 +0900 Organization: Univ. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C05E13.5FFBC920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C05E13.5FFBC920 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSBoYXZlIGEgcXVlc3Rpb24uDQpJIHduYXQgdG8ga25vdyBkaWZmZXJlbmNlIGZvIGZ1bnRjdGlv biBmbyBvc3BmIGluIHRvcG9sb2d5LWRyaXZlbiBhbmQgdHJhZmZpYy1kcml2ZW4/DQphbmQgd2hh dCBpbmZvcm1hdG9uIGlzIGNhcnJlZCBieSByb3V0aW5nIHByb3RvY29sIGluIHR3byBkaWZmZXJl bnQgbWV0aG9kPw0KDQp0aGFua3MgaW4gYWR2YW5jZS4NCg0KeWFuZyB5b2ppbi4NCkkNCg== ------=_NextPart_000_0017_01C05E13.5FFBC920 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgaGF2ZSBh IHF1ZXN0aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgd25hdCB0byBrbm93 IGRpZmZlcmVuY2UgZm8gZnVudGN0aW9uIGZvIG9zcGYgaW4gDQp0b3BvbG9neS1kcml2ZW4gYW5k IHRyYWZmaWMtZHJpdmVuPzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmFuZCB3aGF0 IGluZm9ybWF0b24gaXMgY2FycmVkIGJ5IHJvdXRpbmcgcHJvdG9jb2wgaW4gdHdvIA0KZGlmZmVy ZW50IG1ldGhvZD88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj50aGFua3MgaW4gYWR2YW5jZS48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj55YW5nIHlvamluLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkk8L0ZPTlQ+PC9E SVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0017_01C05E13.5FFBC920-- From owner-mpls@UU.NET Mon Dec 4 04:05:09 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23872 for ; Mon, 4 Dec 2000 04:05:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsca02683; Mon, 4 Dec 2000 09:02:46 GMT Received: by mail-control.mail.uu.net id QQjsca24522 for mpls-outgoing; Mon, 4 Dec 2000 09:02:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsca24515 for ; Mon, 4 Dec 2000 09:02:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsca03690 for ; Mon, 4 Dec 2000 09:01:19 GMT Received: from albatross-ext.wise.edt.ericsson.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [194.237.142.116]) id QQjsca00658 for ; Mon, 4 Dec 2000 09:01:18 GMT Received: from esealnt462.al.sw.ericsson.se (esealnt462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id eB491H424674 for ; Mon, 4 Dec 2000 10:01:18 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Dec 04 10:01:17 2000 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Mon, 4 Dec 2000 09:58:58 +0100 Message-ID: From: "Gabor Korossy (ETH)" To: "'yojiny'" Cc: "'mpls@UU.NET'" Subject: RE: in topology-driven how is ospf work? Date: Mon, 4 Dec 2000 10:00:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ks_c_5601-1987" Sender: owner-mpls@UU.NET Precedence: bulk Yojiny, if you want other people to consider your question worth answering, please, respect the readers by browsing your letter once more before sending it, so that we don't have to guess what do you "wnat to know". /Gabor -----Original Message----- From: owner-mpls@UU.NET [mailto:owner- mpls@UU.NET]On Behalf Of yojiny Sent: Monday, December 04, 2000 8:58 AM To: mpls@UU.NET Subject: in topology-driven how is ospf work? I have a question. I wnat to know difference fo funtction fo ospf in topology-driven and traffic-driven? and what informaton is carred by routing protocol in two different method? thanks in advance. yang yojin. I From owner-mpls@UU.NET Mon Dec 4 06:14:07 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06363 for ; Mon, 4 Dec 2000 06:14:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsci26552; Mon, 4 Dec 2000 11:12:33 GMT Received: by mail-control.mail.uu.net id QQjsci27888 for mpls-outgoing; Mon, 4 Dec 2000 11:12:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsci27883 for ; Mon, 4 Dec 2000 11:12:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsci15064 for ; Mon, 4 Dec 2000 11:11:24 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjsci28430 for ; Mon, 4 Dec 2000 11:11:21 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 04 Dec 2000 16:44:14 +0530 Received: from mohanvak (mohanvak.future.futsoft.com [10.0.6.52]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id eB4Gg0211755 for ; Mon, 4 Dec 2000 22:12:02 +0530 Received: by localhost with Microsoft MAPI; Mon, 4 Dec 2000 16:31:27 +1100 Message-Id: <01C05E0F.A6523660.mohanvak@future.futsoft.com> From: Mohan Varma K Reply-To: "mohanvak@future.futsoft.com" To: "'mpls@uu.net'" Subject: Any dependency Ip over Optical model in MPLS Date: Mon, 4 Dec 2000 16:31:26 +1100 Organization: FSPL X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-mpls@UU.NET Precedence: bulk Hi , In the Ip-optical framework it's been said that the peer model ie the optical switch(Router) will be using the same routing algorithms as the IP routers which looks like very benificial with the enhancements in OSPF/IS-IS. At the very same time with the enhancements in BGP the interworking between IP and optical will be easier. Does the MPLS signalling enhanced drafts for optical (RSVP or CRLDP) assume any of these models or they are completly independent of the above framework. Any clarification will be appreciated. With Regards Mohan Varma. From owner-mpls@UU.NET Mon Dec 4 08:02:58 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09478 for ; Mon, 4 Dec 2000 08:02:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjscq28222; Mon, 4 Dec 2000 13:01:43 GMT Received: by mail-control.mail.uu.net id QQjscq17911 for mpls-outgoing; Mon, 4 Dec 2000 13:01:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjscq17791 for ; Mon, 4 Dec 2000 13:01:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjscq21923 for ; Mon, 4 Dec 2000 13:00:53 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjscq15606 for ; Mon, 4 Dec 2000 13:00:52 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA25131 for mpls@uu.net; Mon, 4 Dec 2000 08:00:51 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjscq16275 for ; Mon, 4 Dec 2000 13:00:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjscp18219 for ; Mon, 4 Dec 2000 12:59:40 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjscp26532 for ; Mon, 4 Dec 2000 12:59:39 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id EAA01797; Mon, 4 Dec 2000 04:59:25 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 04:59:44 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AB7@BBY1EXM01> From: Shahram Davari To: "'francis arts vh624 8492'" , jleu@mindspring.com Cc: Francis Arts , Satoru Matsushima , mpls@UU.NET, mpls-wg@janog.gr.jp Subject: RE: Processing the MPLS TTL Date: Mon, 4 Dec 2000 04:59:35 -0800 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 think both methods are allowed. The two scenarios that they might be used are in Uniform and Tunnel model. In the Uniform model we probably like to copy the MPLS TTL to the IP TTL, and in Tunnel mode we probably like to just decrement the IP TTL by one. Yours, -Shahram > -----Original Message----- > From: francis arts vh624 8492 [mailto:fart@sh.bel.alcatel.be] > Sent: Monday, December 04, 2000 1:07 AM > To: jleu@mindspring.com > Cc: Francis Arts; Satoru Matsushima; mpls@UU.NET; mpls-wg@janog.gr.jp > Subject: Re: Processing the MPLS TTL > > > > Jim, > > I agree that section 2.4.3 indeed indicates that "when a > label is popped, and the > resulting label stack is empty, then the value of the IP TTL > field SHOULD BE > replaced with the outgoing TTL value". > > However, the last paragraph of section 2.4.3 also states that > 'it is recognized > that there may be situations where a network administration > prefers to decrement > the IPv4 TTL by one as it traverses an MPLS domain, instead > of decrementing the > IPv4 TTL by the number of LSP hops within the domain." > > So if one would use the latter approach, the TTL is not meant > to be copied from > the MPLS header into the IP header in the LSP egress node. > > Kind regards, > > Francis. > > ------------- > > "James R. Leu" wrote: > > > Section 2.4.3. "IP-dependent rules" of > draft-ietf-mpls-label-encaps-08.txt > > contradicts what you're saying. Did you get your info from > a different draft? > > > > Jim > > > > On Sat, Dec 02, 2000 at 11:27:23AM +0100, Francis Arts wrote: > > > > > > Hi Satoru, > > > > > > Please find included some information on the question you raised: > > > > > > > Could somebody tell me the behavior of "ingress|egress > LSR/LER" on > > > > this situations? > > > > > > > > > > ** Ingress LSR: > > > In this case the ingress LSR has to use for the MPLS > header a TTL that is > > > large enough to reach the egress LSR (that is, the TTL > should not expire in > > > the middle of the LSP). > > > > > > ** Egress LSR: > > > At the egress LSR the TTL in the MPLS header is not > copied into the IP header > > > of the packet. Instead the TTL as is in the IP header is used. > > > > > > This 'TTL behavior' is -for the TTL aspect- similar to > the 'TTL behavior' for > > > IP over IP tunnels as defined in section 3.1 of RFC 2003 > ('IP within IP'). > > > > > > Kind regards, > > > > > > Francis. > > > > > > -------------- > > > > > > ******************** > > > *Extract from RFC 2003* > > > ******************** > > > > > > 3.1. IP Header Fields and Handling > > > > > > The fields in the outer IP header are set by the > encapsulator as > > > follows: > > > > > > .... > > > > > > Time to Live > > > > > > The Time To Live (TTL) field in the outer IP > header is set to a > > > value appropriate for delivery of the > encapsulated datagram to > > > the tunnel exit point. > > > > > > ... > > > > > > When encapsulating a datagram, the TTL in the inner IP > header is > > > decremented by one if the tunneling is being done as part of > > > forwarding the datagram; otherwise, the inner header TTL is not > > > changed during encapsulation. If the resulting TTL in > the inner IP > > > header is 0, the datagram is discarded and an ICMP > Time Exceeded > > > message SHOULD be returned to the sender. An > encapsulator MUST NOT > > > encapsulate a datagram with TTL = 0. > > > > > > The TTL in the inner IP header is not changed when > decapsulating. > > > If, after decapsulation, the inner datagram has TTL = 0, the > > > decapsulator MUST discard the datagram. If, after > decapsulation, the > > > decapsulator forwards the datagram to one of its > network interfaces, > > > it will decrement the TTL as a result of doing normal > IP forwarding. > > > See also Section 4.4. > > > > > > ... > > > > > > -------------- > > > > > > Satoru Matsushima schreef: > > > > > > > Hi all, > > > > > > > > According to draft-ietf-mpls-label-encaps-08.txt, > > > > > > > > > 2.4.3. IP-dependent rules > > > > > > > > > We define the "IP TTL" field to be the value of the > IPv4 TTL field, > > > > > or the value of the IPv6 Hop Limit field, whichever > is applicable. > > > > > > > > > > When an IP packet is first labeled, the TTL field > of the label stack > > > > > entry MUST BE set to the value of the IP TTL field. > (If the IP TTL > > > > > field needs to be decremented, as part of the IP > processing, it is > > > > > assumed that this has already been done.) > > > > > > > > > > When a label is popped, and the resulting label > stack is empty, then > > > > > the value of the IP TTL field SHOULD BE replaced > with the outgoing > > > > > TTL value, as defined above. In IPv4 this also > requires modification > > > > > of the IP header checksum. > > > > > > > > but this section had continue following. > > > > > > > > > It is recognized that there may be situations where > a network > > > > > administration prefers to decrement the IPv4 TTL by > one as it > > > > > traverses an MPLS domain, instead of decrementing > the IPv4 TTL by the > > > > > number of LSP hops within the domain. > > > > > > > > I think that is very useful for VPNs, but this section > had not consider > > > > this situations. > > > > > > > > Could somebody tell me the behavior of "ingress|egress > LSR/LER" on > > > > this situations? > > > > > > > > Thanks in advance. > > > > > > > > -- > > > > Satoru Matsushima > > > > -- > > James R. Leu > From owner-mpls@UU.NET Mon Dec 4 08:22:27 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14884 for ; Mon, 4 Dec 2000 08:22:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjscr22993; Mon, 4 Dec 2000 13:20:11 GMT Received: by mail-control.mail.uu.net id QQjscr26111 for mpls-outgoing; Mon, 4 Dec 2000 13:19:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjscr26105 for ; Mon, 4 Dec 2000 13:19:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjscr28878 for ; Mon, 4 Dec 2000 13:18:21 GMT Received: from smtp6.mindspring.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQjscr20444 for ; Mon, 4 Dec 2000 13:18:21 GMT Received: from mindspring.com (user-2ive39i.dialup.mindspring.com [165.247.13.50]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id IAA26347; Mon, 4 Dec 2000 08:18:13 -0500 (EST) Message-ID: <3A2B99F5.9CA74B7A@mindspring.com> Date: Mon, 04 Dec 2000 08:19:49 -0500 From: Eric Gray Reply-To: ewgray@mindspring.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: Peter Ashwood-Smith , mpls@UU.NET Subject: Re: New MPLS Charter? References: <200012032247.OAA21378@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, Hi. I invite your attention to the abstract of the draft to which you refer, in which a cast of thousands say: "This document describes extensions to MPLS signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). ..." This sounds to me like it's attempting to describe how MPLS signaling might be extended to support a more general usage. As a result, the intentions of the authors are ambiguous and unclear. I cannot tell whether it is the intention of the authors that these extensions are to become part of MPLS (generalizing MPLS) or to be used as a super-set of MPLS signaling that would be applicable only to signaling applications not already described in current MPLS signaling. It is my hope that it is this latter case as otherwise, we are still in the pre-standard mode where vendors implement MPLS at their own risk I'd really like to see closure on what we have already accomplished. -- Eric Gray Yakov Rekhter wrote (in part): > Eric, > > > The problem with including "implicit" labels in > > ... > > > > As far as GMPLS is concerned, IMHO, we > > need to make a philosophical distinction as to > > whether GMPLS is intended to be a generalized > > use of MPLS signaling or an attempt generalize > > MPLS signaling. The distinction is a subtle one, > > but I think it's at the root of whether or not we > > (as individuals) feel GMPLS belongs in the MPLS > > working group. If it is intended to be a generalized > > use of MPLS signaling, then it should probably > > find a home elsewhere. If it is intended that MPLS > > signaling itself should be generalized, then it should > > be done in the MPLS working group. > > Would you consider draft-ashwood-generalized-mpls-signaling-01.txt > as a generalized use of MPLS signalling, or as an attempt to > generalize MPLS signalling ? > > Yakov. From owner-mpls@UU.NET Mon Dec 4 08:29:08 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17012 for ; Mon, 4 Dec 2000 08:29:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjscr10106; Mon, 4 Dec 2000 13:27:44 GMT Received: by mail-control.mail.uu.net id QQjscr26382 for mpls-outgoing; Mon, 4 Dec 2000 13:27:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjscr26377 for ; Mon, 4 Dec 2000 13:27:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjscr25445 for ; Mon, 4 Dec 2000 13:26:55 GMT Received: from smtp6.mindspring.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQjscr20324 for ; Mon, 4 Dec 2000 13:26:55 GMT Received: from mindspring.com (user-2ive39i.dialup.mindspring.com [165.247.13.50]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id IAA24581; Mon, 4 Dec 2000 08:26:18 -0500 (EST) Message-ID: <3A2B9BDA.F1AD3E8B@mindspring.com> Date: Mon, 04 Dec 2000 08:27:54 -0500 From: Eric Gray Reply-To: ewgray@mindspring.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ashwood-Smith CC: mpls@UU.NET Subject: Re: New MPLS Charter? References: <200012032247.OAA21378@cisco.com> <3A2AEFC0.83AB40CF@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Peter, We're bandying words here. In the abstract of your draft, you give specific examples of the other things you would like to see covered by GMPLS signaling. If you read through my original message, you will see that I said that MPL(ambda)S may be extended in the scope of its meaning to include other types of optical switching - including TDM time-slot and spatial switching applied to optics. The key here is the word "optical". If you look carefully at the abstract of your draft, there is very little targeted there that is not optical. As for the argument that we should do the work all in one place, I do not disagree. I just do not think it should be in the MPLS working group as previously constituted. Our work there is done, and I think it is time we let the world know that. Then we can all move on, like so many of us did from LANE and MPOA and other completed specifications. -- Eric Gray Peter Ashwood-Smith wrote: > Yakov Rekhter wrote: > > > > Eric, > > > > > The problem with including "implicit" labels in > > > the MPLS working group charter is that doing so > > > may defeat the intent of getting the charter down to > > > a manageable size. GMPLS may be generic in its > > > intent, but I think we all know that the focus remains > > > on MPL(ambda)S. > > I do not believe the focus is on Lambda switching. Most > devices today are doing either spacial switching with > mirrors or bubbles or some other physical device, or > TDM switching with SONET. The Lambda stuff is done with > a DWDM infront of a space switch, at least to the best > of my knowledge. As a result there is a great deal of > interest in TDM and Spacial switching right now. > > > > If the idea is to break up the > > > charter into manageable chunks, MPL(ambda)S > > > might be better off in the IPO working group. This > > > is especially true, if MPL(ambda)S includes TDM > > > time-slot assignment "label", optical waveband and > > > optical fiber switching: if these are included, the delta > > > between MPL(ambda)S and GMPLS is very small. > > If we need more time to discuss the various things going > on in MPLS then let's have another WG meeting. Its kind of > frustrating doing almost the same thing several times in > different groups. I recall the traffic engineering stuff > being duplicated and would hate to see us do the same > things with GMPLS. > > > > As far as GMPLS is concerned, IMHO, we > > > need to make a philosophical distinction as to > > > whether GMPLS is intended to be a generalized > > > use of MPLS signaling or an attempt generalize > > > MPLS signaling. The distinction is a subtle one, > > > but I think it's at the root of whether or not we > > > (as individuals) feel GMPLS belongs in the MPLS > > > working group. If it is intended to be a generalized > > > use of MPLS signaling, then it should probably > > > find a home elsewhere. If it is intended that MPLS > > > signaling itself should be generalized, then it should > > > be done in the MPLS working group. > > Call me naive, but I have always felt that a path, no > matter what the characteristics of the switches that create > that path, is controllable by a single signaling and routing > protocol and that only minor differences are required to deal > with the differences in switching technology. As such I > see GMPLS as an attempt to generalize MPLS signaling, not > something that you piggy back on existing MPLS signaling. > > Anyway, my simplistic view of things looks like this: > > - a place to discuss signaling for all layer 1&2 switches. (G)MPLS-WG > - a place to discuss routing OSPF & ISIS-WG > - a place to discuss traffic engineering TE-WG > - a place to discuss applications of (G)MPLS > - a place to discuss peculiarities of different layer 1&2 technologies, IPO+other standards bodies > > Cheers, > > Peter From owner-mpls@UU.NET Mon Dec 4 08:57:38 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24287 for ; Mon, 4 Dec 2000 08:57:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsct15697; Mon, 4 Dec 2000 13:56:36 GMT Received: by mail-control.mail.uu.net id QQjsct27832 for mpls-outgoing; Mon, 4 Dec 2000 13:56:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsct27804 for ; Mon, 4 Dec 2000 13:55:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsct25258 for ; Mon, 4 Dec 2000 13:55:29 GMT Received: from ennovatenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjsct22524 for ; Mon, 4 Dec 2000 13:55:29 GMT Received: from tworster (iguard2.ennovatenetworks.com [63.102.148.66]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id IAA04452; Mon, 4 Dec 2000 08:55:23 -0500 (EST) (envelope-from tom@ennovatenetworks.com) From: "tom worster" To: "'Andre N. Fredette'" Cc: "Mpls List (E-mail)" Subject: RE: New MPLS Charter? Date: Mon, 4 Dec 2000 08:54:53 -0500 Message-ID: <007b01c05df9$c7dca560$7203010a@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.2911.0) In-Reply-To: <5.0.0.25.2.20001201171923.038bf7b8@mailbox> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Andre N. Fredette > > I've seen a couple of opinions posted on how things might get > sorted out. > > Are any of you working to sort out what goes where, and what > this means for > the upcoming meeting? i understand the current status to be that, given the new context of a) mpls re-chartering b) the new sub-ip pseudo-area c) the instantiation of certain new wgs, a great many many work items (i.e. i-ds) must be relocated. i understand that the ads are responsible for determining where each i-d now belongs and we now have to wait for their decision. c u tom From owner-mpls@UU.NET Mon Dec 4 08:58:18 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24445 for ; Mon, 4 Dec 2000 08:58:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsct01701; Mon, 4 Dec 2000 13:56:40 GMT Received: by mail-control.mail.uu.net id QQjsct27831 for mpls-outgoing; Mon, 4 Dec 2000 13:56:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsct27809 for ; Mon, 4 Dec 2000 13:55:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsct23425 for ; Mon, 4 Dec 2000 13:54:55 GMT Received: from samar.sasi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasi.com [164.164.56.2]) id QQjsct21663 for ; Mon, 4 Dec 2000 13:54:51 GMT Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id TAA23229 for ; Mon, 4 Dec 2000 19:24:47 +0530 (IST) Received: from suns3.sasi.com ([10.0.36.3]) by samar.sasi.com; Mon, 04 Dec 2000 19:24:47 +0000 (IST) Received: from localhost (soumen@localhost) by suns3.sasi.com (8.9.3/8.9.3) with ESMTP id TAA04897 for ; Mon, 4 Dec 2000 19:24:47 +0530 (IST) Date: Mon, 4 Dec 2000 19:24:47 +0530 (IST) From: Soumen Sarkar To: Subject: MPLS and fragmentation.. (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi All, I am still waiting for response. Could someone please give some useful pointer here ? -best regards, Soumen On Fri, Nov 24, 2000 at 02:58:09PM +0530, Soumen Sarkar wrote: > > > Hi, > Sorry for bringing back this issue. There were quite > a few mails exchanged on this. Could someone > tell me what has been the accepted strategy to handle > IP fragmentation in MPLS domain. > I would be glad to hear in both cases where > DF bit is set and the cases where DF bit is not set. > -thanks in advance, > Soumen Soumen Sarkar -------------------------------------------------------------------- Project Leader, HS Datacom Soln. Phone: 91-80-5281461 Sasken Communication Technologies Limited Ext: 6364 3008, 12th B Main, 8 Cross, HAL II Stage, Fax: 91-80-5286020 Indiranagar, Bangalore - 560 008, INDIA. Email: soumen@sasken.com From owner-mpls@UU.NET Mon Dec 4 09:43:20 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08749 for ; Mon, 4 Dec 2000 09:43:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjscw03054; Mon, 4 Dec 2000 14:42:17 GMT Received: by mail-control.mail.uu.net id QQjscw12670 for mpls-outgoing; Mon, 4 Dec 2000 14:41:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjscw12656 for ; Mon, 4 Dec 2000 14:41:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjscw18421 for ; Mon, 4 Dec 2000 14:41:00 GMT Received: from gorilla.mchh.siemens.de by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQjscw01063 for ; Mon, 4 Dec 2000 14:40:59 GMT Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA16416; Mon, 4 Dec 2000 15:40:01 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA07281; Mon, 4 Dec 2000 15:40:27 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 15:40:24 +0100 Message-ID: From: Hummel Heinrich To: "'Shahram Davari'" Cc: "'mpls@UU.NET'" Subject: AW: New MPLS charter Date: Mon, 4 Dec 2000 15:40:17 +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 > Shahram, > Maybe we both will learn more good reasons in the Forwarding and Control Element Separation BOF (forces) Heinrich > Although at the beginning of MPLS development it was believed that longest prefix match is slow and label switching will improve it, but future developments showed otherwise. In fact very good algorithms became available that could do a maximum of 3 lookups to do the longest prefix match. So the benefits of MPLS with regard to fast lookup diminished. > > Good point. And I also believe that the existing label transport within BGP4 is an excellent move in the same direction that I am thinking. > > Give me some time to think about other good reasons. Routing is a large area, maybe anybody else find new reasons to do so !? :-) > > > > I mentioned several protocols where to setup labels for > > the control plane: Particularly BGP4 and LDP(unsolicited > > downstream mode). > > But you still need IP to transport BGP, LDP, ..., don't you? > > Sure. > > > Yours, and have a good weekend > > Heinrich From owner-mpls@UU.NET Mon Dec 4 09:55:12 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12153 for ; Mon, 4 Dec 2000 09:55:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjscx19775; Mon, 4 Dec 2000 14:53:56 GMT Received: by mail-control.mail.uu.net id QQjscx13690 for mpls-outgoing; Mon, 4 Dec 2000 14:53:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjscx13676 for ; Mon, 4 Dec 2000 14:53:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjscx02589 for ; Mon, 4 Dec 2000 14:51:30 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjscx18588 for ; Mon, 4 Dec 2000 14:51:29 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA07447 for mpls@uu.net; Mon, 4 Dec 2000 09:51:28 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjscx13446 for ; Mon, 4 Dec 2000 14:50:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjscx17165 for ; Mon, 4 Dec 2000 14:50:00 GMT Received: from nero.doit.wisc.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQjscx15775 for ; Mon, 4 Dec 2000 14:49:59 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id IAA27643; Mon, 4 Dec 2000 08:48:45 -0600 Date: Mon, 4 Dec 2000 08:48:45 -0600 From: "James R. Leu" To: Shahram Davari Cc: "'francis arts vh624 8492'" , jleu@mindspring.com, Francis Arts , Satoru Matsushima , mpls@UU.NET, mpls-wg@janog.gr.jp Subject: Re: Processing the MPLS TTL Message-ID: <20001204084845.A27633@doit.wisc.edu> Reply-To: jleu@mindspring.com References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AB7@BBY1EXM01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9AB7@BBY1EXM01>; from Shahram_Davari@pmc-sierra.com on Mon, Dec 04, 2000 at 04:59:35AM -0800 Organization: none Sender: owner-mpls@UU.NET Precedence: bulk Hello, On Mon, Dec 04, 2000 at 04:59:35AM -0800, Shahram Davari wrote: > Hi, > > I think both methods are allowed. The two scenarios that they might be used > are in Uniform and Tunnel model. In the Uniform model we probably like to > copy the MPLS TTL to the IP TTL, and in Tunnel mode we probably like to just > decrement the IP TTL by one. Isn't there a possible interoperabilty problem with this? The Ingress and Egress have to agree on the same way of handling the TTL? AFAIK none of the signling protocols convery this info. Jim > Yours, > -Shahram > > > -----Original Message----- > > From: francis arts vh624 8492 [mailto:fart@sh.bel.alcatel.be] > > Sent: Monday, December 04, 2000 1:07 AM > > To: jleu@mindspring.com > > Cc: Francis Arts; Satoru Matsushima; mpls@UU.NET; mpls-wg@janog.gr.jp > > Subject: Re: Processing the MPLS TTL > > > > > > > > Jim, > > > > I agree that section 2.4.3 indeed indicates that "when a > > label is popped, and the > > resulting label stack is empty, then the value of the IP TTL > > field SHOULD BE > > replaced with the outgoing TTL value". > > > > However, the last paragraph of section 2.4.3 also states that > > 'it is recognized > > that there may be situations where a network administration > > prefers to decrement > > the IPv4 TTL by one as it traverses an MPLS domain, instead > > of decrementing the > > IPv4 TTL by the number of LSP hops within the domain." > > > > So if one would use the latter approach, the TTL is not meant > > to be copied from > > the MPLS header into the IP header in the LSP egress node. > > > > Kind regards, > > > > Francis. > > -- James R. Leu From owner-mpls@UU.NET Mon Dec 4 10:01:42 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14503 for ; Mon, 4 Dec 2000 10:01:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjscx27458; Mon, 4 Dec 2000 14:59:09 GMT Received: by mail-control.mail.uu.net id QQjscx14228 for mpls-outgoing; Mon, 4 Dec 2000 14:58:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjscx14221 for ; Mon, 4 Dec 2000 14:58:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjscx11684 for ; Mon, 4 Dec 2000 14:57:38 GMT From: venkir@samsung.co.kr Received: from omail01.samsung.co.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjscx28765 for ; Mon, 4 Dec 2000 14:57:36 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id XAA22669; Mon, 4 Dec 2000 23:58:40 +0900 (KST) X-OpenMail-Hops: 2 Date: Mon, 4 Dec 2000 23:57:54 +0900 Message-Id: In-Reply-To: Subject: (Reply) Query about handling Non RSVP neighbours in RSVP-TE MIME-Version: 1.0 TO: mpls@UU.NET, prasanna@csa.iisc.ernet.in Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Mon, 4 Dec 2000 23:28:47 +0900" ;Modification-Date="Mon, 4 Dec 2000 23:57:45 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi prasanna, You r correct only, i.e., the first option is corect. Actually, in that paragraph, they explained about two scenarios. First one is about non-rsvp node as downstream router. In that case, upstream router has to send patherr. It's fine. Second one dealing with the case, where non-rsvp node as upstream router. That means if a rsvp node, gets a path message with LABEL_REQUEST from a non-rsvp node, it has to send a patherr message. Here message is from a non-rsvp node. Am I right? But only thing is, how come, a non-rsvp node sends a path message with LABEL_ REQUEST to rsvp node? I don't think, this case will arise in real time scenario. Regards, Reddy. ---------Original Message--------- I am eager to know the following as it was not clear to me from the draft. This is one of the paragrph from the draft 07.txt 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." This same message SHOULD be sent, if a router receives a LABEL_REQUEST object in a message from a non-RSVP capable router. See [1] for a description of how a downstream router can determine the presence of non-RSVP routers. Does it mean that if we find a non RSVP hop in between we should stop propogating Path mesages forward or does it mean that when we forward the path message it should not contain Label Request Object. If the latter is the correct option, then how can we acheive a proper setting up of an LSP. Because if we dont put Label Request Object in Path message there wont be any Label Object in Resv Message and if this haapens the we have failed to distribute labels to all the nodes along the path. So i think the first option is the correct one ?? Please let me know if i am wrong.... Thanx in advance Pras From owner-mpls@UU.NET Mon Dec 4 10:17:43 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19270 for ; Mon, 4 Dec 2000 10:17:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjscy24532; Mon, 4 Dec 2000 15:14:31 GMT Received: by mail-control.mail.uu.net id QQjscy27328 for mpls-outgoing; Mon, 4 Dec 2000 15:13:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjscy27313 for ; Mon, 4 Dec 2000 15:13:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjscy02859 for ; Mon, 4 Dec 2000 15:13:34 GMT Received: from sutton.acbm.qc.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.96.170.5]) id QQjscy26536 for ; Mon, 4 Dec 2000 15:13:18 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by sutton.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-69929U800L2S100V35) with ESMTP id ca; Mon, 4 Dec 2000 10:09:42 -0500 Received: by HERMES with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 10:12:57 -0500 Message-ID: From: Eyad Saheb To: "'Robert Schellhase'" , "'Alexander.Marhold@xandl.cso.net'" , "'Nhat Thanh Hoang'" , "'eduard metz'" Cc: "'mpls@UU.NET'" Subject: RE: MPLS for UDLR Date: Mon, 4 Dec 2000 10:12:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05E04.AEA912D0" 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_01C05E04.AEA912D0 Content-Type: text/plain; charset="iso-8859-1" Have you considered CR/LDP ? Ofcourse, there's the TCP overhead (is TCP affected by UDL?), but I don't believe CR/LDP has the bi-directional link limitation that RSVP does. However, CR/LDP doesn't have the refreshs; the overhead is only incurred on LSP setup & neighor discovery. For further study, I guess. Eyad -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Robert Schellhase Sent: Thursday, November 30, 2000 9:58 AM To: Alexander.Marhold@xandl.cso.net; Nhat Thanh Hoang; eduard metz Cc: mpls@UU.NET Subject: RE: MPLS for UDLR Thanks for the RSVP insights. They improve my overall understanding of what's happening. UDLR is supposed to fix the problem of receiving on one interface while sending on another, by combining the two physical paths into a single logical interface. So it sounds like we are saying that since MPLS uses RSVP to build its tunnels, but RSVP needs bi-directional interfaces to get its job done, and therein lies the problem. Am I reading this correctly? Does anyone else have thoughts, or a possible workaround idea? Best regards, Robert -----Original Message----- From: Alexander Marhold [mailto:Alexander.Marhold@proin.com] Sent: Thursday, November 30, 2000 2:07 AM To: Nhat Thanh Hoang; Alexander.Marhold@xandl.cso.net; eduard metz; rschell@megapathdsl.net Subject: RE: MPLS for UDLR > As I know RSVP for traffic engineering that uses in MPLS context is > unidirectional, which means you need to configure at least two > constraint-based LSPs (ingress--->egress and ingress<---egress), > if you want > a bidirectional path. > >> LSP is unidirectional, but RSVP is not, >> Sorry for not being clear enough: Of course you are right the tunnel which is set up by RSVP is unidirectional (this is what we tell RSVP when starting the RESV message). What I wanted to express is: That the messages itself, RSVP is sending forward (RESV) and backwards (PATH) to set up the path are assumed to go over the same links in forward and reverse direction. In the UDLR case those links forward and reverse are different. And I think that exactly that is the problem in the UDLR case. with best regards Alexander ------_=_NextPart_001_01C05E04.AEA912D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS for UDLR

Have you considered CR/LDP ?  Ofcourse, there's = the TCP overhead (is TCP affected by UDL?), but I don't believe CR/LDP = has the bi-directional link limitation that RSVP  does.  = However, CR/LDP doesn't have the refreshs; the overhead is only = incurred on LSP setup & neighor discovery.

For further study, I guess.

Eyad

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of Robert
Schellhase
Sent: Thursday, November 30, 2000 9:58 AM
To: Alexander.Marhold@xandl.cso.net; Nhat Thanh = Hoang; eduard metz
Cc: mpls@UU.NET
Subject: RE: MPLS for UDLR


Thanks for the RSVP insights. They improve my overall = understanding of
what's happening.

UDLR is supposed to fix the problem of receiving on = one interface while
sending on another, by combining the two physical = paths into a single
logical interface. So it sounds like we are saying = that since MPLS uses RSVP
to build its tunnels, but RSVP needs bi-directional = interfaces to get its
job done, and therein lies the problem.

Am I reading this correctly? Does anyone else have = thoughts, or a possible
workaround idea?

Best regards,
Robert

-----Original Message-----
From: Alexander Marhold [mailto:Alexander.Marhold@pro= in.com]
Sent: Thursday, November 30, 2000 2:07 AM
To: Nhat Thanh Hoang; = Alexander.Marhold@xandl.cso.net; eduard metz;
rschell@megapathdsl.net
Subject: RE: MPLS for UDLR


> As I know RSVP for traffic engineering that uses = in MPLS context is
> unidirectional, which means you need to = configure at least two
> constraint-based LSPs (ingress--->egress and = ingress<---egress),
> if you want
> a bidirectional path.
>
>> LSP is unidirectional, but RSVP is = not,
>>

Sorry for not being clear enough:
Of course you are right  the tunnel which is = set up by RSVP is
unidirectional (this is what we tell RSVP when = starting the RESV message).

What I wanted to express is:
That the messages itself, RSVP is sending forward = (RESV) and backwards
(PATH) to set up the path are assumed to go over the = same links in forward
and reverse direction. In the UDLR case those links = forward and reverse are
different.

And I think that exactly that is the problem in the = UDLR case.

with best regards
Alexander

------_=_NextPart_001_01C05E04.AEA912D0-- From owner-mpls@UU.NET Mon Dec 4 10:25:47 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21674 for ; Mon, 4 Dec 2000 10:25:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjscz15238; Mon, 4 Dec 2000 15:23:36 GMT Received: by mail-control.mail.uu.net id QQjscz28578 for mpls-outgoing; Mon, 4 Dec 2000 15:22:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjscz28558 for ; Mon, 4 Dec 2000 15:22:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjscz29234 for ; Mon, 4 Dec 2000 15:18:54 GMT Received: from sutton.acbm.qc.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.96.170.5]) id QQjscz01001 for ; Mon, 4 Dec 2000 15:18:53 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by sutton.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-69929U800L2S100V35) with ESMTP id ca; Mon, 4 Dec 2000 10:15:23 -0500 Received: by HERMES with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 10:18:37 -0500 Message-ID: From: Eyad Saheb To: "'Eric Osborne'" , "'Guangzhi Li'" Cc: "'Gaitonde Anandprasanna'" , "'Eric Gray'" , "'mpls@UU.NET'" Subject: RE: Difficulty about IPv4 Prefix in Explicit route Object in RSVP -TE Date: Mon, 4 Dec 2000 10:18:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05E05.79D40780" 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_01C05E05.79D40780 Content-Type: text/plain; charset="iso-8859-1" I have to agree. RSVP-TE has already escaped from the labs and is implemented in its current form by several vendors. Any change now would likely be met by some resistance (of course the vendors should've known about this when they released software based on a draft...). Eyad -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Eric Osborne Sent: Thursday, November 30, 2000 7:55 PM To: Guangzhi Li Cc: Gaitonde Anandprasanna; Eric Gray; mpls@UU.NET Subject: Re: Difficulty about IPv4 Prefix in Explicit route Object in RSVP-TE I can't speak from an implementation standpoint, but I see little reason to change this. It may make things a little easier to code, but then you have to figure out how to be interoperable with all the existing implementations that are deployed already. It seems to me that you'd have to find some way to be backward-compatabile, as well as deal with all the implementations that would behave poorly (possibly crash, etc) because they misinterpreted the new ERO format. Again, I'm not one to make a decision one way or the other about whether this gets done or not, but if I ran the world I'd have to come out against this idea. eric On Thu, Nov 30, 2000 at 04:04:20PM -0500, Guangzhi Li wrote: > Hi, all: > > I asked this question several times. Only Eric Gray gave one reason. > > Thanks for the suggestion. Lots of implementations are going on. Can we change it > now? Our future life will be much easier. > > Putting IPv4 and IPv6 at the end will make implementation easy and few bugoses. > > How many people will support this ?? Thanks. > > -- Guangzhi > > Gaitonde Anandprasanna wrote: > > > Thanks for replying. > > > > But i think if we have the IPV4 prefix at the end then it is much > > easier for implementation. > > > > So cant we change it now??? > > > > Pras > > > > On Thu, 30 Nov 2000, Eric Gray wrote: > > > > > As I recall, the reason for this was that there was > > > an existing implementation that did it this way. In > > > some models of the Universe, no further justification > > > is required. :-) > > > > > > -- > > > Eric Gray > > > > > > Gaitonde Anandprasanna wrote: > > > > > > > I am sorry to repost this question but i am reallly interested in knowing > > > > this . > > > > > > > > If the question i asked is correct then also let me know if in subsequent > > > > drafts we can change the format of ERO subobject (i.e. putting the IPv4 > > > > address at the end of the object.) > > > > > > > > Here is my previous mail :- > > > > > > > > This question was asked by some person earlier but somehow i did not see > > > > the answers in the mailing lists. If i have missed the answer then please > > > > provide pointers to mail archives. > > > > > > > > I wanted to know why the format of the IPv4 Prefix is that way: > > > > > > > > RSVP ERO subobject IPv4 address:- > > > > > > > > In RSVP-TE, the format of subobject 1: IPv4 address (4.4.1.1) is > > > > > > > > 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 | IPv4 address > > > > ----------------------------------------------------------------- > > > > IPv4 address | Prefix Length | Flags > > > > ------------------------------------------------------------------ > > > > > > > > Can somebody explain to me: What is the advantage to split the IPv4 > > > > address in two words? From the > > > > implementation point of view, it should be much easy to put IPv4 address > > > > in a single word. > > > > > > > > Thanx in advance > > > > > > > > Pras ------_=_NextPart_001_01C05E05.79D40780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Difficulty about IPv4 Prefix in Explicit route Object in = RSVP-TE

I have to agree.  RSVP-TE has already escaped = from the labs and is implemented in its current form by several = vendors.  Any change now would likely be met by some resistance = (of course the vendors should've known about this when they released = software based on a draft...).

Eyad

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of Eric
Osborne
Sent: Thursday, November 30, 2000 7:55 PM
To: Guangzhi Li
Cc: Gaitonde Anandprasanna; Eric Gray; = mpls@UU.NET
Subject: Re: Difficulty about IPv4 Prefix in = Explicit route Object in
RSVP-TE


I can't speak from an implementation standpoint, but = I see little
reason to change this.  It may make things a = little easier to code,
but then you have to figure out how to be = interoperable with all the
existing implementations that are deployed = already.  It seems to me
that you'd have to find some way to be = backward-compatabile, as well
as deal with all the implementations that would = behave poorly
(possibly crash, etc) because they misinterpreted = the new ERO format.

Again, I'm not one to make a decision one way or the = other about
whether this gets done or not, but if I ran the = world I'd have to come
out against this idea.



eric

On Thu, Nov 30, 2000 at 04:04:20PM -0500, Guangzhi Li = wrote:
> Hi, all:
>
> I asked this question several times. Only Eric = Gray gave one reason.
>
> Thanks for the suggestion. Lots of = implementations are going on. Can we change it
> now? Our future life will be much = easier.
>
> Putting IPv4 and IPv6 at the end will make = implementation easy and few bugoses.
>
> How many people will support this ?? = Thanks.
>
> -- Guangzhi
>
> Gaitonde Anandprasanna wrote:
>
> > Thanks for replying.
> >
> >    But i think if we have = the IPV4 prefix at the end then it is much
> > easier for implementation.
> >
> > So cant we change it now???
> >
> > Pras
> >
> > On Thu, 30 Nov 2000, Eric Gray = wrote:
> >
> > > As I recall, the reason for this was = that there was
> > > an existing implementation that did = it this way.  In
> > > some models of the Universe, no = further justification
> > > is required. :-)
> > >
> > > --
> > > Eric Gray
> > >
> > > Gaitonde Anandprasanna wrote:
> > >
> > > > I am sorry to repost this = question but i am reallly interested in knowing
> > > > this .
> > > >
> > > > If the question i asked is = correct then also let me know if in subsequent
> > > > drafts we can change the format = of ERO subobject  (i.e. putting the IPv4
> > > > address at the end of the = object.)
> > > >
> > > > Here is my previous mail = :-
> > > >
> > > > This question was asked by some = person earlier but somehow i did not see
> > > > the answers in the mailing = lists. If i have missed the answer then please
> > > > provide pointers to mail = archives.
> > > >
> > > > I wanted to know why the format = of the IPv4 Prefix is that way:
> > > >
> > > >  RSVP ERO subobject IPv4 = address:-
> > > >
> > > >  In RSVP-TE, the format of = subobject 1: IPv4 address (4.4.1.1) is
> > > >
> > > > 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 | IPv4 address
> > > > = -----------------------------------------------------------------=
> > > = >         IPv4 address | = Prefix Length | Flags
> > > > = ------------------------------------------------------------------
> > > >
> > > > Can somebody explain to me: What = is the advantage to split the IPv4
> > > > address in two words? From = the
> > > > implementation point of view, it = should be much easy to put IPv4 address
> > > > in a single word.
> > > >
> > > > Thanx in advance
> > > >
> > > > Pras

------_=_NextPart_001_01C05E05.79D40780-- From owner-mpls@UU.NET Mon Dec 4 10:38:52 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24082 for ; Mon, 4 Dec 2000 10:38:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsda23176; Mon, 4 Dec 2000 15:37:13 GMT Received: by mail-control.mail.uu.net id QQjsda00249 for mpls-outgoing; Mon, 4 Dec 2000 15:36:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsda00237 for ; Mon, 4 Dec 2000 15:36:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsda02399 for ; Mon, 4 Dec 2000 15:36:07 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjsda08392 for ; Mon, 4 Dec 2000 15:36:07 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA15927 for mpls@uu.net; Mon, 4 Dec 2000 10:36:06 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsda00131 for ; Mon, 4 Dec 2000 15:35:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsda25476 for ; Mon, 4 Dec 2000 15:33:52 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjsda18534 for ; Mon, 4 Dec 2000 15:33:51 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id HAA01242; Mon, 4 Dec 2000 07:32:39 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 07:32:55 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9ABD@BBY1EXM01> From: Shahram Davari To: "'Soumen Sarkar'" , mpls@UU.NET Subject: RE: MPLS and fragmentation.. (fwd) Date: Mon, 4 Dec 2000 07:32:52 -0800 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, Check section 3 of: http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-08.txt Yours, _Shahram > -----Original Message----- > From: Soumen Sarkar [mailto:soumen@sasken.com] > Sent: Monday, December 04, 2000 8:55 AM > To: mpls@UU.NET > Subject: MPLS and fragmentation.. (fwd) > > > > > Hi All, > I am still waiting for response. Could someone > please give some useful pointer here ? > -best regards, > Soumen > > On Fri, Nov 24, 2000 at 02:58:09PM +0530, Soumen Sarkar wrote: > > > > > > Hi, > > Sorry for bringing back this issue. There were quite > > a few mails exchanged on this. Could someone > > tell me what has been the accepted strategy to handle > > IP fragmentation in MPLS domain. > > I would be glad to hear in both cases where > > DF bit is set and the cases where DF bit is not set. > > -thanks in advance, > > Soumen > > > Soumen Sarkar > -------------------------------------------------------------------- > Project Leader, HS Datacom Soln. Phone: 91-80-5281461 > Sasken Communication Technologies Limited Ext: 6364 > 3008, 12th B Main, 8 Cross, HAL II Stage, Fax: 91-80-5286020 > Indiranagar, Bangalore - 560 008, INDIA. Email: soumen@sasken.com > > > From owner-mpls@UU.NET Mon Dec 4 10:44:03 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25835 for ; Mon, 4 Dec 2000 10:44:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsda03969; Mon, 4 Dec 2000 15:42:01 GMT Received: by mail-control.mail.uu.net id QQjsda00732 for mpls-outgoing; Mon, 4 Dec 2000 15:41:14 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsda00711 for ; Mon, 4 Dec 2000 15:41:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsda12310 for ; Mon, 4 Dec 2000 15:39:18 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjsda26368 for ; Mon, 4 Dec 2000 15:39:16 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA16491 for mpls@uu.net; Mon, 4 Dec 2000 10:39:15 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsda00418 for ; Mon, 4 Dec 2000 15:38:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsda09254 for ; Mon, 4 Dec 2000 15:38:20 GMT Received: from boyle.eng.level3.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu162-236-107.nc.rr.com [24.162.236.107]) id QQjsda28537 for ; Mon, 4 Dec 2000 15:38:19 GMT Received: from localhost (jboyle@localhost) by boyle.eng.level3.com (8.9.3/8.8.7) with ESMTP id IAA02775; Mon, 4 Dec 2000 08:40:02 -0700 X-Authentication-Warning: boyle.eng.level3.com: jboyle owned process doing -bs Date: Mon, 4 Dec 2000 08:38:42 -0700 (MST) From: Jim Boyle X-Sender: jboyle@boyle.eng.level3.com To: wesam.alanqar@mail.sprint.com cc: mastropietro@coritel.it, mpls@UU.NET Subject: RE: E-LSP or L-LSP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 22 Nov 2000 wesam.alanqar@mail.sprint.com wrote: > Hi > > E-LSP is used when DSCP DiffServ field is mapped to the EXP field in the > MPLS header. > L-LSP is used when DSCP DiffServ field is mapped to the EXP+LABEL fields > in the MPLS header. actually, I don't think L-LSPs look at EXP, just the label. My answer to this question is: consult your vendor. Most high end routers I know of can do a good level of queue processing based on the COS bits (aka the EXP bits), thus for many, this works now. Some high end router vendors can infer the queuing to do based on the label, but I'm not sure about the availability of that. At least one router vendor (avici) should be working to make this available, as L-LSPs have curtis as a major advocate :) best of luck. Jim > > Thanks. > ------------------------------------------------------------------------ > - > Wesam Alanqar > Member of Technical Staff > Technology Concepts, Innovations and Evaluation (TCIE) > Technology Planning & Integration- Sprint TP&I > 9300 Metcalf Avenue > Overland Park, KS 66212-1463 > Phone: 913-534-5623 > Fax: 913-534-3485 > ------------------------------------------------------------------------ > - > > > > > -----Original Message----- > > From: mastropietro [mailto:mastropietro@coritel.it] > > Sent: Wednesday, November 22, 2000 4:05 AM > > To: mpls > > Cc: mastropietro > > Subject: E-LSP or L-LSP > > > > > > Hi All, > > I am a novel researcher on MPLS and TE for Co.Ri.Tel ( Rome, Italy)... > > Is there anyone that can help me to understand when E-LSPs or L-LSPs > > actually should be used? > > Thanks in advance > > > > Simeone Mastropietro > > > > > > From owner-mpls@UU.NET Mon Dec 4 10:46:24 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26577 for ; Mon, 4 Dec 2000 10:46:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsda19402; Mon, 4 Dec 2000 15:42:12 GMT Received: by mail-control.mail.uu.net id QQjsda00829 for mpls-outgoing; Mon, 4 Dec 2000 15:41:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsda00814 for ; Mon, 4 Dec 2000 15:41:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsda07427 for ; Mon, 4 Dec 2000 15:41:12 GMT Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQjsda02740 for ; Mon, 4 Dec 2000 15:41:12 GMT Received: from avici.com (swdev23.avici.com [10.1.2.229]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id eB4Fehq08867; Mon, 4 Dec 2000 10:40:43 -0500 (EST) Message-Id: <200012041540.eB4Fehq08867@mailhost.avici.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Markus Jork To: Eyad Saheb cc: "'Robert Schellhase'" , "'Alexander.Marhold@xandl.cso.net'" , "'Nhat Thanh Hoang'" , "'eduard metz'" , "'mpls@UU.NET'" Subject: Re: MPLS for UDLR In-reply-to: Your message of "Mon, 04 Dec 2000 10:12:56 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Dec 2000 10:40:42 -0500 Sender: owner-mpls@UU.NET Precedence: bulk Just to clear up some confusion in this e-mail exchange. RSVP does not have a problem with unidirectional links. A Path message can be sent out on one interface and the corresponding Resv message can come back in through any other interface. So when there is a unidirectional link from A to B, the only requirement is that B somehow has to be able to send back a Resv message to A (through some other interface or possibly via multiple other intermediate nodes). There is no need for a bi-directional link. Markus > Have you considered CR/LDP ? Ofcourse, there's the TCP overhead (is TCP > affected by UDL?), but I don't believe CR/LDP has the bi-directional link > limitation that RSVP does. However, CR/LDP doesn't have the refreshs; the > overhead is only incurred on LSP setup & neighor discovery. > > For further study, I guess. > > Eyad > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Robert > Schellhase > Sent: Thursday, November 30, 2000 9:58 AM > To: Alexander.Marhold@xandl.cso.net; Nhat Thanh Hoang; eduard metz > Cc: mpls@UU.NET > Subject: RE: MPLS for UDLR > > > Thanks for the RSVP insights. They improve my overall understanding of > what's happening. > > UDLR is supposed to fix the problem of receiving on one interface while > sending on another, by combining the two physical paths into a single > logical interface. So it sounds like we are saying that since MPLS uses RSVP > to build its tunnels, but RSVP needs bi-directional interfaces to get its > job done, and therein lies the problem. > > Am I reading this correctly? Does anyone else have thoughts, or a possible > workaround idea? > > Best regards, > Robert > > -----Original Message----- > From: Alexander Marhold [mailto:Alexander.Marhold@proin.com] > Sent: Thursday, November 30, 2000 2:07 AM > To: Nhat Thanh Hoang; Alexander.Marhold@xandl.cso.net; eduard metz; > rschell@megapathdsl.net > Subject: RE: MPLS for UDLR > > > > As I know RSVP for traffic engineering that uses in MPLS context is > > unidirectional, which means you need to configure at least two > > constraint-based LSPs (ingress--->egress and ingress<---egress), > > if you want > > a bidirectional path. > > > >> LSP is unidirectional, but RSVP is not, > >> > > Sorry for not being clear enough: > Of course you are right the tunnel which is set up by RSVP is > unidirectional (this is what we tell RSVP when starting the RESV message). > > What I wanted to express is: > That the messages itself, RSVP is sending forward (RESV) and backwards > (PATH) to set up the path are assumed to go over the same links in forward > and reverse direction. In the UDLR case those links forward and reverse are > different. > > And I think that exactly that is the problem in the UDLR case. > > with best regards > Alexander > > > > > > > RE: MPLS for UDLR > > > >

Have you considered CR/LDP ?  Ofcourse, there's the TCP overhead (is TCP affected by UDL?), but I don't believe CR/LDP has the bi-directional link limitation that RSVP  does.  However, CR/LDP doesn't have the refreshs; the overhead is only incurred on LSP setup & neighor discovery.

> >

For further study, I guess. >

> >

Eyad >

> >

-----Original Message----- >
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Robert >
Schellhase >
Sent: Thursday, November 30, 2000 9:58 AM >
To: Alexander.Marhold@xandl.cso.net; Nhat Thanh Hoang; eduard metz >
Cc: mpls@UU.NET >
Subject: RE: MPLS for UDLR >

>
> >

Thanks for the RSVP insights. They improve my overall understanding of >
what's happening. >

> >

UDLR is supposed to fix the problem of receiving on one interface while >
sending on another, by combining the two physical paths into a single >
logical interface. So it sounds like we are saying that since MPLS uses RSVP >
to build its tunnels, but RSVP needs bi-directional interfaces to get its >
job done, and therein lies the problem. >

> >

Am I reading this correctly? Does anyone else have thoughts, or a possible >
workaround idea? >

> >

Best regards, >
Robert >

> >

-----Original Message----- >
From: Alexander Marhold [mailto:Alexander.Marhold@proin.com] >
Sent: Thursday, November 30, 2000 2:07 AM >
To: Nhat Thanh Hoang; Alexander.Marhold@xandl.cso.net; eduard metz; >
rschell@megapathdsl.net >
Subject: RE: MPLS for UDLR >

>
> >

> As I know RSVP for traffic engineering that uses in MPLS context is >
> unidirectional, which means you need to configure at least two >
> constraint-based LSPs (ingress--->egress and ingress<---egress), >
> if you want >
> a bidirectional path. >
> >
>> LSP is unidirectional, but RSVP is not, >
>> >

> >

Sorry for not being clear enough: >
Of course you are right  the tunnel which is set up by RSVP is >
unidirectional (this is what we tell RSVP when starting the RESV message). >

> >

What I wanted to express is: >
That the messages itself, RSVP is sending forward (RESV) and backwards >
(PATH) to set up the path are assumed to go over the same links in forward >
and reverse direction. In the UDLR case those links forward and reverse are >
different. >

> >

And I think that exactly that is the problem in the UDLR case. >

> >

with best regards >
Alexander >

> > > > From owner-mpls@UU.NET Mon Dec 4 10:56:36 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29590 for ; Mon, 4 Dec 2000 10:56:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjscy24874; Mon, 4 Dec 2000 15:12:32 GMT Received: by mail-control.mail.uu.net id QQjscy27197 for mpls-outgoing; Mon, 4 Dec 2000 15:12:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjscy27178 for ; Mon, 4 Dec 2000 15:11:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjscy01063 for ; Mon, 4 Dec 2000 15:09:45 GMT Received: from ennovatenetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjscy17521 for ; Mon, 4 Dec 2000 15:09:45 GMT Received: from tworster (iguard2.ennovatenetworks.com [63.102.148.66]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id KAA08296; Mon, 4 Dec 2000 10:08:14 -0500 (EST) (envelope-from tom@ennovatenetworks.com) From: "tom worster" To: , "'Peter Ashwood-Smith'" Cc: Subject: RE: New MPLS Charter? Date: Mon, 4 Dec 2000 10:07:44 -0500 Message-ID: <007e01c05e03$f52a8050$7203010a@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.2911.0) In-Reply-To: <3A2A4AA1.D1A100CB@mindspring.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit eric, peter, in response to both of you: isn't coma supposed to be the new home for what gmpls is trying to do? when i read the description of coma (in the new sub-ip context) i understood it imply as much. (i'm assuming here that the gmpls draft involves, using eric's terminology, generalisation of mpls signalling and not a generalised use.) c u tom > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > Of Eric Gray > Sent: Sunday, December 03, 2000 8:29 AM > To: Peter Ashwood-Smith > Cc: mpls@UU.NET > Subject: Re: New MPLS Charter? > > > Peter, > > The problem with including "implicit" labels in > the MPLS working group charter is that doing so > may defeat the intent of getting the charter down to > a manageable size. GMPLS may be generic in its > intent, but I think we all know that the focus remains > on MPL(ambda)S. If the idea is to break up the > charter into manageable chunks, MPL(ambda)S > might be better off in the IPO working group. This > is especially true, if MPL(ambda)S includes TDM > time-slot assignment "label", optical waveband and > optical fiber switching: if these are included, the delta > between MPL(ambda)S and GMPLS is very small. > > As far as GMPLS is concerned, IMHO, we > need to make a philosophical distinction as to > whether GMPLS is intended to be a generalized > use of MPLS signaling or an attempt generalize > MPLS signaling. The distinction is a subtle one, > but I think it's at the root of whether or not we > (as individuals) feel GMPLS belongs in the MPLS > working group. If it is intended to be a generalized > use of MPLS signaling, then it should probably > find a home elsewhere. If it is intended that MPLS > signaling itself should be generalized, then it should > be done in the MPLS working group. > > Again, IMHO, we should not try to generalize > the set of protocols that apply to anything using > MPLS - that seems like a rat-hole and contributes > to a general atmosphere of FUD. > > -- > Eric Gray > > Peter Ashwood-Smith wrote: > > > I can see how a literal interpretation of item 3) could > cause problems. > > Being pragmatic let me suggest that we insert an indication > that both implicit > > and explicit labels are part of the charter. > > > > I believe the literal interpretation that George is > referring to is > > "explicit labels" and indeed if we are limited to explicit > labels GMPLS > > is homeless. I am sure that is not the intention of the > wording because > > it clearly talks about implicit label switching like > wavlength and space > > so simply adding the words "implicit and explicit" should > solve the problem. > > > > Cheers, > > > > Peter Ashwood-Smith From owner-mpls@UU.NET Mon Dec 4 11:02:40 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01616 for ; Mon, 4 Dec 2000 11:02:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdc21507; Mon, 4 Dec 2000 16:01:07 GMT Received: by mail-control.mail.uu.net id QQjsdc04332 for mpls-outgoing; Mon, 4 Dec 2000 16:00:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsdc03691 for ; Mon, 4 Dec 2000 16:00:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsdc17519 for ; Mon, 4 Dec 2000 16:00:06 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQjsdc29834 for ; Mon, 4 Dec 2000 16:00:05 GMT Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 4 Dec 2000 10:59:17 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YHZ3TWCK; Mon, 4 Dec 2000 10:59:12 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YFZDN52H; Mon, 4 Dec 2000 10:59:10 -0500 Message-ID: <3A2BBF47.2E3E3F8@americasm01.nt.com> Date: Mon, 04 Dec 2000 10:59:03 -0500 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: "mohanvak@future.futsoft.com" CC: "'mpls@uu.net'" Subject: Re: Any dependency Ip over Optical model in MPLS References: <01C05E0F.A6523660.mohanvak@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Does the MPLS signalling enhanced drafts for > optical (RSVP or CRLDP) assume any of these models > or they are completly independent of the above > framework. RSVP-TE, CRLDP and GMPLS do not force you into either an overlay or a peer model. Cheers, Peter Ashwood-Smith From owner-mpls@UU.NET Mon Dec 4 11:04:34 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02423 for ; Mon, 4 Dec 2000 11:04:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdc00058; Mon, 4 Dec 2000 16:01:20 GMT Received: by mail-control.mail.uu.net id QQjsdc04749 for mpls-outgoing; Mon, 4 Dec 2000 16:00:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsdc04711 for ; Mon, 4 Dec 2000 16:00:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsdc17645 for ; Mon, 4 Dec 2000 16:00:08 GMT Received: from sutton.acbm.qc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.96.170.5]) id QQjsdc27705 for ; Mon, 4 Dec 2000 16:00:02 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by sutton.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-69929U800L2S100V35) with ESMTP id ca; Mon, 4 Dec 2000 10:56:31 -0500 Received: by HERMES with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 10:59:43 -0500 Message-ID: From: Eyad Saheb To: "'jleu@mindspring.com'" Cc: "'mpls@uu.net'" Subject: RE: Processing the MPLS TTL Date: Mon, 4 Dec 2000 10:59:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05E0B.375CBE50" 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_01C05E0B.375CBE50 Content-Type: text/plain; charset="iso-8859-1" see below... -----Original Message----- From: James R. Leu [mailto:jleu@mindspring.com] Sent: Monday, December 04, 2000 10:49 AM To: Eyad Saheb Cc: 'jleu@mindspring.com' Subject: Re: Processing the MPLS TTL Hello, On Mon, Dec 04, 2000 at 10:32:03AM -0500, Eyad Saheb wrote: > I believe there is a simple answer to this: configuration. Whether the > network admin wishes to decrement IP TTL throughout the network, or to make > the network appear as one logical hop, it should simply be a matter of > configuring the LER's (ingress or egress, they're the same box). Not for a particular LSP. The LSP setup was requested by ingress, the ingress also decided between case 1 or 2 when forwarding traffic. How does the egress know which case? Manual configuration isn't acceptable because the admin may not even know that this LSP was ever going to be terminated at this node (although that is unlikely, it just proves the point). Either we need to make a decisive statement such as "All TE LSPs will use case 2 and all hop by hop LSPs will use case 1", or signalling needs to give us a hint of which to use. --------------- Eyad: Ah, I'm sorry; I just assumed this would be applicable on the network as a whole rather than on a per-LSP basis. In this case, you are correct: signaling must convey this information. --------------- > CASE 1: Copy TTL to/from IP header > CASE 2: Push new TTL at ingress, discard at egress. > > Case 2 is certainly useful when the network wishes to carry non-IP traffic > (or something that has not been specified yet). Agreed. So in that case the the signalling protocol will probably give us the "hint" we need to make the decision. This needs to be explicitly stated in the spec though so diffent vendors at ingress and egress behave accordingly. Jim -- James R. Leu ------_=_NextPart_001_01C05E0B.375CBE50 Content-Type: text/html; charset="iso-8859-1" RE: Processing the MPLS TTL

see below...

-----Original Message-----
From: James R. Leu [mailto:jleu@mindspring.com]
Sent: Monday, December 04, 2000 10:49 AM
To: Eyad Saheb
Cc: 'jleu@mindspring.com'
Subject: Re: Processing the MPLS TTL


Hello,

On Mon, Dec 04, 2000 at 10:32:03AM -0500, Eyad Saheb wrote:
> I believe there is a simple answer to this: configuration.  Whether the
> network admin wishes to decrement IP TTL throughout the network, or to make
> the network appear as one logical hop, it should simply be a matter of
> configuring the LER's (ingress or egress, they're the same box).

Not for a particular LSP.  The LSP setup was requested by ingress,
the ingress also decided between case 1 or 2 when forwarding traffic.  How
does the egress know which case?  Manual configuration isn't acceptable
because the admin may not even know that this LSP was ever going to be
terminated at this node (although that is unlikely, it just proves the point).

Either we need to make a decisive statement such as "All TE LSPs will use
case 2 and all hop by hop LSPs will use case 1", or signalling needs to
give us a hint of which to use.

---------------
Eyad:
Ah, I'm sorry; I just assumed this would be applicable on the
network as a whole rather than on a per-LSP basis.  In this
case, you are correct: signaling must convey this information.
---------------

> CASE 1: Copy TTL to/from IP header
> CASE 2: Push new TTL at ingress, discard at egress.
>
> Case 2 is certainly useful when the network wishes to carry non-IP traffic
> (or something that has not been specified yet).

Agreed.  So in that case the the signalling protocol will probably give us
the "hint" we need to make the decision.  This needs to be explicitly
stated in the spec though so diffent vendors at ingress and egress behave
accordingly.

Jim
--
James R. Leu

------_=_NextPart_001_01C05E0B.375CBE50-- From owner-mpls@UU.NET Mon Dec 4 11:15:39 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05887 for ; Mon, 4 Dec 2000 11:15:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdc12384; Mon, 4 Dec 2000 16:14:18 GMT Received: by mail-control.mail.uu.net id QQjsdc15790 for mpls-outgoing; Mon, 4 Dec 2000 16:13:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsdc15776 for ; Mon, 4 Dec 2000 16:13:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsdc12275 for ; Mon, 4 Dec 2000 16:12:07 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjsdc18047 for ; Mon, 4 Dec 2000 16:12:07 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07870; Mon, 4 Dec 2000 11:12:03 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA22208; Mon, 4 Dec 2000 11:12:02 -0500 (EST) Message-ID: <3A2BC25D.AC56B67F@marconi.com> Date: Mon, 04 Dec 2000 11:12:13 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: Gaitonde Anandprasanna CC: mpls@UU.NET Subject: Re: Query about handling Non RSVP neighbours in RSVP-TE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gaitonde Anandprasanna wrote: > > I am eager to know the following as it was not clear to me from the > draft. > > This is one of the paragrph from the draft 07.txt > > 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." This same message SHOULD be sent, if a router > receives a LABEL_REQUEST object in a message from a non-RSVP > capable router. See [1] for a description of how a downstream > router can determine the presence of non-RSVP routers. What's not clear here? Non-RSVP routers are illegal in an RSVP-TE cloud. If a Path message should passthrough one, path setup is aborted and a PathErr is sent. > Does it mean that if we find a non RSVP hop in between we should stop > propogating Path mesages forward or does it mean that when we forward > the path message it should not contain Label Request Object. It means you do not propagate the message. You generate a PathErr message. Hopefully, the ingress router will then choose an alternate route that avoids the non-RSVP router. The deal about LABEL_REQUEST is not intended as a part of label distribution. It is intended so that non-TE RSVP may continue to operate through the non-RSVP router (which is specified as part of RFC 2205). -- David From owner-mpls@UU.NET Mon Dec 4 11:23:02 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08103 for ; Mon, 4 Dec 2000 11:23:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdd03356; Mon, 4 Dec 2000 16:21:42 GMT Received: by mail-control.mail.uu.net id QQjsdd16982 for mpls-outgoing; Mon, 4 Dec 2000 16:20:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsdd16967 for ; Mon, 4 Dec 2000 16:20:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsdd18700 for ; Mon, 4 Dec 2000 16:20:00 GMT Received: from megapathdsl.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.megapath.net [216.200.176.4]) id QQjsdd21614 for ; Mon, 4 Dec 2000 16:19:59 GMT Received: from [208.202.21.22] (HELO kensington) by megapathdsl.net (CommuniGate Pro SMTP 3.3.2) with SMTP id 8737960; Mon, 04 Dec 2000 08:20:25 -0800 From: "Robert Schellhase" To: "Markus Jork" Cc: Subject: RE: MPLS for UDLR Date: Mon, 4 Dec 2000 11:19:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200012041540.eB4Fehq08867@mailhost.avici.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Markus, Thanks for clearing this up. Has anyone at Avici thought of using MPLS for UDLR? Robert -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Markus Jork Sent: Monday, December 04, 2000 10:41 AM To: Eyad Saheb Cc: 'Robert Schellhase'; 'Alexander.Marhold@xandl.cso.net'; 'Nhat Thanh Hoang'; 'eduard metz'; 'mpls@UU.NET' Subject: Re: MPLS for UDLR Just to clear up some confusion in this e-mail exchange. RSVP does not have a problem with unidirectional links. A Path message can be sent out on one interface and the corresponding Resv message can come back in through any other interface. So when there is a unidirectional link from A to B, the only requirement is that B somehow has to be able to send back a Resv message to A (through some other interface or possibly via multiple other intermediate nodes). There is no need for a bi-directional link. Markus > Have you considered CR/LDP ? Ofcourse, there's the TCP overhead (is TCP > affected by UDL?), but I don't believe CR/LDP has the bi-directional link > limitation that RSVP does. However, CR/LDP doesn't have the refreshs; the > overhead is only incurred on LSP setup & neighor discovery. > > For further study, I guess. > > Eyad > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Robert > Schellhase > Sent: Thursday, November 30, 2000 9:58 AM > To: Alexander.Marhold@xandl.cso.net; Nhat Thanh Hoang; eduard metz > Cc: mpls@UU.NET > Subject: RE: MPLS for UDLR > > > Thanks for the RSVP insights. They improve my overall understanding of > what's happening. > > UDLR is supposed to fix the problem of receiving on one interface while > sending on another, by combining the two physical paths into a single > logical interface. So it sounds like we are saying that since MPLS uses RSVP > to build its tunnels, but RSVP needs bi-directional interfaces to get its > job done, and therein lies the problem. > > Am I reading this correctly? Does anyone else have thoughts, or a possible > workaround idea? > > Best regards, > Robert > > -----Original Message----- > From: Alexander Marhold [mailto:Alexander.Marhold@proin.com] > Sent: Thursday, November 30, 2000 2:07 AM > To: Nhat Thanh Hoang; Alexander.Marhold@xandl.cso.net; eduard metz; > rschell@megapathdsl.net > Subject: RE: MPLS for UDLR > > > > As I know RSVP for traffic engineering that uses in MPLS context is > > unidirectional, which means you need to configure at least two > > constraint-based LSPs (ingress--->egress and ingress<---egress), > > if you want > > a bidirectional path. > > > >> LSP is unidirectional, but RSVP is not, > >> > > Sorry for not being clear enough: > Of course you are right the tunnel which is set up by RSVP is > unidirectional (this is what we tell RSVP when starting the RESV message). > > What I wanted to express is: > That the messages itself, RSVP is sending forward (RESV) and backwards > (PATH) to set up the path are assumed to go over the same links in forward > and reverse direction. In the UDLR case those links forward and reverse are > different. > > And I think that exactly that is the problem in the UDLR case. > > with best regards > Alexander > > > > > > > RE: MPLS for UDLR > > > >

Have you considered CR/LDP ?  Ofcourse, there's the TCP overhead (is TCP affected by UDL?), but I don't believe CR/LDP has the bi-directional link limitation that RSVP  does.  However, CR/LDP doesn't have the refreshs; the overhead is only incurred on LSP setup & neighor discovery.

> >

For further study, I guess. >

> >

Eyad >

> >

-----Original Message----- >
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Robert >
Schellhase >
Sent: Thursday, November 30, 2000 9:58 AM >
To: Alexander.Marhold@xandl.cso.net; Nhat Thanh Hoang; eduard metz >
Cc: mpls@UU.NET >
Subject: RE: MPLS for UDLR >

>
> >

Thanks for the RSVP insights. They improve my overall understanding of >
what's happening. >

> >

UDLR is supposed to fix the problem of receiving on one interface while >
sending on another, by combining the two physical paths into a single >
logical interface. So it sounds like we are saying that since MPLS uses RSVP >
to build its tunnels, but RSVP needs bi-directional interfaces to get its >
job done, and therein lies the problem. >

> >

Am I reading this correctly? Does anyone else have thoughts, or a possible >
workaround idea? >

> >

Best regards, >
Robert >

> >

-----Original Message----- >
From: Alexander Marhold [mailto:Alexander.Marhold@proin.com ] >
Sent: Thursday, November 30, 2000 2:07 AM >
To: Nhat Thanh Hoang; Alexander.Marhold@xandl.cso.net; eduard metz; >
rschell@megapathdsl.net >
Subject: RE: MPLS for UDLR >

>
> >

> As I know RSVP for traffic engineering that uses in MPLS context is >
> unidirectional, which means you need to configure at least two >
> constraint-based LSPs (ingress--->egress and ingress<---egress), >
> if you want >
> a bidirectional path. >
> >
>> LSP is unidirectional, but RSVP is not, >
>> >

> >

Sorry for not being clear enough: >
Of course you are right  the tunnel which is set up by RSVP is >
unidirectional (this is what we tell RSVP when starting the RESV message). >

> >

What I wanted to express is: >
That the messages itself, RSVP is sending forward (RESV) and backwards >
(PATH) to set up the path are assumed to go over the same links in forward >
and reverse direction. In the UDLR case those links forward and reverse are >
different. >

> >

And I think that exactly that is the problem in the UDLR case. >

> >

with best regards >
Alexander >

> > > > From owner-mpls@UU.NET Mon Dec 4 11:25:32 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08820 for ; Mon, 4 Dec 2000 11:25:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdd07774; Mon, 4 Dec 2000 16:24:12 GMT Received: by mail-control.mail.uu.net id QQjsdd17274 for mpls-outgoing; Mon, 4 Dec 2000 16:23:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsdd17213 for ; Mon, 4 Dec 2000 16:23:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsdd22600 for ; Mon, 4 Dec 2000 16:21:26 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjsdd00658 for ; Mon, 4 Dec 2000 16:21:11 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 LAA09142 for ; Mon, 4 Dec 2000 11:21:09 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26573 for ; Mon, 4 Dec 2000 11:21:08 -0500 (EST) Message-ID: <3A2BC47F.9067A992@marconi.com> Date: Mon, 04 Dec 2000 11:21:19 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: (Reply) Query about handling Non RSVP neighbours in RSVP-TE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit venkir@samsung.co.kr wrote: > > You r correct only, i.e., the first option is corect. > Actually, in that paragraph, they explained about two scenarios. First > one is about non-rsvp node as downstream router. In that case, > upstream router has to send patherr. It's fine. Second one dealing > with the case, where non-rsvp node as upstream router. That means if a > rsvp node, gets a path message with LABEL_REQUEST from a non-rsvp > node, it has to send a patherr message. Here message is from a > non-rsvp node. Am I right? > But only thing is, how come, a non-rsvp node sends a path > message with LABEL_REQUEST to rsvp node? I don't think, this case will > arise in real time scenario. The non-RSVP node won't generate such a message - it's not running RSVP! But it will forward such a message if it receives it. The PHOP node doesn't necessarily know that there's a non-RSVP router between it and the next hop. It may generate a Path message with LABEL_REQUEST, not knowing that there's a non-RSVP router present on that link. The non-RSVP router then forwards the message. The NHOP RSVP router that receives the message detects the non-RSVP router (by comparing TTL values), sees that there's a LABEL_REQUEST object (indicating that this is an RSVP-TE Path message and not a non-TE message), and proceeds to drop the message and generate a PathErr. -- David From owner-mpls@UU.NET Mon Dec 4 12:05:34 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25229 for ; Mon, 4 Dec 2000 12:05:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdg28846; Mon, 4 Dec 2000 17:04:15 GMT Received: by mail-control.mail.uu.net id QQjsdg28797 for mpls-outgoing; Mon, 4 Dec 2000 17:03:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsdg28599 for ; Mon, 4 Dec 2000 17:03:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsdg29085 for ; Mon, 4 Dec 2000 17:03:09 GMT Received: from alemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alemail1.lucent.com [192.11.221.161]) id QQjsdg00081 for ; Mon, 4 Dec 2000 17:03:09 GMT Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA14321 for ; Mon, 4 Dec 2000 12:03:09 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA14312; Mon, 4 Dec 2000 12:03:08 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA27645; Mon, 4 Dec 2000 12:03:07 -0500 (EST) Message-ID: <3A2BCE4B.1BE33B41@lucent.com> Date: Mon, 04 Dec 2000 12:03:07 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Markus Jork CC: "'mpls@UU.NET'" Subject: Re: MPLS for UDLR References: <200012041540.eB4Fehq08867@mailhost.avici.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Markus, I am confused. LSPs are uni-directional, it doesn't mean data links are uni-directional. My understanding is that data links are always bi-directional. In another word, logical physical interfaces to forwarding engine are bi-directional. OSPF only treats bi-directional links as working links. Even RSVP doesn't explicitly assume the bi-directional data link. It seems to me that's the default Can you give me an example of uni-directional data link in packet network? Yangguang Markus Jork wrote: > > Just to clear up some confusion in this e-mail exchange. > RSVP does not have a problem with unidirectional links. > A Path message can be sent out on one interface and the > corresponding Resv message can come back in through any > other interface. > So when there is a unidirectional link from A to B, the only > requirement is that B somehow has to be able to send back a Resv > message to A (through some other interface or possibly via multiple > other intermediate nodes). There is no need for a bi-directional link. > > Markus > > > Have you considered CR/LDP ? Ofcourse, there's the TCP overhead (is TCP > > affected by UDL?), but I don't believe CR/LDP has the bi-directional link > > limitation that RSVP does. However, CR/LDP doesn't have the refreshs; the > > overhead is only incurred on LSP setup & neighor discovery. > > > > For further study, I guess. > > > > Eyad > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Robert > > Schellhase > > Sent: Thursday, November 30, 2000 9:58 AM > > To: Alexander.Marhold@xandl.cso.net; Nhat Thanh Hoang; eduard metz > > Cc: mpls@UU.NET > > Subject: RE: MPLS for UDLR > > > > > > Thanks for the RSVP insights. They improve my overall understanding of > > what's happening. > > > > UDLR is supposed to fix the problem of receiving on one interface while > > sending on another, by combining the two physical paths into a single > > logical interface. So it sounds like we are saying that since MPLS uses RSVP > > to build its tunnels, but RSVP needs bi-directional interfaces to get its > > job done, and therein lies the problem. > > > > Am I reading this correctly? Does anyone else have thoughts, or a possible > > workaround idea? > > > > Best regards, > > Robert > > > > -----Original Message----- > > From: Alexander Marhold [mailto:Alexander.Marhold@proin.com] > > Sent: Thursday, November 30, 2000 2:07 AM > > To: Nhat Thanh Hoang; Alexander.Marhold@xandl.cso.net; eduard metz; > > rschell@megapathdsl.net > > Subject: RE: MPLS for UDLR > > > > > > > As I know RSVP for traffic engineering that uses in MPLS context is > > > unidirectional, which means you need to configure at least two > > > constraint-based LSPs (ingress--->egress and ingress<---egress), > > > if you want > > > a bidirectional path. > > > > > >> LSP is unidirectional, but RSVP is not, > > >> > > > > Sorry for not being clear enough: > > Of course you are right the tunnel which is set up by RSVP is > > unidirectional (this is what we tell RSVP when starting the RESV message). > > > > What I wanted to express is: > > That the messages itself, RSVP is sending forward (RESV) and backwards > > (PATH) to set up the path are assumed to go over the same links in forward > > and reverse direction. In the UDLR case those links forward and reverse are > > different. > > > > And I think that exactly that is the problem in the UDLR case. > > > > with best regards > > Alexander > > > > > > > > > > > > > > RE: MPLS for UDLR > > > > > > > >

Have you considered CR/LDP ?  Ofcourse, there's the TCP overhead (is TCP affected by UDL?), but I don't believe CR/LDP has the bi-directional link limitation that RSVP  does.  However, CR/LDP doesn't have the refreshs; the overhead is only incurred on LSP setup & neighor discovery.

> > > >

For further study, I guess. > >

> > > >

Eyad > >

> > > >

-----Original Message----- > >
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Robert > >
Schellhase > >
Sent: Thursday, November 30, 2000 9:58 AM > >
To: Alexander.Marhold@xandl.cso.net; Nhat Thanh Hoang; eduard metz > >
Cc: mpls@UU.NET > >
Subject: RE: MPLS for UDLR > >

> >
> > > >

Thanks for the RSVP insights. They improve my overall understanding of > >
what's happening. > >

> > > >

UDLR is supposed to fix the problem of receiving on one interface while > >
sending on another, by combining the two physical paths into a single > >
logical interface. So it sounds like we are saying that since MPLS uses RSVP > >
to build its tunnels, but RSVP needs bi-directional interfaces to get its > >
job done, and therein lies the problem. > >

> > > >

Am I reading this correctly? Does anyone else have thoughts, or a possible > >
workaround idea? > >

> > > >

Best regards, > >
Robert > >

> > > >

-----Original Message----- > >
From: Alexander Marhold [mailto:Alexander.Marhold@proin.com] > >
Sent: Thursday, November 30, 2000 2:07 AM > >
To: Nhat Thanh Hoang; Alexander.Marhold@xandl.cso.net; eduard metz; > >
rschell@megapathdsl.net > >
Subject: RE: MPLS for UDLR > >

> >
> > > >

> As I know RSVP for traffic engineering that uses in MPLS context is > >
> unidirectional, which means you need to configure at least two > >
> constraint-based LSPs (ingress--->egress and ingress<---egress), > >
> if you want > >
> a bidirectional path. > >
> > >
>> LSP is unidirectional, but RSVP is not, > >
>> > >

> > > >

Sorry for not being clear enough: > >
Of course you are right  the tunnel which is set up by RSVP is > >
unidirectional (this is what we tell RSVP when starting the RESV message). > >

> > > >

What I wanted to express is: > >
That the messages itself, RSVP is sending forward (RESV) and backwards > >
(PATH) to set up the path are assumed to go over the same links in forward > >
and reverse direction. In the UDLR case those links forward and reverse are > >
different. > >

> > > >

And I think that exactly that is the problem in the UDLR case. > >

> > > >

with best regards > >
Alexander > >

> > > > > > > > From owner-mpls@UU.NET Mon Dec 4 12:13:58 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28552 for ; Mon, 4 Dec 2000 12:13:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdg12939; Mon, 4 Dec 2000 17:12:40 GMT Received: by mail-control.mail.uu.net id QQjsdg04984 for mpls-outgoing; Mon, 4 Dec 2000 17:11:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsdg04956 for ; Mon, 4 Dec 2000 17:11:50 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsdg17722 for ; Mon, 4 Dec 2000 17:11:42 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjsdg12226 for ; Mon, 4 Dec 2000 17:11:41 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 JAA08699; Mon, 4 Dec 2000 09:11:38 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.7/8.7.3) id JAA20650; Mon, 4 Dec 2000 09:11:37 -0800 (PST) Date: Mon, 4 Dec 2000 09:11:37 -0800 (PST) From: Kireeti Kompella Message-Id: <200012041711.JAA20650@kummer.juniper.net> To: swallow@cisco.com, vkompella@JasmineNetworks.com Subject: Re: What's in or out? Cc: mpls@UU.NET Sender: owner-mpls@UU.NET Precedence: bulk Hi George, > > Generalized MPLS - Signaling Functional Description (94621 bytes) > > Generalized MPLS Signaling - CR-LDP Extensions (29232 bytes) > > Generalized MPLS Signaling - RSVP-TE Extensions (43771 bytes) > > I wish. I believe the above three are bound to go into COMA. You know, this new WG has an unfortunate name. We really need these (and related) items to move forward sprightly, not look for life support. While one could argue that GMPLS constitutes a new control plane, and hence needs a new WG, where will "hardcore" MPLS drafts -- MPLS protection/restoration, LSP hierarchy, LDP FT, MPLS & DiffServ, MPLS signalling over unnumbered links etc, go? Kireeti. From owner-mpls@UU.NET Mon Dec 4 12:44:31 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09839 for ; Mon, 4 Dec 2000 12:44:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdi03801; Mon, 4 Dec 2000 17:43:10 GMT Received: by mail-control.mail.uu.net id QQjsdi08473 for mpls-outgoing; Mon, 4 Dec 2000 17:42:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsdi08454 for ; Mon, 4 Dec 2000 17:42:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsdi24814 for ; Mon, 4 Dec 2000 17:41:40 GMT Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQjsdi23736 for ; Mon, 4 Dec 2000 17:41:39 GMT Received: from avici.com (swdev23.avici.com [10.1.2.229]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id eB4Hfcq24582; Mon, 4 Dec 2000 12:41:38 -0500 (EST) Message-Id: <200012041741.eB4Hfcq24582@mailhost.avici.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Markus Jork To: Yangguang Xu cc: "'mpls@UU.NET'" Subject: Re: MPLS for UDLR In-reply-to: Your message of "Mon, 04 Dec 2000 12:03:07 EST." <3A2BCE4B.1BE33B41@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Dec 2000 12:41:36 -0500 Sender: owner-mpls@UU.NET Precedence: bulk Yangguang, I didn't say that uni-directional links are currently in use in packet networks. I'm not familiar with the UDLR work at all but obviously it is an attempt to make use of uni-directional links. So my point was that RSVP's design permits its use over uni-directional links if someone wants to do that. Markus > Markus, > > I am confused. LSPs are uni-directional, it doesn't mean data links are > uni-directional. My understanding is that data links are always bi-directional. > In another word, logical physical interfaces to forwarding engine are > bi-directional. OSPF only treats bi-directional links as working links. Even > RSVP doesn't explicitly assume the bi-directional data link. It seems to me > that's the default > > Can you give me an example of uni-directional data link in packet network? > > Yangguang > > Markus Jork wrote: > > > > Just to clear up some confusion in this e-mail exchange. > > RSVP does not have a problem with unidirectional links. > > A Path message can be sent out on one interface and the > > corresponding Resv message can come back in through any > > other interface. > > So when there is a unidirectional link from A to B, the only > > requirement is that B somehow has to be able to send back a Resv > > message to A (through some other interface or possibly via multiple > > other intermediate nodes). There is no need for a bi-directional link. > > > > Markus > > From owner-mpls@UU.NET Mon Dec 4 13:39:13 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23248 for ; Mon, 4 Dec 2000 13:39:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdm25866; Mon, 4 Dec 2000 18:37:53 GMT Received: by mail-control.mail.uu.net id QQjsdm26259 for mpls-outgoing; Mon, 4 Dec 2000 18:37:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsdm26252 for ; Mon, 4 Dec 2000 18:37:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsdm12465 for ; Mon, 4 Dec 2000 18:36:46 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjsdm11666 for ; Mon, 4 Dec 2000 18:36:45 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA13112 for mpls@uu.net; Mon, 4 Dec 2000 13:36:44 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsdm26153 for ; Mon, 4 Dec 2000 18:36:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsdm09009 for ; Mon, 4 Dec 2000 18:35:49 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjsdm02466 for ; Mon, 4 Dec 2000 18:35:49 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 NAA03314; Mon, 4 Dec 2000 13:35:48 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id NAA21537; Mon, 4 Dec 2000 13:35:47 -0500 (EST) Message-Id: <200012041835.NAA21537@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Kireeti Kompella cc: swallow@cisco.com, vkompella@JasmineNetworks.com, mpls@UU.NET, swallow@cisco.com Subject: Re: What's in or out? In-reply-to: Your message of "Mon, 04 Dec 2000 09:11:37 PST." <200012041711.JAA20650@kummer.juniper.net> Date: Mon, 04 Dec 2000 13:35:47 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Kireeti - > You know, this new WG has an unfortunate name. We really need > these (and related) items to move forward sprightly, not look for > life support. I believe the name is well chosen. I think there are a number of parties that are interested in seeing the work slowed down. > While one could argue that GMPLS constitutes a new control plane, > and hence needs a new WG, where will "hardcore" MPLS drafts -- MPLS > protection/restoration, LSP hierarchy, LDP FT, MPLS & DiffServ, MPLS > signalling over unnumbered links etc, go? It's not clear at all to me at this point. From what little I'm hearing from the AD's a few things like LDP FT will stay in MPLS. Most of the rest they want to pull into COMA until they 'sort things out'. >>>George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Mon Dec 4 14:03:34 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00159 for ; Mon, 4 Dec 2000 14:03:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdo01457; Mon, 4 Dec 2000 19:02:13 GMT Received: by mail-control.mail.uu.net id QQjsdo03400 for mpls-outgoing; Mon, 4 Dec 2000 19:01:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsdo02637 for ; Mon, 4 Dec 2000 19:01:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsdo28558 for ; Mon, 4 Dec 2000 19:00:57 GMT Received: from sutton.acbm.qc.ca by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [207.96.170.5]) id QQjsdo16071 for ; Mon, 4 Dec 2000 19:00:56 GMT Received: from hermes.hyperchip.com ([207.164.218.2]) by sutton.acbm.qc.ca (Post.Office MTA v3.5.2 release 221 ID# 0-69929U800L2S100V35) with ESMTP id ca; Mon, 4 Dec 2000 13:57:25 -0500 Received: by HERMES with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 14:00:40 -0500 Message-ID: From: Eyad Saheb To: "'Markus Jork'" Cc: "'mpls@uu.net'" Subject: RE: MPLS for UDLR Date: Mon, 4 Dec 2000 14:00:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05E24.7E4DB7B0" 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_01C05E24.7E4DB7B0 Content-Type: text/plain; charset="iso-8859-1" My impression is that although there is no restrictions on which interfaces the PATH & RESV messages traverse, they will not accomplish anything if they don't follow the same hops. Thus, if A is connected to B via a uni-directional link, RSVP messages may use another uni-directional link to 'complete the loop'. However, the links must be between A & B, any intermediate hops will interfere: if they support RSVP, they would only have received one of the PATH/RESV messages, or if they don't support RSVP they won't be allowed in the LSP. Isn't this the case ? Eyad -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Markus Jork Sent: Monday, December 04, 2000 12:42 PM To: Yangguang Xu Cc: 'mpls@UU.NET' Subject: Re: MPLS for UDLR Yangguang, I didn't say that uni-directional links are currently in use in packet networks. I'm not familiar with the UDLR work at all but obviously it is an attempt to make use of uni-directional links. So my point was that RSVP's design permits its use over uni-directional links if someone wants to do that. Markus > Markus, > > I am confused. LSPs are uni-directional, it doesn't mean data links are > uni-directional. My understanding is that data links are always bi-directional. > In another word, logical physical interfaces to forwarding engine are > bi-directional. OSPF only treats bi-directional links as working links. Even > RSVP doesn't explicitly assume the bi-directional data link. It seems to me > that's the default > > Can you give me an example of uni-directional data link in packet network? > > Yangguang > > Markus Jork wrote: > > > > Just to clear up some confusion in this e-mail exchange. > > RSVP does not have a problem with unidirectional links. > > A Path message can be sent out on one interface and the > > corresponding Resv message can come back in through any > > other interface. > > So when there is a unidirectional link from A to B, the only > > requirement is that B somehow has to be able to send back a Resv > > message to A (through some other interface or possibly via multiple > > other intermediate nodes). There is no need for a bi-directional link. > > > > Markus > > ------_=_NextPart_001_01C05E24.7E4DB7B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS for UDLR

My impression is that although there is no = restrictions on which interfaces the PATH & RESV messages traverse, = they will not accomplish anything if they don't follow the same = hops.  Thus, if A is connected to B via a uni-directional link, = RSVP messages may use another uni-directional link to 'complete the = loop'.  However, the links must be between A & B, any = intermediate hops will interfere: if they support RSVP, they would only = have received one of the PATH/RESV messages, or if they don't support = RSVP they won't be allowed in the LSP.

Isn't this the case ?

Eyad

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of Markus
Jork
Sent: Monday, December 04, 2000 12:42 PM
To: Yangguang Xu
Cc: 'mpls@UU.NET'
Subject: Re: MPLS for UDLR


Yangguang,

I didn't say that uni-directional links are currently = in use
in packet networks. I'm not familiar with the UDLR = work at all but
obviously it is an attempt to make use of = uni-directional links.
So my point was that RSVP's design permits its use = over uni-directional
links if someone wants to do that.

Markus

> Markus,
>
> I am confused. LSPs are uni-directional, it = doesn't mean data links are
> uni-directional. My understanding is that data = links are always bi-directional.
> In another word, logical physical interfaces to = forwarding engine are
> bi-directional. OSPF only treats bi-directional = links as working links. Even
> RSVP doesn't explicitly assume the = bi-directional data link. It seems to me
> that's the default
>
> Can you give me an example of uni-directional = data link in packet network?
>
> Yangguang
>
> Markus Jork wrote:
> >
> > Just to clear up some confusion in this = e-mail exchange.
> > RSVP does not have a problem with = unidirectional links.
> > A Path message can be sent out on one = interface and the
> > corresponding Resv message can come back = in through any
> > other interface.
> > So when there is a unidirectional link = from A to B, the only
> > requirement is that B somehow has to be = able to send back a Resv
> > message to A (through some other interface = or possibly via multiple
> > other intermediate nodes). There is no = need for a bi-directional link.
> >
> > Markus
> >

------_=_NextPart_001_01C05E24.7E4DB7B0-- From owner-mpls@UU.NET Mon Dec 4 14:08:14 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01579 for ; Mon, 4 Dec 2000 14:08:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdo09612; Mon, 4 Dec 2000 19:06:53 GMT Received: by mail-control.mail.uu.net id QQjsdo10850 for mpls-outgoing; Mon, 4 Dec 2000 19:06:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsdo10764 for ; Mon, 4 Dec 2000 19:06:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsdo12796 for ; Mon, 4 Dec 2000 19:05:23 GMT Received: from mail.hamdard.net.pk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.135.57.5]) id QQjsdo22089 for ; Mon, 4 Dec 2000 19:05:21 GMT Received: from faisal-s ([203.135.57.160]) by mail.hamdard.net.pk (8.9.3/8.9.3) with SMTP id AAA07766; Tue, 5 Dec 2000 00:03:23 +0500 Message-ID: <004c01c05e25$8f5cd300$a03987cb@faisal-s> From: "Faisal S. Naik" To: "mpls uunet" Cc: Subject: Re: MPLS and fragmentation.. Date: Tue, 5 Dec 2000 00:08:15 +0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hello soumen, Isnt this Ip fragmentation a part of the router before the packet enters the MPLS domain. Within the domain, there is only the label swapping mechanism that is working, with nothing to mention about the fragmentation part. Esp in cases of IPv6 fragmentation is not at all allowed, for exceptional cases, extended headers of IPv6 are used. Am i right Nisar saheb :) Regards, Faisal Naik > > > From owner-mpls@UU.NET Mon Dec 4 14:08:17 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01604 for ; Mon, 4 Dec 2000 14:08:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdo24521; Mon, 4 Dec 2000 19:06:56 GMT Received: by mail-control.mail.uu.net id QQjsdo10858 for mpls-outgoing; Mon, 4 Dec 2000 19:06:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsdo10810 for ; Mon, 4 Dec 2000 19:06:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsdo11748 for ; Mon, 4 Dec 2000 19:05:10 GMT Received: from exchsrv1.cosinecom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cosinecom.com [63.88.104.16]) id QQjsdo20216 for ; Mon, 4 Dec 2000 19:05:10 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 11:03:26 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A2911D8AB01@exchsrv1.cosinecom.com> From: Jay Wang To: "'Jim Boyle'" , wesam.alanqar@mail.sprint.com Cc: mastropietro@coritel.it, mpls@UU.NET Subject: RE: E-LSP or L-LSP Date: Mon, 4 Dec 2000 11:03:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05E24.D9F3C8C0" 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_01C05E24.D9F3C8C0 Content-Type: text/plain; charset="ISO-8859-1" > -----Original Message----- > From: Jim Boyle [mailto:jboyle@Level3.net] > Sent: Monday, December 04, 2000 7:39 AM > To: wesam.alanqar@mail.sprint.com > Cc: mastropietro@coritel.it; mpls@UU.NET > Subject: RE: E-LSP or L-LSP > > > On Wed, 22 Nov 2000 wesam.alanqar@mail.sprint.com wrote: > > > Hi > > > > E-LSP is used when DSCP DiffServ field is mapped to the EXP > field in the > > MPLS header. > > L-LSP is used when DSCP DiffServ field is mapped to the > EXP+LABEL fields > > in the MPLS header. > > actually, I don't think L-LSPs look at EXP, just the label. > In L-LSP, the label along can be used to infer the corresponding PSC. However, the EXP bits may be used to keep drop precedence when the Shim header is used. Otherwise, the drop precedence may need to be inferred from the native L2 header. - Jay ------_=_NextPart_001_01C05E24.D9F3C8C0 Content-Type: text/html; charset="ISO-8859-1" RE: E-LSP or L-LSP

> -----Original Message-----
> From: Jim Boyle [mailto:jboyle@Level3.net]
> Sent: Monday, December 04, 2000 7:39 AM
> To: wesam.alanqar@mail.sprint.com
> Cc: mastropietro@coritel.it; mpls@UU.NET
> Subject: RE: E-LSP or L-LSP
>
>
> On Wed, 22 Nov 2000 wesam.alanqar@mail.sprint.com wrote:
>
> > Hi
> >
> > E-LSP is used when DSCP DiffServ field is mapped to the EXP
> field in the
> > MPLS header.
> > L-LSP is used when DSCP DiffServ field is mapped to the
> EXP+LABEL fields
> > in the MPLS header.
>
> actually, I don't think L-LSPs look at EXP, just the label.
>

In L-LSP, the label along can be used to infer the corresponding
PSC.  However, the EXP bits may be used to keep drop precedence when
the Shim header is used. Otherwise, the drop precedence may need to
be inferred from the native L2 header.


- Jay

------_=_NextPart_001_01C05E24.D9F3C8C0-- From owner-mpls@UU.NET Mon Dec 4 14:11:38 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02718 for ; Mon, 4 Dec 2000 14:11:37 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdo16088; Mon, 4 Dec 2000 19:10:17 GMT Received: by mail-control.mail.uu.net id QQjsdo11303 for mpls-outgoing; Mon, 4 Dec 2000 19:09:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsdo11289 for ; Mon, 4 Dec 2000 19:09:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsdo25350 for ; Mon, 4 Dec 2000 19:09:18 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f201.law11.hotmail.com [64.4.17.201]) id QQjsdo28339 for ; Mon, 4 Dec 2000 19:09:16 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 4 Dec 2000 11:09:15 -0800 Received: from 212.29.252.146 by lw11fd.law11.hotmail.msn.com with HTTP; Mon, 04 Dec 2000 19:09:15 GMT X-Originating-IP: [212.29.252.146] From: "milos milos" To: mpls@UU.NET Subject: MPLS VPN SLAs Date: Mon, 04 Dec 2000 19:09:15 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Dec 2000 19:09:15.0593 (UTC) FILETIME=[B1C93B90:01C05E25] Sender: owner-mpls@UU.NET Precedence: bulk What kind of SLAs are provided to MPLS VPN customer? If there's a VPN with three sites - A,B, C- do you get specific SLA for bandwidth and latency for each link (A-B, A-C, B-C) or do you get a SLA "into the cloud" (e.g. A is allowed 128K outgoing and 64K incoming, B is allowed 256K outgoing and 192K incoming, etc..) and so long you don't send more than allowed it's guaranteed? -Milos _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From owner-mpls@UU.NET Mon Dec 4 14:21:44 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05774 for ; Mon, 4 Dec 2000 14:21:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdp13027; Mon, 4 Dec 2000 19:20:23 GMT Received: by mail-control.mail.uu.net id QQjsdp13134 for mpls-outgoing; Mon, 4 Dec 2000 19:19:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsdp13100 for ; Mon, 4 Dec 2000 19:19:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsdp24574 for ; Mon, 4 Dec 2000 19:19:01 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjsdp01076 for ; Mon, 4 Dec 2000 19:19:00 GMT Received: from murphy-bsd.juniper.net (murphy-bsd.juniper.net [172.17.12.128]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA18122 for ; Mon, 4 Dec 2000 11:19:00 -0800 (PST) Received: from juniper.net (localhost [127.0.0.1]) by murphy-bsd.juniper.net (8.8.8/8.7.3) with ESMTP id LAA27089 for ; Mon, 4 Dec 2000 11:17:42 -0800 (PST) Message-ID: <3A2BEDD6.B9EDAA6A@juniper.net> Date: Mon, 04 Dec 2000 11:17:42 -0800 From: Jim Murphy Organization: Juniper Networks X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 2.2.8-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: L-LSP discard priority bits in draft-ietf-mpls-diff-ext-07.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In the following table, 4.2.1.1 Mandatory EXP/PSC --> PHB mapping EXP Field PSC PHB 000 DF ----> DF 000 CSn ----> CSn 000 AFn ----> AFn1 001 AFn ----> AFn2 010 AFn ----> AFn3 000 EF ----> EF should the EXP field corresponding to PHB AFn3 be modified to 011? This will allow bit 3 of the EXP field to always indicate discard preference. This simplifies implementations that only support a binary discard preference. Thanks, Jim From owner-mpls@UU.NET Mon Dec 4 14:37:19 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09124 for ; Mon, 4 Dec 2000 14:37:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdq05594; Mon, 4 Dec 2000 19:35:59 GMT Received: by mail-control.mail.uu.net id QQjsdq15044 for mpls-outgoing; Mon, 4 Dec 2000 19:35:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsdq15032 for ; Mon, 4 Dec 2000 19:35:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsdq13464 for ; Mon, 4 Dec 2000 19:34:50 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjsdq03843 for ; Mon, 4 Dec 2000 19:34:49 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 LAA06042 for ; Mon, 4 Dec 2000 11:34:54 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA00624 for mpls@uu.net; Mon, 4 Dec 2000 14:34:47 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsdn28357 for ; Mon, 4 Dec 2000 18:56:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsdn12032 for ; Mon, 4 Dec 2000 18:55:45 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f156.law11.hotmail.com [64.4.17.156]) id QQjsdn05693 for ; Mon, 4 Dec 2000 18:55:44 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 4 Dec 2000 10:55:43 -0800 Received: from 212.29.252.146 by lw11fd.law11.hotmail.msn.com with HTTP; Mon, 04 Dec 2000 18:55:43 GMT X-Originating-IP: [212.29.252.146] From: "milos milos" To: mpls@UU.NET Subject: MPLS VPN SLAs Date: Mon, 04 Dec 2000 18:55:43 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Dec 2000 18:55:43.0417 (UTC) FILETIME=[CDB10290:01C05E23] Sender: owner-mpls@UU.NET Precedence: bulk What kind of SLAs are provided to MPLS VPN customer? If there's a VPN with three sites - A,B, C- do you get specific SLA for bandwidth and latency for each link (A-B, A-C, B-C) or do you get a SLA "into the cloud" (e.g. A is allowed 128K outgoing and 64K incoming, B is allowed 256K outgoing and 192K incoming, etc..) and so long you don't send more than allowed it's guaranteed? -Milos _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From owner-mpls@UU.NET Mon Dec 4 14:38:48 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09478 for ; Mon, 4 Dec 2000 14:38:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdq08781; Mon, 4 Dec 2000 19:37:28 GMT Received: by mail-control.mail.uu.net id QQjsdq15189 for mpls-outgoing; Mon, 4 Dec 2000 19:36:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsdq15180 for ; Mon, 4 Dec 2000 19:36:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsdq12567 for ; Mon, 4 Dec 2000 19:35:48 GMT Received: from mailhost.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQjsdq29112 for ; Mon, 4 Dec 2000 19:35:47 GMT Received: from avici.com (swdev23.avici.com [10.1.2.229]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id eB4JZfq09612; Mon, 4 Dec 2000 14:35:41 -0500 (EST) Message-Id: <200012041935.eB4JZfq09612@mailhost.avici.com> X-Mailer: exmh version 2.1.1 10/15/1999 From: Markus Jork To: Eyad Saheb cc: "'mpls@uu.net'" Subject: Re: MPLS for UDLR In-reply-to: Your message of "Mon, 04 Dec 2000 14:00:39 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Dec 2000 14:35:40 -0500 Sender: owner-mpls@UU.NET Precedence: bulk Eyad, RSVP works by establishing state along the flow of the Path message. The interface used by Resv messages doesn't matter. A Path message going from A to B includes a HOP object consisting of A's address and a "logical interface handle" (LIH). When B sends a Resv message back to A to 'complete the loop', it sends it to A's address found in the HOP object. The Resv message is not sent with the router alert option and will not be processed by any intermediate nodes it may take to get the message back to A. The Resv message also includes the LIH that B got from A. When the Resv arrives at A, the LIH may then be used to figure out what link this Resv applies to (namely the uni-directional link on which the Path message has been sent out previously). So RSVP will be able to set up a LSP across the uni-directional link. Markus > My impression is that although there is no restrictions on which interfaces > the PATH & RESV messages traverse, they will not accomplish anything if they > don't follow the same hops. Thus, if A is connected to B via a > uni-directional link, RSVP messages may use another uni-directional link to > 'complete the loop'. However, the links must be between A & B, any > intermediate hops will interfere: if they support RSVP, they would only have > received one of the PATH/RESV messages, or if they don't support RSVP they > won't be allowed in the LSP. > > Isn't this the case ? > > Eyad > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Markus > Jork > Sent: Monday, December 04, 2000 12:42 PM > To: Yangguang Xu > Cc: 'mpls@UU.NET' > Subject: Re: MPLS for UDLR > > > Yangguang, > > I didn't say that uni-directional links are currently in use > in packet networks. I'm not familiar with the UDLR work at all but > obviously it is an attempt to make use of uni-directional links. > So my point was that RSVP's design permits its use over uni-directional > links if someone wants to do that. > > Markus > > > Markus, > > > > I am confused. LSPs are uni-directional, it doesn't mean data links are > > uni-directional. My understanding is that data links are always > bi-directional. > > In another word, logical physical interfaces to forwarding engine are > > bi-directional. OSPF only treats bi-directional links as working links. > Even > > RSVP doesn't explicitly assume the bi-directional data link. It seems to > me > > that's the default > > > > Can you give me an example of uni-directional data link in packet network? > > > > Yangguang > > > > Markus Jork wrote: > > > > > > Just to clear up some confusion in this e-mail exchange. > > > RSVP does not have a problem with unidirectional links. > > > A Path message can be sent out on one interface and the > > > corresponding Resv message can come back in through any > > > other interface. > > > So when there is a unidirectional link from A to B, the only > > > requirement is that B somehow has to be able to send back a Resv > > > message to A (through some other interface or possibly via multiple > > > other intermediate nodes). There is no need for a bi-directional link. > > > > > > Markus > > > From owner-mpls@UU.NET Mon Dec 4 15:01:01 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14815 for ; Mon, 4 Dec 2000 15:01:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdr10814; Mon, 4 Dec 2000 19:59:39 GMT Received: by mail-control.mail.uu.net id QQjsdr17495 for mpls-outgoing; Mon, 4 Dec 2000 19:59:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsdr17421 for ; Mon, 4 Dec 2000 19:58:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsdr23435 for ; Mon, 4 Dec 2000 19:58:26 GMT Received: from fir.sycamorenet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fir.sycamorenet.com [63.65.20.2]) id QQjsdr07487 for ; Mon, 4 Dec 2000 19:58:24 GMT Received: by fir.sycamorenet.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 14:40:07 -0500 Message-ID: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com> From: "Wilder, David" To: "'Faisal S. Naik'" , mpls uunet Cc: soumen@sasken.com Subject: RE: MPLS and fragmentation.. Date: Mon, 4 Dec 2000 15:02:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk This is true; IP fragmentation is done by IP before entering the MPLS domain. However, there are case where adding the 4 byte label is going to cause the packet to now exceed the max mtu size. Then one must look at how to handle that situation i.e. fragment, discard or do nothing. Dave -----Original Message----- From: Faisal S. Naik [mailto:faisal2@hamdard.net.pk] Sent: Monday, December 04, 2000 2:08 PM To: mpls uunet Cc: soumen@sasken.com Subject: Re: MPLS and fragmentation.. hello soumen, Isnt this Ip fragmentation a part of the router before the packet enters the MPLS domain. Within the domain, there is only the label swapping mechanism that is working, with nothing to mention about the fragmentation part. Esp in cases of IPv6 fragmentation is not at all allowed, for exceptional cases, extended headers of IPv6 are used. Am i right Nisar saheb :) Regards, Faisal Naik > > > From owner-mpls@UU.NET Mon Dec 4 15:13:34 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17954 for ; Mon, 4 Dec 2000 15:13:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsds02091; Mon, 4 Dec 2000 20:12:14 GMT Received: by mail-control.mail.uu.net id QQjsds00286 for mpls-outgoing; Mon, 4 Dec 2000 20:11:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsds00261 for ; Mon, 4 Dec 2000 20:11:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsds07662 for ; Mon, 4 Dec 2000 20:11:09 GMT Received: from ennovatenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjsds26046 for ; Mon, 4 Dec 2000 20:11:09 GMT Received: from broncos (broncos.tst.ennovatenetworks.com [10.1.1.208]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id PAA27806; Mon, 4 Dec 2000 15:11:04 -0500 (EST) (envelope-from bkumar@ennovatenetworks.com) Reply-To: From: "Brijesh Kumar" To: "'milos milos'" , Subject: RE: MPLS VPN SLAs Date: Mon, 4 Dec 2000 15:11:13 -0500 Message-ID: <004401c05e2e$5abe4760$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: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit milos milos writes; > What kind of SLAs are provided to MPLS VPN customer? If > there's a VPN with > three sites - A,B, C- do you get specific SLA for bandwidth > and latency for > each link (A-B, A-C, B-C) or do you get a SLA "into the > cloud" (e.g. A is > allowed 128K outgoing and 64K incoming, B is allowed 256K > outgoing and 192K > incoming, etc..) and so long you don't send more than allowed it's > guaranteed? It depends on what a "SLA" tries to measure and control. SLAs into clouds can only be meaningful when VPN traffic can be deemed as a commodity (buy x amount of commodity c for price y). Generally not a very useful concept for data networking applications. But can be useful in some circumstances e.g., encrypt all traffic into the cloud (or encrypt traffic for particular applications regardless of source and/or destination). For any SLA to be really useful, a SLA should be closely aligned to the need of one or more user applications (otherwise, why bother?). As most data applications are point to point - they need service provisioning from one end to another end. Therefore, to be of any great use - VPNs should support SLAs that meet specific application needs between any two sites. One should be able to provision QoS from A to B & C, from B to A & C and from C to B & A. As mpls tunnels between edge nodes (PEs) are likely to be shared by more than one VPN - traffic engineering becomes a major issue in supporting per VPN based SLAs. But, this is the right way to provision SLAs in VPNs. Cheers, --brijesh Ennovate Networks Inc. From owner-mpls@UU.NET Mon Dec 4 15:18:03 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19399 for ; Mon, 4 Dec 2000 15:18:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdt03962; Mon, 4 Dec 2000 20:16:42 GMT Received: by mail-control.mail.uu.net id QQjsdt01024 for mpls-outgoing; Mon, 4 Dec 2000 20:16:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsdt00883 for ; Mon, 4 Dec 2000 20:15:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsds18870 for ; Mon, 4 Dec 2000 20:14:55 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjsds06658 for ; Mon, 4 Dec 2000 20:14:55 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06269 for ; Mon, 4 Dec 2000 15:14:52 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA14367 for ; Mon, 4 Dec 2000 15:14:52 -0500 (EST) Message-ID: <3A2BFB48.AAA7DABE@marconi.com> Date: Mon, 04 Dec 2000 15:15:04 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls uunet Subject: Re: MPLS and fragmentation.. References: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Wilder, David" wrote: > > This is true; IP fragmentation is done by IP before entering the MPLS > domain. However, there are case where adding the 4 byte label is > going to cause the packet to now exceed the max mtu size. Then one > must look at how to handle that situation i.e. fragment, discard or do > nothing. I don't see what the problem is here. If the ingress router knows the MTU for the entire path (as it must, if it is going to fragment packets), then it should not be a big deal to subtract a constant value from the computed MTU (to accomodate the label header) and fragment to that value instead. -- David From owner-mpls@UU.NET Mon Dec 4 15:26:12 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21134 for ; Mon, 4 Dec 2000 15:26:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdt16033; Mon, 4 Dec 2000 20:24:52 GMT Received: by mail-control.mail.uu.net id QQjsdt01738 for mpls-outgoing; Mon, 4 Dec 2000 20:24:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsdt01715 for ; Mon, 4 Dec 2000 20:23:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsdt04889 for ; Mon, 4 Dec 2000 20:21:28 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjsdt10904 for ; Mon, 4 Dec 2000 20:21:25 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 MAA16747 for ; Mon, 4 Dec 2000 12:21:30 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA00806 for mpls@uu.net; Mon, 4 Dec 2000 15:21:23 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsdt01334 for ; Mon, 4 Dec 2000 20:19:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsdt24340 for ; Mon, 4 Dec 2000 20:18:04 GMT Received: from tristero.cryptocourier.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQjsdt06079 for ; Mon, 4 Dec 2000 20:18:04 GMT Received: (qmail 18944 invoked from network); 4 Dec 2000 20:21:30 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 4 Dec 2000 20:21:30 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Mon, 4 Dec 2000 12:06:38 -0800 Date: Mon, 4 Dec 2000 12:06:38 -0800 From: Ben Black To: "Wilder, David" Cc: "'Faisal S. Naik'" , mpls uunet , soumen@sasken.com Subject: Re: MPLS and fragmentation.. Message-ID: <20001204120637.B1415@layer8.net> References: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com>; from David.Wilder@sycamorenet.com on Mon, Dec 04, 2000 at 03:02:20PM -0500 Sender: owner-mpls@UU.NET Precedence: bulk it is not possible to exceed the MTU (hence the name). the MTU for a path will be less than the MTU of the media carrying the path. exactly how much less depends on how many labels are stacked, how the encapsulation for a given media is implemented, etc. however, once an LSP is established, its MTU *should* be known (barring oddities when the LSP MTU changes during a failure or other re-routing event). so, faisal is correct: all fragmentation should occur outside the MPLS domain. ben On Mon, Dec 04, 2000 at 03:02:20PM -0500, Wilder, David wrote: > This is true; IP fragmentation is done by IP before entering the MPLS > domain. However, there are case where adding the 4 byte label is going to > cause the packet to now exceed the max mtu size. Then one must look at how > to handle that situation i.e. fragment, discard or do nothing. > > Dave > > -----Original Message----- > From: Faisal S. Naik [mailto:faisal2@hamdard.net.pk] > Sent: Monday, December 04, 2000 2:08 PM > To: mpls uunet > Cc: soumen@sasken.com > Subject: Re: MPLS and fragmentation.. > > > hello soumen, > Isnt this Ip fragmentation a part of the router before the packet enters the > MPLS domain. Within the domain, there is only the label swapping mechanism > that is working, with nothing to mention about the fragmentation part. > Esp in cases of IPv6 fragmentation is not at all allowed, for exceptional > cases, extended headers of IPv6 are used. > Am i right Nisar saheb :) > Regards, > Faisal Naik > > > > > > > From owner-mpls@UU.NET Mon Dec 4 16:49:13 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11930 for ; Mon, 4 Dec 2000 16:49:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsdz12861; Mon, 4 Dec 2000 21:47:50 GMT Received: by mail-control.mail.uu.net id QQjsdz22188 for mpls-outgoing; Mon, 4 Dec 2000 21:47:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsdz22146 for ; Mon, 4 Dec 2000 21:46:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsdz05138 for ; Mon, 4 Dec 2000 21:46:19 GMT From: Keith.Schuettpelz@go.ecitele.com Received: from mizar.ftl.telematics.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.telematics.com [147.137.1.7]) id QQjsdz10687 for ; Mon, 4 Dec 2000 21:46:19 GMT Received: from ussmtp01.ftl.telematics.com (ussmtp01 [147.137.15.41]) by mizar.ftl.telematics.com (8.9.1/8.9.1) with SMTP id QAA20664; Mon, 4 Dec 2000 16:45:55 -0500 (EST) Received: by ussmtp01.ftl.telematics.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 852569AB.0077A6CB ; Mon, 4 Dec 2000 16:46:54 -0500 X-Lotus-FromDomain: ECI TELECOM To: David Charlap cc: mpls uunet Message-ID: <852569AB.0077A509.00@ussmtp01.ftl.telematics.com> Date: Mon, 4 Dec 2000 16:49:01 -0500 Subject: Re: MPLS and fragmentation.. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk >"Wilder, David" wrote: >> >> This is true; IP fragmentation is done by IP before entering the MPLS >> domain. However, there are case where adding the 4 byte label is >> going to cause the packet to now exceed the max mtu size. Then one >> must look at how to handle that situation i.e. fragment, discard or do >> nothing. > >I don't see what the problem is here. If the ingress router knows the >MTU for the entire path (as it must, if it is going to fragment >packets), then it should not be a big deal to subtract a constant value >from the computed MTU (to accomodate the label header) and fragment to >that value instead. > In the case of an LSP setup using CR-LDP, how does the ingress router determine the MTU for the path? (assuming the ingress router is not also a host utilizing the LSP) From owner-mpls@UU.NET Mon Dec 4 17:07:17 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17592 for ; Mon, 4 Dec 2000 17:07:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsea01371; Mon, 4 Dec 2000 22:05:56 GMT Received: by mail-control.mail.uu.net id QQjsea29949 for mpls-outgoing; Mon, 4 Dec 2000 22:05:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsea29864 for ; Mon, 4 Dec 2000 22:05:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsea04717 for ; Mon, 4 Dec 2000 22:05:08 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjsea08681 for ; Mon, 4 Dec 2000 22:05:07 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA16869 for mpls@uu.net; Mon, 4 Dec 2000 17:05:06 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsea28378 for ; Mon, 4 Dec 2000 22:04:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsea27405 for ; Mon, 4 Dec 2000 22:02:50 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjsea18127 for ; Mon, 4 Dec 2000 22:02:50 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA02593; Mon, 4 Dec 2000 17:02:49 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA25909; Mon, 4 Dec 2000 17:02:49 -0500 (EST) Message-Id: <200012042202.RAA25909@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: iesg@ietf.org Cc: mpls@UU.NET Subject: RSVP-TE Last Call Date: Mon, 04 Dec 2000 17:02:49 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk RSVP-TE defines mechanisms for local repair during a failure. When such a repair occurs, it would be appropriate for this to be conveyed via an error message. An error value should be added to the "Notify Error Code" with the meaning "Tunnel locally repaired". Several small edits for clarity were suggested out of the interoperability testing that occurred at UNH. Also a number of typos and other have been pointed out. I would I believe these should be incorporated before publication as an RFC. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Mon Dec 4 17:08:05 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17768 for ; Mon, 4 Dec 2000 17:08:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsea23673; Mon, 4 Dec 2000 22:06:41 GMT Received: by mail-control.mail.uu.net id QQjsea00900 for mpls-outgoing; Mon, 4 Dec 2000 22:06:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsea00535 for ; Mon, 4 Dec 2000 22:05:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsea20615 for ; Mon, 4 Dec 2000 22:05:27 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjsea21832 for ; Mon, 4 Dec 2000 22:05:27 GMT Received: (from erosen@localhost) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA16932 for mpls@uu.net; Mon, 4 Dec 2000 17:05:26 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsea29207 for ; Mon, 4 Dec 2000 22:04:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsea02122 for ; Mon, 4 Dec 2000 22:04:18 GMT Received: from nero.doit.wisc.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQjsea07424 for ; Mon, 4 Dec 2000 22:04:18 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id QAA28062; Mon, 4 Dec 2000 16:04:08 -0600 Date: Mon, 4 Dec 2000 16:04:08 -0600 From: "James R. Leu" To: David Charlap Cc: mpls uunet Subject: Re: MPLS and fragmentation.. Message-ID: <20001204160407.B27937@doit.wisc.edu> Reply-To: jleu@mindspring.com References: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com> <3A2BFB48.AAA7DABE@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A2BFB48.AAA7DABE@marconi.com>; from david.charlap@marconi.com on Mon, Dec 04, 2000 at 03:15:04PM -0500 Organization: none Sender: owner-mpls@UU.NET Precedence: bulk Hello, See my comments at the bottom. On Mon, Dec 04, 2000 at 03:15:04PM -0500, David Charlap wrote: > "Wilder, David" wrote: > > > > This is true; IP fragmentation is done by IP before entering the MPLS > > domain. However, there are case where adding the 4 byte label is > > going to cause the packet to now exceed the max mtu size. Then one > > must look at how to handle that situation i.e. fragment, discard or do > > nothing. > > I don't see what the problem is here. If the ingress router knows the > MTU for the entire path (as it must, if it is going to fragment > packets), then it should not be a big deal to subtract a constant value > from the computed MTU (to accomodate the label header) and fragment to > that value instead. As David said, the key is that you need to know the MTU of the LSP at the ingress. RSVP-TE added a sub object that is used to "calculate" the MTU of the LSP. (it was added just before the Pittsburgh IETF) LDP (CR-LDP) does not have this feature. I'm not sure if the authors of either the LDP or CR-LDP drafts have plans to add it, or if they even believe it is needed. Jim -- James R. Leu From owner-mpls@UU.NET Mon Dec 4 17:20:36 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23372 for ; Mon, 4 Dec 2000 17:20:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjseb12203; Mon, 4 Dec 2000 22:19:16 GMT Received: by mail-control.mail.uu.net id QQjseb08274 for mpls-outgoing; Mon, 4 Dec 2000 22:18:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjseb08248 for ; Mon, 4 Dec 2000 22:18:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjseb13457 for ; Mon, 4 Dec 2000 22:17:20 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjseb17499 for ; Mon, 4 Dec 2000 22:17:18 GMT Received: from ada.csa.iisc.ernet.in (IDENT:root@ada.csa.iisc.ernet.in [144.16.67.35]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id DAA09417; Tue, 5 Dec 2000 03:44:23 +0530 Received: from localhost (prasanna@localhost) by ada.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id DAA24495; Tue, 5 Dec 2000 03:47:14 +0530 X-Authentication-Warning: ada.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Tue, 5 Dec 2000 03:47:14 +0530 (IST) From: Gaitonde Anandprasanna To: David Charlap cc: mpls@UU.NET Subject: Re: (Reply) Query about handling Non RSVP neighbours in RSVP-TE In-Reply-To: <3A2BC47F.9067A992@marconi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Thanx for answering my queries to all. I have one more query . Please see below On Mon, 4 Dec 2000, David Charlap wrote: > venkir@samsung.co.kr wrote: > > > > You r correct only, i.e., the first option is corect. > > Actually, in that paragraph, they explained about two scenarios. First > > one is about non-rsvp node as downstream router. In that case, > > upstream router has to send patherr. It's fine. Second one dealing > > with the case, where non-rsvp node as upstream router. That means if a > > rsvp node, gets a path message with LABEL_REQUEST from a non-rsvp > > node, it has to send a patherr message. Here message is from a > > non-rsvp node. Am I right? > > But only thing is, how come, a non-rsvp node sends a path > > message with LABEL_REQUEST to rsvp node? I don't think, this case will > > arise in real time scenario. > > The non-RSVP node won't generate such a message - it's not running RSVP! > Thats correct. > But it will forward such a message if it receives it. The PHOP node > doesn't necessarily know that there's a non-RSVP router between it and > the next hop. It may generate a Path message with LABEL_REQUEST, not > knowing that there's a non-RSVP router present on that link. The > non-RSVP router then forwards the message. > Yes, But can a PHOP node know wether the node ahead of it is RSVP capable or not. Is there any way ?? Please let me know.. > The NHOP RSVP router that receives the message detects the non-RSVP > router (by comparing TTL values), sees that there's a LABEL_REQUEST > object (indicating that this is an RSVP-TE Path message and not a non-TE > message), and proceeds to drop the message and generate a PathErr. > Yes this clear to me now.. Thanx a lot. Pras > -- David > _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-_|; Mon, 4 Dec 2000 17:30:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjseb17427; Mon, 4 Dec 2000 22:29:18 GMT Received: by mail-control.mail.uu.net id QQjseb09532 for mpls-outgoing; Mon, 4 Dec 2000 22:28:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjseb09524 for ; Mon, 4 Dec 2000 22:28:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjseb18221 for ; Mon, 4 Dec 2000 22:28:42 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjseb03052 for ; Mon, 4 Dec 2000 22:28:41 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 RAA14718 for ; Mon, 4 Dec 2000 17:28:39 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA03230 for ; Mon, 4 Dec 2000 17:28:35 -0500 (EST) Message-ID: <3A2C1A9F.9126A6A0@marconi.com> Date: Mon, 04 Dec 2000 17:28:47 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: (Reply) Query about handling Non RSVP neighbours in RSVP-TE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gaitonde Anandprasanna wrote: > > Yes, But can a PHOP node know wether the node ahead of it is RSVP > capable or not. Is there any way ?? Please let me know.. RSVP doesn't provide a mechanism for learning this. If a router has this knowledge, it must be learned through some other mechanism. Of course, if it receives some other Path on that link, and determines that a non-RSVP router is attached, there's no reason why it can't retain this knowledge for use with respect to Path messages sent out on that interface. -- David From owner-mpls@UU.NET Mon Dec 4 17:35:39 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29577 for ; Mon, 4 Dec 2000 17:35:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsec04219; Mon, 4 Dec 2000 22:34:20 GMT Received: by mail-control.mail.uu.net id QQjsec10144 for mpls-outgoing; Mon, 4 Dec 2000 22:33:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsec10135 for ; Mon, 4 Dec 2000 22:33:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsec09527 for ; Mon, 4 Dec 2000 22:32:43 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjsec08888 for ; Mon, 4 Dec 2000 22:32:43 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15238 for ; Mon, 4 Dec 2000 17:32:40 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA04611 for ; Mon, 4 Dec 2000 17:32:40 -0500 (EST) Message-ID: <3A2C1B91.B2915CC3@marconi.com> Date: Mon, 04 Dec 2000 17:32:49 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls uunet Subject: Re: MPLS and fragmentation.. References: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com> <3A2BFB48.AAA7DABE@marconi.com> <20001204160407.B27937@doit.wisc.edu> <20001204140213.B1431@layer8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ben Black wrote: > > i'd be quite interested in how an IP network would function correctly > when routers do not know the MTU for a link. would the edge devices > learn the LSP MTU through another protocol? The problem isn't for a link - it's for an LSP. Of course a router must know the MTU for directly-attached links. But an LSP-ingress router must know the MTU for the entire LSP - that is, the lowest MTU of all the links that the LSP traverses. This is not something tnat traditional IP routers normally keep track of unless they're running some kind of QoS-signalling protocol like RSVP. -- David From owner-mpls@UU.NET Mon Dec 4 17:44:31 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02690 for ; Mon, 4 Dec 2000 17:44:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsec10433; Mon, 4 Dec 2000 22:43:12 GMT Received: by mail-control.mail.uu.net id QQjsec10967 for mpls-outgoing; Mon, 4 Dec 2000 22:42:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsec10961 for ; Mon, 4 Dec 2000 22:42:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsec29444 for ; Mon, 4 Dec 2000 22:41:44 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjsec21301 for ; Mon, 4 Dec 2000 22:41:43 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA16221 for ; Mon, 4 Dec 2000 17:41:40 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06862 for ; Mon, 4 Dec 2000 17:41:40 -0500 (EST) Message-ID: <3A2C1DAF.23308682@marconi.com> Date: Mon, 04 Dec 2000 17:41:51 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls uunet Subject: Re: MPLS and fragmentation.. References: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com> <3A2BFB48.AAA7DABE@marconi.com> <20001204160407.B27937@doit.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "James R. Leu" wrote: > > As David said, the key is that you need to know the MTU of the LSP at > the ingress. RSVP-TE added a sub object that is used to "calculate" > the MTU of the LSP. (it was added just before the Pittsburgh IETF) Actually, a mechanism for this has always been present. RSVP-TE simply added a second mechanism. The Class-Of-Service CType for TSPEC and FLOWSPEC include MTU fields. The one in the TSPEC is clipped to the interface's MTU as the Path message progresses through the network. The one in the FLOWSPEC is validated against each link as the Resv message comes back. Before this was invented, this capability was achieved via the ADSPEC object. It also contains an MTU field, which is clipped as the Path message propages through the network. The value is then returned using the FLOWSPEC back to the ingress router. > LDP (CR-LDP) does not have this feature. I'm not sure if the authors > of either the LDP or CR-LDP drafts have plans to add it, or if they > even believe it is needed. I'm surprised. Given the need for ingress routers to fragment packets on behalf of the entire LSP, there must be a mechanism somewhere to determine what value everything should be fragmented to. -- David From owner-mpls@UU.NET Mon Dec 4 21:23:58 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04694 for ; Mon, 4 Dec 2000 21:23:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjser17645; Tue, 5 Dec 2000 02:22:34 GMT Received: by mail-control.mail.uu.net id QQjser17133 for mpls-outgoing; Tue, 5 Dec 2000 02:21:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjser17116 for ; Tue, 5 Dec 2000 02:21:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjser06246 for ; Tue, 5 Dec 2000 02:20:20 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQjser14763 for ; Tue, 5 Dec 2000 02:20:19 GMT Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 4 Dec 2000 21:18:44 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 4 Dec 2000 21:18:50 -0500 Message-ID: From: "Peter Tam" To: jleu@mindspring.com, Shahram Davari Cc: "'francis arts vh624 8492'" , Francis Arts , Satoru Matsushima , mpls@UU.NET, mpls-wg@janog.gr.jp Subject: RE: Processing the MPLS TTL Date: Mon, 4 Dec 2000 21:18:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05E61.AFD3B5E0" 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_01C05E61.AFD3B5E0 Content-Type: text/plain; charset="iso-8859-1" James: Part of this email must have been snipped, so I don't have the entire thread of discussion. Any way, my take is that the TTL is ALWAYS copied from the MPLS header to the IP header at the egress LSR. In the conventional mode where it is decremented by 1 at every intermediate hop, it is straight forward as the total decrement is the number of hops transversed. In the tunneling or NBMA (e.g. ATM and FR) scenario, it is decremented by 1 at the ingress LSR and remains constant by intermediate LSRs throughout the domain. Then, the egress LSR copies it in the same way as it does with the conventional mode. In other words, the whole tunneling or NBMA domain is treated as 1 virtual hop. So, there is no inter-operability or agreement problem between ingress and egress LSRs. Regards...Peter Tam, Nortel Networks -----Original Message----- From: James R. Leu [SMTP:jleu@mindspring.com] Sent: Monday, December 04, 2000 9:49 AM To: Shahram Davari Cc: 'francis arts vh624 8492'; jleu@mindspring.com; Francis Arts; Satoru Matsushima; mpls@UU.NET; mpls-wg@janog.gr.jp Subject: Re: Processing the MPLS TTL Hello, On Mon, Dec 04, 2000 at 04:59:35AM -0800, Shahram Davari wrote: > Hi, > > I think both methods are allowed. The two scenarios that they might be used > are in Uniform and Tunnel model. In the Uniform model we probably like to > copy the MPLS TTL to the IP TTL, and in Tunnel mode we probably like to just > decrement the IP TTL by one. Isn't there a possible interoperabilty problem with this? The Ingress and Egress have to agree on the same way of handling the TTL? AFAIK none of the signling protocols convery this info. Jim > Yours, > -Shahram > > > -----Original Message----- > > From: francis arts vh624 8492 [mailto:fart@sh.bel.alcatel.be] > > Sent: Monday, December 04, 2000 1:07 AM > > To: jleu@mindspring.com > > Cc: Francis Arts; Satoru Matsushima; mpls@UU.NET; mpls-wg@janog.gr.jp > > Subject: Re: Processing the MPLS TTL > > > > > > > > Jim, > > > > I agree that section 2.4.3 indeed indicates that "when a > > label is popped, and the > > resulting label stack is empty, then the value of the IP TTL > > field SHOULD BE > > replaced with the outgoing TTL value". > > > > However, the last paragraph of section 2.4.3 also states that > > 'it is recognized > > that there may be situations where a network administration > > prefers to decrement > > the IPv4 TTL by one as it traverses an MPLS domain, instead > > of decrementing the > > IPv4 TTL by the number of LSP hops within the domain." > > > > So if one would use the latter approach, the TTL is not meant > > to be copied from > > the MPLS header into the IP header in the LSP egress node. > > > > Kind regards, > > > > Francis. > > -- James R. Leu ------_=_NextPart_001_01C05E61.AFD3B5E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Processing the MPLS TTL

James:

Part of this email must have been = snipped, so I don't have the entire thread of discussion. Any way, my = take is that  the TTL is ALWAYS copied from the MPLS header to the = IP header at the egress LSR. In the conventional mode where it is = decremented by 1 at every intermediate hop, it is straight forward as = the total decrement is the number of hops transversed. In the tunneling = or NBMA (e.g. ATM and FR) scenario, it is decremented by 1 at the = ingress LSR and remains constant by intermediate LSRs throughout the = domain. Then, the egress LSR copies it in the same way as it does with = the conventional mode. In other words, the whole tunneling or NBMA = domain is treated as 1 virtual hop. So, there is no inter-operability = or agreement problem between ingress and egress LSRs.

Regards...Peter Tam,
Nortel Networks

    -----Original = Message-----
    From:   James R. Leu = [SMTP:jleu@mindspring.com]
    Sent:   Monday, December 04, 2000 9:49 AM
    To:     Shahram Davari
    Cc:     'francis arts vh624 8492'; jleu@mindspring.com; Francis = Arts; Satoru Matsushima; mpls@UU.NET; mpls-wg@janog.gr.jp

    Subject:       = Re: Processing the MPLS TTL

    Hello,

    On Mon, Dec 04, 2000 at 04:59:35AM = -0800, Shahram Davari wrote:
    > Hi,
    >
    > I think both methods are = allowed. The two scenarios that they might be used
    > are in Uniform and Tunnel model. = In the Uniform model we probably like to
    > copy the MPLS TTL to the IP TTL, = and in Tunnel mode we probably like to just
    > decrement the IP TTL by = one.

    Isn't there a possible interoperabilty = problem with this?  The Ingress and
    Egress have to agree on the same way = of handling the TTL? AFAIK none
    of the signling protocols convery = this info.

    Jim

    > Yours,
    > -Shahram
    >
    > > -----Original = Message-----
    > > From: francis arts vh624 = 8492 [mailto:fart@sh.bel.alcatel.be= ]
    > > Sent: Monday, December 04, = 2000 1:07 AM
    > > To: = jleu@mindspring.com
    > > Cc: Francis Arts; Satoru = Matsushima; mpls@UU.NET; mpls-wg@janog.gr.jp
    > > Subject: Re: Processing the = MPLS TTL
    > >
    > >
    > >
    > > Jim,
    > >
    > > I agree that section 2.4.3 = indeed indicates that "when a
    > > label is popped, and = the
    > > resulting label stack is = empty, then the value of the IP TTL
    > > field SHOULD BE
    > > replaced with the outgoing = TTL value".
    > >
    > > However, the last paragraph = of section 2.4.3 also states that
    > > 'it is recognized
    > > that there may be = situations where a network administration
    > > prefers to decrement
    > > the IPv4 TTL by one as it = traverses an MPLS domain, instead
    > > of decrementing the
    > > IPv4 TTL by the number of = LSP hops within the domain."
    > >
    > > So if one would use the = latter approach, the TTL is not meant
    > > to be copied from
    > > the MPLS header into the IP = header in the LSP egress node.
    > >
    > > Kind regards,
    > >
    > >     = Francis.
    > >
    --
    James R. Leu

------_=_NextPart_001_01C05E61.AFD3B5E0-- From owner-mpls@UU.NET Mon Dec 4 23:30:22 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04242 for ; Mon, 4 Dec 2000 23:30:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsez10586; Tue, 5 Dec 2000 04:29:03 GMT Received: by mail-control.mail.uu.net id QQjsez21478 for mpls-outgoing; Tue, 5 Dec 2000 04:28:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsez21464 for ; Tue, 5 Dec 2000 04:28:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsez17655 for ; Tue, 5 Dec 2000 04:28:00 GMT Received: from web10505.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web10505.mail.yahoo.com [216.136.130.155]) id QQjsez08353 for ; Tue, 5 Dec 2000 04:27:45 GMT Message-ID: <20001205042744.24802.qmail@web10505.mail.yahoo.com> Received: from [198.206.187.100] by web10505.mail.yahoo.com; Mon, 04 Dec 2000 20:27:44 PST Date: Mon, 4 Dec 2000 20:27:44 -0800 (PST) From: Mahadevan Iyer Subject: RE: MPLS VPN SLAs To: bkumar@ennovatenetworks.com, "'milos milos'" , mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Is there anyone working for the service providers offering MPLS VPN's who can comment on this topic. "What kind of SLAs are provided to an MPLS VPN customer ?" --- Brijesh Kumar wrote: > milos milos writes; > > What kind of SLAs are provided to MPLS VPN > customer? If > provision QoS from > A to B & C, from B to A & C and from C to B & A. As > mpls tunnels > between edge nodes (PEs) are likely to be shared by > more than one > VPN - traffic engineering becomes a major issue in > supporting per VPN > based SLAs. But, this is the right way to provision > SLAs in VPNs. __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-mpls@UU.NET Tue Dec 5 03:35:15 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29171 for ; Tue, 5 Dec 2000 03:35:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsfq22170; Tue, 5 Dec 2000 08:33:54 GMT Received: by mail-control.mail.uu.net id QQjsfq29369 for mpls-outgoing; Tue, 5 Dec 2000 08:33:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsfq29353 for ; Tue, 5 Dec 2000 08:33:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsfq16786 for ; Tue, 5 Dec 2000 08:33:14 GMT Received: from gorilla.mchh.siemens.de by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQjsfq08550 for ; Tue, 5 Dec 2000 08:33:13 GMT Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA14909; Tue, 5 Dec 2000 09:32:42 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA27516; Tue, 5 Dec 2000 09:33:09 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 09:33:08 +0100 Message-ID: From: Heiles Juergen To: mpls@UU.NET Cc: ip-optical Subject: Generalized MPLS-Scope Date: Tue, 5 Dec 2000 09:32:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, while reading through draft-ietf-mpls-generalized-signaling-01 "Generalized MPLS - Signaling Functional Description" I noticed that the document is not very general in its description, it is focused on SDH/Sonet and WDM. Already in the introduction it limits itself to certain multiplex technologies. It subdivides LSRs into - Packet-Switch Capable PSC (which could be IP, ATM or any other packet/cell based technology) - Time-Division Multiplex Capable TSC - Lambda Switch Capable LSC - and Fiber-Switch Capable FSC. The later 3 are only specific technologies for circuit switching and should as such not listed as generic sub classes. Instead I would subdivide into - Packet-Switch Capable PSC - and Circuit Switch Capable CSC, which could be time-slot switching (TDM with its different flavors like SDH/Sonet and PDH), wavelength/lambda switching (WDM), but also frequency switching (FDM) or code switching (CDM)DM or fiber/wire switching. The differentiation into LSC ands CSC is important and not if it is TDM, WDM, FDM, CDM, ... This gets important if you go into more details of CSC in the same way as IP or ATM gets important for LSC. In draft-bernstein-gmpls-optical-00 "Some Comments on GMPLS and Optical Technologies" some of the specific features of circuit switched networks are listed (e.g. a connection uses a specific amount of link bandwidth, the link has to support the specific format/bandwidth of the connection). They apply to circuit switching in general. So the first focus of GMPLS should be on the specific features/requirements of PSC and CSC. Additional technology specific features/requirements (e.g. for SDH/Sonet, WDM) should be part of a technology specific definition as it is not longer general. Regards Juergen Heiles From owner-mpls@UU.NET Tue Dec 5 06:37:05 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12712 for ; Tue, 5 Dec 2000 06:37:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsgc10646; Tue, 5 Dec 2000 11:35:44 GMT Received: by mail-control.mail.uu.net id QQjsgc20685 for mpls-outgoing; Tue, 5 Dec 2000 11:35:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsgc20680 for ; Tue, 5 Dec 2000 11:35:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsgc19161 for ; Tue, 5 Dec 2000 11:35:08 GMT Received: from hvs.envisage.co.za by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hvs.envisage.co.za [196.36.168.58]) id QQjsgc02834 for ; Tue, 5 Dec 2000 11:35:05 GMT Received: (from hvisage@localhost) by hvs.envisage.co.za (8.10.1/8.10.1) id eB5BYjM11416; Tue, 5 Dec 2000 13:34:45 +0200 Date: Tue, 5 Dec 2000 13:34:45 +0200 From: Hendrik Visage To: David Charlap Cc: mpls uunet Subject: Re: MPLS and fragmentation.. Message-ID: <20001205133445.B11378@hvs.envisage.co.za> References: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com> <3A2BFB48.AAA7DABE@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3A2BFB48.AAA7DABE@marconi.com>; from david.charlap@marconi.com on Mon, Dec 04, 2000 at 03:15:04PM -0500 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Dec 04, 2000 at 03:15:04PM -0500, David Charlap wrote: > "Wilder, David" wrote: > > > > This is true; IP fragmentation is done by IP before entering the MPLS > > domain. However, there are case where adding the 4 byte label is > > going to cause the packet to now exceed the max mtu size. Then one > > must look at how to handle that situation i.e. fragment, discard or do > > nothing. > > I don't see what the problem is here. If the ingress router knows the > MTU for the entire path (as it must, if it is going to fragment The problem starts with some very famous (but perhaps lesser loved by the techies) OSes that doesn't do the Path MTU discovery correctly, which then get's totally confused, and we are having another set of problems to debug with the clients that were promised a pink sun, purple moons and stars with a dash of green.... > packets), then it should not be a big deal to subtract a constant value > from the computed MTU (to accomodate the label header) and fragment to > that value instead. And then the famous OS just goes west, after giving the client a set of fingers to choose from... It's a serious issue for us, where we've seen IPSec and other tunnel solutions giving more trouble than what's it worth. And BTW, have I yet mentioned the impact this might have on transparent caching solutions that ISPs have in place?? Greetz Hendrik > > -- David -- ------------------------ Hendrik Visage hvisage@envisage.co.za From owner-mpls@UU.NET Tue Dec 5 08:13:31 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10417 for ; Tue, 5 Dec 2000 08:13:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsgi05773; Tue, 5 Dec 2000 13:12:10 GMT Received: by mail-control.mail.uu.net id QQjsgi20244 for mpls-outgoing; Tue, 5 Dec 2000 13:11:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsgi20239 for ; Tue, 5 Dec 2000 13:11:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsgi05629 for ; Tue, 5 Dec 2000 13:09:27 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjsgi25011 for ; Tue, 5 Dec 2000 13:09:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA02626 for mpls@uu.net; Tue, 5 Dec 2000 08:09:22 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsgi19874 for ; Tue, 5 Dec 2000 13:08:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsgi06935 for ; Tue, 5 Dec 2000 13:08:14 GMT Received: from procyon.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjsgi28784 for ; Tue, 5 Dec 2000 13:08:14 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id FAA27243; Tue, 5 Dec 2000 05:06:28 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 05:06:51 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9ACA@BBY1EXM01> From: Shahram Davari To: "'Ben Black'" , "Wilder, David" Cc: "'Faisal S. Naik'" , mpls uunet , soumen@sasken.com Subject: RE: MPLS and fragmentation.. Date: Tue, 5 Dec 2000 05:06:27 -0800 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, It is possible to do fragmentation in MPLS layer. Please check section 3 of: http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-08.txt "If the LSR chooses not to discard a labeled IPv4 datagram which is too big, or if the DF bit is set in that datagram, then it MUST execute the following algorithm: 1. Strip off the label stack entries to obtain the IP datagram. 2. Let N be the number of bytes in the label stack (i.e, 4 times the number of label stack entries). 3. If the IP datagram does NOT have the "Don't Fragment" bit set in its IP header: a. convert it into fragments, each of which MUST be at least N bytes less than the Effective Maximum Frame Payload Size. b. Prepend each fragment with the same label header that would have been on the original datagram had fragmentation not been necessary. c. Forward the fragments " Yours, -Shahram > -----Original Message----- > From: Ben Black [mailto:ben@layer8.net] > Sent: Monday, December 04, 2000 3:07 PM > To: Wilder, David > Cc: 'Faisal S. Naik'; mpls uunet; soumen@sasken.com > Subject: Re: MPLS and fragmentation.. > > > it is not possible to exceed the MTU (hence the name). the MTU > for a path will be less than the MTU of the media carrying the path. > exactly how much less depends on how many labels are stacked, how > the encapsulation for a given media is implemented, etc. however, > once an LSP is established, its MTU *should* be known (barring > oddities when the LSP MTU changes during a failure or other > re-routing event). > > so, faisal is correct: all fragmentation should occur outside the MPLS > domain. > > > ben > > On Mon, Dec 04, 2000 at 03:02:20PM -0500, Wilder, David wrote: > > This is true; IP fragmentation is done by IP before > entering the MPLS > > domain. However, there are case where adding the 4 byte > label is going to > > cause the packet to now exceed the max mtu size. Then one > must look at how > > to handle that situation i.e. fragment, discard or do nothing. > > > > Dave > > > > -----Original Message----- > > From: Faisal S. Naik [mailto:faisal2@hamdard.net.pk] > > Sent: Monday, December 04, 2000 2:08 PM > > To: mpls uunet > > Cc: soumen@sasken.com > > Subject: Re: MPLS and fragmentation.. > > > > > > hello soumen, > > Isnt this Ip fragmentation a part of the router before the > packet enters the > > MPLS domain. Within the domain, there is only the label > swapping mechanism > > that is working, with nothing to mention about the > fragmentation part. > > Esp in cases of IPv6 fragmentation is not at all allowed, > for exceptional > > cases, extended headers of IPv6 are used. > > Am i right Nisar saheb :) > > Regards, > > Faisal Naik > > > > > > > > > > > > From owner-mpls@UU.NET Tue Dec 5 08:22:41 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12546 for ; Tue, 5 Dec 2000 08:22:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsgj22237; Tue, 5 Dec 2000 13:21:20 GMT Received: by mail-control.mail.uu.net id QQjsgj21111 for mpls-outgoing; Tue, 5 Dec 2000 13:20:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsgj21101 for ; Tue, 5 Dec 2000 13:20:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsgj14187 for ; Tue, 5 Dec 2000 13:20:40 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjsgj28471 for ; Tue, 5 Dec 2000 13:20:39 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 FAA26446 for ; Tue, 5 Dec 2000 05:20:41 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA03466 for mpls@uu.net; Tue, 5 Dec 2000 08:20:38 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsea07170 for ; Mon, 4 Dec 2000 22:13:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsea01958 for ; Mon, 4 Dec 2000 22:13:40 GMT Received: from tristero.cryptocourier.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQjsea22579 for ; Mon, 4 Dec 2000 22:13:40 GMT Received: (qmail 19228 invoked from network); 4 Dec 2000 22:17:06 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 4 Dec 2000 22:17:06 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Mon, 4 Dec 2000 14:02:14 -0800 Date: Mon, 4 Dec 2000 14:02:14 -0800 From: Ben Black To: "James R. Leu" Cc: David Charlap , mpls uunet Subject: Re: MPLS and fragmentation.. Message-ID: <20001204140213.B1431@layer8.net> References: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com> <3A2BFB48.AAA7DABE@marconi.com> <20001204160407.B27937@doit.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001204160407.B27937@doit.wisc.edu>; from jleu@mindspring.com on Mon, Dec 04, 2000 at 04:04:08PM -0600 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Dec 04, 2000 at 04:04:08PM -0600, James R. Leu wrote: > > LDP (CR-LDP) does not have this feature. I'm not sure if the authors of > either the LDP or CR-LDP drafts have plans to add it, or if they even believe > it is needed. > i'd be quite interested in how an IP network would function correctly when routers do not know the MTU for a link. would the edge devices learn the LSP MTU through another protocol? ben From owner-mpls@UU.NET Tue Dec 5 08:22:48 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12573 for ; Tue, 5 Dec 2000 08:22:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsgj29601; Tue, 5 Dec 2000 13:21:25 GMT Received: by mail-control.mail.uu.net id QQjsgj21122 for mpls-outgoing; Tue, 5 Dec 2000 13:21:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsgj21102 for ; Tue, 5 Dec 2000 13:20:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsgj14476 for ; Tue, 5 Dec 2000 13:20:45 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjsgj28580 for ; Tue, 5 Dec 2000 13:20:45 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 FAA26489 for ; Tue, 5 Dec 2000 05:20:46 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA03474 for mpls@uu.net; Tue, 5 Dec 2000 08:20:43 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsed11282 for ; Mon, 4 Dec 2000 22:45:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsed20514 for ; Mon, 4 Dec 2000 22:45:33 GMT Received: from tristero.cryptocourier.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQjsed26130 for ; Mon, 4 Dec 2000 22:45:33 GMT Received: (qmail 19347 invoked from network); 4 Dec 2000 22:48:59 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 4 Dec 2000 22:48:59 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Mon, 4 Dec 2000 14:34:07 -0800 Date: Mon, 4 Dec 2000 14:34:07 -0800 From: Ben Black To: David Charlap Cc: mpls uunet Subject: Re: MPLS and fragmentation.. Message-ID: <20001204143407.D1431@layer8.net> References: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com> <3A2BFB48.AAA7DABE@marconi.com> <20001204160407.B27937@doit.wisc.edu> <3A2C1DAF.23308682@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3A2C1DAF.23308682@marconi.com>; from david.charlap@marconi.com on Mon, Dec 04, 2000 at 05:41:51PM -0500 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Dec 04, 2000 at 05:41:51PM -0500, David Charlap wrote: > > > LDP (CR-LDP) does not have this feature. I'm not sure if the authors > > of either the LDP or CR-LDP drafts have plans to add it, or if they > > even believe it is needed. > > I'm surprised. Given the need for ingress routers to fragment packets > on behalf of the entire LSP, there must be a mechanism somewhere to > determine what value everything should be fragmented to. > exactly. i believe we are now on the same page. ben From owner-mpls@UU.NET Tue Dec 5 08:23:36 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12777 for ; Tue, 5 Dec 2000 08:23:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsgj01068; Tue, 5 Dec 2000 13:22:15 GMT Received: by mail-control.mail.uu.net id QQjsgj21123 for mpls-outgoing; Tue, 5 Dec 2000 13:21:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsgj21103 for ; Tue, 5 Dec 2000 13:20:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsgj14355 for ; Tue, 5 Dec 2000 13:20:43 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjsgj21044 for ; Tue, 5 Dec 2000 13:20: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 FAA18340 for ; Tue, 5 Dec 2000 05:20:48 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA03470 for mpls@uu.net; Tue, 5 Dec 2000 08:20:41 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsec10652 for ; Mon, 4 Dec 2000 22:39:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsec01025 for ; Mon, 4 Dec 2000 22:39:25 GMT Received: from tristero.cryptocourier.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQjsec11663 for ; Mon, 4 Dec 2000 22:39:25 GMT Received: (qmail 19308 invoked from network); 4 Dec 2000 22:42:51 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 4 Dec 2000 22:42:51 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Mon, 4 Dec 2000 14:27:59 -0800 Date: Mon, 4 Dec 2000 14:27:59 -0800 From: Ben Black To: David Charlap Cc: mpls uunet Subject: Re: MPLS and fragmentation.. Message-ID: <20001204142759.C1431@layer8.net> References: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com> <3A2BFB48.AAA7DABE@marconi.com> <20001204160407.B27937@doit.wisc.edu> <20001204140213.B1431@layer8.net> <3A2C1B91.B2915CC3@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3A2C1B91.B2915CC3@marconi.com>; from david.charlap@marconi.com on Mon, Dec 04, 2000 at 05:32:49PM -0500 Sender: owner-mpls@UU.NET Precedence: bulk as far as the router is concerned, the LSP *is* the link, and that was the intent of my statement. if the router attached the one end of an LSP wishes to forward traffic over that LSP, it must know the MTU for that LSP unless fragmentation is to be performed by intermediate LSRs. ben On Mon, Dec 04, 2000 at 05:32:49PM -0500, David Charlap wrote: > Ben Black wrote: > > > > i'd be quite interested in how an IP network would function correctly > > when routers do not know the MTU for a link. would the edge devices > > learn the LSP MTU through another protocol? > > The problem isn't for a link - it's for an LSP. > > Of course a router must know the MTU for directly-attached links. But > an LSP-ingress router must know the MTU for the entire LSP - that is, > the lowest MTU of all the links that the LSP traverses. > > This is not something tnat traditional IP routers normally keep track of > unless they're running some kind of QoS-signalling protocol like RSVP. > > -- David > From owner-mpls@UU.NET Tue Dec 5 08:24:08 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12914 for ; Tue, 5 Dec 2000 08:24:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsgj25283; Tue, 5 Dec 2000 13:22:47 GMT Received: by mail-control.mail.uu.net id QQjsgj21289 for mpls-outgoing; Tue, 5 Dec 2000 13:22:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsgj21265 for ; Tue, 5 Dec 2000 13:21:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsgj08987 for ; Tue, 5 Dec 2000 13:20:47 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjsgj28644 for ; Tue, 5 Dec 2000 13:20:47 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 FAA26509 for ; Tue, 5 Dec 2000 05:20:49 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id IAA03478 for mpls@uu.net; Tue, 5 Dec 2000 08:20:46 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsfa22348 for ; Tue, 5 Dec 2000 04:38:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsfa26612 for ; Tue, 5 Dec 2000 04:37:48 GMT Received: from 00-SRV-RELATUS.pcnet.whq.netconstruct.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 00-srv-relatus.pcnet.whq.netconstruct.com [208.179.184.70]) id QQjsfa08840 for ; Tue, 5 Dec 2000 04:37:47 GMT Subject: RE: MPLS VPN SLAs Date: Mon, 4 Dec 2000 20:36:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MIMEOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: MPLS VPN SLAs content-class: urn:content-classes:message Thread-Index: AcBedOvuMZcBV2s0SSKAIGqOb/ESjw== From: "Alexander G. Paoli" To: "Mahadevan Iyer" , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA12914 The is an ISP in SO CA, that is offering ATM MPLS VPN (whew). They are called InternetConnect (www.internetconnect.com) Call them and ask for the SLA(s) they are offering customers. If the InternetConnect Engineer is on this board, maybe he can answer directly. I would assume he/she is here :> -AGP -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Mahadevan Iyer Sent: Monday, December 04, 2000 8:28 PM To: bkumar@ennovatenetworks.com; 'milos milos'; mpls@UU.NET Subject: RE: MPLS VPN SLAs Is there anyone working for the service providers offering MPLS VPN's who can comment on this topic. "What kind of SLAs are provided to an MPLS VPN customer ?" --- Brijesh Kumar wrote: > milos milos writes; > > What kind of SLAs are provided to MPLS VPN > customer? If > provision QoS from > A to B & C, from B to A & C and from C to B & A. As > mpls tunnels > between edge nodes (PEs) are likely to be shared by > more than one > VPN - traffic engineering becomes a major issue in > supporting per VPN > based SLAs. But, this is the right way to provision > SLAs in VPNs. __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ From owner-mpls@UU.NET Tue Dec 5 09:32:36 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28772 for ; Tue, 5 Dec 2000 09:32:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsgo19474; Tue, 5 Dec 2000 14:31:15 GMT Received: by mail-control.mail.uu.net id QQjsgo10140 for mpls-outgoing; Tue, 5 Dec 2000 14:30:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsgo10072 for ; Tue, 5 Dec 2000 14:30:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsgo03502 for ; Tue, 5 Dec 2000 14:30:01 GMT Received: from penguin-ext.wise.edt.ericsson.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: penguin-ext.wise.edt.ericsson.se [194.237.142.110]) id QQjsgo11904 for ; Tue, 5 Dec 2000 14:30:00 GMT Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id eB5ETxG01290 for ; Tue, 5 Dec 2000 15:29:59 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Dec 05 15:29:56 2000 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2651.58) id ; Tue, 5 Dec 2000 15:29:57 +0100 Message-ID: From: "Gabor Korossy (ETH)" To: "'Yang Yo-Jin'" Cc: "'mpls@UU.NET'" Subject: RE: in topology-driven how is ospf work? Date: Tue, 5 Dec 2000 15:29:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Vojiny, today the traffic driven MPLS is basicly non-existing (anyone contradicting?). All implementations are based on the topology-driven scheme. Routing protocols however work the same way in MPLS regardless whether it's topology or traffic driven. The information carried is routing information and is independent from MPLS. In case you want to use the traffic engineering extensions then those extensions are also carried, again regardless whether it's topology or traffic driven. regards / Gabor > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner- > mpls@UU.NET]On Behalf Of yojiny > Sent: Monday, December 04, 2000 8:58 AM > To: mpls@UU.NET > Subject: in topology-driven how is ospf work? > > > I have a question. > I wnat to know difference fo funtction fo ospf in topology-driven and > traffic-driven? > and what informaton is carred by routing protocol in two different method? > > thanks in advance. > > yang yojin. > I > > From owner-mpls@UU.NET Tue Dec 5 10:06:44 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09714 for ; Tue, 5 Dec 2000 10:06:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsgq14888; Tue, 5 Dec 2000 15:05:22 GMT Received: by mail-control.mail.uu.net id QQjsgq24133 for mpls-outgoing; Tue, 5 Dec 2000 15:04:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsgq24097 for ; Tue, 5 Dec 2000 15:04:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsgq08929 for ; Tue, 5 Dec 2000 15:04:38 GMT Received: from ennovatenetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjsgq13600 for ; Tue, 5 Dec 2000 15:04:38 GMT Received: from tworster (iguard2.ennovatenetworks.com [63.102.148.66]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id KAA06466 for ; Tue, 5 Dec 2000 10:04:38 -0500 (EST) (envelope-from tom@ennovatenetworks.com) From: "tom worster" To: Subject: RE: MPLS VPN SLAs Date: Tue, 5 Dec 2000 10:04:06 -0500 Message-ID: <000101c05ecc$9d622c50$7203010a@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.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Alexander G. Paoli > > The is an ISP in SO CA, that is offering ATM MPLS VPN (whew). > > They are called InternetConnect (www.internetconnect.com) > Call them and > ask for the SLA(s) they are offering customers. > > If the InternetConnect Engineer is on this board, maybe he can answer > directly. I would assume he/she is here :> if we start looking at service provider offerings in the context of milos' question i think it's important to understand the difference between marketing service with an sla and doing the engineering that can give one real confidence in an sla. i suspect milos may have been interested in the latter. a recent thread on nanog is relevant: http://www.cctec.com/maillists/nanog/historical/0011/msg00577.html c u fsb From owner-mpls@UU.NET Tue Dec 5 10:43:54 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19673 for ; Tue, 5 Dec 2000 10:43:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsgs29526; Tue, 5 Dec 2000 15:42:34 GMT Received: by mail-control.mail.uu.net id QQjsgs29614 for mpls-outgoing; Tue, 5 Dec 2000 15:42:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsgs29600 for ; Tue, 5 Dec 2000 15:41:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsgs06380 for ; Tue, 5 Dec 2000 15:39:59 GMT Received: from femail4.sdc1.sfba.home.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail4.sdc1.sfba.home.com [24.0.95.84]) id QQjsgs25529 for ; Tue, 5 Dec 2000 15:39:58 GMT Received: from c1052242a.frmt1.sfba.home.com ([24.19.208.28]) by femail4.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001205153818.WRDB29141.femail4.sdc1.sfba.home.com@c1052242a.frmt1.sfba.home.com>; Tue, 5 Dec 2000 07:38:18 -0800 Message-ID: <015001c05f36$6aa8e460$1cd01318@frmt1.sfba.home.com> Reply-To: "Manohar Ellanti" From: "Manohar Ellanti" To: "tom worster" , References: <000101c05ecc$9d622c50$7203010a@ennovatenetworks.com> Subject: Re: MPLS VPN SLAs Date: Tue, 5 Dec 2000 19:41:28 -0800 Organization: @home MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "tom worster" To: Sent: Tuesday, December 05, 2000 7:04 AM Subject: RE: MPLS VPN SLAs > > if we start looking at service provider offerings in > the context of milos' question i think it's important > to understand the difference between marketing service > with an sla and doing the engineering that can give one > real confidence in an sla. i suspect milos may have > been interested in the latter. a recent thread on nanog > is relevant: I would agree with you. We still need to understand the engineering aspect of providing per VPN SLA Bruce Davie and Yakov Rekhter discuss QoS for VPNs in their book. The pipe and hose model being discussed in the book do explain some apsects and particularly the hose model which has broad appeal and potential interms better utilization of network resources. I think implementation of VPN may be propietary and may have IP, but interfaces, defining QoS requirements must be standardized for the MPLS based VPNs. > http://www.cctec.com/maillists/nanog/historical/0011/msg00577.html > -Manohar N Ellanti From owner-mpls@UU.NET Tue Dec 5 10:53:39 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22669 for ; Tue, 5 Dec 2000 10:53:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsgt07944; Tue, 5 Dec 2000 15:52:18 GMT Received: by mail-control.mail.uu.net id QQjsgt00873 for mpls-outgoing; Tue, 5 Dec 2000 15:51:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsgt00858 for ; Tue, 5 Dec 2000 15:51:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsgt11856 for ; Tue, 5 Dec 2000 15:51:22 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjsgt18562 for ; Tue, 5 Dec 2000 15:51:22 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 KAA16760 for ; Tue, 5 Dec 2000 10:51:19 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA22080 for ; Tue, 5 Dec 2000 10:51:20 -0500 (EST) Message-ID: <3A2D0F07.35070595@marconi.com> Date: Tue, 05 Dec 2000 10:51:35 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls uunet Subject: Re: MPLS and fragmentation.. References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9ACA@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > It is possible to do fragmentation in MPLS layer. ... Yes, but it is a bad idea if your LSPs are not using best-effort levels of QoS. Fragmentation causes a packet to be forwarded via a router's slow-path. It also increases the amount of data in the stream. Both of which can cause otherwise-compliant data to violate the signalled QoS contract. The only way to avoid this is to have the ingress router do all fragmentation (and possibly subsequent traffic shaping) before injecting the packets into the LSP. -- David From owner-mpls@UU.NET Tue Dec 5 11:05:28 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26031 for ; Tue, 5 Dec 2000 11:05:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsgu06898; Tue, 5 Dec 2000 16:04:02 GMT Received: by mail-control.mail.uu.net id QQjsgu09608 for mpls-outgoing; Tue, 5 Dec 2000 16:03:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsgu09010 for ; Tue, 5 Dec 2000 16:03:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsgu03907 for ; Tue, 5 Dec 2000 16:00:50 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjsgu02450 for ; Tue, 5 Dec 2000 16:00: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 LAA17801 for ; Tue, 5 Dec 2000 11:00:47 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26207 for ; Tue, 5 Dec 2000 11:00:47 -0500 (EST) Message-ID: <3A2D1132.3595A3F1@marconi.com> Date: Tue, 05 Dec 2000 11:00:50 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls uunet Subject: Re: MPLS and fragmentation.. References: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com> <3A2BFB48.AAA7DABE@marconi.com> <20001205133445.B11378@hvs.envisage.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hendrik Visage wrote: > David Charlap wrote: >> "Wilder, David" wrote: >>> >>> This is true; IP fragmentation is done by IP before entering the >>> MPLS domain. However, there are case where adding the 4 byte label >>> is going to cause the packet to now exceed the max mtu size. Then >>> one must look at how to handle that situation i.e. fragment, discard >>> or do nothing. >> >> I don't see what the problem is here. If the ingress router knows >> the MTU for the entire path (as it must, if it is going to fragment > > The problem starts with some very famous (but perhaps lesser loved by > the techies) OSes that doesn't do the Path MTU discovery correctly, This is irrelevant. PMTU Discovery is not used in LSP setup. Once the LSP is established, the ingress router should fragment packets that are too large (or reject them if the DF bit is set.) > which then get's totally confused, and we are having another set of > problems to debug with the clients that were promised a pink sun, > purple moons and stars with a dash of green.... This is the exact same problem you have without MPLS. The only thing that might possible change is the IP address of the router that's dropping the non-compliant packets. I'm sorry if you were under the impression that MPLS will eliminate the needs for clients to have a clue about MTU values. It was never intended to do a thing about that problem, and it does not. >> packets), then it should not be a big deal to subtract a constant >> value from the computed MTU (to accomodate the label header) and >> fragment to that value instead. > > And then the famous OS just goes west, after giving the client a set > of fingers to choose from... What the heck are you talking about? If your client has a broken MTU discovery, it will remain broken with or without MPLS running in the core of the network. > It's a serious issue for us, where we've seen IPSec and other tunnel > solutions giving more trouble than what's it worth. > > And BTW, have I yet mentioned the impact this might have on > transparent caching solutions that ISPs have in place?? If you want to discuss something other than MPLS, please take it to another list. -- David From owner-mpls@UU.NET Tue Dec 5 12:37:27 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20215 for ; Tue, 5 Dec 2000 12:37:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsha15125; Tue, 5 Dec 2000 17:36:04 GMT Received: by mail-control.mail.uu.net id QQjsha06389 for mpls-outgoing; Tue, 5 Dec 2000 17:35:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsha06352 for ; Tue, 5 Dec 2000 17:35:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsha19023 for ; Tue, 5 Dec 2000 17:33:25 GMT Received: from server.nayna.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: node-64-145-162-227.dslspeed.zyan.com [64.145.162.227]) id QQjsha10628 for ; Tue, 5 Dec 2000 17:33:24 GMT Received: from nayna.com (sonicwall [64.145.162.226]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id JAA19370; Tue, 5 Dec 2000 09:33:14 -0800 X-Authentication-Warning: server.nayna.com: Host sonicwall [64.145.162.226] claimed to be nayna.com Message-ID: <3A2D27B5.7050906@nayna.com> Date: Tue, 05 Dec 2000 09:36:53 -0800 From: Sudheer Dharanikota User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: George Swallow CC: iesg@ietf.org, mpls@UU.NET Subject: Re: RSVP-TE Last Call References: <200012042202.RAA25909@lir.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Currently we are working only on the intra-area implications. I would assume there will be many changes needed to the signaling protocols for inter-area TE. What will we do about these changes if we send the RSVP-TE draft to final call? - sudheer George Swallow wrote: > RSVP-TE defines mechanisms for local repair during a failure. When > such a repair occurs, it would be appropriate for this to be conveyed > via an error message. An error value should be added to the "Notify > Error Code" with the meaning "Tunnel locally repaired". > > Several small edits for clarity were suggested out of the > interoperability testing that occurred at UNH. Also a > number of typos and other have been pointed > out. I would I believe these should be incorporated before > publication as an RFC. > > ....George > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Dec 5 12:37:47 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20279 for ; Tue, 5 Dec 2000 12:37:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsha28135; Tue, 5 Dec 2000 17:36:23 GMT Received: by mail-control.mail.uu.net id QQjsha06468 for mpls-outgoing; Tue, 5 Dec 2000 17:35:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsha06427 for ; Tue, 5 Dec 2000 17:35:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsha12118 for ; Tue, 5 Dec 2000 17:33:08 GMT Received: from mailbox.photonex.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.100.64.227]) id QQjsha22042 for ; Tue, 5 Dec 2000 17:33:08 GMT Received: from PEAR.photonex.com ([192.168.1.57]) by mailbox.photonex.com (Switch-2.0.6/Switch-2.0.6) with ESMTP id eB5HVlX29759; Tue, 5 Dec 2000 12:31:47 -0500 (EST) Message-Id: <5.0.0.25.2.20001205123231.00af0950@mailbox> X-Sender: fredette@mailbox X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 05 Dec 2000 12:33:23 -0500 To: David Charlap From: "Andre N. Fredette" Subject: Re: MPLS and fragmentation.. Cc: mpls uunet In-Reply-To: <3A2D0F07.35070595@marconi.com> References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9ACA@BBY1EXM01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:51 AM 12/5/2000 -0500, David Charlap wrote: >Shahram Davari wrote: > > > > It is possible to do fragmentation in MPLS layer. ... > >Yes, but it is a bad idea if your LSPs are not using best-effort levels >of QoS. > >Fragmentation causes a packet to be forwarded via a router's slow-path. This is not always the case. >It also increases the amount of data in the stream. Both of which can >cause otherwise-compliant data to violate the signalled QoS contract. > >The only way to avoid this is to have the ingress router do all >fragmentation (and possibly subsequent traffic shaping) before injecting >the packets into the LSP. > >-- David From owner-mpls@UU.NET Tue Dec 5 12:44:01 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21317 for ; Tue, 5 Dec 2000 12:44:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsha26240; Tue, 5 Dec 2000 17:42:39 GMT Received: by mail-control.mail.uu.net id QQjsha07602 for mpls-outgoing; Tue, 5 Dec 2000 17:42:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsha07584 for ; Tue, 5 Dec 2000 17:41:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsha06412 for ; Tue, 5 Dec 2000 17:40:56 GMT Received: from mailbox.photonex.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.100.64.227]) id QQjsha02870 for ; Tue, 5 Dec 2000 17:40:55 GMT Received: from PEAR.photonex.com ([192.168.1.57]) by mailbox.photonex.com (Switch-2.0.6/Switch-2.0.6) with ESMTP id eB5HdRX00014; Tue, 5 Dec 2000 12:39:27 -0500 (EST) Message-Id: <5.0.0.25.2.20001205123335.03031eb0@mailbox> X-Sender: fredette@mailbox X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 05 Dec 2000 12:41:03 -0500 To: Shahram Davari From: "Andre N. Fredette" Subject: RE: MPLS and fragmentation.. Cc: mpls uunet In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6010C9ACA@BBY1EXM01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Fragmentation in the MPLS layer presumes you know that the packets are IP packets. This is probably the case, but not guaranteed. Andre At 05:06 AM 12/5/2000 -0800, Shahram Davari wrote: >Hi, > >It is possible to do fragmentation in MPLS layer. Please check section 3 of: > >http://www.ietf.org/internet-drafts/draft-ietf-mpls-label-encaps-08.txt > > > "If the LSR chooses not to discard a labeled IPv4 datagram which is > too big, or if the DF bit is set in that datagram, then it MUST > execute the following algorithm: > > 1. Strip off the label stack entries to obtain the IP datagram. > > 2. Let N be the number of bytes in the label stack (i.e, 4 times > the number of label stack entries). > > 3. If the IP datagram does NOT have the "Don't Fragment" bit set > in its IP header: > > a. convert it into fragments, each of which MUST be at least > N bytes less than the Effective Maximum Frame Payload > Size. > > b. Prepend each fragment with the same label header that > would have been on the original datagram had > fragmentation not been necessary. > > c. Forward the fragments " > > >Yours, >-Shahram > > > -----Original Message----- > > From: Ben Black [mailto:ben@layer8.net] > > Sent: Monday, December 04, 2000 3:07 PM > > To: Wilder, David > > Cc: 'Faisal S. Naik'; mpls uunet; soumen@sasken.com > > Subject: Re: MPLS and fragmentation.. > > > > > > it is not possible to exceed the MTU (hence the name). the MTU > > for a path will be less than the MTU of the media carrying the path. > > exactly how much less depends on how many labels are stacked, how > > the encapsulation for a given media is implemented, etc. however, > > once an LSP is established, its MTU *should* be known (barring > > oddities when the LSP MTU changes during a failure or other > > re-routing event). > > > > so, faisal is correct: all fragmentation should occur outside the MPLS > > domain. > > > > > > ben > > > > On Mon, Dec 04, 2000 at 03:02:20PM -0500, Wilder, David wrote: > > > This is true; IP fragmentation is done by IP before > > entering the MPLS > > > domain. However, there are case where adding the 4 byte > > label is going to > > > cause the packet to now exceed the max mtu size. Then one > > must look at how > > > to handle that situation i.e. fragment, discard or do nothing. > > > > > > Dave > > > > > > -----Original Message----- > > > From: Faisal S. Naik [mailto:faisal2@hamdard.net.pk] > > > Sent: Monday, December 04, 2000 2:08 PM > > > To: mpls uunet > > > Cc: soumen@sasken.com > > > Subject: Re: MPLS and fragmentation.. > > > > > > > > > hello soumen, > > > Isnt this Ip fragmentation a part of the router before the > > packet enters the > > > MPLS domain. Within the domain, there is only the label > > swapping mechanism > > > that is working, with nothing to mention about the > > fragmentation part. > > > Esp in cases of IPv6 fragmentation is not at all allowed, > > for exceptional > > > cases, extended headers of IPv6 are used. > > > Am i right Nisar saheb :) > > > Regards, > > > Faisal Naik > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Tue Dec 5 13:22:46 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29791 for ; Tue, 5 Dec 2000 13:22:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjshd10839; Tue, 5 Dec 2000 18:21:24 GMT Received: by mail-control.mail.uu.net id QQjshd25180 for mpls-outgoing; Tue, 5 Dec 2000 18:20:47 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjshd25175 for ; Tue, 5 Dec 2000 18:20:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjshd07941 for ; Tue, 5 Dec 2000 18:17:50 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjshd21450 for ; Tue, 5 Dec 2000 18:17:50 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA01532 for mpls@uu.net; Tue, 5 Dec 2000 13:17:49 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjshd24940 for ; Tue, 5 Dec 2000 18:17:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjshc29265 for ; Tue, 5 Dec 2000 18:14:43 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjshc20937 for ; Tue, 5 Dec 2000 18:14:43 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 NAA13312; Tue, 5 Dec 2000 13:14:42 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA16847; Tue, 5 Dec 2000 12:58:57 -0500 (EST) Message-Id: <200012051758.MAA16847@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: Sudheer Dharanikota cc: George Swallow , iesg@ietf.org, mpls@UU.NET, swallow@cisco.com Subject: Re: RSVP-TE Last Call In-reply-to: Your message of "Tue, 05 Dec 2000 09:36:53 PST." <3A2D27B5.7050906@nayna.com> Date: Tue, 05 Dec 2000 12:58:57 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk It is completely normal to revise spec as they are expanded to cover new functionality. We need to get the base protocol standardized before we start on extensions. ...George p.s. The IESG last call ended yesterday. ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Dec 5 13:48:56 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08799 for ; Tue, 5 Dec 2000 13:48:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjshf07031; Tue, 5 Dec 2000 18:47:33 GMT Received: by mail-control.mail.uu.net id QQjshf27890 for mpls-outgoing; Tue, 5 Dec 2000 18:46:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjshf27878 for ; Tue, 5 Dec 2000 18:46:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjshf02601 for ; Tue, 5 Dec 2000 18:45:20 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjshf03020 for ; Tue, 5 Dec 2000 18:45:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA04584 for mpls@uu.net; Tue, 5 Dec 2000 13:45:19 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjshe27362 for ; Tue, 5 Dec 2000 18:44:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjshe18175 for ; Tue, 5 Dec 2000 18:44:21 GMT Received: from procyon.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjshe14565 for ; Tue, 5 Dec 2000 18:44:20 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id KAA14659 for ; Tue, 5 Dec 2000 10:44:15 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 10:44:16 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9ACC@BBY1EXM01> From: Shahram Davari To: "'mpls@uu.net'" Subject: drat-martini-l2circuit-enacap/trans-mpls Date: Tue, 5 Dec 2000 10:44:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have some questions from the authors of these drafts. 1) Section 5.2.1 of the Encap draft says: "A router that does not support transport of OAM cells MUST discard incoming MPLS frames on an ATM VC LSP that contain an ATM cell with the high-order bit of the PTI set to 1". Since in the MPLS network, only the ingress LSR and egress LSR are ware of the existence of OAM cells, and since the egress LSR does not need to do any thing special for the received OAM cells from the user data cells, I assume by "router" the authors mean ingress LSR. If so then why does it says "incoming MPLS frames"? 2) Section 4.2.1 of the Trans draft says: "A router that does not support transport of ATM cells MUST discard incoming MPLS frames on an ATM VC LSP that contain a control word with the T bit set. This section looks very similar to section 5.2.1 of the Encap draft, while this specific sentence is completely different. Is there a mistake or it is correct? If it is correct then why is this subject in the OAM section? Sine the sentence is talking about received MPLS frames, it seems that it is talking about an egress LSR, but why should an egress LSR that can't support ATM distribute the VC label in the first place? 3) Section 5.2.1 of Encap draft and section 4.2.1 of Trans draft say: "The LSR MAY optionally be configured to periodically generate F5 end-to-end loop back OAM cells on a VC. ... If the LSR fails to receive a response to an F5 end-to-end loop back OAM cell for a pre-defined period of time it MUST withdraw the label mapping for the VC." Is this talking about ingress LSR or egress LSR? 4) Section 5.2.1 of Encap draft and section 4.2.1 of Trans draft say: "If an ingress LSR receives an AIS F5 OAM cell, fails to receive a pre-defined number of the End-to-End loop OAM cells, or a physical interface goes down, it MUST withdraw the label mappings for all VCs associated with the failure. When a VC label mapping is withdrawn, the egress LSR SHOULD generate AIS F5 OAM cells on the VC associated with the withdrawn label mapping. " I always thought that LDP label withdrawal is initiated from downstream (egress). Could you please explain how the ingress LSR can withdraw a label that doesn't belong to it? 5) Section 5.2.1 of Encap draft says: "A router that supports transport of OAM cells MUST follow the procedures outlined in [7] section 8 for mode 0 only" I think it needs to be mentioned that performance OAM cells can't be used with the AAL5 based transmission (due to possible displacement). Regards, Shahram Davari Systems Engineer Product Research Group PMC-Sierra, Inc. (Ottawa) Phone: (613) 271-4018 Fax: (613) 271-7007 From owner-mpls@UU.NET Tue Dec 5 14:07:47 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15352 for ; Tue, 5 Dec 2000 14:07:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjshg15946; Tue, 5 Dec 2000 19:06:26 GMT Received: by mail-control.mail.uu.net id QQjshg10974 for mpls-outgoing; Tue, 5 Dec 2000 19:05:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjshg10959 for ; Tue, 5 Dec 2000 19:05:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjshg21619 for ; Tue, 5 Dec 2000 19:04:35 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjshg13075 for ; Tue, 5 Dec 2000 19:04: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 LAA15655 for ; Tue, 5 Dec 2000 11:04:31 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA04641 for mpls@uu.net; Tue, 5 Dec 2000 14:04:28 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjshe26384 for ; Tue, 5 Dec 2000 18:33:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjshe20186 for ; Tue, 5 Dec 2000 18:31:47 GMT Received: from tristero.cryptocourier.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQjshe25907 for ; Tue, 5 Dec 2000 18:31:46 GMT Received: (qmail 20870 invoked from network); 5 Dec 2000 18:35:14 -0000 Received: from roark.layer8.net (192.168.69.11) by tristero.cryptocourier.com with SMTP; 5 Dec 2000 18:35:14 -0000 Received: by roark.layer8.net (sSMTP sendmail emulation); Tue, 5 Dec 2000 10:20:20 -0800 Date: Tue, 5 Dec 2000 10:20:20 -0800 From: Ben Black To: Hendrik Visage Cc: David Charlap , mpls uunet Subject: Re: MPLS and fragmentation.. Message-ID: <20001205102020.A1505@layer8.net> References: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com> <3A2BFB48.AAA7DABE@marconi.com> <20001205133445.B11378@hvs.envisage.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001205133445.B11378@hvs.envisage.co.za>; from hvisage@envisage.co.za on Tue, Dec 05, 2000 at 01:34:45PM +0200 Sender: owner-mpls@UU.NET Precedence: bulk On Tue, Dec 05, 2000 at 01:34:45PM +0200, Hendrik Visage wrote: > > The problem starts with some very famous (but perhaps lesser loved by > the techies) OSes that doesn't do the Path MTU discovery correctly, > which then get's totally confused, and we are having another set of problems > to debug with the clients that were promised a pink sun, purple moons and > stars with a dash of green.... > path mtu detection is not relevant how endpoints of an LSP determine the mtu of that LSP. ben -- what great thing would you attempt if you knew you could not fail? From owner-mpls@UU.NET Tue Dec 5 15:04:30 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04810 for ; Tue, 5 Dec 2000 15:04:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjshk27075; Tue, 5 Dec 2000 20:03:09 GMT Received: by mail-control.mail.uu.net id QQjshk23852 for mpls-outgoing; Tue, 5 Dec 2000 20:02:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjshk23845 for ; Tue, 5 Dec 2000 20:02:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjshk12868 for ; Tue, 5 Dec 2000 20:01:50 GMT From: Keith.Schuettpelz@go.ecitele.com Received: from mizar.ftl.telematics.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.telematics.com [147.137.1.7]) id QQjshk16822 for ; Tue, 5 Dec 2000 20:01:50 GMT Received: from ussmtp01.ftl.telematics.com (ussmtp01 [147.137.15.41]) by mizar.ftl.telematics.com (8.9.1/8.9.1) with SMTP id PAA11386 for ; Tue, 5 Dec 2000 15:01:11 -0500 (EST) Received: by ussmtp01.ftl.telematics.com(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 852569AC.006E0DE8 ; Tue, 5 Dec 2000 15:02:05 -0500 X-Lotus-FromDomain: ECI TELECOM To: mpls@UU.NET Message-ID: <852569AC.006E0CA8.00@ussmtp01.ftl.telematics.com> Date: Tue, 5 Dec 2000 15:03:26 -0500 Subject: Re: MPLS and fragmentation Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk The question at hand appears to be,,, How does the ingress router endpoint of an LSP established via CR-LDP determine the mtu of that LSP? Could one of the CR-LDP draft authors please comment on this issue? Keith From owner-mpls@UU.NET Tue Dec 5 15:08:54 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06183 for ; Tue, 5 Dec 2000 15:08:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjshk29575; Tue, 5 Dec 2000 20:07:33 GMT Received: by mail-control.mail.uu.net id QQjshk29296 for mpls-outgoing; Tue, 5 Dec 2000 20:06:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjshk29287 for ; Tue, 5 Dec 2000 20:06:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjshk13050 for ; Tue, 5 Dec 2000 20:05:29 GMT Received: from qtech1.quarrytech.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: email.quarrytech.com [4.17.144.4]) id QQjshk24748 for ; Tue, 5 Dec 2000 20:05:29 GMT Received: from [10.1.3.129] (10.1.3.129 [10.1.3.129]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WMHHB9J0; Tue, 5 Dec 2000 15:00:43 -0500 Mime-Version: 1.0 X-Sender: skohalmi@10.1.1.249 Message-Id: In-Reply-To: <3A2D0F07.35070595@marconi.com> References: <9DC5E2ABE65BD54CA9088DA3194461D6010C9ACA@BBY1EXM01> <3A2D0F07.35070595@marconi.com> Date: Tue, 5 Dec 2000 15:05:22 -0500 To: David Charlap , mpls uunet From: Steve Kohalmi Subject: Re: MPLS and fragmentation.. Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-mpls@UU.NET Precedence: bulk At 10:51 AM -0500 12/5/00, David Charlap wrote: >Shahram Davari wrote: > > > > It is possible to do fragmentation in MPLS layer. ... > >Yes, but it is a bad idea if your LSPs are not using best-effort levels >of QoS. > >Fragmentation causes a packet to be forwarded via a router's slow-path. That used to be true. But many new routers with ASIC and network processor assistance can do fragmentation at line speed. >It also increases the amount of data in the stream. Both of which can >cause otherwise-compliant data to violate the signalled QoS contract. > >The only way to avoid this is to have the ingress router do all >fragmentation (and possibly subsequent traffic shaping) before injecting >the packets into the LSP. > >-- David From owner-mpls@UU.NET Tue Dec 5 23:58:48 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11123 for ; Tue, 5 Dec 2000 23:58:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsit25277; Wed, 6 Dec 2000 04:57:28 GMT Received: by mail-control.mail.uu.net id QQjsit01059 for mpls-outgoing; Wed, 6 Dec 2000 04:56:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsit01048 for ; Wed, 6 Dec 2000 04:56:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsit10209 for ; Wed, 6 Dec 2000 04:56:44 GMT Received: from hvs.envisage.co.za by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hvs.envisage.co.za [196.36.168.58]) id QQjsit16178 for ; Wed, 6 Dec 2000 04:56:41 GMT Received: (from hvisage@localhost) by hvs.envisage.co.za (8.10.1/8.10.1) id eB64uTw12133; Wed, 6 Dec 2000 06:56:29 +0200 Date: Wed, 6 Dec 2000 06:56:29 +0200 From: Hendrik Visage To: David Charlap Cc: mpls uunet Subject: Re: MPLS and fragmentation.. Message-ID: <20001206065629.C10441@hvs.envisage.co.za> References: <5B38C8A7BD6AD311A1BC009027B6C22401F53DAF@pine.sycamorenet.com> <3A2BFB48.AAA7DABE@marconi.com> <20001205133445.B11378@hvs.envisage.co.za> <3A2D1132.3595A3F1@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3A2D1132.3595A3F1@marconi.com>; from david.charlap@marconi.com on Tue, Dec 05, 2000 at 11:00:50AM -0500 Sender: owner-mpls@UU.NET Precedence: bulk On Tue, Dec 05, 2000 at 11:00:50AM -0500, David Charlap wrote: > > The problem starts with some very famous (but perhaps lesser loved by > > the techies) OSes that doesn't do the Path MTU discovery correctly, > > This is irrelevant. PMTU Discovery is not used in LSP setup. Which I do agree with. The problem that I thought was asked, and which we would like to see if or how it will/might be addressed, or if it's just ignored. I actually wasn't thinking about the setup of the MTU size (which I assumed to be transparently done by MPLS...) however, I was more interested to know if MPLS would somehow present a solution in the cases where the DF bit is set, and the packet is just little bigger than the MTU by the size of the MPLS labels... This will be an issue if it's not provided, especially with the people using those famous OSes that doesn't do the correct PMTU :( > Once the LSP is established, the ingress router should fragment packets > that are too large (or reject them if the DF bit is set.) > > > which then get's totally confused, and we are having another set of > > problems to debug with the clients that were promised a pink sun, > > purple moons and stars with a dash of green.... > > This is the exact same problem you have without MPLS. The only thing > that might possible change is the IP address of the router that's > dropping the non-compliant packets. > > I'm sorry if you were under the impression that MPLS will eliminate the > needs for clients to have a clue about MTU values. It was never > intended to do a thing about that problem, and it does not. I wasn't, as I also think the initial questioneer wasn't, we just wanted to know if/how it will/might be addressed, or just ignored... > > >> packets), then it should not be a big deal to subtract a constant > >> value from the computed MTU (to accomodate the label header) and > >> fragment to that value instead. > > > > And then the famous OS just goes west, after giving the client a set > > of fingers to choose from... > > What the heck are you talking about? > > If your client has a broken MTU discovery, it will remain broken with or > without MPLS running in the core of the network. Thanx, which is the case with some of the famous OSes :( > > > It's a serious issue for us, where we've seen IPSec and other tunnel > > solutions giving more trouble than what's it worth. > > > > And BTW, have I yet mentioned the impact this might have on > > transparent caching solutions that ISPs have in place?? > > If you want to discuss something other than MPLS, please take it to > another list. See it in the context of the PMTU discovery that's semi broken on certain OSes... > > -- David Hope it calmed you. -- ------------------------ Hendrik Visage hvisage@envisage.co.za From owner-mpls@UU.NET Wed Dec 6 00:44:06 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27362 for ; Wed, 6 Dec 2000 00:44:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsiw17280; Wed, 6 Dec 2000 05:42:43 GMT Received: by mail-control.mail.uu.net id QQjsiw17699 for mpls-outgoing; Wed, 6 Dec 2000 05:42:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsiw17688 for ; Wed, 6 Dec 2000 05:42:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsiw20001 for ; Wed, 6 Dec 2000 05:41:39 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjsiw01233 for ; Wed, 6 Dec 2000 05:41:39 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id AAA17976 for mpls@uu.net; Wed, 6 Dec 2000 00:41:39 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsiw17434 for ; Wed, 6 Dec 2000 05:41:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsiw25846; Wed, 6 Dec 2000 05:40:19 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: flipper.cisco.com [171.69.25.141]) id QQjsiw29003; Wed, 6 Dec 2000 05:40:19 GMT Received: from p7020-img-nt.ietf.org (fred-hm-dhcp3.cisco.com [171.69.128.118]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id VAA15247; Tue, 5 Dec 2000 21:39:46 -0800 (PST) Message-Id: <5.0.2.1.2.20001205213648.028239a0@flipper.cisco.com> X-Sender: fred@flipper.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 X-Priority: 1 (Highest) Date: Tue, 05 Dec 2000 21:39:45 -0800 To: mpls@UU.NET, Routing-discussion@ietf.org, ip-optical@lists.bell-labs.com, te-wg@UU.NET, ptrings@external.cisco.com, nbvpn@bbo.com From: Fred Baker Subject: Resend with correct addresses: Note from the volume cabal for ietf-announce (and other lists) Cc: Steve Coya Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk This note will be sent to ietf-announce in the morning; I am sending it to you now as it is long overdue and you especially need to know. Last week the IETF chair sent out a message informing the community of some plans to improve the organization of some significant work going on in the IETF on "sub-ip" technologies. This potential re-organization affects a number of existing and proposed working groups, including MPLS, IPO, TE, IoPTR, CEOT, and PPVPN (previously NBVPN). Others may be added, or some removed, as the scope and direction solidify. It also proposes the creation of an additional working group, previously known as "CoMa" and renamed to "CCAMP" (see below) to unify the architecture and protocol work for the control and measurement plane. This note is to bring you up to date on where we stand on the planning and logistics for these efforts. The process is ongoing and the details and implications will become more clear over the next week. The IESG will of course be open to community input on the scope and direction of the work in the various groups and will fine tune the WG charters as appropriate. Here are some specific points we would like to emphasize. - while a number of proposed WG charters (and re-charters) are out for community review, none of them has been completely finalized, nor has mapping of various drafts to working groups been completed. It is particularly important to note that at least one of the new proposed charters (MPLS) was accidentally and prematurely posted on the IETF web page. We emphasize that this is *not* necessarily the final charter; a number of questions of scope and milestones are still open and it is possible that some fine tuning of charter is still needed. - Chairs are not finalized for all of the working groups and there are likely to be some reshufflings. Also, we have not selected chairs for the proposed CCAMP working group. In the interim the WG will be chaired by two area directors. The IESG is aggressively looking at candidates and we expect to have permanent chairs well soon after the after San Diego, but in any case well before the Minneapolis meeting. - The effort crosses a number of existing IETF areas. We are therefore going to form a "directorate", consisting of the IESG area directors of the affected areas (OPS, RTG, INT, TSV), and the chairs of the affected working groups and BoFs. This group will have an initial meeting on Sunday night before the IETF in San Diego. As are other directorates, this is not an open group, and exists to advise the area directors as opposed to doing technical work which as always goes on in the working groups. - We have received feedback that the selection of the acronym "CoMA" for the Control and Measurement work was perhaps unfortunate, as it brought the metaphor of "going to sleep" into prominence. We therefore propose instead the acronym "CCAMP", to stand for "Common Control and Measurement Protocols". - While we appreciate the desire for authors of internet drafts to be able to target their efforts and attention to a specific working group, we do not believe we have full enough community consensus on the architectural boundaries and direction to do so at this moment. Therefore, assignment of Internet Drafts to Working Groups will happen after the San Diego meeting with input from WGs and community. It is likely of course, that some drafts will not be progressed, or be combined with others during this process. For now we are asking the existing chairs of the WGs and BOFs to make up their agendas and provide time to discuss the IDs as they were planning to. - The Monday 9:00-11:30 MPLS WG meeting slot will be subdivided into two slots. The first hour will be a joint session of the MPLS WG and a CCAMP Bof, to be chaired by the interim CCAMP chairs. There will be one agenda item for this meeting slot - to discuss the proposed scope and architectural direction for the control and measurement plane work and solicit feedback and ideas from the community. We encourage all WG members with an interest in the overall architecture and direction of the control and measurement plane work to attend. From 10:00-11:30, the MPLS Working Group, chaired by its current chairs, will have its normal meeting, discussing those drafts which continue to be in its purview. More to come as we move forward. Stay tuned. Feedback is solicited and welcome, either through the working group mailing lists (yes we are reading the lists) or directly to the IESG if you deem appropriate. From owner-mpls@UU.NET Wed Dec 6 02:17:06 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12936 for ; Wed, 6 Dec 2000 02:17:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjd00493; Wed, 6 Dec 2000 07:15:44 GMT Received: by mail-control.mail.uu.net id QQjsjd21158 for mpls-outgoing; Wed, 6 Dec 2000 07:15:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsjd21043 for ; Wed, 6 Dec 2000 07:15:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsjc16485 for ; Wed, 6 Dec 2000 07:14:52 GMT Received: from chonnam.chonnam.ac.kr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: chonnam.chonnam.ac.kr [168.131.33.5]) id QQjsjc17372 for ; Wed, 6 Dec 2000 07:14:50 GMT Received: from yojiny (pc85079.chonnam.ac.kr [168.131.85.79] (may be forged)) by chonnam.chonnam.ac.kr (8.10.0/8.10.0) with SMTP id eB66vHf20594; Wed, 6 Dec 2000 15:57:17 +0900 Message-ID: <002701c05f54$81b22040$4f5583a8@chonnam.ac.kr> Reply-To: "Yang Yo-Jin" From: "Yang Yo-Jin" To: "Gabor Korossy \(ETH\)" Cc: References: Subject: Re: in topology-driven how is ospf work? Date: Wed, 6 Dec 2000 16:16:50 +0900 Organization: Univ. MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id CAA12936 Hi Gabor, as i knew, in topology-driven LSR have Label that was allocate all path, in traffic-driven LSR allocate Label to required path or loaded path more than some point determined by administrator. and in MPLS, one of most important thing is to reduce label. but after seeing your mail, as i understand, today all MPLS router allocate Label to all possible path. in that case, LSR have big overhead to manage to Label that was not referred. am i right? I appreciate your thought on this matter. regards / yojiny ----- Original Message ----- From: "Gabor Korossy (ETH)" To: "'Yang Yo-Jin'" Cc: Sent: Tuesday, December 05, 2000 11:29 PM Subject: RE: in topology-driven how is ospf work? > Hi Vojiny, > > today the traffic driven MPLS is basicly non-existing (anyone contradicting?). > All implementations are based on the topology-driven scheme. > Routing protocols however work the same way in MPLS regardless whether it's > topology or traffic driven. The information carried is routing information and > is independent from MPLS. > > In case you want to use the traffic engineering extensions then those > extensions are also carried, again regardless whether it's topology > or traffic driven. > > regards / Gabor > > > > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner- > > mpls@UU.NET]On Behalf Of yojiny > > Sent: Monday, December 04, 2000 8:58 AM > > To: mpls@UU.NET > > Subject: in topology-driven how is ospf work? > > > > > > I have a question. > > I wnat to know difference fo funtction fo ospf in topology-driven and > > traffic-driven? > > and what informaton is carred by routing protocol in two different method? > > > > thanks in advance. > > > > yang yojin. > > I > > > > > From owner-mpls@UU.NET Wed Dec 6 02:29:26 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16714 for ; Wed, 6 Dec 2000 02:29:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjd06144; Wed, 6 Dec 2000 07:28:02 GMT Received: by mail-control.mail.uu.net id QQjsjd22690 for mpls-outgoing; Wed, 6 Dec 2000 07:27:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsjd22674 for ; Wed, 6 Dec 2000 07:27:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsjd22546 for ; Wed, 6 Dec 2000 07:26:31 GMT From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjsjd14274 for ; Wed, 6 Dec 2000 07:26:15 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id QAA13480; Wed, 6 Dec 2000 16:26:45 +0900 (KST) X-OpenMail-Hops: 2 Date: Wed, 6 Dec 2000 16:25:58 +0900 Message-Id: In-Reply-To: Subject: (Reply) MIME-Version: 1.0 TO: mpls@UU.NET, manikv@hclt.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Wed, 6 Dec 2000 16:22:14 +0900" ;Modification-Date="Wed, 6 Dec 2000 16:25:47 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi manik, You need to drop the packet. For more infromation pls go thorugh the section "3.18. Invalid Incoming Labels" in "draft-ietf-mpls-arch-07.txt" Regards, Seenu Samsung India Software Operations Level 7, Prestige Meridian - II M.G.Road, Bangalore, India. Tel: +91-80-558 1281 ext: 268 ============================= Hi all, I am working on MPLS protocol implementation. I have a doubt on MPLS forwarding process. If I received the labeled packet which does not have the entry Label Information Table (I mean does not have the outgoing label entry).. What I have to DO? 1. Do I have to drop the packet 2. Do I have to strip of the Shim header and go for conventional IP routing. Thanks in advance, Manikandan.V ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Wed Dec 6 04:29:57 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14113 for ; Wed, 6 Dec 2000 04:29:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjl06624; Wed, 6 Dec 2000 09:28:36 GMT Received: by mail-control.mail.uu.net id QQjsjl29376 for mpls-outgoing; Wed, 6 Dec 2000 09:28:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsjl29355 for ; Wed, 6 Dec 2000 09:28:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsjl07028 for ; Wed, 6 Dec 2000 09:27:33 GMT Received: from red.gdansk.sprint.pl by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.gdansk.sprint.pl [195.116.73.86]) id QQjsjl05049 for ; Wed, 6 Dec 2000 09:27:23 GMT Received: from localhost (IDENT:maks@localhost [127.0.0.1]) by red.gdansk.sprint.pl (8.10.2/8.10.2) with ESMTP id eB69R4a06639 for ; Wed, 6 Dec 2000 10:27:10 +0100 Date: Wed, 6 Dec 2000 10:27:04 +0100 (CET) From: Maksymilian Milkowski To: mpls@UU.NET Subject: difference? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi all, is there any difference between 'label binding' and 'label mapping' ? Thank you in advance, Maksymilian Milkowski From owner-mpls@UU.NET Wed Dec 6 04:38:29 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16793 for ; Wed, 6 Dec 2000 04:38:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjm11213; Wed, 6 Dec 2000 09:37:08 GMT Received: by mail-control.mail.uu.net id QQjsjm00388 for mpls-outgoing; Wed, 6 Dec 2000 09:36:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsjm00371 for ; Wed, 6 Dec 2000 09:36:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsjm06080 for ; Wed, 6 Dec 2000 09:36:11 GMT From: seenu@samsung.co.kr Received: from omail01.samsung.co.kr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjsjm09943 for ; Wed, 6 Dec 2000 09:36:10 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id SAA01636; Wed, 6 Dec 2000 18:37:06 +0900 (KST) X-OpenMail-Hops: 2 Date: Wed, 6 Dec 2000 18:36:20 +0900 Message-Id: In-Reply-To: Subject: (Reply) RE: (Reply) MIME-Version: 1.0 TO: mpls@UU.NET, manikv@hclt.com Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Wed, 6 Dec 2000 18:35:41 +0900" ;Modification-Date="Wed, 6 Dec 2000 18:36:08 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi manik, I would like to clarify my previous mail. If a packet comes and if it contains Invalid Incoming Label (there is no Label Entry with the "In Label" in the label switching matrix) then it should be dropped. If a packet comes and it has valid Incoming Label Entry, but no Out going label....This is the egress case...So, need to apply conventional routing on the packet. Regards, Seenu Samsung India Software Operations Level 7, Prestige Meridian - II M.G.Road, Bangalore, India. Tel: +91-80-558 1281 ext: 268 ============================= Hi manik, You need to drop the packet. For more infromation pls go thorugh the section "3.18. Invalid Incoming Labels" in "draft-ietf-mpls-arch-07.txt" Regards, Seenu Samsung India Software Operations Level 7, Prestige Meridian - II M.G.Road, Bangalore, India. Tel: +91-80-558 1281 ext: 268 ============================= Hi all, I am working on MPLS protocol implementation. I have a doubt on MPLS forwarding process. If I received the labeled packet which does not have the entry Label Information Table (I mean does not have the outgoing label entry).. What I have to DO? 1. Do I have to drop the packet 2. Do I have to strip of the Shim header and go for conventional IP routing. Thanks in advance, Manikandan.V ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Wed Dec 6 04:53:48 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20306 for ; Wed, 6 Dec 2000 04:53:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjn09496; Wed, 6 Dec 2000 09:52:27 GMT Received: by mail-control.mail.uu.net id QQjsjn02172 for mpls-outgoing; Wed, 6 Dec 2000 09:52:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsjn02164 for ; Wed, 6 Dec 2000 09:52:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsjn23969 for ; Wed, 6 Dec 2000 09:51:28 GMT From: venkir@samsung.co.kr Received: from omail01.samsung.co.kr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjsjn00542 for ; Wed, 6 Dec 2000 09:51:27 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id SAA01045; Wed, 6 Dec 2000 18:52:23 +0900 (KST) X-OpenMail-Hops: 2 Date: Wed, 6 Dec 2000 18:51:36 +0900 Message-Id: In-Reply-To: Subject: Re: difference? MIME-Version: 1.0 TO: mpls@UU.NET, maks@red.gdansk.sprint.pl Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Wed, 6 Dec 2000 18:44:58 +0900" ;Modification-Date="Wed, 6 Dec 2000 18:51:25 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi Milkowski, As for as my knowledge is concerned, label binding is nothing but allocating a label to particular LSP at a node. This is at the time of forming LSP. Label mapping is mapping a particular incoming label to a outgoing label. This is in a situation, where LSP is already existing. Regards, Reddy ----------Original Message-------- Hi all, is there any difference between 'label binding' and 'label mapping' ? Thank you in advance, Maksymilian Milkowski From owner-mpls@UU.NET Wed Dec 6 04:53:59 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20355 for ; Wed, 6 Dec 2000 04:53:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjn04562; Wed, 6 Dec 2000 09:52:38 GMT Received: by mail-control.mail.uu.net id QQjsjn02180 for mpls-outgoing; Wed, 6 Dec 2000 09:52:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsjn02166 for ; Wed, 6 Dec 2000 09:52:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsjn24437 for ; Wed, 6 Dec 2000 09:51:38 GMT Received: from csa.iisc.ernet.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjsjn00643 for ; Wed, 6 Dec 2000 09:51:31 GMT Received: from ada.csa.iisc.ernet.in (IDENT:root@ada.csa.iisc.ernet.in [144.16.67.35]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id PAA29528 for ; Wed, 6 Dec 2000 15:18:09 +0530 Received: from localhost (prasanna@localhost) by ada.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id PAA15754 for ; Wed, 6 Dec 2000 15:21:03 +0530 X-Authentication-Warning: ada.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Wed, 6 Dec 2000 15:21:03 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Question on Draft of RSVP-TE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I have read this draft. But i found it to be discussing only Objects and message processing for Path and REsv mesage. Does the format and the Processing of the PathERR or Resv ERR , Path Tear or Resv tear messages change from base protocol RSVP Please give me some info on this. Thanx in advance pras _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-_|; Wed, 6 Dec 2000 04:56:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjn05441; Wed, 6 Dec 2000 09:54:47 GMT Received: by mail-control.mail.uu.net id QQjsjn02376 for mpls-outgoing; Wed, 6 Dec 2000 09:54:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsjn02350 for ; Wed, 6 Dec 2000 09:54:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsjn00207 for ; Wed, 6 Dec 2000 09:53:28 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjsjn10977 for ; Wed, 6 Dec 2000 09:53:27 GMT Received: from cirwm3nt01.nor.bt.com by gollum (local) with ESMTP; Wed, 6 Dec 2000 09:54:41 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 6 Dec 2000 09:53:13 -0000 Message-ID: To: azinin@cisco.com, xuyg@lucent.com Cc: jplang@calient.net, mpls@UU.NET, andy.bd.reid@bt.com, darren.freeland@bt.com, alan.mcguire@bt.com Subject: RE: draft-ietf-mpls-lmp-01.txt Date: Wed, 6 Dec 2000 09:53:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Alex......just catching up with mail. > I'll take the liberty to answer your questions below. > > > Jonathan, > > > Good work. I have no major concerns on other issues except the control > channel > > management. > > > First, it's not only control "channels", it's control "NETWORK". The > control > > network has many strong requirement regarding reliability, security, > performance > > and scalability. It has to be managed and operated as a "network" not a > > collection of individual control channels. > > The notion of the control channel does not substitute the notion > of the control network. In fact, the control channel between two NEs > uses the control network for transport services, i.e. LMP messages > associated with control channels and bundles are delivered in IP > packets. NH=> Yangguang is dead right here. Recall the chat you/I/Andy Reid had on Tuesday this week in the UK on this subject? The signalling-network is 'bottom-of-stack' wrt layered networks. It lives or dies in accordance with the connectivity of the duct network and the ' survivability mechanism' used to create redundancy. In typical IP networks (where control/user-planes are congruent wrt routing) the 'survivability mechanism' is effectively flooding, which boot-straps the system. In the PSTN, SS7 uses the concept of link sets.....several diversely routed 'bottom-of-stack' transport links between signalling transfer points......where if one link dies, the remainder simply carry on load sharing the signalling messages (this is their boot-strap mechanism). So the signalling (or control-plane) network is a network in its own right and must not use a the same transport/survivability network mechanisms as the user-plane....think of it as a super-resilient VPN if you like, whose design has nothing to do with any other traffic/networks, and requires special attention. > > Control channel "management" (as mechanisms used by BGP, LDP, etc.) > actually > > only provide health check of the control "session" between neighbors. > It's not > > as fast as low layer protocols. Again, the control "network" should take > care of > > all requirements and can do much better. Control channel(session) > "management" > > only serves as an add-on checking. > > In cases where the control channel spans more than one link, > the health check and survival of the control network is insured by > IGP protocols (OSPF/ISIS). NH=> Sorry, not good enough. The signalling network must be designed as a seperate entity for the OTN. See above and refer to our chat earlier this week. > In cases where LMP CC is between directly > connected nodes, LMP Hello process helps faster detection of > unreachable neighbors. > > > Regarding your statement "Each bundled link is identified as described > in > > [KRB00] and each bundled link MUST have an associated control channel". > Is this > > a product specific requirement? > > Which part are you referring to? > > > In order for LMP to be a generic protocol, as I > > have said many times, control network should be considered independent > of > > transport network. There should be no assumption of any correlation > between > > these two networks. NH=> Here we see Yangguang making the same point again. From owner-mpls@UU.NET Wed Dec 6 04:57:35 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21134 for ; Wed, 6 Dec 2000 04:57:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjn14472; Wed, 6 Dec 2000 09:56:14 GMT Received: by mail-control.mail.uu.net id QQjsjn02523 for mpls-outgoing; Wed, 6 Dec 2000 09:55:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsjn02512 for ; Wed, 6 Dec 2000 09:55:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsjn06470 for ; Wed, 6 Dec 2000 09:55:28 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjsjn08738 for ; Wed, 6 Dec 2000 09:55:27 GMT Received: from cclmsent02.lon.bt.com by gandalf (local) with ESMTP; Wed, 6 Dec 2000 09:53:20 +0000 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 6 Dec 2000 09:53:12 -0000 Message-ID: To: petera@nortelnetworks.com, mpls@UU.NET Cc: andy.bd.reid@bt.com, darren.freeland@bt.com, alan.mcguire@bt.com Subject: RE: New MPLS Charter? Date: Wed, 6 Dec 2000 09:53:03 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > I can see how a literal interpretation of item 3) could cause problems. > Being pragmatic let me suggest that we insert an indication that both > implicit > and explicit labels are part of the charter. > > I believe the literal interpretation that George is referring to is > "explicit labels" and indeed if we are limited to explicit labels GMPLS > is homeless. I am sure that is not the intention of the wording because > it clearly talks about implicit label switching like wavlength and space > so simply adding the words "implicit and explicit" should solve the > problem. NH=> Peter, Implicit and explicit labels as you call them are not at all the same thing from an architectural perspective. In 'pure' MPLS we have an enity called the shim-header. So what we are talking about here is the *user-plane* and, if it was understood better, the creation of a new layer network each time a shim (characteristic information) label header is added (I am using functional arch terminology which many manufacturers and operators are familar with). The 'implicit' labels on the other hand are actually substitutional terms which, in essence, mean nothing more than 'technology specific'.......though I know they are dressed-up in the 'Generalised MPLS' philosophy which, in its purest sense, is simply a statement of a desire to use a single control-plane over all technologies, and clearly has nothing at all to do with labels and the user-plane. I think this distinction.......ie explicit labels => user-plane, implicit labels => control-plane philosophy.....are so far removed from each other there is no relationshiop between them. Neil From owner-mpls@UU.NET Wed Dec 6 05:30:24 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28121 for ; Wed, 6 Dec 2000 05:30:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjp20326; Wed, 6 Dec 2000 10:29:04 GMT Received: by mail-control.mail.uu.net id QQjsjp18197 for mpls-outgoing; Wed, 6 Dec 2000 10:28:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsjp18182 for ; Wed, 6 Dec 2000 10:28:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsjp13585 for ; Wed, 6 Dec 2000 10:28:11 GMT Received: from csa.iisc.ernet.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjsjp19023 for ; Wed, 6 Dec 2000 10:28:08 GMT Received: from ada.csa.iisc.ernet.in (IDENT:root@ada.csa.iisc.ernet.in [144.16.67.35]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id PAA29899 for ; Wed, 6 Dec 2000 15:55:08 +0530 Received: from localhost (prasanna@localhost) by ada.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id PAA16720 for ; Wed, 6 Dec 2000 15:58:02 +0530 X-Authentication-Warning: ada.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Wed, 6 Dec 2000 15:58:02 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: HI Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk One question had been asked previosly in the maling list regarding Passing the RRO in the Path ERR and Resv ERR messages.? Is it required and if yes , then what are the resons why u need to do it.??? PLease let me know.... Thanx in advance Pras _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-_|; Wed, 6 Dec 2000 05:59:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjr09842; Wed, 6 Dec 2000 10:57:57 GMT Received: by mail-control.mail.uu.net id QQjsjr21375 for mpls-outgoing; Wed, 6 Dec 2000 10:57:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsjr21365 for ; Wed, 6 Dec 2000 10:57:36 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsjr11611 for ; Wed, 6 Dec 2000 10:57:18 GMT From: venkir@samsung.co.kr Received: from omail01.samsung.co.kr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjsjr26106 for ; Wed, 6 Dec 2000 10:57:17 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id TAA02314; Wed, 6 Dec 2000 19:58:19 +0900 (KST) X-OpenMail-Hops: 2 Date: Wed, 6 Dec 2000 19:57:33 +0900 Message-Id: In-Reply-To: Subject: (Reply) HI MIME-Version: 1.0 TO: mpls@UU.NET, prasanna@csa.iisc.ernet.in Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Wed, 6 Dec 2000 19:41:11 +0900" ;Modification-Date="Wed, 6 Dec 2000 19:57:20 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi Pras, As far as my knowledge is concerned, if RRO is there in ERR messages, Edge routers can analyse it and find out the reason for ERR messages, if ERR messages are related to routing problems. This is the only reason, i am finding for RRO in ERR messages. Regards, Reddy. ------------Original Message---------- One question had been asked previosly in the maling list regarding Passing the RRO in the Path ERR and Resv ERR messages.? Is it required and if yes , then what are the resons why u need to do it.??? PLease let me know.... Thanx in advance Pras From owner-mpls@UU.NET Wed Dec 6 06:19:14 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09308 for ; Wed, 6 Dec 2000 06:19:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjt23387; Wed, 6 Dec 2000 11:17:52 GMT Received: by mail-control.mail.uu.net id QQjsjt05489 for mpls-outgoing; Wed, 6 Dec 2000 11:17:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsjt05481 for ; Wed, 6 Dec 2000 11:17:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsjt14882 for ; Wed, 6 Dec 2000 11:17:00 GMT From: venkir@samsung.co.kr Received: from omail01.samsung.co.kr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omail01.samsung.co.kr [203.254.197.73]) id QQjsjt22222 for ; Wed, 6 Dec 2000 11:16:59 GMT Received: from localhost (root@localhost) by gp_xman. (8.8.8H1/8.8.8) with ESMTP id UAA23373; Wed, 6 Dec 2000 20:17:52 +0900 (KST) X-OpenMail-Hops: 2 Date: Wed, 6 Dec 2000 20:17:06 +0900 Message-Id: In-Reply-To: Subject: (Reply) Question on Draft of RSVP-TE MIME-Version: 1.0 TO: mpls@UU.NET, prasanna@csa.iisc.ernet.in Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="mail.txt" ;Creation-Date="Wed, 6 Dec 2000 19:57:51 +0900" ;Modification-Date="Wed, 6 Dec 2000 20:16:58 +0900" Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi Pras, You are correct only. That draft is not discussing about ERR and Tear messages. As far as my knowledge is concerned, processing of ERR messages is same as RSVP except the processing of newly introduced objects in these messages. These objects processing is same as the one for Path/Resv messages. During processing of Tear messages, we have to free that particular label, alloted. This is the extra processing rule than the normal RVSP. For that one we can add Label object in Tear messages. I think, this info. gives you some idea about ERR and Tear messages. Regards, Reddy. ----------Original Message------- I have read this draft. But i found it to be discussing only Objects and message processing for Path and REsv mesage. Does the format and the Processing of the PathERR or Resv ERR , Path Tear or Resv tear messages change from base protocol RSVP Please give me some info on this. Thanx in advance pras From owner-mpls@UU.NET Wed Dec 6 06:50:58 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16109 for ; Wed, 6 Dec 2000 06:50:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjv26426; Wed, 6 Dec 2000 11:49:35 GMT Received: by mail-control.mail.uu.net id QQjsjv07587 for mpls-outgoing; Wed, 6 Dec 2000 11:49:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsjv07567 for ; Wed, 6 Dec 2000 11:49:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsjv20044 for ; Wed, 6 Dec 2000 11:48:20 GMT Received: from wiprom2mx1.wipro.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQjsjv24364 for ; Wed, 6 Dec 2000 11:48:13 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id RAA12481 for ; Wed, 6 Dec 2000 17:25:12 GMT Received: from wipro.com ([192.168.220.54]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA6A4F for ; Wed, 6 Dec 2000 17:15:49 +0530 Message-ID: <3A2E2AB4.877F0563@wipro.com> Date: Wed, 06 Dec 2000 17:31:58 +0530 From: "Amarnath Honnavalli Anantharamaiah" X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Optional parameters in Hello message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit [1] In the hello message structure there is optional parameters field which contains the following. IPv4 Transport Address 0x0401 Configuration Sequence Number 0x0402 IPv6 Transport Address 0x0403 Can anyone tell me the use of this parameters. Especially thies IP Addresses, This will be present in the UDP header when sending this message which can be made use of this .. [2] If this IP adress in the LDP header is that to be used for communication for further session establishment on a different interface other than the one which is in the Hello adjacency, When do we have such a requirement and what will be the purpose of having different interfaces, one for keeping hello adjecency and one for session establishment. Regards Amar From owner-mpls@UU.NET Wed Dec 6 06:58:23 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17723 for ; Wed, 6 Dec 2000 06:58:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjv15679; Wed, 6 Dec 2000 11:57:01 GMT Received: by mail-control.mail.uu.net id QQjsjv08095 for mpls-outgoing; Wed, 6 Dec 2000 11:56:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsjv08089 for ; Wed, 6 Dec 2000 11:56:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsjv08037 for ; Wed, 6 Dec 2000 11:56:15 GMT Received: from falla.videotron.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: falla.videotron.net [205.151.222.106]) id QQjsjv14551 for ; Wed, 6 Dec 2000 11:56:15 GMT Received: from MartinPicard ([24.202.11.202]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with SMTP id <0G5500J1KAHNIP@falla.videotron.net> for mpls@UU.NET; Wed, 6 Dec 2000 06:56:11 -0500 (EST) Date: Wed, 06 Dec 2000 06:47:27 -0500 From: Martin Picard Subject: Re: (Reply) RE: (Reply) To: seenu@samsung.co.kr, mpls@UU.NET, manikv@hclt.com Message-id: <006801c05f7a$4f043ae0$ca0bca18@videotron.ca> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 References: X-Priority: 3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Seenu, Manik, "the only safe procedure is to discard the packet" - draft-ietf-mpls-arch-07 section 3.22 martin > Hi manik, > > I would like to clarify my previous mail. > > If a packet comes and if it contains Invalid Incoming Label (there is no Label Entry with the "In Label" in the label switching matrix) > then it should be dropped. > > If a packet comes and it has valid Incoming Label Entry, but no Out going label....This is the egress case...So, need to apply conventional routing > on the packet. > > Regards, > Seenu > Samsung India Software Operations > Level 7, Prestige Meridian - II > M.G.Road, Bangalore, India. > > Tel: +91-80-558 1281 ext: 268 > > ============================= > > Hi manik, > > You need to drop the packet. > > For more infromation pls go thorugh the section > "3.18. Invalid Incoming Labels" in "draft-ietf-mpls-arch-07.txt" > > Regards, > Seenu > Samsung India Software Operations > Level 7, Prestige Meridian - II > M.G.Road, Bangalore, India. > > Tel: +91-80-558 1281 ext: 268 > > ============================= > > Hi all, > > I am working on MPLS protocol implementation. > > I have a doubt on MPLS forwarding process. If I received the labeled packet > which does not have the entry Label Information Table (I mean does not have > the outgoing label entry).. What I have to DO? > > 1. Do I have to drop the packet > 2. Do I have to strip of the Shim header and go for conventional IP routing. > > > Thanks in advance, > Manikandan.V > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Wed Dec 6 07:00:07 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18115 for ; Wed, 6 Dec 2000 07:00:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjv18475; Wed, 6 Dec 2000 11:58:45 GMT Received: by mail-control.mail.uu.net id QQjsjv08147 for mpls-outgoing; Wed, 6 Dec 2000 11:58:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsjv08134 for ; Wed, 6 Dec 2000 11:57:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsjv18745 for ; Wed, 6 Dec 2000 11:57:35 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjsjv02397 for ; Wed, 6 Dec 2000 11:57:35 GMT Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP; Wed, 6 Dec 2000 11:56:41 +0000 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 6 Dec 2000 11:56:24 -0000 Message-ID: To: satoru@japan-telecom.co.jp, francis.arts@alcatel.be Cc: mpls@UU.NET, mpls-wg@janog.gr.jp Subject: RE: Processing the MPLS TTL Date: Wed, 6 Dec 2000 11:56:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > Hi Francis, > Thanks for your reply. > > > Please find included some information on the question you raised: > > > > > Could somebody tell me the behavior of "ingress|egress LSR/LER" on > > > this situations? > > > > > > > ** Ingress LSR: > > In this case the ingress LSR has to use for the MPLS header a TTL that > is > > large enough to reach the egress LSR (that is, the TTL should not expire > in > > the middle of the LSP). > > > > ** Egress LSR: > > At the egress LSR the TTL in the MPLS header is not copied into the IP > header > > of the packet. Instead the TTL as is in the IP header is used. > > > > This 'TTL behavior' is -for the TTL aspect- similar to the 'TTL > behavior' for > > IP over IP tunnels as defined in section 3.1 of RFC 2003 ('IP within > IP'). > > In this case, it is right if it works as network devices. > But MPLS-LSP does not work as well as network devices. Thus basically, > MPLS TTL was set to the value of th IP TTL at the ingress LER, and > IP TTL was set to the value of MPLS TTL at the egress LSR/LER. > This is basically situations. > > But Section 2.4.3. "IP-dependent rules" was recognized that > there are situations where a network administration prefers to > decrement the IPv4 TTL by one as it traverses an MPLS domain. > As a result, the MPLS domain has two situations. > > If the MPLS domain really has two situations and be mixed, > how can the egress LSR/LER distinguish these two situations? > > I think it is desirable that these situations should be more described > by "draft-ietf-mpls-label-encaps-08.txt" > I agree completely with the sentiments expressed above......when one creates an LSP at layer N it is a new layer network in a functional arch sense. If one does not accept this then there are both potential layer violation problems (eg TTL and EXP bits), and functional handling problems (eg PHP....puts the LSP trail termination point in the wrong place for server->client adapatation processing, eg OAM and functions like prot-sw which are dependent on OAM triggers). The TTL problem are rather obvious and its impact can be easily illustrated by an example: A server layer LSP trail at level N can be many label-swapping hops (=links), but its just a single hop (= 1 link connection) in the client LSP trail at level N-1. If we try to predict the server label-swapping hops (to pre-decrement the TTL) we will have problems, ie when the LSP at level N is protection switched and the server layer LSP hop count changes. And remember, this relationship recurses to level N+1, level N+2, etc for as many times as there are nested LSPs. So, as far as I am concerned, TTL only has any meaning/significance between the LSP source point where it was generated and the LSP sink point where it is terminated at the level that the LSP exists. I have tried to point the above a few times now, and I can see others are now having the problems I expected because of a lack of functional arch thinking. neil From owner-mpls@UU.NET Wed Dec 6 07:31:33 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25028 for ; Wed, 6 Dec 2000 07:31:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjs10021; Wed, 6 Dec 2000 11:07:46 GMT Received: by mail-control.mail.uu.net id QQjsjs03521 for mpls-outgoing; Wed, 6 Dec 2000 11:07:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsjs03492 for ; Wed, 6 Dec 2000 11:07:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsjs09830 for ; Wed, 6 Dec 2000 11:06:25 GMT Received: from csa.iisc.ernet.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjsjs08082 for ; Wed, 6 Dec 2000 11:06:22 GMT Received: from ruby.csa.iisc.ernet.in (IDENT:root@ruby.csa.iisc.ernet.in [144.16.67.30]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id QAA30328 for ; Wed, 6 Dec 2000 16:33:20 +0530 Received: from localhost (ytr@localhost) by ruby.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id QAA26973 for ; Wed, 6 Dec 2000 16:36:14 +0530 X-Authentication-Warning: ruby.csa.iisc.ernet.in: ytr owned process doing -bs Date: Wed, 6 Dec 2000 16:36:13 +0530 (IST) From: Ramanjaneyulu Y T To: mpls@UU.NET Subject: Hierarchical LSP set up Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Previously i posted one question regarding this , but i didn't get any responses. Pls go through my "long" mail and kindly answer to my questions.Thanks for spending your valauble time to read my mail and answers. The following is the scenarios to establish hierarchial LSps. Method1 ------- --------- --------- | | | | | LER11 | | LER12 | | | | | --------- --------- | | . Y Z . . -------- ------- ------ T . |__X___| | | | | |____| | LER1 |-----| |-----.....|LER2 | | | | | | | -------- ------- ------ at LER1 at LER2 label look up table label look up table X -- FWD Y Z - FWD T NHLFE NHLFE Y -- PUSH Y T -- PUSH T Note: ---- PUSH y -- PUSH label Y FWD y -- check entry 'Y' at NHLFE table The output entry it having separate operations. In this case it just forwads to soecified interface in table. --- Initially there is no LSP existing between LER1 and LER2. When request comes from LER11 , PATH message is sent to LER12 . When LER12 responds with RESV message with label for previous hop.When RESV message reaches from upstream LSR to LER2 , it allocates new label and binds with label from upstream LSR and propagates RESV message to previous hop. The same process is repeated at all LSRS and LER1 also. Now LSP is established between from LER11 to LER12 through LER1 and LER2. Note that this is not hierarchical LSP. In this case , all data transfers occurs normally. Consider the following scenario. -------- --------- | | | | | LER11 | | LER12 | | | | | --------- --------- | | . Y Z . . -------- ------- ------ . |__X___| | | | | |__T_| | LER1 |-----| |-----.....|LER2 | ______| | | | | |_____ |A -------- ------- ------ | | B | . . . . | | ---------- -------- | | | | | LER 22 | | LER 21 | | | | | ---------- -------- In this scenario, we want to set up an LSP between LER21 and LER 22 through LER1 and LER 2 which is a heirarchical LSP (in the sense that the same LSP wil be used by both the traffic flows from LER 11 and LER 21) Note: ---- LER2 generates label 'C' and informs to LER1 for LER21. at LER1 at LER2 label look up table label look up table X -- FWD Y Z - FWD T A -- PUSH C , FWD Y C - FWD B NHLFE NHLFE Y -- PUSH Y T -- PUSH T B -- PUSH B If LER21 wants to establish LSP to LER22. It sends PATH request to LER22. LER22 responds to PATH message with RESV message with label for previous hop. when RESV message reaches to LER2 , it generates a new label for LER1 , LSP is already existing between LER1 and LER2. In core LSRS between LER1 and LER2 , just bypasses this message. At LER1 , it generates a new label and places PUSH LER2 label operation in newly generated label and forwards it to previous hop. My question is , how LER2 differentiate MPLS data packets whether to forward to LER12 or LER22 by seeing on top label ( here 'Z'). Method2 ------- If we establish one LSP between LER1 and LER2, then we can use this LSP to establish LER11 and LER12 as hierarchical LSPs. same way for LER21 and LER22. If this is the case at LER2 , data packet contains label stack of depth 2 . So POP top label at LER2 and based on next label one can forward the packet. But for this one is required to establish LSPs statically and those 2 nodes should know each other. But this approach is not suitable, i think , due to these constraints. During LSP establishment between LER11 and LER12 , the LER2 generates new label and informs to LER1. This is same for second LSP also. suppose LER2 generates M for LER12. The table update is as follows. at LER1 at LER2 label look up table label look up table Z - POP A -- PUSH C , FWD Y C - FWD B X -- PUSH M , FWD Y M - FWD T NHLFE NHLFE Y -- PUSH Y T -- PUSH T B -- PUSH B So at LER2 , the MPLS pkt conatins M,Z or C,Z. So by looking on tables , it learns POP top label and looks on next label. This is works fine in hierarchical environmant , but it has constraints. Questions: --------- 1. Is above methods are correct ? 2. Other than these 2 methods any other methods avaialble to achieve hierarchial LSPs ?. 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@123india.com BANGALORE - 560012 | kingytr@excite.com PH: 91 - 80 - 3092622 ( HOSTEL ) | 91 - 80 - 3092658 ( HFCL LAB ) | visit my home page:www2.csa.iisc.ernet.in/~ytr -------------------------------------------------------------------------------- From owner-mpls@UU.NET Wed Dec 6 07:33:59 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25548 for ; Wed, 6 Dec 2000 07:33:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjy28808; Wed, 6 Dec 2000 12:32:37 GMT Received: by mail-control.mail.uu.net id QQjsjy22150 for mpls-outgoing; Wed, 6 Dec 2000 12:32:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsjy22145 for ; Wed, 6 Dec 2000 12:32:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsjy00280 for ; Wed, 6 Dec 2000 12:30:41 GMT Received: from falla.videotron.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: falla.videotron.net [205.151.222.106]) id QQjsjy01498 for ; Wed, 6 Dec 2000 12:30:41 GMT Received: from MartinPicard ([24.202.11.202]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with SMTP id <0G5500JB1C34IP@falla.videotron.net> for mpls@UU.NET; Wed, 6 Dec 2000 07:30:40 -0500 (EST) Date: Wed, 06 Dec 2000 07:21:55 -0500 From: Martin Picard Subject: Re: Lack of outgoing label was Re: (Reply) RE: (Reply) To: "Manikandan.V" Cc: mpls@UU.NET Message-id: <00c001c05f7f$1fcd2fc0$ca0bca18@videotron.ca> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 References: X-Priority: 3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit What do you mean by Terminating LSR ? If you mean egress-LER, then you should not receive "labelled" packets at all for these destinations since the upstream LSR which is the penultimate hop should pop the label. If you have more than one label on the stack, as the stack depth decreases processing is the same on the top label and eventually the penultimate hop will output an unlabelled packet to the egress-LER. What do you mean by no LSP available in the domain ? Do you mean that for a particular LSR the label space is exausted and no free labels exist ? mp > Thats fine and thanks for your reply. > But, What I mean is what will be the LSR process if the processing LSR is > the Terminating LSR and after that there is no LSP available in the domain. > > Cheers, > mani > > -----Original Message----- > From: Martin Picard [mailto:mpicard@sinc.ca] > Sent: Wednesday, December 06, 2000 5:17 PM > To: seenu@samsung.co.kr; mpls@UU.NET; manikv@hclt.com > Subject: Re: (Reply) RE: (Reply) > > > Seenu, Manik, > > "the only safe procedure is to discard the packet" - > draft-ietf-mpls-arch-07 section 3.22 > > martin > > > > Hi manik, > > > > I would like to clarify my previous mail. > > > > If a packet comes and if it contains Invalid Incoming Label (there is no > Label Entry with the "In Label" in the label switching matrix) > > then it should be dropped. > > > > If a packet comes and it has valid Incoming Label Entry, but no Out going > label....This is the egress case...So, need to apply conventional routing > > on the packet. > > > > Regards, > > Seenu > > Samsung India Software Operations > > Level 7, Prestige Meridian - II > > M.G.Road, Bangalore, India. > > > > Tel: +91-80-558 1281 ext: 268 > > > > ============================= > > > > Hi manik, > > > > You need to drop the packet. > > > > For more infromation pls go thorugh the section > > "3.18. Invalid Incoming Labels" in "draft-ietf-mpls-arch-07.txt" > > > > Regards, > > Seenu > > Samsung India Software Operations > > Level 7, Prestige Meridian - II > > M.G.Road, Bangalore, India. > > > > Tel: +91-80-558 1281 ext: 268 > > > > ============================= > > > > Hi all, > > > > I am working on MPLS protocol implementation. > > > > I have a doubt on MPLS forwarding process. If I received the labeled > packet > > which does not have the entry Label Information Table (I mean does not > have > > the outgoing label entry).. What I have to DO? > > > > 1. Do I have to drop the packet > > 2. Do I have to strip of the Shim header and go for conventional IP > routing. > > > > > > Thanks in advance, > > Manikandan.V > > > > ------- > > The MPLS-OPS Mailing List > > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Wed Dec 6 07:37:10 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26424 for ; Wed, 6 Dec 2000 07:37:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsjy03414; Wed, 6 Dec 2000 12:35:48 GMT Received: by mail-control.mail.uu.net id QQjsjy22237 for mpls-outgoing; Wed, 6 Dec 2000 12:35:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsjy22228 for ; Wed, 6 Dec 2000 12:35:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsjy12350 for ; Wed, 6 Dec 2000 12:34:32 GMT Received: from beamer.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQjsjy01672 for ; Wed, 6 Dec 2000 12:34:32 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 NAA11259; Wed, 6 Dec 2000 13:33:46 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA25644; Wed, 6 Dec 2000 13:34:21 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Dec 2000 13:34:20 +0100 Message-ID: From: Heiles Juergen To: mpls@UU.NET Cc: ip-optical@lists.bell-labs.com Subject: GMPLS - Hierarchies Date: Wed, 6 Dec 2000 13:34:09 +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 draft-ietf-mpls-generalized-signaling-01 mentions in the introduction a hierachy with fiber switching at the top followed by lambda, time-slot and packet switching and clearly distinguish between these levels. I don't agree with this view that a LSP starts and ends on the same LSR type and onyl nesting of LSPs of different LSR types is possible. Take for example an optical cross-connect that switches fiber between its ports (=> fiber switch capable). The single or multiple lambdas on this fiber might be directly after the cross-connect or later combined with other signals from other fibers in a WDM system => (lambda switch capable) or a TDM technique is used to combine several of these signals to a higher bandwidth signal (e.g. going from 2.5 to 10 Gbit/s) (=> time switch capable). So a LSP that starts at LSC device ends up at a TSC device and might have a LSC device in between. Even an interchange of LSPs between packet and circuit switch capable devices is possible, take for a example circuit emulation via ATM. With circuit emulation you can also have a LSP that starts on a TSC device nested into a LSP that starts on a PSC device. A LSP represents a connection through the network/sub-network for a certain signal. This is independent of the switching technologies along the route and at the end as long as the specific signal is supported. At both ends access to the specific signal has to be provided, but it doesn't matter if e.g. a 1.5 Mbit/s signal is transported on a time-slot of a TDM system, on a single wavelength of a WDM system (not economic), over a CDMA radio system or with circuit emulation over an ATM network. The Hierarchy is defined by different signals nested into each other (client/server relationship), but not by the switching types. Regards Juergen Heiles From owner-mpls@UU.NET Wed Dec 6 08:24:11 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05356 for ; Wed, 6 Dec 2000 08:24:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskb07951; Wed, 6 Dec 2000 13:22:50 GMT Received: by mail-control.mail.uu.net id QQjskb07251 for mpls-outgoing; Wed, 6 Dec 2000 13:22:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjskb07245 for ; Wed, 6 Dec 2000 13:22:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjskb25550 for ; Wed, 6 Dec 2000 13:22:01 GMT Received: from smtp4.cluster.oleane.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp4.cluster.oleane.net [195.25.12.62]) id QQjskb07515 for ; Wed, 6 Dec 2000 13:22:00 GMT Received: from oleane (dyn-1-1-091.Vin.dialup.oleane.fr [195.25.4.91]) by smtp4.cluster.oleane.net with SMTP id eB6DLxi97963 for ; Wed, 6 Dec 2000 14:21:59 +0100 (CET) Message-ID: <00c601c05f87$d5132800$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: IP.Net call for papers Date: Wed, 6 Dec 2000 14:24:16 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C3_01C05F90.3683A3A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00C3_01C05F90.3683A3A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The dead line for the IP.Net call for papers has been postponed to = December 22nd. Get more details at: http://www.upperside.fr/baipnet.htm Due to the success of the exhibition part, the event will take place = from 19 to 22 June at the Sofitel Hotel in Paris. ------=_NextPart_000_00C3_01C05F90.3683A3A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The dead line for the IP.Net call = for papers has=20 been postponed to December 22nd.
Get more details at:
http://www.upperside.fr/baip= net.htm
Due to the success of the exhibition = part, the=20 event will take place from 19 to 22 June at the Sofitel Hotel in=20 Paris.
 
------=_NextPart_000_00C3_01C05F90.3683A3A0-- From owner-mpls@UU.NET Wed Dec 6 08:24:41 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05501 for ; Wed, 6 Dec 2000 08:24:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskb09395; Wed, 6 Dec 2000 13:23:20 GMT Received: by mail-control.mail.uu.net id QQjskb07260 for mpls-outgoing; Wed, 6 Dec 2000 13:22:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjskb07255 for ; Wed, 6 Dec 2000 13:22:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjskb07510 for ; Wed, 6 Dec 2000 13:21:38 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjskb06950 for ; Wed, 6 Dec 2000 13:21:35 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 06 Dec 2000 18:55:21 +0530 Received: from arumugamr (arumugamr.future.futsoft.com [10.0.6.51]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id eB6Ir4206871; Thu, 7 Dec 2000 00:23:04 +0530 Received: by localhost with Microsoft MAPI; Wed, 6 Dec 2000 18:42:18 +0530 Message-Id: <01C05FB4.42A47500.arumugamr@future.futsoft.com> From: Arumugam R Reply-To: "arumugamr@future.futsoft.com" To: "'Gaitonde Anandprasanna'" , "'mpls@uu.net'" Subject: RE: HI Date: Wed, 6 Dec 2000 18:42:15 +0530 Organization: FSL 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 Please refer Rsvp-Lsp-Tunnel-7 draft, wherein you will find the RRO object being omitted compared to Rsvp-Lsp-Tunnel-5 draft. Also refer the previous discussions in the mailing list. Regards Aru -------------------------------------------------------------------------------- Arumugam R Senior Software Engineer, Future Software Ltd. Chennai - 35 Phone-4330550 Ext-363 -------------------------------------------------------------------------------- -----Original Message----- From: Gaitonde Anandprasanna [SMTP:prasanna@csa.iisc.ernet.in] Sent: Wednesday, December 06, 2000 3:58 PM To: mpls@uu.net Subject: HI One question had been asked previosly in the maling list regarding Passing the RRO in the Path ERR and Resv ERR messages.? Is it required and if yes , then what are the resons why u need to do it.??? PLease let me know.... Thanx in advance Pras _____________________________ _ |ANANDPRASANNA GAITONDE | _ / )|COMP. SCIENCE & AUTOMATION |( \ / / |D-7,IISc HOSTEL | \ \ / / |INDIAN INSTITUTE OF SCIENCE| \ \ _( (_ |BANGALORE-560012. | _) )_ (((\ \>|_/->___________________<-_|; Wed, 6 Dec 2000 08:43:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskc08473; Wed, 6 Dec 2000 13:41:43 GMT Received: by mail-control.mail.uu.net id QQjskc08805 for mpls-outgoing; Wed, 6 Dec 2000 13:41:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjskc08757 for ; Wed, 6 Dec 2000 13:40:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjskc17771 for ; Wed, 6 Dec 2000 13:40:26 GMT Received: from falla.videotron.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: falla.videotron.net [205.151.222.106]) id QQjskc05292 for ; Wed, 6 Dec 2000 13:40:26 GMT Received: from MartinPicard ([24.202.11.202]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with SMTP id <0G550003VFBC8Q@falla.videotron.net> for mpls@UU.NET; Wed, 6 Dec 2000 08:40:24 -0500 (EST) Date: Wed, 06 Dec 2000 08:31:39 -0500 From: Martin Picard Subject: Re: Lack of outgoing label was Re: (Reply) RE: (Reply) To: dan martin Cc: mpls@UU.NET Message-id: <00d801c05f88$dd769120$ca0bca18@videotron.ca> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 References: X-Priority: 3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dan, The LER does not get a labelled packet. It gets an IP packet. The LSR facing the LER (called upstream LSR for that LSP), will get the labelled packet and will map the incoming label to an outgoing label of "Pop Label" which means that the next hop is the ultimate destination and in order to avoid double lookups in the LER (one for the Label and one for IP) it just strips off the label and send the packet unlabelled to the LER which will "route" the packet. Hope I am not making this worst than it really is. You can always look at mpls-arch draft section 3.16 to get it from the horse's mouth ! mp > up until you explained it, i thought i understood it. > > so the label edge router gets a labeled packet. it has no path to send it > out on. the indicator in the label says it is the last label. now it pops > off the label and routes the packet. > > what am i leaving out? > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Martin > Picard > Sent: Wednesday, December 06, 2000 7:22 AM > To: Manikandan.V > Cc: mpls@UU.NET > Subject: Re: Lack of outgoing label was Re: (Reply) RE: (Reply) > > > What do you mean by Terminating LSR ? > If you mean egress-LER, then you should not receive "labelled" packets > at all for these destinations since the upstream LSR which is the > penultimate hop should pop the label. > If you have more than one label on the stack, as the stack depth decreases > processing is the same on the top label and eventually the penultimate hop > will output an unlabelled packet to the egress-LER. > What do you mean by no LSP available in the domain ? > Do you mean that for a particular LSR the label space is exausted and > no free labels exist ? > > mp > > > > Thats fine and thanks for your reply. > > But, What I mean is what will be the LSR process if the processing LSR is > > the Terminating LSR and after that there is no LSP available in the > domain. > > > > Cheers, > > mani > > > > -----Original Message----- > > From: Martin Picard [mailto:mpicard@sinc.ca] > > Sent: Wednesday, December 06, 2000 5:17 PM > > To: seenu@samsung.co.kr; mpls@UU.NET; manikv@hclt.com > > Subject: Re: (Reply) RE: (Reply) > > > > > > Seenu, Manik, > > > > "the only safe procedure is to discard the packet" - > > draft-ietf-mpls-arch-07 section 3.22 > > > > martin > > > > > > > Hi manik, > > > > > > I would like to clarify my previous mail. > > > > > > If a packet comes and if it contains Invalid Incoming Label (there is no > > Label Entry with the "In Label" in the label switching matrix) > > > then it should be dropped. > > > > > > If a packet comes and it has valid Incoming Label Entry, but no Out > going > > label....This is the egress case...So, need to apply conventional routing > > > on the packet. > > > > > > Regards, > > > Seenu > > > Samsung India Software Operations > > > Level 7, Prestige Meridian - II > > > M.G.Road, Bangalore, India. > > > > > > Tel: +91-80-558 1281 ext: 268 > > > > > > ============================= > > > > > > Hi manik, > > > > > > You need to drop the packet. > > > > > > For more infromation pls go thorugh the section > > > "3.18. Invalid Incoming Labels" in "draft-ietf-mpls-arch-07.txt" > > > > > > Regards, > > > Seenu > > > Samsung India Software Operations > > > Level 7, Prestige Meridian - II > > > M.G.Road, Bangalore, India. > > > > > > Tel: +91-80-558 1281 ext: 268 > > > > > > ============================= > > > > > > Hi all, > > > > > > I am working on MPLS protocol implementation. > > > > > > I have a doubt on MPLS forwarding process. If I received the labeled > > packet > > > which does not have the entry Label Information Table (I mean does not > > have > > > the outgoing label entry).. What I have to DO? > > > > > > 1. Do I have to drop the packet > > > 2. Do I have to strip of the Shim header and go for conventional IP > > routing. > > > > > > > > > Thanks in advance, > > > Manikandan.V > > > > > > ------- > > > The MPLS-OPS Mailing List > > > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > > > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Wed Dec 6 09:09:36 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15464 for ; Wed, 6 Dec 2000 09:09:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjske11691; Wed, 6 Dec 2000 14:08:14 GMT Received: by mail-control.mail.uu.net id QQjske19526 for mpls-outgoing; Wed, 6 Dec 2000 14:07:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjske19446 for ; Wed, 6 Dec 2000 14:07:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjske10061 for ; Wed, 6 Dec 2000 14:06:46 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQjske20038 for ; Wed, 6 Dec 2000 14:06:45 GMT Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 6 Dec 2000 09:05:38 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YGTL2M8F; Wed, 6 Dec 2000 09:05:38 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YFZD3AD4; Wed, 6 Dec 2000 09:05:40 -0500 Message-ID: <3A2E47B1.595F5657@americasm01.nt.com> Date: Wed, 06 Dec 2000 09:05:37 -0500 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: mpls@UU.NET Subject: Re: New MPLS Charter? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit If you take a look at the actual implementations of different cross connects you will find that they have backplane control functions that look something like this: Photonic: connect(, ) TDM: connect([], [] ATM: connect(/, /) PPP LSRs connect(/, /) etc... In essense you can use a single traffic engineering implementation to control all of these devices with little changes between implementations. There is not much more of a (high level control plane) stretch from shim header switching to photonic switching than there was from shim to ATM. Infact there are a number of people that have extended PNNI so that it can control a photonic switch. Anyway I obviously disagree with you ;) but we can happily argue this next week. What I don't understand is why there was no complaining earlier this year or last year when we were first talking about this stuff. Cheers, Peter > > I can see how a literal interpretation of item 3) could cause problems. > > Being pragmatic let me suggest that we insert an indication that both > > implicit > > and explicit labels are part of the charter. > > > > I believe the literal interpretation that George is referring to is > > "explicit labels" and indeed if we are limited to explicit labels GMPLS > > is homeless. I am sure that is not the intention of the wording because > > it clearly talks about implicit label switching like wavlength and space > > so simply adding the words "implicit and explicit" should solve the > > problem. > NH=> Peter, Implicit and explicit labels as you call them are not at all > the same thing from an architectural perspective. In 'pure' MPLS we have an > enity called the shim-header. So what we are talking about here is the > *user-plane* and, if it was understood better, the creation of a new layer > network each time a shim (characteristic information) label header is added > (I am using functional arch terminology which many manufacturers and > operators are familar with). The 'implicit' labels on the other hand are > actually substitutional terms which, in essence, mean nothing more than > 'technology specific'.......though I know they are dressed-up in the > 'Generalised MPLS' philosophy which, in its purest sense, is simply a > statement of a desire to use a single control-plane over all technologies, > and clearly has nothing at all to do with labels and the user-plane. > > I think this distinction.......ie explicit labels => user-plane, implicit > labels => control-plane philosophy.....are so far removed from each other > there is no relationshiop between them. > > Neil From owner-mpls@UU.NET Wed Dec 6 09:33:13 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20613 for ; Wed, 6 Dec 2000 09:33:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskg16222; Wed, 6 Dec 2000 14:31:52 GMT Received: by mail-control.mail.uu.net id QQjskg26350 for mpls-outgoing; Wed, 6 Dec 2000 14:31:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjskg26344 for ; Wed, 6 Dec 2000 14:31:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjskg12601 for ; Wed, 6 Dec 2000 14:31:10 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjskg18300 for ; Wed, 6 Dec 2000 14:31:09 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA19804 for mpls@uu.net; Wed, 6 Dec 2000 09:31:09 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjskg26273 for ; Wed, 6 Dec 2000 14:30:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjskf06951 for ; Wed, 6 Dec 2000 14:29:23 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjskf12489 for ; Wed, 6 Dec 2000 14:29:23 GMT Received: from localhost (yakov@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id GAA27702; Wed, 6 Dec 2000 06:29:08 -0800 (PST) Message-Id: <200012061429.GAA27702@cisco.com> To: neil.2.harrison@bt.com cc: petera@nortelnetworks.com, mpls@UU.NET, andy.bd.reid@bt.com, darren.freeland@bt.com, alan.mcguire@bt.com Subject: Re: New MPLS Charter? In-reply-to: Your message of "Wed, 06 Dec 2000 09:53:03 GMT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27700.976112948.1@cisco.com> Date: Wed, 06 Dec 2000 06:29:08 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Neil, > > I can see how a literal interpretation of item 3) could cause problems. > > Being pragmatic let me suggest that we insert an indication that both > > implicit > > and explicit labels are part of the charter. > > > > I believe the literal interpretation that George is referring to is > > "explicit labels" and indeed if we are limited to explicit labels GMPLS > > is homeless. I am sure that is not the intention of the wording because > > it clearly talks about implicit label switching like wavlength and space > > so simply adding the words "implicit and explicit" should solve the > > problem. > NH=> Peter, Implicit and explicit labels as you call them are not at all > the same thing from an architectural perspective. In 'pure' MPLS we have an > enity called the shim-header. The shim-header is just *one* of the options, but not the only one possible. MPLS also supports carrying labels in VCI/VPI and DLCI. > So what we are talking about here is the > *user-plane* and, if it was understood better, the creation of a new layer > network each time a shim (characteristic information) label header is added > (I am using functional arch terminology which many manufacturers and > operators are familar with). The 'implicit' labels on the other hand are > actually substitutional terms which, in essence, mean nothing more than > 'technology specific'.......though I know they are dressed-up in the > 'Generalised MPLS' philosophy which, in its purest sense, is simply a > statement of a desire to use a single control-plane over all technologies, > and clearly has nothing at all to do with labels and the user-plane. The GMPLS technology has to do with the concept of "label swapping" as a forwarding paradigm. So, it has a lot to do with labels. Yakov. From owner-mpls@UU.NET Wed Dec 6 10:01:17 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25599 for ; Wed, 6 Dec 2000 10:01:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskh12774; Wed, 6 Dec 2000 14:59:55 GMT Received: by mail-control.mail.uu.net id QQjskh09897 for mpls-outgoing; Wed, 6 Dec 2000 14:59:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjskh09892 for ; Wed, 6 Dec 2000 14:59:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjskh10387 for ; Wed, 6 Dec 2000 14:59:11 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQjskh11567 for ; Wed, 6 Dec 2000 14:59:11 GMT Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 6 Dec 2000 09:58:41 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YGTL2WJC; Wed, 6 Dec 2000 09:58:37 -0500 Received: from americasm01.nt.com (bcarsf1d.ca.nortel.com [47.14.99.74]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YFZD3ANT; Wed, 6 Dec 2000 09:58:39 -0500 Message-ID: <3A2E541C.629609C8@americasm01.nt.com> Date: Wed, 06 Dec 2000 09:58:36 -0500 From: "Peter Ashwood-Smith" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: GMPLS - Hierarchies References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Correct, One could take a signal and instead of using hierarchy, simply map it from one type to another of LSP. There is nothing in the generalized draft that precludes such translations. Actually if you go back a year and look at a draft that was presented we had something called a composite label that could change from type to type as it propogated. This work was subsumed by the generalized draft. While it is generally recognized that LSPs form a natural hierarchy, it is perfectly feasable to map from one type to another where the bandwidths are a close match, given that the hardware is capable of doing it. Such hardware is a hybrid LSR (we produce ATM/PPP examples of them today), which may change the label type as the requests/path messages flow. This is most likely to occur with TDM and OXC equipement at the OC-192 and OC-48 rates where there is a close mapping between the OXC lambda and the TDM signal bandwidth. It won't work sell so well at lower rates because you waste too much bandwidth and are forced into a heirarchy whether you want one or not. Cheers, Peter Ashwood-Smith > draft-ietf-mpls-generalized-signaling-01 mentions in the introduction a hierachy with fiber switching at the top followed by lambda, time-slot and packet switching and clearly distinguish between these levels. I don't agree with this view that a LSP starts and ends on the same LSR type and onyl nesting of LSPs of different LSR types is possible. > Take for example an optical cross-connect that switches fiber between its ports (=> fiber switch capable). The single or multiple lambdas on this fiber might be directly after the cross-connect or later combined with other signals from other fibers in a WDM system => (lambda switch capable) or a TDM technique is used to combine several of these signals to a higher bandwidth signal (e.g. going from 2.5 to 10 Gbit/s) (=> time switch capable). So a LSP that starts at LSC device ends up at a TSC device and might have a LSC device in between. Even an interchange of LSPs between packet and circuit switch capable devices is possible, take for a example circuit emulation via ATM. With circuit emulation you can also have a LSP that starts on a TSC device nested into a LSP that starts on a PSC device. > A LSP represents a connection through the network/sub-network for a certain signal. This is independent of the switching technologies along the route and at the end as long as the specific signal is supported. At both ends access to the specific signal has to be provided, but it doesn't matter if e.g. a 1.5 Mbit/s signal is transported on a time-slot of a TDM system, on a single wavelength of a WDM system (not economic), over a CDMA radio system or with circuit emulation over an ATM network. > The Hierarchy is defined by different signals nested into each other (client/server relationship), but not by the switching types. > > Regards > > Juergen Heiles From owner-mpls@UU.NET Wed Dec 6 10:32:52 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00048 for ; Wed, 6 Dec 2000 10:32:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskk14923; Wed, 6 Dec 2000 15:31:31 GMT Received: by mail-control.mail.uu.net id QQjskk24799 for mpls-outgoing; Wed, 6 Dec 2000 15:31:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjskk24761 for ; Wed, 6 Dec 2000 15:30:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjskk15396 for ; Wed, 6 Dec 2000 15:30:33 GMT Received: from falla.videotron.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: falla.videotron.net [205.151.222.106]) id QQjskk13331 for ; Wed, 6 Dec 2000 15:30:32 GMT Received: from MartinPicard ([24.202.11.202]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with SMTP id <0G55006OQKAZ22@falla.videotron.net> for mpls@UU.NET; Wed, 6 Dec 2000 10:28:12 -0500 (EST) Date: Wed, 06 Dec 2000 10:19:24 -0500 From: Martin Picard Subject: Re: Lack of outgoing label was Re: (Reply) RE: (Reply) To: Eyad Saheb Cc: mpls@UU.NET Message-id: <013701c05f97$eae12d20$ca0bca18@videotron.ca> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_2TbqT5LF/XaLZ5vhowDs0g)" X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 References: X-Priority: 3 Sender: owner-mpls@UU.NET Precedence: bulk C'est un message de format MIME en plusieurs parties. --Boundary_(ID_2TbqT5LF/XaLZ5vhowDs0g) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: Lack of outgoing label was Re: (Reply) RE: (Reply)Yes, you are right = Eyad. Penultimate Hop Pop is an optional behavior. mp ----- Message d'origine -----=20 De : Eyad Saheb=20 =C0 : 'Martin Picard'=20 Envoy=E9 : 6 d=E9cembre, 2000 10:14 Objet : RE: Lack of outgoing label was Re: (Reply) RE: (Reply) Last I looked, PHP was not a mandatory req in the MPLS arch.=20 Eyad=20 -----Original Message-----=20 From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Martin=20 Picard=20 Sent: Wednesday, December 06, 2000 8:32 AM=20 To: dan martin=20 Cc: mpls@UU.NET=20 Subject: Re: Lack of outgoing label was Re: (Reply) RE: (Reply)=20 Dan,=20 The LER does not get a labelled packet. It gets an IP packet.=20 The LSR facing the LER (called upstream LSR for that LSP),=20 will get the labelled packet and will map the incoming label=20 to an outgoing label of "Pop Label" which means that the=20 next hop is the ultimate destination and in order to avoid=20 double lookups in the LER (one for the Label and one for IP)=20 it just strips off the label and send the packet unlabelled to=20 the LER which will "route" the packet.=20 Hope I am not making this worst than it really is.=20 You can always look at mpls-arch draft section 3.16=20 to get it from the horse's mouth !=20 mp=20 > up until you explained it, i thought i understood it.=20 >=20 > so the label edge router gets a labeled packet. it has no path to = send it=20 > out on. the indicator in the label says it is the last label. now = it=20 pops=20 > off the label and routes the packet.=20 >=20 > what am i leaving out?=20 >=20 > -----Original Message-----=20 > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of = Martin=20 > Picard=20 > Sent: Wednesday, December 06, 2000 7:22 AM=20 > To: Manikandan.V=20 > Cc: mpls@UU.NET=20 > Subject: Re: Lack of outgoing label was Re: (Reply) RE: (Reply)=20 >=20 >=20 > What do you mean by Terminating LSR ?=20 > If you mean egress-LER, then you should not receive "labelled" = packets=20 > at all for these destinations since the upstream LSR which is the=20 > penultimate hop should pop the label.=20 > If you have more than one label on the stack, as the stack depth = decreases=20 > processing is the same on the top label and eventually the = penultimate hop=20 > will output an unlabelled packet to the egress-LER.=20 > What do you mean by no LSP available in the domain ?=20 > Do you mean that for a particular LSR the label space is exausted = and=20 > no free labels exist ?=20 >=20 > mp=20 >=20 >=20 > > Thats fine and thanks for your reply.=20 > > But, What I mean is what will be the LSR process if the processing = LSR=20 is=20 > > the Terminating LSR and after that there is no LSP available in = the=20 > domain.=20 > >=20 > > Cheers,=20 > > mani=20 > >=20 > > -----Original Message-----=20 > > From: Martin Picard [mailto:mpicard@sinc.ca]=20 > > Sent: Wednesday, December 06, 2000 5:17 PM=20 > > To: seenu@samsung.co.kr; mpls@UU.NET; manikv@hclt.com=20 > > Subject: Re: (Reply) RE: (Reply)=20 > >=20 > >=20 > > Seenu, Manik,=20 > >=20 > > "the only safe procedure is to discard the packet" -=20 > > draft-ietf-mpls-arch-07 section 3.22=20 > >=20 > > martin=20 > >=20 > >=20 > > > Hi manik,=20 > > >=20 > > > I would like to clarify my previous mail.=20 > > >=20 > > > If a packet comes and if it contains Invalid Incoming Label = (there is=20 no=20 > > Label Entry with the "In Label" in the label switching matrix)=20 > > > then it should be dropped.=20 > > >=20 > > > If a packet comes and it has valid Incoming Label Entry, but no = Out=20 > going=20 > > label....This is the egress case...So, need to apply conventional=20 routing=20 > > > on the packet.=20 > > >=20 > > > Regards,=20 > > > Seenu=20 > > > Samsung India Software Operations=20 > > > Level 7, Prestige Meridian - II=20 > > > M.G.Road, Bangalore, India.=20 > > >=20 > > > Tel: +91-80-558 1281 ext: 268=20 > > >=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=20 > > >=20 > > > Hi manik,=20 > > >=20 > > > You need to drop the packet.=20 > > >=20 > > > For more infromation pls go thorugh the section=20 > > > "3.18. Invalid Incoming Labels" in = "draft-ietf-mpls-arch-07.txt"=20 > > >=20 > > > Regards,=20 > > > Seenu=20 > > > Samsung India Software Operations=20 > > > Level 7, Prestige Meridian - II=20 > > > M.G.Road, Bangalore, India.=20 > > >=20 > > > Tel: +91-80-558 1281 ext: 268=20 > > >=20 > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=20 > > >=20 > > > Hi all,=20 > > >=20 > > > I am working on MPLS protocol implementation.=20 > > >=20 > > > I have a doubt on MPLS forwarding process. If I received the = labeled=20 > > packet=20 > > > which does not have the entry Label Information Table (I mean = does not=20 > > have=20 > > > the outgoing label entry).. What I have to DO?=20 > > >=20 > > > 1. Do I have to drop the packet=20 > > > 2. Do I have to strip of the Shim header and go for conventional = IP=20 > > routing.=20 > > >=20 > > >=20 > > > Thanks in advance,=20 > > > Manikandan.V=20 > > >=20 > > > -------=20 > > > The MPLS-OPS Mailing List=20 > > > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml=20 > > > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml=20 --Boundary_(ID_2TbqT5LF/XaLZ5vhowDs0g) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: Lack of outgoing label was Re: (Reply) RE: = (Reply)
Yes, you are right Eyad.
Penultimate Hop Pop is an optional = behavior.
mp
 
----- Message d'origine -----
De=20 : Eyad=20 Saheb
Envoy=E9 : 6 d=E9cembre, = 2000=20 10:14
Objet : RE: Lack of outgoing = label was=20 Re: (Reply) RE: (Reply)

Last I looked, PHP was not a mandatory req in the = MPLS=20 arch.

Eyad

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On = Behalf Of=20 Martin
Picard
Sent: Wednesday,=20 December 06, 2000 8:32 AM
To: dan = martin=20
Cc: mpls@UU.NET=20
Subject: Re: Lack of outgoing label was Re: (Reply) = RE:=20 (Reply)


Dan,

The LER does not get a labelled packet. It gets an = IP=20 packet.
The LSR facing the LER (called = upstream LSR=20 for that LSP),
will get the labelled packet = and will=20 map the incoming label
to an outgoing label = of "Pop=20 Label" which means that the
next hop is the = ultimate=20 destination and in order to avoid
double = lookups in=20 the LER (one for the Label and one for IP)
it just=20 strips off the label and send the packet unlabelled to =
the LER which will "route" the packet.

Hope I am not making this worst than it really = is.=20
You can always look at mpls-arch draft section = 3.16=20
to get it from the horse's mouth !

mp



> up until you explained it, i thought i = understood=20 it.
>
> so = the label=20 edge router gets a labeled packet.  it has no path to send = it=20
> out on.  the indicator in the label says = it is the=20 last label.  now it
pops =
> off the label and routes the packet.
>
> what am i leaving = out?=20
>
> -----Original=20 Message-----
> From: owner-mpls@UU.NET = [mailto:owner-mpls@UU.NET]On = Behalf Of=20 Martin
> Picard
> Sent:=20 Wednesday, December 06, 2000 7:22 AM
> = To:=20 Manikandan.V
> Cc: mpls@UU.NET =
> Subject: Re: Lack of outgoing label was Re: (Reply) RE:=20 (Reply)
>
>=20
> What do you mean by Terminating LSR ? =
> If you mean egress-LER, then you should not receive = "labelled"=20 packets
> at all for these destinations = since the=20 upstream LSR which is the
> penultimate = hop should=20 pop the label.
> If you have more than = one label on=20 the stack, as the stack depth decreases
> = processing is the same on the top label and eventually the penultimate = hop
> will output an unlabelled packet to = the=20 egress-LER.
> What do you mean by no LSP = available=20 in the domain ?
> Do you mean that for a = particular=20 LSR the label space is exausted and
> no = free=20 labels exist ?
>
>=20 mp
>
>
> > Thats fine and thanks for your reply. =
> > But, What I mean is what will be the LSR process if = the=20 processing LSR
is
> >=20 the Terminating LSR and after that there is no LSP available in = the=20
> domain.
> = >=20
> > Cheers,
> = >=20 mani
> >
> >=20 -----Original Message-----
> > From: = Martin=20 Picard [mailto:mpicard@sinc.ca]=20
> > Sent: Wednesday, December 06, 2000 5:17 = PM=20
> > To: seenu@samsung.co.kr; mpls@UU.NET;=20 manikv@hclt.com
> > Subject: Re: = (Reply) RE:=20 (Reply)
> >
>=20 >
> > Seenu, Manik, =
> >
> >   = "the only safe=20 procedure is to discard the packet" -
> = >=20 draft-ietf-mpls-arch-07 section 3.22
> = >=20
> > martin
> = >=20
> >
> > > = Hi=20 manik,
> > >
>=20 > > I would like to clarify my previous mail.
> > >
> > > If a = packet comes=20 and if it contains Invalid Incoming Label (there is
no
> > Label Entry with the = "In Label" in=20 the label switching matrix)
> > > = then it=20 should be dropped.
> > > =
> > > If a packet comes and  it has valid = Incoming Label=20 Entry, but no Out
> going =
> > label....This is the egress case...So, need to = apply=20 conventional
routing
> >=20 > on the packet.
> > > =
> > > Regards,
> > = >=20 Seenu
> > > Samsung India Software=20 Operations
> > > Level 7, Prestige = Meridian -=20 II
> > > M.G.Road, Bangalore, = India.=20
> > >
> > = > Tel:=20 +91-80-558 1281 ext: 268
> > = >=20
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
> > >
> > > Hi = manik,=20
> > >
> > = > You=20 need to drop the packet.
> > = >=20
> > > For more infromation pls go = thorugh  the=20 section
> > > "3.18. Invalid = Incoming Labels"=20 in  "draft-ietf-mpls-arch-07.txt"
> = >=20 >
> > > Regards, =
> > > Seenu
> > > = Samsung=20 India Software Operations
> > > = Level 7,=20 Prestige Meridian - II
> > > = M.G.Road,=20 Bangalore, India.
> > > =
> > > Tel: +91-80-558 1281 ext: 268
> > >
> > >=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
> > >=20
> > > Hi all,
> >=20 >
> > > I am working on MPLS = protocol=20 implementation.
> > > =
> > > I have a doubt on MPLS forwarding process. If = I received=20 the labeled
> > packet =
> > > which does not have the entry Label = Information Table (I=20 mean does not
> > have =
> > > the outgoing label entry).. What I have to = DO?=20
> > >
> > = > 1. Do I=20 have to drop the packet
> > > 2. Do = I have to=20 strip of the Shim header and go for conventional IP
> > routing.
> > = >=20
> > >
> > = > Thanks=20 in advance,
> > > = Manikandan.V=20
> > >
> > = >=20 -------
> > > The MPLS-OPS Mailing=20 List
> > > = Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsop= s.shtml=20
> > > Archive: http://www.mplsrc.c= om/mpls-ops_archive.shtml=20

--Boundary_(ID_2TbqT5LF/XaLZ5vhowDs0g)-- From owner-mpls@UU.NET Wed Dec 6 10:44:00 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02659 for ; Wed, 6 Dec 2000 10:44:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskk01230; Wed, 6 Dec 2000 15:42:40 GMT Received: by mail-control.mail.uu.net id QQjskk26183 for mpls-outgoing; Wed, 6 Dec 2000 15:42:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjskk26145 for ; Wed, 6 Dec 2000 15:41:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjskk16464 for ; Wed, 6 Dec 2000 15:40:36 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjskk29655 for ; Wed, 6 Dec 2000 15:40:36 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA20631 for ; Wed, 6 Dec 2000 07:40:37 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA05494 for mpls@uu.net; Wed, 6 Dec 2000 10:40:34 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsii12600 for ; Wed, 6 Dec 2000 02:02:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsii21916 for ; Wed, 6 Dec 2000 02:01:49 GMT Received: from server.nayna.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: node-64-145-162-227.dslspeed.zyan.com [64.145.162.227]) id QQjsii24405 for ; Wed, 6 Dec 2000 02:01:44 GMT Received: from hp900 (sonicwall [64.145.162.226]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id SAA22948; Tue, 5 Dec 2000 18:01:33 -0800 X-Authentication-Warning: server.nayna.com: Host sonicwall [64.145.162.226] claimed to be hp900 Message-ID: <001e01c05f28$b86f3400$6480000a@nayna.com> From: "Raj Jain" To: , Cc: "Raj Jain" Subject: Revised I-D: IP over Optical Networks: Summary of Issues Date: Tue, 5 Dec 2000 18:03:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit We have revised our Internet Draft: IP over Optical Networks: Summary of Issues draft-osu-ipo-mpls-issues-01.txt Abstract: This draft presents a summary of issues related to transmission of IP packets over optical networks. This is a compilation of many drafts presented so far in IETF. The goal is to create a common document, which by including all the views and proposals will serve as a better reference point for further discussion. The novelty of this draft is that we try to cover all the main areas of integration and deployment of IP and optical networks including architecture, routing, signaling, management, and survivability. This -01 revision contains updated discussion on signaling (Section 4) and fault restoration (Section 6). The draft was returned back by the IETF mailer since it was late and will be resubmitted to the Internet drafts directory after December 11, 2000. In the mean time, it is available at: http://www.cis.ohio-state.edu/~jain/ietf/issues.htm Thanks. -Raj ----------------------------------------------------------------- Raj Jain Nayna Networks, Inc. 157 Topaz St. Milpitas, CA 95035 Phone: 408-956-8000X309 Fax: 408-956-8730 Email: raj@nayna.com From owner-mpls@UU.NET Wed Dec 6 10:56:53 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05796 for ; Wed, 6 Dec 2000 10:56:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskl05332; Wed, 6 Dec 2000 15:55:31 GMT Received: by mail-control.mail.uu.net id QQjskl27768 for mpls-outgoing; Wed, 6 Dec 2000 15:55:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjskl27757 for ; Wed, 6 Dec 2000 15:55:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjskl29485 for ; Wed, 6 Dec 2000 15:53:59 GMT Received: from hoemlsrv.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQjskl03081 for ; Wed, 6 Dec 2000 15:53:59 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA27100 for ; Wed, 6 Dec 2000 10:53:58 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA27088 for ; Wed, 6 Dec 2000 10:53:58 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA01370; Wed, 6 Dec 2000 10:53:58 -0500 (EST) Message-ID: <3A2E6115.C8ED592B@lucent.com> Date: Wed, 06 Dec 2000 10:53:57 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: GMPLS - Hierarchies References: <3A2E541C.629609C8@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Juergen, Agree in concept, LSPs don't have to starts and ends on the same LSR type. A not ugly example is, in circuit switched transport network, a T1 equivalent LSP can go through a TDM mux and then a SONET box capable of low order switch. The key issue is not about "LSR type". It's the characteristic of the LSP. They have to be consistent for "a" LSP. However, when a LSP goes through different technology domains, it's possible, clear and convenient (for many cases) to break them into sections, set up them independently and concatenate them. These sections are actually peers. The client/server relation exist for LSPs of different granularities. Typically, low granularity LSP can use high granularity LSP as tunnel (in your example, the 2.5G pipe can tunnel through a previously established 10G pipe). LSPs of different granularity are set up at different time and triggered by different reasons. Thanks, Yangguang > draft-ietf-mpls-generalized-signaling-01 mentions in the introduction a hierachy with fiber switching at the top followed by lambda, time-slot and packet switching and clearly distinguish between these levels. I don't agree with this view that a LSP starts and ends on the same LSR type and onyl nesting of LSPs of different LSR types is possible. > Take for example an optical cross-connect that switches fiber between its ports (=> fiber switch capable). The single or multiple lambdas on this fiber might be directly after the cross-connect or later combined with other signals from other fibers in a WDM system => (lambda switch capable) or a TDM technique is used to combine several of these signals to a higher bandwidth signal (e.g. going from 2.5 to 10 Gbit/s) (=> time switch capable). So a LSP that starts at LSC device ends up at a TSC device and might have a LSC device in between. Even an interchange of LSPs between packet and circuit switch capable devices is possible, take for a example circuit emulation via ATM. With circuit emulation you can also have a LSP that starts on a TSC device nested into a LSP that starts on a PSC device. > A LSP represents a connection through the network/sub-network for a certain signal. This is independent of the switching technologies along the route and at the end as long as the specific signal is supported. At both ends access to the specific signal has to be provided, but it doesn't matter if e.g. a 1.5 Mbit/s signal is transported on a time-slot of a TDM system, on a single wavelength of a WDM system (not economic), over a CDMA radio system or with circuit emulation over an ATM network. > The Hierarchy is defined by different signals nested into each other (client/server relationship), but not by the switching types. > From owner-mpls@UU.NET Wed Dec 6 11:21:12 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11640 for ; Wed, 6 Dec 2000 11:21:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskn18683; Wed, 6 Dec 2000 16:19:47 GMT Received: by mail-control.mail.uu.net id QQjskn12750 for mpls-outgoing; Wed, 6 Dec 2000 16:19:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjskn12738 for ; Wed, 6 Dec 2000 16:19:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjskn10455 for ; Wed, 6 Dec 2000 16:16:35 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjskn21197 for ; Wed, 6 Dec 2000 16:16:34 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA00971 for mpls@uu.net; Wed, 6 Dec 2000 11:16:33 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjskn12208 for ; Wed, 6 Dec 2000 16:15:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjskm02526 for ; Wed, 6 Dec 2000 16:14:05 GMT Received: from lumen.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lumen.calient.net [63.102.55.200]) id QQjskm17587 for ; Wed, 6 Dec 2000 16:14:05 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Dec 2000 08:14:04 -0800 Message-ID: From: John Drake To: "'Heiles Juergen'" , mpls@UU.NET Cc: ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] GMPLS - Hierarchies Date: Wed, 6 Dec 2000 08:14:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Jergen, An LSP has an two endpoints. At the ingress endpoint, a node is multiplexing stuff into a given LSP. At the egress endpoint, a node is demultiplexing stuff from that LSP. If the ingress and egress endpoints aren't multiplexing and demultiplexing stuff consistently, how is stuff able to successfully transit the LSP? Thanks, John -----Original Message----- From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] Sent: Wednesday, December 06, 2000 4:34 AM To: mpls@UU.NET Cc: ip-optical@lists.bell-labs.com Subject: [IP-Optical] GMPLS - Hierarchies draft-ietf-mpls-generalized-signaling-01 mentions in the introduction a hierachy with fiber switching at the top followed by lambda, time-slot and packet switching and clearly distinguish between these levels. I don't agree with this view that a LSP starts and ends on the same LSR type and onyl nesting of LSPs of different LSR types is possible. Take for example an optical cross-connect that switches fiber between its ports (=> fiber switch capable). The single or multiple lambdas on this fiber might be directly after the cross-connect or later combined with other signals from other fibers in a WDM system => (lambda switch capable) or a TDM technique is used to combine several of these signals to a higher bandwidth signal (e.g. going from 2.5 to 10 Gbit/s) (=> time switch capable). So a LSP that starts at LSC device ends up at a TSC device and might have a LSC device in between. Even an interchange of LSPs between packet and circuit switch capable devices is possible, take for a example circuit emulation via ATM. With circuit emulation you can also have a LSP that starts on a TSC device nested into a LSP that starts on a PSC device. A LSP represents a connection through the network/sub-network for a certain signal. This is independent of the switching technologies along the route and at the end as long as the specific signal is supported. At both ends access to the specific signal has to be provided, but it doesn't matter if e.g. a 1.5 Mbit/s signal is transported on a time-slot of a TDM system, on a single wavelength of a WDM system (not economic), over a CDMA radio system or with circuit emulation over an ATM network. The Hierarchy is defined by different signals nested into each other (client/server relationship), but not by the switching types. Regards Juergen Heiles _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Wed Dec 6 11:30:24 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14266 for ; Wed, 6 Dec 2000 11:30:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskn09560; Wed, 6 Dec 2000 16:29:03 GMT Received: by mail-control.mail.uu.net id QQjskn13552 for mpls-outgoing; Wed, 6 Dec 2000 16:28:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjskn13538 for ; Wed, 6 Dec 2000 16:28:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjskn05594 for ; Wed, 6 Dec 2000 16:25:04 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjskn07023 for ; Wed, 6 Dec 2000 16:24:59 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA00517 for ; Wed, 6 Dec 2000 11:24:57 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25391 for ; Wed, 6 Dec 2000 11:24:57 -0500 (EST) Message-ID: <3A2E686D.4F4C4E3C@marconi.com> Date: Wed, 06 Dec 2000 11:25:17 -0500 From: David Charlap X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Question on Draft of RSVP-TE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Gaitonde Anandprasanna wrote: > > I have read this draft. But i found it to be discussing only Objects > and message processing for Path and REsv mesage. > > Does the format and the Processing of the PathERR or Resv ERR , Path > Tear or Resv tear messages change from base protocol RSVP Processing of these is the same as RFC 2205, except as modified by the TE-draft. These changes (to the best of my knowledge) are: - PathErr: - may be generated by Resv admission control errors as well as Path errors. The name is now a misnomer - any time an error message should be sent to the ingress node, it's done via a PathErr. - New error codes (Routing Error and Notify) - RRO objects may be included. The BNF for PathTear in RFC 2205 specifies "Sender Descriptor", which was redefined in the TE draft. - ResvErr: - Won't be generated by admission control error. PathErr is used instead. - RRO and Label objects may be included. The BNF for ResvErr specifies "Flow Descriptor" which was redefned in the TE draft. - PathTear: - When an ERO was used for establishing a Path, that same ERO must be used when tearing it down. - RRO objects may be included. See above. - ResvTear: - RRO and Label objects may be included. See above. -- David From owner-mpls@UU.NET Wed Dec 6 11:34:36 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15256 for ; Wed, 6 Dec 2000 11:34:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsko09124; Wed, 6 Dec 2000 16:33:15 GMT Received: by mail-control.mail.uu.net id QQjsko14251 for mpls-outgoing; Wed, 6 Dec 2000 16:32:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsko14243 for ; Wed, 6 Dec 2000 16:32:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsko24018 for ; Wed, 6 Dec 2000 16:31:24 GMT Received: from hoemlsrv.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail1.lucent.com [192.11.226.161]) id QQjsko06233 for ; Wed, 6 Dec 2000 16:31:23 GMT Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA13589 for ; Wed, 6 Dec 2000 11:31:22 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA13580; Wed, 6 Dec 2000 11:31:22 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA25165; Wed, 6 Dec 2000 11:31:21 -0500 (EST) Message-ID: <3A2E69D8.DED8826F@lucent.com> Date: Wed, 06 Dec 2000 11:31:20 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Yakov Rekhter CC: neil.2.harrison@bt.com, petera@nortelnetworks.com, mpls@UU.NET, andy.bd.reid@bt.com, darren.freeland@bt.com, alan.mcguire@bt.com Subject: Re: New MPLS Charter? References: <200012061429.GAA27702@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, I am totally confused. I thought we were only looking to have GMPLS for control plane. Label swapping is done in data plane. What's the "label" after a LSP being set up in circuit switched transport network? Below are my understanding of MPLS control plane concepts that can be "mapped" to circuit switched transport network. Given that circuit paths are service-driven, one possible understanding is to treat the service request as an FEC. It contains next hop (or destination address for hop by hop routing) and incoming physical interface (e.g., if negotiation is not required at connection creation time) or path constraints (e.g., if negotiation is required). Because labels are used for traffic forwarding, they are analogous to cross connect ID. Label binding is then conceptually equivalent to choosing cross-connection across the switch matrix. An alternate interpretation (a more popular way )can be constructed as follows: In circuit switched networks, setting up a LSP means making cross connects along the desirable path. Labels are used to determine cross connect configurations. Assuming a non-blocking switch fabric, determining a cross-connect means determining external ingress and egress physical interfaces. So labels are used to indicate specific physical interfaces. Label binding entails choosing the correct ingress or egress interface according to path selection decision and local policies. In both of the above interpretations, making cross connects is equivalent to writing to a label switching forwarding table. After the path is set up, user traffic simply follows the dedicated physical path (cross connect). The concepts below elaborate on the second interpretation. Thanks, Yangguang > > The GMPLS technology has to do with the concept of "label swapping" as a > forwarding paradigm. So, it has a lot to do with labels. > > Yakov. From owner-mpls@UU.NET Wed Dec 6 11:38:42 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16183 for ; Wed, 6 Dec 2000 11:38:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsko22512; Wed, 6 Dec 2000 16:37:22 GMT Received: by mail-control.mail.uu.net id QQjsko14721 for mpls-outgoing; Wed, 6 Dec 2000 16:36:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsko14713 for ; Wed, 6 Dec 2000 16:36:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsko09651 for ; Wed, 6 Dec 2000 16:36:21 GMT Received: from ennovatenetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.102.148.71]) id QQjsko20878 for ; Wed, 6 Dec 2000 16:36:20 GMT Received: from tworster (iguard2.ennovatenetworks.com [63.102.148.66]) by ennovatenetworks.com (8.8.7/8.8.7) with SMTP id LAA27071 for ; Wed, 6 Dec 2000 11:36:18 -0500 (EST) (envelope-from tom@ennovatenetworks.com) From: "tom worster" To: Subject: RE: Resend with correct addresses: Note from the volume cabal for ietf-announce (and other lists) Date: Wed, 6 Dec 2000 11:35:11 -0500 Message-ID: <000101c05fa2$95d74e30$7203010a@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.2911.0) Importance: Normal In-Reply-To: <5.0.2.1.2.20001205213648.028239a0@flipper.cisco.com> 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 Fred Baker > > - While we appreciate the desire for authors of internet drafts to be > able to target their efforts and attention to a specific working > group, we do not believe we have full enough community consensus > on the architectural boundaries and direction to do so at this > moment. Therefore, assignment of Internet Drafts to Working Groups > will happen after the San Diego meeting with input from WGs and > community. many of us have been waiting for the iesg's decision on where our respective drafts are to be relocated. i suppose the above means that any such draft that is not already on a wg agenda is bumped for this meeting. do others read it this the same way i do? c u tom From owner-mpls@UU.NET Wed Dec 6 11:48:01 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18288 for ; Wed, 6 Dec 2000 11:48:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskp09339; Wed, 6 Dec 2000 16:46:40 GMT Received: by mail-control.mail.uu.net id QQjskp15854 for mpls-outgoing; Wed, 6 Dec 2000 16:46:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjskp15788 for ; Wed, 6 Dec 2000 16:46:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsko04262 for ; Wed, 6 Dec 2000 16:44:10 GMT Received: from netmail2.alcatel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail2.alcatel.com [128.251.168.51] (may be forged)) id QQjsko26585 for ; Wed, 6 Dec 2000 16:44:09 GMT Received: from relay2.usa.alcatel.com (relay2.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA02315 for ; Wed, 6 Dec 2000 10:44:08 -0600 (CST) Received: from postal.adn.alcatel.com (localhost [127.0.0.1]) by relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id KAA00031 for ; Wed, 6 Dec 2000 10:44:03 -0600 (CST) Received: from adn.alcatel.com ([198.205.32.172]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA1138; Wed, 6 Dec 2000 11:54:11 -0500 Message-ID: <3A2E79CA.DD59D6C6@adn.alcatel.com> Date: Wed, 06 Dec 2000 11:39:23 -0600 From: Olivier Duroyon Organization: Alcatel X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: darren.freeland@bt.com CC: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: draft-oduroyon-te-ip-optical-01.txt References: <71DA16F18D32D2119A1D0000F8FE9A940920C90E@mbtlipnt01.btlabs.bt.co.uk> Content-Type: multipart/mixed; boundary="------------403930F32E603AFB32B60F64" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------403930F32E603AFB32B60F64 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I just realized that draft-oduroyon-te-ip-optical-01.txt has not reached the database yet. In the meanwhile please find a copy of the second iteration for San Diego. Sorry for the inconvenience. Olivier Duroyon oduroyon@usa.alcatel.com Alcatel USA 703 679 6415 --------------403930F32E603AFB32B60F64 Content-Type: text/plain; charset=us-ascii; name="draft-duroyon-te-ip-optical-01.txt" Content-Disposition: inline; filename="draft-duroyon-te-ip-optical-01.txt" Content-Transfer-Encoding: 7bit Internet Engineering Task Force Olivier Duroyon Rudy Hoebeke Hans De Neve Dimitri Papadimitriou Internet Draft Alcatel Document: draft-duroyon-te-ip-optical-01.txt November 2000 Expiration Date: May 2001 G.LSP Service Model framework in an Optical G-MPLS network 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. 1. Abstract The objective of this draft is to propose an IP service model for a non-packet switch capable optical network where G.LSPs are dynamically triggered by the IP layer and subsequently advertised for IP routing. The business model assumes that several IP service domains, some of which represent different administrative entities, share the same optical backbone and focuses therefore primarily on an overlay model. G-MPLS signaling (refer to [g-mpls]) with UNI support is assumed as underlying control plane protocol. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Duroyon et al. Expires May 2001 1 draft-duroyon-te-ip-optical-01.txt November 2000 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. 3. Introduction This draft introduces an end-to-end IP service model enabling the dynamic management of Generalized Label Switched Paths (G.LSP) by means of G-MPLS signaling with User-to-Network Interface (UNI) support. A G.LSP is a point-to-point connectivity with specified attributes (some of which are mandatory, while others are optional) established between two termination points in the optical network. A G.LSP could be a fiber switched path, a lambda switched path, a TDM switched path (circuit) or a packet-switch capable G.LSP. The scope of this draft is restricted to optical networks, which are by definition non-packet switch capable. Consequently, G.LSPs are restricted to non-packet switch capable G.LSPs, which we hereafter refer to as G.LSPs. For reasons of definiteness, the optical devices are always referred to as Optical Network Elements (ONE) and the IP devices as Client Network Elements (CNE). Boundary CNEs and boundary ONEs are interconnected through an UNI signaling and routing interface. The owner of the UNI interface in the optical domain (UNI-Network or UNI-N) is referred to as in the Boundary ONE Controller (ONE-C). Its counterpart in the Client Network (UNI-Client or UNI-C) is referred to the Boundary CNE Controller (CNE-C). The terminology used in the draft attempts to be in line with the definitions found in [ip-optical], [ouni-framework] and [OIF2000.125.2]. An overlay use of G-MPLS (UNI support) is appropriate for an untrusted environment where several IP service domains, representing different administrative entities, share the same optical backbone. Moreover, this model seems well suited for a network architecture including non-IP devices, e.g., legacy TDM or ATM equipment, that interface with the same optical backbone. This is however beyond the scope of this draft. To distinguish between trusted and untrusted peers, a separate definition for a Trusted and Untrusted network interfaces is proposed: - An Untrusted interface is defined when UNI (respectively NNI) interfaces belongs to distinct administrative authorities. For instance an UNI interface between a client network element and an optical network element belonging to distinct ISPs defines an untrusted relationship between the client and the optical network element. - A Trusted interface is defined when UNI (respectively NNI) interfaces belongs to the same administrative authority. For instance an NNI interface between two ONEs belonging to the same Duroyon et al. Expires May 2001 2 draft-duroyon-te-ip-optical-01.txt November 2000 optical carrier defines a trusted relationship between these optical networks elements. The service model further assumes that a decision point in the IP service domain, e.g., a Traffic Engineering tool (TE tool), will trigger a boundary CNE to issue a G.LSP request towards the optical domain. The decision point determines the need for a G.LSP on the basis of IP Service Level Agreements (IP SLAs) and related information, such as for instance load measurements in the IP service domain. The same TE-tool may also decide about the configuration of Traffic Engineering LSPs (TE-LSP), which are by definition Packet-switch capable LSPs. For the purpose of IP traffic engineering, TE-LSPs are in this case created on top of non-Packet-switch capable G.LSPs. In the remainder of the document, the terms TE tool or decision point are used interchangeably and refer to the IP service domain device, capable of triggering G.LSP requests. 4. IP service model description This section outlines the sequence of events that characterize our proposed IP service model. (1) Configuration Configuration consists of installing and configuring interfaces of the boundary ONEs and boundary CNEs. During this stage of end-points configuration, physical attributes of the end-point (as protection attributes of the drop side) are also configured. Configuration of the NNI interfaces of the ONEs is out of the scope of this draft. (2) Neighbor Discovery, Endpoint Registration and Service Discovery The objective of Neighbor Discovery is to provide the information needed to identify the neighbor identity and neighbor connectivity over each link interconnecting a boundary CNE to a boundary ONE. Endpoint registration is concerned with registering boundary CNE endpoints to the optical network. The registration information includes the resource capabilities, closed user group (CUG) identification, port reachability information, UNI protection capabilities etc. This set of information is critical to enable dynamic G.LSP services at the UNI. The endpoint registration mechanism enables the end system to register its critical set of information so that other end systems can identify its existence and network properties. Duroyon et al. Expires May 2001 3 draft-duroyon-te-ip-optical-01.txt November 2000 Service discovery is concerned with obtaining the essential information about services from the attached optical network that are available for the CNE. This information is used by CNEs to establish the service environment. The service discovery mechanism allows the network element to convey information about available services to the end system. After finishing neighbor discovery, endpoint registration and service discovery, each end system should establish the service environment and have sufficient information to generate G.LSP service request. These mechanisms complement each other and they do not depend on the establishment and use of signaling channels between the two parties. (3) Optical Service Level Agreements Next, the service model consists of negotiating Optical SLAs (O- SLA) at optical network-client network boundaries, or between optical networks. In case of an untrusted peering relationship (i.e. untrusted UNI, respectively NNI), each G.LSP request is authenticated and validated against the O-SLA. The validation process against an O- SLA includes checking whether the request is conforming to the restrictions (e.g., on scope) defined in the O-SLA. O-SLAs may also be defined at trusted interfaces as the optical domain to provision resources that could use them. Trusted in this context refers to the fact that you don't expect the CNE to violate this O-SLA, and as such requests received from trusted neighbors don't need to be validated against the O-SLA. (4) G.LSP service request The decision point of the client network determines the required connectivity through the optical domain based on service requirements as per the IP SLAs. It then triggers the boundary CNEs to send a G.LSP service request towards the associated boundary ONEs, using G-MPLS signaling with UNI support. This process is dynamic and may involve, amongst others, the creation of additional G.LSPs, the deletion of existing G.LSPs or the modification of existing G.LSPs. (5) Address resolution At the UNI, the G.LSP service request sent by the CNE needs to include the ONE source and destination termination-point identifiers (in case of trusted UNI interface) or the CNE source and destination termination-point identifiers (in case of untrusted UNI interface). CNE termination-points should also be considered when the G.LSP is established through several optical networks belonging to different administrative authorities. Duroyon et al. Expires May 2001 4 draft-duroyon-te-ip-optical-01.txt November 2000 Consequently, the source client needs to send an address resolution request to obtain the ONE destination termination-point ID or CNE termination-point ID corresponding to the CNE destination logical- address of the G.LSP service request. (6) Optical path selection In case a dedicated instance of an IGP is used inside the optical transport network, each boundary ONE learns the complete topology of the optical domain. A Constraint-based Shortest Path First (CSPF) algorithm can then be implemented in the boundary ONEs to calculate a route for the G.LSP in line with the constraints specified in the request. As an example, the route of a G.LSP may depend on the protection requirements or routing constraints specified in the G.LSP request. The latter may indicate that the requested G.LSP should be routed diversely from other G.LSPs. This CSPF algorithm is expected to be quite different from an IP CSPF algorithm because of optical networking specific considerations. (7) G.LSP advertisement to the IP layer As soon as the G.LSPs are lit up, they are advertised to the client network. The involved boundary CNEs will either create a new IP link and start to exchange routing information (using IGP or eBGP) or modify the characteristics of the existing IP link. (8) Traffic engineering for optimization of the optical domain Optionally, the optical domain may have its own off-line Optical Traffic Engineering (O-TE) tool. This tool may be used for optimization of resource utilization in the optical network by rearranging some G.LSPs. 5. UNI discovery and registration services In order to provide a flexible and end-to-end IP Service model, with a minimum set of local provisioning, specific mechanisms and procedures have to be defined at the boundary between the client and the optical network: - to discover neighbors identity and connectivity - to register client end-point identity - and to discover the supported UNI and network services. Transport mechanisms used for the UNI discovery and registration services are referenced in [OIF2000.125.2] and [OIF2000.200]. 5.1 Neighbor discovery at the UNI The key objective of Neighbor Discovery at the UNI is to provide the information needed to identify the neighbor identity (IP address associated to the corresponding UNI) and neighbor Duroyon et al. Expires May 2001 5 draft-duroyon-te-ip-optical-01.txt November 2000 connectivity over each link connecting the boundary CNE to the boundary ONE. Neighbor discovery process which is also referred to as the Termination-port identity process, provides the following information to the boundary CNE and ONE: - the ONE discovers the identity of the client CNE by automatically discovering the IPv4 address assigned to the UNI-C and the identity of each physical port connected to the CNE - the CNE discovers the identity of to the connected ONE by automatically discovering the IPv4 address assigned to the UNI-N and the identity of each physical port connected to the ONE If the signaling transport mechanism is not explicitly configured, the neighbor discovery process ends by the bootstrapping of the signaling control-channel used to exchange the information during the end-point registration and the service discovery processes. 5.2 End-point Registration and UNI Service Discovery The end-point registration process includes the exchange of information between the CNE and ONE for each of the ports and logical ports connecting the CNE to the ONE. A logical port defines the structure of a physical port by identifying for a given port each of the channels included within this port and sub-channels included within this channel. The UNI Service discovery process includes the exchange of resource-related information of the Framing and Bandwidth capacity of each of the ports and logical ports connecting the CNE to the ONE. Additional parameters, such as the UNI drop-side protection attributes (UNI client-side protection and UNI network-side protection) and the G.LSP Directionality support could also be exchanged during the resource discovery process. For SDH/Sonet interfaces, the Transparency levels (STE-C, LTE-C), the client support of Virtual Concatenation (VC) and the levels of Continuous Concatenation (CC). The end-point registration process includes also the address registration process [OIF2000.261.1]. The address registration process allows the CNE to register the CNE logical addresses attached to the CNE Termination-point ID to which corresponds an unique ONE Termination-point IDs. A CNE Termination-point ID includes the unique IP address associated with the client element and the logical-port ID. The logical-port ID comprises the port-ID, Channel-ID and Sub-channel-ID as defined in [OIF2000.125.2]. When the address registration is part of the end-point registration process, the CNE associates the CNE Termination-point ID with the corresponding logical address and ONE termination-point ID. When the CNE does not associate logical addresses with their interfaces, Duroyon et al. Expires May 2001 6 draft-duroyon-te-ip-optical-01.txt November 2000 the CNE termination-point ID resolution implies that the boundary ONE knows the mappings between the CNE termination-point ID and the ONE termination-point ID. This case is considered as a particular case where the CNE logical address fields are empty. In this case, the value of the logical address could correspond to the user-group identifier to which the G.LSP belongs; however, in this particular case, the address resolution is always based on the CNE termination-point ID. Other client identifiers could be exchanged during end-point registration process: - the CNE registers the Contract ID attached to a specific element and/or interface - the CNE registers the Closed User-Group (CUG) IDs (i.e. User- Group ID) attached to a specific client end-point or port 5.3 Network Service Discovery The network service Discovery consists of the G.LSP service-related discovery process and a policy related service discovery process. During the G.LSP-related service discovery process, the CNE registers and/or discovers the parameters related to - SDH/Sonet related services, i.e., the SDH/Sonet Transparency levels supported and the Continuous Concatenation levels supported - G.LSP Directionality support - Network-side Protection, i.e., the Protection-levels services provided by the internal optical network (Unprotected, Dedicated 1+1 Protection, Dedicated 1:1 and Shared Protection) - G.LSP Priority classes and Preemption levels supported by the optical network - G.LSP Diversity options supported by the optical network - Security levels support (IPSec or other authentication mechanism) within the signaling used on the control-plane throughout the optical network The discovery of the Policy-related service may include the following parameters: - Service-levels offered by optical network - Scheduling-related service supported by the optical transport network and/or the scheduling desired by the client - Billing-related service supported by the optical transport network and/or the billing method desired by the client - Vendor-related and Optional parameters 6. Address resolution As stated in section 4.5, the source client needs to send an address resolution request to obtain the ONE destination termination-point ID (trusted UNI interface) or CNE termination- Duroyon et al. Expires May 2001 7 draft-duroyon-te-ip-optical-01.txt November 2000 point ID (untrusted UNI interface) corresponding to the destination CNE logical-address. Consequently, at a trusted UNI interface, the G.LSP create message sent by the CNE to the ONE includes the source and destination ONE (or CNE) termination-point IDs requested for this G.LSP. This implies that the source ONE must perform a internal address-lookup toward a directory service or a local mapping table, in order to find the mapping between the destination CNE termination-point ID and the destination ONE termination-point ID. So, the optical network client only needs to know the CNE source and destination logical address and termination-point ID in order to request a G.LSP creation; any other topological information concerning the optical network termination-point identification is transparent for the client. This mechanism is also adapted for inter-domain G.LSP (cf. Section 9.1) since in this case only the autonomous-system (AS) boundary ONE termination-point to CNE termination-point mapping-list has to announced to the neighboring BGP AS's. 7. Optical Service Level Agreements An optical domain-IP service domain boundary coincides with a UNI with its associated O-SLA. Similarly, if there are multiple optical sub-networks in the optical domain, there will be O-SLAs negotiated at each optical sub-network boundary. An optical sub-network boundary then corresponds to an optical Network-to-Network Interface (NNI). In this draft, we limit the discussion to O-SLAs at the level of UNIs. As mentioned before, G.LSP requests issued by a boundary CNE are only accepted within the constraints of an O-SLA. This means that in case of an untrusted peering relationship, each G.LSP request is authenticated and validated against the O-SLA. It was already indicated that O-SLAs may also be defined at trusted interfaces. However, G.LSP requests received from trusted neighbors don't need to be validated against the O-SLA. In the scope of this draft, we only discuss the technical aspects of an O-SLA. Borrowing from the terminology introduced in [diffserv-framework], we refer to the technical part of an O-SLA as an Optical Service Level Specification (O-SLS). An O-SLS is considered to be unidirectional and to specify performance expectations (i.e., the service level) for the IP service domain as well as imposed reachability constraints, e.g., CUG. O-SLS parameters could for example include: 1. Capacity constraints Duroyon et al. Expires May 2001 8 draft-duroyon-te-ip-optical-01.txt November 2000 An ingress O-SLS may contain limits on the maximum number of G.LSPs that can be established from a specific ingress point, possibly as a function of time of day, as well as bandwidth constraints (OC-48, OC-192, etc.). An egress O-SLS may put capacity constraints on the G.LSPs that the receiving IP service domain is willing to terminate. 2. Service performance parameters Examples are G.LSP setup and/or recovery admitted latency, supported protection/restoration options, availability, supported routing constraints, accessibility (i.e., G.LSP request blocking probability), responsiveness (specifying upper limits on the processing time of G.LSP requests), etc. 3. Constraints on the 'scope' of G.LSP request This may be viewed as an extension to the concept of CUGs, which by nature already exhibit reachability limitations. Scope constraints are intended to additionally restrict the topological extent of G.LSPs. In its simplest form, the O-SLS offers to accept any G.LSP request issued by the IP service domain over a specific O-UNI up to a maximum capacity without any scope constraint within the CUG (so- called hose O-SLS). Conversely, the agreement may be constrained by the egress point of a G.LSP. For example, the optical domain service provider might agree to the setup of G.LSPs, up to a certain maximum capacity, but only if these G.LSPs are destined to a specific set of egress points within the CUG. Part of the purpose of O-SLSs is to protect resources in the optical domain by validation of submitted G.LSP requests. If the optical domain and the IP service domain are under control of the same administrative authority, then there is likely to be a trusted peering relationship between both domains. Conversely, in case of an untrusted peering relationship, the optical domain service provider validates incoming G.LSP requests as per the O-SLS. This validation process can be implemented in the ONE-C. In this case, there exist several mechanisms to install an O-SLS in an ONE-C, e.g., CLI, SNMP, LDAP or COPS. Alternatively, the O-SLS enforcement may be outsourced to another policy entity. An O-SLS offers to accept G.LSP requests at the service level agreed with the IP service domain. The optical domain service provider will provision the optical domain accordingly. A broad range of optical services could be envisioned. As an example, services could be defined with different levels of accessibility, depending on the probability that a G.LSP establishment request is blocked. Moreover, services could also be categorized as protected or non-protected, depending on the offered protection level. All of these service level characteristics influence the resource provisioning process in the optical backbone. Duroyon et al. Expires May 2001 9 draft-duroyon-te-ip-optical-01.txt November 2000 For each G.LSP request, the optical domain service provider may also need to identify the O-SLS for which the request is submitted. Some authentication may be included in the request in order to verify that the rightful IP service provider issued the request. In some cases, this customer might be implicitly derived from the signaling channel on which the G.LSP request was received. The authentication mechanism must be specified in the O-SLS. Although it can be assumed that O-SLSs will be static for the foreseeable future, this draft does not preclude dynamic O-SLSs. These would necessitate some automated form of interaction between the IP service domain and the optical domain. In case of an O-SLS at the O-UNI, this may for instance require the interaction between a Bandwidth Broker (BB) in the IP service domain and a Lambda Broker (LB) in the optical domain. At the level of an O-NNI, this would be between different LBs, acting on behalf of the different optical sub-networks. This automated (re-)negotiation of O-SLSs would in turn call for an automated O-SLS admission control function. Note that this admission control function is different from the validation of G.LSP requests as per the negotiated O-SLS, referred to as O-SLS enforcement. 8. G.LSP triggers As stated in [ip-optical], the G.LSP request triggering process should be part of a stable traffic engineering tool in the IP service domain as opposed to a data-driven shortcut approach, similar to the schemes proposed for IP over ATM networks. Henceforth, an integrated TE-LSP and G.LSP triggering process is proposed at the end of this section to alleviate the shortcomings of the former method and is elaborated below. 8.1 Data-driven shortcut approach for G.LSPs The data-driven shortcut model would imply that the boundary CNEs use traffic measurements to autonomously control the number of G.LSPs that connect them with a set of remote boundary CNEs across the optical domain. For example, boundary CNE A could detect that some of its traffic is reaching boundary CNE B in a multi-hop way. If this traffic trunk is large enough, boundary CNE A might decide to set-up a G.LSP to boundary CNE B, relieving the IP forwarding at all intermediate CNEs on the multi-hop path. In an overlay model, once a G.LSP has been established to a new destination, it should be announced as a (new) IP link in the IP service domain routing database. As such, it can be used by any TE entity in the IP service domain and this IP link may carry several TE-LSPs. This implies that the TE entity in the IP service domain would then be constantly reacting to decisions of the boundary CNEs that are continuously changing the IP topology. Such a layered scheme of G.LSP requests and TE-LSP requests is inefficient and could also break the TE service model, when the Duroyon et al. Expires May 2001 10 draft-duroyon-te-ip-optical-01.txt November 2000 only available G.LSP between two boundary CNEs would be torn down. Such a decision might be based on the valid observation that the traffic pattern has changed such that the existing G.LSP is under- utilized and may be re-directed towards another boundary CNE. However, the G.LSP might still carry TE-LSPs. Turning off the G.LSP has the effect of a link failure and will hence trigger the TE entity in the IP service domain to recover from this failure. Depending on whether the TE-LSP was protected or not, one of the following scenarios will take place. 8.1.1 Protected TE-LSPs TE-LSPs can be used to carry mission critical traffic requiring a fast recovery scheme in case of link failures. Upon such an event, the traffic of the working TE-LSP can be switched to a protect TE- LSP that has been pre-configured along a node- and link-disjoint path. Depending on whether G.LSP is protected or not throughout the optical network, the following alternative is considered: - Protected G.LSP: if the turned-off G.LSP was protected within the optical domain, the TE-LSP path calculation might have selected this IP link for both the working and the protect path of the TE- LSP. In that case, the TE-LSP protect path will not be available and connectivity will be lost. - Unprotected G.LSP: in this case the problem would not arise since the route diversity TE-LSP protect scheme would have selected another IP link for the protect path. 8.1.2 Unprotected TE-LSPs If the TE-LSP was not protected, the source nodes of the TE-LSPs running over the turned-off G.LSP will start a CSPF calculation to find an alternative path. As all source nodes will be competing for the same resources, some G.LSP requests will be blocked and it might take a while before all G.LSPs have been restored. The above scenario equally pertains to the case of any link failure in an IP service domain. However, link failures in an IP service domain may be considered as rare events. This is however not the case when this link failure behavior is the result of a data-driven shortcut approach across an optical backbone. 8.2 Integrated TE-LSP and G.LSP triggering process Given the above shortcoming, boundary CNEs should not autonomously decide to tear down a G.LSP. Yet, it may not always be appropriate to maintain an under-utilized G.LSP. However, a G.LSP should not be turned off until the TE-LSPs it carries, have been re-routed along an alternative path. This might even require an additional G.LSP setup between two other boundary CNEs. All of this calls for a coordinated TE-LSP and G.LSP triggering process, integrated in the Duroyon et al. Expires May 2001 11 draft-duroyon-te-ip-optical-01.txt November 2000 same decision point. This is possible since both responsibilities reside within the IP service domain. The ability to dynamically establish G.LSPs adds an extra dimension to the TE capabilities of an IP service domain. In addition to forwarding packets along non-shortest paths, it is now also possible to (re-)configure the topology of the IP service domain by means of adding, deleting or modifying G.LSPs across the optical backbone. This integrated decision point will use the set of IP SLAs and the derived traffic trunk requirements across the IP service domain (possibly complemented with traffic measurements) to determine the optimal set of G.LSPs and TE-LSPs. Several setup optimization strategies are possible depending on the business model in use between the IP Service domain and the optical domain, and also the assumptions taken on the pre-existing optical topology. The TE decision point has the complete knowledge of the IP Topology, all optical end-points, including their logical, and physical attributes (granularity, protection attributes, _). The different strategies may be chosen among the following: 1- Minimize the number of G.LSPs to be lit up This strategy fits in business models where the optical domain doesn't belong to the service domain, and as such each additional network G.LSP is an additional cost to the service domain. The TE decision point optimizes the number of G.LSPs to set up through the optical domain for a given IP traffic pattern. 2- Add capacity without rearranging optical topology Before triggering new G.LSPs, the TE decision point tries to rearrange TE-LSPs without rearranging the underlying optical topology. 3- Add capacity with specific explicit constraints Some environment may lead to some specific constraints to be taken into account during route computation. One simple example is a mixed ATM / IP network. In this example TE-LSP used by ATM and their underlying G.LSP must not be rearranged during the computation to add optical capacity. The TE decision point optimizes the number of G.LSP (and subsequently TE-LSP topology) with the possibility of pinning down some components (TE-LSP, G.LSP, _) Duroyon et al. Expires May 2001 12 draft-duroyon-te-ip-optical-01.txt November 2000 4- Optimize IP topology without any optical constraint TE decision point optimizes the IP topology without taking any constraint on number of G.LSPs setup. The only constraints taken are in this case coming from the end-points attributes. In addition to the computation algorithm strategy, the TE decision point also takes into account the sort of IP services to be achieved, in order to achieve a consistent restoration between protocol layers. One simple way is to define a linear hierarchy between IP services. 1.- Layer 1 protection - Non-PSC Level Protection This service only applies for IP link built between two PSC- capable end-points. The G.LSP connecting both end-points is totally protected. It means that it will be chosen from a pool of G.LSPs with source and destination drop-side protection (1+1, 1:1, Shared Protection). And in addition the G.LSP will request a network-protected path via the optical network. This service will be mainly seen in a traditional environment where the service domain lies on a very reliable transport layer, dedicated to any fast restoration mechanism. 2.- Diverse Layer 2 _ PSC Level Protection This service also only applies for a G.LSP built between two PSC-capable end-points (for instance, an IP link connection). Two G.LSPs are requested to the optical cloud via the same CNE-to-ONE interface, using source and destination drop-side protected G.LSPs. No optical or SDH/Sonet network protection are required for the G.LSPs. But diverse optical paths are requested for both G.LSPs. This service makes sense in a network architecture where the CNE is locally connected to an ONE, and so the diverse path routing must start at the first ONE of the optical network. 3. Diverse Layer 2 - Network Level Protection This service applies indifferently in a mixed PSC-capable (and particularly for IP services) and non-PSC capable optical environment, and not necessarily at the boundary CNE. Two G.LSPs are requested from the IP service domain using two diverse paths. In this case when the G.LSP request reaches the optical cloud boundary, there is no specific protection requirements towards the optical cloud. Duroyon et al. Expires May 2001 13 draft-duroyon-te-ip-optical-01.txt November 2000 4. No G.LSP protection This service applies when the restoration mechanisms don't rely on pre-existing backup paths. In this case on protection constraints have to be taken into account at the optical layer. As described in this paragraph, in order to create a consistent end-to-end IP Service Model, network devices and TE decision point have to synchronize each other to setup and maintain the adequate and optimal set of G.LSPs and TE-LSPs. The resulting topology is based on IP services requirements (Protection scheme, _) and computation strategies (Business models, _). This leads to needs for potential new standardization items, as information exchange between routers and TE decision point (in case of G.LSP setup failure, _). This will be tackle via subsequent studies. 9. G.LSP advertisement to the IP layer The decision point may thus trigger the set-up of an additional G.LSP to an already connected boundary CNE. Alternatively, it may trigger a rearrangement of existing G.LSPs, or the establishment of a G.LSP to a boundary CNE that could previously not be reached through the optical domain. It might very well be that the decision point triggers a boundary CNE to drop a G.LSP if its capacity is no longer needed to meet the requirements of the IP SLAs. In order to make efficient use of the dynamicity of the G.LSP create requests, the routing protocol parameters should be dynamically configurable as well. This section outlines a proposal to achieve a seamless integration of a new G.LSP within the IP service domain for the overlay model by means of automatic configuration. As soon as a G.LSP to a particular boundary CNE has been lit up, it is assumed that it is promoted to an operational IP link. In case of, e.g., regular SDH/SONET framing, this is achieved by running PPP protocol on the newly established G.LSP. 9.1 G.LSP set-up to a previously unreachable boundary CNE The draft [ompls-ospf] defines the different facets of the creation of an IP link in case of a peer-to-peer model and proposes to use the newly established IP link as a forwarding adjacency in the IP service domain. The overlay model imposes different requirements on the IP layer of the boundary CNEs. Indeed, once the first G.LSP is established between two boundary CNEs and promoted as IP link, it is to be advertised as a point-to-point link for IP routing in order to Duroyon et al. Expires May 2001 14 draft-duroyon-te-ip-optical-01.txt November 2000 initiate the IP connectivity between the two boundary CNEs. And subsequently it will allow IP reachability between the associated IP service domains. Two cases must be considered. The G.LSP is promoted to an IP link connecting: - two boundary CNEs of the same Autonomous System (IGP peering), or, - two boundary CNEs of different Autonomous Systems (eBGP peering). The IGP and BGP peering cases do not require the same kind of configuration and are described separately. Note that in case of an IGP peer, it is necessary that the G.LSP be bi-directional, because IGP protocols require a bi-directional transport layer. Bi-directional G.LSP setup is further detailed within [g-mpls] and [onni-framework]. From an addressing point of view, the Packet switch capable end- points can be unnumbered (and, e.g., identified by the Router Id of the boundary CNE), or numbered through initial configuration, but different from the IP address assigned to the UNI signaling agents (UNI-Client and UNI-Network) terminating the signaling channel. It has to be noticed again that within the overlay model, the signaling channel identification is neither known nor advertised throughout the IP service domain. 9.1.1 IGP support Once the first IP link is established between two boundary CNEs and configured to support an IGP peer, the boundary CNEs need to get the proper information: - The first requirement is to select IS-IS or OSPF for the newly formed IP link. - In addition, link routing parameters such as timers and area numbers might have to be specified. For instance, timers in OSPF should be consistent at both ends of the IP link. - Also, link metrics (e.g., resource classes, etc.) need to be inherited or configured for use by IP routing. - Finally, the IGP protocol is enabled and the IP link is advertised. These parameters have to be accessible and are automatically configured (prior to or at the time of G.LSP establishment) by the Duroyon et al. Expires May 2001 15 draft-duroyon-te-ip-optical-01.txt November 2000 decision point of the IP service domain to efficiently deploy the IP service on top of the G.LSP. However, some of the routing parameters (e.g., OSPF timers) may be defaulted to pre-determined values. Those values must be defined network-wide and be consistent between all possible boundary CNE pairs. The decision point should be allowed to overwrite those parameters at the setup time of the G.LSP. 9.1.2 eBGP peering In the case of an inter-domain G.LSP, static route configuration specifying the BGP peer (most probably a virtual interface of the remote boundary CNE) should be configured in the local boundary CNE in order to set up the TCP session used in BGP. In addition, an IP SLA is going to be negotiated between the autonomous systems and routing policies are going to be configured on both ends of the G.LSPs. As opposed to the IGP peering case, triggering of inter-domain G.LSPs will very likely not arise from an automated process because of the BGP peering negotiation procedure. 9.2 Set-up of an additional G.LSP In addition to the option described in 9.1 (creation of a new stand-alone IP link with the new G.LSP and advertisement to the routing protocol), a second option is now possible, which is to create an additional G.LSP to an existing IP link that forms a bundled link [mpls-bundle]. In this case there is no new configuration necessary for the IGP or BGP routing layer but only interactions internal to the boundary CNEs. This bundle is advertised as a single IP link. The G.LSP in itself may be unidirectional, and hence the bundle could have an asymmetric bandwidth. - The boundary CNE upgrades the bandwidth of the bundle link based on the characteristics of this new G.LSP. - The new G.LSP is included in the load balancing mechanism that distributes the traffic amongst the component G.LSPs of the bundled link, e.g., proportional to their bandwidth. - The addition of a new G.LSP to a bundle does not impact the routing topology. Only the new bandwidth of the IP link is advertised within the IP service domain. The other characteristics of the IP link, e.g., the resource classes, remain unchanged. Duroyon et al. Expires May 2001 16 draft-duroyon-te-ip-optical-01.txt November 2000 In the case described in this section, the only mandatory information to be automatically configured by the decision point is the bundle identifier to which the G.LSP is to be added. 9.3 Rearrangement of an existing G.LSP Within the optical network, two alternatives could be considered for the rearrangement of an existing G.LSP: - Either the non-destructive modification of an already established G.LSP. In this case, the source and destination termination-points of the G.LSP can not be changed, but other parameters such as bandwidth and network protection could be modified without disrupting the working G.LSP. - Or the destructive modification of an already established G.LSP. This case is the straightforward combination of G.LSP tear-down followed by a new G.LSP set-up towards a different destination. 10. References [diffserv-framework] Y.Bernet et al, "A Framework for Differentiated Services", Internet Draft, draft-ietf-diffserv- framework-03.txt, February 1999. [g-mpls] Peter Ashwood-Smith et al., "Generalized MPLS _ Signaling Functional Description", Internet draft, draft-ietf-mpls- generalized-signaling-00.txt, October 2000. [ip-optical] James Luciani et al., " IP over Optical Networks _ A Framework", Internet draft, draft-ip-optical-framework-00.txt, February 2000. [ompls-isis] K. Kompella et al., "IS-IS Extensions in Support of MPL(ambda)S", Internet Draft, draft-kompella-isis-ompls-extensions- 00.txt, July 2000. [ompls-ospf] K. Kompella et al., "OSPF Extensions in Support of MPL(ambda)S", Internet Draft, draft-kompella-ospf-ompls-extensions- 00.txt, July 2000. [mpls-bundle] K. Kompella et al., "Link Bundling in MPLS Traffic Engineering", Internet Draft, draft-kompella-mpls-bundle-02.txt, July 2000. [onni-framework] D.Papadimitriou et al,. "Optical NNI Framework and Signaling Requirements", Work in progress, draft-papadimitriou- onni-framework-00.txt, November 2000. [ouni-framework] B.Rajagopalan et al., `Signaling Requirements at the Optical UNI', Internet Draft, draft-bala-mpls-optical-uni- signaling-00.txt, July 2000. Duroyon et al. Expires May 2001 17 draft-duroyon-te-ip-optical-01.txt November 2000 [OIF2000.125.2] B. Rajagopalan et al., "User Network Interface v1.0 Proposal", OIF Contribution 125.2, October 2000. [OIF2000.200] D. Pendarakis et al., "Signaling Transport Mechanisms for UNI 1.0", OIF Contribution 200, September 2000. [OIF2000.261.1] D. Papadimitriou et al., "Address Registration and Resolution", OIF Contribution 261, November 2000. 11. Acknowledgments The authors would like to thank Emmanuel Desmet, Sitaram Kalipatnapu and Gert Grammel for their constructive comments. 12. Author's Addresses Olivier Duroyon Alcatel USA 15036 Conference Center Drive Chantilly, VA, 20151 Phone: (703) 679 6415 Email: olivier.d.duroyon@usa.alcatel.com Rudy Hoebeke Alcatel Bell Francis Wellesplein 1 2018 Antwerp, Belgium Phone: (32) 3/240.84.39 Email: rudy.hoebeke@alcatel.be Hans De Neve Alcatel Bell Francis Wellesplein 1 2018 Antwerp, Belgium Phone: (32) 3/240.76.94 Email: hans.de_neve@alcatel.be Dimitri Papadimitriou Alcatel NSG-NA Francis Wellesplein 1 2018 Antwerp, Belgium Phone: (32) 3/240.84.91 Email: dimitri.papadimitriou@alcatel.be Duroyon et al. Expires May 2001 18 --------------403930F32E603AFB32B60F64-- From owner-mpls@UU.NET Wed Dec 6 11:48:47 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18512 for ; Wed, 6 Dec 2000 11:48:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskp01746; Wed, 6 Dec 2000 16:47:27 GMT Received: by mail-control.mail.uu.net id QQjskp15976 for mpls-outgoing; Wed, 6 Dec 2000 16:46:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjskp15968 for ; Wed, 6 Dec 2000 16:46:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjskp08500 for ; Wed, 6 Dec 2000 16:46:38 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjskp06505 for ; Wed, 6 Dec 2000 16:46:38 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA05349 for mpls@uu.net; Wed, 6 Dec 2000 11:46:37 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjskp15881 for ; Wed, 6 Dec 2000 16:46:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjskp10223 for ; Wed, 6 Dec 2000 16:46:05 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjskp05637 for ; Wed, 6 Dec 2000 16:46:04 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17857; Wed, 6 Dec 2000 11:45:57 -0500 (EST) Message-Id: <200012061645.LAA17857@ietf.org> To: IETF-Announce:; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: mpls@UU.NET From: The IESG Subject: Document Action: MPLS Loop Prevention Mechanism to Experimental Date: Wed, 06 Dec 2000 11:45:57 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft 'MPLS Loop Prevention Mechanism' as an Experimental Protocol. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are David Oran and Rob Coltun. From owner-mpls@UU.NET Wed Dec 6 11:49:28 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18668 for ; Wed, 6 Dec 2000 11:49:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskp09047; Wed, 6 Dec 2000 16:48:07 GMT Received: by mail-control.mail.uu.net id QQjskp16042 for mpls-outgoing; Wed, 6 Dec 2000 16:47:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjskp15996 for ; Wed, 6 Dec 2000 16:47:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjskp10770 for ; Wed, 6 Dec 2000 16:46:16 GMT Received: from newdev.harvard.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212]) id QQjskp05939 for ; Wed, 6 Dec 2000 16:46:16 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id LAA15588; Wed, 6 Dec 2000 11:46:16 -0500 (EST) Date: Wed, 6 Dec 2000 11:46:16 -0500 (EST) From: Scott Bradner Message-Id: <200012061646.LAA15588@newdev.harvard.edu> To: mpls@UU.NET, tom@ennovatenetworks.com Subject: RE: Resend with correct addresses: Note from the volume cabal for ietf-announce (and other lists) Sender: owner-mpls@UU.NET Precedence: bulk > many of us have been waiting for the iesg's decision on > where our respective drafts are to be relocated. i suppose > the above means that any such draft that is not already on > a wg agenda is bumped for this meeting. you should talk to the chairs of the wg/bof session to see what they plan to do Scott From owner-mpls@UU.NET Wed Dec 6 11:55:59 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20649 for ; Wed, 6 Dec 2000 11:55:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskp21874; Wed, 6 Dec 2000 16:54:38 GMT Received: by mail-control.mail.uu.net id QQjskp16768 for mpls-outgoing; Wed, 6 Dec 2000 16:54:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjskp16761 for ; Wed, 6 Dec 2000 16:53:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjskp03709 for ; Wed, 6 Dec 2000 16:53:32 GMT Received: from beamer.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: beamer.mchh.siemens.de [194.138.158.163]) id QQjskp11636 for ; Wed, 6 Dec 2000 16:53:31 GMT Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA16586; Wed, 6 Dec 2000 17:52:53 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA27134; Wed, 6 Dec 2000 17:53:28 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Dec 2000 17:53:27 +0100 Message-ID: From: Heiles Juergen To: "'John Drake'" , Heiles Juergen , mpls@UU.NET Cc: ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] GMPLS - Hierarchies Date: Wed, 6 Dec 2000 17:53:05 +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 John, I agree that at the endpoints of a trail (in ITU terms), where the signal that is connected through the network is terminated, the same processing for the payload is needed (either multiplexing or any other kind of adaptation). However this is not part of the LSP and of the LSR functionality. Consider a Optical Channel/lambda LSP. According to the document - as I read it - the LSP is should be terminated on a LSR with Lambda switch capable (LSC) interfaces (e.g. an optical switch), hwoever the paylaod of the Optical Channel is a SDH or IP signal which require TDM or packet processing. For sure you want to connect your signal between endpoints with the same client processing, but this is only of interest for the selection of the correct endpoints, but not for the LSP set-up itself. The LSP set up should only care about the signal itself and not about its payload. FAX and telphones use the same infrastrucutre for the setup of the connection, you have to be shure to connect the same endpoints by using up to correct number or you have a automatic selection of the correct payload processing using signaling. This signaling should only apply to theendpoints and not to intermediate nodes. Furthermore a LSP -at least for circuit switching - doesn't have to start and end at the trail termination where you extract your payload. A LSP could be used only for a sub part of the overall connection, e.g. a DS1 signal starts in a user domain with tradional TMN path setup or even manual connections, the DS1 comes to a operator which uses GMPLS for path -setup (in this case a permanent connection set-up by himself as the user doesn't support the UNI). The LSP starts in the middleof the overall DS1 connection and no access to the paylaod of the DS1 is requried at that point. Regards Juergen > -----Original Message----- > From: John Drake [SMTP:jdrake@calient.net] > Sent: Wednesday, December 06, 2000 5:14 PM > To: 'Heiles Juergen'; mpls@UU.NET > Cc: ip-optical@lists.bell-labs.com > Subject: RE: [IP-Optical] GMPLS - Hierarchies > > Jergen, > > An LSP has an two endpoints. At the ingress endpoint, a node is > multiplexing stuff into a given LSP. At the egress endpoint, a node is > demultiplexing stuff from that LSP. If the ingress and egress endpoints > aren't multiplexing and demultiplexing stuff consistently, how is stuff able > to successfully transit the LSP? > > Thanks, > > John > > -----Original Message----- > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] > Sent: Wednesday, December 06, 2000 4:34 AM > To: mpls@UU.NET > Cc: ip-optical@lists.bell-labs.com > Subject: [IP-Optical] GMPLS - Hierarchies > > > draft-ietf-mpls-generalized-signaling-01 mentions in the introduction a > hierachy with fiber switching at the top followed by lambda, time-slot and > packet switching and clearly distinguish between these levels. I don't agree > with this view that a LSP starts and ends on the same LSR type and onyl > nesting of LSPs of different LSR types is possible. > Take for example an optical cross-connect that switches fiber between its > ports (=> fiber switch capable). The single or multiple lambdas on this > fiber might be directly after the cross-connect or later combined with other > signals from other fibers in a WDM system => (lambda switch capable) or a > TDM technique is used to combine several of these signals to a higher > bandwidth signal (e.g. going from 2.5 to 10 Gbit/s) (=> time switch > capable). So a LSP that starts at LSC device ends up at a TSC device and > might have a LSC device in between. Even an interchange of LSPs between > packet and circuit switch capable devices is possible, take for a example > circuit emulation via ATM. With circuit emulation you can also have a LSP > that starts on a TSC device nested into a LSP that starts on a PSC device. > A LSP represents a connection through the network/sub-network for a certain> > signal. This is independent of the switching technologies along the route > and at the end as long as the specific signal is supported. At both ends > access to the specific signal has to be provided, but it doesn't matter if > e.g. a 1.5 Mbit/s signal is transported on a time-slot of a TDM system, on a > single wavelength of a WDM system (not economic), over a CDMA radio system > or with circuit emulation over an ATM network. > The Hierarchy is defined by different signals nested into each other > (client/server relationship), but not by the switching types. > > Regards > > Juergen Heiles > > > > > > > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Wed Dec 6 12:10:01 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24331 for ; Wed, 6 Dec 2000 12:10:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskq12461; Wed, 6 Dec 2000 17:08:40 GMT Received: by mail-control.mail.uu.net id QQjskq00529 for mpls-outgoing; Wed, 6 Dec 2000 17:08:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjskq00514 for ; Wed, 6 Dec 2000 17:08:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjskq15784 for ; Wed, 6 Dec 2000 17:06:55 GMT Received: from gw.tropicnetworks.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: gw.tropicnetworks.com [209.87.233.9]) id QQjskq02846 for ; Wed, 6 Dec 2000 17:06:54 GMT Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for cmr2.ash.ops.us.uu.net [198.5.241.40]) with SMTP; 6 Dec 2000 17:08:06 UT Received: from pcneustadter ([10.1.2.74]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with SMTP id AAA503A; Wed, 6 Dec 2000 12:08:37 -0500 From: "Udo Neustadter" To: "Peter Ashwood-Smith" Cc: , Subject: RE: Re: GMPLS - Hierarchies Date: Wed, 6 Dec 2000 12:03:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3A2E541C.629609C8@americasm01.nt.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit May understanding is that the hierarchy build is a logical one, and no real labels are added to the flow. The flow is identified by the specific TDM channels. I just can not see where the waste of bandwidth is coming from. Udo >... > > This is most likely to occur with TDM and OXC equipement at the OC-192 and OC-48 rates where there is a >close mapping between the OXC lambda and the TDM signal bandwidth. It won't work sell so well at lower rates >because you waste too much bandwidth and are forced into a heirarchy whether you want one or not. > > Cheers, > > Peter Ashwood-Smith >... From owner-mpls@UU.NET Wed Dec 6 12:24:59 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27537 for ; Wed, 6 Dec 2000 12:24:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjskr01742; Wed, 6 Dec 2000 17:23:38 GMT Received: by mail-control.mail.uu.net id QQjskr02534 for mpls-outgoing; Wed, 6 Dec 2000 17:23:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjskr02507 for ; Wed, 6 Dec 2000 17:22:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjskr24572 for ; Wed, 6 Dec 2000 17:21:13 GMT Received: from falla.videotron.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: falla.videotron.net [205.151.222.106]) id QQjskr28278 for ; Wed, 6 Dec 2000 17:21:13 GMT Received: from MartinPicard ([24.202.11.202]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with SMTP id <0G5500CNYPDQUT@falla.videotron.net> for mpls@UU.NET; Wed, 6 Dec 2000 12:17:50 -0500 (EST) Date: Wed, 06 Dec 2000 12:09:01 -0500 From: Martin Picard Subject: Re: Lack of outgoing label was Re: (Reply) RE: (Reply) To: Keith.Schuettpelz@go.ecitele.com, esaheb@hyperchip.com Cc: mpls@UU.NET Message-id: <01d401c05fa7$3adfda60$ca0bca18@videotron.ca> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 References: <852569AD.005A2D64.00@ussmtp01.ftl.telematics.com> X-Priority: 3 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQjskr01742 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA27537 Keith, Wether or not the LSR are capable of popping the stack should be determined at session initialization according to mpls-arch. But, this is assumed to be the case when peer LSRs are not ATM or F/R LSRs (lsp-spec section 6). Now, when an LSRs knows that its peer is capable of popping the stack, it should distribute an Implicit Null label for its ultimate destination prefixes (mpls-arch section 4.1.5). Then, the upstream LSR has no choice but to do penultimate hop pop since it's been requested with Implicit Null. (mpls-arch section 3.16) Although designed to be optional and flexible eventually, it looks like for now, with LSRs not ATM or F/R, the penultimate hop pop behavior is optionnal but "ASSUMED" for now. mp > > > > According to section 3.16 of MPLS arch, > > "An LSR which is capable of popping the label stack at all MUST do > penultimate hop popping when so requested by its downstream label > distribution peer." > > So I assume that when you say PHP is optional and not mandatory, > you mean the downstream LSR can optionally choose whether or not > to request PHP. > > However, it appears that the upstream LSR is required to support > PHP (if it is capable of popping the label stack at all). > > Do you agree? > > Keith > > > > > RE: Lack of outgoing label was Re: (Reply) > > RE: (Reply)Yes, you are right Eyad. > > Penultimate Hop Pop is an optional behavior. > > mp > > > > ----- Message d'origine ----- > > De : Eyad Saheb > > > > ---------------------------------------------------------------------------- ---- Ŕ : 'Martin Picard' > Envoyé : 6 décembre, 2000 10:14 > Objet : RE: Lack of outgoing label was Re: (Reply) RE: (Reply) > > > Last I looked, PHP was not a mandatory req in the MPLS arch. > > Eyad From owner-mpls@UU.NET Wed Dec 6 13:04:55 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02879 for ; Wed, 6 Dec 2000 13:04:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsku28439; Wed, 6 Dec 2000 18:03:33 GMT Received: by mail-control.mail.uu.net id QQjsku12670 for mpls-outgoing; Wed, 6 Dec 2000 18:03:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsku12430 for ; Wed, 6 Dec 2000 18:02:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsku28789 for ; Wed, 6 Dec 2000 18:02:24 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjsku28730 for ; Wed, 6 Dec 2000 18:02:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA13899 for mpls@uu.net; Wed, 6 Dec 2000 13:02:23 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsku09843 for ; Wed, 6 Dec 2000 18:01:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsku07974 for ; Wed, 6 Dec 2000 18:01:31 GMT Received: from lumen.chromisys.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lumen.calient.net [63.102.55.200]) id QQjsku05969 for ; Wed, 6 Dec 2000 18:01:30 GMT Received: by nt_d2300.chromisys.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Dec 2000 10:01:29 -0800 Message-ID: From: John Drake To: "'Heiles Juergen'" , mpls@UU.NET Cc: ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] GMPLS - Hierarchies Date: Wed, 6 Dec 2000 10:01:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Juergen, The capabilities of the LSP endpoints are an integral part of the LSP and are advertised as link characteristics in the link state database. I.e., if you have a link between a PXC and a router, then the unidirectional link from the PXC to the router is advertised as PSC, while the link from the router to the PXC is advertised as LSC. If you had an FA-LSP between two routers that transited multiple PXCs, then both unidirectional LSPs would be advertised as PSC. In the latter case, the FA LSP may transit intermediate PXC links which are LSC. It is the case that the encoding of the LSP needs to be consistent across all of the links that it transits, which I think was your concern. In your example, if you wanted to establish an FA LSP of type LSC, then it would begin and terminate on links in the links state database that are advertised as links of type LSC, not not PSC or T(DM)SC. If one wanted to create another LSP, whose endpoints were either PSC or T(DM)SC, then that LSP could transit the FA LSP of type LSC. You should probably read the GMPLS routing drafts, which explain this in more detail. John -----Original Message----- From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] Sent: Wednesday, December 06, 2000 8:53 AM To: John Drake; Heiles Juergen; mpls@UU.NET Cc: ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] GMPLS - Hierarchies John, I agree that at the endpoints of a trail (in ITU terms), where the signal that is connected through the network is terminated, the same processing for the payload is needed (either multiplexing or any other kind of adaptation). However this is not part of the LSP and of the LSR functionality. Consider a Optical Channel/lambda LSP. According to the document - as I read it - the LSP is should be terminated on a LSR with Lambda switch capable (LSC) interfaces (e.g. an optical switch), hwoever the paylaod of the Optical Channel is a SDH or IP signal which require TDM or packet processing. For sure you want to connect your signal between endpoints with the same client processing, but this is only of interest for the selection of the correct endpoints, but not for the LSP set-up itself. The LSP set up should only care about the signal itself and not about its payload. FAX and telphones use the same infrastrucutre for the setup of the connection, you have to be shure to connect the same endpoints by using up to correct number or you have a automatic selection of the correct payload processing using signaling. This signaling should only apply to theendpoints and not to intermediate nodes. Furthermore a LSP -at least for circuit switching - doesn't have to start and end at the trail termination where you extract your payload. A LSP could be used only for a sub part of the overall connection, e.g. a DS1 signal starts in a user domain with tradional TMN path setup or even manual connections, the DS1 comes to a operator which uses GMPLS for path -setup (in this case a permanent connection set-up by himself as the user doesn't support the UNI). The LSP starts in the middleof the overall DS1 connection and no access to the paylaod of the DS1 is requried at that point. Regards Juergen > -----Original Message----- > From: John Drake [SMTP:jdrake@calient.net] > Sent: Wednesday, December 06, 2000 5:14 PM > To: 'Heiles Juergen'; mpls@UU.NET > Cc: ip-optical@lists.bell-labs.com > Subject: RE: [IP-Optical] GMPLS - Hierarchies > > Jergen, > > An LSP has an two endpoints. At the ingress endpoint, a node is > multiplexing stuff into a given LSP. At the egress endpoint, a node is > demultiplexing stuff from that LSP. If the ingress and egress endpoints > aren't multiplexing and demultiplexing stuff consistently, how is stuff able > to successfully transit the LSP? > > Thanks, > > John > > -----Original Message----- > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] > Sent: Wednesday, December 06, 2000 4:34 AM > To: mpls@UU.NET > Cc: ip-optical@lists.bell-labs.com > Subject: [IP-Optical] GMPLS - Hierarchies > > > draft-ietf-mpls-generalized-signaling-01 mentions in the introduction a > hierachy with fiber switching at the top followed by lambda, time-slot and > packet switching and clearly distinguish between these levels. I don't agree > with this view that a LSP starts and ends on the same LSR type and onyl > nesting of LSPs of different LSR types is possible. > Take for example an optical cross-connect that switches fiber between its > ports (=> fiber switch capable). The single or multiple lambdas on this > fiber might be directly after the cross-connect or later combined with other > signals from other fibers in a WDM system => (lambda switch capable) or a > TDM technique is used to combine several of these signals to a higher > bandwidth signal (e.g. going from 2.5 to 10 Gbit/s) (=> time switch > capable). So a LSP that starts at LSC device ends up at a TSC device and > might have a LSC device in between. Even an interchange of LSPs between > packet and circuit switch capable devices is possible, take for a example > circuit emulation via ATM. With circuit emulation you can also have a LSP > that starts on a TSC device nested into a LSP that starts on a PSC device. > A LSP represents a connection through the network/sub-network for a certain> > signal. This is independent of the switching technologies along the route > and at the end as long as the specific signal is supported. At both ends > access to the specific signal has to be provided, but it doesn't matter if > e.g. a 1.5 Mbit/s signal is transported on a time-slot of a TDM system, on a > single wavelength of a WDM system (not economic), over a CDMA radio system > or with circuit emulation over an ATM network. > The Hierarchy is defined by different signals nested into each other > (client/server relationship), but not by the switching types. > > Regards > > Juergen Heiles > > > > > > > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Wed Dec 6 17:09:42 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09836 for ; Wed, 6 Dec 2000 17:09:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjslk25556; Wed, 6 Dec 2000 22:08:21 GMT Received: by mail-control.mail.uu.net id QQjslk28677 for mpls-outgoing; Wed, 6 Dec 2000 22:07:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjslk28662 for ; Wed, 6 Dec 2000 22:07:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjslk17383 for ; Wed, 6 Dec 2000 22:07:36 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjslk24350 for ; Wed, 6 Dec 2000 22:07:35 GMT Received: from cryndent01.mww.bt.com by gandalf (local) with ESMTP; Wed, 6 Dec 2000 22:07:10 +0000 Received: by cryndent01.mww.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 6 Dec 2000 22:07:05 -0000 Message-ID: To: neustadter@tropicnetworks.com, petera@nortelnetworks.com Cc: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: Re: GMPLS - Hierarchies Date: Wed, 6 Dec 2000 22:06:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk We really must start to get layering in into our heads......the user-plane *must* apply a well-known piece of characteristic information between the source and sink of a trail. These are the 'true' labels....the fact that some control-plane sets them up is almost incidental. The real arguments starts as to the *nature* of that control-plane, but as I said that is orthogonal to the fact that LSPs do create real hierarchies (in the user-plane). neil > -----Original Message----- > From: Udo Neustadter [SMTP:neustadter@tropicnetworks.com] > Sent: Wednesday, December 06, 2000 5:03 PM > To: Peter Ashwood-Smith > Cc: mpls; ip-optical > Subject: RE: Re: GMPLS - Hierarchies > > May understanding is that the hierarchy build is a logical one, and no > real > labels are added to the flow. The flow is identified by the specific TDM > channels. I just can not see where the waste of bandwidth is coming from. > > Udo > > >... > > > > This is most likely to occur with TDM and OXC equipement at the OC-192 > and OC-48 rates where there is a > >close mapping between the OXC lambda and the TDM signal bandwidth. It > won't > work sell so well at lower rates > >because you waste too much bandwidth and are forced into a heirarchy > whether you want one or not. > > > > Cheers, > > > > Peter Ashwood-Smith > >... From owner-mpls@UU.NET Wed Dec 6 17:09:54 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09889 for ; Wed, 6 Dec 2000 17:09:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjslk15344; Wed, 6 Dec 2000 22:08:33 GMT Received: by mail-control.mail.uu.net id QQjslk28688 for mpls-outgoing; Wed, 6 Dec 2000 22:07:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjslk28667 for ; Wed, 6 Dec 2000 22:07:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjslk17328 for ; Wed, 6 Dec 2000 22:07:35 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjslk24331 for ; Wed, 6 Dec 2000 22:07:35 GMT Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP; Wed, 6 Dec 2000 22:07:07 +0000 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 6 Dec 2000 22:06:54 -0000 Message-ID: To: jdrake@calient.net, Juergen.Heiles@icn.siemens.de, mpls@UU.NET Cc: ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] GMPLS - Hierarchies Date: Wed, 6 Dec 2000 22:06:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Spot on John. Its called layering in functional architecture. Each LSP creates a layer network. It has a source and a sink point at which certain characteristic information (eg the shim header for MPLS, or some other header if say ATM-based MPLS is being used (actually also the AAL)) is applied and removed respectively. The header is only relevant between these points and *should* have no direct impact on other client or server layers during normal operation (things are different under failures...I must get that OAM ID out!)......if it does there is danger of layer violation causing both backward and future cross-layer evolutionary problems, re my various mail concerns on EXP, TTL and PHP issues that some will have seen wrt to the shim header and the point of LSP trail termination and server->client (layer) adaptation. I really believe if more people had a better understanding of this (ie func arch) then we could make better and more accurate progress. Many of the questions I see coming up are because what are to me/others basic functional arch concepts are not understood or being applied. Can I make a plea to those who have access to G.805 to go and have a look at it and those that don't check out the Book from Andy Reid (a close colleague of mine) and Mike Sexton [Broadband Networking, Hardcover - 589 pages 1st edition (January 15, 1997) Artech House; ISBN: 0890065780]. This work was found essential to unambiguously define SONET/SDH......not by operators, but by manufacturers ......and is in common usage today in many parts of our industry. It is also applicable to all other layer network technologies I can think of. Neil > From: John Drake [SMTP:jdrake@calient.net] > > Jergen, > > An LSP has an two endpoints. At the ingress endpoint, a node is > multiplexing stuff into a given LSP. At the egress endpoint, a node is > demultiplexing stuff from that LSP. If the ingress and egress endpoints > aren't multiplexing and demultiplexing stuff consistently, how is stuff > able > to successfully transit the LSP? > > Thanks, > > John > > -----Original Message----- > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de] > Sent: Wednesday, December 06, 2000 4:34 AM > To: mpls@UU.NET > Cc: ip-optical@lists.bell-labs.com > Subject: [IP-Optical] GMPLS - Hierarchies > > > draft-ietf-mpls-generalized-signaling-01 mentions in the introduction a > hierachy with fiber switching at the top followed by lambda, time-slot and > packet switching and clearly distinguish between these levels. I don't > agree > with this view that a LSP starts and ends on the same LSR type and onyl > nesting of LSPs of different LSR types is possible. From owner-mpls@UU.NET Wed Dec 6 17:11:00 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10365 for ; Wed, 6 Dec 2000 17:11:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjslk27679; Wed, 6 Dec 2000 22:09:40 GMT Received: by mail-control.mail.uu.net id QQjslk28807 for mpls-outgoing; Wed, 6 Dec 2000 22:09:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjslk28736 for ; Wed, 6 Dec 2000 22:08:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjslk17993 for ; Wed, 6 Dec 2000 22:07:47 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjslk14067 for ; Wed, 6 Dec 2000 22:07:47 GMT Received: from chqlubnt02.lon.bt.com by marvin (local) with ESMTP; Wed, 6 Dec 2000 22:07:10 +0000 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 6 Dec 2000 22:06:57 -0000 Message-ID: To: Juergen.Heiles@icn.siemens.de, jdrake@calient.net, mpls@UU.NET Cc: ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] GMPLS - Hierarchies Date: Wed, 6 Dec 2000 22:06:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > Furthermore a LSP -at least for circuit switching - doesn't have to start > and end at the trail termination where you extract your payload. NH=> I fudamentally disagree *if* we are adhering to functional arch. > A LSP could be used only for a sub part of the overall connection, e.g. a > DS1 signal starts in a user domain with tradional TMN path setup or even > manual connections, the DS1 comes to a operator which uses GMPLS for path > -setup (in this case a permanent connection set-up by himself as the user > doesn't support the UNI). The LSP starts in the middleof the overall DS1 > connection and no access to the paylaod of the DS1 is requried at that > point. NH=> The DSI signal is 'an LSP' in its own right......it is, after all, a clear layer network trail entity. The fact that it may be served (on link connections, which are a partition of the end-end DS1 trail) by lower layer "LSPs" (which could be a DS3, VC4, ODU, etc.......and which themselves are trails *but* only between their points of source/sink) is academic.....the DS1 trail is completely unaware of this, and the layering recursion of client_links=>server_trails can recurse many times.......its stops at the duct network. Your example *must*, and indeed does, fit this. neil > From owner-mpls@UU.NET Wed Dec 6 21:23:18 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06980 for ; Wed, 6 Dec 2000 21:23:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsmb16790; Thu, 7 Dec 2000 02:21:57 GMT Received: by mail-control.mail.uu.net id QQjsmb05085 for mpls-outgoing; Thu, 7 Dec 2000 02:21:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsmb05080 for ; Thu, 7 Dec 2000 02:21:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsmb05338 for ; Thu, 7 Dec 2000 02:20:46 GMT Received: from chonnam.chonnam.ac.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: chonnam.chonnam.ac.kr [168.131.33.5]) id QQjsmb14787 for ; Thu, 7 Dec 2000 02:20:43 GMT Received: from yojiny (pc85079.chonnam.ac.kr [168.131.85.79] (may be forged)) by chonnam.chonnam.ac.kr (8.10.0/8.10.0) with SMTP id eB7233f17420; Thu, 7 Dec 2000 11:03:03 +0900 Message-ID: <007801c05ff4$8f407900$4f5583a8@chonnam.ac.kr> Reply-To: "Yang Yo-Jin" From: "Yang Yo-Jin" To: "Eyad Saheb" Cc: References: Subject: Re: in topology-driven how is ospf work? Date: Thu, 7 Dec 2000 11:22:33 +0900 Organization: Univ. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0075_01C0603F.FE9A38E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0075_01C0603F.FE9A38E0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 UkU6IGluIHRvcG9sb2d5LWRyaXZlbiBob3cgaXMgb3NwZiB3b3JrP0hpIEV5YWQgU2FoZWINCmkg bWVhbiBieSAicG9zc2libGUgcGF0aCIgYSBwYWlyIG9mIHNvdXJjZSBhbmQgZGVzdGluYXRpb24s IG9yIGVuZ3Jlc3MgYW5kIGVncmVzcyB0aGF0IHdhcyBsaW5rZWQgDQpieSBzaG9ydGVzdCBwYXRo IC4NCg0KYW5kIHdoYXQgaSB3YW50IHRvIGtub3cgaXMgaW4gdG9wb2xvZ3ktZHJpdmVuLCB3aGV0 aGVyIGFsbG9jYXRpb24gb2YgTGFiZWwgd2FzIGRvbmUgYnkgcm91dGluZyBwcm90aG9jb2wgb3Ig YnkgYW5vdGhlciBzaWduYWxpbmcgcHJvdG9jb2wgbGlrZSBMRFA/DQoNCmkgd2lsbCBhcHByZWNp YXRlIHlvdXIgdGhvdWdodCBvbiB0aGlzIHF1ZXN0aW9uLg0KcmVnYXJkcy95b2ppbnkNCg0KICAt LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBFeWFkIFNhaGViIA0KICBUbzog J1lhbmcgWW8tSmluJyANCiAgU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDA3LCAyMDAwIDEyOjI1 IEFNDQogIFN1YmplY3Q6IFJFOiBpbiB0b3BvbG9neS1kcml2ZW4gaG93IGlzIG9zcGYgd29yaz8N Cg0KDQogIHNlZSBpbi1saW5lIGNvbW1lbnRzLi4gDQoNCiAgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gDQogIEZyb206IG93bmVyLW1wbHNAVVUuTkVUIFttYWlsdG86b3duZXItbXBsc0BVVS5O RVRdT24gQmVoYWxmIE9mIFlhbmcgWW8tSmluIA0KICBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVy IDA2LCAyMDAwIDI6MTcgQU0gDQogIFRvOiBHYWJvciBLb3Jvc3N5IChFVEgpIA0KICBDYzogbXBs c0BVVS5ORVQgDQogIFN1YmplY3Q6IFJlOiBpbiB0b3BvbG9neS1kcml2ZW4gaG93IGlzIG9zcGYg d29yaz8gDQoNCg0KDQogID5IaSBHYWJvciwgDQogID4gDQogID5hcyBpIGtuZXcsIGluIHRvcG9s b2d5LWRyaXZlbiBMU1IgaGF2ZSBMYWJlbCB0aGF0IHdhcyBhbGxvY2F0ZSBhbGwgcGF0aCwgDQog ID4gICAgICAgICAgICAgICAgaW4gdHJhZmZpYy1kcml2ZW4gTFNSIGFsbG9jYXRlIExhYmVsIHRv IHJlcXVpcmVkIHBhdGggb3IgbG9hZGVkIHBhdGggDQogID4gICAgICAgICAgICAgICAgbW9yZSB0 aGFuIHNvbWUgcG9pbnQgZGV0ZXJtaW5lZCBieSBhZG1pbmlzdHJhdG9yLiANCiAgPiAgICAgICAg ICAgICAgICBhbmQgaW4gTVBMUywgb25lIG9mIG1vc3QgaW1wb3J0YW50IHRoaW5nIGlzIHRvIHJl ZHVjZSBsYWJlbC4gDQogID4gDQogID5idXQgYWZ0ZXIgc2VlaW5nIHlvdXIgbWFpbCwgDQogID5h cyBpIHVuZGVyc3RhbmQsIHRvZGF5IGFsbCBNUExTIHJvdXRlciBhbGxvY2F0ZSBMYWJlbCB0byBh bGwgcG9zc2libGUgcGF0aC4gDQogID5pbiB0aGF0IGNhc2UsIExTUiBoYXZlIGJpZyBvdmVyaGVh ZCB0byBtYW5hZ2UgdG8gTGFiZWwgdGhhdCB3YXMgbm90IHJlZmVycmVkLiANCg0KICBIb3cgY2Fu IHRoaXMgaGFwcGVuID8gIElmIExTUiBhbGxvY2F0ZSBsYWJlbCB0byBBTEwgUE9TU0lCTEUgcGF0 aHMsIHRoZW4gYW55IG90aGVyIA0KICBvbmVzIGFyZSBJTVBPU1NJQkxFLCBjb3JyZWN0ID8gIElu IGZhY3QsIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRvcG9sb2d5LWRyaXZlbiBMU1JzIGNhbiANCiAg cGVyZm9ybSB0cmFmZmljLWRyaXZlbiBsYWJlbCBhbGxvY2F0aW9uIHNpbmNlIHRoYXQgd2Fzbid0 IHRoZSBpbnRlbmRlZCBjb25maWd1cmF0aW9uLiANCiAgICAgDQogID5hbSBpIHJpZ2h0PyANCiAg PiANCiAgPkkgYXBwcmVjaWF0ZSB5b3VyIHRob3VnaHQgb24gdGhpcyBtYXR0ZXIuIA0KICA+cmVn YXJkcyAvIHlvamlueSANCg0K ------=_NextPart_000_0075_01C0603F.FE9A38E0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5SRTogaW4gdG9wb2xvZ3ktZHJpdmVuIGhvdyBpcyBv c3BmIHdvcms/PC9USVRMRT4NCjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD1rc19jXzU2MDEtMTk4NyI+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNS41MC40NTIyLjE4MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hF QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+SGkgRXlhZCBTYWhlYjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj5pIG1lYW4gYnkgInBvc3NpYmxlIHBhdGgiJm5ic3A7YSBwYWlyIG9mIA0Kc291 cmNlIGFuZCBkZXN0aW5hdGlvbiwgb3IgZW5ncmVzcyZuYnNwO2FuZCBlZ3Jlc3MgdGhhdCB3YXMg bGlua2VkIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5i eSBzaG9ydGVzdCBwYXRoJm5ic3A7LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+YW5kIHdoYXQgaSB3YW50IHRvIGtub3cgaXMgaW4gDQp0b3BvbG9neS1kcml2 ZW4sJm5ic3A7d2hldGhlciBhbGxvY2F0aW9uIG9mIExhYmVsIHdhcyBkb25lIGJ5IHJvdXRpbmcg DQpwcm90aG9jb2wmbmJzcDtvciBieSZuYnNwO2Fub3RoZXIgc2lnbmFsaW5nIHByb3RvY29sIGxp a2UgTERQPzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+aSB3 aWxsIGFwcHJlY2lhdGUgeW91ciB0aG91Z2h0IG9uIHRoaXMgDQpxdWVzdGlvbi48L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+cmVnYXJkcy95b2ppbnk8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPiZuYnNw OzwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7 IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAw MCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBw dCCxvLiyIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIA0KICBz dHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogMTBwdCCxvLiyOyBmb250LWNvbG9yOiBi bGFjayI+PEI+RnJvbTo8L0I+IDxBIA0KICB0aXRsZT1lc2FoZWJAaHlwZXJjaGlwLmNvbSBocmVm PSJtYWlsdG86ZXNhaGViQGh5cGVyY2hpcC5jb20iPkV5YWQgU2FoZWI8L0E+IA0KICA8L0RJVj4N CiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCCxvLiyIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPXUwMDIw MzY4QGNob25uYW0uY2hvbm5hbS5hYy5rciANCiAgaHJlZj0ibWFpbHRvOnUwMDIwMzY4QGNob25u YW0uY2hvbm5hbS5hYy5rciI+J1lhbmcgWW8tSmluJzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9 IkZPTlQ6IDEwcHQgsby4siI+PEI+U2VudDo8L0I+IFRodXJzZGF5LCBEZWNlbWJlciAwNywgMjAw MCAxMjoyNSANCiAgQU08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCCxvLiyIj48Qj5T dWJqZWN0OjwvQj4gUkU6IGluIHRvcG9sb2d5LWRyaXZlbiBob3cgaXMgb3NwZiANCiAgd29yaz88 L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxQPjxGT05UIHNpemU9Mj5zZWUgaW4tbGluZSBj b21tZW50cy4uPC9GT05UPiA8L1A+DQogIDxQPjxGT05UIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj5Gcm9tOiA8QSANCiAgaHJlZj0ibWFp bHRvOm93bmVyLW1wbHNAVVUuTkVUIj5vd25lci1tcGxzQFVVLk5FVDwvQT4gWzxBIA0KICBocmVm PSJtYWlsdG86b3duZXItbXBsc0BVVS5ORVQiPm1haWx0bzpvd25lci1tcGxzQFVVLk5FVDwvQT5d T24gQmVoYWxmIE9mIFlhbmcgDQogIFlvLUppbjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj5TZW50 OiBXZWRuZXNkYXksIERlY2VtYmVyIDA2LCAyMDAwIDI6MTcgDQogIEFNPC9GT05UPiA8QlI+PEZP TlQgc2l6ZT0yPlRvOiBHYWJvciBLb3Jvc3N5IChFVEgpPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0y PkNjOiANCiAgPEEgaHJlZj0ibWFpbHRvOm1wbHNAVVUuTkVUIj5tcGxzQFVVLk5FVDwvQT48L0ZP TlQ+IDxCUj48Rk9OVCBzaXplPTI+U3ViamVjdDogDQogIFJlOiBpbiB0b3BvbG9neS1kcml2ZW4g aG93IGlzIG9zcGYgd29yaz88L0ZPTlQ+IDwvUD48QlI+DQogIDxQPjxGT05UIHNpemU9Mj4mZ3Q7 SGkgR2Fib3IsPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCAN CiAgc2l6ZT0yPiZndDthcyBpIGtuZXcsIGluIHRvcG9sb2d5LWRyaXZlbiBMU1IgaGF2ZSBMYWJl bCB0aGF0IHdhcyBhbGxvY2F0ZSBhbGwgDQogIHBhdGgsPC9GT05UPiA8QlI+PEZPTlQgDQogIHNp emU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBpbiB0cmFmZmlj LWRyaXZlbiBMU1IgYWxsb2NhdGUgTGFiZWwgdG8gcmVxdWlyZWQgcGF0aCBvciBsb2FkZWQgcGF0 aCANCiAgPC9GT05UPjxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQogIG1vcmUgdGhhbiBzb21lIHBvaW50IGRldGVybWluZWQgYnkgYWRt aW5pc3RyYXRvci48L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIGFuZCBpbiBNUExTLCBvbmUgb2YgbW9zdCBpbXBvcnRh bnQgdGhpbmcgaXMgdG8gcmVkdWNlIGxhYmVsLiA8L0ZPTlQ+PEJSPjxGT05UIA0KICBzaXplPTI+ Jmd0OzwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7YnV0IGFmdGVyIHNlZWluZyB5b3VyIG1h aWwsPC9GT05UPiANCiAgPEJSPjxGT05UIHNpemU9Mj4mZ3Q7YXMgaSB1bmRlcnN0YW5kLCB0b2Rh eSBhbGwgTVBMUyByb3V0ZXIgYWxsb2NhdGUgTGFiZWwgdG8gDQogIGFsbCBwb3NzaWJsZSBwYXRo LjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7aW4gdGhhdCBjYXNlLCBMU1IgaGF2ZSBiaWcg DQogIG92ZXJoZWFkIHRvIG1hbmFnZSB0byBMYWJlbCB0aGF0IHdhcyBub3QgcmVmZXJyZWQuPC9G T05UPiA8L1A+DQogIDxQPjxGT05UIHNpemU9Mj5Ib3cgY2FuIHRoaXMgaGFwcGVuID8mbmJzcDsg SWYgTFNSIGFsbG9jYXRlIGxhYmVsIHRvIEFMTCANCiAgUE9TU0lCTEUgcGF0aHMsIHRoZW4gYW55 IG90aGVyPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPm9uZXMgYXJlIElNUE9TU0lCTEUsIA0KICBj b3JyZWN0ID8mbmJzcDsgSW4gZmFjdCwgSSBkb24ndCBiZWxpZXZlIHRoYXQgdG9wb2xvZ3ktZHJp dmVuIExTUnMgY2FuPC9GT05UPiANCiAgPEJSPjxGT05UIHNpemU9Mj5wZXJmb3JtIHRyYWZmaWMt ZHJpdmVuIGxhYmVsIGFsbG9jYXRpb24gc2luY2UgdGhhdCB3YXNuJ3QgdGhlIA0KICBpbnRlbmRl ZCBjb25maWd1cmF0aW9uLjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsgPC9G T05UPjxCUj48Rk9OVCANCiAgc2l6ZT0yPiZndDthbSBpIHJpZ2h0PzwvRk9OVD4gPEJSPjxGT05U IHNpemU9Mj4mZ3Q7PC9GT05UPiA8QlI+PEZPTlQgDQogIHNpemU9Mj4mZ3Q7SSBhcHByZWNpYXRl IHlvdXIgdGhvdWdodCBvbiB0aGlzIG1hdHRlci48L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0y PiZndDtyZWdhcmRzIC8geW9qaW55PC9GT05UPiA8L1A+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hU TUw+DQo= ------=_NextPart_000_0075_01C0603F.FE9A38E0-- From owner-mpls@UU.NET Wed Dec 6 22:54:46 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27393 for ; Wed, 6 Dec 2000 22:54:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsmh16806; Thu, 7 Dec 2000 03:53:20 GMT Received: by mail-control.mail.uu.net id QQjsmh22609 for mpls-outgoing; Thu, 7 Dec 2000 03:52:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsmh22604 for ; Thu, 7 Dec 2000 03:52:49 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsmh29826 for ; Thu, 7 Dec 2000 03:52:09 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjsmh15213 for ; Thu, 7 Dec 2000 03:52:09 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 TAA18759 for ; Wed, 6 Dec 2000 19:52:14 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id WAA07473 for mpls@uu.net; Wed, 6 Dec 2000 22:52:07 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsmg21967 for ; Thu, 7 Dec 2000 03:44:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsmg06678 for ; Thu, 7 Dec 2000 03:44:11 GMT Received: from jake.micromuse.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.micromuse.com [194.131.185.75]) id QQjsmg20776 for ; Thu, 7 Dec 2000 03:44:11 GMT Received: from costner.micromuse.com (costner [194.131.185.122]) by jake.micromuse.co.uk (Switch-2.1.0/Switch-2.1.0) with ESMTP id eB73gh411764 for ; Thu, 7 Dec 2000 03:42:43 GMT Received: from dfiore.netops.com (dfiore.netops.com [207.17.13.75]) by costner.micromuse.com (8.9.1/8.9.1) with ESMTP id DAA28613 for ; Thu, 7 Dec 2000 03:59:18 GMT Date: Wed, 06 Dec 2000 22:44:05 -0500 From: David Fiore Reply-To: David Fiore To: mpls@UU.NET Subject: mplsInterfaceFailedLabelLookup Message-ID: <5080000.976160645@dfiore.netops.com> X-Mailer: Mulberry/2.0.6b1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit According to the MIB, mplsInterfaceFailedLabelLookup counts the number of times a LSP arriving at an MPLS interface was discarded because there was no matching cross-connect. Aside from the situation where a user has simply misconfigured static paths (so we are talking about the situation where the LSRs dynamically setup LSPs), it would seem to me that seeing this counter going up would be an indcation that there was some significant level of route instability at layer 3. Am I understanding the situation correctly? Are there other common scenarios whereby this obejct would be seen increasing? ADthanksVANCE -dbf ------------------------------------------------------------------------ \\\|/// \\ _ _ // ( @ @ ) +-------------oOQo-(_)-oQOo----------+ | +----------+ | | | __ __ | David Fiore | | | | \ / | | Staff Engineer | | | | \/ | | Micromuse Corp. | | | | |\/| | | | | | | | | | | 914.747.7630 (o) | | | +-+ +-+ | | | +----------+ david@micromuse.com | +----------------------Oooo----------+ oooO ( ) ( ) ) / \ ( (_/ \_) From owner-mpls@UU.NET Wed Dec 6 23:36:49 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02796 for ; Wed, 6 Dec 2000 23:36:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsmk11593; Thu, 7 Dec 2000 04:35:28 GMT Received: by mail-control.mail.uu.net id QQjsmk06796 for mpls-outgoing; Thu, 7 Dec 2000 04:35:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsmk06791 for ; Thu, 7 Dec 2000 04:35:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsmk12204 for ; Thu, 7 Dec 2000 04:34:52 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjsmk19729 for ; Thu, 7 Dec 2000 04:34:51 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id XAA23480 for mpls@uu.net; Wed, 6 Dec 2000 23:34:51 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsmk06772 for ; Thu, 7 Dec 2000 04:34:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsmk18837 for ; Thu, 7 Dec 2000 04:34:18 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjsmk09643 for ; Thu, 7 Dec 2000 04:34:17 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 XAA18147; Wed, 6 Dec 2000 23:33:40 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id XAA06684; Wed, 6 Dec 2000 23:33:40 -0500 (EST) Message-Id: <200012070433.XAA06684@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET, agenda@ietf.org Cc: swallow@cisco.com, oran@cisco.com, rcoltun@redback.com, vijay@cosinecom.com Subject: MPLS Agenda for SD Date: Wed, 06 Dec 2000 23:33:40 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Folks - Attached is the MPLS agenda. The first hour of the MPLS slot will be used to discuss CCAMP and the relationship of MPLS to CCAMP. Caveat - based on what happens there, the attached agenda could be modified. There is a large number of drafts being presented in other work groups for which I had agenda requests to also present in MPLS. Given the current uncertainties surrounding our charter, and the attendant inability to adjudicate any new work I see no point in presenting these in MPLS as well. Even with that done, the schedule is full. Given the nature of the session from 9-10, I assume that we won't be able to begin MPLS work at 10:00 sharp. So I've scheduled 75 minutes on Monday and the full two hours on Thursday. Our ADs requested that all of the Generalized MPLS work occur on Thursday. ...George ====================================================================== MPLS Work Group Monday Shortly after 10 - 11:30 ====================================================================== F. LeFaucher 10 ietf-mpls-diff-te-ext-00 ietf-mpls-diff-te-reqts-00 A. Farrell 10 ietf-mpls-ldp-ft-00 O. Paridaens 10 draft-schrijvp-mpls-ldp-end-to-end-auth-02.txt A. Paraschiv 5 draft-ietf-mpls-lsp-query-01.txt Sriganesh Kini 10 kini-restoration-shared-backup-00 kini-rsvp-lsp-restoration-00 Ken Owens 15 draft-chang-mpls-path-protection-02.txt draft-chang-rsvpte-path-protection-ext-01.txt draft-owens-crldp-path-protection-ext-00.txt G. Swallow 5 swallow-rsvp-bypass-label-01 A. Iwata 10 iwata-mpls-crankback-00 Thursday 15:30 - 17:30 ====================================================================== K. Kompella 20 ietf-mpls-lsp-hierarchy-01 kompella-mpls-bundle-04 kompella-mpls-unnum-02 ietf-mpls-rsvp-unnum-00 ietf-mpls-crldp-unnum-00 L. Berger 20 ietf-mpls-generalized-signaling-00 ietf-mpls-generalized-rsvp-te-00 ietf-mpls-generalized-cr-ldp-00 V. Sharma 20 bernstein-gmpls-optical-00 bms-optical-sdhsonet-mpls-control-frmwrk-00 mack-crane-gmpls-signaling-enhancements-00 Jonathan Lang 15 ietf-mpls-lmp-01 Andre Fredette 15 fredette-lmp-wdm-00 Aboul-Magd 10 ietf-mpls-ldp-optical-uni-00 Liaw/Yu 10 yu-mpls-rsvp-oif-uni-ext-00 Lin 10 lin-mpls-sigalign-00 ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Dec 7 02:40:42 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15656 for ; Thu, 7 Dec 2000 02:40:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsmw18617; Thu, 7 Dec 2000 07:39:21 GMT Received: by mail-control.mail.uu.net id QQjsmw22627 for mpls-outgoing; Thu, 7 Dec 2000 07:38:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsmw22622 for ; Thu, 7 Dec 2000 07:38:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsmw10795; Thu, 7 Dec 2000 07:38:34 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjsmw14416; Thu, 7 Dec 2000 07:38:31 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 07 Dec 2000 13:10:50 +0530 Received: from arumugamr (arumugamr.future.futsoft.com [10.0.6.51]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id eB7D8K213019; Thu, 7 Dec 2000 18:38:21 +0530 Received: by localhost with Microsoft MAPI; Thu, 7 Dec 2000 12:57:27 +0530 Message-Id: <01C0604D.403C0F00.arumugamr@future.futsoft.com> From: Arumugam R Reply-To: "arumugamr@future.futsoft.com" To: "'awduche@uu.net'" , "'dhg@juniper.net'" , "'lberger@labn.net'" , "'mpls@uu.net'" , "'swallow@cisco.com'" , "'tonyl@home.net'" To: "'vsriniva@cosinecom.com'" Subject: Question on Non support of ERO Object. Date: Thu, 7 Dec 2000 12:57:26 +0530 Organization: FSL 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, In section 4.3.7 Non support of ERO in Rsvp-Lsp-Tunnel-07 draft, it is said that An RSVP router that does not recognize the EXPLICIT_ROUTE object sends a PathErr with the error code "Unknown object class" toward the sender. This causes the path setup to fail. The sender should notify management that a LSP cannot be established and possibly take action to continue the reservation without the EXPLICIT_ROUTE or via a different explicit route. My question is how the sender knows that the intermediate node does not support ERO object alone and support other TE objects such as RSVP-TE session, Label Request Object etc. The sender once it receives "Unknown Object class", if my assumption is right it has to assume that the intermediate node supports only RSVP and not RSVP-TE. Hence it will try to establish a path via a different explicit route and not through the same intermediate node without an ERO, unless otherwise it is sure of the behavior of the node. I think the statement underlined can be removed, else there is any specific purpose for keeping the above statement. Any reply from authors. Thanks in advance Regards Aru ------------------------------------------------------------------------ -------- Arumugam R Senior Software Engineer, Future Software Ltd. Chennai - 35 Phone-4330550 Ext-363 ------------------------------------------------------------------------ -------- From owner-mpls@UU.NET Thu Dec 7 03:21:02 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26818 for ; Thu, 7 Dec 2000 03:21:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsmz22325; Thu, 7 Dec 2000 08:19:40 GMT Received: by mail-control.mail.uu.net id QQjsmz06935 for mpls-outgoing; Thu, 7 Dec 2000 08:19:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsmz06930 for ; Thu, 7 Dec 2000 08:19:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsmz11531 for ; Thu, 7 Dec 2000 08:19:00 GMT Received: from csa.iisc.ernet.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjsmz21348 for ; Thu, 7 Dec 2000 08:18:53 GMT Received: from ada.csa.iisc.ernet.in (IDENT:root@ada.csa.iisc.ernet.in [144.16.67.35]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id NAA23952; Thu, 7 Dec 2000 13:45:20 +0530 Received: from localhost (prasanna@localhost) by ada.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id NAA11461; Thu, 7 Dec 2000 13:48:14 +0530 X-Authentication-Warning: ada.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Thu, 7 Dec 2000 13:48:14 +0530 (IST) From: Gaitonde Anandprasanna To: david.charlap@marconi.com cc: mpls@UU.NET Subject: Doubt regarding having Explaicit Route Object in Path Err. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Thanx for replying to my queries. I have one more question. In the draft of RSVP-TE section 4.3.6 Forward Compatibility It is anticipated that new subobjects may be defined over time. A node which encounters an unrecognized subobject during its normal ERO processing sends a PathErr with the error code "Routing Error" and error value of "Bad Explicit Route Object" toward the sender. The EXPLICIT_ROUTE object is included, truncated (on the left) to the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ offending subobject. The presence of an unrecognized subobject which ^^^^^^^^^^^^^^^^^^^^^^^^ is not encountered in a node's ERO processing SHOULD be ignored. It is passed forward along with the rest of the remaining ERO stack. I did not understand how we can add the partial ERO (till the offending subobject to the Path ERR. Is there any Provision??? Thanx in advance Pras From owner-mpls@UU.NET Thu Dec 7 04:52:49 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17585 for ; Thu, 7 Dec 2000 04:52:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsnf27130; Thu, 7 Dec 2000 09:51:28 GMT Received: by mail-control.mail.uu.net id QQjsnf24013 for mpls-outgoing; Thu, 7 Dec 2000 09:51:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsnf23986 for ; Thu, 7 Dec 2000 09:51:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsnf24771 for ; Thu, 7 Dec 2000 09:51:00 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjsnf26607 for ; Thu, 7 Dec 2000 09:51:00 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA06355 for mpls@uu.net; Thu, 7 Dec 2000 04:51:00 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsnf23943 for ; Thu, 7 Dec 2000 09:50:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsnf21691 for ; Thu, 7 Dec 2000 09:49:59 GMT Received: from hoemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQjsnf25532 for ; Thu, 7 Dec 2000 09:49:59 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA20572 for ; Thu, 7 Dec 2000 04:49:59 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id EAA20548 for ; Thu, 7 Dec 2000 04:49:58 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA11107; Thu, 7 Dec 2000 10:49:57 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA11087; Thu, 7 Dec 2000 10:49:53 +0100 (MET) Message-ID: <3A2F5D3F.92E85B81@lucent.com> Date: Thu, 07 Dec 2000 10:49:51 +0100 From: Maarten Vissers Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] GMPLS - Hierarchies References: Content-Type: multipart/mixed; boundary="------------EB745EBAA42DDE976ADFBCC0" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------EB745EBAA42DDE976ADFBCC0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All: It might be the moment to introduce some more terminology to differentiate between the two cases. In the ATM/FR interconnection the terms "network interworking" and "service interworking" are being used. Refer e.g. to FRF.5 and FRF.8 (see http://www.frforum.com/5000/5000index.html). This has then be used as basis for an extension of ITU-T Rec. G.805: - network interworking has been present in G.805 from day one as the default "client/server relation", in which the complete client signal (i.e. actual traffic plus trail overhead) is transparently transported within the payload of the server signal - service interworking has been added (section 5.5/G.805 (03/00) in the form of a generic definition of "layer network interworking". The importance here is that not only the traffic is forwarded, but also the associated trail overhead/OAM information. -------------------- 5.5/G.805 (03/00) Layer network interworking The objective of layer network interworking is to provide an end-to-end trail between different types of layer network trail terminations. This requires interworking of characteristic information as different layer networks have per definition different characteristic information. In general the adapted information of different layer networks for the same client layer network is also different, although this is not necessarily the case. Layer networking may therefor require the interworking of adapted information. The trail overhead of a layer network can be defined in terms of semantics and syntax. Provided that the same semantics exist in two layer networks, the trail overhead can be interworked by passing on the semantics from one layer network to the other in the appropriate syntax, as defined by the characteristic information. In other words layer network interworking shall be transparent for the semantics of the trail overhead. If both layer networks have a different set of semantics, the layer network interworking is restricted to the common set of semantics. The layer network interworking function has to terminate (insert, supervise) the semantics that are not interworked. Figure 19/G.805 - Layer network interworking Layer network interworking is accomplished through an interworking processing function as depicted in Figure 19. The interworking processing function supports an interworking link connection between two layer network connections. The interworking link connection is special in the sense that it is asymmetric, delimited by different types of ports. Also special because it is in general only transparent for a specified set of client layers. An interworking link is a topological component that represents a bridge between two layer networks. The interworking link creates a "super layer network", defined by the complete set of access groups that can be interworked for a specified set of client layer networks. Layer network interworking function uni-directional: A transport processing function which converts characteristic information of one layer network to the characteristic information of another layer network. The integrity of end-to-end performance and maintenance information is maintained. The function may be limited to a set of client layer networks. Layer network interworking function bi-directional: A transport processing function that consist of a pair of co-located uni-directional service interworking functions, one for the interworking form layer network X to Y and the other for the interworking from layer network Y to X. ---------------------- Regards, Maarten --------------EB745EBAA42DDE976ADFBCC0 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Lucent Technologies Nederland;NA&CPSE version:2.1 email;internet:mvissers@lucent.com adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------EB745EBAA42DDE976ADFBCC0-- From owner-mpls@UU.NET Thu Dec 7 05:05:23 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA20198 for ; Thu, 7 Dec 2000 05:05:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsng10644; Thu, 7 Dec 2000 10:04:03 GMT Received: by mail-control.mail.uu.net id QQjsng05840 for mpls-outgoing; Thu, 7 Dec 2000 10:03:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsng05819 for ; Thu, 7 Dec 2000 10:03:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsng01512 for ; Thu, 7 Dec 2000 10:01:54 GMT Received: from red.gdansk.sprint.pl by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.gdansk.sprint.pl [195.116.73.86]) id QQjsng08599 for ; Thu, 7 Dec 2000 10:01:53 GMT Received: from localhost (IDENT:maks@localhost [127.0.0.1]) by red.gdansk.sprint.pl (8.10.2/8.10.2) with ESMTP id eB7A1lr08546 for ; Thu, 7 Dec 2000 11:01:47 +0100 Date: Thu, 7 Dec 2000 11:01:47 +0100 (CET) From: Maksymilian Milkowski To: mpls@UU.NET Subject: Hop Count TLV Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi all, this is Hop Count TLV encoding (from Internet Draft "LDP Specification draft-ietf-mpls-ldp-11.txt): 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Hop Count (0x0103) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HC Value | +-+-+-+-+-+-+-+-+ HC Value is described as "1 octet unsigned integer hop count value". OK Length field is not described and i have doubts whether it is needed - - HC field is always 1 octet long. Am I wrong ? Thanks in advance, Maksymilian Milkowski From owner-mpls@UU.NET Thu Dec 7 06:46:56 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02705 for ; Thu, 7 Dec 2000 06:46:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsnn28221; Thu, 7 Dec 2000 11:45:34 GMT Received: by mail-control.mail.uu.net id QQjsnn24552 for mpls-outgoing; Thu, 7 Dec 2000 11:45:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsnn24452 for ; Thu, 7 Dec 2000 11:45:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsnm13241 for ; Thu, 7 Dec 2000 11:43:51 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjsnm25551 for ; Thu, 7 Dec 2000 11:43:51 GMT Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP; Thu, 7 Dec 2000 11:43:08 +0000 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Thu, 7 Dec 2000 11:42:50 -0000 Message-ID: To: mvissers@lucent.com, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] GMPLS - Hierarchies Date: Thu, 7 Dec 2000 11:18:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Marten......just one small observation to clarify what is really meant by service interworking....see below: > - service interworking has been added (section 5.5/G.805 (03/00) in > the form of a generic definition of "layer network interworking". > The importance here is that not only the traffic is forwarded, but > also the associated trail overhead/OAM information. > NH=> I would have put this slightly differently........ - Payload is moved from layer X trail to (peer) layer Y trail intact and transparently, ie the payload area must be the same size. - Overhead functionality is *mapped* between the specific O/H of the layer X trail and the layer Y trail. This mapping may not be 100% complete, since there could be functionality provided in the layer X trail that is not present in the layer Y trail (or vice versa). For example, in ATM there is an AIS function but this does not exist in FR. In FR there is a BECN function, but this does not exist in ATM. ATM uses LLC-SNAP client (ie payload) encapsulation but FR uses NPLID. etc. neil From owner-mpls@UU.NET Thu Dec 7 07:36:07 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08373 for ; Thu, 7 Dec 2000 07:36:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsnq13126; Thu, 7 Dec 2000 12:34:45 GMT Received: by mail-control.mail.uu.net id QQjsnq09165 for mpls-outgoing; Thu, 7 Dec 2000 12:34:24 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsnq09158 for ; Thu, 7 Dec 2000 12:34:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsnq11702 for ; Thu, 7 Dec 2000 12:32:47 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjsnq23769 for ; Thu, 7 Dec 2000 12:32:46 GMT Received: from cirwm3nt01.nor.bt.com by gandalf (local) with ESMTP; Thu, 7 Dec 2000 12:32:02 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Thu, 7 Dec 2000 12:32:00 -0000 Message-ID: To: Shahram_Davari@pmc-sierra.com, mpls@UU.NET Subject: RE: drat-martini-l2circuit-enacap/trans-mpls Date: Thu, 7 Dec 2000 12:31:48 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Shahram......There are lots of problems with OAM cells in ATM. They are far too long winded to go into on mail here, but if anyone wants to know talk to me at San Diego or give me a call on +44 1 604 820 724. We will need OAM for MPLS (user-plane), and this should learn from the ATM history. neil > -----Original Message----- > From: Shahram Davari [SMTP:Shahram_Davari@pmc-sierra.com] > Sent: Tuesday, December 05, 2000 6:45 PM > To: 'mpls@uu.net' > Subject: drat-martini-l2circuit-enacap/trans-mpls > > Hi, > > I have some questions from the authors of these drafts. > > 1) Section 5.2.1 of the Encap draft says: > > "A router that does not support transport of OAM cells MUST discard > incoming MPLS frames on an ATM VC LSP that contain an ATM cell with the > high-order bit of the PTI set to 1". > > Since in the MPLS network, only the ingress LSR and egress LSR are ware of > the existence of OAM cells, and since the egress LSR does not need to do > any thing special for the received OAM cells from the user data cells, I > assume by "router" the authors mean ingress LSR. If so then why does it > says "incoming MPLS frames"? > > 2) Section 4.2.1 of the Trans draft says: > > "A router that does not support transport of ATM cells MUST discard > incoming MPLS frames on an ATM VC LSP that contain a control word with the > T bit set. > > This section looks very similar to section 5.2.1 of the Encap draft, while > this specific sentence is completely different. Is there a mistake or it > is correct? If it is correct then why is this subject in the OAM section? > Sine the sentence is talking about received MPLS frames, it seems that it > is talking about an egress LSR, but why should an egress LSR that can't > support ATM distribute the VC label in the first place? > > 3) Section 5.2.1 of Encap draft and section 4.2.1 of Trans draft say: > "The LSR MAY optionally be configured to periodically generate F5 > end-to-end loop back OAM cells on a VC. ... If the LSR fails to receive a > response to an F5 end-to-end loop back OAM cell for a pre-defined period > of time it MUST withdraw the label mapping for the VC." > Is this talking about ingress LSR or egress LSR? > 4) Section 5.2.1 of Encap draft and section 4.2.1 of Trans draft say: > "If an ingress LSR receives an AIS F5 OAM cell, fails to receive a > pre-defined number of the End-to-End loop OAM cells, or a physical > interface goes down, it MUST withdraw the label mappings for all VCs > associated with the failure. When a VC label mapping is withdrawn, the > egress LSR SHOULD generate AIS F5 OAM cells on the VC associated with the > withdrawn label mapping. " > I always thought that LDP label withdrawal is initiated from downstream > (egress). Could you please explain how the ingress LSR can withdraw a > label that doesn't belong to it? > > 5) Section 5.2.1 of Encap draft says: > > "A router that supports transport of OAM cells MUST follow the procedures > outlined in [7] section 8 for mode 0 only" > I think it needs to be mentioned that performance OAM cells can't be used > with the AAL5 based transmission (due to possible displacement). > Regards, > Shahram Davari > Systems Engineer > Product Research Group > PMC-Sierra, Inc. (Ottawa) > Phone: (613) 271-4018 > Fax: (613) 271-7007 From owner-mpls@UU.NET Thu Dec 7 07:44:35 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09732 for ; Thu, 7 Dec 2000 07:44:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsnq13083; Thu, 7 Dec 2000 12:43:13 GMT Received: by mail-control.mail.uu.net id QQjsnq09604 for mpls-outgoing; Thu, 7 Dec 2000 12:42:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsnq09596 for ; Thu, 7 Dec 2000 12:42:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsnq25037 for ; Thu, 7 Dec 2000 12:41:18 GMT Received: from gorilla.mchh.siemens.de by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQjsnq10412 for ; Thu, 7 Dec 2000 12:41:17 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 NAA09709; Thu, 7 Dec 2000 13:40:32 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA09009; Thu, 7 Dec 2000 13:40:59 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 13:40:58 +0100 Message-ID: From: Heiles Juergen To: "'neil.2.harrison@bt.com'" , Heiles Juergen , jdrake@calient.net, mpls@UU.NET Cc: ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] GMPLS - Hierarchies Date: Thu, 7 Dec 2000 13:40:21 +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 Neil, I think this is a fundamental question we have to anwser: Is the LSP always identical to a trail in the transport plane? In my view not necessarly. The LSP could also be a sub-network connection. Consider in the future a VC-4 trail crossing several operator domains. Some operators can automatically set-up the VC--4 path through their network using GMPLS. Other operators still use todays method with path-setup via the TMN. The operator with GMPLS sets-up a SPC for this VC-4 (and not any server layer) through its network. The set-up request for this LSP comes from the TMN and not via a UNI/NNI as the other operator or the user at the end-point doesn't support it. In this case the LSP spans only a part/sub-network connection of the overall VC-4 trail. I might be also only a definition problem. What is a LSP, the overall connection through the network or only the part that is set-up using GMPLS signaling? Juergen > -----Original Message----- > From: neil.2.harrison@bt.com [SMTP:neil.2.harrison@bt.com] > Sent: Wednesday, December 06, 2000 11:07 PM > To: Juergen.Heiles@icn.siemens.de; jdrake@calient.net; mpls@UU.NET > Cc: ip-optical@lists.bell-labs.com > Subject: RE: [IP-Optical] GMPLS - Hierarchies > > > > > Furthermore a LSP -at least for circuit switching - doesn't have to start > > and end at the trail termination where you extract your payload. > NH=> I fudamentally disagree *if* we are adhering to functional > arch. > > A LSP could be used only for a sub part of the overall connection, e.g. a > > DS1 signal starts in a user domain with tradional TMN path setup or even > > manual connections, the DS1 comes to a operator which uses GMPLS for path > > -setup (in this case a permanent connection set-up by himself as the user > > doesn't support the UNI). The LSP starts in the middleof the overall DS1 > > connection and no access to the paylaod of the DS1 is requried at that > > point. > NH=> The DSI signal is 'an LSP' in its own right......it is, after > all, a clear layer network trail entity. The fact that it may be served (on > link connections, which are a partition of the end-end DS1 trail) by lower > layer "LSPs" (which could be a DS3, VC4, ODU, etc.......and which themselves > are trails *but* only between their points of source/sink) is > academic.....the DS1 trail is completely unaware of this, and the layering > recursion of client_links=>server_trails can recurse many times.......its > stops at the duct network. > Your example *must*, and indeed does, fit this. > neil > > > From owner-mpls@UU.NET Thu Dec 7 08:35:02 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17420 for ; Thu, 7 Dec 2000 08:35:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsnu02014; Thu, 7 Dec 2000 13:33:40 GMT Received: by mail-control.mail.uu.net id QQjsnu24799 for mpls-outgoing; Thu, 7 Dec 2000 13:33:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsnu24791 for ; Thu, 7 Dec 2000 13:33:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsnu00112 for ; Thu, 7 Dec 2000 13:33:10 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjsnu18133 for ; Thu, 7 Dec 2000 13:33:10 GMT Received: from cclmsent02.lon.bt.com by gandalf (local) with ESMTP; Thu, 7 Dec 2000 13:32:43 +0000 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Thu, 7 Dec 2000 13:32:32 -0000 Message-ID: To: NunoS@ptinovacao.pt, Juergen.Heiles@icn.siemens.de, jdrake@calient.net, mpls@UU.NET Cc: ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] GMPLS - Hierarchies Date: Thu, 7 Dec 2000 13:32:26 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > So the question is indeed, is the functional architecture defined in > G.805 > applicable to the MPLS/MPlambaS worlds? > How does this cope with G.cls (connectionless) work? > Excellent question Nuno. I and some colleagues have been discussing this in BT for a while. Indeed one of my colleagues has a Rapportuership for this very issue in ITU SG13. Only problem is finding the time to set it all down for IP and MPLS.....but it really ought to be done at some point, and the sooner the better. I don't really want to open a debate up here on specific functional entities (ie like the ones you suggested in your response), but I will flag this up internally to my collegues and try to see if we can get some action going on this. I know there are lots of people tuned-in to this list who understand the benefits of func arch descriptions and I am sure would like to see some activity here. Neil From owner-mpls@UU.NET Thu Dec 7 08:36:49 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17631 for ; Thu, 7 Dec 2000 08:36:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsnu23135; Thu, 7 Dec 2000 13:35:28 GMT Received: by mail-control.mail.uu.net id QQjsnu24846 for mpls-outgoing; Thu, 7 Dec 2000 13:35:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsnu24841 for ; Thu, 7 Dec 2000 13:35:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsnu00134 for ; Thu, 7 Dec 2000 13:33:10 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjsnu20469 for ; Thu, 7 Dec 2000 13:33:10 GMT Received: from chqlubnt02.lon.bt.com by gandalf (local) with ESMTP; Thu, 7 Dec 2000 13:32:39 +0000 Received: by chqlubnt02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Thu, 7 Dec 2000 13:32:23 -0000 Message-ID: To: Juergen.Heiles@icn.siemens.de, jdrake@calient.net, mpls@UU.NET Cc: ip-optical@lists.bell-labs.com Subject: RE: [IP-Optical] GMPLS - Hierarchies Date: Thu, 7 Dec 2000 13:32:23 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Juergen, What you are alluding to here is the distinction I tried to make a couple of days ago when 'explicit' and 'implicit' LSPs were being considered, that is: - implicit infers that some clear user-plane header in is force that is created at the start of the LSP and terminated at the sink of the LSP. This is the shim header, though it can be used with even *lower* layer server trails using PPP, FR or ATM (you would need to draw the func arch represenation of what I am saying here if not clear to see the trails at play). - explicit infers no shim header in the user-plane...and what is really being talked about is a common-control plane for whatever user-plane trail overhead has been defined for the layer network technology considered, eg ODU (for the OTN), VC4 (in a lower layer STM-N trail), etc. These are very different cases as I think should be obvious. You are referring to the second point above. So now we have a concept of an LSP that has no specific MPLS user-plane (shim) header as such, just whatever that layer technology has been defined with. Well that's OK. It does not really matter to me whether a control-plane or a management-plane is involved in setting up the server layer trail.......lets say a VC4 for example. But what *is* clear and indisputable, is that there can only be 2 points that delimit that VC4 trail....the source where the VC4 trail is 1st created and the sink where the VC4 trail is terminated (and where the client layer network trails, if any, are exposed, eg ATM, PPP, VC12s, etc). Now you seem to be suggesting that the *control* entity responsible for setting up the VC4 is somehow partitioned. Well that's OK too I guess......and this is how we would provision a VC4 today (ie via management) across >=2 different operator boundaries. I think the case that is worrying you is where this 'control' partitioning is 1/2 management and 1/2 signalling........Hm!.......would not seem brilliant, but could be made to work I guess (bit like have S-PVCs running to some international gateway, but not beyond I guess....not good for resilience though). Have a think about what I am saying above and see if it helps.....I think its just a mattter of (i) looking/drawing-out at what real trail entities are involved in the user-plane and (ii) considering how this overall trail is set-up as a separate issue. neil > -----Original Message----- > From: Heiles Juergen [SMTP:Juergen.Heiles@icn.siemens.de] > Sent: Thursday, December 07, 2000 12:40 PM > To: 'neil.2.harrison@bt.com'; Heiles Juergen; jdrake@calient.net; > mpls@UU.NET > Cc: ip-optical@lists.bell-labs.com > Subject: RE: [IP-Optical] GMPLS - Hierarchies > > Neil, > > I think this is a fundamental question we have to anwser: > Is the LSP always identical to a trail in the transport plane? > In my view not necessarly. The LSP could also be a sub-network connection. > Consider in the future a VC-4 trail crossing several operator domains. > Some operators can automatically set-up the VC--4 path through their > network using GMPLS. Other operators still use todays method with > path-setup via the TMN. The operator with GMPLS sets-up a SPC for this > VC-4 (and not any server layer) through its network. The set-up request > for this LSP comes from the TMN and not via a UNI/NNI as the other > operator or the user at the end-point doesn't support it. In this case the > LSP spans only a part/sub-network connection of the overall VC-4 trail. > I might be also only a definition problem. What is a LSP, the overall > connection through the network or only the part that is set-up using GMPLS > signaling? > > Juergen > > > -----Original Message----- > > From: neil.2.harrison@bt.com [SMTP:neil.2.harrison@bt.com] > > Sent: Wednesday, December 06, 2000 11:07 PM > > To: Juergen.Heiles@icn.siemens.de; jdrake@calient.net; mpls@UU.NET > > Cc: ip-optical@lists.bell-labs.com > > Subject: RE: [IP-Optical] GMPLS - Hierarchies > > > > > > > > > Furthermore a LSP -at least for circuit switching - doesn't have to > start > > > and end at the trail termination where you extract your payload. > > NH=> I fudamentally disagree *if* we are adhering to functional > > arch. > > > A LSP could be used only for a sub part of the overall connection, > e.g. a > > > DS1 signal starts in a user domain with tradional TMN path setup or > even > > > manual connections, the DS1 comes to a operator which uses GMPLS for > path > > > -setup (in this case a permanent connection set-up by himself as the > user > > > doesn't support the UNI). The LSP starts in the middleof the overall > DS1 > > > connection and no access to the paylaod of the DS1 is requried at that > > > point. > > NH=> The DSI signal is 'an LSP' in its own right......it is, after > > all, a clear layer network trail entity. The fact that it may be served > (on > > link connections, which are a partition of the end-end DS1 trail) by > lower > > layer "LSPs" (which could be a DS3, VC4, ODU, etc.......and which > themselves > > are trails *but* only between their points of source/sink) is > > academic.....the DS1 trail is completely unaware of this, and the > layering > > recursion of client_links=>server_trails can recurse many > times.......its > > stops at the duct network. > > Your example *must*, and indeed does, fit this. > > neil > > > > > From owner-mpls@UU.NET Thu Dec 7 08:37:44 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17747 for ; Thu, 7 Dec 2000 08:37:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsnu24649; Thu, 7 Dec 2000 13:36:23 GMT Received: by mail-control.mail.uu.net id QQjsnu24924 for mpls-outgoing; Thu, 7 Dec 2000 13:36:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsnu24866 for ; Thu, 7 Dec 2000 13:35:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsnu23364 for ; Thu, 7 Dec 2000 13:35:27 GMT Received: from ns01.newbridge.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns01.newbridge.com [192.75.23.67]) id QQjsnu23091 for ; Thu, 7 Dec 2000 13:35:26 GMT Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id IAA24189 for ; Thu, 7 Dec 2000 08:26:53 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdEAA0ND9R9; Thu Dec 7 08:26:51 2000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@uu.net; Thu, 7 Dec 2000 08:32:48 -0500 Received: from alcatel.com ([138.120.245.204]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA6291 for ; Thu, 7 Dec 2000 08:32:46 -0500 Message-Id: <3A2FBB8C.D70055F5@alcatel.com> Date: Thu, 07 Dec 2000 08:32:12 -0800 From: "Kainia Cloutier" Organization: Alcatel CID X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: looser ER and RSVP-TE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit My dear colleagues, section 2.4 of the CR-LDP draft specifies the Route pinning TLV: loose ERs are pinned down, upon establishment, to ensure they will not deviate from their route in the event a better route becomes available. I was always certain that RSVP-TE had addressed this. However, a recent search in the RSVP-TE draft, showed me that route pinning is omitted. I am extremely concerned about this. I have recently sent some e-mails to my closest MPLS colleagues in other companies, and yes, it seems that this issue is left to be vendor specific. Could the authors of the RSVP-TE draft comment about this? Best Regards, Kainia Cloutier, Alcatel. From owner-mpls@UU.NET Thu Dec 7 08:52:16 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19445 for ; Thu, 7 Dec 2000 08:52:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsnv20856; Thu, 7 Dec 2000 13:50:55 GMT Received: by mail-control.mail.uu.net id QQjsnv26044 for mpls-outgoing; Thu, 7 Dec 2000 13:50:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsnv26039 for ; Thu, 7 Dec 2000 13:50:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsnv20779 for ; Thu, 7 Dec 2000 13:49:29 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjsnv18975 for ; Thu, 7 Dec 2000 13:49:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA20442 for mpls@uu.net; Thu, 7 Dec 2000 08:49:27 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsnv25995 for ; Thu, 7 Dec 2000 13:48:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsnv17489 for ; Thu, 7 Dec 2000 13:48:24 GMT Received: from xover.hjinc.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjsnv17706 for ; Thu, 7 Dec 2000 13:48:22 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 08:45:42 -0500 Message-ID: <87009604743AD411B1F600508BA0F959040CDE@xover.hjinc.com> From: "Sanford, Bill" To: "'Kainia Cloutier'" , mpls@UU.NET Subject: RE: looser ER and RSVP-TE Date: Thu, 7 Dec 2000 08:45:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Wouldn't that be the same as an Explicit Route Object with "strict" nodes? In the second and third paragraph of 4.3.3.1. (Strict and Loose Subobjects) The path between a strict node and its preceding node MUST include only network nodes from the strict node and its preceding abstract node. The path between a loose node and its preceding node MAY include other network nodes that are not part of the strict node or its preceding abstract node. > -----Original Message----- > From: Kainia Cloutier [mailto:kainia.cloutier@alcatel.com] > Sent: Thursday, December 07, 2000 11:32 AM > To: mpls@UU.NET > Subject: looser ER and RSVP-TE > > > My dear colleagues, > > section 2.4 of the CR-LDP draft specifies the Route pinning TLV: loose > ERs are pinned down, upon establishment, to ensure they will > not deviate > from their route in the event a better route becomes available. > > I was always certain that RSVP-TE had addressed this. > However, a recent > search in the RSVP-TE draft, showed me that route pinning is > omitted. I > am extremely concerned about this. I have recently sent some > e-mails to > my closest MPLS colleagues in other companies, and yes, it seems that > this issue is left to be vendor specific. > > Could the authors of the RSVP-TE draft comment about this? > > Best Regards, > Kainia Cloutier, > Alcatel. > > > > > > > > From owner-mpls@UU.NET Thu Dec 7 09:14:08 2000 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22110 for ; Thu, 7 Dec 2000 09:14:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsnw07539; Thu, 7 Dec 2000 14:12:47 GMT Received: by mail-control.mail.uu.net id QQjsnw09867 for mpls-outgoing; Thu, 7 Dec 2000 14:12:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsnw09838 for ; Thu, 7 Dec 2000 14:11:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsnw08116 for ; Thu, 7 Dec 2000 14:09:18 GMT Received: from smtp6.mindspring.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp6.mindspring.com [207.69.200.110]) id QQjsnw02954 for ; Thu, 7 Dec 2000 14:09:18 GMT Received: from mindspring.com (user-2ive3ph.dialup.mindspring.com [165.247.15.49]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id JAA22827; Thu, 7 Dec 2000 09:08:07 -0500 (EST) Message-ID: <3A2F9A28.457F8E66@mindspring.com> Date: Thu, 07 Dec 2000 09:09:45 -0500 From: Eric Gray Reply-To: ewgray@mindspring.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Maksymilian Milkowski CC: mpls@UU.NET Subject: Re: Hop Count TLV References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Maksymilian Milkowski, You're not exactly wrong. But be aware of the (expanded) meaning of _T_ype-_L_ength-_V_alue. There are lots of TLV types with well defined length associated with the type. None-the-less, it is very much simpler to always include a length field. Oh, and by the way, don't get the length wrong. :-) -- Eric Gray You wrote: > Hi all, > > this is Hop Count TLV encoding (from Internet Draft "LDP Specification > draft-ietf-mpls-ldp-11.txt): > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|0| Hop Count (0x0103) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | HC Value | > +-+-+-+-+-+-+-+-+ > > HC Value is described as "1 octet unsigned integer hop count value". OK > Length field is not described and i have doubts whether it is needed - > - HC field is always 1 octet long. > Am I wrong ? > > Thanks in advance, > Maksymilian Milkowski From owner-mpls@UU.NET Thu Dec 7 09:20:32 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22882 for ; Thu, 7 Dec 2000 09:20:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsnx12127; Thu, 7 Dec 2000 14:19:11 GMT Received: by mail-control.mail.uu.net id QQjsnx10971 for mpls-outgoing; Thu, 7 Dec 2000 14:18:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsnx10944 for ; Thu, 7 Dec 2000 14:18:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsnx25839 for ; Thu, 7 Dec 2000 14:15:07 GMT Received: from ihemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQjsnx10770 for ; Thu, 7 Dec 2000 14:15:06 GMT Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA10141 for ; Thu, 7 Dec 2000 09:15:05 -0500 (EST) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id JAA10117; Thu, 7 Dec 2000 09:15:04 -0500 (EST) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA26922; Thu, 7 Dec 2000 09:08:47 -0500 Message-ID: <3A2F9AF3.F4F12C83@lucent.com> Date: Thu, 07 Dec 2000 09:13:07 -0500 From: John Ellson Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: Nuno Silva CC: neil.2.harrison@bt.com, Juergen.Heiles@icn.siemens.de, jdrake@calient.net, mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] GMPLS - Hierarchies References: <25CCC6566D01D411885B00A024559FB7DA68CC@EXCHANGE_GERAL> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQjsnx12127 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA22882 Nuno, The service being provided by a switched network provider between two UNIs is a Link with one or more Link-connections providing capacity. Once a Link-Connection has been provided it can be considered by the user as a fixed resource which can be used to provide larger composite connections. Internal to the provider's domain the Link, in general, may be further partitioned into Link-Subnet-Link, and Subnets can be partitioned into Subnet-Link-Subnet, so a Link as provided to a User may infact consist of an arbitrarily long alternating sequence of Link-Subnet and a terminating Link. As a minimum, all Links provided by a Switched network can be composed into: Link-Subnet-Link. The end Links could reasonably be called Access Links, but they are not fundamentally different from any other Link. External to the provider's domain, the Link may be just a part of an even longer composite Link, for example if one provider is just handing off to another provider. This is all partitioning. i.e. this is all at one network layer without any terminations or adaptations. At the limit of Link partitioning, the link-connections of a single link may be provided by one or more parallel trails in a server layer. e.g. A Link comprised of 6 Link-Connections may have 4 Link-Connections provided by one Trail and 2 provided by another. i.e. the relationship between a Link and a Trail is not, in general, 1:1. So the relationship between a Link provided to a user, and a trail in some server layer, is highly indirect and is rarely 1:1. This is why it makes no sense to talk about the technology of the server layer when requesting a connection in a client layer. When we are talking about partitioning, we should be talking about SNPs (Subnetwork Points), not TTPs of CTPs. In connection management we presume that SNPs are also TTPs or CTPs in real equipment, but during the establishment of a connection within one layer the details of multiplexing can be abstracted away by use of SNPs. SNPs are aliases, that is they carry a different name for the same object instance. Thus CTPs and TTPs have a name based on physical containment that allows an operator to find the smallest-replaceable-units during maintenance. SNPs on the other hand, carry a name that is convenient to connection-setup. e.g. labels. Since Subnets can be nested, a single CTP or TTP instance can have many SNP aliases. One for each of the nested Subnets. e.g. The TTP: Net1,NE3,Board6,TTP2 may have SNP aliases: 2076, 949-2076, and 732-949-2076 if we have a hierarchical namespace. Its also possible, in principle, that the SNPs have names that are unrelated to each other. An SNP is the shared point on the boundary of a Subnet that is at the junction of a Subnet-Connection inside the subnet, and a Link-Connection outside the Subnet. In any connection operation, the Link-Connections represent the fixed resource and the Subnet-Connection the flexibility. (This is not saying that Link-Connections are inflexible, only that a Link-Connection is static during the operation to form a longer connection.) I hope this helps John Ellson Nuno Silva wrote: > > Neil et all, > > Under the scope of G.805 (March 2000), do you think it makes sense to model > an LSP as a Network Connection, composed by a concatenation of SNCs and LCs > (if so, what would be the subnetwork connections, the link connections, the > TTPs and CTPs), or as an IP trail? > > TTPs - are the IP interfaces/ports? > CTPs- are the labels? > LCs - are the connections/associations between 2 labels in two different > LSRs? > SNCs- are the forwarding tables in the LSRs and LERs? (a connection between > the TTP and CTP in the LER, or a connection between CTPs in the LSRs)? > > So the question is indeed, is the functional architecture defined in G.805 > applicable to the MPLS/MPlambaS worlds? > How does this cope with G.cls (connectionless) work? > > Thanx ahead. Nuno. > > > Nuno Carvalho Silva > PT Inovaçăo, SGR > > Phone: + 351 234 403 394 > Fax: + 351 234 424 160 > E-mail: nunos@ptinovacao.pt > > > -----Original Message----- > > From: neil.2.harrison@bt.com [SMTP:neil.2.harrison@bt.com] > > Sent: Wednesday, December 06, 2000 10:07 PM > > To: Juergen.Heiles@icn.siemens.de; jdrake@calient.net; mpls@UU.NET > > Cc: ip-optical@lists.bell-labs.com > > Subject: RE: [IP-Optical] GMPLS - Hierarchies > > > > > > > > > Furthermore a LSP -at least for circuit switching - doesn't have to > > start > > > and end at the trail termination where you extract your payload. > > NH=> I fudamentally disagree *if* we are adhering to functional > > arch. > > > A LSP could be used only for a sub part of the overall connection, e.g. > > a > > > DS1 signal starts in a user domain with tradional TMN path setup or even > > > manual connections, the DS1 comes to a operator which uses GMPLS for > > path > > > -setup (in this case a permanent connection set-up by himself as the > > user > > > doesn't support the UNI). The LSP starts in the middleof the overall DS1 > > > connection and no access to the paylaod of the DS1 is requried at that > > > point. > > NH=> The DSI signal is 'an LSP' in its own right......it is, after > > all, a clear layer network trail entity. The fact that it may be served > > (on > > link connections, which are a partition of the end-end DS1 trail) by lower > > layer "LSPs" (which could be a DS3, VC4, ODU, etc.......and which > > themselves > > are trails *but* only between their points of source/sink) is > > academic.....the DS1 trail is completely unaware of this, and the layering > > recursion of client_links=>server_trails can recurse many times.......its > > stops at the duct network. > > Your example *must*, and indeed does, fit this. > > neil > > > > > > > > > _______________________________________________ > > IP-Optical mailing list > > IP-Optical@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/ip-optical > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Thu Dec 7 09:26:29 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23593 for ; Thu, 7 Dec 2000 09:26:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsnx18611; Thu, 7 Dec 2000 14:25:06 GMT Received: by mail-control.mail.uu.net id QQjsnx11674 for mpls-outgoing; Thu, 7 Dec 2000 14:24:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsnx11651 for ; Thu, 7 Dec 2000 14:24:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsnx08266 for ; Thu, 7 Dec 2000 14:23:57 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjsnx27640 for ; Thu, 7 Dec 2000 14:23:57 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA23702 for mpls@uu.net; Thu, 7 Dec 2000 09:23:57 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsnx11493 for ; Thu, 7 Dec 2000 14:23:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsnx04385 for ; Thu, 7 Dec 2000 14:22:30 GMT Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQjsnx19750 for ; Thu, 7 Dec 2000 14:22:29 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 JAA18252 for ; Thu, 7 Dec 2000 09:22:29 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA18241 for ; Thu, 7 Dec 2000 09:22:28 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA04271; Thu, 7 Dec 2000 15:22:28 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA04238; Thu, 7 Dec 2000 15:22:24 +0100 (MET) Message-ID: <3A2F9D20.BDF8A213@lucent.com> Date: Thu, 07 Dec 2000 15:22:24 +0100 From: Maarten Vissers Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Re: [IP-Optical] GMPLS - Hierarchies References: <25CCC6566D01D411885B00A024559FB7DA68CC@EXCHANGE_GERAL> Content-Type: multipart/mixed; boundary="------------B84C0FEBFDC4C95CE6A802D6" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------B84C0FEBFDC4C95CE6A802D6 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All: As both G.805 and GMPLS are describing the same physical network, there must be a unique relation between the terminology in the two cases. I see it as our duty to discover and describe this relation; otherwise I foresee problems when the transport plane (derived from G.805) and the control plane (derived from GMPLS) are to interconnect. A) Transport view = When you look at today's transport network, you can identify the following: - user network (might be as small as a single network element) - network operator network. =46rom the network operator's perspective, the user connects via a fiber (let's limit to this medium for this purpose). The network operator will now transport the complete or only a part of the signal on this fiber. = In either case, the network operator doesn't provide the trail or network connection. The trail and network connection start in the user network. As such, the network operator provides transport via a subnetwork connection. Example of complete signal transport: transport of an = STM-N/OC-N signal including all of its overhead. E.g. STM-N signal is mapped into the payload of the ODUk. Other example is the transport of a DS1 via the payload of = a VT1.5 signal, or an E1 via the payload of a VC-12 signal. As the ODUk, VT1.5 and VC-12 start in the operator's network, the ODUk, VT1.5 and VC-12 trail and network connection start in the operator's network. These are the server layer trails and network connections. Example of transport of a part of the signal: transport of a VC-4 or STS-1; in this case the STM-N/OC-N signal on the fiber is terminated and the VC-4 or STS-1 is extracted and passed through. In network management these DS1 and E1 subnetwork connections are often referred to as DS1 and E1 circuits. We could formalise this terminology, allowing us to start talking about VC-4 circuit, STS-1 circuit, STM-N/OC-N circuit. Something to consider? B) Monitoring view A network operator may decide that the transport of the signal through his subnetwork connection ("circuit") has to be monitored. The subnetwork connection can therefore be extended with tandem connection (ATM: segment) monitor functionality. = For SDH/SONET and ATM one tandem connection level is defined. = For OTN, 6 levels of tandem connection are defined in G.709. = For MPLS, ... levels of tandem connection are proposed in the MPLS OAM activity (Neil can you provide the number here) in draft Y.17oam.1. Tandem connections can be nested, and perhaps even overlapping (under discussion at the moment in Q.11/15). ----- What has helped me in the past, is to formalize the relationships. I have used BNF for this (refer e.g. to Annex C/EN 300 417-1-1 (http://webapp.etsi.org/pda/home.asp?wki_id=3D7959)). Perhaps we can use BNF (or similar tool) again to formalise the relationships in GMPLS. Regards, Maarten ---- copy of annex C/EN 300 417-1-1 -------- Annex C (informative): Network "production rules" The relationship between trails, (sub-)network connections, link connections, atomic functions, and reference points can be described by means of the "production rules" of a network. This kind of formalism can also be found in software language specifications. One of the methods used to describe a language is the Backus-Naur Form (BNF) 23) . This shows the decomposition and partitioning processes described in =A7 3 of ITU-T Recommendation G.803 [28]. ::=3D AP AP ::=3D TCP TCP ::=3D CP CP | | ::=3D | Transmission_Medium ::=3D Degenerate_Connection | Matrix_Connection (C) ::=3D Adaptation (A) ::=3D Trail_Termination (TT) ::=3D AP_D TCP_D TCP_D AP_D ::=3D CP CP | ::=3D Domain_Monitoring_Adaptation (D_A) ::=3D Domain_Monitoring_Trail_Termination (D_T) AP_D: Domain Monitoring Access Point CP_D: Domain monitoring Connection Point TCP_D: Domain Monitoring Termination Connection Point TM: Transmission_Medium The shows the recursion, which terminates when the is selected. This represents the cross-connection on an individual matrix, or an inflexible (fixed) connection for the case where a matrix is not present. It is represented by the (flexible) connection function or an (inflexible) line. The shows the layering process, which terminates when the Transmission_Medium is selected. The concept of the is introduced here because it is considered to provide a rigid way of describing the property that is required for the so-called tandem connection i.e. a sub-network connection that can be monitored via an overhead dedicated for this purpose. --------------B84C0FEBFDC4C95CE6A802D6 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Lucent Technologies Nederland;NA&CPSE version:2.1 email;internet:mvissers@lucent.com adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------B84C0FEBFDC4C95CE6A802D6-- From owner-mpls@UU.NET Thu Dec 7 09:32:28 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24288 for ; Thu, 7 Dec 2000 09:32:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsny25450; Thu, 7 Dec 2000 14:31:07 GMT Received: by mail-control.mail.uu.net id QQjsny12477 for mpls-outgoing; Thu, 7 Dec 2000 14:30:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsny12453 for ; Thu, 7 Dec 2000 14:30:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsnx07174 for ; Thu, 7 Dec 2000 14:29:14 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjsnx23199 for ; Thu, 7 Dec 2000 14:29:14 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 GAA08011 for ; Thu, 7 Dec 2000 06:29:19 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA09026 for mpls@uu.net; Thu, 7 Dec 2000 09:29:12 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsnq09421 for ; Thu, 7 Dec 2000 12:39:57 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsnq15393 for ; Thu, 7 Dec 2000 12:38:06 GMT Received: from mailgestao.intra.cet.pt by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [194.65.138.12]) id QQjsnq29364 for ; Thu, 7 Dec 2000 12:37:36 GMT Received: by mailgestao.intra.cet.pt with Internet Mail Service (5.5.2448.0) id ; Thu, 7 Dec 2000 12:34:12 -0000 Message-ID: <25CCC6566D01D411885B00A024559FB7DA68CC@EXCHANGE_GERAL> From: Nuno Silva To: neil.2.harrison@bt.com, Juergen.Heiles@icn.siemens.de, jdrake@calient.net, mpls@UU.NET Cc: ip-optical@lists.bell-labs.com, Nuno Silva Subject: RE: [IP-Optical] GMPLS - Hierarchies Date: Thu, 7 Dec 2000 12:52:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA24288 Neil et all, Under the scope of G.805 (March 2000), do you think it makes sense to model an LSP as a Network Connection, composed by a concatenation of SNCs and LCs (if so, what would be the subnetwork connections, the link connections, the TTPs and CTPs), or as an IP trail? TTPs - are the IP interfaces/ports? CTPs- are the labels? LCs - are the connections/associations between 2 labels in two different LSRs? SNCs- are the forwarding tables in the LSRs and LERs? (a connection between the TTP and CTP in the LER, or a connection between CTPs in the LSRs)? So the question is indeed, is the functional architecture defined in G.805 applicable to the MPLS/MPlambaS worlds? How does this cope with G.cls (connectionless) work? Thanx ahead. Nuno. Nuno Carvalho Silva PT Inovaçăo, SGR Phone: + 351 234 403 394 Fax: + 351 234 424 160 E-mail: nunos@ptinovacao.pt > -----Original Message----- > From: neil.2.harrison@bt.com [SMTP:neil.2.harrison@bt.com] > Sent: Wednesday, December 06, 2000 10:07 PM > To: Juergen.Heiles@icn.siemens.de; jdrake@calient.net; mpls@UU.NET > Cc: ip-optical@lists.bell-labs.com > Subject: RE: [IP-Optical] GMPLS - Hierarchies > > > > > Furthermore a LSP -at least for circuit switching - doesn't have to > start > > and end at the trail termination where you extract your payload. > NH=> I fudamentally disagree *if* we are adhering to functional > arch. > > A LSP could be used only for a sub part of the overall connection, e.g. > a > > DS1 signal starts in a user domain with tradional TMN path setup or even > > manual connections, the DS1 comes to a operator which uses GMPLS for > path > > -setup (in this case a permanent connection set-up by himself as the > user > > doesn't support the UNI). The LSP starts in the middleof the overall DS1 > > connection and no access to the paylaod of the DS1 is requried at that > > point. > NH=> The DSI signal is 'an LSP' in its own right......it is, after > all, a clear layer network trail entity. The fact that it may be served > (on > link connections, which are a partition of the end-end DS1 trail) by lower > layer "LSPs" (which could be a DS3, VC4, ODU, etc.......and which > themselves > are trails *but* only between their points of source/sink) is > academic.....the DS1 trail is completely unaware of this, and the layering > recursion of client_links=>server_trails can recurse many times.......its > stops at the duct network. > Your example *must*, and indeed does, fit this. > neil > > > > > _______________________________________________ > IP-Optical mailing list > IP-Optical@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Thu Dec 7 10:12:33 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01327 for ; Thu, 7 Dec 2000 10:12:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsoa10058; Thu, 7 Dec 2000 15:11:13 GMT Received: by mail-control.mail.uu.net id QQjsoa28381 for mpls-outgoing; Thu, 7 Dec 2000 15:10:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsoa28366 for ; Thu, 7 Dec 2000 15:10:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjsoa17381 for ; Thu, 7 Dec 2000 15:10:00 GMT Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [209.6.34.2]) id QQjsoa18044 for ; Thu, 7 Dec 2000 15:09:59 GMT Message-ID: From: Jeff Parker To: "'ewgray@mindspring.com'" , Maksymilian Milkowski Cc: mpls@UU.NET Subject: RE: Hop Count TLV Date: Thu, 7 Dec 2000 10:09:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Maksymilian Milkowski, > > You're not exactly wrong. But be aware of the > (expanded) meaning of _T_ype-_L_ength-_V_alue. > There are lots of TLV types with well defined length > associated with the type. > > Eric Gray Maksymilian - Adding the length to every TLV makes it easy to add new types, as an implementation can skip fields it does not understand. Adding the length also makes the parsing logic very simple. This flexibility and simplicity would be lost if some of the TLVs were just TVs. - jeff parker - Axiowave Networks > > HC Value is described as "1 octet unsigned integer hop > > count value". OK Length field is not described and i > > have doubts whether it is needed - > > > > Maksymilian Milkowski From owner-mpls@UU.NET Thu Dec 7 10:52:55 2000 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06473 for ; Thu, 7 Dec 2000 10:52:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsod10050; Thu, 7 Dec 2000 15:51:34 GMT Received: by mail-control.mail.uu.net id QQjsod03105 for mpls-outgoing; Thu, 7 Dec 2000 15:50:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsod03086 for ; Thu, 7 Dec 2000 15:50:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsod21544 for ; Thu, 7 Dec 2000 15:48:28 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjsod23724 for ; Thu, 7 Dec 2000 15:48:27 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA00905 for mpls@uu.net; Thu, 7 Dec 2000 10:48:26 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjsod02886 for ; Thu, 7 Dec 2000 15:47:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjsod16571 for ; Thu, 7 Dec 2000 15:46:46 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjsod21865 for ; Thu, 7 Dec 2000 15:46:45 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 KAA09636; Thu, 7 Dec 2000 10:46:44 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA03573; Thu, 7 Dec 2000 10:46:44 -0500 (EST) Message-Id: <200012071546.KAA03573@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: "Kainia Cloutier" cc: mpls@UU.NET, swallow@cisco.com Subject: Re: looser ER and RSVP-TE In-reply-to: Your message of "Thu, 07 Dec 2000 08:32:12 PST." <3A2FBB8C.D70055F5@alcatel.com> Date: Thu, 07 Dec 2000 10:46:44 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Kainia - This is one of the places where soft state works to your advantage. In RSVP you can pin a route by. 1. Sending a Path message with a loose source route and an RRO. 2. Use the RRO to create a fully defined ERO. 3. Refreseh the Path with that ERO. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu Dec 7 10:57:38 2000 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07099 for ; Thu, 7 Dec 2000 10:57:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjsod02670; Thu, 7 Dec 2000 15:56:17 GMT Received: by mail-control.mail.uu.net id QQjsod03728 for mpls-outgoing; Thu, 7 Dec 2000 15:55:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjsod03719 for ; Thu, 7 Dec 2000 15:55:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjsod08830 for ; Thu, 7 Dec 2000 15:55:37 GMT Received: from csa.iisc.ernet.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: csa.iisc.ernet.in [144.16.67.8]) id QQjsod15966 for ; Thu, 7 Dec 2000 15:55:33 GMT Received: from ada.csa.iisc.ernet.in (IDENT:root@ada.csa.iisc.ernet.in [144.16.67.35]) by csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id VAA12253 for ; Thu, 7 Dec 2000 21:22:34 +0530 Received: from localhost (prasanna@localhost) by ada.csa.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id VAA21693 for ; Thu, 7 Dec 2000 21:25:30 +0530 X-Authentication-Warning: ada.csa.iisc.ernet.in: prasanna owned process doing -bs Date: Thu, 7 Dec 2000 21:25:30 +0530 (IST) From: Gaitonde Anandprasanna To: mpls@UU.NET Subject: Query regarding the Error "RRO is too large" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk I am confused about one thing. Suppose i get a reserve message with Share explcit style then i have the following sender discriptor. ::= ::= | ::=