From owner-mpls@UU.NET Thu Nov 1 09:51:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19925 for ; Thu, 1 Nov 2001 09:51:19 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlngt17900; Thu, 1 Nov 2001 14:51:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQlngt25005 for mpls-outgoing; Thu, 1 Nov 2001 14:51:01 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlngt24997 for ; Thu, 1 Nov 2001 14:50:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlngt04437 for ; Thu, 1 Nov 2001 14:50:07 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlngt06471 for ; Thu, 1 Nov 2001 14:50:27 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07235 for ; Thu, 1 Nov 2001 09:50:06 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA21040 for mpls@uu.net; Thu, 1 Nov 2001 09:50:06 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlnel14342 for ; Wed, 31 Oct 2001 23:57:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlnel18785 for ; Wed, 31 Oct 2001 23:57:30 GMT Received: from c2.ciena.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.118.32.25]) id QQlnel05317 for ; Wed, 31 Oct 2001 23:57:50 GMT Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id SAA29709; Wed, 31 Oct 2001 18:57:28 -0500 (EST) Received: from w2kmsdexg01(10.21.2.3) by c2.ciena.com via smap (V2.0) id xma029643; Wed, 31 Oct 01 18:57:17 -0500 Received: by W2KMSDEXG01.ciena.com with Internet Mail Service (5.5.2653.19) id <4XJF4SFD>; Wed, 31 Oct 2001 15:56:43 -0800 Message-ID: <1863277D226CDA42BA94C0BC6D6F3CEE4983E8@W2KMSDEXG01.ciena.com> From: "Fu, Jingsong" To: MPLS Mailing List Subject: encapsulate a labeled frame on ethernet - rfc3032 Date: Wed, 31 Oct 2001 15:56:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk When encasulating a label frame ove ethernet, 0x8847/0x8848 is uesed in ethertype to indicate that a frame is MPLS packet. Where should be the original ethertype, or is it removed? Thanks, Jingsong Fu From owner-mpls@UU.NET Thu Nov 1 11:18:26 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22869 for ; Thu, 1 Nov 2001 11:18:26 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlngz21643; Thu, 1 Nov 2001 16:18:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQlngz10082 for mpls-outgoing; Thu, 1 Nov 2001 16:18:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlngz10075 for ; Thu, 1 Nov 2001 16:18:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlngz21808 for ; Thu, 1 Nov 2001 16:17:55 GMT Received: from morpheus.lanterncom.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.161.157.68]) id QQlngz20767 for ; Thu, 1 Nov 2001 16:17:44 GMT Received: by morpheus.lanterncom.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 08:05:20 -0800 Message-ID: <58BE468BAC66D511AFE6000347251A2D5395E8@morpheus.lanterncom.com> From: Anoop Ghanwani To: "'Fu, Jingsong'" , MPLS Mailing List Subject: RE: encapsulate a labeled frame on ethernet - rfc3032 Date: Thu, 1 Nov 2001 08:05:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk If you send out MPLS packets, it means you have terminated the MAC domain and therefore the Ethertype is removed along with the rest of the original MAC header. An exception is if you use MPLS to provide L2 VPN service for Ethernet frames. In that case, the entire Ethernet frame is encapsulated within an MPLS header, and if going out over Ethernet, you would have a separate "outer" MAC header. -Anoop > -----Original Message----- > From: Fu, Jingsong [mailto:JFu@ciena.com] > Sent: Wednesday, October 31, 2001 3:57 PM > To: MPLS Mailing List > Subject: encapsulate a labeled frame on ethernet - rfc3032 > > > > > When encasulating a label frame ove ethernet, 0x8847/0x8848 > is uesed in > ethertype to indicate that a frame is MPLS packet. Where should be the > original ethertype, or is it removed? > > Thanks, > > Jingsong Fu > From owner-mpls@UU.NET Thu Nov 1 12:39:00 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24897 for ; Thu, 1 Nov 2001 12:39:00 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnhe10362; Thu, 1 Nov 2001 17:39:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnhe05653 for mpls-outgoing; Thu, 1 Nov 2001 17:38:42 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlnhe05648 for ; Thu, 1 Nov 2001 17:38:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlnhe19393 for ; Thu, 1 Nov 2001 17:37:54 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlnhe28677 for ; Thu, 1 Nov 2001 17:37:43 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA02087 for ; Thu, 1 Nov 2001 12:37:53 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA28573 for mpls@uu.net; Thu, 1 Nov 2001 12:37:53 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlnhd04569 for ; Thu, 1 Nov 2001 17:23:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlnhd26630 for ; Thu, 1 Nov 2001 17:22:15 GMT Received: from mail1.propulsionnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [209.10.38.226]) id QQlnhd12077 for ; Thu, 1 Nov 2001 17:22:35 GMT Received: from MirabileDictu (mirabile-dictu.propulsionnetworks.com [192.168.10.54]) by mail1.propulsionnetworks.com (8.10.2+Sun/8.11.3) with SMTP id fA1HGsE08427 for ; Thu, 1 Nov 2001 09:16:54 -0800 (PST) From: "Arun M. Thomas" To: "MPLS Mailing List" Subject: RE: encapsulate a labeled frame on ethernet - rfc3032 Date: Thu, 1 Nov 2001 09:22:13 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <58BE468BAC66D511AFE6000347251A2D5395E8@morpheus.lanterncom.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Today, the labels 0 and 3 are reserved labels which identify the encapsulation of the content beneath the MPLS shim layer. Is it possible, therefore, to assign specific label values to certain ethertypes which an LER might understand and encode correctly in outgoing packets? Is there any long term approach (I haven't seen any, but I also haven't read all the drafts out there) in the works? Cheers, -AMT -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Anoop Ghanwani Sent: Thursday, November 01, 2001 8:05 AM To: 'Fu, Jingsong'; MPLS Mailing List Subject: RE: encapsulate a labeled frame on ethernet - rfc3032 If you send out MPLS packets, it means you have terminated the MAC domain and therefore the Ethertype is removed along with the rest of the original MAC header. An exception is if you use MPLS to provide L2 VPN service for Ethernet frames. In that case, the entire Ethernet frame is encapsulated within an MPLS header, and if going out over Ethernet, you would have a separate "outer" MAC header. -Anoop > -----Original Message----- > From: Fu, Jingsong [mailto:JFu@ciena.com] > Sent: Wednesday, October 31, 2001 3:57 PM > To: MPLS Mailing List > Subject: encapsulate a labeled frame on ethernet - rfc3032 > > > > > When encasulating a label frame ove ethernet, 0x8847/0x8848 > is uesed in > ethertype to indicate that a frame is MPLS packet. Where should be the > original ethertype, or is it removed? > > Thanks, > > Jingsong Fu > From owner-mpls@UU.NET Thu Nov 1 14:09:12 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27847 for ; Thu, 1 Nov 2001 14:09:12 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnhk21989; Thu, 1 Nov 2001 19:09:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnhk20156 for mpls-outgoing; Thu, 1 Nov 2001 19:09:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlnhk20147 for ; Thu, 1 Nov 2001 19:08:47 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 QQlnhk00316 for ; Thu, 1 Nov 2001 19:08:32 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQlnhk23903 for ; Thu, 1 Nov 2001 19:08:53 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 OAA13160 for ; Thu, 1 Nov 2001 14:08:30 -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 OAA21230 for ; Thu, 1 Nov 2001 14:08:29 -0500 (EST) Message-ID: <3BE19DE0.1FD0003A@marconi.com> Date: Thu, 01 Nov 2001 14:09:20 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: encapsulate a labeled frame on ethernet - rfc3032 References: <1863277D226CDA42BA94C0BC6D6F3CEE4983E8@W2KMSDEXG01.ciena.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Fu, Jingsong" wrote: > > When encasulating a label frame ove ethernet, 0x8847/0x8848 is > uesed in ethertype to indicate that a frame is MPLS packet. Where > should be the original ethertype, or is it removed? The original Ethertype is lost. The egress router (which pops the label and transmits an unlabeled packet) is responsible for providing one. Note that preserving an ethertype is not useful here. The labeled packet may leave an Ethernet and get forwarded onto something else. The egress router must provide an appropriate layer-2 encapsulation for the medium it transmits the unlabeled packet on. Since the egress router must know the type of the MPLS payload in order to function over any medium, it should know the appropriate ethertype if the egress interface is Ethernet. How the egress router learns the type will depend on how the LSP was set up. RSVP-TE sends the type in the label-request object (using ethertypes). LDP assumes that everything is IP. I don't know how CR-LDP does this. -- David From owner-mpls@UU.NET Thu Nov 1 14:13:26 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27982 for ; Thu, 1 Nov 2001 14:13:26 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnhk00737; Thu, 1 Nov 2001 19:13:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnhk20713 for mpls-outgoing; Thu, 1 Nov 2001 19:13:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlnhk20708 for ; Thu, 1 Nov 2001 19:13:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlnhk20673 for ; Thu, 1 Nov 2001 19:11:43 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQlnhk26336 for ; Thu, 1 Nov 2001 19:11:33 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 OAA13558 for ; Thu, 1 Nov 2001 14:11:38 -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 OAA22052 for ; Thu, 1 Nov 2001 14:11:38 -0500 (EST) Message-ID: <3BE19E9D.8B6A74B@marconi.com> Date: Thu, 01 Nov 2001 14:12:29 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: question on e-lsp and l-lsp References: <66ADEEFA234AD4119AA600D0B7741E3A023F6103@HEADOFFICE03_FS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Fan, Zhong" wrote: > > Can anybody shed some light on the differences between e-lsp and > l-lsp please? I'm reading draft-ietf-mpls-diff-ext-09.txt at the > moment. Although the draft gives denifition of these two kinds of > LSPs, I am still confused. Is this all about the mapping of diffserv > classes to MPLS FEC or EXP? The draft explains the differences. In superbrief summary; - An L-LSP has one QoS for all packets. It is determined at LSP setup. This is similar to setting up an LSP without any DiffServ extensions, except that the objects used in the signaling are different. - An E-LSP has up to 8 QoS levels for the single LSP. The EXP bits determine the appropriate QoS on a per-packet basis. The QoS that is assigned to each EXP value is signaled at LSP setup (or is a configured default if the values are not signaled.) -- David From owner-mpls@UU.NET Thu Nov 1 14:26:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28253 for ; Thu, 1 Nov 2001 14:26:06 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnhl21412; Thu, 1 Nov 2001 19:26:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnhl21832 for mpls-outgoing; Thu, 1 Nov 2001 19:25:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlnhl21827 for ; Thu, 1 Nov 2001 19:25:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlnhl06542 for ; Thu, 1 Nov 2001 19:24:15 GMT Received: from mail3.uunet.ca by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail3.uunet.ca [142.77.1.29]) id QQlnhl15278 for ; Thu, 1 Nov 2001 19:24:04 GMT Received: from mtl-vipswitch-01 ([205.205.115.130]) by mail3.uunet.ca with SMTP id <258615-3055>; Thu, 1 Nov 2001 14:21:16 -0500 Received: by NETVIPSWITCH with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Nov 2001 14:21:14 -0500 Message-ID: From: Jean-Bertos Simo To: "'mpls@uu.net'" Subject: Mandatory objects when using RSVP-TE for LSP Tunnels Date: Thu, 1 Nov 2001 14:21:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1630A.5ECF78C4" 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_01C1630A.5ECF78C4 Content-Type: text/plain; charset="iso-8859-1" In draft-ietf-mpls-rsvp-lsp-tunnels-08.txt, and are mandatory objects in a Path Message. I would like someone to enlighten me about the following issues: 1) What's the expected behavior of an RSVP-capable router that receives a Path Message: - without a object? - without a object? My understanding is that the Path Message can be silently dropped or the router can return a PathErr Message. However, my preference would go to dropping the Path Message to reduce traffic load. 2) Are these two objects mandatory in a PathTear Message when dealing with a LSP_TUNNEL_IPV4_SESSION session object? 3) If any of these objects is missing in a PathTear Message, what behavior is expected from a RSVP-capable router? 4) When processing a PathTear Message, do we have to check whether the or objects are empty or containing any data? 5) Can anyone provide me references where I can find mandatory objects of Teardown, Error and Confirmation messages of RSVP-TE? Thanks for your help. Jean-Bertos ------_=_NextPart_001_01C1630A.5ECF78C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mandatory objects when using RSVP-TE for LSP Tunnels

In = draft-ietf-mpls-rsvp-lsp-tunnels-08.txt, <sender descriptor> and = <LABEL_REQUEST> are mandatory objects in a Path Message. I would = like someone to enlighten me about the following issues:

1) What's the expected behavior of an = RSVP-capable router that receives a Path Message:
-  without a = <LABEL_REQUEST> object?
-  without a <sender = descriptor> object?
My understanding is that the Path = Message can be silently dropped or the router can return a PathErr = Message. However, my preference would go to dropping the Path Message = to reduce traffic load.

2) Are these two objects mandatory in = a PathTear Message when dealing with a LSP_TUNNEL_IPV4_SESSION session = object?

3) If any of these objects is missing = in a PathTear Message, what behavior is expected from a RSVP-capable = router?

4) When processing a PathTear Message, = do we have to check whether  the <SENDER_TEMPLATE> or  = <SENDER_TSPEC> objects are empty or containing any = data?

5) Can anyone provide me references = where I can find mandatory objects of Teardown, Error and Confirmation = messages of RSVP-TE?

Thanks for your help.

Jean-Bertos

------_=_NextPart_001_01C1630A.5ECF78C4-- From owner-mpls@UU.NET Thu Nov 1 16:08:54 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00537 for ; Thu, 1 Nov 2001 16:08:54 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnhs01273; Thu, 1 Nov 2001 21:08:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnhs07339 for mpls-outgoing; Thu, 1 Nov 2001 21:08:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlnhs07327 for ; Thu, 1 Nov 2001 21:08:27 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 QQlnhs21971 for ; Thu, 1 Nov 2001 21:07:19 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlnhs28563 for ; Thu, 1 Nov 2001 21:07:09 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA02680 for ; Thu, 1 Nov 2001 16:07:17 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA08238 for mpls@uu.net; Thu, 1 Nov 2001 16:07:17 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlnhr17723 for ; Thu, 1 Nov 2001 20:59:57 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlnhr05591 for ; Thu, 1 Nov 2001 20:59:28 GMT Received: from web13504.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13504.mail.yahoo.com [216.136.175.83]) id QQlnhr10988 for ; Thu, 1 Nov 2001 20:59:48 GMT Message-ID: <20011101205927.28476.qmail@web13504.mail.yahoo.com> Received: from [63.121.148.130] by web13504.mail.yahoo.com via HTTP; Thu, 01 Nov 2001 12:59:27 PST Date: Thu, 1 Nov 2001 12:59:27 -0800 (PST) From: Vishal M Subject: Re: question on e-lsp and l-lsp To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have some followup questions on L-LSP and E-LSPs: 1. Can we map multiple CTs onto a single L-LSP ? The draft seem to suggest that creation of a separate LSP can be done for every CT. Is creation of separate L-LSP mandatory for every CT or is it left to the implementation? 2. Somewhere I read that E-LSP shouldn't be used for ATM-LSR. Could someone please explain why ? Thanks for your time, Vishal. "Fan, Zhong" wrote: > > Can anybody shed some light on the differences between e-lsp and > l-lsp please? I'm reading draft-ietf-mpls-diff-ext-09.txt at the > moment. Although the draft gives denifition of these two kinds of > LSPs, I am still confused. Is this all about the mapping of diffserv > classes to MPLS FEC or EXP? The draft explains the differences. In superbrief summary; - An L-LSP has one QoS for all packets. It is determined at LSP setup. This is similar to setting up an LSP without any DiffServ extensions, except that the objects used in the signaling are different. - An E-LSP has up to 8 QoS levels for the single LSP. The EXP bits determine the appropriate QoS on a per-packet basis. The QoS that is assigned to each EXP value is signaled at LSP setup (or is a configured default if the values are not signaled.) -- David __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From owner-mpls@UU.NET Thu Nov 1 16:31:02 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01176 for ; Thu, 1 Nov 2001 16:31:02 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnhu14284; Thu, 1 Nov 2001 21:31:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnhu09455 for mpls-outgoing; Thu, 1 Nov 2001 21:30:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlnhu09440 for ; Thu, 1 Nov 2001 21:30:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlnht21167 for ; Thu, 1 Nov 2001 21:27:26 GMT Received: from ersfirep1 by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns1.jasper.com [64.19.21.34] (may be forged)) id QQlnht04727 for ; Thu, 1 Nov 2001 21:27:46 GMT Received: by ersfirep1; id PAA26755; Thu, 1 Nov 2001 15:29:27 -0600 (CST) Received: from unknown(10.0.0.65) by ersfirep1.erlangtech.com via smap (V5.5) id xma026751; Thu, 1 Nov 01 15:28:58 -0600 Message-ID: <00dd01c1631b$c178c9b0$4100000a@internal.erlangtech.com> Reply-To: "Yongjun Im" From: "Yongjun Im" To: "Vishal M" , References: <20011101205927.28476.qmail@web13504.mail.yahoo.com> Subject: Re: question on e-lsp and l-lsp Date: Thu, 1 Nov 2001 15:25:40 -0600 Organization: Erlang Technology, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Vishal M" To: Sent: Thursday, November 01, 2001 2:59 PM Subject: Re: question on e-lsp and l-lsp > > Hi, > > I have some followup questions on L-LSP and E-LSPs: > > 1. Can we map multiple CTs onto a single L-LSP ? The > draft seem to suggest that creation of a separate LSP > can be done for every CT. What is CT? > > Is creation of separate L-LSP mandatory for every CT > or is it left to the implementation? > > 2. Somewhere I read that E-LSP shouldn't be used for > ATM-LSR. Could someone please explain why ? Since ATM-LSR has only cell switching capability, it is not able to look into EXP field in the shim header. Howerver, Edge ATM-LSR can look into EXP field. > > Thanks for your time, > Vishal. > > "Fan, Zhong" wrote: > > > > Can anybody shed some light on the differences > between e-lsp and > > l-lsp please? I'm reading > draft-ietf-mpls-diff-ext-09.txt at the > > moment. Although the draft gives denifition of these > two kinds of > > LSPs, I am still confused. Is this all about the > mapping of diffserv > > classes to MPLS FEC or EXP? > > The draft explains the differences. > > In superbrief summary; > > - An L-LSP has one QoS for all packets. It is > determined at LSP > setup. This is similar to setting up an LSP without > any DiffServ > extensions, except that the objects used in the > signaling are > different. > > - An E-LSP has up to 8 QoS levels for the single LSP. > The EXP bits > determine the appropriate QoS on a per-packet basis. > The QoS that > is assigned to each EXP value is signaled at LSP > setup (or is a > configured default if the values are not signaled.) > > -- David > > > __________________________________________________ > Do You Yahoo!? > Make a great connection at Yahoo! Personals. > http://personals.yahoo.com > From owner-mpls@UU.NET Thu Nov 1 16:42:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01311 for ; Thu, 1 Nov 2001 16:42:20 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnhu04462; Thu, 1 Nov 2001 21:42:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnhu10367 for mpls-outgoing; Thu, 1 Nov 2001 21:42:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlnhu10362 for ; Thu, 1 Nov 2001 21: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 QQlnhu02213 for ; Thu, 1 Nov 2001 21:41:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlnhu24352 for ; Thu, 1 Nov 2001 21:40:51 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA07824 for ; Thu, 1 Nov 2001 16:41:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA10103 for mpls@uu.net; Thu, 1 Nov 2001 16:41:01 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlnhu10169 for ; Thu, 1 Nov 2001 21:40: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 QQlnhu29949 for ; Thu, 1 Nov 2001 21:40:18 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQlnhu23177 for ; Thu, 1 Nov 2001 21:40: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 QAA00968; Thu, 1 Nov 2001 16:40:15 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA10919; Thu, 1 Nov 2001 16:40:09 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Nov 2001 16:40:08 -0500 Message-ID: From: "Proch, Daniel" To: "'Vishal M'" , mpls@UU.NET Subject: RE: question on e-lsp and l-lsp Date: Thu, 1 Nov 2001 16:40:07 -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 Vishal, Somewhere I read that E-LSP shouldn't be used for ATM-LSR. Could someone please explain why ? MPLS over ATM (cell) interfaces uses the existing ATM cell structure and what were the contents of the VPI field or the combined VPI/VCI fields to infer a label. There are no EXP bits in the header and therefore only L-LSPs can be supported on LC-ATM interfaces. dan -----Original Message----- From: Vishal M [mailto:vishal_study@yahoo.com] Sent: Thursday, November 01, 2001 3:59 PM To: mpls@UU.NET Subject: Re: question on e-lsp and l-lsp Hi, I have some followup questions on L-LSP and E-LSPs: 1. Can we map multiple CTs onto a single L-LSP ? The draft seem to suggest that creation of a separate LSP can be done for every CT. Is creation of separate L-LSP mandatory for every CT or is it left to the implementation? 2. Somewhere I read that E-LSP shouldn't be used for ATM-LSR. Could someone please explain why ? Thanks for your time, Vishal. "Fan, Zhong" wrote: > > Can anybody shed some light on the differences between e-lsp and > l-lsp please? I'm reading draft-ietf-mpls-diff-ext-09.txt at the > moment. Although the draft gives denifition of these two kinds of > LSPs, I am still confused. Is this all about the mapping of diffserv > classes to MPLS FEC or EXP? The draft explains the differences. In superbrief summary; - An L-LSP has one QoS for all packets. It is determined at LSP setup. This is similar to setting up an LSP without any DiffServ extensions, except that the objects used in the signaling are different. - An E-LSP has up to 8 QoS levels for the single LSP. The EXP bits determine the appropriate QoS on a per-packet basis. The QoS that is assigned to each EXP value is signaled at LSP setup (or is a configured default if the values are not signaled.) -- David __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From owner-mpls@UU.NET Thu Nov 1 16:49:11 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01393 for ; Thu, 1 Nov 2001 16:49:11 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnhv16973; Thu, 1 Nov 2001 21:49:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnhv10955 for mpls-outgoing; Thu, 1 Nov 2001 21:48:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlnhv10950 for ; Thu, 1 Nov 2001 21:48:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlnhv07788 for ; Thu, 1 Nov 2001 21:48:05 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQlnhv11920 for ; Thu, 1 Nov 2001 21:48:25 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 QAA02132 for ; Thu, 1 Nov 2001 16:48:02 -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 QAA15253 for ; Thu, 1 Nov 2001 16:48:03 -0500 (EST) Message-ID: <3BE1C346.DB77C479@marconi.com> Date: Thu, 01 Nov 2001 16:48:54 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: Mandatory objects when using RSVP-TE for LSP Tunnels References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jean-Bertos Simo wrote: > > In draft-ietf-mpls-rsvp-lsp-tunnels-08.txt Please note that the current draft is version -09. > , and are mandatory objects in > a Path Message. I would like someone to enlighten me about the > following issues: > > 1) What's the expected behavior of an RSVP-capable router that > receives a Path Message: > - without a object? This menans that the Path message may not be used for LSP setup. If your router is capable of using RSVP to signal resource reservations on unlabeled packets (aka classical RSVP, as defined by RFC 2205), then you can process the Path message. If your router only uses RSVP for setting up LSPs, then a required object is missing - drop the packet. > - without a object? If your RSVP implementation is only capable of setting up LSPs, then mandatory objects are missing - drop the packet. If your RSVP implementation is capable of classical RSVP operation, then it should accept the packet. A missing sender descriptor is legal if a WF-style reservation is reserved by the egress router, since WF style does not require identification of the sender. Note that WF style reservation is not valid for MPLS. > My understanding is that the Path Message can be silently dropped or > the router can return a PathErr Message. However, my preference would > go to dropping the Path Message to reduce traffic load. There is no error code defined that you could use in a PathErr for this. Therefore, you should not generate a PathErr in this situation. > 2) Are these two objects mandatory in a PathTear Message when dealing > with a LSP_TUNNEL_IPV4_SESSION session object? LABEL_REQUEST is not required for PathTear. It is not part of the BNF of RFC-2205 (obviously), and no updated BNF is provided in the RSVP-TE draft. Sender decriptors are optional in PathTear, in the same sense as they are optional in Path messages. I'm not 100% certain, but it's my understanding that a sender descriptor is needed when tearing down any Path that was set up using a sender dscriptor - since it is required to identify the sender. > 3) If any of these objects is missing in a PathTear Message, what > behavior is expected from a RSVP-capable router? Errors in PathTear messages never result in generation of error-message packets. There is no such thing as a PathTearErr message. If a required object is missing, the packet is dropped. > 4) When processing a PathTear Message, do we have to check whether > the or objects are empty or > containing any data? Read RFC 2205. Section 3.1.5. TSPEC and ADSPEC are optional and should be ignored in PathTear messages. SENDER_TEMPLATE is required to identify the sender. If it is missing, then you can't identify which sender in the session is being torn. > 5) Can anyone provide me references where I can find mandatory > objects of Teardown, Error and Confirmation messages of RSVP-TE? RFC 2205. -- David From owner-mpls@UU.NET Thu Nov 1 16:50:34 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01419 for ; Thu, 1 Nov 2001 16:50:34 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnhv09838; Thu, 1 Nov 2001 21:50:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnhv11029 for mpls-outgoing; Thu, 1 Nov 2001 21:50:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlnhv11024 for ; Thu, 1 Nov 2001 21:50: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 QQlnhv04439 for ; Thu, 1 Nov 2001 21:50:03 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: law2-f138.hotmail.com [216.32.181.138]) id QQlnhv15171 for ; Thu, 1 Nov 2001 21:50:22 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 1 Nov 2001 13:50:01 -0800 Received: from 63.104.212.252 by lw2fd.hotmail.msn.com with HTTP; Thu, 01 Nov 2001 21:50:00 GMT X-Originating-IP: [63.104.212.252] From: "Sandeep S" To: mpls@UU.NET Subject: questions related to Refresh reduction Date: Thu, 01 Nov 2001 21:50:00 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Nov 2001 21:50:01.0196 (UTC) FILETIME=[282872C0:01C1631F] Sender: owner-mpls@UU.NET Precedence: bulk Hello, Are MsgIds used only for stable states refresh messages or also for trigger messages. RFC2961 mentions using for any RSVP message - would mean they are used for PATHTEAR, RESVTEAR etc. Suppose I have setup- Node1 ----- Node2 ------ Node3 ------ Node4 Both bundling and msgids used only between Node2 and Node3. I have one lsp from Node1 to Node 4 and it is in stable state. Now I setup one more lsp from Node1 to Node4. PATH message for this new lsp reaches Node2 and it suppose happens to coincide at the same time as Node2 is sending its Summary refresh for the first lsp. Cuz of bundling would this ACK be piggy-backed on the trigger PATH for the new lsp. If so would the destination IP of bundled packet be changed to next-hop of Node3 or would it still be Node4 (cuz PATH is being sent to Node4) _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mpls@UU.NET Thu Nov 1 16:57:25 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01569 for ; Thu, 1 Nov 2001 16:57:25 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnhv20829; Thu, 1 Nov 2001 21:57:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnhv11521 for mpls-outgoing; Thu, 1 Nov 2001 21:57:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlnhv11516 for ; Thu, 1 Nov 2001 21:57: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 QQlnhv23476 for ; Thu, 1 Nov 2001 21:56:15 GMT Received: from zcars0m9.nortelnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157]) id QQlnhv27135 for ; Thu, 1 Nov 2001 21:56:35 GMT Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fA1LtZS05176 for ; Thu, 1 Nov 2001 16:55:35 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 1 Nov 2001 16:56:00 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 16:55:23 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD348F04BA@zcard0ka.ca.nortel.com> From: "David Allan" To: "Proch, Daniel" , "'Vishal M'" , mpls@UU.NET Subject: RE: question on e-lsp and l-lsp Date: Thu, 1 Nov 2001 16:55:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1631F.E747C160" 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_01C1631F.E747C160 Content-Type: text/plain; charset="iso-8859-1" That and the fact that VCCs by design do not support multiple queuing disciplines. Shuffling the cell order tends to cause problems ;-) Dave > -----Original Message----- > From: Proch, Daniel [mailto:Daniel.Proch@marconi.com] > Sent: Thursday, November 01, 2001 4:40 PM > To: 'Vishal M'; mpls@UU.NET > Subject: RE: question on e-lsp and l-lsp > > > Vishal, > > Somewhere I read that E-LSP shouldn't be used for > ATM-LSR. Could someone please explain why ? > > MPLS over ATM (cell) interfaces uses the existing ATM cell > structure and > what were the contents of the VPI field or the combined > VPI/VCI fields to > infer a label. There are no EXP bits in the header and therefore only > L-LSPs can be supported on LC-ATM interfaces. > > dan > > -----Original Message----- > From: Vishal M [mailto:vishal_study@yahoo.com] > Sent: Thursday, November 01, 2001 3:59 PM > To: mpls@UU.NET > Subject: Re: question on e-lsp and l-lsp > > > > Hi, > > I have some followup questions on L-LSP and E-LSPs: > > 1. Can we map multiple CTs onto a single L-LSP ? The > draft seem to suggest that creation of a separate LSP > can be done for every CT. > > Is creation of separate L-LSP mandatory for every CT > or is it left to the implementation? > > 2. Somewhere I read that E-LSP shouldn't be used for > ATM-LSR. Could someone please explain why ? > > Thanks for your time, > Vishal. > > "Fan, Zhong" wrote: > > > > Can anybody shed some light on the differences > between e-lsp and > > l-lsp please? I'm reading > draft-ietf-mpls-diff-ext-09.txt at the > > moment. Although the draft gives denifition of these > two kinds of > > LSPs, I am still confused. Is this all about the > mapping of diffserv > > classes to MPLS FEC or EXP? > > The draft explains the differences. > > In superbrief summary; > > - An L-LSP has one QoS for all packets. It is > determined at LSP > setup. This is similar to setting up an LSP without > any DiffServ > extensions, except that the objects used in the > signaling are > different. > > - An E-LSP has up to 8 QoS levels for the single LSP. > The EXP bits > determine the appropriate QoS on a per-packet basis. > The QoS that > is assigned to each EXP value is signaled at LSP > setup (or is a > configured default if the values are not signaled.) > > -- David > > > __________________________________________________ > Do You Yahoo!? > Make a great connection at Yahoo! Personals. > http://personals.yahoo.com > > ------_=_NextPart_001_01C1631F.E747C160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: question on e-lsp and l-lsp

That and the fact that VCCs by design do not support = multiple queuing disciplines. Shuffling the cell order tends to cause = problems ;-)

Dave

> -----Original Message-----
> From: Proch, Daniel [mailto:Daniel.Proch@marconi.com= ]
> Sent: Thursday, November 01, 2001 4:40 = PM
> To: 'Vishal M'; mpls@UU.NET
> Subject: RE: question on e-lsp and l-lsp
>
>
> Vishal,
>
> Somewhere I read that E-LSP shouldn't be used = for
> ATM-LSR. Could someone please explain why = ?
>
> MPLS over ATM (cell) interfaces uses the = existing ATM cell
> structure and
> what were the contents of the VPI field or the = combined
> VPI/VCI fields to
> infer a label.  There are no EXP bits in = the header and therefore only
> L-LSPs can be supported on LC-ATM = interfaces. 
>
> dan
>
> -----Original Message-----
> From: Vishal M [mailto:vishal_study@yahoo.com= ]
> Sent: Thursday, November 01, 2001 3:59 = PM
> To: mpls@UU.NET
> Subject: Re: question on e-lsp and l-lsp
>
>
>
> Hi,
>
> I have some followup questions on L-LSP and = E-LSPs:
>
> 1. Can we map multiple CTs onto a single L-LSP = ? The
> draft seem to suggest that creation of a = separate LSP
> can be done for every CT.
>
> Is creation of separate L-LSP mandatory for = every CT
> or  is it left to the = implementation?
>
> 2. Somewhere I read that E-LSP shouldn't be = used for
> ATM-LSR. Could someone please explain why = ?
>
> Thanks for your time,
> Vishal.
>
> "Fan, Zhong" wrote:
> >
> > Can anybody shed some light on the = differences
> between e-lsp and
> > l-lsp please? I'm reading
> draft-ietf-mpls-diff-ext-09.txt at the
> > moment. Although the draft gives = denifition of these
> two kinds of
> > LSPs, I am still confused. Is this all = about the
> mapping of diffserv
> > classes to MPLS FEC or EXP?
>
> The draft explains the differences.
>
> In superbrief summary;
>
> - An L-LSP has one QoS for all packets.  = It is
> determined at LSP
>   setup.  This is similar to = setting up an LSP without
> any DiffServ
>   extensions, except that the objects = used in the
> signaling are
>   different.
>
> - An E-LSP has up to 8 QoS levels for the = single LSP.
> The EXP bits
>   determine the appropriate QoS on a = per-packet basis.
>  The QoS that
>   is assigned to each EXP value is = signaled at LSP
> setup (or is a
>   configured default if the values = are not signaled.)
>
> -- David
>
>
> = __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! = Personals.
> http://personals.yahoo.com
>
>

------_=_NextPart_001_01C1631F.E747C160-- From owner-mpls@UU.NET Thu Nov 1 16:58:42 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01598 for ; Thu, 1 Nov 2001 16:58:42 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnhv23603; Thu, 1 Nov 2001 21:58:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnhv11595 for mpls-outgoing; Thu, 1 Nov 2001 21:58:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlnhv11590 for ; Thu, 1 Nov 2001 21:58:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlnhv22690 for ; Thu, 1 Nov 2001 21:57:40 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 QQlnhv02193 for ; Thu, 1 Nov 2001 21:58:01 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 QAA03107 for ; Thu, 1 Nov 2001 16:57:37 -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 QAA18616 for ; Thu, 1 Nov 2001 16:57:38 -0500 (EST) Message-ID: <3BE1C585.D5E5ACE7@marconi.com> Date: Thu, 01 Nov 2001 16:58:29 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: question on e-lsp and l-lsp References: <20011101205927.28476.qmail@web13504.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vishal M wrote: > > 2. Somewhere I read that E-LSP shouldn't be used for ATM-LSR. Could > someone please explain why ? ATM switches usually do not have the ability to make switching/queueing decisions based on more information than what's in the 5-byte cell header. Without this capability, E-LSPs can not be properly implemented. -- David From owner-mpls@UU.NET Thu Nov 1 17:23:05 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02046 for ; Thu, 1 Nov 2001 17:23:04 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnhx15193; Thu, 1 Nov 2001 22:23:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnhx02772 for mpls-outgoing; Thu, 1 Nov 2001 22:22:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlnhx02767 for ; Thu, 1 Nov 2001 22:22:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlnhx23535 for ; Thu, 1 Nov 2001 22:22:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlnhx01421 for ; Thu, 1 Nov 2001 22:21:52 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA13424 for ; Thu, 1 Nov 2001 17:22:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA12863 for mpls@uu.net; Thu, 1 Nov 2001 17:22:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlnhx02695 for ; Thu, 1 Nov 2001 22:21: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 QQlnhx02113 for ; Thu, 1 Nov 2001 22:21:05 GMT Received: from EXCH-SJC-IMS2.force10networks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: corp.force10networks.com [206.54.51.125]) id QQlnhx29757 for ; Thu, 1 Nov 2001 22:20:53 GMT Received: from EXCH-CLUSTER.force10networks.com ([10.11.0.39]) by EXCH-SJC-IMS2.force10networks.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 1 Nov 2001 14:19:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: questions related to Refresh reduction Date: Thu, 1 Nov 2001 14:19:43 -0800 Message-ID: Thread-Topic: questions related to Refresh reduction Thread-Index: AcFjH1gZQvzo+w7MSUag5b+TZ1pPmgAAIrpQ From: "Rajeev Manur" To: "Sandeep S" , X-OriginalArrivalTime: 01 Nov 2001 22:19:44.0112 (UTC) FILETIME=[4EDBD700:01C16323] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA02046 SRefresh msgs can used only if the corresponding PATH/RESV trigger msgs have been sent with MSG_ID objects. That's how you can associate the states.. MSG_ID_ACK/NACK can be either sent in seperate msgs or piggybacked in other msgs.. Bundle msgs are always addressed to the immediate RSVP peer. The sub-msgs contained inside the bundle msgs are themselves complete msgs with their own rsvp header.. with regards, Rajeev -----Original Message----- From: Sandeep S [mailto:san_101@hotmail.com] Sent: Thursday, November 01, 2001 1:50 PM To: mpls@UU.NET Subject: questions related to Refresh reduction Hello, Are MsgIds used only for stable states refresh messages or also for trigger messages. RFC2961 mentions using for any RSVP message - would mean they are used for PATHTEAR, RESVTEAR etc. Suppose I have setup- Node1 ----- Node2 ------ Node3 ------ Node4 Both bundling and msgids used only between Node2 and Node3. I have one lsp from Node1 to Node 4 and it is in stable state. Now I setup one more lsp from Node1 to Node4. PATH message for this new lsp reaches Node2 and it suppose happens to coincide at the same time as Node2 is sending its Summary refresh for the first lsp. Cuz of bundling would this ACK be piggy-backed on the trigger PATH for the new lsp. If so would the destination IP of bundled packet be changed to next-hop of Node3 or would it still be Node4 (cuz PATH is being sent to Node4) _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mpls@UU.NET Thu Nov 1 17:49:58 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02349 for ; Thu, 1 Nov 2001 17:49:57 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnhz01558; Thu, 1 Nov 2001 22:50:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnhz05118 for mpls-outgoing; Thu, 1 Nov 2001 22:49:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlnhz05111 for ; Thu, 1 Nov 2001 22:49: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 QQlnhz28074 for ; Thu, 1 Nov 2001 22:49:23 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: law2-f13.hotmail.com [216.32.181.13]) id QQlnhz10767 for ; Thu, 1 Nov 2001 22:49:43 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 1 Nov 2001 14:49:22 -0800 Received: from 63.104.212.3 by lw2fd.hotmail.msn.com with HTTP; Thu, 01 Nov 2001 22:49:22 GMT X-Originating-IP: [63.104.212.3] From: "Sandeep S" To: mpls@UU.NET Subject: RE: questions related to Refresh reduction Date: Thu, 01 Nov 2001 22:49:22 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Nov 2001 22:49:22.0912 (UTC) FILETIME=[731B2E00:01C16327] Sender: owner-mpls@UU.NET Precedence: bulk Thanks Rajeev. One more question - So if PATHTEAR/RESVTEAR/PATHERROR/RESVERROR messages are set with ACK bit and the peer replies with a NACK/ACK, cuz it is not a reliable exchange or as we don't care about it being received by next-hop or not, these ACKs or NACKs would be dropped or would never matter even if we don't get them -Sandeep >SRefresh msgs can used only if the corresponding PATH/RESV trigger msgs >have been sent with MSG_ID objects. That's how you can associate the >states.. > >MSG_ID_ACK/NACK can be either sent in seperate msgs or piggybacked in >other msgs.. > >Bundle msgs are always addressed to the immediate RSVP peer. The >sub-msgs contained inside the bundle msgs are themselves complete msgs >with their own rsvp header.. > >with regards, >Rajeev > >-----Original Message----- >From: Sandeep S [mailto:san_101@hotmail.com] >Sent: Thursday, November 01, 2001 1:50 PM >To: mpls@UU.NET >Subject: questions related to Refresh reduction > > >Hello, > >Are MsgIds used only for stable states refresh messages or also for >trigger >messages. RFC2961 mentions using for any RSVP message - would mean they >are >used for PATHTEAR, RESVTEAR etc. > >Suppose I have setup- > >Node1 ----- Node2 ------ Node3 ------ Node4 > >Both bundling and msgids used only between Node2 and Node3. I have one >lsp >from Node1 to Node 4 and it is in stable state. Now I setup one more lsp > >from Node1 to Node4. PATH message for this new lsp reaches Node2 and it >suppose happens to coincide at the same time as Node2 is sending its >Summary >refresh for the first lsp. Cuz of bundling would this ACK be >piggy-backed on >the trigger PATH for the new lsp. If so would the destination IP of >bundled >packet be changed to next-hop of Node3 or would it still be Node4 (cuz >PATH >is being sent to Node4) > >_________________________________________________________________ >Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mpls@UU.NET Thu Nov 1 20:39:27 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05461 for ; Thu, 1 Nov 2001 20:39:27 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnik18835; Fri, 2 Nov 2001 01:39:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnik16214 for mpls-outgoing; Fri, 2 Nov 2001 01:39:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlnik16207 for ; Fri, 2 Nov 2001 01:38: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 QQlnik25233 for ; Fri, 2 Nov 2001 01:38:37 GMT Received: from rcsntx.swbell.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mta4.rcsntx.swbell.net [151.164.30.28]) id QQlnik17490 for ; Fri, 2 Nov 2001 01:38:57 GMT Received: from yongjuni ([64.123.58.120]) by mta4.rcsntx.swbell.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GM500HNQGK5MO@mta4.rcsntx.swbell.net> for mpls@uu.net; Thu, 01 Nov 2001 19:38:29 -0600 (CST) Date: Thu, 01 Nov 2001 19:35:44 -0600 From: Yongjun Im Subject: Re: question on e-lsp and l-lsp To: Vishal M Cc: mpls@UU.NET Reply-to: Yongjun Im Message-id: <00b301c1633e$b0c04f80$1700000a@lg.co.kr> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20011102012854.20434.qmail@web13508.mail.yahoo.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT ----- Original Message ----- From: "Vishal M" To: "Yongjun Im" Cc: Sent: Thursday, November 01, 2001 7:28 PM Subject: Re: question on e-lsp and l-lsp > > > > > 1. Can we map multiple CTs onto a single L-LSP ? > > The > > > draft seem to suggest that creation of a separate > > LSP > > > can be done for every CT. > > > > What is CT? > > ...I apologize...CT stands for Class Type... > So can we map multiple Class Types onto a single > L-LSP ? In order to map multiple class types to LSP, the class type should be mapped into EXP fileld in a shim header. That is the definition of E-LSP. In case of L-LSP, the only class identifier available to an LSR is a label value. That is the definition of L-LSP. > > Thanks, > Vishal. > > > > > > > Is creation of separate L-LSP mandatory for every > > CT > > > or is it left to the implementation? > > > > > > __________________________________________________ > Do You Yahoo!? > Find a job, post your resume. > http://careers.yahoo.com > From owner-mpls@UU.NET Thu Nov 1 23:56:16 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10368 for ; Thu, 1 Nov 2001 23:56:16 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnix19031; Fri, 2 Nov 2001 04:56:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnix25775 for mpls-outgoing; Fri, 2 Nov 2001 04:56:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlnix25757 for ; Fri, 2 Nov 2001 04:56:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlnix05112 for ; Fri, 2 Nov 2001 04:53:39 GMT Received: from itplgateway.cpqitpltech4 by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.4.185.134]) id QQlnix24015 for ; Fri, 2 Nov 2001 04:53:56 GMT Received: from KRISHNAKANTH ([192.168.0.105]) by itplgateway.cpqitpltech4 with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V8AS2JJ5; Fri, 2 Nov 2001 10:21:56 +0530 Message-ID: <00bf01c1635b$1a9ee800$6900a8c0@krishnakanth> From: "Krishnakanth Rao" To: Subject: LIB and NHLFE Date: Fri, 2 Nov 2001 10:29:08 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BC_01C16389.34387870" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00BC_01C16389.34387870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Are LIB(label information base) and NHLFE(next hop label forwarding = entry) both the same Krishnakanth ------=_NextPart_000_00BC_01C16389.34387870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Are LIB(label information base) and = NHLFE(next hop=20 label forwarding entry) both the same
 
Krishnakanth
 
------=_NextPart_000_00BC_01C16389.34387870-- From owner-mpls@UU.NET Fri Nov 2 01:25:52 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14204 for ; Fri, 2 Nov 2001 01:25:52 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnjd20963; Fri, 2 Nov 2001 06:25:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnjd08212 for mpls-outgoing; Fri, 2 Nov 2001 06:25:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlnjd08207 for ; Fri, 2 Nov 2001 06:25: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 QQlnjd15897 for ; Fri, 2 Nov 2001 06:24:51 GMT Received: from multitech.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQlnjd07290 for ; Fri, 2 Nov 2001 06:25:07 GMT Received: from abhay (abhay [192.168.1.136]) by multitech.co.in (8.11.0/8.11.0) with SMTP id fA26OBQ06496 for ; Fri, 2 Nov 2001 11:54:13 +0530 Message-ID: <001001c16367$fcac0dc0$dff2fea9@abhay> From: "abhay" To: "'mpls@uu.net'" References: <751B6DD7A243D511AB9F0002557C56870154531F@HUAWEIMAIL> <001601c15d0e$f09b00e0$dff2fea9@abhay> Subject: Binding DSCP at the Ingress Date: Fri, 2 Nov 2001 12:01:07 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C16396.0E56D360" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C16396.0E56D360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Doubt in draft-ietf-mpls-te-mib-07.txtHello All, What are the steps to be considered when mapping the DSCP = field in the ipv4/ipv6 to FEC's at ingress. What changes are necessary for the distribution protocol. I dont need the routers to examine the dscp field along each = hop. Thanks in advance, Regards, Abhay =20 =20 ----- Original Message -----=20 From: abhay=20 To: Ashwin C. Prabhu ; mpls-ops@mplsrc.com ; 'mpls@uu.net'=20 Cc: cheenu@alphion.com ; tnadeau@cisco.com ; arun@force10networks.com=20 Sent: Thursday, October 25, 2001 10:08 AM Subject: Re: Why do we need CR-LDP Tunnel Resource Table in TE MIB 7? Ashwin, Sometime ago the CR-LDP sentence in the MIB was not present = for resource allocation. And during those times,I used my own MIB variables,just to = have a little fun and give CR-LDP a fair chance.Now u see it,later u wont...again..any = extensions to CR-LDP,you will see it again. In good humour. Regards, Abhay ----- Original Message -----=20 From: Ashwin C. Prabhu=20 To: mpls-ops@mplsrc.com ; 'mpls@uu.net'=20 Cc: cheenu@alphion.com ; tnadeau@cisco.com ; = arun@force10networks.com=20 Sent: Wednesday, October 24, 2001 3:43 PM Subject: Why do we need CR-LDP Tunnel Resource Table in TE MIB 7? Hello All =20 Why the CR-LDP Tunnel Resource Table is added in the = draft-ietf-mpls-te-mib-07.txt.=20 There is also a mplsTunnelResourceTable which has all the = parameters=20 of the mplsTunnelCRLDPResTable.=20 =20 And the note specifically says that this is in addition to the = Tunnel Resource Table .=20 =20 The mplsTunnelCRLDPResTable allows a manager to specify which CR-LDP-specific resources are desired for an MPLS tunnel if that tunnel is signaled using CR-LDP. Note that these attributes are in addition to those specified in mplsTunnelResourceTable. This table also allows several tunnels to point to a single entry in this table, implying that these tunnels should share resources. =20 And the parameters of the table are same expect the = mplsTunnelCRLDPResFlags. Can you please tell me what is the differance between these 2 tables = and why is this=20 needed ? =20 =20 Ashwin =20 =20 =20 =20 ------=_NextPart_000_000D_01C16396.0E56D360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Doubt in draft-ietf-mpls-te-mib-07.txt
Hello All,
          &nbs= p; What=20 are the steps to be considered when mapping the DSCP field in the=20 ipv4/ipv6
          &nbs= p; to=20 FEC's at ingress.
          &nbs= p; What=20 changes are necessary for the distribution protocol.
          &nbs= p; I=20 dont need the routers to examine the dscp field along each = hop.
       =20     Thanks in advance,
       =20     Regards,
       =20     Abhay
          =20
          &nbs= p;=20
----- Original Message -----
From:=20 abhay=20
To: Ashwin C.=20 Prabhu ; mpls-ops@mplsrc.com ; 'mpls@uu.net' =
Cc: cheenu@alphion.com ; tnadeau@cisco.com=20 ; arun@force10networks.com
Sent: Thursday, October 25, = 2001 10:08=20 AM
Subject: Re: Why do we need = CR-LDP Tunnel=20 Resource Table in TE MIB 7?

Ashwin,
           = Sometime=20 ago the CR-LDP sentence in the MIB was not present for resource=20 allocation.
           = And during=20 those times,I used my own MIB variables,just to have a little fun and = give=20 CR-LDP
          &nbs= p;a=20 fair chance.Now u see it,later u wont...again..any extensions to = CR-LDP,you=20 will see it again.
           = In good=20 humour.
          =20 Regards,
          &nbs= p;Abhay
----- Original Message -----
From:=20 Ashwin C.=20 Prabhu
To: mpls-ops@mplsrc.com ; 'mpls@uu.net' =
Cc: cheenu@alphion.com ; tnadeau@cisco.com ; arun@force10networks.com
Sent: Wednesday, October 24, = 2001 3:43=20 PM
Subject: Why do we need = CR-LDP Tunnel=20 Resource Table in TE MIB 7?

 
Hello All
 
 Why the CR-LDP Tunnel Resource = Table is added=20 in the draft-ietf-mpls-te-mib-07.txt.
 There is also a = mplsTunnelResourceTable which=20 has all the parameters
 of the mplsTunnelCRLDPResTable.=20
 
 And the note specifically says that = this is=20 in addition to the Tunnel Resource Table .
 
The mplsTunnelCRLDPResTable = allows a=20 manager to
          = specify=20 which CR-LDP-specific resources are=20 desired
          = for an=20 MPLS tunnel if that tunnel is signaled=20 using
          = CR-LDP.=20 Note that these attributes are in=20 addition
          = to those=20 specified in mplsTunnelResourceTable.=20 = This
          = table=20 also allows several tunnels to point to=20 a
          single = entry in=20 this table, implying that=20 these
          = tunnels=20 should share resources.
 
And the parameters of the table are same = expect the=20 mplsTunnelCRLDPResFlags.
Can you please tell me what is the = differance=20 between these 2 tables and why is this
needed ?
 
 
Ashwin
 
 
 
 
------=_NextPart_000_000D_01C16396.0E56D360-- From owner-mpls@UU.NET Fri Nov 2 03:31:36 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27838 for ; Fri, 2 Nov 2001 03:31:35 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnjm14170; Fri, 2 Nov 2001 08:31:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnjm22495 for mpls-outgoing; Fri, 2 Nov 2001 08:31:16 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlnjm22490 for ; Fri, 2 Nov 2001 08:31:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlnjm15400 for ; Fri, 2 Nov 2001 08:31:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlnjm14817 for ; Fri, 2 Nov 2001 08:31:23 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA22215 for ; Fri, 2 Nov 2001 03:31:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA08686 for mpls@uu.net; Fri, 2 Nov 2001 03:31:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlnjm22452 for ; Fri, 2 Nov 2001 08:30:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlnjl10470 for ; Fri, 2 Nov 2001 08:28:56 GMT Received: from 8848.net by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [211.99.202.115]) id QQlnjl12178 for ; Fri, 2 Nov 2001 08:28:43 GMT Received: from 8848.net([10.1.0.100]) by 8848.net(JetMail 2.5.3.0) with SMTP id jm123be2aedc; Fri, 2 Nov 2001 08:26:40 -0000 Received: from cmr2.ash.ops.us.uu.net([198.5.241.40]) by 8848.net(JetMail 2.5.3.0) with SMTP id jmd43bdd9b98; Mon, 29 Oct 2001 14:26:32 -0000 Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlmvp04192; Mon, 29 Oct 2001 14:25:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQlmvp29990 for mpls-outgoing; Mon, 29 Oct 2001 14:24:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlmvp29985 for ; Mon, 29 Oct 2001 14:24:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlmvp13704 for ; Mon, 29 Oct 2001 14:24:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlmvp19113 for ; Mon, 29 Oct 2001 14:24:21 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA18573 for ; Mon, 29 Oct 2001 09:24:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA09361 for mpls@uu.net; Mon, 29 Oct 2001 09:24:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlmvp29881 for ; Mon, 29 Oct 2001 14: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 QQlmvp04686 for ; Mon, 29 Oct 2001 14:23:03 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQlmvp00119 for ; Mon, 29 Oct 2001 14:23:23 GMT Received: from ASIMHA-W2K.cisco.com (dhcp-64-102-48-149.cisco.com [64.102.48.149]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA19252; Mon, 29 Oct 2001 09:23:00 -0500 (EST) Date: Mon, 29 Oct 2001 09:22:09 -0500 (Eastern Standard Time) From: Ajay Simha To: Shirish Indurkar cc: MPLS Subject: Re: Doubt in MPLS-VPN .... In-Reply-To: <3BDD3D8D.D80340C2@cisco.com> Message-ID: X-X-Sender: asimha@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 29 Oct 2001, Shirish Indurkar wrote: SI>Hi All, SI> SI>It is said that MPLS-VPNs generally consists of a set of sites that SI>are interconnected by means of MPLS provider core network and the SI>Service providers backbone consists of PE routers and Provider routers. SI> SI>Now that MPLS forwarding carries packets between PEs routers through the SI>service provider backbone , MPLS packet must traverse through the P routers SI>(if any) in between these PE routers. SI> SI>My question is how we can be sure that the MPLS-VPN Packet is really Safe SI>when it traverses through the P routers ? I mean how the corporate information SI>is still secured when it passes through the P routers ? It is still traversing SI>through the Public infrastructure unencrypted . SI> SI>Any suggestion of yours would be of great help . Is the packet "safe" when it traverses a provider network when you buy frame relay or atm service or a leased line? If you are still concerned in the atm/fr/leased line situation what would you do - my guess is you'd encrypt you data from the customer end. You can still do this with MPLS VPNs. -ajay SI> SI>Thanks in advance . SI> SI>Shirish. SI> -- Ajay Simha MPLS Deployment Engineer IOS Technology Division (919) 392-3141 "Study as if you were to live forever Live as if you were to die tomorrow" - Mahatma Gandhi From owner-mpls@UU.NET Fri Nov 2 09:45:28 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06365 for ; Fri, 2 Nov 2001 09:45:28 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnkl11579; Fri, 2 Nov 2001 14:45:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnkk09644 for mpls-outgoing; Fri, 2 Nov 2001 14:44:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlnkk09638 for ; Fri, 2 Nov 2001 14:44:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlnkk12241 for ; Fri, 2 Nov 2001 14:41:44 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 QQlnkk18174 for ; Fri, 2 Nov 2001 14:42:04 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16364; Fri, 2 Nov 2001 09:41:40 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00982; Fri, 2 Nov 2001 09:41:40 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Nov 2001 09:41:39 -0500 Message-ID: <313680C9A886D511A06000204840E1CF76B85C@whq-msgusr-02.pit.comms.marconi.com> From: "Iren, Sami" To: "'Yongjun Im'" , Vishal M Cc: mpls@UU.NET Subject: RE: question on e-lsp and l-lsp Date: Fri, 2 Nov 2001 09:41:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I think the use of the term "class type" is not clear here. *If you are referring to the "class type" as defined in draft-ietf-tewg-diff-te-reqts-01.txt and draft-lefaucheur-diff-te-proto-00.txt, the mapping is in the form of service class to class type. That is every service class (PSC) belongs to a class type. When an lsp is signalled, the class type is signalled in the CLASSTYPE object. And only one classtype can be signalled per lsp (be it L-LSP or E-LSP). See above drafts for more information. *If you are referring to service class (PSC) such as EF, BE, or AF classes, then each L-LSP can signal only one service class. That is a single L-LSP can only carry traffic belonging to a single service class. If you want to carry several service classes together in a single lsp, you have to use E-LSPs. Regards, --Sami > -----Original Message----- > From: Yongjun Im [mailto:yongjuni@erlangtech.com] > Sent: Thursday, November 01, 2001 8:36 PM > To: Vishal M > Cc: mpls@UU.NET > Subject: Re: question on e-lsp and l-lsp > > > > ----- Original Message ----- > From: "Vishal M" > To: "Yongjun Im" > Cc: > Sent: Thursday, November 01, 2001 7:28 PM > Subject: Re: question on e-lsp and l-lsp > > > > > > > > > > 1. Can we map multiple CTs onto a single L-LSP ? > > > The > > > > draft seem to suggest that creation of a separate > > > LSP > > > > can be done for every CT. > > > > > > What is CT? > > > > ...I apologize...CT stands for Class Type... > > So can we map multiple Class Types onto a single > > L-LSP ? > In order to map multiple class types to LSP, the class type should be > mapped into EXP fileld in a shim header. That is the > definition of E-LSP. > In case of L-LSP, the only class identifier available to an > LSR is a label value. > That is the definition of L-LSP. > > > > Thanks, > > Vishal. > > > > > > > > > > Is creation of separate L-LSP mandatory for every > > > CT > > > > or is it left to the implementation? > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Find a job, post your resume. > > http://careers.yahoo.com > > > > From owner-mpls@UU.NET Fri Nov 2 11:44:25 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10997 for ; Fri, 2 Nov 2001 11:44:24 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnks21200; Fri, 2 Nov 2001 16:44:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnks26762 for mpls-outgoing; Fri, 2 Nov 2001 16:43:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlnks26757 for ; Fri, 2 Nov 2001 16:43:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlnks19492 for ; Fri, 2 Nov 2001 16:43:44 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlnks19940 for ; Fri, 2 Nov 2001 16:44:04 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA01835 for ; Fri, 2 Nov 2001 11:43:43 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA02281 for mpls@uu.net; Fri, 2 Nov 2001 11:43:43 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlniq01205 for ; Fri, 2 Nov 2001 03:09: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 QQlniq27869 for ; Fri, 2 Nov 2001 03:08:50 GMT Received: from web13504.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13504.mail.yahoo.com [216.136.175.83]) id QQlniq12936 for ; Fri, 2 Nov 2001 03:09:11 GMT Message-ID: <20011102030849.66317.qmail@web13504.mail.yahoo.com> Received: from [63.121.148.130] by web13504.mail.yahoo.com via HTTP; Thu, 01 Nov 2001 19:08:49 PST Date: Thu, 1 Nov 2001 19:08:49 -0800 (PST) From: Vishal M Subject: RE: question on e-lsp and l-lsp (Drop Precedence) To: mpls@UU.NET In-Reply-To: <3549C09B853DD5119B540002A52CDD348F04BA@zcard0ka.ca.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Since EXP bits are used to classify traffic types, how is drop precedence specified in E-LSP? Is drop-precedence implied by the traffic class itself? I understand with L-LSP, EXP bits are used to specify this. Thanks, Vishal. --- David Allan wrote: > That and the fact that VCCs by design do not support > multiple queuing > disciplines. Shuffling the cell order tends to cause > problems ;-) > > Dave > > > -----Original Message----- > > From: Proch, Daniel > [mailto:Daniel.Proch@marconi.com] > > Sent: Thursday, November 01, 2001 4:40 PM > > To: 'Vishal M'; mpls@UU.NET > > Subject: RE: question on e-lsp and l-lsp > > > > > > Vishal, > > > > Somewhere I read that E-LSP shouldn't be used for > > ATM-LSR. Could someone please explain why ? > > > > MPLS over ATM (cell) interfaces uses the existing > ATM cell > > structure and > > what were the contents of the VPI field or the > combined > > VPI/VCI fields to > > infer a label. There are no EXP bits in the > header and therefore only > > L-LSPs can be supported on LC-ATM interfaces. > > > > dan > > > > -----Original Message----- > > From: Vishal M [mailto:vishal_study@yahoo.com] > > Sent: Thursday, November 01, 2001 3:59 PM > > To: mpls@UU.NET > > Subject: Re: question on e-lsp and l-lsp > > > > > > > > Hi, > > > > I have some followup questions on L-LSP and > E-LSPs: > > > > 1. Can we map multiple CTs onto a single L-LSP ? > The > > draft seem to suggest that creation of a separate > LSP > > can be done for every CT. > > > > Is creation of separate L-LSP mandatory for every > CT > > or is it left to the implementation? > > > > 2. Somewhere I read that E-LSP shouldn't be used > for > > ATM-LSR. Could someone please explain why ? > > > > Thanks for your time, > > Vishal. > > > > "Fan, Zhong" wrote: > > > > > > Can anybody shed some light on the differences > > between e-lsp and > > > l-lsp please? I'm reading > > draft-ietf-mpls-diff-ext-09.txt at the > > > moment. Although the draft gives denifition of > these > > two kinds of > > > LSPs, I am still confused. Is this all about the > > mapping of diffserv > > > classes to MPLS FEC or EXP? > > > > The draft explains the differences. > > > > In superbrief summary; > > > > - An L-LSP has one QoS for all packets. It is > > determined at LSP > > setup. This is similar to setting up an LSP > without > > any DiffServ > > extensions, except that the objects used in the > > signaling are > > different. > > > > - An E-LSP has up to 8 QoS levels for the single > LSP. > > The EXP bits > > determine the appropriate QoS on a per-packet > basis. > > The QoS that > > is assigned to each EXP value is signaled at LSP > > setup (or is a > > configured default if the values are not > signaled.) > > > > -- David > > > > > > __________________________________________________ > > Do You Yahoo!? > > Make a great connection at Yahoo! Personals. > > http://personals.yahoo.com > > > > > __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From owner-mpls@UU.NET Fri Nov 2 11:44:54 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11066 for ; Fri, 2 Nov 2001 11:44:54 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnkt17637; Fri, 2 Nov 2001 16:45:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnks26924 for mpls-outgoing; Fri, 2 Nov 2001 16:44:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlnks26867 for ; Fri, 2 Nov 2001 16:44:07 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 QQlnks06997 for ; Fri, 2 Nov 2001 16:43:34 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlnks19661 for ; Fri, 2 Nov 2001 16:43:54 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA01821 for ; Fri, 2 Nov 2001 11:43:32 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA02277 for mpls@uu.net; Fri, 2 Nov 2001 11:43:32 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlnij15521 for ; Fri, 2 Nov 2001 01:29:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlnij29336 for ; Fri, 2 Nov 2001 01:28:55 GMT Received: from web13508.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13508.mail.yahoo.com [216.136.175.87]) id QQlnij04517 for ; Fri, 2 Nov 2001 01:29:15 GMT Message-ID: <20011102012854.20434.qmail@web13508.mail.yahoo.com> Received: from [63.121.148.130] by web13508.mail.yahoo.com via HTTP; Thu, 01 Nov 2001 17:28:54 PST Date: Thu, 1 Nov 2001 17:28:54 -0800 (PST) From: Vishal M Subject: Re: question on e-lsp and l-lsp To: Yongjun Im Cc: mpls@UU.NET In-Reply-To: <00dd01c1631b$c178c9b0$4100000a@internal.erlangtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk > > 1. Can we map multiple CTs onto a single L-LSP ? > The > > draft seem to suggest that creation of a separate > LSP > > can be done for every CT. > > What is CT? ...I apologize...CT stands for Class Type... So can we map multiple Class Types onto a single L-LSP ? Thanks, Vishal. > > > > Is creation of separate L-LSP mandatory for every > CT > > or is it left to the implementation? > > __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com From owner-mpls@UU.NET Fri Nov 2 12:03:48 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11710 for ; Fri, 2 Nov 2001 12:03:48 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnku18049; Fri, 2 Nov 2001 17:04:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnku08704 for mpls-outgoing; Fri, 2 Nov 2001 17:03:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlnku08563 for ; Fri, 2 Nov 2001 17:03:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlnku24080 for ; Fri, 2 Nov 2001 17:01:58 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQlnku20565 for ; Fri, 2 Nov 2001 17:02:18 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id fA2H1v065060; Fri, 2 Nov 2001 09:01:58 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200111021701.fA2H1v065060@merlot.juniper.net> To: mpls@UU.NET cc: swallow@cisco.com Subject: changes to unnumbered and link bundling MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <99280.1004720517.1@juniper.net> Date: Fri, 02 Nov 2001 09:01:57 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Folks, Based on the results of the e-mail exchange on this list I plan to make the following changes in draft-ietf-mpls-bundle, draft-ietf-mpls-rsvp-unnum, and in draft-ietf-mpls-crldp-unnum: 1) Mandate that one always use the IF_ID HOP on bundled links (thus eliminating the Implicit Indication from draft-ietf-mpls-bundle-00.txt). 2) Do away with the COMPONENT_IF_* TLV, and just use IF_INDEX for identifying (unnumbered) components in link bundling 3) Mandate that one always use the IF_ID HOP object on an unnumbered link. 4) Make handling numbered and unnumberd interfaces in the ERO more consistent/uniform by changing the semantics of the Unnumbered interface subobject (or more precisely the Interface ID field of this subobject) from: The Interface ID is the outgoing interface identifier with respect to the LSR specified by the router ID. to The Interface ID is the interface identifier assigned to the interface by the LSR specified by the router ID. and making other appropriate changes in the text to reflect this. Yakov. From owner-mpls@UU.NET Fri Nov 2 14:30:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16027 for ; Fri, 2 Nov 2001 14:30:48 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnle04675; Fri, 2 Nov 2001 19:31:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnle08236 for mpls-outgoing; Fri, 2 Nov 2001 19:30:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlnle08231 for ; Fri, 2 Nov 2001 19:30: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 QQlnle14778 for ; Fri, 2 Nov 2001 19:30:17 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQlnle15268 for ; Fri, 2 Nov 2001 19:30:38 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA16688; Fri, 2 Nov 2001 14:30:14 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24512; Fri, 2 Nov 2001 14:30:16 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Nov 2001 14:30:15 -0500 Message-ID: <313680C9A886D511A06000204840E1CF76B85D@whq-msgusr-02.pit.comms.marconi.com> From: "Iren, Sami" To: "'Vishal M'" , mpls@UU.NET Subject: RE: question on e-lsp and l-lsp (Drop Precedence) Date: Fri, 2 Nov 2001 14:30:14 -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 In the case of E-LSPs, the EXP bits indicate the per hop behavior (PHB) which specifies both the service class and drop precedence (if applicable). For example for AF1 class there are three PHBs: AF11: green AF1 packet AF12: yellow AF1 packet AF13: red AF1 packet For each of these PHBs there is a code point (DSCP). It is this value that is stored in EXP bits. Since it is 3-bits, the EXP field can only store up to 8 PHBs. --Sami > -----Original Message----- > From: Vishal M [mailto:vishal_study@yahoo.com] > Sent: Thursday, November 01, 2001 10:09 PM > To: mpls@UU.NET > Subject: RE: question on e-lsp and l-lsp (Drop Precedence) > > > > Since EXP bits are used to classify traffic types, how > is drop precedence specified in E-LSP? > > Is drop-precedence implied by the traffic class > itself? > > I understand with L-LSP, EXP bits are used to specify > this. > > Thanks, > Vishal. > > --- David Allan wrote: > > That and the fact that VCCs by design do not support > > multiple queuing > > disciplines. Shuffling the cell order tends to cause > > problems ;-) > > > > Dave > > > > > -----Original Message----- > > > From: Proch, Daniel > > [mailto:Daniel.Proch@marconi.com] > > > Sent: Thursday, November 01, 2001 4:40 PM > > > To: 'Vishal M'; mpls@UU.NET > > > Subject: RE: question on e-lsp and l-lsp > > > > > > > > > Vishal, > > > > > > Somewhere I read that E-LSP shouldn't be used for > > > ATM-LSR. Could someone please explain why ? > > > > > > MPLS over ATM (cell) interfaces uses the existing > > ATM cell > > > structure and > > > what were the contents of the VPI field or the > > combined > > > VPI/VCI fields to > > > infer a label. There are no EXP bits in the > > header and therefore only > > > L-LSPs can be supported on LC-ATM interfaces. > > > > > > dan > > > > > > -----Original Message----- > > > From: Vishal M [mailto:vishal_study@yahoo.com] > > > Sent: Thursday, November 01, 2001 3:59 PM > > > To: mpls@UU.NET > > > Subject: Re: question on e-lsp and l-lsp > > > > > > > > > > > > Hi, > > > > > > I have some followup questions on L-LSP and > > E-LSPs: > > > > > > 1. Can we map multiple CTs onto a single L-LSP ? > > The > > > draft seem to suggest that creation of a separate > > LSP > > > can be done for every CT. > > > > > > Is creation of separate L-LSP mandatory for every > > CT > > > or is it left to the implementation? > > > > > > 2. Somewhere I read that E-LSP shouldn't be used > > for > > > ATM-LSR. Could someone please explain why ? > > > > > > Thanks for your time, > > > Vishal. > > > > > > "Fan, Zhong" wrote: > > > > > > > > Can anybody shed some light on the differences > > > between e-lsp and > > > > l-lsp please? I'm reading > > > draft-ietf-mpls-diff-ext-09.txt at the > > > > moment. Although the draft gives denifition of > > these > > > two kinds of > > > > LSPs, I am still confused. Is this all about the > > > mapping of diffserv > > > > classes to MPLS FEC or EXP? > > > > > > The draft explains the differences. > > > > > > In superbrief summary; > > > > > > - An L-LSP has one QoS for all packets. It is > > > determined at LSP > > > setup. This is similar to setting up an LSP > > without > > > any DiffServ > > > extensions, except that the objects used in the > > > signaling are > > > different. > > > > > > - An E-LSP has up to 8 QoS levels for the single > > LSP. > > > The EXP bits > > > determine the appropriate QoS on a per-packet > > basis. > > > The QoS that > > > is assigned to each EXP value is signaled at LSP > > > setup (or is a > > > configured default if the values are not > > signaled.) > > > > > > -- David > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Make a great connection at Yahoo! Personals. > > > http://personals.yahoo.com > > > > > > > > > > > __________________________________________________ > Do You Yahoo!? > Make a great connection at Yahoo! Personals. > http://personals.yahoo.com > From owner-mpls@UU.NET Fri Nov 2 15:10:05 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16951 for ; Fri, 2 Nov 2001 15:10:03 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnlg02550; Fri, 2 Nov 2001 20:09:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnlg29801 for mpls-outgoing; Fri, 2 Nov 2001 20:09:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlnlg29795 for ; Fri, 2 Nov 2001 20:09: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 QQlnlg07974 for ; Fri, 2 Nov 2001 20:07:50 GMT Received: from exchange01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange01.movaz.com [65.205.166.180]) id QQlnlg14526 for ; Fri, 2 Nov 2001 20:08:11 GMT Received: from BLIULAPTOP ([172.16.24.104]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 2 Nov 2001 15:07:50 -0500 Message-ID: <077401c163da$0c342990$681810ac@movaz.com> From: "Adrian Farrel" To: "Edward Harrison" Cc: , "Tim Hall" , "NEC - Atsushi Iwata" , , "AT & T - Jerry Ash" References: <53F74F5A7B94D511841C00B0D0AB16F813611F@baker.datcon.co.uk> Subject: Re: Comment and suggestion for draft-iwata-mpls-crankback-01.txt Date: Fri, 2 Nov 2001 15:07:49 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 02 Nov 2001 20:07:50.0311 (UTC) FILETIME=[0C476370:01C163DA] Sender: owner-mpls@UU.NET Precedence: bulk Hi Ed, Apologies for a very late reply, and thank you for your interest in this draft. Comments in-line in your edited text. > Reporting upstream Link blockages > ================================= > > In section 5, Location Identifiers of Blocked Links or Nodes, there is the > following sentence: > > "Upon a link blockage, the first and second ER-Hop TLVs are > returned, which means that the blockage location is the link between > the two nodes indicated by these TLVs." > > Whilst this seems to work fine if the blockage is on the downstream link, > there are circumstances where the blockage may be on the upstream link. For > example, in RSVP when processing a Resv, there may not be sufficient > resources on the upstream link. Alternatively, if out of band signalling is > used, the signaling message (e.g. an RSVP Path) may arrive at the downstream > node, but the data link to the upstream node may be unavailable. As you note later, this (RSVP-only) scenario is covered in section 9.6. Your point has a more general message, however, and the situation may arise on the forward path (the downstream node is unable to reserve the resources for the incoming link). We will generalize the text to indicate that - the use of ER hops as discussed is just an example - the point is to provide (in forward path order) the two hops that encompass the link. We will also beef up section 9.6 to be more explicit about where the implementation should go for information to fill into the Rerouting object. > Dealing with ResvErr message using SE style > =========================================== > > In section 9.6, ResvErr usage, there is the following text: > > "When a ResvErr carrying a Rerouting object is received at an egress > LSR, the egress LSR MAY ignore this object and perform the same > actions as for any other ResvErr. However, if the egress LSR supports > the crankback extensions defined in this draft, it SHOULD generate a > PathErr message and send it to the ingress LSR." > > I think this fails to address ResvErr messages that use the Shared Explicit > (SE) style and actually refers to more than one LSP (for example, if make > before break is being used). Under these circumstances multiple PathErr > message should presumably be sent, each containing the rerouting object. > > Perhaps adding the following text would be appropriate: > > "If the ResvErr uses the SE style and refers to more than one Path, a > PathErr SHOULD be sent for each of the LSPs indicated in the Filterspec > object of the ResvErr." Correct. We will add something of this nature. > Reporting Label information > =========================== > > I realise that your original draft concentrates on base MPLS rather than > GMPLS. That's true, but at this time we don't see any need for an additional object (although we're happy to continue to look at this). [SNIP] > When Explicit Label control is used, it could be useful for the rerouting > information to contain not only information on the node or link that caused > the failure, but also, if it was a specific label operation that caused the > failure, information on the label that failed. For example, if the lambda was specified in the ERO then identifying the link that failed together with a reason code is enough to identify the failed lambda. There are already reason codes (e.g. in generalized-rsvp-te) to cover these events. If the lambda was not specified in the ERO then identifying which one failed may not be much use to the repair point. But (as you say) the Acceptable Label Set gives lots of useful information about how tro modify the ERO to give it a good chance of success. > Note that this object may prove superfluous given the recent addition of > Acceptable Label Set to the GMPLS drafts. That said, the two objects > provide subtly different things - Acceptable Label Set telling you which > labels you can use, whilst the above object tells you which ones you can't. > I'd be interested to know if you feel it would be useful to have these two > pieces of information, or whether Acceptable Label Set is enough. Actually, knowing one label that you can't use, doesn't seem very helpful. Knowing the full list that you can use seems more useful. Again, there is a wider point which you raise which is useful. We will look more widely at providing supplementary information for resource failures. Regards, Adrian From owner-mpls@UU.NET Fri Nov 2 15:12:05 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16989 for ; Fri, 2 Nov 2001 15:12:05 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnlg22021; Fri, 2 Nov 2001 20:12:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnlg00165 for mpls-outgoing; Fri, 2 Nov 2001 20:11:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlnlg00159 for ; Fri, 2 Nov 2001 20:11:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlnlg10832 for ; Fri, 2 Nov 2001 20:11:25 GMT Received: from dnsmx1rrc.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQlnlg20892 for ; Fri, 2 Nov 2001 20:11:45 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA05380 for ; Fri, 2 Nov 2001 15:08:54 -0500 (EST) Subject: rsvpte questions To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Fri, 2 Nov 2001 15:08:53 -0500 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 11/02/2001 03:08:54 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have questions for the rsvpte. 1. Can I interpret no acceptable links as unknown ip addresss in the second ERO in the path msg sent out from Ingress,and then the InterLSR will send out the patherr msg with error code 'Routing problem', and 'no route available toward destination'. (draft rsvpte secion 4.7.4). (I observed one vendor implement this way) or path msg has to pass the three tests.(can some one give me the example for the value Link-attr) In order to be validated a link MUST pass the following three tests. To precisely describe the tests use the definitions in the object description above. We also define Link-attr A 32-bit vector representing attributes associated with a link. The three tests are 1. Exclude-any This test excludes a link from consideration if the link carries any of the attributes in the set. (link-attr & exclude-any) == 0 2. Include-any This test accepts a link if the link carries any of the attributes in the set. (include-any == 0) | ((link-attr & include-any) != 0) 3. Include-all This test accepts a link only if the link carries all of the attributes in the set. (include-all == 0) | (((link-attr & include-all) ^ include- all) == 0) For a link to be acceptable, all three tests MUST pass. If the test fails, the node SHOULD send a PathErr message with an error code of "Routing Problem" and an error value of "no route available toward destination". 2. In rfc 2205 appendix B, the error code 21, and sb-code 01, service coflict, does it mean the conflict of Thanks, Julia Thanks, From owner-mpls@UU.NET Fri Nov 2 17:05:10 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19958 for ; Fri, 2 Nov 2001 17:05:10 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnlo11883; Fri, 2 Nov 2001 22:05:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnlo08728 for mpls-outgoing; Fri, 2 Nov 2001 22:04:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlnlo08685 for ; Fri, 2 Nov 2001 22:04:31 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 QQlnlo26181 for ; Fri, 2 Nov 2001 22:04:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlnlo22654 for ; Fri, 2 Nov 2001 22:03:53 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA15638 for ; Fri, 2 Nov 2001 17:04:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA16812 for mpls@uu.net; Fri, 2 Nov 2001 17:04:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlnlo08583 for ; Fri, 2 Nov 2001 22:03:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlnlo12932 for ; Fri, 2 Nov 2001 22:03:25 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlnlo21568 for ; Fri, 2 Nov 2001 22:03:14 GMT Received: from telescope.cisco.com (telescope.cisco.com [161.44.166.204]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA15530 for ; Fri, 2 Nov 2001 17:03:22 -0500 (EST) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA23076 for ; Fri, 2 Nov 2001 17:03:21 -0500 (EST) Message-Id: <200111022203.RAA23076@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Second last call on LDP Query Date: Fri, 02 Nov 2001 17:03:21 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk This message begins a one week last call on: MPLS LDP Query Message Description draft-ietf-mpls-lsp-query-03.txt The last call ends Friday Nov 9, 12pm GMT. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Sat Nov 3 20:28:44 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20013 for ; Sat, 3 Nov 2001 20:28:43 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlnpt27971; Sun, 4 Nov 2001 01:28:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQlnpt22207 for mpls-outgoing; Sun, 4 Nov 2001 01:28:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlnpt22202 for ; Sun, 4 Nov 2001 01:28:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlnpt28053 for ; Sun, 4 Nov 2001 01:28:10 GMT Received: from dnsmx1pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQlnpt14798 for ; Sun, 4 Nov 2001 01:28:32 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id UAA11491 for ; Sat, 3 Nov 2001 20:24:53 -0500 (EST) Subject: RSVPTE questions, please help me for this, thanks To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Sat, 3 Nov 2001 20:24:53 -0500 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 11/03/2001 08:24:54 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can someone help me? In the rsvpte ResvTear msg, is there any label object in the FF/SE flow descriptor list? ::= [] [ ]
 
Which label distribution protocol does = cisco IOS=20 support RSVP or CR-LDP ?
 
Krishnakanth
------=_NextPart_000_004F_01C16C28.6B4D8A60-- From owner-mpls@UU.NET Tue Nov 13 03:32:20 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17977 for ; Tue, 13 Nov 2001 03:32:20 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQloyc06167; Tue, 13 Nov 2001 08:32:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQloyc13053 for mpls-outgoing; Tue, 13 Nov 2001 08:31:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQloyc13036 for ; Tue, 13 Nov 2001 08:31:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQloyb07815 for ; Tue, 13 Nov 2001 08:29:22 GMT Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQloyb00908 for ; Tue, 13 Nov 2001 08:29:16 GMT Received: by sanmiguel.madrid.telindus.es with Internet Mail Service (5.5.2448.0) id ; Tue, 13 Nov 2001 09:23:36 +0100 Message-ID: From: Javier Antich To: Krishnakanth Rao , mpls@UU.NET Subject: RE: label distribution protocol Date: Tue, 13 Nov 2001 09:23:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA17977 RSVP-TE, LDP, TDP and MP-BGP for VPN label distribution. ^ ^ ==============ooo====(.)v(.)====ooo===== Javier Antich Romaguera Network Consultant --------------------------------------------------------------------------- TELINDUS Pza. Ciudad de Viena, 6-2º 28040 Madrid --------------------------------------------------------------------------- javier.antich@telindus.es tel: +34 91 456 00 08 fax: +34 91 536 10 74 --------------------------------------------------------------------------- For more information about our products and services, please visit our website http://www.telindus.com --------------------------------------------------------------------------- Full connectivity & mobility ==================ooo0===0ooo======== > -----Mensaje original----- > De: Krishnakanth Rao [SMTP:krishnakanth.rao@cominsights.com] > Enviado el: martes 13 de noviembre de 2001 5:19 > Para: mpls@UU.NET > Asunto: label distribution protocol > > > Which label distribution protocol does cisco IOS support RSVP or CR-LDP ? > > Krishnakanth From owner-mpls@UU.NET Tue Nov 13 03:35:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18002 for ; Tue, 13 Nov 2001 03:35:06 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQloyc04380; Tue, 13 Nov 2001 08:35:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQloyc13226 for mpls-outgoing; Tue, 13 Nov 2001 08:34:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQloyc13195 for ; Tue, 13 Nov 2001 08:34:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQloyc08975 for ; Tue, 13 Nov 2001 08:33:48 GMT Received: from rose.tju.edu.cn by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rose.tju.edu.cn [202.113.0.9]) id QQloyc08930 for ; Tue, 13 Nov 2001 08:33:41 GMT Received: from rose ([202.113.4.43]) by rose.tju.edu.cn (8.9.3/8.8.7) with SMTP id QAA01587 for ; Tue, 13 Nov 2001 16:16:26 +0800 Message-Id: <200111130816.QAA01587@rose.tju.edu.cn> Date: Tue, 13 Nov 2001 16:31:22 +0800 From: STONE CHEN To: "mpls@UU.NET" Subject: CBR X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Maybe someone can help me. I am looking for some documents about the algorithm of Constrainte-based Routing (CBR). especially about the delay constraint and the delay model of the router. Thanks in advance. stone From owner-mpls@UU.NET Tue Nov 13 07:22:47 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21085 for ; Tue, 13 Nov 2001 07:22:47 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQloyr07558; Tue, 13 Nov 2001 12:22:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQloyr16898 for mpls-outgoing; Tue, 13 Nov 2001 12:22:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQloyr16893 for ; Tue, 13 Nov 2001 12:22:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQloyr18305 for ; Tue, 13 Nov 2001 12:19:58 GMT Received: from samar.sasken.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQloyr06206 for ; Tue, 13 Nov 2001 12:19:39 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id fADCJjc05182; Tue, 13 Nov 2001 17:49:47 +0530 (IST) Received: from sasken.com (pcsvb197.sasken.com [10.1.66.197]) by sunsv2.sasken.com (8.9.3/8.9.3) with ESMTP id RAA01179; Tue, 13 Nov 2001 17:49:45 +0530 (IST) Message-ID: <3BF10F42.2EB1F39@sasken.com> Date: Tue, 13 Nov 2001 17:47:06 +0530 From: Adithya S Bhat Reply-To: adithya@sasken.com Organization: Sasken X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ppvpn@zephion.net" , MPLS-UUNET Subject: BGP/MPLS VPNs : On an Egress PE, on which table is the label look up done ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, WRT rfc2547bis, Section 5, Forwarding across the backbone: "MPLS will then carry the packet across the backbone. The egress PE router's treatment of the packet will depend on the Label that was first pushed on by the ingress PE. In many cases, the PE will be able to determine, from this label, the sub-interface over which the packet should be transmitted (to a CE device), as well as the proper data link layer header for that interface. " To determine the sub-interface over which the packet is transmitted ( to a CE ), the PE , I assume, will have to do a label look up in some table. I am not abel to understand, what table will this be ? ( as per my understanding ) I am sure that this not the VRF. Juniper white paper on rfc2547bis ( Example #1) talks of a "MPLS forwarding table", on which the the label look up is done. Is this table similar to LIB in LDP ??, if yes, can I assume that BGP will maintain a seperate LIB. Am i missing something here ? Regard -- Adithya From owner-mpls@UU.NET Tue Nov 13 08:05:43 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22099 for ; Tue, 13 Nov 2001 08:05:43 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQloyu19183; Tue, 13 Nov 2001 13:05:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQloyu01061 for mpls-outgoing; Tue, 13 Nov 2001 13:05:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQloyu01019 for ; Tue, 13 Nov 2001 13:05:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQloyu28655 for ; Tue, 13 Nov 2001 13:05:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQloyu18334 for ; Tue, 13 Nov 2001 13:04:50 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA02169 for ; Tue, 13 Nov 2001 08:05:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA18284 for mpls@uu.net; Tue, 13 Nov 2001 08:05:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQloyu00445 for ; Tue, 13 Nov 2001 13:04:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQloyu09570 for ; Tue, 13 Nov 2001 13:04:36 GMT Received: from sj-msg-core-3.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-3.cisco.com [171.70.157.152]) id QQloyu17666 for ; Tue, 13 Nov 2001 13:04:23 GMT Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fADD2Kx02550; Tue, 13 Nov 2001 05:02:20 -0800 (PST) Received: from cisco.com ([10.50.39.29]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id ACO90873; Tue, 13 Nov 2001 04:55:24 -0800 (PST) Message-ID: <3BF11A27.FFFF276E@cisco.com> Date: Tue, 13 Nov 2001 14:03:35 +0100 From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: adithya@sasken.com CC: "ppvpn@zephion.net" , MPLS-UUNET Subject: Re: BGP/MPLS VPNs : On an Egress PE, on which table is the label look up done ? References: <3BF10F42.2EB1F39@sasken.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The most likely you will have a LFIB for such a lookup. That is the table which is build from all label sources (LIB, BGP transported labels ... etc..). R. > Adithya S Bhat wrote: > > Hi all, > > WRT rfc2547bis, Section 5, Forwarding across the backbone: > "MPLS will then carry the packet across the backbone. The egress PE > router's treatment of the packet will depend on the Label that was first > pushed on by the ingress PE. In many cases, the PE will be able to > determine, from this label, the sub-interface over which the packet > should be transmitted (to a CE device), as well as the proper data link > layer header for that interface. " > > To determine the sub-interface over which the packet is transmitted ( to > a CE ), the PE , I assume, will have to do a label look up in some > table. I am not abel to understand, what table will this be ? ( as per > my understanding ) I am sure that this not the VRF. Juniper white paper > on rfc2547bis ( Example #1) talks of a "MPLS forwarding table", on which > the the label look up is done. Is this table similar to LIB in LDP ??, > if yes, can I assume that BGP will maintain a seperate LIB. > > Am i missing something here ? > > Regard > -- > Adithya From owner-mpls@UU.NET Tue Nov 13 08:35:15 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23636 for ; Tue, 13 Nov 2001 08:35:15 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQloyw12807; Tue, 13 Nov 2001 13:34:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQloyw11586 for mpls-outgoing; Tue, 13 Nov 2001 13:34:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQloyw11575 for ; Tue, 13 Nov 2001 13:34:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQloyw06877 for ; Tue, 13 Nov 2001 13:34:29 GMT Received: from mail11.student.main.ntu.edu.sg by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [155.69.5.163]) id QQloyw10794 for ; Tue, 13 Nov 2001 13:34:15 GMT Received: from mail02.student.main.ntu.edu.sg ([155.69.5.166]) by mail11.student.main.ntu.edu.sg with Microsoft SMTPSVC(5.0.2195.2966); Tue, 13 Nov 2001 21:14:52 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: how to map the traffic? Date: Tue, 13 Nov 2001 21:14:52 +0800 Message-ID: <0C42D409AF10B1428A0B026FB160A5BE1C1DFC@mail02.student.main.ntu.edu.sg> Thread-Topic: how to map the traffic? Thread-Index: AcFsRuTTpdvqD9gvEdWKKgABAhIqWA== From: "#ZHU YONGQING#" To: X-OriginalArrivalTime: 13 Nov 2001 13:14:53.0129 (UTC) FILETIME=[2E78B390:01C16C45] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA23636 hi, I have a question about mapping the traffic. When the traffic flows arrive the ingress LSR of MPLS domain, how are they mapped into pre-estabished LSPs? Is it an issue of traffic engineering? Does it need any algorithm or is there any protocol about it? Thanks a lot! From owner-mpls@UU.NET Tue Nov 13 08:45:26 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24047 for ; Tue, 13 Nov 2001 08:45:26 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQloyx00824; Tue, 13 Nov 2001 13:45:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQloyx12432 for mpls-outgoing; Tue, 13 Nov 2001 13:45:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQloyw12355 for ; Tue, 13 Nov 2001 13:44:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQloyw18201 for ; Tue, 13 Nov 2001 13:44:44 GMT Received: from huaweimail.in.huawei.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.162]) id QQloyw28455 for ; Tue, 13 Nov 2001 13:44:30 GMT Received: by HUAWEIMAIL with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 19:18:03 +0530 Message-ID: <751B6DD7A243D511AB9F0002557C568701958396@HUAWEIMAIL> From: "Ashwin C. Prabhu" To: #ZHU YONGQING# , mpls@UU.NET Subject: RE: how to map the traffic? Date: Tue, 13 Nov 2001 19:18:02 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16C49.D04FFD00" 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_01C16C49.D04FFD00 Content-Type: text/plain; charset="iso-8859-1" Hello You can read the section 2.1. FECs of the RFC 3036 Regds Ashwin -----Original Message----- From: #ZHU YONGQING# [mailto:PG01320073@ntu.edu.sg] Sent: Tuesday, November 13, 2001 6:15 PM To: mpls@UU.NET Subject: how to map the traffic? hi, I have a question about mapping the traffic. When the traffic flows arrive the ingress LSR of MPLS domain, how are they mapped into pre-estabished LSPs? Is it an issue of traffic engineering? Does it need any algorithm or is there any protocol about it? Thanks a lot! ------_=_NextPart_001_01C16C49.D04FFD00 Content-Type: text/html; charset="iso-8859-1" RE: how to map the traffic?

Hello

 You can read the section

2.1. FECs of the RFC 3036

Regds
Ashwin

-----Original Message-----
From: #ZHU YONGQING# [mailto:PG01320073@ntu.edu.sg]
Sent: Tuesday, November 13, 2001 6:15 PM
To: mpls@UU.NET
Subject: how to map the traffic?


hi,
I have a question about mapping the traffic. When the traffic flows
arrive the ingress LSR of MPLS domain, how are they mapped into
pre-estabished LSPs? Is it an issue of traffic engineering? Does it need
any algorithm or is there any protocol about it?

Thanks a lot!

------_=_NextPart_001_01C16C49.D04FFD00-- From owner-mpls@UU.NET Tue Nov 13 08:56:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24449 for ; Tue, 13 Nov 2001 08:56:22 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQloyx13922; Tue, 13 Nov 2001 13:56:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQloyx13147 for mpls-outgoing; Tue, 13 Nov 2001 13:55:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQloyx13142 for ; Tue, 13 Nov 2001 13:55: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 QQloyx13652 for ; Tue, 13 Nov 2001 13:54:59 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQloyx12198 for ; Tue, 13 Nov 2001 13:54:47 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA06017 for ; Tue, 13 Nov 2001 08:54:58 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA21336 for mpls@uu.net; Tue, 13 Nov 2001 08:54:58 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQloxi16224 for ; Tue, 13 Nov 2001 03:42:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQloxi24573 for ; Tue, 13 Nov 2001 03:42:42 GMT Received: from mp001.verizon.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mp001pub.verizon.net [206.46.170.170]) id QQloxi11714 for ; Tue, 13 Nov 2001 03:42:36 GMT Received: from [192.168.129.170] by mp001.verizon.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20011113034241.DPSN13782.mp001.verizon.net@[192.168.129.170]> for ; Mon, 12 Nov 2001 21:42:41 -0600 From: Joe Dumont Reply-To: joe.dumont@verizon.net To: mpls@UU.NET Subject: Hello protocol in rsvp-lsp-tunnel-09.txt Date: Mon, 12 Nov 2001 21:42:41 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011113034241.DPSN13782.mp001.verizon.net@[192.168.129.170]> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I read draft-ietf-mpls-rsvp-lsp-tunnel-09.txt and was wondering how the Hello protocol would be implemented. Specifically, if the ip address of the neighbor node(s) is (are) unknown, how do we get that address to establish the initial Hello "connectivity"? Is this message issued on a well-known broadcast address? thanks in advance... Joe From owner-mpls@UU.NET Tue Nov 13 09:45:41 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27001 for ; Tue, 13 Nov 2001 09:45:41 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQloza06209; Tue, 13 Nov 2001 14:43:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQloza06507 for mpls-outgoing; Tue, 13 Nov 2001 14:42:52 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQloza06499 for ; Tue, 13 Nov 2001 14:42:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQloza07326 for ; Tue, 13 Nov 2001 14:42:12 GMT Received: from mail11.student.main.ntu.edu.sg by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [155.69.5.163]) id QQloza04326 for ; Tue, 13 Nov 2001 14:41:58 GMT Received: from mail01.student.main.ntu.edu.sg ([155.69.5.165]) by mail11.student.main.ntu.edu.sg with Microsoft SMTPSVC(5.0.2195.2966); Tue, 13 Nov 2001 22:23:03 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: how to map the traffic? Date: Tue, 13 Nov 2001 22:23:03 +0800 Message-ID: Thread-Topic: how to map the traffic? Thread-Index: AcFsRuTTpdvqD9gvEdWKKgABAhIqWAAA4pnA From: "#SHEN SHU#" To: "#ZHU YONGQING#" , X-OriginalArrivalTime: 13 Nov 2001 14:23:03.0430 (UTC) FILETIME=[B47B1A60:01C16C4E] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA27001 Zhu YongQing, LSP is not a container, actually there won't be any "mapping into LSP" operation when a incoming native upper protocol packet arrives the ingress LSR. All LSRs along the established LSP should have already known to which LSR to forward a packet with certain label. The label is sure to mean the packet belongs to a certain FEC. The ingress LSR should keep an FEC-to-NHLFE Map (FTN) in order determine which label should be tagged on the packet, then perform NHLFE specified operations on the packet and forward the packet. Please correct if I make any misunderstanding. Best regards, Shu SHEN Research student Network Technology Research Center Nanyang Technological University, Singapore -----Original Message----- From: #ZHU YONGQING# Sent: Tuesday, November 13, 2001 9:15 PM To: mpls@UU.NET Subject: how to map the traffic? hi, I have a question about mapping the traffic. When the traffic flows arrive the ingress LSR of MPLS domain, how are they mapped into pre-estabished LSPs? Is it an issue of traffic engineering? Does it need any algorithm or is there any protocol about it? Thanks a lot! From owner-mpls@UU.NET Tue Nov 13 10:02:04 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28010 for ; Tue, 13 Nov 2001 10:02:04 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlozb29264; Tue, 13 Nov 2001 14:59:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQlozb07840 for mpls-outgoing; Tue, 13 Nov 2001 14:59:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlozb07808 for ; Tue, 13 Nov 2001 14:59:04 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlozb00782 for ; Tue, 13 Nov 2001 14:58:52 GMT Received: from msgbas1.cos.agilent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: msgbas1x.cos.agilent.com [192.25.240.36]) id QQlozb02192 for ; Tue, 13 Nov 2001 14:58:46 GMT Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 59F0416FC for ; Tue, 13 Nov 2001 07:58:51 -0700 (MST) Received: from axcsbh5.cos.agilent.com (axcsbh5.cos.agilent.com [130.29.152.150]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 8CB78394C for ; Tue, 13 Nov 2001 07:54:55 -0700 (MST) Received: from 130.29.152.150 by axcsbh5.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 13 Nov 2001 07:54:27 -0700 Received: by axcsbh5.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 07:53:51 -0700 Message-ID: <0D9185CE635BD511ACA50090277A6FCF01B8E2EB@axcs18.cos.agilent.com> From: "KHARE,MADHUKAR (A-NewEngland,ex1)" To: "'mpls@uu.net'" Subject: Hello Extension - destination IP address Date: Tue, 13 Nov 2001 07:48:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk This is regarding the Hello extension for RSVP. We are unsure what to use for the destination IP address for a Hello Request message. The draft just says "The IP destination address is the IP address of the neighbor node". When the first Hello Req is sent out, we don't know the address of the neighbor node". Are we supposed to use a broadcast IP address first time around? From owner-mpls@UU.NET Tue Nov 13 10:03:58 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28186 for ; Tue, 13 Nov 2001 10:03:58 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlozb28403; Tue, 13 Nov 2001 14:59:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQlozb07794 for mpls-outgoing; Tue, 13 Nov 2001 14:58:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlozb07775 for ; Tue, 13 Nov 2001 14:58:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlozb19163 for ; Tue, 13 Nov 2001 14:58:09 GMT Received: from MAIL13.student.main.ntu.edu.sg by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [155.69.5.164]) id QQlozb29334 for ; Tue, 13 Nov 2001 14:57:56 GMT Received: from mail02.student.main.ntu.edu.sg ([155.69.5.166]) by MAIL13.student.main.ntu.edu.sg with Microsoft SMTPSVC(5.0.2195.2966); Tue, 13 Nov 2001 22:52:05 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16C52.C2D1809D" Subject: RE: how to map the traffic? Date: Tue, 13 Nov 2001 22:52:05 +0800 Message-ID: <0C42D409AF10B1428A0B026FB160A5BE1C1E02@mail02.student.main.ntu.edu.sg> Thread-Topic: how to map the traffic? Thread-Index: AcFsT1nybw2aWR43T2Gf5y/TC3kUpQABArjg From: "#ZHU YONGQING#" To: "Ashwin C. Prabhu" , X-OriginalArrivalTime: 13 Nov 2001 14:52:05.0709 (UTC) FILETIME=[C2F5C7D0:01C16C52] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C16C52.C2D1809D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you! Do you mean the load distribution algorithms also used in ATM and other networks? =20 -----Original Message----- From: Ashwin C. Prabhu [mailto:Ashwinp@in.huawei.com] Sent: Tuesday, November 13, 2001 10:29 PM To: #ZHU YONGQING# Subject: RE: how to map the traffic? Hello=20 =20 It depends on your policy. If you have multiple LSP's then either you can choose=20 one of them or you can choose some algorithm to distribute the traffic on the LSP's. For this matter you can use any load distribution algoritms.=20 =20 Ashwin =20 -----Original Message----- From: #ZHU YONGQING# [mailto:PG01320073@ntu.edu.sg] Sent: Tuesday, November 13, 2001 7:03 PM To: Ashwin C. Prabhu Subject: RE: how to map the traffic? Thanks!=20 Then if there are multiple LSPs between an paticular ingress-egress nodes pair, and the arriving traffic flows are destinated to the egress node, how can they decide which LSP to take? (it's out of the scope of rfc3036) -----Original Message----- From: Ashwin C. Prabhu [mailto:Ashwinp@in.huawei.com] Sent: Tuesday, November 13, 2001 9:48 PM To: #ZHU YONGQING#; mpls@UU.NET Subject: RE: how to map the traffic? Hello=20 You can read the section=20 2.1. FECs of the RFC 3036=20 Regds=20 Ashwin=20 -----Original Message-----=20 From: #ZHU YONGQING# [ mailto:PG01320073@ntu.edu.sg]=20 Sent: Tuesday, November 13, 2001 6:15 PM=20 To: mpls@UU.NET=20 Subject: how to map the traffic?=20 hi,=20 I have a question about mapping the traffic. When the traffic flows=20 arrive the ingress LSR of MPLS domain, how are they mapped into=20 pre-estabished LSPs? Is it an issue of traffic engineering? Does it need any algorithm or is there any protocol about it?=20 Thanks a lot!=20 ------_=_NextPart_001_01C16C52.C2D1809D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: how to map the traffic?
Thank=20 you!
Do=20 you mean the load distribution algorithms also used in ATM and other=20 networks?
 
-----Original Message-----
From: Ashwin C. Prabhu=20 [mailto:Ashwinp@in.huawei.com]
Sent: Tuesday, November 13, = 2001=20 10:29 PM
To: #ZHU YONGQING#
Subject: RE: how to = map the=20 traffic?

Hello
 
  It depends on your policy. If you = have=20 multiple LSP's then either you can choose
  one of them or you can choose some = algorithm=20 to distribute the traffic on the LSP's.
  For this matter you can use any load = distribution algoritms.
 
Ashwin
 
-----Original Message-----
From: #ZHU YONGQING#=20 [mailto:PG01320073@ntu.edu.sg]
Sent: Tuesday, November 13, = 2001=20 7:03 PM
To: Ashwin C. Prabhu
Subject: RE: how to = map the=20 traffic?

Thanks!
Then if there are multiple LSPs = between an=20 paticular ingress-egress nodes pair, and the arriving traffic flows = are=20 destinated to the egress node, how can they decide which LSP to = take? (it's=20 out of the scope of rfc3036)
-----Original Message-----
From: Ashwin C. = Prabhu=20 [mailto:Ashwinp@in.huawei.com]
Sent: Tuesday, November = 13, 2001=20 9:48 PM
To: #ZHU YONGQING#; = mpls@UU.NET
Subject: RE:=20 how to map the traffic?


Hello

 You can read the section

2.1. FECs of the RFC 3036

Regds
Ashwin =

-----Original Message-----
From:=20 #ZHU YONGQING# [mailto:PG01320073@ntu.edu.sg]=20
Sent: Tuesday, November 13, 2001 6:15 PM =
To: mpls@UU.NET
Subject: how to = map the=20 traffic?


hi,
I have a question = about=20 mapping the traffic. When the traffic flows
arrive=20 the ingress LSR of MPLS domain, how are they mapped into =
pre-estabished LSPs? Is it an issue of traffic = engineering? Does it=20 need
any algorithm or is there any = protocol about=20 it?

Thanks a lot!=20

------_=_NextPart_001_01C16C52.C2D1809D-- From owner-mpls@UU.NET Tue Nov 13 10:07:04 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28443 for ; Tue, 13 Nov 2001 10:07:04 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlozc05188; Tue, 13 Nov 2001 15:03:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQlozc18163 for mpls-outgoing; Tue, 13 Nov 2001 15:02:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlozc17366 for ; Tue, 13 Nov 2001 15:02: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 QQlozc27376 for ; Tue, 13 Nov 2001 15:02:32 GMT Received: from tenornetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQlozc06145 for ; Tue, 13 Nov 2001 15:02:20 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fADF2S005258; Tue, 13 Nov 2001 10:02:28 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; TUE, 13 Nov 2001 10:01:40 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id <404WR41V>; Tue, 13 Nov 2001 10:01:40 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E5659A2AD@newman.tenornet.com> From: "Arvind, K" To: "'joe.dumont@verizon.net'" Cc: "'mpls@UU.NET'" Subject: RE: Hello protocol in rsvp-lsp-tunnel-09.txt Date: Tue, 13 Nov 2001 10:01:39 -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 Joe: One approach would be to initiate the Hello protocol as soon as a neighbor's IP address is learned via other means, e.g., from a received RSVP message. Regards, Arvind. > -----Original Message----- > From: Joe Dumont [SMTP:vze2vf6v@verizon.net] > Sent: Monday, November 12, 2001 10:43 PM > To: mpls@UU.NET > Subject: Hello protocol in rsvp-lsp-tunnel-09.txt > > Hi, > > I read draft-ietf-mpls-rsvp-lsp-tunnel-09.txt and > was wondering how the Hello protocol would be implemented. > Specifically, if the ip address of the neighbor node(s) is > (are) unknown, how do we get that address to establish the > initial Hello "connectivity"? Is this message issued on a > well-known broadcast address? > > thanks in advance... > > Joe > > > From owner-mpls@UU.NET Tue Nov 13 10:15:24 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29073 for ; Tue, 13 Nov 2001 10:15:24 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlozc23414; Tue, 13 Nov 2001 15:12:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQlozc28238 for mpls-outgoing; Tue, 13 Nov 2001 15:12:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlozc28218 for ; Tue, 13 Nov 2001 15:12:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlozc21655 for ; Tue, 13 Nov 2001 15:11:47 GMT Received: from msgbas1.cos.agilent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: msgbas1x.cos.agilent.com [192.25.240.36]) id QQlozc19597 for ; Tue, 13 Nov 2001 15:11:50 GMT Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 766272AC9; Tue, 13 Nov 2001 08:11:46 -0700 (MST) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 56F78991; Tue, 13 Nov 2001 08:04:43 -0700 (MST) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 13 Nov 2001 08:04:17 -0700 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 08:03:17 -0700 Message-ID: <0D9185CE635BD511ACA50090277A6FCF01B8E2EC@axcs18.cos.agilent.com> From: "KHARE,MADHUKAR (A-NewEngland,ex1)" To: "'Feng, Mark'" , "'Hong Liao'" , mpls@UU.NET Subject: RE: RSVP questions---two session objects in one rsvp path msg Date: Tue, 13 Nov 2001 08:03:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk There is a case where an implementation could choose to use only the first of the two session objects, and discard the other, specifically when they are duplicates, but that is an implementation specific decision. > -----Original Message----- > From: Feng, Mark [mailto:m_feng@trillium.com] > Sent: Monday, November 12, 2001 7:20 PM > To: 'Hong Liao'; mpls@UU.NET > Subject: RE: RSVP questions---two session objects in one rsvp path msg > > > IMO, this is incorrect. The SESSION object, as the name > implies, is used to > identify the session the Path belongs to. If there are more > than one SESSION > objects, the node cannot identify the session. > > - Mark > > > -----Original Message----- > > From: Hong Liao [mailto:hliao@telcordia.com] > > Sent: Monday, November 12, 2001 3:05 PM > > To: mpls@UU.NET > > Subject: RSVP questions---two session objects in one rsvp path msg > > > > > > Hi, > > > > Is it correct to have two session objects in one Path msg? > > > > I observed that once Ingress sent out the path msg, the > > Intermediate router > > will forward a path msg with two session objects, and one > > session contains > > correct session contents, and other one contains very strange > > info which is > > not info from the configuration. > > > > Has anyone seen this situation before? Is it correct for > > this or not(for > > me, it is not)? > > > > Thanks, > > Julia > > > > > From owner-mpls@UU.NET Tue Nov 13 10:57:27 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01006 for ; Tue, 13 Nov 2001 10:57:26 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlozf29165; Tue, 13 Nov 2001 15:55:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQlozf01493 for mpls-outgoing; Tue, 13 Nov 2001 15:54:47 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlozf01488 for ; Tue, 13 Nov 2001 15:54:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlozf18040 for ; Tue, 13 Nov 2001 15:53:43 GMT Received: from [172.16.1.119] by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mdclient1.opnet.com [12.145.55.10]) id QQlozf22550 for ; Tue, 13 Nov 2001 15:53:31 GMT Received: from wtn10216.opnet.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 13 Nov 2001 10:50:37 -0500 Message-Id: <5.0.0.25.2.20011113103118.03078b10@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 13 Nov 2001 10:51:57 -0500 To: mpls@UU.NET From: Sachin Kalra Subject: Questions about draft-swallow-rsvp-bypass-label-01 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi All: I have some questions about draft-swallow-rsvp-bypass-label-01.txt. Any help is greatly appreciated. The draft states that (Pg 4, Line 11) "...if R4 does not use a global label space then a label must be assigned out of the label space used by R4 on the interface terminating the link from R7. if, however, R4 has a global label space then the label which R2 uses during the backup could be the same label value which is used by R3." For the following topology [R8] \ [R1]---------[R2]----[R3]----[R4]-----------------[R5] \ // \ [R6]===[R7] [R9] My questions are that if R4 does not use global label space (i.e. it has multiple label spaces, specific to particular interfaces) then 1> WHEN should the label be assigned out of label space used by R4 on the interface terminating the link from R7? a> Does it happens at the time when Primary LSP is signaled? If Yes, then how is [R2] informed about this label? b> Or does it happens at time when primary LSP fails and backup takeover? If Yes, then does this means that signaling for Backup LSP takes place? c> How does [R6] and [R7] decide in this case upon their labels to be used and when to swap and when to pop? Please, if possible also send me some pointers to any drafts, RFCs or other readings related to this topic. Thanks, Sachin Kalra From owner-mpls@UU.NET Tue Nov 13 12:32:40 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07015 for ; Tue, 13 Nov 2001 12:32:40 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlozl27017; Tue, 13 Nov 2001 17:29:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQlozl18404 for mpls-outgoing; Tue, 13 Nov 2001 17:29:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlozl18399 for ; Tue, 13 Nov 2001 17:29: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 QQlozl15705 for ; Tue, 13 Nov 2001 17:28:30 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 QQlozl22418 for ; Tue, 13 Nov 2001 17:28:32 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26066 for ; Tue, 13 Nov 2001 12:28:28 -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 MAA02444 for ; Tue, 13 Nov 2001 12:28:28 -0500 (EST) Message-ID: <3BF15875.5A3C1A98@marconi.com> Date: Tue, 13 Nov 2001 12:29:25 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Hello protocol in rsvp-lsp-tunnel-09.txt References: <20011113034241.DPSN13782.mp001.verizon.net@[192.168.129.170]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Joe Dumont wrote: > > I read draft-ietf-mpls-rsvp-lsp-tunnel-09.txt and was wondering how > the Hello protocol would be implemented. Specifically, if the ip > address of the neighbor node(s) is (are) unknown, how do we get > that address to establish the initial Hello "connectivity"? Is > this message issued on a well-known broadcast address? Several possible ways. 1: For a a point-to-point link (like POS or ATM), then the neighbor address might be configured as a part of the link's configuration. 1a: Even for a broadcast interface (like Ethernet), you may have the ability to configure a set of neighbor addresses that you expect to find attached to each interface. 2: It may be possible to get this information from routing protocols. 3: You can discover these addresses based on the addresses of incoming RSVP messages, like Path, Resv and Hello requests from your neighbor. -- David From owner-mpls@UU.NET Tue Nov 13 12:38:23 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07357 for ; Tue, 13 Nov 2001 12:38:23 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlozm08907; Tue, 13 Nov 2001 17:34:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQlozm18881 for mpls-outgoing; Tue, 13 Nov 2001 17:34:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlozm18864 for ; Tue, 13 Nov 2001 17:34:31 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 QQlozm22569 for ; Tue, 13 Nov 2001 17:33:56 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 QQlozm06860 for ; Tue, 13 Nov 2001 17:33: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 MAA26450 for ; Tue, 13 Nov 2001 12:33: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 MAA04265 for ; Tue, 13 Nov 2001 12:33:53 -0500 (EST) Message-ID: <3BF159BB.990CE693@marconi.com> Date: Tue, 13 Nov 2001 12:34:51 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: Hello Extension - destination IP address References: <0D9185CE635BD511ACA50090277A6FCF01B8E2EB@axcs18.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "KHARE,MADHUKAR (A-NewEngland,ex1)" wrote: > > This is regarding the Hello extension for RSVP. We are unsure what > to use for the destination IP address for a Hello Request message. > > The draft just says "The IP destination address is the IP address > of the neighbor node". When the first Hello Req is sent out, we > don't know the address of the neighbor node". > > Are we supposed to use a broadcast IP address first time around? No. Hellos are not sent to broadcast addresses. They are not used for discovering neighbors. If your router doesn't have neighbor addresses configured, then you won't know your neighbor addresses until after you receive other packets from them - like Path and Resv messages. Once you know the address, you can begin sending Hellos. If you do this (discovering neighbors for Hellos by snooping other RSVP packets), then you may want to stop sending Hellos when the all of the neighbor's RSVP state is torn, since you won't be able to tell whether the neighbor went offline, changed address, or simply doesn't have state. -- David From owner-mpls@UU.NET Tue Nov 13 13:01:59 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09068 for ; Tue, 13 Nov 2001 13:01:59 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlozn24224; Tue, 13 Nov 2001 17:59:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQlozn21138 for mpls-outgoing; Tue, 13 Nov 2001 17:59:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlozn21113 for ; Tue, 13 Nov 2001 17:59:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlozn14638 for ; Tue, 13 Nov 2001 17:58:37 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 QQlozn22576 for ; Tue, 13 Nov 2001 17:58:31 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28359; Tue, 13 Nov 2001 12:58:34 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA10726; Tue, 13 Nov 2001 12:58:33 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Nov 2001 12:58:32 -0500 Message-ID: <39469E08BD83D411A3D900204840EC55762E29@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'STONE CHEN'" , mpls@UU.NET Subject: RE: CBR Date: Tue, 13 Nov 2001 12:58:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="gb2312" Sender: owner-mpls@UU.NET Precedence: bulk Chen: There are many algorithms to solve your problem. Look at Table 2 in: http://www.cis.ohio-state.edu/~jain/cis788-99/qos_routing/ or look at for much more information: http://cairo.cs.uiuc.edu/papers/SCthesis.ps --Venkata Naidu -> Hi, -> -> Maybe someone can help me. -> I am looking for some documents about the algorithm of -> Constrainte-based Routing (CBR). -> especially about the delay constraint and the delay model of -> the router. -> Thanks in advance. -> stone -> From owner-mpls@UU.NET Tue Nov 13 13:31:37 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10874 for ; Tue, 13 Nov 2001 13:31:37 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlozp20740; Tue, 13 Nov 2001 18:28:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQlozp13793 for mpls-outgoing; Tue, 13 Nov 2001 18:28:40 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlozp13778 for ; Tue, 13 Nov 2001 18:28:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlozp27986 for ; Tue, 13 Nov 2001 18:28:22 GMT Received: from zrc2s03g.us.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) id QQlozp09494 for ; Tue, 13 Nov 2001 18:28:09 GMT Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA17046 for ; Tue, 13 Nov 2001 12:28:20 -0600 (CST) Received: from zsc4c000.us.nortel.com by smtprch2.nortel.com; Tue, 13 Nov 2001 12:21:25 -0600 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 10:27:16 -0800 Message-ID: <4F973E944951D311B6660008C7917CF0074EA25A@zsc4c008.us.nortel.com> From: "Manoj Kulkarni" To: "'raszuk@cisco.com'" , adithya@sasken.com Cc: ppvpn@zephion.net, MPLS-UUNET Subject: RE: ppvpn Re: BGP/MPLS VPNs : On an Egress PE, on which table is the label look up done ? Date: Tue, 13 Nov 2001 10:27:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16C70.D2053C60" 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_01C16C70.D2053C60 Content-Type: text/plain; charset="iso-8859-1" This will be specific to implementation. In the simplest case one can decode a VRF and a pointer to the sub-interface (towards CE) from the inner label. There will be some data path module that would maintain this and BGP may not maintain a separate LIB. --Manoj -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com] Sent: Tuesday, November 13, 2001 5:04 AM To: adithya@sasken.com Cc: ppvpn@zephion.net; MPLS-UUNET Subject: ppvpn Re: BGP/MPLS VPNs : On an Egress PE, on which table is the label look up done ? The most likely you will have a LFIB for such a lookup. That is the table which is build from all label sources (LIB, BGP transported labels ... etc..). R. > Adithya S Bhat wrote: > > Hi all, > > WRT rfc2547bis, Section 5, Forwarding across the backbone: > "MPLS will then carry the packet across the backbone. The egress PE > router's treatment of the packet will depend on the Label that was first > pushed on by the ingress PE. In many cases, the PE will be able to > determine, from this label, the sub-interface over which the packet > should be transmitted (to a CE device), as well as the proper data link > layer header for that interface. " > > To determine the sub-interface over which the packet is transmitted ( to > a CE ), the PE , I assume, will have to do a label look up in some > table. I am not abel to understand, what table will this be ? ( as per > my understanding ) I am sure that this not the VRF. Juniper white paper > on rfc2547bis ( Example #1) talks of a "MPLS forwarding table", on which > the the label look up is done. Is this table similar to LIB in LDP ??, > if yes, can I assume that BGP will maintain a seperate LIB. > > Am i missing something here ? > > Regard > -- > Adithya ------_=_NextPart_001_01C16C70.D2053C60 Content-Type: text/html; charset="iso-8859-1" RE: ppvpn Re: BGP/MPLS VPNs : On an Egress PE, on which table is the label look up done ?

This will be specific to implementation. In the simplest case
one can decode a VRF and a pointer to the sub-interface
(towards CE) from the inner label. There will be some data
path module that would maintain this and BGP may not maintain
a separate LIB.

--Manoj

-----Original Message-----
From: Robert Raszuk [mailto:raszuk@cisco.com]
Sent: Tuesday, November 13, 2001 5:04 AM
To: adithya@sasken.com
Cc: ppvpn@zephion.net; MPLS-UUNET
Subject: ppvpn Re: BGP/MPLS VPNs : On an Egress PE, on which table is
the label look up done ?



The most likely you will have a LFIB for such a lookup. That is the
table which is build from all label sources (LIB, BGP transported labels
... etc..).

R.

> Adithya S Bhat wrote:
>
> Hi all,
>
> WRT rfc2547bis, Section 5, Forwarding across the backbone:
> "MPLS will then carry the packet across the backbone.  The egress PE
> router's treatment of the packet will depend on the Label that was first
> pushed on by the ingress PE.  In many cases, the PE will be  able to
> determine, from this label, the sub-interface over which the packet
> should be transmitted (to a CE device), as well as the proper data link
> layer header for that interface. "
>
> To determine the sub-interface over which the packet is transmitted ( to
> a CE ), the PE , I assume, will have to do a label look up in some
> table. I am not abel to understand, what table will this be ? ( as per
> my understanding ) I am sure that this not the VRF. Juniper white paper
> on rfc2547bis ( Example #1) talks of a "MPLS forwarding table", on which
> the the label look up is done. Is this table similar to LIB in LDP ??,
> if yes, can I assume that BGP will maintain a seperate LIB.
>
> Am i missing something here ?
>
> Regard
> --
> Adithya

------_=_NextPart_001_01C16C70.D2053C60-- From owner-mpls@UU.NET Tue Nov 13 14:41:07 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14358 for ; Tue, 13 Nov 2001 14:41:07 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlozu15220; Tue, 13 Nov 2001 19:38:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQlozu08544 for mpls-outgoing; Tue, 13 Nov 2001 19:38:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlozu08539 for ; Tue, 13 Nov 2001 19:38:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlozu11229 for ; Tue, 13 Nov 2001 19:38:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlozu24415 for ; Tue, 13 Nov 2001 19:37:58 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA24496 for ; Tue, 13 Nov 2001 14:38:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA09037 for mpls@uu.net; Tue, 13 Nov 2001 14:38:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlozu08507 for ; Tue, 13 Nov 2001 19:37:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlozu07108 for ; Tue, 13 Nov 2001 19:37:09 GMT Received: from netmail2.alcatel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail2.alcatel.com [128.251.168.51]) id QQlozu13263 for ; Tue, 13 Nov 2001 19:36:56 GMT Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged)) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA28769 for ; Tue, 13 Nov 2001 13:37:08 -0600 (CST) Received: from alcatel.com ([198.205.41.158]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA56A6; Tue, 13 Nov 2001 14:54:23 -0500 Message-ID: <3BF181BD.EF4C00D6@alcatel.com> Date: Tue, 13 Nov 2001 15:25:33 -0500 From: Senthil Venkatachalam Organization: Alcatel X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: swallow@cisco.com, vijay@cosinecom.com CC: Sudheer Dharanikota , Papadimitriou Dimitri , mpls@UU.NET Subject: Slot for draft-venkatachalam-interarea-mpls-te-02.txt Content-Type: multipart/alternative; boundary="------------93B5682A67ECB4A224EC79B9" Sender: owner-mpls@UU.NET Precedence: bulk --------------93B5682A67ECB4A224EC79B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi George, We would like to request a slot to present our draft: draft-venkatachalam-interarea-mpls-te-02.txt at the Salt Lake City IETF. Best Regards, Senthil. -- Senthil K. Venkatachalam senthil.venkatachalam@adn.alcatel.com Off#:, MBox: (703) 679-6435 [Off] Alcatel USA (703) 679-6450 [Fax] __________________________________________________________________ --------------93B5682A67ECB4A224EC79B9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi George,

We would like to request a slot to present our draft:
draft-venkatachalam-interarea-mpls-te-02.txt

at the Salt Lake City IETF.

Best Regards,
Senthil.
 
  

-- 
Senthil K. Venkatachalam     senthil.venkatachalam@adn.alcatel.com
Off#:, MBox:                 (703) 679-6435 [Off]
Alcatel USA                  (703) 679-6450 [Fax]
__________________________________________________________________
  --------------93B5682A67ECB4A224EC79B9-- From owner-mpls@UU.NET Tue Nov 13 15:10:28 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15083 for ; Tue, 13 Nov 2001 15:10:28 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlozw05564; Tue, 13 Nov 2001 20:07:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQlozw29612 for mpls-outgoing; Tue, 13 Nov 2001 20:07:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlozw29605 for ; Tue, 13 Nov 2001 20:07:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlozw24878 for ; Tue, 13 Nov 2001 20:07:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlozw14752 for ; Tue, 13 Nov 2001 20:06:57 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA28664 for ; Tue, 13 Nov 2001 15:07:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA10570 for mpls@uu.net; Tue, 13 Nov 2001 15:07:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlozw28800 for ; Tue, 13 Nov 2001 20:06:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlozw20455 for ; Tue, 13 Nov 2001 20:05:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlozw10595 for ; Tue, 13 Nov 2001 20:05:01 GMT Received: from telescope.cisco.com (telescope.cisco.com [161.44.166.204]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA28417; Tue, 13 Nov 2001 15:05:05 -0500 (EST) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA28945; Tue, 13 Nov 2001 15:05:05 -0500 (EST) Message-Id: <200111132005.PAA28945@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: Senthil Venkatachalam cc: swallow@cisco.com, vijay@cosinecom.com, Sudheer Dharanikota , Papadimitriou Dimitri , mpls@UU.NET, swallow@cisco.com Subject: Re: Slot for draft-venkatachalam-interarea-mpls-te-02.txt In-reply-to: Your message of "Tue, 13 Nov 2001 15:25:33 EST." <3BF181BD.EF4C00D6@alcatel.com> Date: Tue, 13 Nov 2001 15:05:05 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk The SubIP Area Directorate ruled that this topic belongs in CCAMP. I and Kireeti both wanted it in MPLS, but we lost. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Tue Nov 13 16:29:38 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17627 for ; Tue, 13 Nov 2001 16:29:38 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpab03095; Tue, 13 Nov 2001 21:27:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpab26659 for mpls-outgoing; Tue, 13 Nov 2001 21:27:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpab26652 for ; Tue, 13 Nov 2001 21:27:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpab18544 for ; Tue, 13 Nov 2001 21:26:40 GMT Received: from calliope1.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns01.fm.intel.com [132.233.247.10]) id QQlpab05730 for ; Tue, 13 Nov 2001 21:26:34 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id VAA16480 for ; Tue, 13 Nov 2001 21:26:39 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001111313255220381 ; Tue, 13 Nov 2001 13:25:52 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 13:26:47 -0800 Message-ID: From: "Feng, Mark" To: "'David Charlap'" , "'mpls@uu.net'" Subject: RE: Hello Extension - destination IP address Date: Tue, 13 Nov 2001 13:26:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I agree with most of the comments; but I have one doubt. Please see comments below. - Mark > -----Original Message----- > From: David Charlap [mailto:David.Charlap@marconi.com] > Sent: Tuesday, November 13, 2001 9:35 AM > To: 'mpls@uu.net' > Subject: Re: Hello Extension - destination IP address > > > "KHARE,MADHUKAR (A-NewEngland,ex1)" wrote: > > > > This is regarding the Hello extension for RSVP. We are unsure what > > to use for the destination IP address for a Hello Request message. > > > > The draft just says "The IP destination address is the IP address > > of the neighbor node". When the first Hello Req is sent out, we > > don't know the address of the neighbor node". > > > > Are we supposed to use a broadcast IP address first time around? > > No. Hellos are not sent to broadcast addresses. They are > not used for > discovering neighbors. > > If your router doesn't have neighbor addresses configured, then you > won't know your neighbor addresses until after you receive > other packets > from them - like Path and Resv messages. Once you know the > address, you > can begin sending Hellos. > > If you do this (discovering neighbors for Hellos by snooping > other RSVP > packets), then you may want to stop sending Hellos when the all of the > neighbor's RSVP state is torn, since you won't be able to tell whether > the neighbor went offline, changed address, or simply doesn't have > state. > Why is it necessary to stop sending the Hello in this case? IMO, the way the Hello state machine works is independant of the means to discover the neighbour. Even if the neighbour's RSVP states are gone, the neighbour should still respond to the Hello messages. This should be applicable in the case when the neighbour is configured. By stopping the Hello exchange, the neighbour might incorrectly think that there is a problem communicating with the current node. > -- David > From owner-mpls@UU.NET Tue Nov 13 17:25:44 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19421 for ; Tue, 13 Nov 2001 17:25:43 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpaf12864; Tue, 13 Nov 2001 22:24:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpaf21440 for mpls-outgoing; Tue, 13 Nov 2001 22:24:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpaf21435 for ; Tue, 13 Nov 2001 22:24:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpaf16161 for ; Tue, 13 Nov 2001 22:22:42 GMT Received: from dnsmx1pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQlpaf19263 for ; Tue, 13 Nov 2001 22:22:35 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA19707 for ; Tue, 13 Nov 2001 17:15:09 -0500 (EST) Subject: Re: resvtear msg To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Tue, 13 Nov 2001 17:14:58 -0500 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 11/13/2001 05:15:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Sorry to bring this topic again. I would like to make a conclusion, if I am wrong, please point me out. [My question] For example, the ingress sent out the path msg to egress, the egress should not send out the resvtear msg, since pathrear will delete all the path and resv state block. But it is possible that egress send out the path msg before the the ingress sent out the pathtear msg. or it is also fine for the egress sent out the resvtear msg even the ingress send out the pathtear msg already. [answer] It should not have resvtear msg sent back if the pathtear msg has been sent out to delete all the path, resv state block. For my understanding, no resvtear msg should be sent out for the response for the pathtear msg. I observed that there is one vendor which implements this way---egress sent out the resvtear to response the pathtear msg. Can anyone confirm this one for me? Julia David Charlap cc: (bcc: Hong Liao/Telcordia) Subject: Re: resvtear msg 10/11/01 05:24 PM Hariom P wrote: > > Why can't every hop that processes resvtear do the following, > 1. Del matching reserv state and forward resvtear if required to the > prevhop It should always send a ResvTear after deleting the corresponding state. If the state is not present on the previous-hop router, then that router will ignore the message. It is unreasonable to expect a router to know with certainty what the adjacent routers' states are. If you send a ResvTear when the neighbor has no state, it's not a big deal - the message will just be ignored. If, however, you do not send a ResvTear when you should have, the neighbor's Resv state will not go away until it times out. Depending on how the routers are configured, this could be quite a long time. > 2. And send a pathtear to the nexthop This is wrong. Path state should not be deleted when Resv state is deleted. It must remain established, and the node must continue refreshing it. It is perfectly legal (and not unusual in classical RSVP) for an egress node to delete a reservation and later re-establish it with different parameters. Don't think of RSVP as a variation on LDP. It is not. A Path message is not just a request for a label. It establishes state in and of itself. It is not something that can be causally discarded simply because some corresponding Resv state has been destroyed. -- David From owner-mpls@UU.NET Tue Nov 13 17:33:09 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19726 for ; Tue, 13 Nov 2001 17:33:09 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpaf02279; Tue, 13 Nov 2001 22:29:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpaf22126 for mpls-outgoing; Tue, 13 Nov 2001 22:29:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpaf22113 for ; Tue, 13 Nov 2001 22:29:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpaf02714 for ; Tue, 13 Nov 2001 22:28:36 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f108.law12.hotmail.com [64.4.19.108]) id QQlpaf00017 for ; Tue, 13 Nov 2001 22:28:30 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 13 Nov 2001 14:28:04 -0800 Received: from 206.54.51.125 by lw12fd.law12.hotmail.msn.com with HTTP; Tue, 13 Nov 2001 22:28:04 GMT X-Originating-IP: [206.54.51.125] From: "Hariom P" To: m_feng@trillium.com, David.Charlap@marconi.com, mpls@UU.NET Subject: RE: Hello Extension - destination IP address Date: Tue, 13 Nov 2001 14:28:04 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Nov 2001 22:28:04.0586 (UTC) FILETIME=[761F1CA0:01C16C92] Sender: owner-mpls@UU.NET Precedence: bulk I totally agree with David. RSVP hellos are designed for "faster node failure detection" and there is no point in doing this detection when no RSVP sessions are active between two peers.. with regards, hmp >From: "Feng, Mark" >To: "'David Charlap'" , "'mpls@uu.net'" > >Subject: RE: Hello Extension - destination IP address >Date: Tue, 13 Nov 2001 13:26:32 -0800 > >I agree with most of the comments; but I have one doubt. Please see >comments >below. > >- Mark > > > -----Original Message----- > > From: David Charlap [mailto:David.Charlap@marconi.com] > > Sent: Tuesday, November 13, 2001 9:35 AM > > To: 'mpls@uu.net' > > Subject: Re: Hello Extension - destination IP address > > > > > > "KHARE,MADHUKAR (A-NewEngland,ex1)" wrote: > > > > > > This is regarding the Hello extension for RSVP. We are unsure what > > > to use for the destination IP address for a Hello Request message. > > > > > > The draft just says "The IP destination address is the IP address > > > of the neighbor node". When the first Hello Req is sent out, we > > > don't know the address of the neighbor node". > > > > > > Are we supposed to use a broadcast IP address first time around? > > > > No. Hellos are not sent to broadcast addresses. They are > > not used for > > discovering neighbors. > > > > If your router doesn't have neighbor addresses configured, then you > > won't know your neighbor addresses until after you receive > > other packets > > from them - like Path and Resv messages. Once you know the > > address, you > > can begin sending Hellos. > > > > If you do this (discovering neighbors for Hellos by snooping > > other RSVP > > packets), then you may want to stop sending Hellos when the all of the > > neighbor's RSVP state is torn, since you won't be able to tell whether > > the neighbor went offline, changed address, or simply doesn't have > > state. > > > >Why is it necessary to stop sending the Hello in this case? IMO, the way >the >Hello state machine works is independant of the means to discover the >neighbour. Even if the neighbour's RSVP states are gone, the neighbour >should still respond to the Hello messages. This should be applicable in >the >case when the neighbour is configured. > >By stopping the Hello exchange, the neighbour might incorrectly think that >there is a problem communicating with the current node. > > > -- David > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mpls@UU.NET Tue Nov 13 17:43:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20033 for ; Tue, 13 Nov 2001 17:43:50 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpag01587; Tue, 13 Nov 2001 22:40:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpag24279 for mpls-outgoing; Tue, 13 Nov 2001 22:40:01 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpag24247 for ; Tue, 13 Nov 2001 22:39:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpag08537 for ; Tue, 13 Nov 2001 22:39:40 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 QQlpag00291 for ; Tue, 13 Nov 2001 22:39:42 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19159 for ; Tue, 13 Nov 2001 17:39:37 -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 RAA02979 for ; Tue, 13 Nov 2001 17:39:38 -0500 (EST) Message-ID: <3BF1A164.4858AF20@marconi.com> Date: Tue, 13 Nov 2001 17:40:36 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: Hello Extension - destination IP address References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Feng, Mark" wrote: > David Charlap wrote: >> >> If you do this (discovering neighbors for Hellos by snooping other >> RSVP packets), then you may want to stop sending Hellos when the >> all of the neighbor's RSVP state is torn, since you won't be able >> to tell whether the neighbor went offline, changed address, or >> simply doesn't have state. > > Why is it necessary to stop sending the Hello in this case? It's not necessary. But you don't want to waste CPU time and bandwidth sending Hellos to a non-existant peer. If you discover a peer by snooping RSVP setup messages, then it makes sense to "un-discover" it by snooping RSVP tear messages. > IMO, the way the Hello state machine works is independant of the > means to discover the neighbour. Even if the neighbour's RSVP > states are gone, the neighbour should still respond to the Hello > messages. If all the state is gone, how can you be sure the switch's is still running? Suppose the state goes away due to a link failure (lost carrier on the fiber). When the link comes back up, there may be a different switch at the other end of the fiber. If so, that switch may not be running RSVP, or it may not support Hello, or it may simply have a different IP address. > This should be applicable in the case when the neighbour is > configured. When you explicitly configure a neighbor's address, then it makes sense to assume that the configuration is correct. > By stopping the Hello exchange, the neighbour might incorrectly > think that there is a problem communicating with the current node. So what? If all state is gone, then what is the neighbor going to do? There's nothing left to tear down or signal an error for anyway. -- David From owner-mpls@UU.NET Tue Nov 13 17:45:11 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20108 for ; Tue, 13 Nov 2001 17:45:11 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpag28295; Tue, 13 Nov 2001 22:42:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpag24956 for mpls-outgoing; Tue, 13 Nov 2001 22:42:16 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpag24911 for ; Tue, 13 Nov 2001 22:42:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpag11767 for ; Tue, 13 Nov 2001 22:41:04 GMT Received: from thalia.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11]) id QQlpag06986 for ; Tue, 13 Nov 2001 22:40:52 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id WAA11384 for ; Tue, 13 Nov 2001 22:41:03 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001111314414226548 ; Tue, 13 Nov 2001 14:41:42 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 14:41:03 -0800 Message-ID: From: "Feng, Mark" To: "'Hariom P'" , "Feng, Mark" , David.Charlap@marconi.com, mpls@UU.NET Subject: RE: Hello Extension - destination IP address Date: Tue, 13 Nov 2001 14:40:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk That's not the point I am trying to make. If it is so desired that, when there is no active sessions, the Hello exchange is stopped, this should be done even when the neighbours are configured, instead of discovered. As to whether to maintain the Hello exchange when there is no active sessions, my only concern is that, by stopping the exchange, the RSVP neighbour might think that the communication has been lost. Whether this is OK as to the original intent of the RFC, I am not sure. - Mark > -----Original Message----- > From: Hariom P [mailto:hmp123@hotmail.com] > Sent: Tuesday, November 13, 2001 2:28 PM > To: m_feng@trillium.com; David.Charlap@marconi.com; mpls@UU.NET > Subject: RE: Hello Extension - destination IP address > > > I totally agree with David. RSVP hellos are designed for "faster node > failure detection" and there is no point in doing this > detection when no > RSVP sessions are active between two peers.. > > > with regards, > hmp > > > >From: "Feng, Mark" > >To: "'David Charlap'" , > "'mpls@uu.net'" > > > >Subject: RE: Hello Extension - destination IP address > >Date: Tue, 13 Nov 2001 13:26:32 -0800 > > > >I agree with most of the comments; but I have one doubt. Please see > >comments > >below. > > > >- Mark > > > > > -----Original Message----- > > > From: David Charlap [mailto:David.Charlap@marconi.com] > > > Sent: Tuesday, November 13, 2001 9:35 AM > > > To: 'mpls@uu.net' > > > Subject: Re: Hello Extension - destination IP address > > > > > > > > > "KHARE,MADHUKAR (A-NewEngland,ex1)" wrote: > > > > > > > > This is regarding the Hello extension for RSVP. We are > unsure what > > > > to use for the destination IP address for a Hello > Request message. > > > > > > > > The draft just says "The IP destination address is the > IP address > > > > of the neighbor node". When the first Hello Req is sent out, we > > > > don't know the address of the neighbor node". > > > > > > > > Are we supposed to use a broadcast IP address first time around? > > > > > > No. Hellos are not sent to broadcast addresses. They are > > > not used for > > > discovering neighbors. > > > > > > If your router doesn't have neighbor addresses > configured, then you > > > won't know your neighbor addresses until after you receive > > > other packets > > > from them - like Path and Resv messages. Once you know the > > > address, you > > > can begin sending Hellos. > > > > > > If you do this (discovering neighbors for Hellos by snooping > > > other RSVP > > > packets), then you may want to stop sending Hellos when > the all of the > > > neighbor's RSVP state is torn, since you won't be able to > tell whether > > > the neighbor went offline, changed address, or simply doesn't have > > > state. > > > > > > >Why is it necessary to stop sending the Hello in this case? > IMO, the way > >the > >Hello state machine works is independant of the means to discover the > >neighbour. Even if the neighbour's RSVP states are gone, the > neighbour > >should still respond to the Hello messages. This should be > applicable in > >the > >case when the neighbour is configured. > > > >By stopping the Hello exchange, the neighbour might > incorrectly think that > >there is a problem communicating with the current node. > > > > > -- David > > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > From owner-mpls@UU.NET Tue Nov 13 17:50:40 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20309 for ; Tue, 13 Nov 2001 17:50:39 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpah16777; Tue, 13 Nov 2001 22:47:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpah26002 for mpls-outgoing; Tue, 13 Nov 2001 22:47:07 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpah25937 for ; Tue, 13 Nov 2001 22:46:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpah22887 for ; Tue, 13 Nov 2001 22:45:54 GMT Received: from hermes.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [192.55.52.18]) id QQlpah13690 for ; Tue, 13 Nov 2001 22:45:41 GMT Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.20 2001/11/09 23:25:44 root Exp $) with ESMTP id fADMkM323009 for ; Tue, 13 Nov 2001 22:46:22 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.11 2001/11/09 23:28:01 root Exp $) with SMTP id fADMkMj28918 for ; Tue, 13 Nov 2001 22:46:22 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001111314452700533 ; Tue, 13 Nov 2001 14:45:27 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 14:45:52 -0800 Message-ID: From: "Feng, Mark" To: "'Hong Liao'" , mpls@UU.NET Subject: RE: resvtear msg Date: Tue, 13 Nov 2001 14:45:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Rtear shouldn't be sent as response to a Ptear. It will most likely be dropped by the neighbour since the state would've be removed by the Ptear. - Mark > -----Original Message----- > From: Hong Liao [mailto:hliao@telcordia.com] > Sent: Tuesday, November 13, 2001 2:15 PM > To: mpls@UU.NET > Subject: Re: resvtear msg > > > > Hi, > > Sorry to bring this topic again. > > I would like to make a conclusion, if I am wrong, please point me out. > > [My question] > For example, the ingress sent out the path msg to egress, the > egress should > not send out the resvtear msg, since pathrear will delete all > the path and > resv state block. But it is possible that egress send out > the path msg > before the the ingress sent out the pathtear msg. > > or it is also fine for the egress sent out the resvtear msg even the > ingress send out the pathtear msg already. > > [answer] > > It should not have resvtear msg sent back if the pathtear > msg has been > sent out to delete all the path, resv state block. > > For my understanding, no resvtear msg should be sent out for > the response > for the pathtear msg. > > I observed that there is one vendor which implements this > way---egress sent > out the resvtear to response the pathtear msg. > > Can anyone confirm this one for me? > > Julia > > > > > > > David Charlap > > mpls@UU.NET > rconi.com> cc: (bcc: > Hong Liao/Telcordia) > Subject: Re: > resvtear msg > 10/11/01 05:24 PM > > > > > > > > > > > Hariom P wrote: > > > > Why can't every hop that processes resvtear do the following, > > 1. Del matching reserv state and forward resvtear if required to the > > prevhop > > It should always send a ResvTear after deleting the corresponding > state. If the state is not present on the previous-hop router, then > that router will ignore the message. It is unreasonable to expect a > router to know with certainty what the adjacent routers' states are. > > If you send a ResvTear when the neighbor has no state, it's not a big > deal - the message will just be ignored. If, however, you do > not send a > ResvTear when you should have, the neighbor's Resv state will not go > away until it times out. Depending on how the routers are configured, > this could be quite a long time. > > > 2. And send a pathtear to the nexthop > > This is wrong. Path state should not be deleted when Resv state is > deleted. It must remain established, and the node must continue > refreshing it. > > It is perfectly legal (and not unusual in classical RSVP) for > an egress > node to delete a reservation and later re-establish it with different > parameters. > > Don't think of RSVP as a variation on LDP. It is not. A Path message > is not just a request for a label. It establishes state in and of > itself. It is not something that can be causally discarded simply > because some corresponding Resv state has been destroyed. > > -- David > > > From owner-mpls@UU.NET Tue Nov 13 18:01:23 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20560 for ; Tue, 13 Nov 2001 18:01:23 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpah29835; Tue, 13 Nov 2001 22:58:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpah27223 for mpls-outgoing; Tue, 13 Nov 2001 22:57:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpah27218 for ; Tue, 13 Nov 2001 22:57: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 QQlpah26240 for ; Tue, 13 Nov 2001 22:57:03 GMT Received: from hermes.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [192.55.52.18]) id QQlpah27347 for ; Tue, 13 Nov 2001 22:56:57 GMT Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.20 2001/11/09 23:25:44 root Exp $) with ESMTP id fADMvV327821 for ; Tue, 13 Nov 2001 22:57:31 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.11 2001/11/09 23:28:01 root Exp $) with SMTP id fADMvUj04219 for ; Tue, 13 Nov 2001 22:57:30 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001111314563500146 ; Tue, 13 Nov 2001 14:56:35 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 14:57:00 -0800 Message-ID: From: "Feng, Mark" To: "'David Charlap'" , "'mpls@uu.net'" Subject: RE: Hello Extension - destination IP address Date: Tue, 13 Nov 2001 14:56:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: David Charlap [mailto:David.Charlap@marconi.com] > Sent: Tuesday, November 13, 2001 2:41 PM > To: 'mpls@uu.net' > Subject: Re: Hello Extension - destination IP address > > > "Feng, Mark" wrote: > > David Charlap wrote: > >> > >> If you do this (discovering neighbors for Hellos by snooping other > >> RSVP packets), then you may want to stop sending Hellos when the > >> all of the neighbor's RSVP state is torn, since you won't be able > >> to tell whether the neighbor went offline, changed address, or > >> simply doesn't have state. > > > > Why is it necessary to stop sending the Hello in this case? > > It's not necessary. But you don't want to waste CPU time and > bandwidth > sending Hellos to a non-existant peer. > > If you discover a peer by snooping RSVP setup messages, then it makes > sense to "un-discover" it by snooping RSVP tear messages. > > > IMO, the way the Hello state machine works is independant of the > > means to discover the neighbour. Even if the neighbour's RSVP > > states are gone, the neighbour should still respond to the Hello > > messages. > > If all the state is gone, how can you be sure the switch's is still > running? > > Suppose the state goes away due to a link failure (lost carrier on the > fiber). When the link comes back up, there may be a > different switch at > the other end of the fiber. If so, that switch may not be > running RSVP, > or it may not support Hello, or it may simply have a different IP > address. > Wouldn't the Hello exchange timed out before the normal cleanup timer expiry? In either case, wouldn't the Hello state machine itself eventually settle to the correct state in the above cases? But I agree that it is more efficient to stop the Hello exchange. Thanks for the clarification. - Mark > > This should be applicable in the case when the neighbour is > > configured. > > When you explicitly configure a neighbor's address, then it > makes sense > to assume that the configuration is correct. > > > By stopping the Hello exchange, the neighbour might incorrectly > > think that there is a problem communicating with the current node. > > So what? If all state is gone, then what is the neighbor > going to do? > There's nothing left to tear down or signal an error for anyway. > > -- David > From owner-mpls@UU.NET Tue Nov 13 18:06:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20701 for ; Tue, 13 Nov 2001 18:06:30 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpai08412; Tue, 13 Nov 2001 23:04:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpai08132 for mpls-outgoing; Tue, 13 Nov 2001 23:04:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpai08125 for ; Tue, 13 Nov 2001 23:04:23 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpai04727 for ; Tue, 13 Nov 2001 23:03:30 GMT Received: from [172.16.1.119] by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mdclient1.opnet.com [12.145.55.10]) id QQlpai10072 for ; Tue, 13 Nov 2001 23:03:24 GMT Received: from wtn10216.opnet.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 13 Nov 2001 18:00:23 -0500 Message-Id: <5.0.0.25.2.20011113175048.00aaa070@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 13 Nov 2001 18:02:31 -0500 To: mpls@UU.NET From: Sachin Kalra Subject: RSVP-TE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Dear All: I have some questions about RSVP-TE Backup LSPs (Bypass tunnels). Any help is greatly appreciated. Please let me know if the draft (draft-swallow-rsvp-bypass-label-01) is too old to discuss in the list. (So that I just don't keep waiting for the mails :-) ) The draft draft-swallow-rsvp-bypass-label-01.txt states that (Pg 4, Line 11) "...if R4 does not use a global label space then a label must be assigned out of the label space used by R4 on the interface terminating the link from R7. if, however, R4 has a global label space then the label which R2 uses during the backup could be the same label value which is used by R3." For the following topology [R8] \ [R1]---------[R2]----[R3]----[R4]-----------------[R5] \\ // \ [R6]===[R7] [R9] My questions are that if R4 does not use global label space (i.e. it has multiple label spaces, specific to particular interfaces) then 1> WHEN should the label be assigned out of label space used by R4 on the interface terminating the link from R7? a> Does it happens at the time when Primary LSP is signaled? If Yes, then how is [R2] informed about this label? b> Or does it happens at time when primary LSP fails and backup takeover? If Yes, then does this means that signaling for Backup LSP takes place? c> How does [R6] and [R7] decide in this case upon their labels to be used and when to swap and when to pop? Or in other words how is the Bypass Tunnel established? Is it statically configured? Please, give some pointers to other readings related to this topic. Thanks, Sachin Kalra From owner-mpls@UU.NET Tue Nov 13 18:09:40 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20786 for ; Tue, 13 Nov 2001 18:09:40 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpai15740; Tue, 13 Nov 2001 23:08:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpai17095 for mpls-outgoing; Tue, 13 Nov 2001 23:08:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpai17081 for ; Tue, 13 Nov 2001 23:08:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpai08615 for ; Tue, 13 Nov 2001 23:05:44 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 QQlpai20521 for ; Tue, 13 Nov 2001 23:05:31 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA20635 for ; Tue, 13 Nov 2001 18:05:41 -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 SAA08390 for ; Tue, 13 Nov 2001 18:05:42 -0500 (EST) Message-ID: <3BF1A781.28081FF5@marconi.com> Date: Tue, 13 Nov 2001 18:06:41 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: Hello Extension - destination IP address References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Feng, Mark" wrote: >> >> Suppose the state goes away due to a link failure (lost carrier on >> the fiber). When the link comes back up, there may be a different >> switch at the other end of the fiber. If so, that switch may not >> be running RSVP, or it may not support Hello, or it may simply >> have a different IP address. > > Wouldn't the Hello exchange timed out before the normal cleanup > timer expiry? Probably. But if carrier is lost on the fiber, that will likely be detected in hardware before the Hello times out. > In either case, wouldn't the Hello state machine itself eventually > settle to the correct state in the above cases? Yes, it will successfully tear everything. But do you want to restart Hellos immediately or wait for new Path state? IMO, if a neighbor address is configured, it makes sense to restart Hellos immediately after tearing down local state, so you can know when the neighbor comes back up (when you start getting Hello Acks back). But it would be foolish to do this if you're auto-discovering your neighbor, because that neighbor might have disappeared from the network altogether. -- David From owner-mpls@UU.NET Tue Nov 13 18:13:42 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20939 for ; Tue, 13 Nov 2001 18:13:42 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpai19317; Tue, 13 Nov 2001 23:09:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpai17135 for mpls-outgoing; Tue, 13 Nov 2001 23:09:18 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpai17117 for ; Tue, 13 Nov 2001 23:09:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpai29487 for ; Tue, 13 Nov 2001 23:08:53 GMT Received: from dnsmx1pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQlpai18045 for ; Tue, 13 Nov 2001 23:08:47 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA28131; Tue, 13 Nov 2001 18:04:01 -0500 (EST) Subject: RE: resvtear msg To: "Feng, Mark" Cc: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Tue, 13 Nov 2001 18:03:50 -0500 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 11/13/2001 06:04:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk >>It will most likely be dropped by the neighbour since the state would've be removed by the Ptear. If it is considered wrong if the ResvTear msg sent out after the Pathtear msg, or it is fine, neighbour just ingore it. Thanks, Julia "Feng, Mark" , mpls@UU.NET ium.com> cc: (bcc: Hong Liao/Telcordia) Subject: RE: resvtear msg 11/13/01 05:45 PM Rtear shouldn't be sent as response to a Ptear. It will most likely be dropped by the neighbour since the state would've be removed by the Ptear. - Mark > -----Original Message----- > From: Hong Liao [mailto:hliao@telcordia.com] > Sent: Tuesday, November 13, 2001 2:15 PM > To: mpls@UU.NET > Subject: Re: resvtear msg > > > > Hi, > > Sorry to bring this topic again. > > I would like to make a conclusion, if I am wrong, please point me out. > > [My question] > For example, the ingress sent out the path msg to egress, the > egress should > not send out the resvtear msg, since pathrear will delete all > the path and > resv state block. But it is possible that egress send out > the path msg > before the the ingress sent out the pathtear msg. > > or it is also fine for the egress sent out the resvtear msg even the > ingress send out the pathtear msg already. > > [answer] > > It should not have resvtear msg sent back if the pathtear > msg has been > sent out to delete all the path, resv state block. > > For my understanding, no resvtear msg should be sent out for > the response > for the pathtear msg. > > I observed that there is one vendor which implements this > way---egress sent > out the resvtear to response the pathtear msg. > > Can anyone confirm this one for me? > > Julia > > > > > > > David Charlap > > mpls@UU.NET > rconi.com> cc: (bcc: > Hong Liao/Telcordia) > Subject: Re: > resvtear msg > 10/11/01 05:24 PM > > > > > > > > > > > Hariom P wrote: > > > > Why can't every hop that processes resvtear do the following, > > 1. Del matching reserv state and forward resvtear if required to the > > prevhop > > It should always send a ResvTear after deleting the corresponding > state. If the state is not present on the previous-hop router, then > that router will ignore the message. It is unreasonable to expect a > router to know with certainty what the adjacent routers' states are. > > If you send a ResvTear when the neighbor has no state, it's not a big > deal - the message will just be ignored. If, however, you do > not send a > ResvTear when you should have, the neighbor's Resv state will not go > away until it times out. Depending on how the routers are configured, > this could be quite a long time. > > > 2. And send a pathtear to the nexthop > > This is wrong. Path state should not be deleted when Resv state is > deleted. It must remain established, and the node must continue > refreshing it. > > It is perfectly legal (and not unusual in classical RSVP) for > an egress > node to delete a reservation and later re-establish it with different > parameters. > > Don't think of RSVP as a variation on LDP. It is not. A Path message > is not just a request for a label. It establishes state in and of > itself. It is not something that can be causally discarded simply > because some corresponding Resv state has been destroyed. > > -- David > > > From owner-mpls@UU.NET Tue Nov 13 18:22:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21377 for ; Tue, 13 Nov 2001 18:22:44 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpaj10288; Tue, 13 Nov 2001 23:22:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpaj18598 for mpls-outgoing; Tue, 13 Nov 2001 23:21:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpaj18593 for ; Tue, 13 Nov 2001 23:21: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 QQlpaj05088 for ; Tue, 13 Nov 2001 23:21:13 GMT Received: from thalia.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11]) id QQlpaj08730 for ; Tue, 13 Nov 2001 23:21:07 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id XAA05585 for ; Tue, 13 Nov 2001 23:21:11 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001111315215017466 ; Tue, 13 Nov 2001 15:21:50 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 15:21:11 -0800 Message-ID: From: "Feng, Mark" To: "'David Charlap'" , "'mpls@uu.net'" Subject: RE: Hello Extension - destination IP address Date: Tue, 13 Nov 2001 15:21:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: David Charlap [mailto:David.Charlap@marconi.com] > Sent: Tuesday, November 13, 2001 3:07 PM > To: 'mpls@uu.net' > Subject: Re: Hello Extension - destination IP address > > > "Feng, Mark" wrote: > >> > >> Suppose the state goes away due to a link failure (lost carrier on > >> the fiber). When the link comes back up, there may be a different > >> switch at the other end of the fiber. If so, that switch may not > >> be running RSVP, or it may not support Hello, or it may simply > >> have a different IP address. > > > > Wouldn't the Hello exchange timed out before the normal cleanup > > timer expiry? > > Probably. But if carrier is lost on the fiber, that will likely be > detected in hardware before the Hello times out. > Right. > > In either case, wouldn't the Hello state machine itself eventually > > settle to the correct state in the above cases? > > Yes, it will successfully tear everything. But do you want to restart > Hellos immediately or wait for new Path state? > > IMO, if a neighbor address is configured, it makes sense to restart > Hellos immediately after tearing down local state, so you can > know when > the neighbor comes back up (when you start getting Hello Acks back). > But it would be foolish to do this if you're auto-discovering your > neighbor, because that neighbor might have disappeared from > the network > altogether. > I agree. It makes more sense to start/re-start the Hello when we receive messages (again) from the neighbour. > -- David > From owner-mpls@UU.NET Tue Nov 13 18:25:24 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21448 for ; Tue, 13 Nov 2001 18:25:24 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpaj25193; Tue, 13 Nov 2001 23:23:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpaj18686 for mpls-outgoing; Tue, 13 Nov 2001 23:23:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpaj18670 for ; Tue, 13 Nov 2001 23:23:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpaj00017 for ; Tue, 13 Nov 2001 23:23:08 GMT Received: from thalia.fm.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11]) id QQlpaj07499 for ; Tue, 13 Nov 2001 23:23:10 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id XAA06638 for ; Tue, 13 Nov 2001 23:23:06 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001111315222007326 ; Tue, 13 Nov 2001 15:22:20 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 15:23:15 -0800 Message-ID: From: "Feng, Mark" To: "'Hong Liao'" , "Feng, Mark" Cc: mpls@UU.NET Subject: RE: resvtear msg Date: Tue, 13 Nov 2001 15:23:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk It is wrong to send the RTear; and the neighbour will most likely ignore it, because there shouldn't be any states matching the RTear after the PTear has been processed. - Mark > -----Original Message----- > From: Hong Liao [mailto:hliao@telcordia.com] > Sent: Tuesday, November 13, 2001 3:04 PM > To: Feng, Mark > Cc: mpls@UU.NET > Subject: RE: resvtear msg > > > > >>It will most likely be dropped by the neighbour since the > state would've > be removed by the Ptear. > > If it is considered wrong if the ResvTear msg sent out after > the Pathtear > msg, or it is fine, neighbour just ingore it. > > Thanks, > Julia > > > > > > > "Feng, Mark" > > Liao'" , mpls@UU.NET > ium.com> cc: (bcc: Hong > Liao/Telcordia) > Subject: RE: > resvtear msg > 11/13/01 > > 05:45 PM > > > > > > > > > > > Rtear shouldn't be sent as response to a Ptear. It will most likely be > dropped by the neighbour since the state would've be removed > by the Ptear. > > - Mark > > > -----Original Message----- > > From: Hong Liao [mailto:hliao@telcordia.com] > > Sent: Tuesday, November 13, 2001 2:15 PM > > To: mpls@UU.NET > > Subject: Re: resvtear msg > > > > > > > > Hi, > > > > Sorry to bring this topic again. > > > > I would like to make a conclusion, if I am wrong, please > point me out. > > > > [My question] > > For example, the ingress sent out the path msg to egress, the > > egress should > > not send out the resvtear msg, since pathrear will delete all > > the path and > > resv state block. But it is possible that egress send out > > the path msg > > before the the ingress sent out the pathtear msg. > > > > or it is also fine for the egress sent out the resvtear msg even the > > ingress send out the pathtear msg already. > > > > [answer] > > > > It should not have resvtear msg sent back if the pathtear > > msg has been > > sent out to delete all the path, resv state block. > > > > For my understanding, no resvtear msg should be sent out for > > the response > > for the pathtear msg. > > > > I observed that there is one vendor which implements this > > way---egress sent > > out the resvtear to response the pathtear msg. > > > > Can anyone confirm this one for me? > > > > Julia > > > > > > > > > > > > > > David Charlap > > > > > mpls@UU.NET > > rconi.com> cc: (bcc: > > Hong Liao/Telcordia) > > Subject: Re: > > resvtear msg > > 10/11/01 05:24 PM > > > > > > > > > > > > > > > > > > > > > > Hariom P wrote: > > > > > > Why can't every hop that processes resvtear do the following, > > > 1. Del matching reserv state and forward resvtear if > required to the > > > prevhop > > > > It should always send a ResvTear after deleting the corresponding > > state. If the state is not present on the previous-hop router, then > > that router will ignore the message. It is unreasonable to expect a > > router to know with certainty what the adjacent routers' states are. > > > > If you send a ResvTear when the neighbor has no state, it's > not a big > > deal - the message will just be ignored. If, however, you do > > not send a > > ResvTear when you should have, the neighbor's Resv state will not go > > away until it times out. Depending on how the routers are > configured, > > this could be quite a long time. > > > > > 2. And send a pathtear to the nexthop > > > > This is wrong. Path state should not be deleted when Resv state is > > deleted. It must remain established, and the node must continue > > refreshing it. > > > > It is perfectly legal (and not unusual in classical RSVP) for > > an egress > > node to delete a reservation and later re-establish it with > different > > parameters. > > > > Don't think of RSVP as a variation on LDP. It is not. A > Path message > > is not just a request for a label. It establishes state in and of > > itself. It is not something that can be causally discarded simply > > because some corresponding Resv state has been destroyed. > > > > -- David > > > > > > > > > From owner-mpls@UU.NET Tue Nov 13 21:42:40 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25790 for ; Tue, 13 Nov 2001 21:42:40 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpaw16099; Wed, 14 Nov 2001 02:42:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpaw00982 for mpls-outgoing; Wed, 14 Nov 2001 02:41:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpaw00975 for ; Wed, 14 Nov 2001 02:41: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 QQlpaw27518 for ; Wed, 14 Nov 2001 02:41:33 GMT Received: from rose.tju.edu.cn by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rose.tju.edu.cn [202.113.0.9]) id QQlpaw29003 for ; Wed, 14 Nov 2001 02:41:25 GMT Received: from rose ([202.113.4.43]) by rose.tju.edu.cn (8.9.3/8.8.7) with SMTP id KAA03634 for ; Wed, 14 Nov 2001 10:24:19 +0800 Message-Id: <200111140224.KAA03634@rose.tju.edu.cn> Date: Wed, 14 Nov 2001 10:39:16 +0800 From: STONE CHEN To: "mpls@UU.NET" Subject: Delay constraint X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello,everyone, In constrainte based routing,how to deal with the delay constraint? Someone just taked it into account as the "length"of the link. Is there any other model? Thanks in advance. stone From owner-mpls@UU.NET Wed Nov 14 01:04:12 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29345 for ; Wed, 14 Nov 2001 01:04:12 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpbk00517; Wed, 14 Nov 2001 06:03:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpbk23492 for mpls-outgoing; Wed, 14 Nov 2001 06:03:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpbk23481 for ; Wed, 14 Nov 2001 06:03:07 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpbk29919 for ; Wed, 14 Nov 2001 06:02:56 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQlpbk28269 for ; Wed, 14 Nov 2001 06:02:50 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id fAE62t078807; Tue, 13 Nov 2001 22:02:55 -0800 (PST) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id WAA05903; Tue, 13 Nov 2001 22:02:54 -0800 (PST) Date: Tue, 13 Nov 2001 22:02:54 -0800 (PST) From: Kireeti Kompella Message-Id: <200111140602.WAA05903@kummer.juniper.net> To: David.Charlap@marconi.com, m_feng@trillium.com, mpls@UU.NET Subject: RE: Hello Extension - destination IP address In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk > Why is it necessary to stop sending the Hello in this case? Excellent question. Kireeti. From owner-mpls@UU.NET Wed Nov 14 07:12:29 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19068 for ; Wed, 14 Nov 2001 07:12:29 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpci27590; Wed, 14 Nov 2001 12:07:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpci23619 for mpls-outgoing; Wed, 14 Nov 2001 12:07:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpci23565 for ; Wed, 14 Nov 2001 12:07:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpci25273 for ; Wed, 14 Nov 2001 12:07:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlpci26245 for ; Wed, 14 Nov 2001 12:06:56 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA16662 for ; Wed, 14 Nov 2001 07:07:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA22816 for mpls@uu.net; Wed, 14 Nov 2001 07:07:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpci19323 for ; Wed, 14 Nov 2001 12:05: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 QQlpci13101 for ; Wed, 14 Nov 2001 12:02:58 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQlpci05024 for ; Wed, 14 Nov 2001 12:03:00 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18707; Wed, 14 Nov 2001 07:02:54 -0500 (EST) Message-Id: <200111141202.HAA18707@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-multicast-06.txt Date: Wed, 14 Nov 2001 07:02:54 -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 : Framework for IP Multicast in MPLS Author(s) : D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul, F. Ansari Filename : draft-ietf-mpls-multicast-06.txt Pages : 28 Date : 13-Nov-01 This document offers a framework for IP multicast deployment in an MPLS environment. Issues arising when MPLS techniques are applied to IP multicast are overviewed. The pros and cons of existing IP multicast routing protocols in the context of MPLS are described and the relation to the different trigger methods and label distribution modes are discussed. The consequences of various layer 2 (L2) technologies are listed. Both point-to-point and multi-access networks are considered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-multicast-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-multicast-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-multicast-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011113143916.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-multicast-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-multicast-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011113143916.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Nov 14 08:42:28 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22191 for ; Wed, 14 Nov 2001 08:42:27 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpco28844; Wed, 14 Nov 2001 13:40:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpco18774 for mpls-outgoing; Wed, 14 Nov 2001 13:40:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpco18769 for ; Wed, 14 Nov 2001 13:40: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 QQlpco02555 for ; Wed, 14 Nov 2001 13:40:22 GMT Received: from roura.ac.upc.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: roura.ac.upc.es [147.83.33.10]) id QQlpco05201 for ; Wed, 14 Nov 2001 13:40:14 GMT Received: from ac.upc.es (pccba12.ac.upc.es [147.83.35.91]) by roura.ac.upc.es (8.11.6/8.11.0) with ESMTP id fAEDe2b14748 for ; Wed, 14 Nov 2001 14:40:02 +0100 (MET) Message-ID: <3BF273CC.4753A44F@ac.upc.es> Date: Wed, 14 Nov 2001 14:38:20 +0100 From: Salvatore Spadaro X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Information Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello everybody, I am studying the Optical Channel demands statistics according to the traffic generated by the users in an IP over ASON environment. Could someone help me with information about the triggering mechanism of the Optical Channels? For example, in a MPLS router, which is the triggering mechanism of the establishment for a new LSP? Thank you very much in advanced. Salvatore From owner-mpls@UU.NET Wed Nov 14 10:03:04 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26336 for ; Wed, 14 Nov 2001 10:03:04 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpcu08416; Wed, 14 Nov 2001 15:00:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpcu14246 for mpls-outgoing; Wed, 14 Nov 2001 15:00:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpct14146 for ; Wed, 14 Nov 2001 14:59:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpct01660 for ; Wed, 14 Nov 2001 14:58:51 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 QQlpct08279 for ; Wed, 14 Nov 2001 14:58:38 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA27884; Wed, 14 Nov 2001 09:58:47 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA21394; Wed, 14 Nov 2001 09:58:48 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Nov 2001 09:58:47 -0500 Message-ID: <39469E08BD83D411A3D900204840EC55762E31@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'STONE CHEN'" , mpls@UU.NET Subject: RE: Delay constraint Date: Wed, 14 Nov 2001 09:58:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="gb2312" Sender: owner-mpls@UU.NET Precedence: bulk Stone: Have a look at: draft-lefaucheur-te-metric-igp-01.txt draft-fedyk-mpls-te-metrics-00.txt draft-fedyk-isis-ospf-te-metrics-01.txt draft-wimer-ospf-traffic-00.txt Most of the proposals w.r.t delay are considered as a *metric* instead of as a continuous measurement of (path/link) delay --Venkata Naidu -> Hello,everyone, -> In constrainte based routing,how to deal with the delay -> constraint? -> Someone just taked it into account as the "length"of the link. -> Is there any other model? -> -> Thanks in advance. -> stone -> From owner-mpls@UU.NET Wed Nov 14 10:34:28 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28365 for ; Wed, 14 Nov 2001 10:34:28 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpcw09818; Wed, 14 Nov 2001 15:31:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpcw07257 for mpls-outgoing; Wed, 14 Nov 2001 15:31:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpcw07238 for ; Wed, 14 Nov 2001 15:31:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpcw18314 for ; Wed, 14 Nov 2001 15:30:04 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandmail.sandburst.com [216.57.132.42]) id QQlpcw14673 for ; Wed, 14 Nov 2001 15:30:06 GMT Message-ID: <3BF28DFA.3AE7FD7D@sandburst.com> Date: Wed, 14 Nov 2001 10:30:02 -0500 From: Eric Gray MIME-Version: 1.0 To: David Charlap Cc: MPLS Mailing List Subject: Re: Hello Extension - destination IP address References: <3BF1A164.4858AF20@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, Sorry, I don't buy this. Entirely aside from whether or not this is what was being proposed, it doesn't make sense to conclude that a peer has gone away because it has torn down all current signaling state. Not that I will necessarily agree that it makes sense to 'discover' RSVP peers using setup messages, either... You wrote (in part, and out of context): > ... > If you discover a peer by snooping RSVP setup messages, then it makes > sense to "un-discover" it by snooping RSVP tear messages. > ... > -- David -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray From owner-mpls@UU.NET Wed Nov 14 10:56:14 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29582 for ; Wed, 14 Nov 2001 10:56:14 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpcx24885; Wed, 14 Nov 2001 15:52:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpcx08814 for mpls-outgoing; Wed, 14 Nov 2001 15:51:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpcx08809 for ; Wed, 14 Nov 2001 15:51:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpcx06567 for ; Wed, 14 Nov 2001 15:51:18 GMT Received: from tenornetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQlpcx18280 for ; Wed, 14 Nov 2001 15:51:06 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fAEFp9016249; Wed, 14 Nov 2001 10:51:09 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; WED, 14 Nov 2001 10:50:27 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id <404WRXMB>; Wed, 14 Nov 2001 10:50:27 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E5659A2B1@newman.tenornet.com> From: "Arvind, K" To: "'Feng, Mark'" , "'David Charlap'" , "'mpls@uu.net'" Cc: "Arvind, K" Subject: RE: Hello Extension - destination IP address Date: Wed, 14 Nov 2001 10:50:21 -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 Please see comments (tagged KA>) in-line. Regards, Arvind. "Feng, Mark" wrote: > David Charlap wrote: >> >> If you do this (discovering neighbors for Hellos by snooping other >> RSVP packets), then you may want to stop sending Hellos when the >> all of the neighbor's RSVP state is torn, since you won't be able >> to tell whether the neighbor went offline, changed address, or >> simply doesn't have state. > > Why is it necessary to stop sending the Hello in this case? >It's not necessary. But you don't want to waste CPU time and bandwidth sending Hellos to a non-existant peer. KA> If the peer were non-existent, wouldn't the Hello protocol detect that and stop sending Hellos automatically? According to draft-ietf-mpls-rsvp-lsp-tunnel: "If no Instance values are received, via either REQUEST or ACK objects, from a neighbor within a configured number of hello_intervals, then a node MUST presume that it cannot communicate with the neighbor." At this point a node has the option of either reinitiating or suspending the HELLO protocol ("When communication is lost or presumed to be lost as above, a node MAY reinitiate HELLOs."). If conserving CPU time and bandwidth is an important requirement, an implementation can choose not to reinitiate HELLOs at this point. > IMO, the way the Hello state machine works is independant of the > means to discover the neighbour. Even if the neighbour's RSVP > states are gone, the neighbour should still respond to the Hello > messages. If all the state is gone, how can you be sure the switch's is still running? Suppose the state goes away due to a link failure (lost carrier on the fiber). When the link comes back up, there may be a different switch at the other end of the fiber. If so, that switch may not be running RSVP, or it may not support Hello, or it may simply have a different IP address. KA> Wouldn't the HELLO protocol automatically detect that the neighbor is down in this case as before? From owner-mpls@UU.NET Wed Nov 14 12:04:01 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04047 for ; Wed, 14 Nov 2001 12:04:01 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpdc03337; Wed, 14 Nov 2001 17:00:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpdc07924 for mpls-outgoing; Wed, 14 Nov 2001 17:00:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpdc07627 for ; Wed, 14 Nov 2001 17:00: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 QQlpdb28830 for ; Wed, 14 Nov 2001 16:59:25 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 QQlpdb29753 for ; Wed, 14 Nov 2001 16:59:18 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08986 for ; Wed, 14 Nov 2001 11:59:20 -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 LAA26006 for ; Wed, 14 Nov 2001 11:59:21 -0500 (EST) Message-ID: <3BF2A327.A26C8324@marconi.com> Date: Wed, 14 Nov 2001 12:00:23 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: Hello Extension - destination IP address References: <6B190B34070BD411ACA000B0D0214E5659A2B1@newman.tenornet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Arvind, K" wrote: >>> >>> Why is it necessary to stop sending the Hello in this case? >> >> It's not necessary. But you don't want to waste CPU time and >> bandwidth sending Hellos to a non-existant peer. > > If the peer were non-existent, wouldn't the Hello protocol detect > that and stop sending Hellos automatically? It's not required to. > According to > draft-ietf-mpls-rsvp-lsp-tunnel: > "If no Instance values are received, via either REQUEST or ACK > objects, from a neighbor within a configured number of > hello_intervals, then a node MUST presume that it cannot communicate > with the neighbor." At this point a node has the option of either > reinitiating or suspending the HELLO protocol ("When communication > is lost or presumed to be lost as above, a node MAY reinitiate > HELLOs."). If conserving CPU time and bandwidth is an important > requirement, an implementation can choose not to reinitiate HELLOs > at this point. Please read more than just the part you want to see. A router does not have to stop sending hellos after detecting a neighbor failure. It is allowed to automatically reinstate hellos, and it is allowed stop sending them. It is wrong to assume that everybody is going to stop sending hellos after a failure, just as it is wrong to assume that everybody is going to continue sending them after that same failure. If a neighbor address is configured (and therefore does not have to be discovered), it makes sense to resume hellos immediately. This allows us to detect our neighbor's hello instance ID as soon as it starts responding to hellos again (instead of waiting for some external trigger to restart hellos), which may be advantagious to some implementations. >>> IMO, the way the Hello state machine works is independant of the >>> means to discover the neighbour. Even if the neighbour's RSVP >>> states are gone, the neighbour should still respond to the Hello >>> messages. >> >> If all the state is gone, how can you be sure the switch's is still >> running? >> >> Suppose the state goes away due to a link failure (lost carrier on >> the fiber). When the link comes back up, there may be a different >> switch at the other end of the fiber. If so, that switch may not >> be running RSVP, or it may not support Hello, or it may simply have >> a different IP address. > > Wouldn't the HELLO protocol automatically detect that the neighbor > is down in this case as before? A neighbor's failure to respond to Hello does not indicate failure unless that neighbor was previously responding and later stopped. A neighbor that never responds may be perfectly operational, but doesn't support Hello (or has Hello disabled). Hello-detected neighbor failure is an edge-triggered event. You can detect an instant of failure. You can not use it to detect the duration of that failure. -- David From owner-mpls@UU.NET Wed Nov 14 12:08:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04327 for ; Wed, 14 Nov 2001 12:08:26 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpdc12821; Wed, 14 Nov 2001 17:04:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpdc14959 for mpls-outgoing; Wed, 14 Nov 2001 17:04:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpdc14952 for ; Wed, 14 Nov 2001 17:04:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpdc27604 for ; Wed, 14 Nov 2001 17:03:37 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandmail.sandburst.com [216.57.132.42]) id QQlpdc10154 for ; Wed, 14 Nov 2001 17:03:25 GMT Message-ID: <3BF2A3E2.78D9EA06@sandburst.com> Date: Wed, 14 Nov 2001 12:03:30 -0500 From: Eric Gray MIME-Version: 1.0 To: David Charlap , MPLS Mailing List Subject: Re: Hello Extension - destination IP address References: <3BF1A164.4858AF20@marconi.com> <3BF28DFA.3AE7FD7D@sandburst.com> <3BF2A05F.CCD355B0@marconi.com> <3BF2A285.36E22164@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > David, > > Interesting. Are you perhaps referring to 'reading you own messages' as > snooping? If you are, then the rest of what you say makes perfect sense. For the sake of clarity, 'your own messages' relates to messages addressed to you rather than messages sent by you - wher 'you' refers to the implementation or peer in question. > > > You wrote: > > > Eric Gray wrote: > > > David Charlap wrote: > > >> > > >> If you discover a peer by snooping RSVP setup messages, then it > > >> makes sense to "un-discover" it by snooping RSVP tear messages. > > > > > > Sorry, I don't buy this. Entirely aside from whether or not this > > > is what was being proposed, it doesn't make sense to conclude that > > > a peer has gone away because it has torn down all current signaling > > > state. Not that I will necessarily agree that it makes sense to > > > 'discover' RSVP peers using setup messages, either... > > > > OK then. > > > > How do you propose that a router determines what addresses to send > > hellos to? Do you want to mandate that this be configured? If not, how > > would you propose learning about neighbors? Inspecting the routing > > table for peers may result in a lot of non-RSVP neighbors, which you > > will be flooding with Hellos for no good reason. The only way to ensure > > that the neighbor is using RSVP is to note any RSVP messages that may > > come from that neighbor. > > > > Once you use this mechanism, how would you propose removing a neighbor > > from your list of neighbors to send hellos to? Surely you don't want to > > keep sending them forever, simply because you received one message a > > long time ago. When do you stop if you don't stop when the last Path > > adjacency goes away? > > > > Finally, keep in mind that the purpose of Hello is to summarily tear > > down state without waiting for a soft-state timeout. If you have no > > established state, what do you gain be sending them? > > > > -- David > > -- > Eric Gray (mailto:eric.gray@sandburst.com) > http://www.mindspring.com/~ewgray -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray From owner-mpls@UU.NET Wed Nov 14 12:13:12 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04575 for ; Wed, 14 Nov 2001 12:13:12 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpdb15863; Wed, 14 Nov 2001 16:49:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpdb03447 for mpls-outgoing; Wed, 14 Nov 2001 16:49:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpdb03419 for ; Wed, 14 Nov 2001 16:49:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpdb29376 for ; Wed, 14 Nov 2001 16:47:40 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQlpdb05996 for ; Wed, 14 Nov 2001 16:47:31 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08099 for ; Wed, 14 Nov 2001 11:47:29 -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 LAA23496 for ; Wed, 14 Nov 2001 11:47:30 -0500 (EST) Message-ID: <3BF2A05F.CCD355B0@marconi.com> Date: Wed, 14 Nov 2001 11:48:31 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: MPLS Mailing List Subject: Re: Hello Extension - destination IP address References: <3BF1A164.4858AF20@marconi.com> <3BF28DFA.3AE7FD7D@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray wrote: > David Charlap wrote: >> >> If you discover a peer by snooping RSVP setup messages, then it >> makes sense to "un-discover" it by snooping RSVP tear messages. > > Sorry, I don't buy this. Entirely aside from whether or not this > is what was being proposed, it doesn't make sense to conclude that > a peer has gone away because it has torn down all current signaling > state. Not that I will necessarily agree that it makes sense to > 'discover' RSVP peers using setup messages, either... OK then. How do you propose that a router determines what addresses to send hellos to? Do you want to mandate that this be configured? If not, how would you propose learning about neighbors? Inspecting the routing table for peers may result in a lot of non-RSVP neighbors, which you will be flooding with Hellos for no good reason. The only way to ensure that the neighbor is using RSVP is to note any RSVP messages that may come from that neighbor. Once you use this mechanism, how would you propose removing a neighbor from your list of neighbors to send hellos to? Surely you don't want to keep sending them forever, simply because you received one message a long time ago. When do you stop if you don't stop when the last Path adjacency goes away? Finally, keep in mind that the purpose of Hello is to summarily tear down state without waiting for a soft-state timeout. If you have no established state, what do you gain be sending them? -- David From owner-mpls@UU.NET Wed Nov 14 12:17:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04851 for ; Wed, 14 Nov 2001 12:17:53 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpdc27964; Wed, 14 Nov 2001 17:12:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpdc24450 for mpls-outgoing; Wed, 14 Nov 2001 17:12:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpdc24429 for ; Wed, 14 Nov 2001 17:12:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpdc14110 for ; Wed, 14 Nov 2001 17:10:26 GMT Received: from [172.16.1.119] by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mdclient1.opnet.com [12.145.55.10]) id QQlpdc29633 for ; Wed, 14 Nov 2001 17:10:29 GMT Received: from wtn10216.opnet.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 14 Nov 2001 12:07:17 -0500 Message-Id: <5.0.0.25.2.20011114120027.00b0e7c0@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 14 Nov 2001 12:09:29 -0500 To: mpls@UU.NET From: Sachin Kalra Subject: Re: RSVP-TE Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_782818002==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_782818002==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Even if [R4] is using GLA (Global Label Allocation) then When and how is Backup tunnel signaled and established? (Because some papers talk about "Un signaled Backup tunnels" and some talk about "signaling backup tunnels" & labels being swapped in LSRs along this tunnel. So how do these LSRs along the Backup Tunnel decide upon their Label operations if there is no signaling for backup Tunnel?) Thanks, Sachin Kalra >Date: Tue, 13 Nov 2001 18:02:31 -0500 >To: mpls@UU.NET >From: Sachin Kalra >Subject: RSVP-TE > >Dear All: > >I have some questions about RSVP-TE Backup LSPs (Bypass tunnels). Any help >is greatly appreciated. > >Please let me know if the draft (draft-swallow-rsvp-bypass-label-01) is >too old to discuss in the list. (So that I just don't keep waiting for the >mails :-) ) > >The draft draft-swallow-rsvp-bypass-label-01.txt states that (Pg 4, Line 11) >"...if R4 does not use a global label space then a label must be assigned >out of the label space used by R4 on the interface terminating the link >from R7. if, however, R4 has a global label space then the label which R2 >uses during the backup could be the same label value which is used by R3." > >For the following topology > [R8] > \ >[R1]---------[R2]----[R3]----[R4]-----------------[R5] > \\ // \ > [R6]===[R7] [R9] > > >My questions are that if R4 does not use global label space (i.e. it has >multiple label spaces, specific to particular interfaces) then > 1> WHEN should the label be assigned out of label space used by > R4 on the interface terminating the link from R7? > a> Does it happens at the time when Primary LSP is signaled? > If Yes, then how is [R2] informed about this label? > > b> Or does it happens at time when primary LSP fails and > backup takeover? > If Yes, then does this means that signaling for > Backup LSP takes place? > > c> How does [R6] and [R7] decide in this case upon their > labels to be used and when to swap and when to pop? Or in other words how > is the Bypass Tunnel established? Is it statically configured? > > >Please, give some pointers to other readings related to this topic. >Thanks, >Sachin Kalra --=====================_782818002==_.ALT Content-Type: text/html; charset="us-ascii" Even if [R4] is using GLA (Global Label Allocation) then

When and how is Backup tunnel signaled and established?

(Because some papers talk about "Un signaled Backup tunnels" and some talk about "signaling backup tunnels" & labels being swapped in LSRs along this tunnel. So how do these LSRs along the Backup Tunnel decide upon their Label operations if there is no signaling for backup Tunnel?)

Thanks,
Sachin Kalra

Date: Tue, 13 Nov 2001 18:02:31 -0500
To: mpls@UU.NET
From: Sachin Kalra <skalra@opnet.com>
Subject: RSVP-TE

Dear All:

I have some questions about RSVP-TE Backup LSPs (Bypass tunnels). Any help is greatly appreciated.

Please let me know if the draft (draft-swallow-rsvp-bypass-label-01) is too old to discuss in the list. (So that I just don't keep waiting for the mails :-)  )

The draft draft-swallow-rsvp-bypass-label-01.txt states that (Pg 4, Line 11)
"...if R4 does not use a global label space then a label must be assigned out of the label space used by R4 on the interface terminating the link from R7. if, however, R4 has a global label space then the label which R2 uses during the backup could be the same label value which is used by R3."

For the following topology
        [R8]
             \
[R1]---------[R2]----[R3]----[R4]-----------------[R5]
                 \\              //    \
                 [R6]===[R7]     [R9]


My questions are that if R4 does not use global label space (i.e. it has multiple label spaces, specific to particular interfaces) then
        1> WHEN should the label be assigned out of label space used by R4 on the interface terminating the link from R7?
                a> Does it happens at the time when Primary LSP is signaled?
                        If Yes, then how is [R2] informed about this label?
                
                b> Or does it happens at time when primary LSP fails and backup takeover?
                        If Yes, then does this means that signaling for Backup LSP takes place?
                
                c> How does [R6] and [R7] decide in this case upon their labels to be used and when to swap and when to pop? Or in other words how is the Bypass Tunnel established? Is it statically  configured?


Please, give some pointers to other readings related to this topic.
Thanks,
Sachin Kalra
--=====================_782818002==_.ALT-- From owner-mpls@UU.NET Wed Nov 14 12:19:26 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05093 for ; Wed, 14 Nov 2001 12:19:26 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpdd04265; Wed, 14 Nov 2001 17:16:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpdd25053 for mpls-outgoing; Wed, 14 Nov 2001 17:16:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpdd25037 for ; Wed, 14 Nov 2001 17:16:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpdc25722 for ; Wed, 14 Nov 2001 17:12: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 QQlpdc04598 for ; Wed, 14 Nov 2001 17:12:54 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA10220 for ; Wed, 14 Nov 2001 12:12:43 -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 MAA29172 for ; Wed, 14 Nov 2001 12:12:44 -0500 (EST) Message-ID: <3BF2A649.AF687855@marconi.com> Date: Wed, 14 Nov 2001 12:13:45 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: MPLS Mailing List Subject: Re: Hello Extension - destination IP address References: <3BF1A164.4858AF20@marconi.com> <3BF28DFA.3AE7FD7D@sandburst.com> <3BF2A05F.CCD355B0@marconi.com> <3BF2A285.36E22164@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray wrote: > > Interesting. Are you perhaps referring to 'reading you own > messages' as snooping? If you are, then the rest of what you say > makes perfect sense. Yes. I'm talking about using incoming Path/Resv messages for a purpose additional to simply creating Path/Resv state. When you receive a Path or a Resv from a neighbor, and the TTL indicates that there were no non-RSVP routers between you and the neighbor, you can assume that the address in the HOP object is a directly-attached RSVP-capable router. It is therefore an address you may want to start exchanging Hellos with. Once the last amount of state goes away, however, you can no longer make that assumption. If you continue sending Hellos, you can still detect a failure, if you stop getting acknowledgements, or if the neighbor's instance ID changes. If the ID changes, you can even continue sending Hellos, since you know that the box is still there. If the acknowledgements stop, however, you don't know if the box is administratively down, rebooting, crashed, or turned off. And it serves no purpose (other than perhaps in a debugging effort) to detect a neighbor failure when there is no established state, since there's nothing to tear down. -- David From owner-mpls@UU.NET Wed Nov 14 13:00:56 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07776 for ; Wed, 14 Nov 2001 13:00:56 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpdf20966; Wed, 14 Nov 2001 17:57:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpdf27869 for mpls-outgoing; Wed, 14 Nov 2001 17:57:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpdf27864 for ; Wed, 14 Nov 2001 17:57:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpdf25910 for ; Wed, 14 Nov 2001 17:56:53 GMT Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157]) id QQlpdf01503 for ; Wed, 14 Nov 2001 17:56:55 GMT Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fAEHuCS15785 for ; Wed, 14 Nov 2001 12:56:12 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 14 Nov 2001 12:56:37 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Nov 2001 12:55:45 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34AA70BA@zcard0ka.ca.nortel.com> From: "David Allan" To: Ping Pan , mpls-list Subject: RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-02.txt] Date: Wed, 14 Nov 2001 12:55:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16D35.944B6D70" 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_01C16D35.944B6D70 Content-Type: text/plain; charset="iso-8859-1" Hi Ping: I'm trying to place LSP-PING in the spectrum between detection and diagnostic tools. If it is detection, then it strikes me as somewhat slow, not somthing I'd (for example) base protection switching on. If I try to switch quickly, then I'm doing it on the basis of ICMP failures (which can generate a false positive quite easily). If I switch authoritatively (avoiding false positives), then I am looking at relatively long outages (10s of seconds, as I need repeated ICMP failures to render the LSP as suspect, then some number of LSP-PING timeouts to ensure that it is the LSP that failed). I note the requirement to expedite LSP-PING handling in aware LSRs in 4.3. If it is diagnostic, then it does relatively quickly tell me that the LSP is genuinely and uniquely broken, but I need further tools to figure out the resource that is messed up. Simply tearing down the LSP returns suspect resources to the available pool in the network. Is this a fair characterization of LSP-PINGs limitations? BTW You mention the ability to test e2e MTU in the advertisment, but it does not leap out in the text. I assume this is an ad-hoc use of the PING mechanism (operator triggers MTU test and injects big LSP-PING packet into LSP and observes if it works). Is this the case? thanks Dave ------_=_NextPart_001_01C16D35.944B6D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: I-D ACTION:draft-pan-lsp-ping-02.txt]

Hi Ping:

I'm trying to place LSP-PING in the spectrum between = detection and diagnostic tools.

If it is detection, then it strikes me as somewhat = slow, not somthing I'd (for example) base protection switching on. If I = try to switch quickly, then I'm doing it on the basis of ICMP failures = (which can generate a false positive quite easily). If I switch = authoritatively (avoiding false positives), then I am looking at = relatively long outages (10s of seconds, as I need repeated ICMP = failures to render the LSP as suspect, then some number of LSP-PING = timeouts to ensure that it is the LSP that failed). I note the = requirement to expedite LSP-PING handling in aware LSRs in = 4.3.

If it is diagnostic, then it does relatively quickly = tell me that the LSP is genuinely and uniquely broken, but I need = further tools to figure out the resource that is messed up. Simply = tearing down the LSP returns suspect resources to the available pool in = the network.

Is this a fair characterization of LSP-PINGs = limitations?

BTW You mention the ability to test e2e MTU in the = advertisment, but it does not leap out in the text. I assume this is an = ad-hoc use of the PING mechanism (operator triggers MTU test and = injects big LSP-PING packet into LSP and observes if it works). Is this = the case?

thanks
Dave

------_=_NextPart_001_01C16D35.944B6D70-- From owner-mpls@UU.NET Wed Nov 14 13:10:59 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08624 for ; Wed, 14 Nov 2001 13:10:58 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpdg11611; Wed, 14 Nov 2001 18:06:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpdg16063 for mpls-outgoing; Wed, 14 Nov 2001 18:06:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpdg15879 for ; Wed, 14 Nov 2001 18:05:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpdg01366 for ; Wed, 14 Nov 2001 18:04:38 GMT Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQlpdg16022 for ; Wed, 14 Nov 2001 18:04:41 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fAEI4U029010; Wed, 14 Nov 2001 13:04:30 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; WED, 14 Nov 2001 13:03:41 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id <404WRX50>; Wed, 14 Nov 2001 13:03:41 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E5659A2B2@newman.tenornet.com> From: "Arvind, K" To: "'David Charlap'" Cc: "'mpls@uu.net'" Subject: RE: Hello Extension - destination IP address Date: Wed, 14 Nov 2001 13:03:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk David: I do agree that reinitiating Hellos after a neighbor failure is detected is optional, and this was stated clearly in my response. If an implementation chooses to reinitiate HELLOs only when a neighbor address is configured rather than when it is learned, I have no problem with that. I didn't state or imply that a neighbor's failure to respond to a HELLO always indicates a node failure - if it never responded to HELLOs in the past and continues not to, of course you cannot conclude that the neighbor has failed. The point of contention really was whether it is necessary to stop sending Hellos when all of a neighbor's RSVP state is torn, "since you won't be able to tell whether the neighbor went offline, changed address, or simply doesn't have state" (quoted from an earlier message in this thread) . I interpreted RSVP state to mean LSP state (for LSPs traversing the neighbor). If this interpretation is wrong, then this was the source of confusion. If it is correct, I still don't see the need to stop the HELLO protocol (except for reasons of CPU/bandwidth conservation, if that is a requirement) because "you won't be able to tell whether the neighbor went offline, changed address, or simply doesn't have state". There is no such need because if a neighbor that is running the HELLO protocol went offline or changed address, the HELLO protocol (if left running even after removing all LSP state) will detect it. Also, there are mechanisms in the HELLO protocol that allow the protocol optionally to go into a suspended state, if a neighbor becomes unreachable for whatever reason - this can take care of cpu/bandwidth utilization issues, if deployed. Regards, Arvind > -----Original Message----- > From: David Charlap [SMTP:David.Charlap@marconi.com] > Sent: Wednesday, November 14, 2001 12:00 PM > To: 'mpls@uu.net' > Subject: Re: Hello Extension - destination IP address > > "Arvind, K" wrote: > >>> > >>> Why is it necessary to stop sending the Hello in this case? > >> > >> It's not necessary. But you don't want to waste CPU time and > >> bandwidth sending Hellos to a non-existant peer. > > > > If the peer were non-existent, wouldn't the Hello protocol detect > > that and stop sending Hellos automatically? > > It's not required to. KA>I meant "stop sending Hellos, if it chooses to do so" as must be clear from the rest of the paragraph (quoted below). > > According to > > draft-ietf-mpls-rsvp-lsp-tunnel: > > "If no Instance values are received, via either REQUEST or ACK > > objects, from a neighbor within a configured number of > > hello_intervals, then a node MUST presume that it cannot communicate > > with the neighbor." At this point a node has the option of either > > reinitiating or suspending the HELLO protocol ("When communication > > is lost or presumed to be lost as above, a node MAY reinitiate > > HELLOs."). If conserving CPU time and bandwidth is an important > > requirement, an implementation can choose not to reinitiate HELLOs > > at this point. > > Please read more than just the part you want to see. > > A router does not have to stop sending hellos after detecting a neighbor > failure. It is allowed to automatically reinstate hellos, and it is > allowed stop sending them. > KA> I think this is exactly what I stated above - reinitiation of HELLOs is KA>optional. > It is wrong to assume that everybody is going to stop sending hellos > after a failure, just as it is wrong to assume that everybody is going > to continue sending them after that same failure. > KA>I don't think I made any such assumption. All I pointed out was that the KA>draft says that reinitiation of HELLOs is optional, and can be omitted if conserving KA>CPU time and bandwidth is an important requirement. > If a neighbor address is configured (and therefore does not have to be > discovered), it makes sense to resume hellos immediately. This allows > us to detect our neighbor's hello instance ID as soon as it starts > responding to hellos again (instead of waiting for some external trigger > to restart hellos), which may be advantagious to some implementations. > KA> Maybe so. > >>> IMO, the way the Hello state machine works is independant of the > >>> means to discover the neighbour. Even if the neighbour's RSVP > >>> states are gone, the neighbour should still respond to the Hello > >>> messages. > >> > >> If all the state is gone, how can you be sure the switch's is still > >> running? > >> > >> Suppose the state goes away due to a link failure (lost carrier on > >> the fiber). When the link comes back up, there may be a different > >> switch at the other end of the fiber. If so, that switch may not > >> be running RSVP, or it may not support Hello, or it may simply have > >> a different IP address. > > > > Wouldn't the HELLO protocol automatically detect that the neighbor > > is down in this case as before? > > A neighbor's failure to respond to Hello does not indicate failure > unless that neighbor was previously responding and later stopped. > KA> I believe this is the case we are discussing (i.e., the neighbor was previously responding and later stopepd), not the case where a neighbor that never responds but is perfectly operational. > A > neighbor that never responds may be perfectly operational, but doesn't >support Hello (or has Hello disabled). > Hello-detected neighbor failure is an edge-triggered event. You can > detect an instant of failure. You can not use it to detect the duration > of that failure. > > -- David From owner-mpls@UU.NET Wed Nov 14 13:25:04 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09321 for ; Wed, 14 Nov 2001 13:25:03 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpdh11295; Wed, 14 Nov 2001 18:22:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpdh19129 for mpls-outgoing; Wed, 14 Nov 2001 18:21:48 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpdh19124 for ; Wed, 14 Nov 2001 18:21:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpdh20131 for ; Wed, 14 Nov 2001 18:21:35 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandmail.sandburst.com [216.57.132.42]) id QQlpdh14415 for ; Wed, 14 Nov 2001 18:21:37 GMT Message-ID: <3BF2B62D.E0E64CC6@sandburst.com> Date: Wed, 14 Nov 2001 13:21:33 -0500 From: Eric Gray MIME-Version: 1.0 To: David Charlap Cc: MPLS Mailing List Subject: Re: Hello Extension - destination IP address References: <3BF1A164.4858AF20@marconi.com> <3BF28DFA.3AE7FD7D@sandburst.com> <3BF2A05F.CCD355B0@marconi.com> <3BF2A285.36E22164@sandburst.com> <3BF2A649.AF687855@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, As I said, this makes perfect sense - though I would be inclined to look at at least two aspects of this behavior in a different way. For one, I do not think of this as 'peer discovery' so much as I realize that the purpose of the 'Hello' messages is to prolong the validity of state information (in this sense, calling them 'Hello' messages, rather than 'Keep Alive' messages is misleading). Clearly, there is no point in preservation of an empty set of state information. For the other, I am inclined to think of snooping as listening to messages not intended to the 'snooping' implementation. I guess you could think of this as snooping, if - in a specific implementation - there is an intermediate (software) entity that redirects RSVP setup and teardown messages sending them to a separate (software) entity. But that reflects a particular implementation's view of the world. You wrote: > Eric Gray wrote: > > > > Interesting. Are you perhaps referring to 'reading you own > > messages' as snooping? If you are, then the rest of what you say > > makes perfect sense. > > Yes. I'm talking about using incoming Path/Resv messages for a purpose > additional to simply creating Path/Resv state. > > When you receive a Path or a Resv from a neighbor, and the TTL indicates > that there were no non-RSVP routers between you and the neighbor, you > can assume that the address in the HOP object is a directly-attached > RSVP-capable router. It is therefore an address you may want to start > exchanging Hellos with. > > Once the last amount of state goes away, however, you can no longer make > that assumption. > > If you continue sending Hellos, you can still detect a failure, if you > stop getting acknowledgements, or if the neighbor's instance ID > changes. If the ID changes, you can even continue sending Hellos, since > you know that the box is still there. If the acknowledgements stop, > however, you don't know if the box is administratively down, rebooting, > crashed, or turned off. > > And it serves no purpose (other than perhaps in a debugging effort) to > detect a neighbor failure when there is no established state, since > there's nothing to tear down. > > -- David -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray From owner-mpls@UU.NET Wed Nov 14 13:28:11 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09567 for ; Wed, 14 Nov 2001 13:28:11 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpdh19248; Wed, 14 Nov 2001 18:24:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpdh19254 for mpls-outgoing; Wed, 14 Nov 2001 18:24:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpdh19244 for ; Wed, 14 Nov 2001 18:24:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpdh20062 for ; Wed, 14 Nov 2001 18:21:17 GMT Received: from calliope1.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns01.fm.intel.com [132.233.247.10]) id QQlpdh09544 for ; Wed, 14 Nov 2001 18:21:05 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id SAA18503 for ; Wed, 14 Nov 2001 18:21:16 GMT Received: from fmsmsx27.fm.intel.com ([132.233.42.27]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001111410215714533 ; Wed, 14 Nov 2001 10:21:57 -0800 Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Nov 2001 10:21:57 -0800 Message-ID: From: "Feng, Mark" To: "'Arvind, K'" , "'David Charlap'" Cc: "'mpls@uu.net'" Subject: RE: Hello Extension - destination IP address Date: Wed, 14 Nov 2001 10:21:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Arvind, K [mailto:arvind@tenornetworks.com] > Sent: Wednesday, November 14, 2001 10:04 AM > To: 'David Charlap' > Cc: 'mpls@uu.net' > Subject: RE: Hello Extension - destination IP address > > The point of contention really was whether it is necessary to > stop sending > Hellos when all of a neighbor's RSVP state is torn, "since > you won't be > able to tell whether the neighbor went offline, changed > address, or simply > doesn't have state" (quoted from an earlier message in this thread) . > I interpreted RSVP state to mean LSP state (for LSPs traversing the > neighbor). If this interpretation is wrong, then this was the > source of > confusion. > If it is correct, I still don't see the need to stop the > HELLO protocol > (except for reasons of CPU/bandwidth conservation, if that is > a requirement) > because "you won't be able to tell whether the neighbor went offline, > changed address, or simply doesn't have state". There is no such need > because if a neighbor that is running the HELLO protocol went > offline or > changed address, the HELLO protocol (if left running even > after removing all > LSP state) will detect it. Also, there are mechanisms in the > HELLO protocol > that allow the protocol optionally to go into a suspended state, if a > neighbor becomes unreachable for whatever reason - this can > take care of > cpu/bandwidth utilization issues, if deployed. > Regards, > Arvind > I think, based on the previous discussion, stopping the Hello exchange is to save CPU/bandwidth. It's been mentioned previously that, even if the Hello is not stopped, the Hello state machine itself will come to the correct state. In case the neighbours are configured, there might be issues related to how much control/responsibility the user should have, e.g. stopping/re-starting of Hello. In case of discovering neighbours by "snooping" messsages received, the Hello machine is controlled entirely by the implementation. In this case, I feel you can do either, i.e. stopping/continue when all the states are torn. One curious thing mentioned above is the "suspension" of Hello. How's that work? I don't remember seeing that in the RFC. Thanks. - Mark From owner-mpls@UU.NET Wed Nov 14 15:38:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15619 for ; Wed, 14 Nov 2001 15:38:45 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpdq06540; Wed, 14 Nov 2001 20:36:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpdq08536 for mpls-outgoing; Wed, 14 Nov 2001 20:35:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpdq08522 for ; Wed, 14 Nov 2001 20:35:50 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpdq16874 for ; Wed, 14 Nov 2001 20:35:01 GMT Received: from tenornetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQlpdq04536 for ; Wed, 14 Nov 2001 20:34:55 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fAEKYw016124; Wed, 14 Nov 2001 15:34:58 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; WED, 14 Nov 2001 15:34:19 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id <404WRYM0>; Wed, 14 Nov 2001 15:34:19 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E5659A2B3@newman.tenornet.com> From: "Arvind, K" To: "'Feng, Mark'" Cc: "'mpls@uu.net'" Subject: RE: Hello Extension - destination IP address Date: Wed, 14 Nov 2001 15:34:16 -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 > LSP state) will detect it. Also, there are mechanisms in the > HELLO protocol > that allow the protocol optionally to go into a suspended state, if a > neighbor becomes unreachable for whatever reason - this can >>One curious thing mentioned above is the "suspension" of Hello. How's that >>work? I don't remember seeing that in the RFC. Thanks. Mark: The terminology "go into a suspended state" is not from the draft. By this phrase, I meant the ability to time out a neighbor and then to choose not to reinitiate HELLOs, perhaps until the neighbor is rediscovered through other means. (See section on "Hello Usage"): "If no Instance values are received, via either REQUEST or ACK objects, from a neighbor within a configured number of hello_intervals, then a node MUST presume that it cannot communicate with the neighbor ... When communication is lost or presumed to be lost as described above, a node MAY re-initiate HELLOs." Regards, Arvind. > -----Original Message----- > From: Feng, Mark [SMTP:m_feng@trillium.com] > Sent: Wednesday, November 14, 2001 1:21 PM > To: 'Arvind, K'; 'David Charlap' > Cc: 'mpls@uu.net' > Subject: RE: Hello Extension - destination IP address > > > > > -----Original Message----- > > From: Arvind, K [mailto:arvind@tenornetworks.com] > > Sent: Wednesday, November 14, 2001 10:04 AM > > To: 'David Charlap' > > Cc: 'mpls@uu.net' > > Subject: RE: Hello Extension - destination IP address > > > > The point of contention really was whether it is necessary to > > stop sending > > Hellos when all of a neighbor's RSVP state is torn, "since > > you won't be > > able to tell whether the neighbor went offline, changed > > address, or simply > > doesn't have state" (quoted from an earlier message in this thread) . > > I interpreted RSVP state to mean LSP state (for LSPs traversing the > > neighbor). If this interpretation is wrong, then this was the > > source of > > confusion. > > If it is correct, I still don't see the need to stop the > > HELLO protocol > > (except for reasons of CPU/bandwidth conservation, if that is > > a requirement) > > because "you won't be able to tell whether the neighbor went offline, > > changed address, or simply doesn't have state". There is no such need > > because if a neighbor that is running the HELLO protocol went > > offline or > > changed address, the HELLO protocol (if left running even > > after removing all > > LSP state) will detect it. Also, there are mechanisms in the > > HELLO protocol > > that allow the protocol optionally to go into a suspended state, if a > > neighbor becomes unreachable for whatever reason - this can > > take care of > > cpu/bandwidth utilization issues, if deployed. > > Regards, > > Arvind > > > > I think, based on the previous discussion, stopping the Hello exchange is > to > save CPU/bandwidth. It's been mentioned previously that, even if the Hello > is not stopped, the Hello state machine itself will come to the correct > state. > > In case the neighbours are configured, there might be issues related to > how > much control/responsibility the user should have, e.g. > stopping/re-starting > of Hello. > In case of discovering neighbours by "snooping" messsages received, the > Hello machine is controlled entirely by the implementation. In this case, > I > feel you can do either, i.e. stopping/continue when all the states are > torn. > > One curious thing mentioned above is the "suspension" of Hello. How's that > work? I don't remember seeing that in the RFC. Thanks. > > - Mark From owner-mpls@UU.NET Wed Nov 14 16:51:16 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18163 for ; Wed, 14 Nov 2001 16:51:15 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpdv14425; Wed, 14 Nov 2001 21:48:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpdv03685 for mpls-outgoing; Wed, 14 Nov 2001 21:48:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpdv03675 for ; Wed, 14 Nov 2001 21:48:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpdv11780 for ; Wed, 14 Nov 2001 21:47:47 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 QQlpdv06213 for ; Wed, 14 Nov 2001 21:47: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 QAA05355 for ; Wed, 14 Nov 2001 16:47:44 -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 QAA08052 for ; Wed, 14 Nov 2001 16:47:44 -0500 (EST) Message-ID: <3BF2E6BE.D1E28B53@marconi.com> Date: Wed, 14 Nov 2001 16:48:46 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: MPLS Mailing List Subject: Re: Hello Extension - destination IP address References: <3BF1A164.4858AF20@marconi.com> <3BF28DFA.3AE7FD7D@sandburst.com> <3BF2A05F.CCD355B0@marconi.com> <3BF2A285.36E22164@sandburst.com> <3BF2A649.AF687855@marconi.com> <3BF2B62D.E0E64CC6@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray wrote: > > As I said, this makes perfect sense - though I would be inclined to > look at at least two aspects of this behavior in a different way. > For one, I do not think of this as 'peer discovery' so much as I > realize that the purpose of the 'Hello' messages is to prolong the > validity of state information (in this sense, calling them 'Hello' > messages, rather than 'Keep Alive' messages is misleading). No. The purpose is exactly opposite. The purpose of RSVP Hello is to terminate connections earlier than they would otherwise be terminated (via soft-state timeouts.) The only way to keep a connection alive is to refresh it (using the features of RFC 2961, if available.) > Clearly, there is no point in preservation of an empty set of state > information. For the other, I am inclined to think of snooping as > listening to messages not intended to the 'snooping' implementation. > I guess you could think of this as snooping, if - in a specific > implementation - there is an intermediate (software) entity that > redirects RSVP setup and teardown messages sending them to a > separate (software) entity. But that reflects a particular > implementation's view of the world. Maybe it was a bad choice of words. I've always pictures RSVP Hello as something that can run independantly of the rest of RSVP, issuing "tear all state of this interface" commands to RSVP when Hello detects a neighbor failure. In this sense, if non-Hello packets have an affect of Hello processing it can be thought of as snooping. But you're right that this sense is not necessarily applicable, depending on how you visualize the protocol and/or implement it. -- David From owner-mpls@UU.NET Wed Nov 14 17:03:41 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18858 for ; Wed, 14 Nov 2001 17:03:41 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpdw01905; Wed, 14 Nov 2001 22:00:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpdw07323 for mpls-outgoing; Wed, 14 Nov 2001 22:00:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpdw07207 for ; Wed, 14 Nov 2001 22:00:35 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpdw05166 for ; Wed, 14 Nov 2001 22:00:00 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQlpdw02522 for ; Wed, 14 Nov 2001 22:00:02 GMT Received: from PRALAY (devdhcp63138.dev.acc.am.ericsson.se [129.192.63.138]) by acc.com (8.12.0/8.12.0) with SMTP id fAELxv7N017376; Wed, 14 Nov 2001 13:59:58 -0800 (PST) Reply-To: From: "Kameswara Rao Avasarala" To: "k m a" , Subject: RE: traffic engineering Date: Wed, 14 Nov 2001 13:56:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20011108200729.11191.qmail@mailweb22.rediffmail.com> Importance: Normal Disposition-Notification-To: "Kameswara Rao Avasarala" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I understood your question as "How does an edge LSR map an incoming packet to a particular LSP ? " . Is my understanding correct ? Kamesh. Kameswara Rao Avasarala Software Engineer Ericsson Inc Telephone: Work:805-562-6212 Resi: 805-562-8841 -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of k m a Sent: Thursday, November 08, 2001 12:07 PM To: mpls@UU.NET Subject: traffic engineering hi all, i have a doubt in the traffic engineering aspect of MPLS..i wanted to ask as to how the edge router which recives the packets from outside ,route them into the core...does it checks for links everytime a packet arrives....i mean how does it decide on an LSP...and does it have to probe the links for every packet that comes to it! in short my question is referring to how the edge router in contarsts to a normal router behaves..for routing packets.....does it probe the available links packet by packet..or does it do once in the beginning and then sends them to a particular LSP the packet which r of same destination!! hope am clear....!! thanx From owner-mpls@UU.NET Wed Nov 14 17:07:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19106 for ; Wed, 14 Nov 2001 17:07:48 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpdw09957; Wed, 14 Nov 2001 22:05:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpdw15210 for mpls-outgoing; Wed, 14 Nov 2001 22:04:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpdw15202 for ; Wed, 14 Nov 2001 22:04:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpdw14672 for ; Wed, 14 Nov 2001 22:04:03 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 QQlpdw07268 for ; Wed, 14 Nov 2001 22:03:51 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA11009 for ; Wed, 14 Nov 2001 16:59:58 -0500 (EST) Subject: resv_confirm in the resvtear msg and tspec in the patherr msg To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Wed, 14 Nov 2001 16:59:57 -0500 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 11/14/2001 04:59:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can anyone answer my following two questions? According to the spec rfc 2205, the resvtear msg has the following format: 1. ResvTear Message> ::= [] [ ]
Hi ,
     Yes,I would = like to add=20 that most of the ATM algorithms can be effectively used on MPLS=20 networks.
      Yes,for = mapping=20 traffic there is one universal rule :
 
      Mapping of the=20 Queue to port,which is charactersitic of many load balancing,diffeserv=20 implementations.
      =
      Regards,
      = Abhay
      
----- Original Message -----
From:=20 #ZHU=20 YONGQING#
To: Ashwin C.=20 Prabhu ; mpls@UU.NET=20
Sent: Tuesday, November 13, = 2001 8:22=20 PM
Subject: RE: how to map the=20 traffic?

Thank = you!
Do you mean the load = distribution=20 algorithms also used in ATM and other networks?
 
-----Original Message-----
From: Ashwin C. Prabhu = [mailto:Ashwinp@in.huawei.com]Sent:=20 Tuesday, November 13, 2001 10:29 PM
To: #ZHU=20 YONGQING#
Subject: RE: how to map the=20 traffic?

Hello
 
  It depends on your policy. If you = have=20 multiple LSP's then either you can choose
  one of them or you can choose some = algorithm=20 to distribute the traffic on the LSP's.
  For this matter you can use any = load=20 distribution algoritms.
 
Ashwin
 
-----Original Message-----
From: #ZHU YONGQING# = [mailto:PG01320073@ntu.edu.sg]
Sent: Tuesday, November = 13, 2001=20 7:03 PM
To: Ashwin C. Prabhu
Subject: RE: how = to map=20 the traffic?

Thanks!
Then if there are multiple LSPs = between an=20 paticular ingress-egress nodes pair, and the arriving traffic = flows are=20 destinated to the egress node, how can they decide which LSP to = take?=20 (it's out of the scope of rfc3036)
-----Original Message-----
From: Ashwin C. = Prabhu=20 [mailto:Ashwinp@in.huawei.com]
Sent: Tuesday, November = 13,=20 2001 9:48 PM
To: #ZHU YONGQING#;=20 mpls@UU.NET
Subject: RE: how to map the=20 traffic?


Hello

 You can read the section

2.1. FECs of the RFC 3036

Regds
Ashwin =

-----Original Message-----
From:=20 #ZHU YONGQING# [mailto:PG01320073@ntu.edu.sg]=20
Sent: Tuesday, November 13, 2001 6:15 = PM=20
To: mpls@UU.NET
Subject: how to=20 map the traffic?


hi,
I have a = question about=20 mapping the traffic. When the traffic flows
arrive the ingress LSR of MPLS domain, how are they = mapped=20 into
pre-estabished LSPs? Is it an = issue of=20 traffic engineering? Does it need
any = algorithm=20 or is there any protocol about it?

Thanks a lot!=20

------=_NextPart_000_000A_01C16DD1.AD059060-- From owner-mpls@UU.NET Thu Nov 15 02:51:16 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15200 for ; Thu, 15 Nov 2001 02:51:16 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpfj02537; Thu, 15 Nov 2001 07:49:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpfj29489 for mpls-outgoing; Thu, 15 Nov 2001 07:49:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpfj29477 for ; Thu, 15 Nov 2001 07:49:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpfj26453 for ; Thu, 15 Nov 2001 07:49:12 GMT Received: from MAIL13.student.main.ntu.edu.sg by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [155.69.5.164]) id QQlpfj01106 for ; Thu, 15 Nov 2001 07:48:57 GMT Received: from mail02.student.main.ntu.edu.sg ([155.69.5.166]) by MAIL13.student.main.ntu.edu.sg with Microsoft SMTPSVC(5.0.2195.2966); Thu, 15 Nov 2001 15:27:04 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16DA6.EC521BC8" Subject: RE: how to map the traffic? Date: Thu, 15 Nov 2001 15:27:03 +0800 Message-ID: <0C42D409AF10B1428A0B026FB160A5BE1C1EAB@mail02.student.main.ntu.edu.sg> Thread-Topic: how to map the traffic? Thread-Index: AcFtovLUmMpoYNmLEdW27AAIx1184AAA/Uqw From: "#ZHU YONGQING#" To: "abhay" , X-OriginalArrivalTime: 15 Nov 2001 07:27:04.0295 (UTC) FILETIME=[EC80D770:01C16DA6] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C16DA6.EC521BC8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you very much!=20 I'm very iterested in algorithms about traffic distribution and load balancing. Can you recommend me some papers in this field? Do these ATM algorithms require modification to be used in MPLS? Or can they be used directly in MPLS? regards, Zhu -----Original Message----- From: abhay [mailto:abhay@multitech.co.in] Sent: Thursday, November 15, 2001 3:03 PM To: #ZHU YONGQING#; Ashwin C. Prabhu; mpls@UU.NET Subject: Re: how to map the traffic? Hi , Yes,I would like to add that most of the ATM algorithms can be effectively used on MPLS networks. Yes,for mapping traffic there is one universal rule : =20 Mapping of the Queue to port,which is charactersitic of many load balancing,diffeserv implementations. =20 Regards, Abhay =20 ----- Original Message -----=20 From: #ZHU YONGQING#=20 To: Ashwin C. Prabhu ; mpls@UU.NET=20 Sent: Tuesday, November 13, 2001 8:22 PM Subject: RE: how to map the traffic? Thank you! Do you mean the load distribution algorithms also used in ATM and other networks? =20 -----Original Message----- From: Ashwin C. Prabhu [ mailto:Ashwinp@in.huawei.com] Sent: Tuesday, November 13, 2001 10:29 PM To: #ZHU YONGQING# Subject: RE: how to map the traffic? Hello=20 =20 It depends on your policy. If you have multiple LSP's then either you can choose=20 one of them or you can choose some algorithm to distribute the traffic on the LSP's. For this matter you can use any load distribution algoritms.=20 =20 Ashwin =20 -----Original Message----- From: #ZHU YONGQING# [mailto:PG01320073@ntu.edu.sg] Sent: Tuesday, November 13, 2001 7:03 PM To: Ashwin C. Prabhu Subject: RE: how to map the traffic? Thanks!=20 Then if there are multiple LSPs between an paticular ingress-egress nodes pair, and the arriving traffic flows are destinated to the egress node, how can they decide which LSP to take? (it's out of the scope of rfc3036) -----Original Message----- From: Ashwin C. Prabhu [mailto:Ashwinp@in.huawei.com] Sent: Tuesday, November 13, 2001 9:48 PM To: #ZHU YONGQING#; mpls@UU.NET Subject: RE: how to map the traffic? Hello=20 You can read the section=20 2.1. FECs of the RFC 3036=20 Regds=20 Ashwin=20 -----Original Message-----=20 From: #ZHU YONGQING# [ mailto:PG01320073@ntu.edu.sg]=20 Sent: Tuesday, November 13, 2001 6:15 PM=20 To: mpls@UU.NET=20 Subject: how to map the traffic?=20 hi,=20 I have a question about mapping the traffic. When the traffic flows=20 arrive the ingress LSR of MPLS domain, how are they mapped into=20 pre-estabished LSPs? Is it an issue of traffic engineering? Does it need any algorithm or is there any protocol about it?=20 Thanks a lot!=20 ------_=_NextPart_001_01C16DA6.EC521BC8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: how to map the traffic?
Thank=20 you very much!
I'm=20 very iterested in algorithms about traffic distribution and load = balancing. Can=20 you recommend me some papers in this field? Do these ATM=20 algorithms require modification to be used in MPLS? Or can = they be=20 used directly in MPLS?
regards,
Zhu
-----Original Message-----
From: abhay=20 [mailto:abhay@multitech.co.in]
Sent: Thursday, November 15, = 2001=20 3:03 PM
To: #ZHU YONGQING#; Ashwin C. Prabhu;=20 mpls@UU.NET
Subject: Re: how to map the=20 traffic?

Hi ,
     Yes,I would = like to add=20 that most of the ATM algorithms can be effectively used on MPLS=20 networks.
      = Yes,for mapping=20 traffic there is one universal rule :
 
      Mapping of=20 the Queue to port,which is charactersitic of many load = balancing,diffeserv=20 implementations.
      =
      Regards,
      = Abhay
      
----- Original Message -----
From:=20 #ZHU=20 YONGQING#
To: Ashwin C.=20 Prabhu ; mpls@UU.NET=20
Sent: Tuesday, November 13, = 2001 8:22=20 PM
Subject: RE: how to map the=20 traffic?

Thank = you!
Do you mean the load = distribution=20 algorithms also used in ATM and other networks?
 
-----Original Message-----
From: Ashwin C. = Prabhu [mailto:Ashwinp@in.huawei.com]Sent:=20 Tuesday, November 13, 2001 10:29 PM
To: #ZHU=20 YONGQING#
Subject: RE: how to map the=20 traffic?

Hello
 
  It depends on your policy. If = you have=20 multiple LSP's then either you can choose
  one of them or you can choose = some=20 algorithm to distribute the traffic on the = LSP's.
  For this matter you can use any = load=20 distribution algoritms.
 
Ashwin
 
-----Original Message-----
From: #ZHU = YONGQING#=20 [mailto:PG01320073@ntu.edu.sg]
Sent: Tuesday, November = 13,=20 2001 7:03 PM
To: Ashwin C. Prabhu
Subject: = RE: how=20 to map the traffic?

Thanks!
Then if there are multiple LSPs = between an=20 paticular ingress-egress nodes pair, and the arriving traffic = flows are=20 destinated to the egress node, how can they decide which LSP to = take?=20 (it's out of the scope of rfc3036)
-----Original Message-----
From: Ashwin C. = Prabhu=20 [mailto:Ashwinp@in.huawei.com]
Sent: Tuesday, = November 13,=20 2001 9:48 PM
To: #ZHU YONGQING#;=20 mpls@UU.NET
Subject: RE: how to map the=20 traffic?


Hello

 You can read the section

2.1. FECs of the RFC 3036

Regds
Ashwin

-----Original Message-----
From: #ZHU YONGQING# [mailto:PG01320073@ntu.edu.sg]=20
Sent: Tuesday, November 13, 2001 6:15 = PM=20
To: mpls@UU.NET
Subject: how=20 to map the traffic?


hi,
I have a = question about=20 mapping the traffic. When the traffic flows
arrive the ingress LSR of MPLS domain, how are they = mapped=20 into
pre-estabished LSPs? Is it an = issue of=20 traffic engineering? Does it need
any=20 algorithm or is there any protocol about it?

Thanks a lot!=20 =

------_=_NextPart_001_01C16DA6.EC521BC8-- From owner-mpls@UU.NET Thu Nov 15 05:41:52 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17029 for ; Thu, 15 Nov 2001 05:41:51 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpfu15284; Thu, 15 Nov 2001 10:38:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpfu09422 for mpls-outgoing; Thu, 15 Nov 2001 10:38:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpfu09417 for ; Thu, 15 Nov 2001 10:38:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpfu13428 for ; Thu, 15 Nov 2001 10:36:49 GMT Received: from multitech.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQlpfu12648 for ; Thu, 15 Nov 2001 10:36:33 GMT Received: from abhay ([192.168.1.112]) by multitech.co.in (8.12.1/8.12.1) with SMTP id fAFAardw010919; Thu, 15 Nov 2001 16:06:55 +0530 Message-ID: <000c01c16dc2$54130460$7001a8c0@multitech.co.in> From: "abhay" To: "#ZHU YONGQING#" , References: <0C42D409AF10B1428A0B026FB160A5BE1C1EAB@mail02.student.main.ntu.edu.sg> Subject: Re: how to map the traffic? Date: Thu, 15 Nov 2001 16:13:11 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C16DF0.6C186040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C16DF0.6C186040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: how to map the traffic?Hi Zhu Yongqing, You can visit the ATM forum for an explanation = of these algorithms. These algorithms can be applied to the Switching = and the Semantics in the Label Information Base or the VCI = Lookuptable,they will be almost the same. That means,they can be applied to both ATM and = MPLS ----- Original Message -----=20 From: #ZHU YONGQING#=20 To: abhay ; mpls@UU.NET=20 Sent: Thursday, November 15, 2001 12:57 PM Subject: RE: how to map the traffic? Thank you very much!=20 I'm very iterested in algorithms about traffic distribution and load = balancing. Can you recommend me some papers in this field? Do these ATM = algorithms require modification to be used in MPLS? Or can they be used = directly in MPLS? regards, Zhu -----Original Message----- From: abhay [mailto:abhay@multitech.co.in] Sent: Thursday, November 15, 2001 3:03 PM To: #ZHU YONGQING#; Ashwin C. Prabhu; mpls@UU.NET Subject: Re: how to map the traffic? Hi , Yes,I would like to add that most of the ATM algorithms can be = effectively used on MPLS networks. Yes,for mapping traffic there is one universal rule : Mapping of the Queue to port,which is charactersitic of many = load balancing,diffeserv implementations. =20 Regards, Abhay =20 ----- Original Message -----=20 From: #ZHU YONGQING#=20 To: Ashwin C. Prabhu ; mpls@UU.NET=20 Sent: Tuesday, November 13, 2001 8:22 PM Subject: RE: how to map the traffic? Thank you! Do you mean the load distribution algorithms also used in ATM and = other networks? -----Original Message----- From: Ashwin C. Prabhu [mailto:Ashwinp@in.huawei.com] Sent: Tuesday, November 13, 2001 10:29 PM To: #ZHU YONGQING# Subject: RE: how to map the traffic? Hello=20 =20 It depends on your policy. If you have multiple LSP's then = either you can choose=20 one of them or you can choose some algorithm to distribute the = traffic on the LSP's. For this matter you can use any load distribution algoritms.=20 =20 Ashwin =20 -----Original Message----- From: #ZHU YONGQING# [mailto:PG01320073@ntu.edu.sg] Sent: Tuesday, November 13, 2001 7:03 PM To: Ashwin C. Prabhu Subject: RE: how to map the traffic? Thanks!=20 Then if there are multiple LSPs between an paticular = ingress-egress nodes pair, and the arriving traffic flows are destinated = to the egress node, how can they decide which LSP to take? (it's out of = the scope of rfc3036) -----Original Message----- From: Ashwin C. Prabhu [mailto:Ashwinp@in.huawei.com] Sent: Tuesday, November 13, 2001 9:48 PM To: #ZHU YONGQING#; mpls@UU.NET Subject: RE: how to map the traffic? Hello=20 You can read the section=20 2.1. FECs of the RFC 3036=20 Regds=20 Ashwin=20 -----Original Message-----=20 From: #ZHU YONGQING# [mailto:PG01320073@ntu.edu.sg]=20 Sent: Tuesday, November 13, 2001 6:15 PM=20 To: mpls@UU.NET=20 Subject: how to map the traffic?=20 hi,=20 I have a question about mapping the traffic. When the = traffic flows=20 arrive the ingress LSR of MPLS domain, how are they mapped = into=20 pre-estabished LSPs? Is it an issue of traffic engineering? = Does it need=20 any algorithm or is there any protocol about it?=20 Thanks a lot!=20 ------=_NextPart_000_0009_01C16DF0.6C186040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: how to map the traffic?
Hi Zhu Yongqing,
          &nbs= p;            = ; You=20 can visit the ATM forum for an explanation of these = algorithms.
          &nbs= p;            = ; These=20 algorithms can be applied to the Switching and the Semantics = in
          &nbs= p;            = ;=20 the Label Information Base or the VCI Lookuptable,they will be almost = the=20 same.
          &nbs= p;            = ; That=20 means,they can be applied to both ATM and MPLS
----- Original Message -----
From:=20 #ZHU=20 YONGQING#
To: abhay ; mpls@UU.NET
Sent: Thursday, November 15, = 2001 12:57=20 PM
Subject: RE: how to map the=20 traffic?

Thank you very much!
I'm=20 very iterested in algorithms about traffic distribution and load = balancing.=20 Can you recommend me some papers in this field? Do these ATM=20 algorithms require modification to be used in MPLS? Or can = they be=20 used directly in MPLS?
regards,
Zhu
-----Original Message-----
From: abhay [mailto:abhay@multitech.co.in]Sent:=20 Thursday, November 15, 2001 3:03 PM
To: #ZHU YONGQING#; = Ashwin C.=20 Prabhu; mpls@UU.NET
Subject: Re: how to map the=20 traffic?

Hi ,
     Yes,I = would like to=20 add that most of the ATM algorithms can be effectively used on MPLS=20 networks.
      = Yes,for mapping=20 traffic there is one universal rule :
 
      Mapping of=20 the Queue to port,which is charactersitic of many load = balancing,diffeserv=20 implementations.
      =
      Regards,
     =20 Abhay
      
----- Original Message ----- =
From:=20 #ZHU=20 YONGQING#
To: Ashwin C.=20 Prabhu ; mpls@UU.NET
Sent: Tuesday, November 13, = 2001 8:22=20 PM
Subject: RE: how to map the = traffic?

Thank = you!
Do you mean the load = distribution=20 algorithms also used in ATM and other = networks?
 
-----Original Message-----
From: Ashwin C. = Prabhu [mailto:Ashwinp@in.huawei.com]Sent:=20 Tuesday, November 13, 2001 10:29 PM
To: #ZHU=20 YONGQING#
Subject: RE: how to map the=20 traffic?

Hello
 
  It depends on your policy. If = you have=20 multiple LSP's then either you can choose
  one of them or you can choose = some=20 algorithm to distribute the traffic on the = LSP's.
  For this matter you can use = any load=20 distribution algoritms.
 
Ashwin
 
-----Original Message-----
From: #ZHU = YONGQING#=20 [mailto:PG01320073@ntu.edu.sg]
Sent: Tuesday, = November 13,=20 2001 7:03 PM
To: Ashwin C. Prabhu
Subject: = RE: how=20 to map the traffic?

Thanks!
Then if there are multiple LSPs=20 between an paticular ingress-egress nodes pair, and the = arriving=20 traffic flows are destinated to the egress node, how can they = decide=20 which LSP to take? (it's out of the scope of=20 rfc3036)
-----Original Message-----
From: Ashwin = C. Prabhu=20 [mailto:Ashwinp@in.huawei.com]
Sent: Tuesday, = November 13,=20 2001 9:48 PM
To: #ZHU YONGQING#;=20 mpls@UU.NET
Subject: RE: how to map the=20 traffic?


Hello

 You can read the section

2.1. FECs of the RFC 3036

Regds
Ashwin

-----Original Message----- =
From: #ZHU YONGQING# [mailto:PG01320073@ntu.edu.sg]=20
Sent: Tuesday, November 13, 2001 6:15 = PM=20
To: mpls@UU.NET
Subject:=20 how to map the traffic?


hi,
I have a = question about=20 mapping the traffic. When the traffic flows
arrive the ingress LSR of MPLS domain, how are they = mapped=20 into
pre-estabished LSPs? Is it an = issue of=20 traffic engineering? Does it need
any=20 algorithm or is there any protocol about it?

Thanks a lot!=20 =

------=_NextPart_000_0009_01C16DF0.6C186040-- From owner-mpls@UU.NET Thu Nov 15 07:27:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19450 for ; Thu, 15 Nov 2001 07:27:45 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpgb10413; Thu, 15 Nov 2001 12:26:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpgb25851 for mpls-outgoing; Thu, 15 Nov 2001 12:26:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpgb25817 for ; Thu, 15 Nov 2001 12:26:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpgb28072 for ; Thu, 15 Nov 2001 12:26:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlpgb10181 for ; Thu, 15 Nov 2001 12:25:50 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA02659 for ; Thu, 15 Nov 2001 07:26:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA00797 for mpls@uu.net; Thu, 15 Nov 2001 07:26:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpgb25738 for ; Thu, 15 Nov 2001 12:25:13 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 QQlpgb00237 for ; Thu, 15 Nov 2001 12:24:25 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQlpgb07930 for ; Thu, 15 Nov 2001 12:24:12 GMT Received: from packetexchange.net (unknown [217.204.176.205]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id 6AA2B15F83E; Thu, 15 Nov 2001 12:26:12 +0000 (GMT) Message-ID: <3BF3A65E.72D8C73C@packetexchange.net> Date: Thu, 15 Nov 2001 11:26:22 +0000 From: Giles Heron Reply-To: giles@packetexchange.net Organization: PacketExchange Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Narasimha Swamy Cc: "'mpls@uu.net'" Subject: Re: l2vpn doubt References: <13D467F625FAD511AE2A00D0B7B917D70642BA@mailserver.netbrahma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Narasimha Swamy wrote: > > Hi, my question is in the context of L2VPNs(martini drafts). > Using the new FEC element defined in > draft-martini-l2circuit-trans-mpls-07.txt, is it possible to achieve > "Single Endpoint Configuration of Emulated VCs" as explained in section 7.3 > of draft-ietf-ppvpn-l2vpn-00.txt. i.e. using this FEC element, how can > egress LSR indicate to ingress LSR, that to associate a particular > attachment VC at the ingress side with this L2VPN circuit. it can't. draft-martini-l2circuit-trans-mpls requires both ends to be configured with a matching VC ID. > Or does the draft-martini-l2circuit-trans-mpls-07.txt draft suggests to > configure a particular L2VPN circuit at the both LSRs using same VC ID(in > which case ofcourse, "Single Endpoint Configuration of Emulated VCs" is not > possible. And i think frames can't be transfered until circuit is configured > from both LSRs). exactly. BTW a proposal for extending draft-martini with single-sided signaling is documented in draft-rosen-ppvpn-l2-signaling-00.txt. Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Thu Nov 15 09:09:02 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24001 for ; Thu, 15 Nov 2001 09:09:02 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpgi18642; Thu, 15 Nov 2001 14:07:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpgi10920 for mpls-outgoing; Thu, 15 Nov 2001 14:06:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpgi10891 for ; Thu, 15 Nov 2001 14:06:25 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 QQlpgi22410 for ; Thu, 15 Nov 2001 14:05:26 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlpgi16345 for ; Thu, 15 Nov 2001 14:05:29 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA10109 for ; Thu, 15 Nov 2001 09:05:25 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA05602 for mpls@uu.net; Thu, 15 Nov 2001 09:05:25 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpen00952 for ; Thu, 15 Nov 2001 02:26:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpen19057 for ; Thu, 15 Nov 2001 02:26:04 GMT Received: from mp001.verizon.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mp001pub.verizon.net [206.46.170.170]) id QQlpen20855 for ; Thu, 15 Nov 2001 02:25:57 GMT Received: from [192.168.129.170] by mp001.verizon.net (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20011115022603.TCVC22496.mp001.verizon.net@[192.168.129.170]>; Wed, 14 Nov 2001 20:26:03 -0600 From: Joe Dumont Reply-To: joe.dumont@verizon.net To: mpls@UU.NET CC: joe.dumont@verizon.net Subject: DiffServ object in Rsvp Path messages Date: Wed, 14 Nov 2001 20:26:03 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011115022603.TCVC22496.mp001.verizon.net@[192.168.129.170]> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, While I was reading draft-ietf-mpls-generalized-rsvp-te-05.txt, I did not see a reference to the Rsvp DIFFSERV object in the Path message BNF figure. In draft-ietf-mpls-diff-ext-09.txt it precedes the POLICY_DATA object. Where would it appear with respect to the new gMPLS objects like PROTECTION, NOTIFY_REQUEST and ADMIN_STATUS? thanks, Joe From owner-mpls@UU.NET Thu Nov 15 11:23:36 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01415 for ; Thu, 15 Nov 2001 11:23:36 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpgr23413; Thu, 15 Nov 2001 16:20:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpgr01916 for mpls-outgoing; Thu, 15 Nov 2001 16:19:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpgr01911 for ; Thu, 15 Nov 2001 16:19:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpgr16828 for ; Thu, 15 Nov 2001 16:18:43 GMT Received: from dnsmx2pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQlpgr20606 for ; Thu, 15 Nov 2001 16:18:37 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA29780 for ; Thu, 15 Nov 2001 11:16:12 -0500 (EST) Subject: rsvp te question To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hong Liao" Date: Thu, 15 Nov 2001 11:16:12 -0500 X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 11/15/2001 11:16:13 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can anyone answer my following two questions? According to the spec rfc 2205, the resvtear msg has the following format: 1. ResvTear Message> ::= [] [ ]
Please be aware that we have = published four MIBs=20 related to monitoring and managing GMPLS systems.
 
These may be found at
 
http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-g= mpls-tc-mib-00.txt
http://search.ietf.org/internet-drafts/draft-nadeau-ccam= p-gmpls-label-mib-00.txt
http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-g= mpls-te-mib-00.txt
http://search.ietf.org/internet-drafts/draft-nadeau-ccamp-= gmpls-lsr-mib-00.txt
 
 
The TC MIB provides additional = Textual=20 Conventions to supplement those in = draft-ietf-mpls-tc-mib-02.txt
 
The Label MIB is entirely new for=20 GMPLS.
 
The TE and LSR MIBs are based=20 on draft-ietf-mpls-tc-mib-02.txt and draft-ietf-mpls-lsr-mib-06.txt = respectively.  Material for the TE MIB was drawn from http://search.ietf.org/internet-drafts/draft-nadeau-mpls-gmp= ls-te-mib-00.txt which should now be seen as = obsolete.
 
Discussions should take place on the = CCAMP=20 mailing list. We would welcome all = comments and=20 input.
 
We have asked for a slot in the CCAMP = WG agenda=20 at the upcoming IETF to present these.
 
Regards,
Adrian
--
Adrian Farrel
Movaz Networks = Inc.
Tel: 703-847-1867
afarrel@movaz.com
------=_NextPart_000_00E4_01C16DDA.74C91D80-- From owner-mpls@UU.NET Thu Nov 15 13:52:36 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11442 for ; Thu, 15 Nov 2001 13:52:36 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlphb25934; Thu, 15 Nov 2001 18:50:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQlphb22386 for mpls-outgoing; Thu, 15 Nov 2001 18:50:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlphb22380 for ; Thu, 15 Nov 2001 18:50:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlphb13017 for ; Thu, 15 Nov 2001 18:49:41 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQlphb19269 for ; Thu, 15 Nov 2001 18:49:34 GMT Received: from juniper.net (dhcp-nsw-47.juniper.net [172.17.13.209]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id fAFImq070926; Thu, 15 Nov 2001 10:48:52 -0800 (PST) (envelope-from pingpan@juniper.net) Message-ID: <3BF40E48.6010509@juniper.net> Date: Thu, 15 Nov 2001 10:49:44 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: David Allan CC: mpls-list Subject: Re: [Fwd: I-D ACTION:draft-pan-lsp-ping-02.txt] References: <3549C09B853DD5119B540002A52CDD34B0BDEF@zcard0ka.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, David Allan wrote: > > > > Do you imply that the root of the cause is due to the requirement to > > expedite LSP-ping handing on the intermediate routers? > > No, I simply note that there is an implementation recommendation to > expedite propagating the LSP_PING cookie back to the ingress. I'd > presume this is designed to reduce the time required to make an > authoritative decision on the status of a suspect LSP, although I don't > know if you can actually make any assumptions when picking the timeout > for an LSP-PING response (e.g. you are only speeding up knowning its not > broken). > LSP-ping uses a two-step query sequence: first use ICMP-ECHO-REQUEST. If no response, use LSP-ECHO. One of the reasons for a such design is to control processing overhead at the egress. We assume ICMP-ECHO-REQUEST packets are always easier to handle than LSP-ECHO. When to generate those query messages is up to the users (just like the 'ping' command). If they want to run it in the background, I hope they can use a large time interval. If they need to find out the problem faster, send a storm (like 'ping -f'). To define the protocol, we cannot specify the actual time values (I tried, and Dave Cooper told me to get lost. :-)). > So you think of it as more of a diagnostic aid...? > Actually, does it matter? :-) Thanks! - Ping From owner-mpls@UU.NET Thu Nov 15 14:54:36 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15592 for ; Thu, 15 Nov 2001 14:54:31 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlphf26341; Thu, 15 Nov 2001 19:50:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQlphf15621 for mpls-outgoing; Thu, 15 Nov 2001 19:50:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlphf15616 for ; Thu, 15 Nov 2001 19:50:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlphf12959 for ; Thu, 15 Nov 2001 19:48:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlphf14768 for ; Thu, 15 Nov 2001 19:47:50 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA00360 for ; Thu, 15 Nov 2001 14:48:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA22342 for mpls@uu.net; Thu, 15 Nov 2001 14:48:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlphf15513 for ; Thu, 15 Nov 2001 19:47:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlphf10713 for ; Thu, 15 Nov 2001 19:47:02 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQlphf23639 for ; Thu, 15 Nov 2001 19:47:05 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15019; Thu, 15 Nov 2001 14:46:57 -0500 (EST) Message-Id: <200111151946.OAA15019@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , mpls@UU.NET From: The IESG Subject: Protocol Action: MPLS Support of Differentiated Services to Proposed Standard Date: Thu, 15 Nov 2001 14:46:57 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft 'MPLS Support of Differentiated Services' as a Proposed Standard. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Bert Wijnen and Scott Bradner. Technical Summary This document defines a mechanism for the support of Differentiated Services (diffserv) over Multi-Protocol Label Switching (MPLS) networks. This mechanism allows the MPLS network administrator to select how diffserv Behavior Aggregates (BAs) are mapped onto Label Switched Paths (LSPs) so that he/she can best match the diffserv, Traffic Engineering and protection objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs. Working Group Summary There was working group consensus on this proposal and no issues were raised during IETF last-call. The last call was also noted on the difserv mailing list and no issues were raised there. Protocol Quality This proposal was reviewed for the IESG by Scott Bradner. Note to RFC Editor: Please change the reference to Explicit Congestion Notification (ECN) from RFC 2481 to RFC 3168. From owner-mpls@UU.NET Thu Nov 15 15:11:25 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16605 for ; Thu, 15 Nov 2001 15:11:25 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlphg18647; Thu, 15 Nov 2001 20:04:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQlphg27074 for mpls-outgoing; Thu, 15 Nov 2001 20:04:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlphg27067 for ; Thu, 15 Nov 2001 20:04:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlphg13556 for ; Thu, 15 Nov 2001 20:04:03 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 QQlphg19495 for ; Thu, 15 Nov 2001 20:04:05 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24919 for ; Thu, 15 Nov 2001 15:03: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 PAA26013 for ; Thu, 15 Nov 2001 15:03:58 -0500 (EST) Message-ID: <3BF41FF0.38395275@marconi.com> Date: Thu, 15 Nov 2001 15:05:04 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Protocol Action: MPLS Support of Differentiated Services toProposed Standard References: <200111151946.OAA15019@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The IESG wrote: > > The IESG has approved the Internet-Draft 'MPLS Support of > Differentiated Services' as a > Proposed Standard. This document is the product of the Multiprotocol > Label Switching Working Group. The IESG contact persons are Bert > Wijnen and Scott Bradner. So do we have IANA-assigned numbers for the DIFFSERV RSVP object yet? Draft -09 still says it's TBD. -- David From owner-mpls@UU.NET Thu Nov 15 15:58:48 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19958 for ; Thu, 15 Nov 2001 15:58:48 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlphj10638; Thu, 15 Nov 2001 20:55:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQlphj10713 for mpls-outgoing; Thu, 15 Nov 2001 20:55:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlphj10708 for ; Thu, 15 Nov 2001 20:55:44 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlphj19138 for ; Thu, 15 Nov 2001 20:53:50 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 QQlphj23684 for ; Thu, 15 Nov 2001 20:53:37 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA00038 for ; Thu, 15 Nov 2001 15:53:47 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06911 for ; Thu, 15 Nov 2001 15:53:48 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Nov 2001 15:53:47 -0500 Message-ID: <313680C9A886D511A06000204840E1CF8F4DDF@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: "'mpls@UU.NET'" Subject: How are the domain administrators are planning to use E-LSPs? Date: Thu, 15 Nov 2001 15:53:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi! I have some basic questions related to the usage of E-LSPs. I will appreciate, if you can help me with the following questions: Q1. Is any domain administrator/service provider actually using (planning) to use the E-LSPs in their network ? In which cases, E-LSPs are more useful than L-LSPs? Q2. While deploying E-LSPs in the network, is the primary usage is limited to differentiation via the signaled DiffServ classes ? OR is there practical use for reserving (and enforcing) bandwidth for the E-LSP (per LSP / per PSC bandwidth specification) ? Currently, the DS-TE-requirement draft does not address the E-LSP related requirements very clearly. Should it be updated with E-LSP related requirements? Thanks, sanjay From owner-mpls@UU.NET Thu Nov 15 15:59:16 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20045 for ; Thu, 15 Nov 2001 15:59:15 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlphj14042; Thu, 15 Nov 2001 20:57:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQlphj10901 for mpls-outgoing; Thu, 15 Nov 2001 20:57:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlphj10892 for ; Thu, 15 Nov 2001 20:57:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlphj11060 for ; Thu, 15 Nov 2001 20:57:32 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandmail.sandburst.com [216.57.132.42]) id QQlphj13153 for ; Thu, 15 Nov 2001 20:57:35 GMT Message-ID: <3BF42C35.178AF49B@sandburst.com> Date: Thu, 15 Nov 2001 15:57:25 -0500 From: Eric Gray MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: Protocol Action: MPLS Support of Differentiated Services toProposed Standard References: <200111151946.OAA15019@ietf.org> <3BF41FF0.38395275@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, I think it's the DIFFSERV Class number that's TBD, and it is often the case that assignments are not sought prior to getting the nod from the IESG. Also needed is the Diff-Serv Error code. You wrote: > The IESG wrote: > > > > The IESG has approved the Internet-Draft 'MPLS Support of > > Differentiated Services' as a > > Proposed Standard. This document is the product of the Multiprotocol > > Label Switching Working Group. The IESG contact persons are Bert > > Wijnen and Scott Bradner. > > So do we have IANA-assigned numbers for the DIFFSERV RSVP object yet? > > Draft -09 still says it's TBD. > > -- David -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray From owner-mpls@UU.NET Thu Nov 15 16:05:44 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20539 for ; Thu, 15 Nov 2001 16:05:44 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlphk06790; Thu, 15 Nov 2001 21:02:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQlphk19489 for mpls-outgoing; Thu, 15 Nov 2001 21:02:09 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlphk18957 for ; Thu, 15 Nov 2001 21:02:05 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 QQlphk26670 for ; Thu, 15 Nov 2001 21:01:39 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlphk20910 for ; Thu, 15 Nov 2001 21:01:32 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA11328 for ; Thu, 15 Nov 2001 16:01:38 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA26327 for mpls@uu.net; Thu, 15 Nov 2001 16:01:37 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlphk12123 for ; Thu, 15 Nov 2001 21:00:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlphj20812 for ; Thu, 15 Nov 2001 20:59:41 GMT Received: from web21005.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web21005.mail.yahoo.com [216.136.227.59]) id QQlphj17374 for ; Thu, 15 Nov 2001 20:59:34 GMT Message-ID: <20011115205940.20267.qmail@web21005.mail.yahoo.com> Received: from [63.67.101.6] by web21005.mail.yahoo.com via HTTP; Thu, 15 Nov 2001 12:59:40 PST Date: Thu, 15 Nov 2001 12:59:40 -0800 (PST) From: S Leung Subject: RSVP-TE draft support by Cisco and Juniper To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Anyone knows if Cisco and Juniper supports draft-ietf-mpls-rsvp-lsp-tunnel-09.txt? If yes, in which software release? Mainly interested in Section 2.3 (Service Classes), the Null Service (which replaces the COS service as described in draft-07). Any of their releases still support the COS service SENDER_TSPEC and FLOWSPEC objects? Thanks, S. Leung __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com From owner-mpls@UU.NET Thu Nov 15 16:38:39 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22498 for ; Thu, 15 Nov 2001 16:38:39 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlphm01698; Thu, 15 Nov 2001 21:35:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQlphm03022 for mpls-outgoing; Thu, 15 Nov 2001 21:35:47 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlphm03013 for ; Thu, 15 Nov 2001 21:35:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlphm14915 for ; Thu, 15 Nov 2001 21:35:12 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 QQlphm13929 for ; Thu, 15 Nov 2001 21:35:05 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fAFLYoU02559; Thu, 15 Nov 2001 16:34:50 -0500 (EST) Date: Thu, 15 Nov 2001 16:34:50 -0500 (EST) From: Scott Bradner Message-Id: <200111152134.fAFLYoU02559@newdev.harvard.edu> To: David.Charlap@marconi.com, mpls@UU.NET Subject: Re: Protocol Action: MPLS Support of Differentiated Services toProposed Standard Sender: owner-mpls@UU.NET Precedence: bulk > So do we have IANA-assigned numbers for the DIFFSERV RSVP object yet? the IANA makes teh assignments during the RFC publication process Scott From owner-mpls@UU.NET Thu Nov 15 19:06:10 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28796 for ; Thu, 15 Nov 2001 19:06:09 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlphw11120; Fri, 16 Nov 2001 00:03:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQlphw03861 for mpls-outgoing; Fri, 16 Nov 2001 00:03:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlphw03856 for ; Fri, 16 Nov 2001 00:03: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 QQlphw05079 for ; Fri, 16 Nov 2001 00:02:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlphw09332 for ; Fri, 16 Nov 2001 00:01:50 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA02012 for ; Thu, 15 Nov 2001 19:02:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA05510 for mpls@uu.net; Thu, 15 Nov 2001 19:02:01 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlphw27577 for ; Fri, 16 Nov 2001 00:01: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 QQlphw00435 for ; Fri, 16 Nov 2001 00:00:29 GMT Received: from web13506.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13506.mail.yahoo.com [216.136.175.85]) id QQlphw07208 for ; Fri, 16 Nov 2001 00:00:32 GMT Message-ID: <20011116000028.50537.qmail@web13506.mail.yahoo.com> Received: from [63.67.101.6] by web13506.mail.yahoo.com via HTTP; Thu, 15 Nov 2001 16:00:28 PST Date: Thu, 15 Nov 2001 16:00:28 -0800 (PST) From: Vishal M Subject: Why LSR need to know of EXP<->PSC maps in MPLS DiffServ model To: mpls@UU.NET Cc: te-wg@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, This is quite a basic question on on MPLS Support of Diff Serv (draft-ietf-mpls-diff-ext-09.txt). The draft talks about having EXP<=>PHB mappings on all the LSRs a LSP passes through. I understand the need for having PSC mapping to EXP on the ingress LER. i.e. an ingress LER that converts IP to MPLS would have to use the IP DSCP bits to generate MPLS EXP bits. Consider a core LSR (acting as transit for LSP), why does it need to know about the PSCs (i.e. mapping EXP<=>PSC) ? It could possibly make all the decisions about internal scheduling etc based on EXP bits on the incoming MPLS packets. Could someone please clarify this. Thanks a lot for your time, Regards, Vishal. __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com From owner-mpls@UU.NET Thu Nov 15 23:21:01 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05595 for ; Thu, 15 Nov 2001 23:21:01 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpin04070; Fri, 16 Nov 2001 04:19:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpin24971 for mpls-outgoing; Fri, 16 Nov 2001 04:19:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpin24961 for ; Fri, 16 Nov 2001 04:19:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpin20115 for ; Fri, 16 Nov 2001 04:19:08 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlpin03588 for ; Fri, 16 Nov 2001 04:19:12 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA15695 for ; Thu, 15 Nov 2001 23:19:08 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA16540 for mpls@uu.net; Thu, 15 Nov 2001 23:19:08 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpin24853 for ; Fri, 16 Nov 2001 04:17:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpin13614 for ; Fri, 16 Nov 2001 04:15:46 GMT Received: from web13507.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13507.mail.yahoo.com [216.136.175.86]) id QQlpin27803 for ; Fri, 16 Nov 2001 04:15:39 GMT Message-ID: <20011116041546.20908.qmail@web13507.mail.yahoo.com> Received: from [63.67.101.5] by web13507.mail.yahoo.com via HTTP; Thu, 15 Nov 2001 20:15:46 PST Date: Thu, 15 Nov 2001 20:15:46 -0800 (PST) From: Vishal M Subject: Re: LSR and EXP<->PSC maps To: mpls@UU.NET Cc: te-wg@ops.ietf.org In-Reply-To: <20011116000028.50537.qmail@web13506.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Perhaps I should re-phrase my question: The packet is classified by the ingress LER and EXP bits are marked. IP packet is prefixed with MPLS shim header and forwarded in the MPLS cloud. Questions: ========== Why do we need to propagate (or signal) EXP<=>PHB mapping to the core-LSRs ? Why can't the core LSRs do the scheduling just based on the EXP bits ? What additional functionality does the PHBID serve at the core-LSRs? Could someone pls help... Thanks, Vishal. --- Vishal M wrote: > > Hi, > > This is quite a basic question on on MPLS Support of > Diff Serv (draft-ietf-mpls-diff-ext-09.txt). > > The draft talks about having EXP<=>PHB mappings on > all > the LSRs a LSP passes through. > > I understand the need for having PSC mapping to EXP > on > the ingress LER. i.e. an ingress LER that converts > IP > to MPLS would have to use the IP DSCP bits to > generate > MPLS EXP bits. > > Consider a core LSR (acting as transit for LSP), why > does it need to know about the PSCs (i.e. mapping > EXP<=>PSC) ? > > It could possibly make all the decisions about > internal scheduling etc based on EXP bits on the > incoming MPLS packets. > > Could someone please clarify this. > > Thanks a lot for your time, > > Regards, > Vishal. > > > __________________________________________________ > Do You Yahoo!? > Find the one for you at Yahoo! Personals > http://personals.yahoo.com __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com From owner-mpls@UU.NET Fri Nov 16 01:17:49 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09034 for ; Fri, 16 Nov 2001 01:17:49 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpiv14275; Fri, 16 Nov 2001 06:17:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpiv11948 for mpls-outgoing; Fri, 16 Nov 2001 06:16:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpiv11943 for ; Fri, 16 Nov 2001 06:16: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 QQlpiu15392 for ; Fri, 16 Nov 2001 06:14: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 QQlpiu16555 for ; Fri, 16 Nov 2001 06:14:30 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 16 Nov 2001 11:57:22 +0530 Received: from abdulmk (abdulmk.future.futsoft.com [10.4.8.10]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id fAG68pB26489; Fri, 16 Nov 2001 11:38:52 +0530 From: "Abdul Malick" To: Cc: Subject: RE: LSR and EXP<->PSC maps Date: Fri, 16 Nov 2001 11:35:32 +0530 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Vishal, I assume we are talking about E-LSP. If you look at the EXP, it has only 3 bits and hence an E-LSP can carry only upto 8 PHBs. But we already have 14 PHBs that are commonly used (1 EF, 12 AFs, 1 BE) and theoratically speaking we can have more. Hence by limiting the scope of the EXP-> PHB to only an E-LSP under consideration, we can support more PHBs using more than one E-LSP. Since the mapping of EXP to PHB is local and sigificant only to one E-LSP, the mapping has to be signalled along with the E-LSP. In the core LSRs this mapping (maintained per E-LSP label conext) is used to map the EXP bits to a particular PHB. This mapping could therefore be different for different E-LSPs. Please correct me if i am wrong. Hope this helps. Regards, Malick -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Vishal M Sent: Friday, 16 November 2001 9:46 AM To: mpls@uu.net Cc: te-wg@ops.ietf.org Subject: Re: LSR and EXP<->PSC maps Perhaps I should re-phrase my question: The packet is classified by the ingress LER and EXP bits are marked. IP packet is prefixed with MPLS shim header and forwarded in the MPLS cloud. Questions: ========== Why do we need to propagate (or signal) EXP<=>PHB mapping to the core-LSRs ? Why can't the core LSRs do the scheduling just based on the EXP bits ? What additional functionality does the PHBID serve at the core-LSRs? Could someone pls help... Thanks, Vishal. --- Vishal M wrote: > > Hi, > > This is quite a basic question on on MPLS Support of > Diff Serv (draft-ietf-mpls-diff-ext-09.txt). > > The draft talks about having EXP<=>PHB mappings on > all > the LSRs a LSP passes through. > > I understand the need for having PSC mapping to EXP > on > the ingress LER. i.e. an ingress LER that converts > IP > to MPLS would have to use the IP DSCP bits to > generate > MPLS EXP bits. > > Consider a core LSR (acting as transit for LSP), why > does it need to know about the PSCs (i.e. mapping > EXP<=>PSC) ? > > It could possibly make all the decisions about > internal scheduling etc based on EXP bits on the > incoming MPLS packets. > > Could someone please clarify this. > > Thanks a lot for your time, > > Regards, > Vishal. > > > __________________________________________________ > Do You Yahoo!? > Find the one for you at Yahoo! Personals > http://personals.yahoo.com __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com From owner-mpls@UU.NET Fri Nov 16 03:44:35 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24266 for ; Fri, 16 Nov 2001 03:44:35 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpje00678; Fri, 16 Nov 2001 08:43:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpje00837 for mpls-outgoing; Fri, 16 Nov 2001 08:43:45 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpje00830 for ; Fri, 16 Nov 2001 08:43:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpje12596 for ; Fri, 16 Nov 2001 08:43:13 GMT Received: from mailFA11.rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.54.124.145]) id QQlpje29497 for ; Fri, 16 Nov 2001 08:43:04 GMT Received: (qmail 25383 invoked by uid 510); 16 Nov 2001 08:43:18 -0000 Date: 16 Nov 2001 08:43:18 -0000 Message-ID: <20011116084318.25382.qmail@mailFA11.rediffmail.com> Received: from unknown (203.199.51.150) by rediffmail.com via HTTP; 16 Nov 2001 08:43:18 -0000 MIME-Version: 1.0 From: "Kanwar Deep Singh" Reply-To: "Kanwar Deep Singh" To: mpls@UU.NET Subject: Information about PHB Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA24266 Hi all, Can anyone tell me what exactly is PHB or where can i find information about PHB... ?? actually for my project I need to modify existing IGP protocol...& make the changes to work with MPLS... I'm using ns simulator for simulations.. it would be very nice if someone..tells it in refrence to NS architecture... which file in NS package to look for.....the modifications... thanks in advence, kanwar From owner-mpls@UU.NET Fri Nov 16 09:39:17 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03244 for ; Fri, 16 Nov 2001 09:39:16 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpkc28220; Fri, 16 Nov 2001 14:36:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpkc20026 for mpls-outgoing; Fri, 16 Nov 2001 14:36:23 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpkc20021 for ; Fri, 16 Nov 2001 14:36:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpkc23991 for ; Fri, 16 Nov 2001 14:35:40 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQlpkc25482 for ; Fri, 16 Nov 2001 14:35:25 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 16 Nov 2001 20:17:35 +0530 Received: from abdulmk (abdulmk.future.futsoft.com [10.4.8.10]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id fAGEYPS26939; Fri, 16 Nov 2001 20:04:27 +0530 From: "Abdul Malick" To: "Choudhury, Sanjaya" , "'mpls@UU.NET'" Subject: RE: How are the domain administrators are planning to use E-LSPs? Date: Fri, 16 Nov 2001 20:01:07 +0530 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <313680C9A886D511A06000204840E1CF8F4DDF@whq-msgusr-02.pit.comms.marconi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi! I have some basic questions related to the usage of E-LSPs. I will appreciate, if you can help me with the following questions: Q1. Is any domain administrator/service provider actually using (planning) to use the E-LSPs in their network ? In which cases, E-LSPs are more useful than L-LSPs? >> One advantage of using E-LSP, i think is the conservation of Labels. In case we know that the path taken by an LSP is capable of supporting all the required services. Then we can conserve labels by using one E-LSP to support more than one PSC (to support the required services). In case of L-LSP we will have to use one LSP for each PSC and hence waste more labels. Is that right? Q2. While deploying E-LSPs in the network, is the primary usage is limited to differentiation via the signaled DiffServ classes ? OR is there practical use for reserving (and enforcing) bandwidth for the E-LSP (per LSP / per PSC bandwidth specification) ? >> I don't know if there is a means to signal the distribution of the BW among different PSCs carried in an E-LSP. I think the present approach is to use predefined distribution (configuration). Please correct me if i am wrong. Currently, the DS-TE-requirement draft does not address the E-LSP related requirements very clearly. Should it be updated with E-LSP related requirements? Thanks, sanjay From owner-mpls@UU.NET Fri Nov 16 11:46:36 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09757 for ; Fri, 16 Nov 2001 11:46:36 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpkk14755; Fri, 16 Nov 2001 16:44:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpkk09954 for mpls-outgoing; Fri, 16 Nov 2001 16:44:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpkk09946 for ; Fri, 16 Nov 2001 16:43:55 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpkk03787 for ; Fri, 16 Nov 2001 16:43: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 QQlpkk11774 for ; Fri, 16 Nov 2001 16:42:49 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA06867 for ; Fri, 16 Nov 2001 11:42:58 -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 LAA25494 for ; Fri, 16 Nov 2001 11:42:59 -0500 (EST) Message-ID: <3BF54258.FB4A7B8B@marconi.com> Date: Fri, 16 Nov 2001 11:44:08 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Information about PHB References: <20011116084318.25382.qmail@mailFA11.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kanwar Deep Singh wrote: > > Can anyone tell me what exactly is PHB or where can i > find information about PHB... ?? A PHB is a per-hop behavior. There are several drafts and RFCs that describe various kinds of PHB - including AF, EF, etc. Search the IETF RFC index and draft index for "PHB" and "Per Hop Behavior" and you'll find many papers on the subject. If you're looking for a description of the PHBID values used in the DiffServ extensions to RSVP-TE and CR-LDP, see RFC 2836. -- David From owner-mpls@UU.NET Fri Nov 16 14:41:09 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20826 for ; Fri, 16 Nov 2001 14:41:09 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpkw18743; Fri, 16 Nov 2001 19:38:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpkw21200 for mpls-outgoing; Fri, 16 Nov 2001 19:38:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpkw21193 for ; Fri, 16 Nov 2001 19:38: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 QQlpkw09796 for ; Fri, 16 Nov 2001 19:37:40 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: law2-f36.hotmail.com [216.32.181.36]) id QQlpkw17285 for ; Fri, 16 Nov 2001 19:37:33 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 16 Nov 2001 11:37:40 -0800 Received: from 63.104.212.3 by lw2fd.hotmail.msn.com with HTTP; Fri, 16 Nov 2001 19:37:39 GMT X-Originating-IP: [63.104.212.3] From: "Sandeep S" To: mpls@UU.NET Subject: ERO processing Date: Fri, 16 Nov 2001 19:37:39 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Nov 2001 19:37:40.0193 (UTC) FILETIME=[2725CD10:01C16ED6] Sender: owner-mpls@UU.NET Precedence: bulk As per my understanding whenever we get an ERO in PATH, the first node we should look at and find it is not a local subnet on the box we should just discard it. Is it necessary to it be a STRICT node rather than being a LOOSE. What are the possible negative parts using either one of them. -Sandeep ====== 4.3.4. Processing of the Explicit Route Object 4.3.4.1. Selection of the Next Hop 1) The node receiving the RSVP message MUST first evaluate the first subobject. If the node is not part of the abstract node described by the first subobject, it has received the message in error and SHOULD return a "Bad initial subobject" error. If there is no first subobject, the message is also in error and the system SHOULD return a "Bad EXPLICIT_ROUTE object" error. 6) Finally, the node replaces the first subobject with any subobject that denotes an abstract node containing the next hop. This is necessary so that when the explicit route is received by the next hop, it will be accepted. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mpls@UU.NET Fri Nov 16 15:02:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22957 for ; Fri, 16 Nov 2001 15:02:00 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpkx13188; Fri, 16 Nov 2001 19:59:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpkx22535 for mpls-outgoing; Fri, 16 Nov 2001 19:58:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpkx22526 for ; Fri, 16 Nov 2001 19:58:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpkx26114 for ; Fri, 16 Nov 2001 19:58:11 GMT Received: from calliope1.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns01.fm.intel.com [132.233.247.10]) id QQlpkx01697 for ; Fri, 16 Nov 2001 19:57:57 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id TAA26092 for ; Fri, 16 Nov 2001 19:58:08 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001111611585004966 ; Fri, 16 Nov 2001 11:58:50 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Nov 2001 11:58:06 -0800 Message-ID: From: "Feng, Mark" To: "'Sandeep S'" , mpls@UU.NET Subject: RE: ERO processing Date: Fri, 16 Nov 2001 11:58:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk It doesn't matter whether the type is loose or strict. I don't quite understand what the second half of the question is. - Mark > -----Original Message----- > From: Sandeep S [mailto:san_101@hotmail.com] > Sent: Friday, November 16, 2001 11:38 AM > To: mpls@UU.NET > Subject: ERO processing > > > As per my understanding whenever we get an ERO in PATH, the first node > we should look at and find it is not a local subnet on the > box we should > just discard it. > > Is it necessary to it be a STRICT node rather than being a > LOOSE. What are > the possible negative parts using either one of them. > > -Sandeep > > ====== > 4.3.4. Processing of the Explicit Route Object > > 4.3.4.1. Selection of the Next Hop > > 1) The node receiving the RSVP message MUST first evaluate > the first > subobject. If the node is not part of the abstract node > described by > the first subobject, it has received the message in error > and SHOULD > return a "Bad initial subobject" error. If there is no first > subobject, the message is also in error and the system > SHOULD return a > "Bad EXPLICIT_ROUTE object" error. > > 6) Finally, the node replaces the first subobject with any > subobject > that denotes an abstract node containing the next hop. This is > necessary so that when the explicit route is received by the next > hop, it will be accepted. > > > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > From owner-mpls@UU.NET Fri Nov 16 23:04:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04572 for ; Fri, 16 Nov 2001 23:04:20 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpme21193; Sat, 17 Nov 2001 04:03:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpme12198 for mpls-outgoing; Sat, 17 Nov 2001 04:02:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpme12100 for ; Sat, 17 Nov 2001 04:02: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 QQlpme21134 for ; Sat, 17 Nov 2001 04:01:01 GMT Received: from mailFA8.rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.54.124.153]) id QQlpme17737 for ; Sat, 17 Nov 2001 04:00:52 GMT Received: (qmail 17000 invoked by uid 510); 17 Nov 2001 04:01:25 -0000 Date: 17 Nov 2001 04:01:25 -0000 Message-ID: <20011117040125.16999.qmail@mailFA8.rediffmail.com> Received: from unknown (203.129.233.98) by rediffmail.com via HTTP; 17 Nov 2001 04:01:24 -0000 MIME-Version: 1.0 From: "Kanwar Deep Singh" Reply-To: "Kanwar Deep Singh" To: mpls@UU.NET Subject: Interfacing of Routing table & MPLS table..?? Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA04572 Hi ns-users, I'm working on implementing MPLS over present IGP routing protocols. I want to smulate it on ns but I'm not getting exact file from where to start. It is mentioned that "Routing protocol builds routing table & LDP then uses routing table to establish label bindings." But in my case I want to know.. 1. Where is the present routing table configured in ns package. (it is mentioned in manual it uses Dijkstra's Algo for static& Belmen Ford for Dynamic routing" 2. Which is the file or code which uses this routing table & calculates Label bindings according to LDP specifications. Thanks in advance, Kanwar From owner-mpls@UU.NET Sat Nov 17 01:03:54 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06116 for ; Sat, 17 Nov 2001 01:03:54 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpmm09104; Sat, 17 Nov 2001 06:03:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpmm29334 for mpls-outgoing; Sat, 17 Nov 2001 06:03:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpmm29325 for ; Sat, 17 Nov 2001 06:02:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpml03823 for ; Sat, 17 Nov 2001 05:59:18 GMT Received: from web14707.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14707.mail.yahoo.com [216.136.224.124]) id QQlpml03455 for ; Sat, 17 Nov 2001 05:59:10 GMT Message-ID: <20011117055917.5009.qmail@web14707.mail.yahoo.com> Received: from [203.200.15.20] by web14707.mail.yahoo.com via HTTP; Fri, 16 Nov 2001 21:59:17 PST Date: Fri, 16 Nov 2001 21:59:17 -0800 (PST) From: pradeep n Subject: reg:VoMPLS To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hello .*, What are the benefits of VoMPLS v/s VoATM. Give me more details. I have gone thru the imple aggrement. mpls forum. I need more details on VoMPLS, where can i get it. Plz do mail me asap. Pradeep-srinath __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com From owner-mpls@UU.NET Sat Nov 17 20:11:18 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01292 for ; Sat, 17 Nov 2001 20:11:18 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlppk04283; Sun, 18 Nov 2001 01:10:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQlppk05064 for mpls-outgoing; Sun, 18 Nov 2001 01:10:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlppk05013 for ; Sun, 18 Nov 2001 01:09:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlppk17187 for ; Sun, 18 Nov 2001 01:08:56 GMT Received: from uni03mr.unity.ncsu.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uni03mr.unity.ncsu.edu [152.1.1.166]) id QQlppk28025 for ; Sun, 18 Nov 2001 01:08:44 GMT Received: from unity.ncsu.edu (n00120-104afc.unity.ncsu.edu [152.1.162.59]) by uni03mr.unity.ncsu.edu (8.8.8/8.8.8/UR01Feb99) with ESMTP id UAA10605 for ; Sat, 17 Nov 2001 20:08:50 -0500 (EST) Message-ID: <3BF70A22.F0376EB@unity.ncsu.edu> Date: Sat, 17 Nov 2001 20:08:50 -0500 From: Akshay Adhikari Organization: NC State University X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: question: draft-many-optical-restoration Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have a a few questions about draft-many-optical-restoration. 1. The draft says that when a unidirectional failure is detected, a notification message is sent from the source of the failure to the ingress and egress nodes. If the provisioned strategy is used, the ingress only has to reconfigure its OXC to use a different outgoing interface (theoutgoing interface for the backup lightpath) instead of the current one (the outgoing interface for the primary path). Similarly, the egress also has to configure its outgoing interface upon receiving the failure notification message. Why does the egress have to configure its outgoing interface? I am not very familiar with GMPLS, but I think this is because of the assumption that lightpaths are bidirectional. Is this correct? 2. Is it correct that for the provisioned case, the rest of of the OXCs along the backup path (except the ingress) are already configured (while setting up the primary lightpath), so that a lightpath create message is not required to establish the backup path upon failure? 3. Therefore, if we consider unidirectional lightpaths in the provisioned case, then the ingress does not need to inform the egress that it has swithced to the backup path, (which it does currently by a notification message sent to the egress after it has reconfigured its outgoing interface). Thus, the signaling that is needed is only a). Node which detects failure sends failure notification to ingress and egress of each failed lightpath. b). Upon receiving the failure notification, the ingress simply reconfigures itself to send data out the backup lightpath. There wont be a need for the ingress to send a notification to the egress, and vice versa. Is this correct? TIA, akshay From owner-mpls@UU.NET Mon Nov 19 08:26:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26622 for ; Mon, 19 Nov 2001 08:26:42 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpuz08702; Mon, 19 Nov 2001 13:25:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpuz14975 for mpls-outgoing; Mon, 19 Nov 2001 13:25:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpuz14970 for ; Mon, 19 Nov 2001 13:25:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpuz26705 for ; Mon, 19 Nov 2001 13:25:20 GMT Received: from albatross-ext.wise.edt.ericsson.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [194.237.142.116]) id QQlpuz22725 for ; Mon, 19 Nov 2001 13:25:06 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 fAJDPEf03262 for ; Mon, 19 Nov 2001 14:25:14 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Nov 19 14:25:00 2001 +0100 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Nov 2001 14:26:47 +0100 Message-ID: From: "Roberto Mameli (ERI)" To: "'Abdul Malick'" , "Choudhury, Sanjaya" , "'mpls@UU.NET'" Subject: RE: How are the domain administrators are planning to use E-LSPs? Date: Mon, 19 Nov 2001 14:24:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Sanjay and Abdul, in my opinion there are a lot of possible scenarios in which E-LSP are useful... some of them are described in appendix A of draft-ietf-mpls-diff-ext-09.txt (see e.g. scenario 3). Just to add another example consider a provider running only a couple of BAs (e.g. a premium and a standard class of service) that would like to traffic engineer its network. He could be simply interested in fair distribution of traffic at the purpose of avoiding congestion and increase efficiency, without the additional complexity of per-class routing and per-class protection/restoration functionality. In this case E-LSP is the right solution; it provides all the functionality requested in this scenario and also allows label space saving (as Abdul correctly states). As far as per-PSC BW requirements signaling concerns, the standard currently doesn't cover this issue. In my opinion this represents an inconsistency. Just consider that the Class-Type proposed to reduce IGP flooding is not compatible with E-LSP (unless you find a way to signal BW per-PSC). A proposal in the direction of filling this gap is given in: http://www.ietf.org/internet-drafts/draft-iovanna-rsvp-mpls-flowspec-00.txt Hope it helps Regards, Roberto > -----Original Message----- > From: Abdul Malick [mailto:abdulmk@future.futsoft.com] > Sent: Friday, November 16, 2001 3:31 PM > To: Choudhury, Sanjaya; 'mpls@UU.NET' > Subject: RE: How are the domain administrators are planning to use > E-LSPs? > > Hi! I have some basic questions related to the usage of E-LSPs. > I will appreciate, if you can help me with the > following questions: > > Q1. Is any domain administrator/service provider actually using > (planning) to use the E-LSPs in their network ? In which cases, > E-LSPs are more useful than L-LSPs? > > > >> One advantage of using E-LSP, i think is the > conservation of Labels. In > case we know that the path taken by an LSP is capable of > supporting all the > required services. Then we can conserve labels by using one > E-LSP to support > more than one PSC (to support the required services). In case > of L-LSP we > will have to use one LSP for each PSC and hence waste more > labels. Is that > right? > > Q2. While deploying E-LSPs in the network, is the primary usage > is limited to differentiation via the signaled DiffServ > classes ? > > OR is there practical use for reserving (and enforcing) > bandwidth > for the E-LSP (per LSP / per PSC bandwidth specification) ? > > >> I don't know if there is a means to signal the > distribution of the BW > among different PSCs carried in an E-LSP. I think the present > approach is to > use predefined distribution (configuration). Please correct me if i am > wrong. > > > > > Currently, the DS-TE-requirement draft does not address the > E-LSP related requirements very clearly. Should it be updated > with E-LSP related requirements? > > Thanks, > sanjay From owner-mpls@UU.NET Mon Nov 19 08:41:12 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27960 for ; Mon, 19 Nov 2001 08:41:12 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpva10596; Mon, 19 Nov 2001 13:40:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpva16057 for mpls-outgoing; Mon, 19 Nov 2001 13:40:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpva16052 for ; Mon, 19 Nov 2001 13:40:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpva08619 for ; Mon, 19 Nov 2001 13:40:00 GMT Received: from mel.alcatel.fr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mel.alcatel.fr [212.208.74.132]) id QQlpva19993 for ; Mon, 19 Nov 2001 13:39:50 GMT Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (8.11.6/8.11.6/ALCANET/MAIL2 2001) with ESMTP id fAJDdxQ02692 for ; Mon, 19 Nov 2001 14:39:59 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id OAA10486 for ; Mon, 19 Nov 2001 14:39:32 +0100 (MET) Received: from athos.dinsunnet ([188.9.12.98]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id OAA20996 for ; Mon, 19 Nov 2001 14:39:09 +0100 (MET) Received: from p50669 by athos.dinsunnet (8.9.1b+Sun/SMI-SVR4) id OAA13501; Mon, 19 Nov 2001 14:39:39 +0100 (MET) Message-ID: <023c01c170ff$50094240$caf609bc@p50669> From: "Yacine El Mghazli" To: References: Subject: LSR MIB : InSegmentXCIndex read-only ? Date: Mon, 19 Nov 2001 14:37:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, In the LSR MIB, according to the lattest draft, why is the MAX-ACCESS of the mplsInSegmentXCIndex (and also the OutSegmentXCIndex) set to "read-only" ? In other words : who links an XC entry with an In(/Out)Segment entry... since it's not the SNMP manager ? thanks in advance, Yacine From owner-mpls@UU.NET Mon Nov 19 09:20:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00059 for ; Mon, 19 Nov 2001 09:20:22 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpvd18484; Mon, 19 Nov 2001 14:19:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpvd08495 for mpls-outgoing; Mon, 19 Nov 2001 14:19:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpvd08490 for ; Mon, 19 Nov 2001 14:19:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpvd06156 for ; Mon, 19 Nov 2001 14:16:18 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQlpvd13526 for ; Mon, 19 Nov 2001 14:16:07 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 19 Nov 2001 19:59:05 +0530 Received: from abdulmk (abdulmk.future.futsoft.com [10.4.8.10]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id fAJEFuB15784; Mon, 19 Nov 2001 19:45:56 +0530 From: "Abdul Malick" To: "Roberto Mameli \(ERI\)" , "Choudhury, Sanjaya" , Subject: RE: How are the domain administrators are planning to use E-LSPs? Date: Mon, 19 Nov 2001 19:42:45 +0530 Message-Id: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Roberto, Thanks for your reply. The following draft released by Nabil Seddigh & others discusses about signaling BW per OA / PSC for E-LSP. Hope its of some help to you. http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv-elsp-00.txt Regards, Malick. -----Original Message----- From: Roberto Mameli (ERI) [mailto:Roberto.Mameli@eri.ericsson.se] Sent: Monday, 19 November 2001 6:55 PM To: 'Abdul Malick'; Choudhury, Sanjaya; 'mpls@UU.NET' Subject: RE: How are the domain administrators are planning to use E-LSPs? Sanjay and Abdul, in my opinion there are a lot of possible scenarios in which E-LSP are useful... some of them are described in appendix A of draft-ietf-mpls-diff-ext-09.txt (see e.g. scenario 3). Just to add another example consider a provider running only a couple of BAs (e.g. a premium and a standard class of service) that would like to traffic engineer its network. He could be simply interested in fair distribution of traffic at the purpose of avoiding congestion and increase efficiency, without the additional complexity of per-class routing and per-class protection/restoration functionality. In this case E-LSP is the right solution; it provides all the functionality requested in this scenario and also allows label space saving (as Abdul correctly states). As far as per-PSC BW requirements signaling concerns, the standard currently doesn't cover this issue. In my opinion this represents an inconsistency. Just consider that the Class-Type proposed to reduce IGP flooding is not compatible with E-LSP (unless you find a way to signal BW per-PSC). A proposal in the direction of filling this gap is given in: http://www.ietf.org/internet-drafts/draft-iovanna-rsvp-mpls-flowspec-00.txt Hope it helps Regards, Roberto > -----Original Message----- > From: Abdul Malick [mailto:abdulmk@future.futsoft.com] > Sent: Friday, November 16, 2001 3:31 PM > To: Choudhury, Sanjaya; 'mpls@UU.NET' > Subject: RE: How are the domain administrators are planning to use > E-LSPs? > > Hi! I have some basic questions related to the usage of E-LSPs. > I will appreciate, if you can help me with the > following questions: > > Q1. Is any domain administrator/service provider actually using > (planning) to use the E-LSPs in their network ? In which cases, > E-LSPs are more useful than L-LSPs? > > > >> One advantage of using E-LSP, i think is the > conservation of Labels. In > case we know that the path taken by an LSP is capable of > supporting all the > required services. Then we can conserve labels by using one > E-LSP to support > more than one PSC (to support the required services). In case > of L-LSP we > will have to use one LSP for each PSC and hence waste more > labels. Is that > right? > > Q2. While deploying E-LSPs in the network, is the primary usage > is limited to differentiation via the signaled DiffServ > classes ? > > OR is there practical use for reserving (and enforcing) > bandwidth > for the E-LSP (per LSP / per PSC bandwidth specification) ? > > >> I don't know if there is a means to signal the > distribution of the BW > among different PSCs carried in an E-LSP. I think the present > approach is to > use predefined distribution (configuration). Please correct me if i am > wrong. > > > > > Currently, the DS-TE-requirement draft does not address the > E-LSP related requirements very clearly. Should it be updated > with E-LSP related requirements? > > Thanks, > sanjay From owner-mpls@UU.NET Mon Nov 19 09:28:24 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00577 for ; Mon, 19 Nov 2001 09:28:23 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpvd29421; Mon, 19 Nov 2001 14:26:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpvd09023 for mpls-outgoing; Mon, 19 Nov 2001 14:26:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpvd09016 for ; Mon, 19 Nov 2001 14:26:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpvd09467 for ; Mon, 19 Nov 2001 14:26:04 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlpvd02384 for ; Mon, 19 Nov 2001 14:25:54 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA26214 for ; Mon, 19 Nov 2001 09:26:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20831 for mpls@uu.net; Mon, 19 Nov 2001 09:26:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpnl00169 for ; Sat, 17 Nov 2001 12:19:14 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 QQlpnl25618 for ; Sat, 17 Nov 2001 12:18:50 GMT Received: from moutvdom01.kundenserver.de by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: moutvdom01.kundenserver.de [195.20.224.200]) id QQlpnl17836 for ; Sat, 17 Nov 2001 12:18:41 GMT Received: from [195.20.224.204] (helo=mrvdom00.schlund.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2) id 1654Qq-0004OO-00 for mpls@uu.net; Sat, 17 Nov 2001 13:18:48 +0100 Received: from p3ee1f2d0.dip0.t-ipconnect.de ([62.225.242.208] helo=amadeus.hhagg.de) by mrvdom00.schlund.de with esmtp (Exim 2.12 #2) id 1654Qq-0002kp-00 for mpls@uu.net; Sat, 17 Nov 2001 13:18:48 +0100 Received: (qmail 6442 invoked from network); 17 Nov 2001 12:20:07 -0000 Received: from unknown (HELO bartleby) (192.168.1.100) by 192.168.1.253 with SMTP; 17 Nov 2001 12:20:07 -0000 From: "Hanspeter Hagg" To: Subject: MPLS UML-Model Date: Sat, 17 Nov 2001 13:18:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi folks! I am a student writing a diploma thesis about MPLS. Concentrating especially on the management aspect. The goal is to find some data for optimizing an MPLS cloud. There are questions like: 'Can i associate a label counter with a specific flow?', that need to be answered. My first step was to create an information and communication model of the MPLS architecture. I am sending a link of a gif-image with the current status of my work whithin this mail. http://www.hhagg.de/mpls/mpls_model.gif Please feel free to comment and criticize the model. I need to know if I am on the right track. Thanx ------------------------------------------------------------ tel: +49 (0)89 5429 0959 - address: Luisenstr. 49/I fax: +49 (0)89 5231 4864 - 80333 Munich, Germany mobile: +49 (0)179 135 4906 - www: http://www.hhagg.de ------------------------------------------------------------ From owner-mpls@UU.NET Mon Nov 19 09:42:36 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01513 for ; Mon, 19 Nov 2001 09:42:36 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpve04132; Mon, 19 Nov 2001 14:40:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpve10204 for mpls-outgoing; Mon, 19 Nov 2001 14:40:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpve10197 for ; Mon, 19 Nov 2001 14:40:19 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 QQlpve09287 for ; Mon, 19 Nov 2001 14:38:59 GMT Received: from mel.alcatel.fr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mel.alcatel.fr [212.208.74.132]) id QQlpve00890 for ; Mon, 19 Nov 2001 14:39:03 GMT Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (8.11.6/8.11.6/ALCANET/MAIL2 2001) with ESMTP id fAJEcuQ11646; Mon, 19 Nov 2001 15:38:58 +0100 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id PAA11441; Mon, 19 Nov 2001 15:38:39 +0100 (MET) Received: from athos.dinsunnet ([188.9.12.98]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id PAA25476; Mon, 19 Nov 2001 15:38:09 +0100 (MET) Received: from p50669 by athos.dinsunnet (8.9.1b+Sun/SMI-SVR4) id PAA15398; Mon, 19 Nov 2001 15:38:39 +0100 (MET) Message-ID: <02aa01c17107$8e650760$caf609bc@p50669> From: "Yacine El Mghazli" To: "phani R" Cc: References: <20011119140811.91916.qmail@web11402.mail.yahoo.com> Subject: Re: LSR MIB : InSegmentXCIndex read-only ? Date: Mon, 19 Nov 2001 15:36:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit thanks for your reply phani, but unfortunately, it's not so clear for me... the manager can create XC entries, InSegment and OutSegment entries (read-create MAX-ACCESS, except the In(/Out)SegmentXCIndex column)... but it cannot link them together ! according to your previous email, the MPLS forwarder/controller is responsible for linking these, but how do it choose which XC entry to link to such In(/Out)Segment entry (among those which have been created by the manager) ? why cannot the manager set XCindex also ? be sure I don't think you're wrong... tell me please what is the point I misunderstand :-( thanks, yacine > Good day, > The MPLS forwarder/controller maintaining the > Fib would link the XC entry with the corresponding > in-segment/out-segment during the creation for that > entry /row. > > Thanks > Phani.R > --- Yacine El Mghazli > wrote: > Hi all, > > > > In the LSR MIB, according to the lattest draft, why > > is the MAX-ACCESS of the > > mplsInSegmentXCIndex (and also the > > OutSegmentXCIndex) set to "read-only" ? > > In other words : who links an XC entry with an > > In(/Out)Segment entry... > > since it's not the SNMP manager ? > > > > thanks in advance, > > Yacine > > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page from News and Sport to Email and Music Charts > http://uk.my.yahoo.com From owner-mpls@UU.NET Mon Nov 19 10:00:30 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02613 for ; Mon, 19 Nov 2001 10:00:30 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpvf03601; Mon, 19 Nov 2001 14:57:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpvf11551 for mpls-outgoing; Mon, 19 Nov 2001 14:56:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpvf11538 for ; Mon, 19 Nov 2001 14:56:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpvf17390 for ; Mon, 19 Nov 2001 14:54:13 GMT Received: from albatross-ext.wise.edt.ericsson.se by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [194.237.142.116]) id QQlpvf12593 for ; Mon, 19 Nov 2001 14:53:56 GMT Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fAJEs8f21435 for ; Mon, 19 Nov 2001 15:54:08 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Mon Nov 19 15:54:06 2001 +0100 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Nov 2001 15:55:40 +0100 Message-ID: From: "Paola Iovanna (ERI)" To: "'Abdul Malick'" , mpls@UU.NET Subject: RE: How are the domain administrators planning to use E-LSPs? Date: Mon, 19 Nov 2001 15:53:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA02613 Hi Malick, the draft pointed by Roberto in the previous mail proposes a more general solution with respect to the one you are referring to. It introduces the extension of Tspec (FlowSpec) for MPLS scenario. This approach allows preserving the functionality of the Sender_Tspec (FlowSpec), without introducing a specific object for E-LSP. In fact the MPLS Flow-Spec can be used for both E-LSP and L-LSP, and even for QoS over MPLS scenarios other than DiffServ. Regards Paola -----Original Message----- From: Abdul Malick [mailto:abdulmk@future.futsoft.com] Sent: lunedì 19 novembre 2001 15.13 To: Roberto Mameli (ERI); Choudhury, Sanjaya; mpls@UU.NET Subject: RE: How are the domain administrators are planning to use E-LSPs? Hello Roberto, Thanks for your reply. The following draft released by Nabil Seddigh & others discusses about signaling BW per OA / PSC for E-LSP. Hope its of some help to you. http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv-elsp-00.txt Regards, Malick. -----Original Message----- From: Roberto Mameli (ERI) [mailto:Roberto.Mameli@eri.ericsson.se] Sent: Monday, 19 November 2001 6:55 PM To: 'Abdul Malick'; Choudhury, Sanjaya; 'mpls@UU.NET' Subject: RE: How are the domain administrators are planning to use E-LSPs? Sanjay and Abdul, in my opinion there are a lot of possible scenarios in which E-LSP are useful... some of them are described in appendix A of draft-ietf-mpls-diff-ext-09.txt (see e.g. scenario 3). Just to add another example consider a provider running only a couple of BAs (e.g. a premium and a standard class of service) that would like to traffic engineer its network. He could be simply interested in fair distribution of traffic at the purpose of avoiding congestion and increase efficiency, without the additional complexity of per-class routing and per-class protection/restoration functionality. In this case E-LSP is the right solution; it provides all the functionality requested in this scenario and also allows label space saving (as Abdul correctly states). As far as per-PSC BW requirements signaling concerns, the standard currently doesn't cover this issue. In my opinion this represents an inconsistency. Just consider that the Class-Type proposed to reduce IGP flooding is not compatible with E-LSP (unless you find a way to signal BW per-PSC). A proposal in the direction of filling this gap is given in: http://www.ietf.org/internet-drafts/draft-iovanna-rsvp-mpls-flowspec-00.txt Hope it helps Regards, Roberto > -----Original Message----- > From: Abdul Malick [mailto:abdulmk@future.futsoft.com] > Sent: Friday, November 16, 2001 3:31 PM > To: Choudhury, Sanjaya; 'mpls@UU.NET' > Subject: RE: How are the domain administrators are planning to use > E-LSPs? > > Hi! I have some basic questions related to the usage of E-LSPs. > I will appreciate, if you can help me with the > following questions: > > Q1. Is any domain administrator/service provider actually using > (planning) to use the E-LSPs in their network ? In which cases, > E-LSPs are more useful than L-LSPs? > > > >> One advantage of using E-LSP, i think is the > conservation of Labels. In > case we know that the path taken by an LSP is capable of > supporting all the > required services. Then we can conserve labels by using one > E-LSP to support > more than one PSC (to support the required services). In case > of L-LSP we > will have to use one LSP for each PSC and hence waste more > labels. Is that > right? > > Q2. While deploying E-LSPs in the network, is the primary usage > is limited to differentiation via the signaled DiffServ > classes ? > > OR is there practical use for reserving (and enforcing) > bandwidth > for the E-LSP (per LSP / per PSC bandwidth specification) ? > > >> I don't know if there is a means to signal the > distribution of the BW > among different PSCs carried in an E-LSP. I think the present > approach is to > use predefined distribution (configuration). Please correct me if i am > wrong. > > > > > Currently, the DS-TE-requirement draft does not address the > E-LSP related requirements very clearly. Should it be updated > with E-LSP related requirements? > > Thanks, > sanjay From owner-mpls@UU.NET Mon Nov 19 11:00:25 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06214 for ; Mon, 19 Nov 2001 11:00:24 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpvj24913; Mon, 19 Nov 2001 15:57:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpvj05644 for mpls-outgoing; Mon, 19 Nov 2001 15:56:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpvj05635 for ; Mon, 19 Nov 2001 15:56: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 QQlpvj16988 for ; Mon, 19 Nov 2001 15:56:03 GMT Received: from wiprom2mx2.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx2.wipro.com [203.197.164.42]) id QQlpvj22649 for ; Mon, 19 Nov 2001 15:56:06 GMT Received: from m2vwall3.wipro.com (m2vwall3.wipro.com [164.164.29.237]) by wiprom2mx2.wipro.com (8.11.3/8.11.3) with SMTP id fAJFtwT07139 for ; Mon, 19 Nov 2001 21:25:58 +0530 (IST) Received: from 192.168.2.18 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Mon, 19 Nov 2001 21:25:55 +0530 Received: from Sonal.alc.wipinfo.soft.net ([192.168.220.119]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GN21LG00.PYZ for ; Mon, 19 Nov 2001 21:26:04 +0530 Message-ID: <000701c170ed$b857b3c0$77dca8c0@Sonal.alc.wipinfo.soft.net> Reply-To: "venkat" From: "Venkat Dabbara" To: Subject: next hop change in CRLDP Date: Mon, 19 Nov 2001 21:31:23 +1000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: quoted-printable hai , This is regarding next hop change in CRLDP ( Better next hop = avalability ) . I could find some discussion happening before on this but it = wasn't satisfactory=20 Some one had asked=20 +AD4-Suppose a CRLSP is setup with no-pin option and LSR-A is=20 +AD4- part of LSP as=20 +AD4- loose hop member.=20 +AD4- When LSR-A finds better nexthop, it is supposed to taer down=20 +AD4- LSP along old=20 +AD4- path and send label request to new nexthop. For this, LSR-A=20 +AD4- has to store=20 +AD4- all the TLVs it received in CRLSP initiation request so that=20 +AD4- it can initiate=20 +AD4- request along new nexthop. Does not it imply that CR-LDP is=20 +AD4- not scalable?=20 And some one had answered it saying=20 +AD4AIg- This is not a scalability issue but a simple engineering issue, = +AD4- no-pinning with a CR-LDP loose hop is an unlikely scenario.=20 +AD4- No pinning is most appropriate with LDP. +ACI- Ruling out such a scenario doesn't seem to solve the problem ..What if = the scenario comes in ?? Surely we can react as it is being done in LDP where u just tear down = the path . Some thing of +ACI- make and break+ACI- policy should be done which = would be of some meaning rather than going for +ACI-break and make +ACI- as done in LDP where u land up tearing down the CRLSP for every better = next hop avalibility. As pointed out by some one , will it be scalable to store the list of = remaining hops present in ERTlv at every hop ??? If yes ,this would solve the purpose to some extent ... Please correct me if i am wrong. regards venkat =20 =20 --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit ------------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ---------------------------------------------------------------------------------------------------------------------- --------------InterScan_NT_MIME_Boundary-- From owner-mpls@UU.NET Mon Nov 19 11:40:56 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08680 for ; Mon, 19 Nov 2001 11:40:56 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpvm21385; Mon, 19 Nov 2001 16:37:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpvm28718 for mpls-outgoing; Mon, 19 Nov 2001 16:37:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpvm28709 for ; Mon, 19 Nov 2001 16:37:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpvm29172 for ; Mon, 19 Nov 2001 16:36:51 GMT Received: from mailrelay.laurelnetworks.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: host11.laurelnetworks.com [63.94.127.11] (may be forged)) id QQlpvm13468 for ; Mon, 19 Nov 2001 16:36:55 GMT Received: from sherlock.laurelnetworks.com (sherlock.laurelnetworks.com [10.0.0.20]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with ESMTP id LAA05599 for ; Mon, 19 Nov 2001 11:36:51 -0500 Received: by sherlock.laurelnetworks.com with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Nov 2001 11:32:20 -0500 Message-ID: <48E9CC6471FFD411B1AB00B0D079A42FE00D0D@sherlock.laurelnetworks.com> From: Ganesh Murugesan To: "'mpls@uu.net'" Cc: Ganesh Murugesan Subject: Minor question on RRO in RSVP-Te Date: Mon, 19 Nov 2001 11:32:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I had a minor question (more on the wording) in draft-ietf-mpls-rsvp-lsp-tunnel-09.txt on RROs. The draft on Page 33 says The contents of a RECORD_ROUTE object are a series of variable-length data items called subobjects. Each subobject has its own Length field. The length contains the total length of the subobject in bytes, including the Type and Length fields. The length MUST always be a multiple of 4, and at least 4. Since the three types of subobjects defined under RRO are the IPv4, IPv6 and the label recording subobjects, shouldn't the last line say strictly greater than 4, since all the three types have length greater than 4. thanks ganesh From owner-mpls@UU.NET Mon Nov 19 12:51:09 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12569 for ; Mon, 19 Nov 2001 12:51:09 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpvr04588; Mon, 19 Nov 2001 17:48:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpvr23814 for mpls-outgoing; Mon, 19 Nov 2001 17:48:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpvr23807 for ; Mon, 19 Nov 2001 17:48:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpvr03727 for ; Mon, 19 Nov 2001 17:45:35 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 QQlpvr29860 for ; Mon, 19 Nov 2001 17:45: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 MAA29925 for ; Mon, 19 Nov 2001 12:45:32 -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 MAA07505 for ; Mon, 19 Nov 2001 12:45:31 -0500 (EST) Message-ID: <3BF9458E.20601D71@marconi.com> Date: Mon, 19 Nov 2001 12:46:54 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: Minor question on RRO in RSVP-Te References: <48E9CC6471FFD411B1AB00B0D079A42FE00D0D@sherlock.laurelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ganesh Murugesan wrote: > > I had a minor question (more on the wording) in > draft-ietf-mpls-rsvp-lsp-tunnel-09.txt on RROs. > > The draft on Page 33 says > The contents of a RECORD_ROUTE object are a series of > variable-length data items called subobjects. Each subobject has its > own Length field. The length contains the total length of the > subobject in bytes, including the Type and Length fields. The length > MUST always be a multiple of 4, and at least 4. > Since the three types of subobjects defined under RRO are the IPv4, > IPv6 and the label recording subobjects, shouldn't the last line say > strictly greater than 4, since all the three types have length > greater than 4. There have been ERO/RRO subobjects in prior drafts (now expired) that were length 4 (the "LSP Termination" subobject, which was deleted fron the draft in version -05). It is possible that we may define subobjects of length 4 in the future as well. What purpose is served by changing the wording so that we are no longer free to define a new subobject of length 4? -- David From owner-mpls@UU.NET Mon Nov 19 21:07:02 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06408 for ; Mon, 19 Nov 2001 21:07:01 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpwr08119; Tue, 20 Nov 2001 00:15:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpwr07224 for mpls-outgoing; Tue, 20 Nov 2001 00:15:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpwq07127 for ; Tue, 20 Nov 2001 00:14:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpwq16490 for ; Tue, 20 Nov 2001 00:13:25 GMT Received: from [172.16.1.115] by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mdclient1.opnet.com [12.145.55.10]) id QQlpwq04970 for ; Tue, 20 Nov 2001 00:13:30 GMT Received: from wtn10216.opnet.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 19 Nov 2001 19:10:01 -0500 Message-Id: <5.0.0.25.2.20011119183844.00a86c60@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 19 Nov 2001 19:12:13 -0500 To: mpls@UU.NET From: Sachin Kalra Subject: Does LSPs signaled through Bypass Tunnel need NHLFEs on transit nodes? Cc: mpls-ops@mplsrc.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi: I have few questions about "Bypass Tunnels". Any help is appreciated. In following figure Primary LSP traverses from (R1->R2->R3->R4->R5) and Bypass tunnel from (R2->R6->R7->R8->-R4). Bypass is denoted by double lines. [R0] \ [R1]---------[R2]------------------[R3]-----------------[R4]-----------------[R5] \\ // \ \\ // \ [R6]======[R7]======[R8] [R9] If R4 is using Interface specific Label Space. (i.e. it does not use Global Label Space). Then we need to signal LSP through "Bypass Tunnel" path to obtain label assigned out of the label space used by R4 on the interface terminating the link from R8 (Which will later be used by R2 for label swapping before stacking the label for Bypass Tunnel) In this case my understanding is that once R2 has the "required label" from R4, then R6, R7, R8 do not need to maintain any state for the signaled LSP, nor do they need any NHLFEs for that LSP. Because traffic will be sent through the "Bypass Tunnel". 1. Is this correct? 2. How do we handle this scenario? 3. Does LSPs signaled through Bypass Tunnel need NHLFEs on transit nodes? Thanks for your time, Sachin Kalra From owner-mpls@UU.NET Mon Nov 19 22:42:45 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12457 for ; Mon, 19 Nov 2001 22:42:44 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpwo17265; Mon, 19 Nov 2001 23:38:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpwo15168 for mpls-outgoing; Mon, 19 Nov 2001 23:38:28 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlpwo15163 for ; Mon, 19 Nov 2001 23:38:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpwo25406 for ; Mon, 19 Nov 2001 23:37:51 GMT Received: from [172.16.1.115] by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mdclient1.opnet.com [12.145.55.10]) id QQlpwo29705 for ; Mon, 19 Nov 2001 23:37:56 GMT Received: from wtn10216.opnet.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 19 Nov 2001 18:34:25 -0500 Message-Id: <5.0.0.25.2.20011119182925.00a78240@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 19 Nov 2001 18:36:37 -0500 To: (Recipient list suppressed) From: Sachin Kalra Subject: Does Cisco and Juniper both use GLAs? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi: I would appreciate if somebody can tell me that 1. If Cisco use just Global Label Allocation (GLA) or does it also use Interface specific "Label Spaces" ? 2. If Juniper use just Global Label Allocation (GLA) or does it also use Interface specific "Label Spaces" ? 3. Is there any other vendor that use Interface specific "Label Spaces"? Thanks, Sachin Kalra From owner-mpls@UU.NET Mon Nov 19 23:25:46 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12987 for ; Mon, 19 Nov 2001 23:25:45 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpwu22026; Tue, 20 Nov 2001 01:09:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpwu00058 for mpls-outgoing; Tue, 20 Nov 2001 01:09:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpwu00052 for ; Tue, 20 Nov 2001 01:09:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpwu08509 for ; Tue, 20 Nov 2001 01:08:25 GMT Received: from morpheus.lanterncom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.161.157.68]) id QQlpwu19684 for ; Tue, 20 Nov 2001 01:08:15 GMT Received: by morpheus.lanterncom.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Nov 2001 17:06:45 -0800 Message-ID: <58BE468BAC66D511AFE6000347251A2DED425E@morpheus.lanterncom.com> From: Anoop Ghanwani To: "'Sachin Kalra'" Cc: "'mpls@uu.net'" Subject: RE: Is any Reservation done for Bypass Tunnels? Date: Mon, 19 Nov 2001 17:06:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk If you expect to provide service guarantees (bandwidth, delay, etc.) even in the event of failure, then you do need to reserve capacity. It all depends on the kind of service that the ISP is selling. -Anoop > -----Original Message----- > From: Sachin Kalra [mailto:skalra@opnet.com] > Sent: Monday, November 19, 2001 3:52 PM > To: mpls@UU.NET > Subject: Is any Reservation done for Bypass Tunnels? > > > Hi: > > Please, can somebody tell me if any reservation is done for > "Bypass Tunnels"? > > Thanks, > Sachin Kalra > From owner-mpls@UU.NET Mon Nov 19 23:59:43 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13757 for ; Mon, 19 Nov 2001 23:59:42 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpwp02280; Mon, 19 Nov 2001 23:54:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpwp16242 for mpls-outgoing; Mon, 19 Nov 2001 23:54:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpwp16234 for ; Mon, 19 Nov 2001 23:54:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpwp16720 for ; Mon, 19 Nov 2001 23:53:36 GMT Received: from [172.16.1.115] by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mdclient1.opnet.com [12.145.55.10]) id QQlpwp00838 for ; Mon, 19 Nov 2001 23:53:40 GMT Received: from wtn10216.opnet.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 19 Nov 2001 18:50:12 -0500 Message-Id: <5.0.0.25.2.20011119184641.00a83910@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 19 Nov 2001 18:52:24 -0500 To: mpls@UU.NET From: Sachin Kalra Subject: Is any Reservation done for Bypass Tunnels? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi: Please, can somebody tell me if any reservation is done for "Bypass Tunnels"? Thanks, Sachin Kalra From owner-mpls@UU.NET Tue Nov 20 02:36:21 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01471 for ; Tue, 20 Nov 2001 02:36:21 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpxu23393; Tue, 20 Nov 2001 07:34:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpxu23863 for mpls-outgoing; Tue, 20 Nov 2001 07:34:00 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpxu23857 for ; Tue, 20 Nov 2001 07:33: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 QQlpxu24099 for ; Tue, 20 Nov 2001 07:33:15 GMT Received: from itplgateway.cpqitpltech4 by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: PPP-184-4.bng.vsnl.net.in [203.197.184.4]) id QQlpxu04972 for ; Tue, 20 Nov 2001 07:32:54 GMT Received: from KRISHNAKANTH ([192.168.0.105]) by itplgateway.cpqitpltech4 with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XGWRF0HR; Tue, 20 Nov 2001 12:35:26 +0530 Message-ID: <002b01c17192$de075170$6900a8c0@CPQITPLTECH4> From: "Krishnakanth Rao" To: Subject: label distribution accros network boundaries-IP to ATM Date: Tue, 20 Nov 2001 12:43:15 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C171C0.EC5EF470" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C171C0.EC5EF470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Will we have a label distribution problem at the boundaries of IP core = and ATM core networks if we have end-to-end label label distribution = when you cross over from a IP-based MPLS network and an ATM-based MPLS = network, since in IP network with routers as the LERs/LSRs, the label is = distributed in a MPLS shim header that gets created to "frame" the IP = packet. In ATM networks, the label is the VPI/VCI values in the regular = ATM cell header.=20 What problems can occur if we send a labelled packets across the = boundry between a IP based and ATM based MPLS network. Krishnakanth ------=_NextPart_000_0028_01C171C0.EC5EF470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Will we have a label distribution problem at the = boundaries of IP core and ATM core networks if we have end-to-end label = label=20 distribution when you cross over from a IP-based MPLS network and an = ATM-based=20 MPLS network, since in IP network with routers as the LERs/LSRs, the = label is=20 distributed in a MPLS shim header that gets created to "frame" the IP = packet. In=20 ATM networks, the label is the VPI/VCI values in the regular ATM cell = header.=20
 
What  problems can occur if we send=20 a labelled packets across the boundry between a IP based and ATM = based MPLS=20 network.
 
Krishnakanth
------=_NextPart_000_0028_01C171C0.EC5EF470-- From owner-mpls@UU.NET Tue Nov 20 02:58:52 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01649 for ; Tue, 20 Nov 2001 02:58:52 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpxv04165; Tue, 20 Nov 2001 07:55:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpxv25262 for mpls-outgoing; Tue, 20 Nov 2001 07:55:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpxv25257 for ; Tue, 20 Nov 2001 07:55:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpxv13633 for ; Tue, 20 Nov 2001 07:54:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlpxv23508 for ; Tue, 20 Nov 2001 07:54:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id CAA14908 for ; Tue, 20 Nov 2001 02:54:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id CAA10751 for mpls@uu.net; Tue, 20 Nov 2001 02:54:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpxv25154 for ; Tue, 20 Nov 2001 07:52: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 QQlpxv25113 for ; Tue, 20 Nov 2001 07:52:40 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQlpxv28543 for ; Tue, 20 Nov 2001 07:52:27 GMT Received: from JVASSEUR-W2K.cisco.com (jvasseur-isdn-home.cisco.com [10.49.89.2]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA00310; Tue, 20 Nov 2001 08:50:58 +0100 (MET) Message-Id: <4.3.2.7.2.20011120084812.034e1968@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Nov 2001 08:50:29 +0100 To: Sachin Kalra From: Jean Philippe Vasseur Subject: Re: Does LSPs signaled through Bypass Tunnel need NHLFEs on transit nodes? Cc: mpls@UU.NET, mpls-ops@mplsrc.com In-Reply-To: <5.0.0.25.2.20011119183844.00a86c60@mail.opnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, At 19:12 19/11/2001 -0500, Sachin Kalra wrote: >Hi: > >I have few questions about "Bypass Tunnels". Any help is appreciated. > >In following figure Primary LSP traverses from (R1->R2->R3->R4->R5) and >Bypass tunnel from (R2->R6->R7->R8->-R4). Bypass is denoted by double lines. > > > [R0] > \ >[R1]---------[R2]------------------[R3]-----------------[R4]-----------------[R5] > > \\ // \ > \\ // \ > [R6]======[R7]======[R8] [R9] > > >If R4 is using Interface specific Label Space. (i.e. it does not use >Global Label Space). Then we need to signal LSP through "Bypass Tunnel" >path to obtain label assigned out of the label space used by R4 on the >interface terminating the link from R8 (Which will later be used by R2 for >label swapping before stacking the label for Bypass Tunnel) > >In this case my understanding is that once R2 has the "required label" >from R4, then R6, R7, R8 do not need to maintain any state for the >signaled LSP, nor do they need any NHLFEs for that LSP. Because traffic >will be sent through the "Bypass Tunnel". > >1. Is this correct? yes >2. How do we handle this scenario? see draft-manyfolks-rsvp-fastreroute-00.txt (very recently published) >3. Does LSPs signaled through Bypass Tunnel need NHLFEs on transit nodes? no. JP. >Thanks for your time, >Sachin Kalra From owner-mpls@UU.NET Tue Nov 20 03:12:35 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01810 for ; Tue, 20 Nov 2001 03:12:34 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpxw22079; Tue, 20 Nov 2001 08:09:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpxw15269 for mpls-outgoing; Tue, 20 Nov 2001 08:09:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlpxw15246 for ; Tue, 20 Nov 2001 08:09:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlpxw07785 for ; Tue, 20 Nov 2001 08:09:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlpxw20804 for ; Tue, 20 Nov 2001 08:09:06 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA15633 for ; Tue, 20 Nov 2001 03:09:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA11736 for mpls@uu.net; Tue, 20 Nov 2001 03:09:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpxw15160 for ; Tue, 20 Nov 2001 08:07:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlpxw03487 for ; Tue, 20 Nov 2001 08:07:21 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQlpxw22629 for ; Tue, 20 Nov 2001 08:07:08 GMT Received: from JVASSEUR-W2K.cisco.com (jvasseur-isdn-home.cisco.com [10.49.89.2]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA01306; Tue, 20 Nov 2001 08:56:20 +0100 (MET) Message-Id: <4.3.2.7.2.20011120085117.03dc0828@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Nov 2001 08:55:53 +0100 To: Sachin Kalra From: Jean Philippe Vasseur Subject: Re: Is any Reservation done for Bypass Tunnels? Cc: mpls@UU.NET In-Reply-To: <5.0.0.25.2.20011119184641.00a83910@mail.opnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, At 18:52 19/11/2001 -0500, Sachin Kalra wrote: >Hi: > >Please, can somebody tell me if any reservation is done for "Bypass Tunnels"? Bypass tunnel is a TE LSP so it will have bandwidth, affinities, .... properties. JP. >Thanks, >Sachin Kalra From owner-mpls@UU.NET Tue Nov 20 05:51:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03678 for ; Tue, 20 Nov 2001 05:51:42 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpyh22985; Tue, 20 Nov 2001 10:48:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpyh05457 for mpls-outgoing; Tue, 20 Nov 2001 10:48:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpyh05446 for ; Tue, 20 Nov 2001 10:48: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 QQlpyh10512 for ; Tue, 20 Nov 2001 10:46:35 GMT Received: from multitech.co.in by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQlpyh08890 for ; Tue, 20 Nov 2001 10:46:20 GMT Received: from abhay (abhay [192.168.1.136]) by multitech.co.in (8.12.1/8.12.1) with SMTP id fAKAjfdw001848; Tue, 20 Nov 2001 16:15:43 +0530 Message-ID: <002701c171b1$89a61e80$8801a8c0@multitech.co.in> From: "abhay" To: "venkat" , References: <000701c170ed$b857b3c0$77dca8c0@Sonal.alc.wipinfo.soft.net> Subject: Re: next hop change in CRLDP Date: Tue, 20 Nov 2001 16:23:02 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C171DF.A084FBC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C171DF.A084FBC0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: quoted-printable hello venkat, Yes,why not,there is no hard based rule for not storing = ER-TLV's Ref T.E MIB One reason for not doing so would be that usually = Loose hops are not directly connected. In other words the administrator does not know the = stable topology and gives it a shot by specifying the next hop to be = loose,which means the loose hop can be reached through any router.(Here = if route pinning is applied,then a better next hop is no use). =20 =20 But,to do that,your MPLS management should very very = efficient In such cases,when you might have a lot of = communication between your signaling and forwarding management. =20 Also,there arises a question,of controlling the child = like Ingress of the Initiated LSP to sustain the paths,since this is a downstream on = demand mode =20 Also,whats the used of the better next hop ?.I dont = see any good use of it,when one has a CR-LSP. I guess it more of engineering and adding an extra = rear view mirror to CR-LDP Hope this helps, Regards, Abhay ----- Original Message -----=20 From: Venkat Dabbara +ADw-venkat.dabb+AEA-wipro.com+AD4- To: +ADw-mpls+AEA-UU.NET+AD4- Sent: Monday, November 19, 2001 5:01 PM Subject: next hop change in CRLDP=20 hai , This is regarding next hop change in CRLDP ( Better next hop = avalability ) . I could find some discussion happening before on this but it = wasn't satisfactory=20 Some one had asked=20 +AD4-Suppose a CRLSP is setup with no-pin option and LSR-A is=20 +AD4- part of LSP as=20 +AD4- loose hop member.=20 +AD4- When LSR-A finds better nexthop, it is supposed to taer down=20 +AD4- LSP along old=20 +AD4- path and send label request to new nexthop. For this, LSR-A=20 +AD4- has to store=20 +AD4- all the TLVs it received in CRLSP initiation request so that=20 +AD4- it can initiate=20 +AD4- request along new nexthop. Does not it imply that CR-LDP is=20 +AD4- not scalable?=20 And some one had answered it saying=20 +AD4AIg- This is not a scalability issue but a simple engineering issue, = +AD4- no-pinning with a CR-LDP loose hop is an unlikely scenario.=20 +AD4- No pinning is most appropriate with LDP. +ACI- Ruling out such a scenario doesn't seem to solve the problem ..What if = the scenario comes in ?? Surely we can react as it is being done in LDP where u just tear down = the path . Some thing of +ACI- make and break+ACI- policy should be done which = would be of some meaning rather than going for +ACI-break and make +ACI- as done in LDP where u land up tearing down the CRLSP for every better = next hop avalibility. As pointed out by some one , will it be scalable to store the list of = remaining hops present in ERTlv at every hop ??? If yes ,this would solve the purpose to some extent ... Please correct me if i am wrong. regards venkat =20 =20 ------=_NextPart_000_0024_01C171DF.A084FBC0 Content-Type: text/html; charset="utf-7" Content-Transfer-Encoding: quoted-printable +/v8APAAh-DOCTYPE HTML PUBLIC +ACI--//W3C//DTD HTML 4.0 = Transitional//EN+ACIAPg- +ADw-HTML+AD4APA-HEAD+AD4- +ADw-META content+AD0AIg-text/html+ADs- charset+AD0-utf-7+ACI- = http-equiv+AD0-Content-Type+AD4- +ADw-META content+AD0AIg-MSHTML 5.00.2614.3500+ACI- = name+AD0-GENERATOR+AD4- +ADw-STYLE+AD4APA-/STYLE+AD4- +ADw-/HEAD+AD4- +ADw-BODY+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial size+AD0-2+AD4-hello = venkat,+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-=20 Yes,why not,there is no hard based rule for not storing = ER-TLV's+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsA= Jg-nbsp+ADsAJg-nbsp+ADs-Ref=20 T.E MIB+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial = size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- = +ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-=20 +ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- = +ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- One = reason for not doing so=20 would be that usually Loose hops+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial = size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- = +ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-=20 +ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- are not directly=20 connected.+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsA= Jg-nbsp+ADs-In=20 other words the administrator does not know the stable = topology+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsA= Jg-nbsp+ADs-and=20 gives it a shot by specifying the next hop to be loose,which = means+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-= =20 the loose hop can be reached through any router.(Here if route pinning=20 is+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial = size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- = +ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-=20 +ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- = +ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- = applied,then a better next hop=20 is no use).+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-= =20 +ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-= =20 +ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-= =20 But,to do that,your MPLS management should very very = efficient+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsA= Jg-nbsp+ADs-In=20 such cases,when you might have a lot of communication = between+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsA= Jg-nbsp+ADs-your=20 signaling and forwarding management.+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsA= Jg-nbsp+ADsAPA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsA= Jg-nbsp+ADs-Also,there=20 arises a question,of controlling the child like Ingress of the Initiated = LSP+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-= =20 to sustain the paths,since this is a downstream on demand = mode+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsA= Jg-nbsp+ADsAPA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsA= Jg-nbsp+ADs-Also,whats=20 the used of the better next hop ?.I dont see any good use of it,when=20 one+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial = size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- = +ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-=20 +ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- = +ACY-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- has a = CR-LSP.+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-= =20 I guess it more of engineering and adding an extra rear view mirror to=20 CR-LDP+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsA= Jg-nbsp+ADsAPA-/FONT+AD4APA-FONT=20 face+AD0-Arial size+AD0-2+AD4-Hope this = helps,+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-= =20 Regards,+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial=20 size+AD0-2+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+AD= sAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs= AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs-= =20 Abhay+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4AJg-nbsp+ADsAPA-/DIV+AD4- +ADw-DIV+AD4AJg-nbsp+ADsAPA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial size+AD0-2+AD4------ Original = Message ----- +ADw-/FONT+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial size+AD0-2+AD4-From: Venkat Dabbara = +ACY-lt+ADsAPA-A=20 href+AD0AIg-mailto:venkat.dabb+AEA-wipro.com+ACIAPg-venkat.dabb+AEA-wipro= .com+ADw-/A+AD4AJg-gt+ADsAPA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial size+AD0-2+AD4-To: +ACY-lt+ADsAPA-A=20 href+AD0AIg-mailto:mpls+AEA-UU.NET+ACIAPg-mpls+AEA-UU.NET+ADw-/A+AD4AJg-g= t+ADsAPA-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial size+AD0-2+AD4-Sent: Monday, = November 19, 2001 5:01=20 PM+ADw-/FONT+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-FONT face+AD0-Arial size+AD0-2+AD4-Subject: next hop = change in CRLDP=20 +ADw-/FONT+AD4APA-/DIV+AD4APA-/DIV+AD4- +ADw-DIV+AD4APA-BR+AD4APA-/DIV+AD4APA-FONT face+AD0-Arial = size+AD0-2+AD4-hai=20 ,+ADw-BR+AD4APA-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg= -nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- This is regarding next=20 hop change in CRLDP ( Better next hop avalability )=20 .+ADw-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsA= Jg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- I could find some=20 discussion happening before on this but it wasn't satisfactory=20 +ADw-BR+AD4APA-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-= nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADs- Some one had asked=20 +ADw-BR+AD4APA-BR+AD4AJg-gt+ADs-Suppose a CRLSP is setup with no-pin = option and+ACY-nbsp+ADs- LSR-A is=20 +ADw-BR+AD4AJg-gt+ADs- part of LSP as +ADw-BR+AD4AJg-gt+ADs- loose hop = member. +ADw-BR+AD4AJg-gt+ADs- When LSR-A finds=20 better nexthop, it is supposed to taer down +ADw-BR+AD4AJg-gt+ADs- LSP = along old +ADw-BR+AD4AJg-gt+ADs-=20 path+ACY-nbsp+ADs- and send label request to new nexthop. For this, = LSR-A +ADw-BR+AD4AJg-gt+ADs- has=20 to store +ADw-BR+AD4AJg-gt+ADs- all the TLVs it received in CRLSP = initiation request so that=20 +ADw-BR+AD4AJg-gt+ADs- it can initiate +ADw-BR+AD4AJg-gt+ADs- request = along new nexthop. Does not it imply=20 that CR-LDP is +ADw-BR+AD4AJg-gt+ADs- not scalable? = +ADw-BR+AD4APA-BR+AD4-And some one had answered it=20 saying +ADw-BR+AD4APA-BR+AD4AJg-gt+ADsAIg- This is not a scalability = issue but a simple engineering=20 issue, +ADw-BR+AD4AJg-gt+ADs- no-pinning with a CR-LDP loose hop is an = unlikely scenario.=20 +ADw-BR+AD4AJg-gt+ADs- No pinning is most appropriate with LDP. = +ACIAPA-BR+AD4APA-BR+AD4-Ruling out such a=20 scenario doesn't seem+ACY-nbsp+ADs- to solve the problem ..What if the = scenario comes in=20 ??+ADw-BR+AD4-Surely we can react as it is being done in LDP where u = just tear down the=20 path .+ADw-BR+AD4-Some thing of +ACI- make and break+ACIAJg-nbsp+ADs- = policy should be done which=20 would be of some meaning rather than going = for+ADw-BR+AD4AJg-nbsp+ADsAIg-break and make +ACIAPA-BR+AD4-as=20 done in LDP where u land up tearing down the CRLSP for every better next = hop=20 avalibility.+ADw-BR+AD4APA-BR+AD4-As pointed out by some one , will it = be scalable to store=20 the list of remaining hops present in ERTlv+ADw-BR+AD4-at every hop ??? = If yes ,this=20 would solve the purpose to some extent ...+ADw-BR+AD4APA-BR+AD4-Please = correct me if i am=20 wrong.+ADw-BR+AD4APA-BR+AD4-regards+ADw-BR+AD4-venkat+ADw-BR+AD4APA-BR+AD= 4APA-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJ= g-nbsp+ADsAJg-nbsp+ADs-=20 +ADw-BR+AD4APA-BR+AD4AJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-nbsp+ADsAJg-= nbsp+ADs- = +ADw-BR+AD4APA-BR+AD4APA-BR+AD4APA-BR+AD4APA-BR+AD4APA-/FONT+AD4APA-/BODY= +AD4APA-/HTML+AD4- ------=_NextPart_000_0024_01C171DF.A084FBC0-- From owner-mpls@UU.NET Tue Nov 20 06:56:10 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04150 for ; Tue, 20 Nov 2001 06:56:10 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpyl25348; Tue, 20 Nov 2001 11:50:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpyl28836 for mpls-outgoing; Tue, 20 Nov 2001 11:50:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlpyl28831 for ; Tue, 20 Nov 2001 11:50:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlpyl23754 for ; Tue, 20 Nov 2001 11:50:04 GMT Received: from wiprom2mx2.wipro.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx2.wipro.com [203.197.164.42]) id QQlpyl24656 for ; Tue, 20 Nov 2001 11:49:49 GMT Received: from m2vwall3.wipro.com (m2vwall3.wipro.com [164.164.29.237]) by wiprom2mx2.wipro.com (8.11.3/8.11.3) with SMTP id fAKBnmT09016 for ; Tue, 20 Nov 2001 17:19:50 +0530 (IST) Received: from 192.168.2.18 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Tue, 20 Nov 2001 17:19:43 +0530 Received: from venkat.wipro.com ([192.168.220.119]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GN3KV400.4HI; Tue, 20 Nov 2001 17:19:52 +0530 Date: Tue, 20 Nov 2001 17:25:18 +0530 (IST) From: "Venkat Dabbara" X-Sender: venkat@venkat.wipro.com Reply-To: venkat.dabb@wipro.com To: abhay cc: mpls@UU.NET Subject: Re: next hop change in CRLDP In-Reply-To: <002701c171b1$89a61e80$8801a8c0@multitech.co.in> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk hai abhay , Thanks for the reply ...Well , i too don't see ne good reason for having a new next hop availablity in CRLDP . Just wanted to knoe that if there is any standard way in which a LSR should behave when it comes accross a situation ... I feel route pinning every CRLSP by default would solve things wherein u never respond to a new next hop availablity and continue to use the same old pinned path ....Is that ok ?? thanks and regards venkat On Tue, 20 Nov 2001, abhay wrote: > hello venkat, > Yes,why not,there is no hard based rule for not storing ER-TLV's > Ref T.E MIB > One reason for not doing so would be that usually Loose hops > are not directly connected. > In other words the administrator does not know the stable topology > and gives it a shot by specifying the next hop to be loose,which means > the loose hop can be reached through any router.(Here if route pinning is > applied,then a better next hop is no use). > > > But,to do that,your MPLS management should very very efficient > In such cases,when you might have a lot of communication between > your signaling and forwarding management. > > Also,there arises a question,of controlling the child like Ingress of the Initiated LSP > to sustain the paths,since this is a downstream on demand mode > > Also,whats the used of the better next hop ?.I dont see any good use of it,when one > has a CR-LSP. > I guess it more of engineering and adding an extra rear view mirror to CR-LDP > Hope this helps, > Regards, > Abhay > > > ----- Original Message ----- > From: Venkat Dabbara +ADw-venkat.dabb+AEA-wipro.com+AD4- > To: +ADw-mpls+AEA-UU.NET+AD4- > Sent: Monday, November 19, 2001 5:01 PM > Subject: next hop change in CRLDP > > > hai , > > This is regarding next hop change in CRLDP ( Better next hop avalability ) . > I could find some discussion happening before on this but it wasn't satisfactory > > Some one had asked > > +AD4-Suppose a CRLSP is setup with no-pin option and LSR-A is > +AD4- part of LSP as > +AD4- loose hop member. > +AD4- When LSR-A finds better nexthop, it is supposed to taer down > +AD4- LSP along old > +AD4- path and send label request to new nexthop. For this, LSR-A > +AD4- has to store > +AD4- all the TLVs it received in CRLSP initiation request so that > +AD4- it can initiate > +AD4- request along new nexthop. Does not it imply that CR-LDP is > +AD4- not scalable? > > And some one had answered it saying > > +AD4AIg- This is not a scalability issue but a simple engineering issue, > +AD4- no-pinning with a CR-LDP loose hop is an unlikely scenario. > +AD4- No pinning is most appropriate with LDP. +ACI- > > Ruling out such a scenario doesn't seem to solve the problem ..What if the scenario comes in ?? > Surely we can react as it is being done in LDP where u just tear down the path . > Some thing of +ACI- make and break+ACI- policy should be done which would be of some meaning rather than going for > +ACI-break and make +ACI- > as done in LDP where u land up tearing down the CRLSP for every better next hop avalibility. > > As pointed out by some one , will it be scalable to store the list of remaining hops present in ERTlv > at every hop ??? If yes ,this would solve the purpose to some extent ... > > Please correct me if i am wrong. > > regards > venkat > > > > > > > > > > > From owner-mpls@UU.NET Tue Nov 20 07:13:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04637 for ; Tue, 20 Nov 2001 07:13:45 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpym17141; Tue, 20 Nov 2001 12:02:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpym09028 for mpls-outgoing; Tue, 20 Nov 2001 12:02:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpym08963 for ; Tue, 20 Nov 2001 12:02: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 QQlpym17239 for ; Tue, 20 Nov 2001 12:00:55 GMT Received: from gleb.nbase.co.il by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gleb.nbase.co.il [194.90.136.56]) id QQlpym12745 for ; Tue, 20 Nov 2001 12:00:41 GMT Received: by gleb.nbase.co.il (Postfix, from userid 1000) id EB353E03C; Tue, 20 Nov 2001 14:00:56 +0200 (IST) Date: Tue, 20 Nov 2001 14:00:56 +0200 To: mpls@UU.NET Subject: Status of draft-ietf-mpls-ldp-state-04.txt Message-ID: <20011120140056.A15060@nbase.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline From: gleb@nbase.co.il (Gleb Natapov) Sender: owner-mpls@UU.NET Precedence: bulk Hello, What is the status of draft-ietf-mpls-ldp-state? The current version of the draft (draft-ietf-mpls-ldp-state-04) expired in September 2001. -- Gleb. From owner-mpls@UU.NET Tue Nov 20 10:59:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16473 for ; Tue, 20 Nov 2001 10:59:50 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlpzb06497; Tue, 20 Nov 2001 15:56:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQlpzb07446 for mpls-outgoing; Tue, 20 Nov 2001 15:56:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlpzb07389 for ; Tue, 20 Nov 2001 15:56:10 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 QQlpzb26020 for ; Tue, 20 Nov 2001 15:55:17 GMT Received: from smtp.adc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.adc.com [155.226.10.207]) id QQlpzb26372 for ; Tue, 20 Nov 2001 15:55:04 GMT Received: from B10.basystems.com.adc.com (localhost [127.0.0.1]) by smtp.adc.com (8.11.1/8.11.1) with ESMTP id fAKFt8X28238; Tue, 20 Nov 2001 09:55:09 -0600 (CST) From: Igor Lasic MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15354.31778.546306.861572@B10.basystems.com> Date: Tue, 20 Nov 2001 10:52:02 -0500 To: "Ashwin C. Prabhu" Cc: #ZHU YONGQING# , mpls@UU.NET Subject: RE: how to map the traffic? In-Reply-To: <751B6DD7A243D511AB9F0002557C568701958396@HUAWEIMAIL> References: <751B6DD7A243D511AB9F0002557C568701958396@HUAWEIMAIL> X-Mailer: VM 6.96 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit 3036 defines FECs as far as LDP is concerned. Try RFC 3031 section 3.12 and draft-ietf-mpls-ftn-mib-03.txt they pertain to a more general approach. Igor Ashwin C. Prabhu writes: > > Hello > > You can read the section > > 2.1. FECs of the RFC 3036 > > Regds > Ashwin > > -----Original Message----- > From: #ZHU YONGQING# [ mailto:PG01320073@ntu.edu.sg > ] > Sent: Tuesday, November 13, 2001 6:15 PM > To: mpls@UU.NET > Subject: how to map the traffic? > > > hi, > I have a question about mapping the traffic. When the traffic flows > arrive the ingress LSR of MPLS domain, how are they mapped into > pre-estabished LSPs? Is it an issue of traffic engineering? Does it need > > any algorithm or is there any protocol about it? > > Thanks a lot! > > > > > > > RE: how to map the traffic? > > >
> >

Hello >

> >

 You can read the section >

> >

2.1. FECs of the RFC 3036 >

> >

Regds >
Ashwin >

> >

-----Original Message----- >
From: #ZHU YONGQING# [mailto:PG01320073@ntu.edu.sg] >
Sent: Tuesday, November 13, 2001 6:15 PM >
To: mpls@UU.NET >
Subject: how to map the traffic? >

>
> >

hi, >
I have a question about mapping the traffic. When the traffic flows >
arrive the ingress LSR of MPLS domain, how are they mapped into >
pre-estabished LSPs? Is it an issue of traffic engineering? Does it need >
any algorithm or is there any protocol about it? >

> >

Thanks a lot! >

> > > From owner-mpls@UU.NET Tue Nov 20 23:31:52 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18214 for ; Tue, 20 Nov 2001 23:31:51 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqaz18554; Wed, 21 Nov 2001 04:29:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqaz15097 for mpls-outgoing; Wed, 21 Nov 2001 04:29:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlqaz15089 for ; Wed, 21 Nov 2001 04:29:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlqaz22231 for ; Wed, 21 Nov 2001 04:28:27 GMT Received: from itplgateway.cpqitpltech4 by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: PPP-184-58.bng.vsnl.net.in [203.197.184.58]) id QQlqaz17240 for ; Wed, 21 Nov 2001 04:28:01 GMT Received: from KRISHNAKANTH ([192.168.0.105]) by itplgateway.cpqitpltech4 with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XGWRF0R1; Wed, 21 Nov 2001 09:55:20 +0530 Message-ID: <00eb01c17245$a9eb3b00$6900a8c0@CPQITPLTECH4> From: "Krishnakanth Rao" To: Subject: mapping of traffic to tunnels Date: Wed, 21 Nov 2001 10:03:21 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E8_01C17273.C04D4720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00E8_01C17273.C04D4720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have configured an MPLS tunnel in Cisco IOS using the following = commands interface tunnel1 ip unnumbered loopback 1 tunnel destination 1.1.1.1 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng bandwidth 1000 tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng path-option 1 dynamic what is the command to map a traffic belonging to particular FEC(having = a particular DSCP or having a particular address prefix) to this tunnel = ? ------=_NextPart_000_00E8_01C17273.C04D4720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have configured an MPLS tunnel in Cisco IOS using the following=20 commands
   interface tunnel1
   ip = unnumbered=20 loopback 1
   tunnel destination 1.1.1.1
   = tunnel=20 mode mpls traffic-eng
   tunnel mpls traffic-eng autoroute=20 announce
   tunnel mpls traffic-eng bandwidth = 1000
  =20 tunnel mpls traffic-eng priority 1 1
   tunnel mpls = traffic-eng=20 path-option 1 dynamic
 
what is the command to map a traffic belonging to particular = FEC(having a=20 particular DSCP or having a particular address prefix) to this tunnel=20 ?
------=_NextPart_000_00E8_01C17273.C04D4720-- From owner-mpls@UU.NET Tue Nov 20 23:46:15 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18389 for ; Tue, 20 Nov 2001 23:46:14 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqba13672; Wed, 21 Nov 2001 04:33:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqba15394 for mpls-outgoing; Wed, 21 Nov 2001 04:32:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlqba15389 for ; Wed, 21 Nov 2001 04:32: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 QQlqba23378 for ; Wed, 21 Nov 2001 04:32:21 GMT Received: from multitech.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.39.98]) id QQlqba11653 for ; Wed, 21 Nov 2001 04:32:02 GMT Received: from abhay (abhay [192.168.1.136]) by multitech.co.in (8.12.1/8.12.1) with SMTP id fAL4VIdw014588; Wed, 21 Nov 2001 10:01:19 +0530 Message-ID: <001d01c17246$69884520$8801a8c0@multitech.co.in> From: "abhay" To: "Yacine El Mghazli" , "phani R" Cc: References: <20011119140811.91916.qmail@web11402.mail.yahoo.com> <02aa01c17107$8e650760$caf609bc@p50669> Subject: Re: LSR MIB : InSegmentXCIndex read-only ? Date: Wed, 21 Nov 2001 10:08:47 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C17274.82B11260" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C17274.82B11260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Yacine, Why not ,?.Manager can have a range of special XCIndicies Ref: Static Configuration. More over the XCIndex is made in the switching = tables,remember the search tries ,:-) Regards, Abhay ----- Original Message -----=20 From: Yacine El Mghazli To: phani R Cc: Sent: Monday, November 19, 2001 8:06 PM Subject: Re: LSR MIB : InSegmentXCIndex read-only ? > thanks for your reply phani, >=20 > but unfortunately, it's not so clear for me... >=20 > the manager can create XC entries, InSegment and OutSegment entries > (read-create MAX-ACCESS, except the In(/Out)SegmentXCIndex column)... = but it > cannot link them together ! > according to your previous email, the MPLS forwarder/controller is > responsible for linking these, but how do it choose which XC entry to = link > to such In(/Out)Segment entry (among those which have been created by = the > manager) ? >=20 > why cannot the manager set XCindex also ? >=20 > be sure I don't think you're wrong... tell me please what is the point = I > misunderstand :-( >=20 > thanks, > yacine >=20 >=20 >=20 > > Good day, > > The MPLS forwarder/controller maintaining the > > Fib would link the XC entry with the corresponding > > in-segment/out-segment during the creation for that > > entry /row. > > > > Thanks > > Phani.R > > --- Yacine El Mghazli > > wrote: > Hi all, > > > > > > In the LSR MIB, according to the lattest draft, why > > > is the MAX-ACCESS of the > > > mplsInSegmentXCIndex (and also the > > > OutSegmentXCIndex) set to "read-only" ? > > > In other words : who links an XC entry with an > > > In(/Out)Segment entry... > > > since it's not the SNMP manager ? > > > > > > thanks in advance, > > > Yacine > > > > __________________________________________________ > > Do You Yahoo!? > > Everything you'll ever need on one web page from News and Sport to = Email > and Music Charts > > http://uk.my.yahoo.com ------=_NextPart_000_001A_01C17274.82B11260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Yacine,
          &nbs= p;  =20 Why not ,?.Manager can have a range of special XCIndicies
          &nbs= p;   Ref:=20 Static Configuration.
          &nbs= p;   More=20 over the XCIndex is made in the switching tables,remember the search = tries=20 ,:-)
          &nbs= p;   Regards,
          &nbs= p;  =20 Abhay
 
----- Original Message -----
From: Yacine El Mghazli <yacine.elmghazli@ms.alcate= l.fr>
To: phani R <phani_luck@yahoo.com><= /DIV>
Cc: <mpls@UU.NET>
Sent: Monday, November 19, 2001 8:06=20 PM
Subject: Re: LSR MIB : InSegmentXCIndex = read-only=20 ?

> thanks for your = reply=20 phani,
>
> but unfortunately, it's not so clear for = me...
>=20
> the manager can create XC entries, InSegment and OutSegment=20 entries
> (read-create MAX-ACCESS, except the = In(/Out)SegmentXCIndex=20 column)... but it
> cannot link them together !
> according = to your=20 previous email, the MPLS forwarder/controller is
> responsible for = linking=20 these, but how do it choose which XC entry to link
> to such=20 In(/Out)Segment entry (among those which have been created by = the
>=20 manager) ?
>
> why cannot the manager set XCindex also = ?
>=20
> be sure I don't think you're wrong... tell me please what is = the point=20 I
> misunderstand :-(
>
> thanks,
> = yacine
>=20
>
>
> > Good day,
>=20 >          The MPLS=20 forwarder/controller maintaining the
> > Fib would link the XC = entry=20 with the corresponding
> > in-segment/out-segment during the = creation=20 for that
> > entry /row.
> >
> > = Thanks
> >=20 Phani.R
> > --- Yacine El Mghazli <yacine.elmghazli@ms.alcate= l.fr>
>=20 > wrote: > Hi all,
> > >
> > > In the LSR = MIB,=20 according to the lattest draft, why
> > > is the MAX-ACCESS = of=20 the
> > > mplsInSegmentXCIndex (and also the
> > = >=20 OutSegmentXCIndex) set to "read-only" ?
> > > In other words = : who=20 links an XC entry with an
> > > In(/Out)Segment = entry...
>=20 > > since it's not the SNMP manager ?
> > >
> = > >=20 thanks in advance,
> > > Yacine
> >
> >=20 __________________________________________________
> > Do You=20 Yahoo!?
> > Everything you'll ever need on one web page from = News and=20 Sport to Email
> and Music Charts
> > http://uk.my.yahoo.com<= /BODY> ------=_NextPart_000_001A_01C17274.82B11260-- From owner-mpls@UU.NET Wed Nov 21 02:25:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06288 for ; Wed, 21 Nov 2001 02:25:00 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqbl29437; Wed, 21 Nov 2001 07:24:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqbl25118 for mpls-outgoing; Wed, 21 Nov 2001 07:24:01 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqbl25108 for ; Wed, 21 Nov 2001 07:23: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 QQlqbl06912 for ; Wed, 21 Nov 2001 07:23:29 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQlqbl06991 for ; Wed, 21 Nov 2001 07:23:17 GMT Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 12:47:59 +0530 Message-ID: <13D467F625FAD511AE2A00D0B7B917D70642BD@mailserver.netbrahma.com> From: Narasimha Swamy To: "'mpls@uu.net'" Subject: error handling in l2vpn Date: Wed, 21 Nov 2001 12:47:59 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, In case of L2VPN sessions configuration, it is possible for an edge LSR to receive unmatched MTU or vc-type from other edge LSR for a particular l2vpn session. What type of message should be sent in this case to indicate this error. If notification message is sent, what will be the Status Code. regards swamy. From owner-mpls@UU.NET Wed Nov 21 05:19:29 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08444 for ; Wed, 21 Nov 2001 05:19:29 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqbx29463; Wed, 21 Nov 2001 10:18:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqbx05267 for mpls-outgoing; Wed, 21 Nov 2001 10:18:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqbx05256 for ; Wed, 21 Nov 2001 10:18:07 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 QQlqbw08305 for ; Wed, 21 Nov 2001 10:14:57 GMT Received: from itplgateway.cpqitpltech4 by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.200.62.205]) id QQlqbw22234 for ; Wed, 21 Nov 2001 10:14:41 GMT Received: from KRISHNAKANTH ([192.168.0.105]) by itplgateway.cpqitpltech4 with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XGWRF0XY; Wed, 21 Nov 2001 15:42:17 +0530 Message-ID: <01f501c17276$10bc7c60$6900a8c0@CPQITPLTECH4> From: "Krishnakanth Rao" To: Subject: mapping to MPLS Tunnels Date: Wed, 21 Nov 2001 15:49:54 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F2_01C172A4.29AE0D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01F2_01C172A4.29AE0D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How do I configure a router(cisco) to use a specified MPLS Tunnel when = the traffic matches filter in the specified access list. ------=_NextPart_000_01F2_01C172A4.29AE0D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

How do I configure a router(cisco) to use a specified MPLS = Tunnel=20 when the traffic matches filter in the specified = access=20 list.

------=_NextPart_000_01F2_01C172A4.29AE0D00-- From owner-mpls@UU.NET Wed Nov 21 05:23:18 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08467 for ; Wed, 21 Nov 2001 05:23:18 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqbx05009; Wed, 21 Nov 2001 10:22:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqbx05558 for mpls-outgoing; Wed, 21 Nov 2001 10:22:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqbx05547 for ; Wed, 21 Nov 2001 10:21:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlqbx20584 for ; Wed, 21 Nov 2001 10:20:07 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqbx29852 for ; Wed, 21 Nov 2001 10:19:52 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA23675 for ; Wed, 21 Nov 2001 05:20:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id FAA19803 for mpls@uu.net; Wed, 21 Nov 2001 05:20:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlqbx05285 for ; Wed, 21 Nov 2001 10:18:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlqbx08545 for ; Wed, 21 Nov 2001 10:16:22 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQlqbx11692 for ; Wed, 21 Nov 2001 10:16:27 GMT Received: from packetexchange.net (unknown [217.204.176.205]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id CC64F15F83E; Wed, 21 Nov 2001 10:18:08 +0000 (GMT) Message-ID: <3BFB7F4D.A5D65971@packetexchange.net> Date: Wed, 21 Nov 2001 10:17:49 +0000 From: Giles Heron Reply-To: giles@packetexchange.net Organization: PacketExchange Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Narasimha Swamy Cc: "'mpls@uu.net'" , Luca Martini Subject: Re: error handling in l2vpn References: <13D467F625FAD511AE2A00D0B7B917D70642BD@mailserver.netbrahma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Narasimha Swamy wrote: > > Hi, > In case of L2VPN sessions configuration, it is possible for an edge LSR to > receive unmatched MTU or vc-type from other edge LSR for a particular l2vpn > session. By L2VPN here do you mean draft-martini? If so then yes - it is possible for the edge LSR to receive unmatched MTU or vc-type from the peer edge LSR. > What type of message should be sent in this case to indicate this error. If > notification message is sent, what will be the Status Code. A label release should be sent. I'm not sure what the status code should be. Luca can probably tell us... Giles > regards > swamy. -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Wed Nov 21 05:38:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08659 for ; Wed, 21 Nov 2001 05:38:31 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqby15361; Wed, 21 Nov 2001 10:37:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqby06650 for mpls-outgoing; Wed, 21 Nov 2001 10:37:03 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqby06641 for ; Wed, 21 Nov 2001 10:36: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 QQlqby00459 for ; Wed, 21 Nov 2001 10:36:05 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQlqby22769 for ; Wed, 21 Nov 2001 10:35:52 GMT Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 16:00:34 +0530 Message-ID: <13D467F625FAD511AE2A00D0B7B917D70642BE@mailserver.netbrahma.com> From: Narasimha Swamy To: "'giles@packetexchange.net'" Cc: "'mpls@uu.net'" , Luca Martini Subject: RE: error handling in l2vpn Date: Wed, 21 Nov 2001 16:00:34 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > Narasimha Swamy wrote: > > > > Hi, > > In case of L2VPN sessions configuration, it is possible for an edge LSR > to > > receive unmatched MTU or vc-type from other edge LSR for a particular > l2vpn > > session. > > By L2VPN here do you mean draft-martini? yes, i mean draft-martini. > If so then yes - it is possible for the edge LSR to receive unmatched > MTU or vc-type from the peer edge LSR. > > > What type of message should be sent in this case to indicate this error. > If > > notification message is sent, what will be the Status Code. > > A label release should be sent. I'm not sure what the status code > should be. Luca can probably tell us... > if label release is the one to be sent, i don't think status code required, as status code is meaningful only in the context of notification messages. But according to the section 3.5.1.1.1 of rfc3036, it seems to be label release is meant for different scenarios than this l2vpn one. May be it is meaningful to send notification message using Extended Status to indicate the mismatch problem. > Giles > > > regards > > swamy. > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > From owner-mpls@UU.NET Wed Nov 21 08:48:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14240 for ; Wed, 21 Nov 2001 08:48:56 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqcl29520; Wed, 21 Nov 2001 13:47:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqcl18117 for mpls-outgoing; Wed, 21 Nov 2001 13:47:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlqcl18112 for ; Wed, 21 Nov 2001 13:47:29 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlqck24786 for ; Wed, 21 Nov 2001 13:44:43 GMT Received: from mailrelay.laurelnetworks.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: host11.laurelnetworks.com [63.94.127.11] (may be forged)) id QQlqck23455 for ; Wed, 21 Nov 2001 13:44:47 GMT Received: from saturn.laurelnetworks.com (IDENT:tob@saturn.laurelnetworks.com [10.0.4.108]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with SMTP id IAA01443; Wed, 21 Nov 2001 08:44:07 -0500 To: giles@packetexchange.net Cc: Narasimha Swamy , "'mpls@uu.net'" , Luca Martini Subject: Re: error handling in l2vpn References: <13D467F625FAD511AE2A00D0B7B917D70642BD@mailserver.netbrahma.com> <3BFB7F4D.A5D65971@packetexchange.net> From: Toby Smith Date: 21 Nov 2001 08:47:44 -0500 In-Reply-To: Giles Heron's message of "Wed, 21 Nov 2001 10:17:49 +0000" Message-ID: <7rk7wknslb.fsf@saturn.laurelnetworks.com> Lines: 39 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Giles Heron writes: > Narasimha Swamy wrote: > > > > Hi, > > In case of L2VPN sessions configuration, it is possible for an edge LSR to > > receive unmatched MTU or vc-type from other edge LSR for a particular l2vpn > > session. > > By L2VPN here do you mean draft-martini? > > If so then yes - it is possible for the edge LSR to receive unmatched > MTU or vc-type from the peer edge LSR. > > > What type of message should be sent in this case to indicate this error. If > > notification message is sent, what will be the Status Code. > > A label release should be sent. Hi, Are you sure about this last bit? If one LSR has a configured MTU of 1400, and receives information from its peer for the same VC ID & interface type, but with an advertised MTU of 1500, I would think that this situation would be better served by maintaining the received mapping and relaying this status to the local user, who has a better chance of configuring the local interface to a matching MTU (or fixing things up on the remote side). If a release is sent instead, it then opens up the issue of having the LSR who issued the release later send a request for that mapping. Either that, or the remote LSR who receives the release from the local LSR now has enough information to pick a new MTU that might be more amenable to the LSR which sent the release. But now we're talking about MTU negotiation, aren't we. Regards, Tob From owner-mpls@UU.NET Wed Nov 21 09:37:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16472 for ; Wed, 21 Nov 2001 09:37:07 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqco21031; Wed, 21 Nov 2001 14:30:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqco10316 for mpls-outgoing; Wed, 21 Nov 2001 14:30:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlqco10311 for ; Wed, 21 Nov 2001 14:30: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 QQlqcn01273 for ; Wed, 21 Nov 2001 14:29:02 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqcn00032 for ; Wed, 21 Nov 2001 14:28:49 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA07137 for ; Wed, 21 Nov 2001 09:29:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA00537 for mpls@uu.net; Wed, 21 Nov 2001 09:29:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlqcn10187 for ; Wed, 21 Nov 2001 14:28:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlqcn16642 for ; Wed, 21 Nov 2001 14:26:50 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQlqcn14875 for ; Wed, 21 Nov 2001 14:26:54 GMT Received: from packetexchange.net (unknown [217.204.176.205]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id 245A215F838; Wed, 21 Nov 2001 14:28:36 +0000 (GMT) Message-ID: <3BFBBA00.CFA9954B@packetexchange.net> Date: Wed, 21 Nov 2001 14:28:16 +0000 From: Giles Heron Reply-To: giles@packetexchange.net Organization: PacketExchange Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Toby Smith Cc: Narasimha Swamy , "'mpls@uu.net'" , Luca Martini Subject: Re: error handling in l2vpn References: <13D467F625FAD511AE2A00D0B7B917D70642BD@mailserver.netbrahma.com> <3BFB7F4D.A5D65971@packetexchange.net> <7rk7wknslb.fsf@saturn.laurelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Toby Smith wrote: > > Giles Heron writes: > > > Narasimha Swamy wrote: > > > > > > Hi, > > > In case of L2VPN sessions configuration, it is possible for an edge LSR to > > > receive unmatched MTU or vc-type from other edge LSR for a particular l2vpn > > > session. > > > > By L2VPN here do you mean draft-martini? > > > > If so then yes - it is possible for the edge LSR to receive unmatched > > MTU or vc-type from the peer edge LSR. > > > > > What type of message should be sent in this case to indicate this error. If > > > notification message is sent, what will be the Status Code. > > > > A label release should be sent. > > Hi, > > Are you sure about this last bit? If one LSR has a configured MTU of > 1400, and receives information from its peer for the same VC ID & > interface type, but with an advertised MTU of 1500, I would think that > this situation would be better served by maintaining the received > mapping and relaying this status to the local user, who has a better > chance of configuring the local interface to a matching MTU (or fixing > things up on the remote side). > > If a release is sent instead, it then opens up the issue of having the > LSR who issued the release later send a request for that mapping. > > Either that, or the remote LSR who receives the release from the local > LSR now has enough information to pick a new MTU that might be more > amenable to the LSR which sent the release. But now we're talking > about MTU negotiation, aren't we. exactly. And from my memory of the discussion I think we decided to try and avoid getting into negotiation for this parameter. So we decided to depend on the SP managing to configure a matching MTU size as well as VC ID and VC type at both ends... In general I'd expect vendors to default the MTU to something sensible for that encaps (e.g. 1500 for Ethernet, 1500 or 4470 for PPP, and so on.) So most of the time (assuming the SP has a core which can transport this default MTU) no further action should be necessary from the SP. I think I argued for putting default MTU values in the draft? I can't remember why we didn't put them in? Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Wed Nov 21 09:40:25 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17026 for ; Wed, 21 Nov 2001 09:40:25 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqco19719; Wed, 21 Nov 2001 14:38:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqco12428 for mpls-outgoing; Wed, 21 Nov 2001 14:38:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqco12421 for ; Wed, 21 Nov 2001 14:38:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlqco22451 for ; Wed, 21 Nov 2001 14:37:21 GMT Received: from mailrelay.laurelnetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: host11.laurelnetworks.com [63.94.127.11] (may be forged)) id QQlqco18726 for ; Wed, 21 Nov 2001 14:37:10 GMT Received: from saturn.laurelnetworks.com (IDENT:tob@saturn.laurelnetworks.com [10.0.4.108]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with SMTP id JAA03874; Wed, 21 Nov 2001 09:36:46 -0500 To: giles@packetexchange.net Cc: Narasimha Swamy , "'mpls@uu.net'" , Luca Martini Subject: Re: error handling in l2vpn References: <13D467F625FAD511AE2A00D0B7B917D70642BD@mailserver.netbrahma.com> <3BFB7F4D.A5D65971@packetexchange.net> <7rk7wknslb.fsf@saturn.laurelnetworks.com> <3BFBBA00.CFA9954B@packetexchange.net> From: Toby Smith Date: 21 Nov 2001 09:40:23 -0500 In-Reply-To: Giles Heron's message of "Wed, 21 Nov 2001 14:28:16 +0000" Message-ID: <7r7ksknq5k.fsf@saturn.laurelnetworks.com> Lines: 54 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Giles Heron writes: > > Hi, > > > > Are you sure about this last bit? If one LSR has a configured MTU of > > 1400, and receives information from its peer for the same VC ID & > > interface type, but with an advertised MTU of 1500, I would think that > > this situation would be better served by maintaining the received > > mapping and relaying this status to the local user, who has a better > > chance of configuring the local interface to a matching MTU (or fixing > > things up on the remote side). > > > > If a release is sent instead, it then opens up the issue of having the > > LSR who issued the release later send a request for that mapping. > > > > Either that, or the remote LSR who receives the release from the local > > LSR now has enough information to pick a new MTU that might be more > > amenable to the LSR which sent the release. But now we're talking > > about MTU negotiation, aren't we. > > exactly. Excellent. So, are you backing down from your statement about sending a release? After all, you say: > So we decided to depend on the SP managing to configure a matching MTU > size as well as VC ID and VC type at both ends... ...which I think is the correct approach, and I think that's best served by simply maintaining the received mapping with the mismatched MTU and reconfiguring one of the boxes based on the information that the user can see in the sent & received label mappings show commands, instead of having an LSR send a release as soon as it receives a mapping with an MTU it doesn't expect, and then having to figure out a way to get the released mappings back again later. > In general I'd expect vendors to default the MTU to something sensible > for that encaps (e.g. 1500 for Ethernet, 1500 or 4470 for PPP, and so > on.) So most of the time (assuming the SP has a core which can > transport this default MTU) no further action should be necessary from > the SP. Hopefully, yeah. :) > I think I argued for putting default MTU values in the draft? I can't > remember why we didn't put them in? Seems like a good idea that might save someone the hassle of first discovering the defaults during some interop event. :) Regards, Tob From owner-mpls@UU.NET Wed Nov 21 09:57:40 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18032 for ; Wed, 21 Nov 2001 09:57:39 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqcp23773; Wed, 21 Nov 2001 14:54:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqcp15117 for mpls-outgoing; Wed, 21 Nov 2001 14:54:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqcp15110 for ; Wed, 21 Nov 2001 14:54:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqcp14967 for ; Wed, 21 Nov 2001 14:54:05 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqcp21550 for ; Wed, 21 Nov 2001 14:53:51 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA10232 for ; Wed, 21 Nov 2001 09:54:04 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA02057 for mpls@uu.net; Wed, 21 Nov 2001 09:54:04 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlqcp14983 for ; Wed, 21 Nov 2001 14:52:57 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 QQlqcp27131 for ; Wed, 21 Nov 2001 14:51:21 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQlqcp10756 for ; Wed, 21 Nov 2001 14:51:10 GMT Received: from packetexchange.net (unknown [217.204.176.205]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id 3B2B815F83F; Wed, 21 Nov 2001 14:53:07 +0000 (GMT) Message-ID: <3BFBBFBF.54ECB219@packetexchange.net> Date: Wed, 21 Nov 2001 14:52:47 +0000 From: Giles Heron Reply-To: giles@packetexchange.net Organization: PacketExchange Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Toby Smith Cc: Narasimha Swamy , "'mpls@uu.net'" , Luca Martini Subject: Re: error handling in l2vpn References: <13D467F625FAD511AE2A00D0B7B917D70642BD@mailserver.netbrahma.com> <3BFB7F4D.A5D65971@packetexchange.net> <7rk7wknslb.fsf@saturn.laurelnetworks.com> <3BFBBA00.CFA9954B@packetexchange.net> <7r7ksknq5k.fsf@saturn.laurelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Toby Smith wrote: > > Giles Heron writes: > > > > Hi, > > > > > > Are you sure about this last bit? If one LSR has a configured MTU of > > > 1400, and receives information from its peer for the same VC ID & > > > interface type, but with an advertised MTU of 1500, I would think that > > > this situation would be better served by maintaining the received > > > mapping and relaying this status to the local user, who has a better > > > chance of configuring the local interface to a matching MTU (or fixing > > > things up on the remote side). > > > > > > If a release is sent instead, it then opens up the issue of having the > > > LSR who issued the release later send a request for that mapping. > > > > > > Either that, or the remote LSR who receives the release from the local > > > LSR now has enough information to pick a new MTU that might be more > > > amenable to the LSR which sent the release. But now we're talking > > > about MTU negotiation, aren't we. > > > > exactly. > > Excellent. So, are you backing down from your statement about sending > a release? After all, you say: I didn't say that ;-) > > So we decided to depend on the SP managing to configure a matching MTU > > size as well as VC ID and VC type at both ends... > > ...which I think is the correct approach, and I think that's best > served by simply maintaining the received mapping with the mismatched > MTU and reconfiguring one of the boxes based on the information that > the user can see in the sent & received label mappings show commands, > instead of having an LSR send a release as soon as it receives a > mapping with an MTU it doesn't expect, and then having to figure out a > way to get the released mappings back again later. but if you retain the received mapping then presumably the circuit will start "working"? Whereas if the circuit fails to come up the user will figure out that something is wrong. Hopefully when (s)he turns on debug there will be a tell-tale message saying "MTU size mismatch". There is, I believe, a precedent for this. Doesn't OSPFv2 fail to establish an adjacency unless the MTUs match? > > In general I'd expect vendors to default the MTU to something sensible > > for that encaps (e.g. 1500 for Ethernet, 1500 or 4470 for PPP, and so > > on.) So most of the time (assuming the SP has a core which can > > transport this default MTU) no further action should be necessary from > > the SP. > > Hopefully, yeah. :) > > > I think I argued for putting default MTU values in the draft? I can't > > remember why we didn't put them in? > > Seems like a good idea that might save someone the hassle of first > discovering the defaults during some interop event. :) okay. Let's poll the other authors to see what we get... Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Wed Nov 21 10:00:54 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18186 for ; Wed, 21 Nov 2001 10:00:54 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqcp21344; Wed, 21 Nov 2001 14:58:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqcp15399 for mpls-outgoing; Wed, 21 Nov 2001 14:57:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqcp15382 for ; Wed, 21 Nov 2001 14:57:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlqcp24185 for ; Wed, 21 Nov 2001 14:56:40 GMT Received: from mailrelay.laurelnetworks.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: host11.laurelnetworks.com [63.94.127.11] (may be forged)) id QQlqcp00229 for ; Wed, 21 Nov 2001 14:56:45 GMT Received: from saturn.laurelnetworks.com (IDENT:tob@saturn.laurelnetworks.com [10.0.4.108]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with SMTP id JAA04783; Wed, 21 Nov 2001 09:56:08 -0500 To: giles@packetexchange.net Cc: Narasimha Swamy , "'mpls@uu.net'" , Luca Martini Subject: Re: error handling in l2vpn References: <13D467F625FAD511AE2A00D0B7B917D70642BD@mailserver.netbrahma.com> <3BFB7F4D.A5D65971@packetexchange.net> <7rk7wknslb.fsf@saturn.laurelnetworks.com> <3BFBBA00.CFA9954B@packetexchange.net> <7r7ksknq5k.fsf@saturn.laurelnetworks.com> <3BFBBFBF.54ECB219@packetexchange.net> From: Toby Smith Date: 21 Nov 2001 09:59:45 -0500 In-Reply-To: Giles Heron's message of "Wed, 21 Nov 2001 14:52:47 +0000" Message-ID: <7r3d38np9a.fsf@saturn.laurelnetworks.com> Lines: 36 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Giles Heron writes: > > ...which I think is the correct approach, and I think that's best > > served by simply maintaining the received mapping with the mismatched > > MTU and reconfiguring one of the boxes based on the information that > > the user can see in the sent & received label mappings show commands, > > instead of having an LSR send a release as soon as it receives a > > mapping with an MTU it doesn't expect, and then having to figure out a > > way to get the released mappings back again later. > > but if you retain the received mapping then presumably the circuit will > start "working"? No, not at all. Luca is very sage, and accounts for this in the trans draft: - Interface MTU A 2 octet value indicating the MTU in octets. This is the Maximum Transmission Unit, excluding encapsulation overhead, of the egress packet interface that will be transmitting the decapsulated PDU that is received from the MPLS network. This parameter is applicable only to VC types 1, 2, 4, 5, 6, and 7, and is REQUIRED for these VC types. If this parameter does not match in both directions of a specific VC, that VC MUST NOT be enabled. So, we can happily retain the mismatched label mapping without fear of any forwarding taking place, and still have the information available for the user to perform diagnosis. As a benefit, when the problem's resolved, one of the LSRs will issue a withdraw/mapping to convey the modified MTU, and things will start working. Regards, Tob From owner-mpls@UU.NET Wed Nov 21 10:06:01 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18444 for ; Wed, 21 Nov 2001 10:06:01 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqcq10279; Wed, 21 Nov 2001 15:02:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqcq19997 for mpls-outgoing; Wed, 21 Nov 2001 15:02:29 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqcq19881 for ; Wed, 21 Nov 2001 15:02: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 QQlqcq22257 for ; Wed, 21 Nov 2001 15:02:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqcq08101 for ; Wed, 21 Nov 2001 15:01:49 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA11321 for ; Wed, 21 Nov 2001 10:02:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA02732 for mpls@uu.net; Wed, 21 Nov 2001 10:02:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlqcq17738 for ; Wed, 21 Nov 2001 15:00: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 QQlqcq19559 for ; Wed, 21 Nov 2001 15:00:17 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQlqcq25161 for ; Wed, 21 Nov 2001 15:00:07 GMT Received: from packetexchange.net (unknown [217.204.176.205]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id 9CC6715F83E; Wed, 21 Nov 2001 15:02:08 +0000 (GMT) Message-ID: <3BFBC1DD.1C33E35F@packetexchange.net> Date: Wed, 21 Nov 2001 15:01:49 +0000 From: Giles Heron Reply-To: giles@packetexchange.net Organization: PacketExchange Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Toby Smith Cc: Narasimha Swamy , "'mpls@uu.net'" , Luca Martini Subject: Re: error handling in l2vpn References: <13D467F625FAD511AE2A00D0B7B917D70642BD@mailserver.netbrahma.com> <3BFB7F4D.A5D65971@packetexchange.net> <7rk7wknslb.fsf@saturn.laurelnetworks.com> <3BFBBA00.CFA9954B@packetexchange.net> <7r7ksknq5k.fsf@saturn.laurelnetworks.com> <3BFBBFBF.54ECB219@packetexchange.net> <7r3d38np9a.fsf@saturn.laurelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Toby Smith wrote: > > Giles Heron writes: > > > > ...which I think is the correct approach, and I think that's best > > > served by simply maintaining the received mapping with the mismatched > > > MTU and reconfiguring one of the boxes based on the information that > > > the user can see in the sent & received label mappings show commands, > > > instead of having an LSR send a release as soon as it receives a > > > mapping with an MTU it doesn't expect, and then having to figure out a > > > way to get the released mappings back again later. > > > > but if you retain the received mapping then presumably the circuit will > > start "working"? > > No, not at all. Luca is very sage, and accounts for this in the trans > draft: > > - Interface MTU > > A 2 octet value indicating the MTU in octets. This is the Maximum > Transmission Unit, excluding encapsulation overhead, of the > egress packet interface that will be transmitting the > decapsulated PDU that is received from the MPLS network. This > parameter is applicable only to VC types 1, 2, 4, 5, 6, and 7, > and is REQUIRED for these VC types. If this parameter does not > match in both directions of a specific VC, that VC MUST NOT be > enabled. > > So, we can happily retain the mismatched label mapping without fear of > any forwarding taking place, and still have the information available > for the user to perform diagnosis. As a benefit, when the problem's > resolved, one of the LSRs will issue a withdraw/mapping to convey the > modified MTU, and things will start working. ah. My bad. I misread "MUST NOT be enabled" as "MUST be released". Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Wed Nov 21 10:26:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19522 for ; Wed, 21 Nov 2001 10:26:14 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqcr08377; Wed, 21 Nov 2001 15:21:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqcr06965 for mpls-outgoing; Wed, 21 Nov 2001 15:21:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlqcr06960 for ; Wed, 21 Nov 2001 15:21:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqcr01752 for ; Wed, 21 Nov 2001 15:21:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqcr15948 for ; Wed, 21 Nov 2001 15:20:49 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA13712 for ; Wed, 21 Nov 2001 10:21:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA03902 for mpls@uu.net; Wed, 21 Nov 2001 10:21:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqcr06793 for ; Wed, 21 Nov 2001 15:20:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlqcr16040 for ; Wed, 21 Nov 2001 15:19:40 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQlqcr05230 for ; Wed, 21 Nov 2001 15:19:44 GMT Received: from ASIMHA-W2K.cisco.com (dhcp-64-102-48-149.cisco.com [64.102.48.149]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA05510; Wed, 21 Nov 2001 10:19:32 -0500 (EST) Date: Wed, 21 Nov 2001 10:18:34 -0500 (Eastern Standard Time) From: Ajay Simha To: Krishnakanth Rao cc: mpls@UU.NET Subject: Re: mapping to MPLS Tunnels In-Reply-To: <01f501c17276$10bc7c60$6900a8c0@CPQITPLTECH4> Message-ID: X-X-Sender: asimha@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 21 Nov 2001, Krishnakanth Rao wrote: KR>How do I configure a router(cisco) to use a specified MPLS Tunnel when KR>the traffic matches filter in the specified access list. This is a Cisco question. Please don't post such things on this list. I'm going to unicast you on how you can do this. -ajay KR> KR> -- Ajay Simha MPLS Deployment Engineer IOS Technology Division (919) 392-3141 "Study as if you were to live forever Live as if you were to die tomorrow" - Mahatma Gandhi From owner-mpls@UU.NET Wed Nov 21 15:07:48 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03228 for ; Wed, 21 Nov 2001 15:07:43 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqdk20134; Wed, 21 Nov 2001 20:04:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqdk24886 for mpls-outgoing; Wed, 21 Nov 2001 20:04:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqdk24881 for ; Wed, 21 Nov 2001 20:04:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlqdk25745 for ; Wed, 21 Nov 2001 20:03:54 GMT Received: from [172.16.1.119] by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mdclient1.opnet.com [12.145.55.10]) id QQlqdk10618 for ; Wed, 21 Nov 2001 20:03:59 GMT Received: from wtn10216.opnet.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 21 Nov 2001 15:00:24 -0500 Message-Id: <5.0.0.25.2.20011121145925.04a23b50@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 21 Nov 2001 15:02:43 -0500 To: Jean Philippe Vasseur From: Sachin Kalra Subject: Re: Does LSPs signaled through Bypass Tunnel need NHLFEs on transit nodes? Cc: mpls@UU.NET In-Reply-To: <4.3.2.7.2.20011120084812.034e1968@paris.cisco.com> References: <5.0.0.25.2.20011119183844.00a86c60@mail.opnet.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_98301389==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_98301389==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Thanks a lot to all those who replied. I will read draft-manyfolks-rsvp-fastreroute-00.txt (Rename to draft-ping-rsvp-fastreroute-00.txt) and will get back to the List if If I have any more questions. Happy Thanksgiving. Sachin Kalra At 08:50 AM 11/20/01 +0100, Jean Philippe Vasseur wrote: >Hi, > >At 19:12 19/11/2001 -0500, Sachin Kalra wrote: >>Hi: >> >>I have few questions about "Bypass Tunnels". Any help is appreciated. >> >>In following figure Primary LSP traverses from (R1->R2->R3->R4->R5) and >>Bypass tunnel from (R2->R6->R7->R8->-R4). Bypass is denoted by double lines. >> >> >> [R0] >> \ >>[R1]---------[R2]------------------[R3]-----------------[R4]-----------------[R5] >> >> \\ // \ >> \\ // \ >> [R6]======[R7]======[R8] [R9] >> >> >>If R4 is using Interface specific Label Space. (i.e. it does not use >>Global Label Space). Then we need to signal LSP through "Bypass Tunnel" >>path to obtain label assigned out of the label space used by R4 on the >>interface terminating the link from R8 (Which will later be used by R2 >>for label swapping before stacking the label for Bypass Tunnel) >> >>In this case my understanding is that once R2 has the "required label" >>from R4, then R6, R7, R8 do not need to maintain any state for the >>signaled LSP, nor do they need any NHLFEs for that LSP. Because traffic >>will be sent through the "Bypass Tunnel". >> >>1. Is this correct? > >yes > >>2. How do we handle this scenario? > >see draft-manyfolks-rsvp-fastreroute-00.txt (very recently published) > >>3. Does LSPs signaled through Bypass Tunnel need NHLFEs on transit nodes? > >no. > >JP. > >>Thanks for your time, >>Sachin Kalra =========================================================== Sachin Kalra Modeling Engineer OPNET Technologies, Inc. (240)-497-3000 x2796 =========================================================== --=====================_98301389==_.ALT Content-Type: text/html; charset="us-ascii" Thanks a lot to all those who replied.

I will read draft-manyfolks-rsvp-fastreroute-00.txt (Rename to draft-ping-rsvp-fastreroute-00.txt) and will get back to the List if If I have any more questions.

Happy Thanksgiving.
Sachin Kalra



At 08:50 AM 11/20/01 +0100, Jean Philippe Vasseur wrote:
Hi,

At 19:12 19/11/2001 -0500, Sachin Kalra wrote:
Hi:

I have few questions about "Bypass Tunnels". Any help is appreciated.

In following figure Primary LSP traverses from (R1->R2->R3->R4->R5) and Bypass tunnel from (R2->R6->R7->R8->-R4). Bypass is denoted by double lines.


        [R0]
             \
[R1]---------[R2]------------------[R3]-----------------[R4]-----------------[R5]
                  \\                                        //     \
                   \\                     //    \
                [R6]======[R7]======[R8]        [R9]


If R4 is using Interface specific Label Space. (i.e. it does not use Global Label Space). Then we need to signal LSP through "Bypass Tunnel" path to obtain label assigned out of the label space used by R4 on the interface terminating the link from R8 (Which will later be used by R2 for label swapping before stacking the label for Bypass Tunnel)

In this case my understanding is that once R2 has the "required label" from R4, then R6, R7, R8 do not need to maintain any state for the signaled LSP, nor do they need any NHLFEs for that LSP. Because traffic will be sent through the "Bypass Tunnel".

1. Is this correct?

yes

2. How do we handle this scenario?

see draft-manyfolks-rsvp-fastreroute-00.txt (very recently published)

3. Does LSPs signaled through Bypass Tunnel need NHLFEs on transit nodes?

no.

JP.

Thanks for your time,
Sachin Kalra

===========================================================
Sachin Kalra
Modeling Engineer
OPNET Technologies, Inc.
(240)-497-3000 x2796
===========================================================

--=====================_98301389==_.ALT-- From owner-mpls@UU.NET Thu Nov 22 23:38:44 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27162 for ; Thu, 22 Nov 2001 23:38:43 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqik10588; Fri, 23 Nov 2001 04:37:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqik03890 for mpls-outgoing; Fri, 23 Nov 2001 04:37:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlqik03883 for ; Fri, 23 Nov 2001 04:37:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlqik21764 for ; Fri, 23 Nov 2001 04:37:18 GMT Received: from itplgateway.cpqitpltech4 by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.93.135.78]) id QQlqik09396 for ; Fri, 23 Nov 2001 04:37:02 GMT Received: from KRISHNAKANTH ([192.168.0.105]) by itplgateway.cpqitpltech4 with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XMNPL0K1; Fri, 23 Nov 2001 10:04:26 +0530 Message-ID: <002b01c173d9$49dc0ce0$6900a8c0@CPQITPLTECH4> From: "Krishnakanth Rao" To: Subject: MPLS resource class Date: Fri, 23 Nov 2001 10:12:38 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C17407.61064B00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C17407.61064B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The ietf draft - draft-ietf-mpls-cr-ldp-05.txt (Constraint-Based LSP = Setup using LDP) talks about the resource class . What kind of resources = are indicated by this class. Could somebody explain it in detail. Krishnakanth ------=_NextPart_000_0028_01C17407.61064B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The ietf draft - draft-ietf-mpls-cr-ldp-05.txt = (Constraint-Based=20 LSP Setup using LDP) talks about the resource class . What kind of = resources are=20 indicated by this class. Could = somebody explain=20 it in detail.

Krishnakanth

 

 ------=_NextPart_000_0028_01C17407.61064B00-- From owner-mpls@UU.NET Fri Nov 23 01:26:40 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00430 for ; Fri, 23 Nov 2001 01:26:40 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqir20388; Fri, 23 Nov 2001 06:26:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqir19795 for mpls-outgoing; Fri, 23 Nov 2001 06:25:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlqir19790 for ; Fri, 23 Nov 2001 06:25:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlqir05158 for ; Fri, 23 Nov 2001 06:24:48 GMT Received: from elrond.trinicom.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [63.149.136.227]) id QQlqir10084 for ; Fri, 23 Nov 2001 06:24:53 GMT Received: (qmail 18126 invoked by uid 30); 23 Nov 2001 06:24:46 -0000 Date: 23 Nov 2001 06:24:46 -0000 Message-ID: <20011123062446.18125.qmail@elrond.trinicom.com> To: krishnakanth.rao@cominsights.com, mpls@UU.NET Subject: RE: MPLS resource class From: Sean Crocker X-Mailer: Postaci 1.1.0 (ftp://ftp.onar.com.tr/pub/linux/postaci) X-Comment: This message was sent from 208.232.192.18 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary = be2a6ef16e3fdcd85f7c4d7245cc8030c Sender: owner-mpls@UU.NET Precedence: bulk This is a MIME encoded message. --be2a6ef16e3fdcd85f7c4d7245cc8030c Content-Type: text/plain Content-Transfer-Encoding: 7bit Krishnakanth, >The ietf draft - draft-ietf-mpls-cr-ldp-05.txt (Constraint-Based LSP Setup using LDP) talks about the resource class . What kind of resources are indicated by this class. Could somebody explain it in detail. It's simply up to the administrator what resources are indicated. An administrator may want different resource class values depending on bandwidth (oc12 vs oc48), something wierder like queueing capabilities on outbound interfaces, or many other things... then LSP ingresses can be configured to use these links or not use them depending on the values. I don't think there is a range set aside for defined, "standard" values. Not sure if there has been any discussion to do so, but I suppose the aim of such would be for ease of configuration of constrained LSPs between domains. Also see http://www.ietf.org/rfc/rfc2702.txt sections 6.2 and 5.6.3 Sean > >Krishnakanth --------------------------------------- This message was sent by www.trinicom.com Webmail. --be2a6ef16e3fdcd85f7c4d7245cc8030c-- From owner-mpls@UU.NET Fri Nov 23 03:54:55 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15631 for ; Fri, 23 Nov 2001 03:54:55 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqjb25656; Fri, 23 Nov 2001 08:53:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqjb08725 for mpls-outgoing; Fri, 23 Nov 2001 08:53:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqjb08720 for ; Fri, 23 Nov 2001 08:53:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlqjb03989 for ; Fri, 23 Nov 2001 08:53:19 GMT Received: from gateway.ipinfusion.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gt.ipinfusion.com [209.11.132.18] (may be forged)) id QQlqjb21037 for ; Fri, 23 Nov 2001 08:53:07 GMT Received: from ipinfusion.com ([10.10.0.152]) by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id fAN8orR20353; Fri, 23 Nov 2001 00:50:53 -0800 Message-ID: <3BFE0DCF.5040400@ipinfusion.com> Date: Fri, 23 Nov 2001 00:50:23 -0800 From: Haseeb Budhani Organization: IP Infusion Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mpls@UU.NET Subject: Three RSVP-TE specific questions. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello folks, I'd like to get help on the following three issues: 1. Is it possible to have different types of subojects -- IPv6 and IPv4 -- in an ERO object ?? In case I missed it, the draft doesnt allow or explicitly forbid this ... 2. If local repair is in place, doesnt that basically counter the whole idea of having explicit routes ?? If CSPF or some other parallel mechanism is in place, when would one want to employ local repair ?? 3. It would seem unlikely that a label subobject be present in the Route Record Object in a Path message. If there is a label subobject in a Path message, should this be flagged an error ?? Any/all help will be greatly appreciated. -- Haseeb Budhani. From owner-mpls@UU.NET Fri Nov 23 14:44:54 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22414 for ; Fri, 23 Nov 2001 14:44:54 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqks20730; Fri, 23 Nov 2001 19:44:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqks25626 for mpls-outgoing; Fri, 23 Nov 2001 19:44:16 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqks25599 for ; Fri, 23 Nov 2001 19:44:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqks06087 for ; Fri, 23 Nov 2001 19:44:07 GMT Received: from hongkong.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.84.12.153]) id QQlqks11032 for ; Fri, 23 Nov 2001 19:43:53 GMT Received: from hongkong.com([10.1.7.100]) by hongkong.com(JetMail 2.5.3.0) with SMTP id jm73bfef67a; Fri, 23 Nov 2001 19:32:33 -0000 Received: from host.secure4-hosting.net([209.239.41.31]) by hongkong.com(JetMail 2.5.3.0) with SMTP id jm03bf9b4a2; Tue, 20 Nov 2001 01:31:31 -0000 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id fAK0iFX16357 for newsupdate@hongkong.com; Mon, 19 Nov 2001 19:44:15 -0500 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Message-Id: <5.0.0.25.2.20011119184641.00a83910@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 19 Nov 2001 18:52:24 -0500 To: mpls@UU.NET From: Sachin Kalra Subject: Is any Reservation done for Bypass Tunnels? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: archive/latest/2820 X-Loop: mpls-ops@mplsrc.com X-Auto-Forward: newsupdate@hongkong.com dannylau@hkicable.com Sender: owner-mpls@UU.NET Precedence: bulk Hi: Please, can somebody tell me if any reservation is done for "Bypass Tunnels"? Thanks, Sachin Kalra ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Fri Nov 23 15:08:40 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22774 for ; Fri, 23 Nov 2001 15:08:40 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqku11266; Fri, 23 Nov 2001 20:07:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqku15988 for mpls-outgoing; Fri, 23 Nov 2001 20:07:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqku15761 for ; Fri, 23 Nov 2001 20:07:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlqku24303 for ; Fri, 23 Nov 2001 20:07:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqku00510 for ; Fri, 23 Nov 2001 20:06:50 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA12378 for ; Fri, 23 Nov 2001 15:07:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA10258 for mpls@uu.net; Fri, 23 Nov 2001 15:07:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqku12483 for ; Fri, 23 Nov 2001 20:05:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqku08976 for ; Fri, 23 Nov 2001 20:04:44 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQlqku11220 for ; Fri, 23 Nov 2001 20:04:30 GMT Received: from JVASSEUR-W2K.cisco.com (jvasseur-isdn-home.cisco.com [10.49.89.2]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA29046; Fri, 23 Nov 2001 20:53:42 +0100 (MET) Message-Id: <4.3.2.7.2.20011123205055.05701718@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 Nov 2001 20:53:13 +0100 To: Sachin Kalra From: Jean Philippe Vasseur Subject: Re: Is any Reservation done for Bypass Tunnels? Cc: mpls@UU.NET In-Reply-To: <5.0.0.25.2.20011119184641.00a83910@mail.opnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 18:52 19/11/2001 -0500, Sachin Kalra wrote: >Hi: > >Please, can somebody tell me if any reservation is done for "Bypass Tunnels"? If what you look for is fast recovery only, the bypass tunnel can be configured as unconstrained. If you want bandwidth protection, the bypass tunnel will be set up WITH bandwidth. The amount of bandwidth allocated to the bypass tunnel determine the level of bandwidth protection you provide. JP. >Thanks, >Sachin Kalra > >------- >The MPLS-OPS Mailing List >Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Sat Nov 24 01:19:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01351 for ; Sat, 24 Nov 2001 01:19:31 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqmj29717; Sat, 24 Nov 2001 06:18:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqmj11724 for mpls-outgoing; Sat, 24 Nov 2001 06:18:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlqmj11716 for ; Sat, 24 Nov 2001 06:18: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 QQlqmj14048 for ; Sat, 24 Nov 2001 06:15:47 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqmj03078 for ; Sat, 24 Nov 2001 06:15:35 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA00674 for ; Sat, 24 Nov 2001 01:15:46 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA04969 for mpls@uu.net; Sat, 24 Nov 2001 01:15:46 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlqcd01500 for ; Wed, 21 Nov 2001 11:58:23 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 QQlqcd19576 for ; Wed, 21 Nov 2001 11:58:17 GMT Received: from out004pub.verizon.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: out004pub.verizon.net [206.46.170.104]) id QQlqcd18384 for ; Wed, 21 Nov 2001 11:58:04 GMT Received: from dumont02 (1Cust226.tnt1.mel1.da.uu.net [63.34.210.226]) by out004pub.verizon.net with SMTP ; id fALBxLY02674 Wed, 21 Nov 2001 05:59:25 -0600 (CST) From: "Joe Dumont" To: , Subject: Position of Rsvp DIFFSERV in Rsvp Path Messages Date: Wed, 21 Nov 2001 22:56:30 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, While I was reading draft-ietf-mpls-generalized-rsvp-te-05.txt, I did not see a reference to the Rsvp DIFFSERV object in the Path message BNF figure. In draft-ietf-mpls-diff-ext-09.txt it precedes the POLICY_DATA object. Where would it appear with respect to the new gMPLS objects like PROTECTION, NOTIFY_REQUEST and ADMIN_STATUS? thanks, Joe From owner-mpls@UU.NET Sun Nov 25 14:10:05 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23900 for ; Sun, 25 Nov 2001 14:10:05 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqsa06064; Sun, 25 Nov 2001 19:08:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqsa05963 for mpls-outgoing; Sun, 25 Nov 2001 19:08:00 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqsa05956 for ; Sun, 25 Nov 2001 19:07:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlqsa13940 for ; Sun, 25 Nov 2001 19:07:54 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQlqsa27195 for ; Sun, 25 Nov 2001 19:08:00 GMT Received: from juniper.net ([172.24.248.112]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id fAPJ6c027115; Sun, 25 Nov 2001 11:06:38 -0800 (PST) (envelope-from pingpan@juniper.net) Message-ID: <3C014176.7080503@juniper.net> Date: Sun, 25 Nov 2001 11:07:34 -0800 From: Ping Pan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Jean Philippe Vasseur CC: Sachin Kalra , mpls@UU.NET Subject: Re: Is any Reservation done for Bypass Tunnels? References: <4.3.2.7.2.20011123205055.05701718@paris.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 Jean Philippe Vasseur wrote: > At 18:52 19/11/2001 -0500, Sachin Kalra wrote: > >> Hi: >> >> Please, can somebody tell me if any reservation is done for "Bypass >> Tunnels"? > > > If what you look for is fast recovery only, the bypass tunnel can be > configured as unconstrained. If you want bandwidth protection, the > bypass tunnel will be set up WITH bandwidth. The amount of bandwidth > allocated to the bypass tunnel determine the level of bandwidth > protection you provide. In addition, if you want to avoid running bandwidth admission control for the backup flows, you can simply set up a bypass LSP with EXP bit on. - Ping > > JP. > >> Thanks, >> Sachin Kalra >> From owner-mpls@UU.NET Sun Nov 25 19:21:15 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26201 for ; Sun, 25 Nov 2001 19:21:15 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqsv27962; Mon, 26 Nov 2001 00:20:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqsv04032 for mpls-outgoing; Mon, 26 Nov 2001 00:19:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqsv04027 for ; Mon, 26 Nov 2001 00:19: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 QQlqsv17288 for ; Mon, 26 Nov 2001 00:19:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqsv00270 for ; Mon, 26 Nov 2001 00:18:49 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA14630 for ; Sun, 25 Nov 2001 19:19:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA15877 for mpls@uu.net; Sun, 25 Nov 2001 19:19:01 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlqsv03973 for ; Mon, 26 Nov 2001 00:18:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlqsv12067 for ; Mon, 26 Nov 2001 00:16:22 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQlqsv26349 for ; Mon, 26 Nov 2001 00:16:09 GMT Received: from ASIMHA-W2K.cisco.com (sjc-vpn1-673.cisco.com [10.21.98.161]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA23665; Sun, 25 Nov 2001 19:16:14 -0500 (EST) Date: Sun, 25 Nov 2001 19:15:14 -0500 (Eastern Standard Time) From: Ajay Simha To: Haseeb Budhani cc: mpls@UU.NET Subject: Re: Three RSVP-TE specific questions. In-Reply-To: <3BFE0DCF.5040400@ipinfusion.com> Message-ID: X-X-Sender: asimha@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 23 Nov 2001, Haseeb Budhani wrote: HB>Hello folks, HB> HB>I'd like to get help on the following three issues: HB> HB>1. Is it possible to have different types of subojects -- IPv6 and IPv4 HB>-- in an ERO object ?? In case I missed it, the draft doesnt allow or HB>explicitly forbid this ... Haseeb, Looks liked you missed it: The contents of an EXPLICIT_ROUTE object are a series of variable- length data items called subobjects. Each subobject has the form: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ |L| Type | Length | (Subobject contents) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+ L The L bit is an attribute of the subobject. The L bit is set if the subobject represents a loose hop in the explicit route. If the bit is not set, the subobject represents a strict hop in the explicit route. Type The Type indicates the type of contents of the subobject. Currently defined values are: 1 IPv4 prefix 2 IPv6 prefix 32 Autonomous system number HB> HB>2. If local repair is in place, doesnt that basically counter the whole HB>idea of having explicit routes ?? If CSPF or some other parallel HB>mechanism is in place, when would one want to employ local repair ?? You could have explicit routes at the headend may be couple of them in sequence. The main point to be noted here is that explicit routes does not mean no CSPF. There could be checks against the TE-DB to ensure that require bandwidth/attributes (affinity) is available along an explicitly specified path. The other assumption that local repair makes is that the repair is "temporary". It does send a PathErr back to the headend with error-code=25 (notification) and error-value=3 (tunnel locally repaired). Upon receiving such an error, the headend is at liberty to pick an alternate path be it explicit or dynamic. HB> HB>3. It would seem unlikely that a label subobject be present in the Route HB>Record Object in a Path message. If there is a label subobject in a Path HB>message, should this be flagged an error ?? Again this seems to be quite clear in the draft: 4.4.3. Processing RRO Typically, a node initiates an RSVP session by adding the RRO to the Path message. The initial RRO contains only one subobject - the sender's IP addresses. If the node also desires label recording, it sets the Label_Recording flag in the SESSION_ATTRIBUTE object. When a Path message containing an RRO is received by an intermediate router, the router stores a copy of it in the Path State Block. The RRO is then used in the next Path refresh event for formatting Path messages. When a new Path message is to be sent, the router adds a new subobject to the RRO and appends the resulting RRO to the Path message before transmission. Hope this helps. -ajay HB> HB>Any/all help will be greatly appreciated. HB> HB> -- Ajay Simha MPLS Deployment Engineer IOS Technology Division (919) 392-3141 "Study as if you were to live forever Live as if you were to die tomorrow" - Mahatma Gandhi From owner-mpls@UU.NET Sun Nov 25 19:29:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26273 for ; Sun, 25 Nov 2001 19:29:05 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqsv11465; Mon, 26 Nov 2001 00:28:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqsv04684 for mpls-outgoing; Mon, 26 Nov 2001 00:28:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlqsv04679 for ; Mon, 26 Nov 2001 00:28:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlqsv16578 for ; Mon, 26 Nov 2001 00:28:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqsv14064 for ; Mon, 26 Nov 2001 00:27:49 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA14854 for ; Sun, 25 Nov 2001 19:28:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA16518 for mpls@uu.net; Sun, 25 Nov 2001 19:28:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqsv04642 for ; Mon, 26 Nov 2001 00:27:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlqsv02907 for ; Mon, 26 Nov 2001 00:26:59 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: uzura.cisco.com [64.102.17.77]) id QQlqsv12221 for ; Mon, 26 Nov 2001 00:26:46 GMT Received: from ASIMHA-W2K.cisco.com (sjc-vpn1-673.cisco.com [10.21.98.161]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA24606; Sun, 25 Nov 2001 19:26:57 -0500 (EST) Date: Sun, 25 Nov 2001 19:25:58 -0500 (Eastern Standard Time) From: Ajay Simha To: Krishnakanth Rao cc: mpls@UU.NET Subject: Re: mapping of traffic to tunnels In-Reply-To: <00eb01c17245$a9eb3b00$6900a8c0@CPQITPLTECH4> Message-ID: X-X-Sender: asimha@uzura.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 21 Nov 2001, Krishnakanth Rao wrote: With all due respect.... this is NOT a Cisco alias so let us not waste everyone else's time... -ajay KR>I have configured an MPLS tunnel in Cisco IOS using the following commands KR> interface tunnel1 KR> ip unnumbered loopback 1 KR> tunnel destination 1.1.1.1 KR> tunnel mode mpls traffic-eng KR> tunnel mpls traffic-eng autoroute announce KR> tunnel mpls traffic-eng bandwidth 1000 KR> tunnel mpls traffic-eng priority 1 1 KR> tunnel mpls traffic-eng path-option 1 dynamic KR> KR>what is the command to map a traffic belonging to particular FEC(having KR>a particular DSCP or having a particular address prefix) to this tunnel KR>? KR> KR> -- Ajay Simha MPLS Deployment Engineer IOS Technology Division (919) 392-3141 "Study as if you were to live forever Live as if you were to die tomorrow" - Mahatma Gandhi From owner-mpls@UU.NET Mon Nov 26 08:37:33 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25678 for ; Mon, 26 Nov 2001 08:37:33 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlquw24018; Mon, 26 Nov 2001 13:33:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQlquw10058 for mpls-outgoing; Mon, 26 Nov 2001 13:33:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlquw10053 for ; Mon, 26 Nov 2001 13:33:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlquw01159 for ; Mon, 26 Nov 2001 13:32:12 GMT Received: from smtp4.cluster.oleane.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp4.cluster.oleane.net [195.25.12.62]) id QQlquw11141 for ; Mon, 26 Nov 2001 13:32:18 GMT Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp4.cluster.oleane.net with SMTP id fAQDWAc33936 for ; Mon, 26 Nov 2001 14:32:11 +0100 (CET) Message-ID: <00b001c17680$538c9c60$0201a8c0@oleane.com> Reply-To: "Michel Gosse" From: "Michel Gosse" To: Subject: MPLS World 2002 Date: Mon, 26 Nov 2001 14:43:26 +0100 Organization: Upper Side Conferences MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01C17688.B4B25360" 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 This is a multi-part message in MIME format. ------=_NextPart_000_00AD_01C17688.B4B25360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The MPLS World Congress early registration discount will end next = december 15. Please refer to: http://www.upperside.fr/congress02/mplsworld2002.htm Michel Gosse MPLS World News http://www.mplsworld.com ------=_NextPart_000_00AD_01C17688.B4B25360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The MPLS World Congress early registration discount = will end=20 next december 15.
Please refer to: http://www.= upperside.fr/congress02/mplsworld2002.htm
 
 
Michel Gosse
 
MPLS World News
http://www.mplsworld.com
------=_NextPart_000_00AD_01C17688.B4B25360-- From owner-mpls@UU.NET Mon Nov 26 10:58:05 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06011 for ; Mon, 26 Nov 2001 10:58:04 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqvf10650; Mon, 26 Nov 2001 15:54:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqvf28827 for mpls-outgoing; Mon, 26 Nov 2001 15:54:40 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqvf28822 for ; Mon, 26 Nov 2001 15:54: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 QQlqvf01204 for ; Mon, 26 Nov 2001 15:53:55 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQlqvf05490 for ; Mon, 26 Nov 2001 15:53: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 KAA29913 for ; Mon, 26 Nov 2001 10:53: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 KAA15172 for ; Mon, 26 Nov 2001 10:53:51 -0500 (EST) Message-ID: <3C0265FB.8CF70958@marconi.com> Date: Mon, 26 Nov 2001 10:55:39 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Three RSVP-TE specific questions. References: <3BFE0DCF.5040400@ipinfusion.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Haseeb Budhani wrote: > > I'd like to get help on the following three issues: > > 1. Is it possible to have different types of subojects -- IPv6 and > IPv4 -- in an ERO object ?? In case I missed it, the draft doesnt > allow or explicitly forbid this ... it is permitted. Of course, when a router identifies a v6 subobject as the next-hop, it must be able to determine the next-hop address needed to reach that v6 address (probably via the local routing table.) > 2. If local repair is in place, doesnt that basically counter the > whole idea of having explicit routes ?? If CSPF or some other > parallel mechanism is in place, when would one want to employ local > repair ?? Local repair is only used in the case where the ERO-specified path is temporarily broken. It exists to temporarily find another path (which may not be optimal) in order to keep data-plane traffic flowing while a new ERO is generated to replace the failed one. > 3. It would seem unlikely that a label subobject be present in the > Route Record Object in a Path message. If there is a label subobject > in a Path message, should this be flagged an error ?? Why? What would break if it was present? What purpose is served in generating errors and tearing down state because something of no consequense appears out of place? -- David From owner-mpls@UU.NET Mon Nov 26 12:22:05 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14081 for ; Mon, 26 Nov 2001 12:22:05 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqvl25920; Mon, 26 Nov 2001 17:19:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqvl13953 for mpls-outgoing; Mon, 26 Nov 2001 17:19:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlqvl13948 for ; Mon, 26 Nov 2001 17:19:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqvl02373 for ; Mon, 26 Nov 2001 17:18:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqvl22322 for ; Mon, 26 Nov 2001 17:17:49 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA11060 for ; Mon, 26 Nov 2001 12:18:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA29473 for mpls@uu.net; Mon, 26 Nov 2001 12:18:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlqvl13866 for ; Mon, 26 Nov 2001 17:17:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqvk26748 for ; Mon, 26 Nov 2001 17:14:56 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqvk16821 for ; Mon, 26 Nov 2001 17:14:43 GMT Received: from telescope.cisco.com (telescope.cisco.com [161.44.166.204]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA10682 for ; Mon, 26 Nov 2001 12:14:55 -0500 (EST) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA20055 for ; Mon, 26 Nov 2001 12:14:55 -0500 (EST) Message-Id: <200111261714.MAA20055@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Time to set the agenda Date: Mon, 26 Nov 2001 12:14:55 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Please send any agenda request to me and Vijay. Tnx George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Mon Nov 26 13:44:49 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19927 for ; Mon, 26 Nov 2001 13:44:49 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqvq21696; Mon, 26 Nov 2001 18:41:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqvq12380 for mpls-outgoing; Mon, 26 Nov 2001 18:40:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqvq12375 for ; Mon, 26 Nov 2001 18:40: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 QQlqvq01782 for ; Mon, 26 Nov 2001 18:40:23 GMT Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157]) id QQlqvq20160 for ; Mon, 26 Nov 2001 18:40:29 GMT Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fAQIdhd22422 for ; Mon, 26 Nov 2001 13:39:43 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 26 Nov 2001 13:40:18 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 13:39:14 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34D614B3@zcard0ka.ca.nortel.com> From: "David Allan" To: mpls Subject: MIBs and TTL Date: Mon, 26 Nov 2001 13:39:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C176A9.A4FD0340" 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_01C176A9.A4FD0340 Content-Type: text/plain; charset="ISO-8859-1" Quick question, From what I can see, none of the MPLS MIBs seem to acknowledge TTL. There's a couple of issues to address: - what to do at the egress of a non-TTL capable link. (e.g. how much to decrement the value). This looks like an LSR-MIB "in-segment" table issue. - whether to use pipe or uniform model at an LSR ingress point (which looks like it hits a bunch of places, FTN, MPLS-TE and LSR). Did I miss it somewhere? thanks Dave ------_=_NextPart_001_01C176A9.A4FD0340 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable MIBs and TTL

Quick question,

From what I can see, none of the MPLS MIBs seem to = acknowledge TTL. There's a couple of issues to address:

- what to do at the egress of a non-TTL capable link. = (e.g. how much to decrement the value). This looks like an LSR-MIB = "in-segment" table issue.

- whether to use pipe or uniform model at an LSR = ingress point (which looks like it hits a bunch of places, FTN, MPLS-TE = and LSR).

Did I miss it somewhere?

thanks
Dave

 
 

------_=_NextPart_001_01C176A9.A4FD0340-- From owner-mpls@UU.NET Mon Nov 26 14:13:51 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22441 for ; Mon, 26 Nov 2001 14:13:51 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqvs09927; Mon, 26 Nov 2001 19:10:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqvs03262 for mpls-outgoing; Mon, 26 Nov 2001 19:10:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqvs03257 for ; Mon, 26 Nov 2001 19:10:24 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqvs16391 for ; Mon, 26 Nov 2001 19:10:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqvs17691 for ; Mon, 26 Nov 2001 19:09:49 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA26227 for ; Mon, 26 Nov 2001 14:10:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA03735 for mpls@uu.net; Mon, 26 Nov 2001 14:10:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqvs03139 for ; Mon, 26 Nov 2001 19:08:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqvs08992 for ; Mon, 26 Nov 2001 19:08:25 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqvs15316 for ; Mon, 26 Nov 2001 19:08:12 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.167.72]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA25971; Mon, 26 Nov 2001 14:08:25 -0500 (EST) Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126]) by bucket.cisco.com (Mirapoint) with ESMTP id AAF87642; Mon, 26 Nov 2001 14:08:24 -0500 (EST) Message-Id: <4.3.2.7.2.20011126140642.0268f9c8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Nov 2001 14:09:11 -0500 To: "David Allan" From: Thomas Nadeau Subject: Re: MIBs and TTL Cc: mpls In-Reply-To: <3549C09B853DD5119B540002A52CDD34D614B3@zcard0ka.ca.nortel. com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_15475222==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_15475222==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed > From what I can see, none of the MPLS MIBs seem to acknowledge TTL. > There's a couple of issues to address: > >- what to do at the egress of a non-TTL capable link. (e.g. how much to >decrement the value). This looks like an LSR-MIB "in-segment" table issue. That is true, but to-date, no neither the vendors implementing them nor the SPs using them one has found it necessary to add them. What would you like to see? >- whether to use pipe or uniform model at an LSR ingress point >(which looks like it hits a bunch of places, FTN, MPLS-TE and LSR). I don't understand what you mean by a "pipe or uniform model" above. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. --=====================_15475222==_.ALT Content-Type: text/html; charset="us-ascii"
From what I can see, none of the MPLS MIBs seem to acknowledge TTL. There's a couple of issues to address:

- what to do at the egress of a non-TTL capable link. (e.g. how much to decrement the value). This looks like an LSR-MIB "in-segment" table issue.

        That is true, but to-date, no neither the vendors implementing them nor the
SPs using them one has found it necessary to add them. What would you like to see?

- whether to use pipe or uniform model at an LSR ingress point
(which looks like it hits a bunch of places, FTN, MPLS-TE and LSR).

        I don't understand what you mean by a "pipe or uniform model" above.

        --Tom




------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. --=====================_15475222==_.ALT-- From owner-mpls@UU.NET Mon Nov 26 14:55:07 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25272 for ; Mon, 26 Nov 2001 14:55:07 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqvv20010; Mon, 26 Nov 2001 19:52:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqvv06640 for mpls-outgoing; Mon, 26 Nov 2001 19:52:05 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqvv06635 for ; Mon, 26 Nov 2001 19:52: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 QQlqvv05857 for ; Mon, 26 Nov 2001 19:50:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqvv16570 for ; Mon, 26 Nov 2001 19:49:49 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA02086 for ; Mon, 26 Nov 2001 14:50:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA06038 for mpls@uu.net; Mon, 26 Nov 2001 14:50:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqvv06421 for ; Mon, 26 Nov 2001 19:48:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlqvv28003 for ; Mon, 26 Nov 2001 19:47:32 GMT Received: from sj-msg-core-4.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10]) id QQlqvv01339 for ; Mon, 26 Nov 2001 19:47:19 GMT Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fAQJHXl21524; Mon, 26 Nov 2001 11:17:33 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id fAQJHWN19422; Mon, 26 Nov 2001 11:17:32 -0800 (PST) Received: from BORA-W2K1.cisco.com (dhcp-171-69-39-121.cisco.com [171.69.39.121]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA00131; Mon, 26 Nov 2001 11:17:30 -0800 (PST) Message-Id: <4.3.2.7.2.20011126111404.02688938@mira-sjc5-9.cisco.com> X-Sender: bora@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Nov 2001 11:15:57 -0800 To: Thomas Nadeau From: Bora Akyol Subject: Re: MIBs and TTL Cc: "David Allan" , mpls In-Reply-To: <4.3.2.7.2.20011126140642.0268f9c8@bucket.cisco.com> References: <3549C09B853DD5119B540002A52CDD34D614B3@zcard0ka.ca.nortel. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk For a discussion of TTL in MPLS networks, you may want to see draft-agarwal-mpls-ttl-01.txt. We are planning on asking the WG to make this a WG document at this IETF. (We have already asked on the list as well). Bora At 02:09 PM 11/26/2001 -0500, Thomas Nadeau wrote: >> From what I can see, none of the MPLS MIBs seem to acknowledge TTL. >> There's a couple of issues to address: >> >>- what to do at the egress of a non-TTL capable link. (e.g. how much to >>decrement the value). This looks like an LSR-MIB "in-segment" table issue. > > That is true, but to-date, no neither the vendors implementing > them nor the >SPs using them one has found it necessary to add them. What would you like >to see? > >>- whether to use pipe or uniform model at an LSR ingress point >>(which looks like it hits a bunch of places, FTN, MPLS-TE and LSR). > > I don't understand what you mean by a "pipe or uniform model" above. > > --Tom > From owner-mpls@UU.NET Mon Nov 26 14:55:25 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25310 for ; Mon, 26 Nov 2001 14:55:25 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqvv22277; Mon, 26 Nov 2001 19:53:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqvv06658 for mpls-outgoing; Mon, 26 Nov 2001 19:52:37 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqvv06650 for ; Mon, 26 Nov 2001 19:52: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 QQlqvv09778 for ; Mon, 26 Nov 2001 19:51:18 GMT Received: from zcars0m9.nortelnetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157]) id QQlqvv18404 for ; Mon, 26 Nov 2001 19:51:04 GMT Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fAQJocd05608 for ; Mon, 26 Nov 2001 14:50:38 -0500 (EST) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 26 Nov 2001 14:51:03 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 14:50:00 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34D61612@zcard0ka.ca.nortel.com> From: "David Allan" To: Thomas Nadeau Cc: mpls Subject: RE: MIBs and TTL Date: Mon, 26 Nov 2001 14:49:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C176B3.8793F9D0" 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_01C176B3.8793F9D0 Content-Type: text/plain; charset="ISO-8859-1" Thomas: Pipe or uniform is the terminology adopted in the MPLS diffserv draft and carried forward into http://www.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-01.txt The short story is: - for uniform model TTL is independent of MPLS level. You copy TTL values up and down the stack as you push and pop. - for pipe model, TTL is unique to each MPLS level. So configuring this looks painful (get it from incoming label before x-connect entry, or get it from incoming IP payload, or set it to fixed value at ingress) :-(. As to how to handle non-TTL capable links, an unsigned object added to InterfaceConfEntry (InterfaceTTLDec?) with a default value of 1 should be all that is required. The only wrinkle being that I don't fully grok pop and swap to be sure that a non-ttl link label under the top label would work correctly. thanks Dave -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@cisco.com] Sent: Monday, November 26, 2001 2:09 PM To: Allan, David [CAR:NS00:EXCH] Cc: mpls Subject: Re: MIBs and TTL From what I can see, none of the MPLS MIBs seem to acknowledge TTL. There's a couple of issues to address: - what to do at the egress of a non-TTL capable link. (e.g. how much to decrement the value). This looks like an LSR-MIB "in-segment" table issue. That is true, but to-date, no neither the vendors implementing them nor the SPs using them one has found it necessary to add them. What would you like to see? - whether to use pipe or uniform model at an LSR ingress point (which looks like it hits a bunch of places, FTN, MPLS-TE and LSR). I don't understand what you mean by a "pipe or uniform model" above. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. ------_=_NextPart_001_01C176B3.8793F9D0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: MIBs and TTL

Thomas:

Pipe or uniform is the terminology adopted in the = MPLS diffserv draft and carried forward into
http://www.ietf.org/internet-drafts/draft-agarwal-mpls= -ttl-01.txt

The short story is:
- for uniform model TTL is independent of MPLS = level. You copy TTL values up and down the stack as you push and = pop.
- for pipe model, TTL is unique to each MPLS = level.
So configuring this looks painful (get it from = incoming label before x-connect entry, or get it from incoming IP = payload, or set it to fixed value at ingress) :-(.

As to how to handle non-TTL capable links, an = unsigned object added to InterfaceConfEntry (InterfaceTTLDec?) with a = default value of 1 should be all that is required. The only wrinkle = being that I don't fully grok pop and swap to be sure that a non-ttl = link label under the top label would work correctly.

thanks
Dave


-----Original Message-----
From: Thomas Nadeau [mailto:tnadeau@cisco.com]
Sent: Monday, November 26, 2001 2:09 PM
To: Allan, David [CAR:NS00:EXCH]
Cc: mpls
Subject: Re: MIBs and TTL




From what I can see, none of the MPLS MIBs seem to = acknowledge TTL. There's a couple of issues to address:

- what to do at the egress of a non-TTL capable link. = (e.g. how much to decrement the value). This looks like an LSR-MIB = "in-segment" table issue.

        That is = true, but to-date, no neither the vendors implementing them nor the =
SPs using them one has found it necessary to add = them. What would you like to see?


- whether to use pipe or uniform model at an LSR = ingress point
(which looks like it hits a bunch of places, FTN, = MPLS-TE and LSR).

        I don't = understand what you mean by a "pipe or uniform model" = above.

        = --Tom





---------------------------------------------------------------= ---------
Mathematics is the supreme nostalgia of our time. =

------_=_NextPart_001_01C176B3.8793F9D0-- From owner-mpls@UU.NET Mon Nov 26 15:05:12 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26296 for ; Mon, 26 Nov 2001 15:05:12 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqvw29137; Mon, 26 Nov 2001 20:02:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqvw17661 for mpls-outgoing; Mon, 26 Nov 2001 20:02:33 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqvw17650 for ; Mon, 26 Nov 2001 20:02:28 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqvw10071 for ; Mon, 26 Nov 2001 20:02:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqvw05004 for ; Mon, 26 Nov 2001 20:01:49 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA03898 for ; Mon, 26 Nov 2001 15:02:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA07219 for mpls@uu.net; Mon, 26 Nov 2001 15:02:01 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqvw13342 for ; Mon, 26 Nov 2001 20:01: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 QQlqvv04446 for ; Mon, 26 Nov 2001 19:59:38 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqvv01318 for ; Mon, 26 Nov 2001 19:59:24 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.167.72]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA03479; Mon, 26 Nov 2001 14:59:37 -0500 (EST) Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126]) by bucket.cisco.com (Mirapoint) with ESMTP id AAF88621; Mon, 26 Nov 2001 14:59:36 -0500 (EST) Message-Id: <4.3.2.7.2.20011126145804.02687160@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Nov 2001 15:00:23 -0500 To: "David Allan" From: Thomas Nadeau Subject: RE: MIBs and TTL Cc: mpls In-Reply-To: <3549C09B853DD5119B540002A52CDD34D61612@zcard0ka.ca.nortel. com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_18547149==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_18547149==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed >Pipe or uniform is the terminology adopted in the MPLS diffserv draft and >carried forward into >http://www.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-01.txt > Sorry, from the original context, I wasn't sure. >The short story is: >- for uniform model TTL is independent of MPLS level. You copy TTL values >up and down the stack as you push and pop. >- for pipe model, TTL is unique to each MPLS level. >So configuring this looks painful (get it from incoming label before >x-connect entry, or get it from incoming IP payload, or set it to fixed >value at ingress) :-(. It looks painful, but is flexible as to support different implementations. >As to how to handle non-TTL capable links, an unsigned object added to >InterfaceConfEntry (InterfaceTTLDec?) with a default value of 1 should be >all that is required. The only wrinkle being that I don't fully grok pop >and swap to be sure that a non-ttl link label under the top label would >work correctly. This is certainly an option. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. --=====================_18547149==_.ALT Content-Type: text/html; charset="us-ascii"
Pipe or uniform is the terminology adopted in the MPLS diffserv draft and carried forward into
http://www.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-01.txt

        Sorry, from the original context, I wasn't sure.

The short story is:
- for uniform model TTL is independent of MPLS level. You copy TTL values up and down the stack as you push and pop.
- for pipe model, TTL is unique to each MPLS level.
So configuring this looks painful (get it from incoming label before x-connect entry, or get it from incoming IP payload, or set it to fixed value at ingress) :-(.

        It looks painful, but is flexible as to support different implementations.

As to how to handle non-TTL capable links, an unsigned object added to InterfaceConfEntry (InterfaceTTLDec?) with a default value of 1 should be all that is required. The only wrinkle being that I don't fully grok pop and swap to be sure that a non-ttl link label under the top label would work correctly.

        This is certainly an option.

        --Tom
        



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. --=====================_18547149==_.ALT-- From owner-mpls@UU.NET Mon Nov 26 15:49:49 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00025 for ; Mon, 26 Nov 2001 15:49:49 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqvz16923; Mon, 26 Nov 2001 20:47:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqvz00238 for mpls-outgoing; Mon, 26 Nov 2001 20:46:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqvz00233 for ; Mon, 26 Nov 2001 20:46: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 QQlqvy11526 for ; Mon, 26 Nov 2001 20:44:11 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandmail.sandburst.com [216.57.132.42]) id QQlqvy12172 for ; Mon, 26 Nov 2001 20:44:17 GMT Message-ID: <3C02A994.B2E4286C@sandburst.com> Date: Mon, 26 Nov 2001 15:44:04 -0500 From: Eric Gray MIME-Version: 1.0 To: David Allan Cc: mpls Subject: Re: MIBs and TTL References: <3549C09B853DD5119B540002A52CDD34D614B3@zcard0ka.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, For non-TTL capable links, the TTL should have been decremented at the ingress, rather than the egress. The ingress - for example - may decrement by one, or by the hop-count. If these are the choices, the actual decrement at the ingress will depend on the model of the LSP. You wrote: > > > Quick question, > > From what I can see, none of the MPLS MIBs seem to acknowledge TTL. There's a couple of issues to address: > > - what to do at the egress of a non-TTL capable link. (e.g. how much to decrement the value). This looks like an LSR-MIB "in-segment" table issue. > > - whether to use pipe or uniform model at an LSR ingress point (which looks like it hits a bunch of places, FTN, MPLS-TE and LSR). > > Did I miss it somewhere? > > thanks > Dave > > > -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray From owner-mpls@UU.NET Mon Nov 26 16:04:39 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01359 for ; Mon, 26 Nov 2001 16:04:39 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqwa09680; Mon, 26 Nov 2001 21:01:53 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqwa05360 for mpls-outgoing; Mon, 26 Nov 2001 21:01:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqwa05320 for ; Mon, 26 Nov 2001 21:01:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlqwa25704 for ; Mon, 26 Nov 2001 21:00:19 GMT Received: from zcars0m9.nortelnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars0m9.nortelnetworks.com [47.129.242.157]) id QQlqwa07387 for ; Mon, 26 Nov 2001 21:00:25 GMT Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fAQKxcd16221 for ; Mon, 26 Nov 2001 15:59:38 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 26 Nov 2001 16:00:06 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 15:59:02 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34D6178F@zcard0ka.ca.nortel.com> From: "David Allan" To: Thomas Nadeau Cc: mpls Subject: RE: MIBs and TTL Date: Mon, 26 Nov 2001 15:59:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C176BD.2CEEF980" 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_01C176BD.2CEEF980 Content-Type: text/plain; charset="ISO-8859-1" I meant painful from the point of view of the number of places it could appear in the MIBs (which might not actually be that bad and looks like it could be confined to the XCTable). I'd assume the most useful definition would be configurable per LSP with a default LSR setting. (per LSP default is default specified for the LSR). cheers Dave. -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@cisco.com] Sent: Monday, November 26, 2001 3:00 PM To: Allan, David [CAR:NS00:EXCH] Cc: mpls Subject: RE: MIBs and TTL Pipe or uniform is the terminology adopted in the MPLS diffserv draft and carried forward into http://www.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-01.txt Sorry, from the original context, I wasn't sure. The short story is: - for uniform model TTL is independent of MPLS level. You copy TTL values up and down the stack as you push and pop. - for pipe model, TTL is unique to each MPLS level. So configuring this looks painful (get it from incoming label before x-connect entry, or get it from incoming IP payload, or set it to fixed value at ingress) :-(. It looks painful, but is flexible as to support different implementations. As to how to handle non-TTL capable links, an unsigned object added to InterfaceConfEntry (InterfaceTTLDec?) with a default value of 1 should be all that is required. The only wrinkle being that I don't fully grok pop and swap to be sure that a non-ttl link label under the top label would work correctly. This is certainly an option. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. ------_=_NextPart_001_01C176BD.2CEEF980 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
I=20 meant painful from the point of view of the number of places it could = appear in=20 the MIBs (which might not actually be that bad and looks like it could = be=20 confined to the XCTable).  I'd assume the most useful definition = would=20 be configurable per LSP with a default LSR setting. (per LSP = default is=20 default specified for the LSR).
 
cheers
Dave.
-----Original Message-----
From: Thomas Nadeau=20 [mailto:tnadeau@cisco.com]
Sent: Monday, November 26, 2001 = 3:00=20 PM
To: Allan, David [CAR:NS00:EXCH]
Cc:=20 mpls
Subject: RE: MIBs and TTL
Pipe or uniform is the = terminology=20 adopted in the MPLS diffserv draft and carried forward into =
http://www.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-01.txt=

        = Sorry,=20 from the original context, I wasn't sure.

The short story = is:
- for uniform model TTL is = independent of=20 MPLS level. You copy TTL values up and down the stack as you push = and=20 pop.
- for pipe = model, TTL is=20 unique to each MPLS level.
So=20 configuring this looks painful (get it from incoming label before = x-connect=20 entry, or get it from incoming IP payload, or set it to fixed value = at=20 ingress)=20 = :-(.

      &= nbsp; It=20 looks painful, but is flexible as to support different=20 implementations.

As to how to handle = non-TTL=20 capable links, an unsigned object added to InterfaceConfEntry=20 (InterfaceTTLDec?) with a default value of 1 should be all that is = required.=20 The only wrinkle being that I don't fully grok pop and swap to be = sure that=20 a non-ttl link label under the top label would work=20 = correctly.

     &= nbsp;  This=20 is certainly an=20 = option.

        --Tom
        



=
-------------------------------------------------------------------= -----
Mathematics=20 is the supreme nostalgia of our time. ------_=_NextPart_001_01C176BD.2CEEF980-- From owner-mpls@UU.NET Mon Nov 26 16:29:17 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03247 for ; Mon, 26 Nov 2001 16:29:17 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqwb13613; Mon, 26 Nov 2001 21:26:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqwb22217 for mpls-outgoing; Mon, 26 Nov 2001 21:26:13 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlqwb22212 for ; Mon, 26 Nov 2001 21:26:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqwb23619 for ; Mon, 26 Nov 2001 21:25:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqwb11268 for ; Mon, 26 Nov 2001 21:24:49 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA15252 for ; Mon, 26 Nov 2001 16:25:03 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA11853 for mpls@uu.net; Mon, 26 Nov 2001 16:25:03 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqwb22065 for ; Mon, 26 Nov 2001 21:24:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqwb09329 for ; Mon, 26 Nov 2001 21:23:55 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqwb09634 for ; Mon, 26 Nov 2001 21:23:41 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.167.72]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA15071; Mon, 26 Nov 2001 16:23:55 -0500 (EST) Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126]) by bucket.cisco.com (Mirapoint) with ESMTP id AAF90204; Mon, 26 Nov 2001 16:23:54 -0500 (EST) Message-Id: <4.3.2.7.2.20011126160800.026e33a0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Nov 2001 16:24:41 -0500 To: "David Allan" From: Thomas Nadeau Subject: RE: MIBs and TTL Cc: mpls In-Reply-To: <3549C09B853DD5119B540002A52CDD34D6178F@zcard0ka.ca.nortel. com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_23605102==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_23605102==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed >I meant painful from the point of view of the number of places it could >appear in the MIBs (which might not actually be that bad and looks like it >could be confined to the XCTable). I'd assume the most useful definition >would be configurable per LSP with a default LSR setting. (per LSP default >is default specified for the LSR). Appearing in more than one place is not such a bad thing if it is useful, and not done too often. --Tom > >cheers >Dave. >>-----Original Message----- >>From: Thomas Nadeau [mailto:tnadeau@cisco.com] >>Sent: Monday, November 26, 2001 3:00 PM >>To: Allan, David [CAR:NS00:EXCH] >>Cc: mpls >>Subject: RE: MIBs and TTL >> >> >>>Pipe or uniform is the terminology adopted in the MPLS diffserv draft >>>and carried forward into >>>http://www.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-01.txt >>> >> >> Sorry, from the original context, I wasn't sure. >> >>>The short story is: >>>- for uniform model TTL is independent of MPLS level. You copy TTL >>>values up and down the stack as you push and pop. >>>- for pipe model, TTL is unique to each MPLS level. >>>So configuring this looks painful (get it from incoming label before >>>x-connect entry, or get it from incoming IP payload, or set it to fixed >>>value at ingress) :-(. >> >> It looks painful, but is flexible as to support different >> implementations. >> >>>As to how to handle non-TTL capable links, an unsigned object added to >>>InterfaceConfEntry (InterfaceTTLDec?) with a default value of 1 should >>>be all that is required. The only wrinkle being that I don't fully grok >>>pop and swap to be sure that a non-ttl link label under the top label >>>would work correctly. >> >> This is certainly an option. >> >> --Tom >> >> >> >> >>------------------------------------------------------------------------ >>Mathematics is the supreme nostalgia of our time. ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. --=====================_23605102==_.ALT Content-Type: text/html; charset="us-ascii"
I meant painful from the point of view of the number of places it could appear in the MIBs (which might not actually be that bad and looks like it could be confined to the XCTable).  I'd assume the most useful definition would be configurable per LSP with a default LSR setting. (per LSP default is default specified for the LSR).

        Appearing in more than one place is not such a bad thing
if it is useful, and not done too often.

        --Tom


 
cheers
Dave.
-----Original Message-----
From: Thomas Nadeau [mailto:tnadeau@cisco.com]
Sent: Monday, November 26, 2001 3:00 PM
To: Allan, David [CAR:NS00:EXCH]
Cc: mpls
Subject: RE: MIBs and TTL


Pipe or uniform is the terminology adopted in the MPLS diffserv draft and carried forward into
http://www.ietf.org/internet-drafts/draft-agarwal-mpls-ttl-01.txt

        Sorry, from the original context, I wasn't sure.

The short story is:
- for uniform model TTL is independent of MPLS level. You copy TTL values up and down the stack as you push and pop.
- for pipe model, TTL is unique to each MPLS level.
So configuring this looks painful (get it from incoming label before x-connect entry, or get it from incoming IP payload, or set it to fixed value at ingress) :-(.

        It looks painful, but is flexible as to support different implementations.

As to how to handle non-TTL capable links, an unsigned object added to InterfaceConfEntry (InterfaceTTLDec?) with a default value of 1 should be all that is required. The only wrinkle being that I don't fully grok pop and swap to be sure that a non-ttl link label under the top label would work correctly.

        This is certainly an option.

        --Tom
        



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. --=====================_23605102==_.ALT-- From owner-mpls@UU.NET Mon Nov 26 19:35:26 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16248 for ; Mon, 26 Nov 2001 19:35:25 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqwo29036; Tue, 27 Nov 2001 00:32:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqwo02106 for mpls-outgoing; Tue, 27 Nov 2001 00:32:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlqwo02099 for ; Tue, 27 Nov 2001 00:32:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqwo23395 for ; Tue, 27 Nov 2001 00:31:12 GMT Received: from 8848.net by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [211.99.202.115]) id QQlqwo22493 for ; Tue, 27 Nov 2001 00:30:56 GMT Received: from 8848.net([10.1.0.100]) by 8848.net(JetMail 2.5.3.0) with SMTP id jmc3c032de8; Tue, 27 Nov 2001 00:28:47 -0000 Received: from cmr0.ash.ops.us.uu.net([198.5.241.38]) by 8848.net(JetMail 2.5.3.0) with SMTP id jm14b3bfe37ae; Fri, 23 Nov 2001 06:28:09 -0000 Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqir21246; Fri, 23 Nov 2001 06:26:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqir19795 for mpls-outgoing; Fri, 23 Nov 2001 06:25:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlqir19790 for ; Fri, 23 Nov 2001 06:25:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlqir05158 for ; Fri, 23 Nov 2001 06:24:48 GMT Received: from elrond.trinicom.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [63.149.136.227]) id QQlqir10084 for ; Fri, 23 Nov 2001 06:24:53 GMT Received: (qmail 18126 invoked by uid 30); 23 Nov 2001 06:24:46 -0000 Date: 23 Nov 2001 06:24:46 -0000 Message-ID: <20011123062446.18125.qmail@elrond.trinicom.com> To: krishnakanth.rao@cominsights.com, mpls@UU.NET Subject: RE: MPLS resource class From: Sean Crocker X-Mailer: Postaci 1.1.0 (ftp://ftp.onar.com.tr/pub/linux/postaci) X-Comment: This message was sent from 208.232.192.18 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary = be2a6ef16e3fdcd85f7c4d7245cc8030c Sender: owner-mpls@UU.NET Precedence: bulk This is a MIME encoded message. --be2a6ef16e3fdcd85f7c4d7245cc8030c Content-Type: text/plain Content-Transfer-Encoding: 7bit Krishnakanth, >The ietf draft - draft-ietf-mpls-cr-ldp-05.txt (Constraint-Based LSP Setup using LDP) talks about the resource class . What kind of resources are indicated by this class. Could somebody explain it in detail. It's simply up to the administrator what resources are indicated. An administrator may want different resource class values depending on bandwidth (oc12 vs oc48), something wierder like queueing capabilities on outbound interfaces, or many other things... then LSP ingresses can be configured to use these links or not use them depending on the values. I don't think there is a range set aside for defined, "standard" values. Not sure if there has been any discussion to do so, but I suppose the aim of such would be for ease of configuration of constrained LSPs between domains. Also see http://www.ietf.org/rfc/rfc2702.txt sections 6.2 and 5.6.3 Sean > >Krishnakanth --------------------------------------- This message was sent by www.trinicom.com Webmail. --be2a6ef16e3fdcd85f7c4d7245cc8030c-- From owner-mpls@UU.NET Tue Nov 27 03:38:13 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16528 for ; Tue, 27 Nov 2001 03:38:13 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqxu25308; Tue, 27 Nov 2001 08:37:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqxu09965 for mpls-outgoing; Tue, 27 Nov 2001 08:37:21 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqxu09952 for ; Tue, 27 Nov 2001 08:37:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlqxu27633 for ; Tue, 27 Nov 2001 08:35:24 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQlqxu09919 for ; Tue, 27 Nov 2001 08:35:10 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Nov 2001 14:13:34 +0530 Message-ID: From: "Gopinath G - CTD, Chennai." To: mpls@UU.NET Subject: Instance in CR-LDP Date: Tue, 27 Nov 2001 14:03:27 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Is there any relation between Instance in Tunnel table and LSP-Modification ? Thanks In Advance gopinathg From owner-mpls@UU.NET Tue Nov 27 04:09:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17047 for ; Tue, 27 Nov 2001 04:09:20 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqxw28813; Tue, 27 Nov 2001 09:08:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqxw01230 for mpls-outgoing; Tue, 27 Nov 2001 09:08:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqxw01224 for ; Tue, 27 Nov 2001 09:08: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 QQlqxw06464 for ; Tue, 27 Nov 2001 09:08:25 GMT From: neil.2.harrison@bt.com Received: from cbibipnt05.hc.bt.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQlqxw27991 for ; Tue, 27 Nov 2001 09:08:11 GMT Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35) id ; Tue, 27 Nov 2001 09:08:32 -0000 Message-ID: To: eric.gray@sandburst.com Cc: mpls@UU.NET Subject: RE: MIBs and TTL Date: Tue, 27 Nov 2001 09:08:04 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Eric....what happens if you decrement at an ingress by N say (N being the 'guessed/known' number of hops) and then protection switching occurs such that the hops change to M now.....does one have to re-set the ingress decrement to the new 'guess/known' number of hops? regards, Neil > -----Original Message----- > From: Eric Gray [mailto:eric.gray@sandburst.com] > Sent: 26 November 2001 20:44 > To: David Allan > Cc: mpls > Subject: Re: MIBs and TTL > > > David, > > For non-TTL capable links, the TTL should have been decremented at > the ingress, rather than the egress. The ingress - for example - may > decrement by one, or by the hop-count. If these are the choices, the > actual decrement at the ingress will depend on the model of the LSP. > From owner-mpls@UU.NET Tue Nov 27 09:48:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00700 for ; Tue, 27 Nov 2001 09:48:35 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqys11857; Tue, 27 Nov 2001 14:44:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqys01759 for mpls-outgoing; Tue, 27 Nov 2001 14:44:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlqys01752 for ; Tue, 27 Nov 2001 14:44:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqys28412 for ; Tue, 27 Nov 2001 14:44:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqys10440 for ; Tue, 27 Nov 2001 14:43:49 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA18362 for ; Tue, 27 Nov 2001 09:44:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA27233 for mpls@uu.net; Tue, 27 Nov 2001 09:44:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlqys01662 for ; Tue, 27 Nov 2001 14:43:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqys07052 for ; Tue, 27 Nov 2001 14:43:00 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlqys08902 for ; Tue, 27 Nov 2001 14:42:46 GMT Received: from bucket.cisco.com (mirapoint@bucket.cisco.com [161.44.167.72]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA18210; Tue, 27 Nov 2001 09:42:59 -0500 (EST) Received: from tnadeau-w2k.cisco.com (tnadeau-frame5.cisco.com [10.83.99.126]) by bucket.cisco.com (Mirapoint) with ESMTP id AAF97271; Tue, 27 Nov 2001 09:42:58 -0500 (EST) Message-Id: <4.3.2.7.2.20011127094258.02745868@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Nov 2001 09:43:44 -0500 To: "Gopinath G - CTD, Chennai." From: Thomas Nadeau Subject: Re: Instance in CR-LDP Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_85948116==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_85948116==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:03 PM 11/27/2001 +0530, Gopinath G - CTD, Chennai. wrote: >Hi > > Is there any relation between Instance in Tunnel table and >LSP-Modification ? I don't understand the question. Do you mean the tunnelInstanceID in the MPLS TE MIB's tunnelTable? What do you mean by "LSP modification?" --Tom >Thanks In Advance > >gopinathg ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. --=====================_85948116==_.ALT Content-Type: text/html; charset="us-ascii" At 02:03 PM 11/27/2001 +0530, Gopinath G - CTD, Chennai. wrote:
Hi

   Is there any relation between Instance in Tunnel table and
LSP-Modification ?

        I don't understand the question. Do you mean the tunnelInstanceID
in the MPLS TE MIB's tunnelTable?  What do you mean by "LSP
modification?"

        --Tom


Thanks In Advance

gopinathg



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time. --=====================_85948116==_.ALT-- From owner-mpls@UU.NET Tue Nov 27 11:07:29 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06016 for ; Tue, 27 Nov 2001 11:07:29 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqyy06314; Tue, 27 Nov 2001 16:04:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqyy07192 for mpls-outgoing; Tue, 27 Nov 2001 16:03:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlqyy07183 for ; Tue, 27 Nov 2001 16:03:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlqyy08821 for ; Tue, 27 Nov 2001 16:02:15 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQlqyy27462 for ; Tue, 27 Nov 2001 16:02: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 LAA12003 for ; Tue, 27 Nov 2001 11:02:13 -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 LAA08638 for ; Tue, 27 Nov 2001 11:02:13 -0500 (EST) Message-ID: <3C03B974.D996CE96@marconi.com> Date: Tue, 27 Nov 2001 11:04:04 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: RSVP Path without ADSPEC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit What type of reservation should an egress router generate when it receives an IntServ TSPEC and no ADSPEC? If the TSpec is using the deprecated CoS C-Type, it is obvious that best-effort is being requested. It is similarly obvious if the TSpec is using the IntServ Null service instead of the Token Bucket TSpec parameters. When the TSpec is using the Token Bucket TSpec parameters, the kind of reservation (Guaranteed, Controlled-Load or best-effort) is supposed to be determined by the presence or absence of service-specific fragments in the ADSPEC. RFC 2210 explicitly states that an egress router should not make a reservation using a particular service if that service's fragment is missing from the ADSPEC. But it appears that some vendors (broken, perhaps) generate ADSPEC objects with no service fragments, or they generate Path messages without ADSPEC objects altogether. What kind of service should the egress router reserve in this case? IMO, this means that the choice of service is "don't care", and the egress is free to choose any kind it wants. I personally think that best-effort is the best thing to do in this case, since it imposes the least impact on the rest of the network. I have been informed, however, that some implementations respond to this situation (missing ADSPEC or ADSPEC with no service fragments) by making a Controlled Load reservation, and that these implementation actually generate missing-ADSPEC Path messages when they want to request Controlled Load - meaning they are expecting everybody else to handle this ambiguous situation in the same way they do. What is this group's opinion here? I'm especially interested in hearing from the RSVP-TE draft authors in this regard. Finally, is there a way to signal best-effort other than Null service and the deprecated CoS object? I currently understand the IntServ RFCs such that a zero parameter means "don't care", therefore a Controlled-Load FLOWSPEC with all zeros for parameters should be synonymous with best-effort. Is this correct or should this actually imply a Controlled-Load reservation for zero resources (which is effectively a black-hole if traffic is policed.) Thanks in advance. -- David From owner-mpls@UU.NET Tue Nov 27 11:41:30 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08558 for ; Tue, 27 Nov 2001 11:41:29 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlqza02135; Tue, 27 Nov 2001 16:38:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQlqza18856 for mpls-outgoing; Tue, 27 Nov 2001 16:37:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlqza18851 for ; Tue, 27 Nov 2001 16:37:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlqza17584 for ; Tue, 27 Nov 2001 16:36:12 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandmail.sandburst.com [216.57.132.42]) id QQlqza00876 for ; Tue, 27 Nov 2001 16:35:59 GMT Message-ID: <3C03C0F6.ED6B19E9@sandburst.com> Date: Tue, 27 Nov 2001 11:36:06 -0500 From: Eric Gray MIME-Version: 1.0 To: neil.2.harrison@bt.com Cc: MPLS Mailing List Subject: Re: MIBs and TTL References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Neil, Three comments WRT this question: 1) This is one of the really good reasons why you might use the pipe model - you probably would not want to age a customer's packets differently because of an internal routing change (or - in your example - mishap); 2) Unless the LSR is patently incapable of being an intermediate LSR, it will almost certainly have stored the current hop-count for whatever Label it is presently using for any particular LSP; 3) If you're alluding to the idea that hop-count may not have been provided, I believe this to be very unlikely in the non-TTL capable LSP case. You wrote: > Eric....what happens if you decrement at an ingress by N say (N being the > 'guessed/known' number of hops) and then protection switching occurs such > that the hops change to M now.....does one have to re-set the ingress > decrement to the new 'guess/known' number of hops? > > regards, Neil > > > -----Original Message----- > > From: Eric Gray [mailto:eric.gray@sandburst.com] > > Sent: 26 November 2001 20:44 > > To: David Allan > > Cc: mpls > > Subject: Re: MIBs and TTL > > > > > > David, > > > > For non-TTL capable links, the TTL should have been decremented at > > the ingress, rather than the egress. The ingress - for example - may > > decrement by one, or by the hop-count. If these are the choices, the > > actual decrement at the ingress will depend on the model of the LSP. > > > -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray From owner-mpls@UU.NET Wed Nov 28 04:59:34 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27113 for ; Wed, 28 Nov 2001 04:59:34 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrbq16701; Wed, 28 Nov 2001 09:39:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrbq29462 for mpls-outgoing; Wed, 28 Nov 2001 09:39:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlrbq29457 for ; Wed, 28 Nov 2001 09:39:14 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 QQlrbq03465 for ; Wed, 28 Nov 2001 09:39:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrbq29316 for ; Wed, 28 Nov 2001 09:38:48 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id EAA04967 for ; Wed, 28 Nov 2001 04:39:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA14472 for mpls@uu.net; Wed, 28 Nov 2001 04:39:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlrbq29422 for ; Wed, 28 Nov 2001 09:37:59 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlrbq11674 for ; Wed, 28 Nov 2001 09:37:38 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f79.law10.hotmail.com [64.4.15.79]) id QQlrbq26689 for ; Wed, 28 Nov 2001 09:37:24 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 28 Nov 2001 01:37:34 -0800 Received: from 63.17.88.122 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 28 Nov 2001 09:37:33 GMT X-Originating-IP: [63.17.88.122] From: "manoj juneja" To: yakov@juniper.net Cc: mpls@UU.NET Subject: Re : changes to unnumbered and link bundling Date: Wed, 28 Nov 2001 02:37:33 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Nov 2001 09:37:34.0256 (UTC) FILETIME=[4EE4D300:01C177F0] Sender: owner-mpls@UU.NET Precedence: bulk Hi Yakov, Should we assume these changes as final ? Does this mean that for establishing bi-directional LSP, if_index need to be specified and there is no need to specify component_id_upstream/downstream for bi-directional LSP ? Regards, manoj. >-----Original Message----- >From: Yakov Rekhter [mailto:yakov@juniper.net] >Sent: Friday, November 02, 2001 9:02 AM >To: mpls@UU.NET >Cc: swallow@cisco.com >Subject: changes to unnumbered and link bundling > > >Folks, > >Based on the results of the e-mail exchange on this list >I plan to make the following changes in draft-ietf-mpls-bundle, >draft-ietf-mpls-rsvp-unnum, and in draft-ietf-mpls-crldp-unnum: > >1) Mandate that one always use the IF_ID HOP on bundled links > (thus eliminating the Implicit Indication from > draft-ietf-mpls-bundle-00.txt). > >2) Do away with the COMPONENT_IF_* TLV, and just use IF_INDEX for > identifying (unnumbered) components in link bundling > >3) Mandate that one always use the IF_ID HOP object on an unnumbered > link. > >4) Make handling numbered and unnumberd interfaces in the ERO > more consistent/uniform by changing the semantics of the Unnumbered > interface subobject (or more precisely the Interface ID field > of this subobject) from: > > The Interface ID is the outgoing interface identifier with > respect to the LSR specified by the router ID. > > to > > The Interface ID is the interface identifier assigned to > the interface by the LSR specified by the router ID. > > and making other appropriate changes in the text to reflect this. > >Yakov. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-mpls@UU.NET Wed Nov 28 06:01:43 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29492 for ; Wed, 28 Nov 2001 06:01:43 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrbw13892; Wed, 28 Nov 2001 11:00:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrbw25215 for mpls-outgoing; Wed, 28 Nov 2001 11:00:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlrbw24947 for ; Wed, 28 Nov 2001 11:00:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlrbw26077 for ; Wed, 28 Nov 2001 11:00:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrbv12833 for ; Wed, 28 Nov 2001 10:59:47 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA07794 for ; Wed, 28 Nov 2001 06:00:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA18061 for mpls@uu.net; Wed, 28 Nov 2001 06:00:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlrbv24387 for ; Wed, 28 Nov 2001 10:59:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlrbv23240 for ; Wed, 28 Nov 2001 10:59:25 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 QQlrbv16091 for ; Wed, 28 Nov 2001 10:59:11 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29062; Wed, 28 Nov 2001 05:59:19 -0500 (EST) Message-Id: <200111281059.FAA29062@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-te-feed-03.txt Date: Wed, 28 Nov 2001 05:59:19 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Improving Topology Data Base Accuracy with LSP Feedback Author(s) : P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki Filename : draft-ietf-mpls-te-feed-03.txt Pages : 10 Date : 27-Nov-01 One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a set of constraints, which those links can meet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-te-feed-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-te-feed-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011127135520.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-te-feed-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-te-feed-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011127135520.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Nov 28 10:14:51 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12837 for ; Wed, 28 Nov 2001 10:14:51 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrcm10158; Wed, 28 Nov 2001 15:13:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrcm19798 for mpls-outgoing; Wed, 28 Nov 2001 15:12:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlrcm19759 for ; Wed, 28 Nov 2001 15:12:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrcm21953 for ; Wed, 28 Nov 2001 15:11:23 GMT Received: from dent.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dent.axion.bt.co.uk [132.146.16.161]) id QQlrcm07758 for ; Wed, 28 Nov 2001 15:11:30 GMT Received: from celiborn.ip-engineering.bt.com (actually celiborn.galadriel.bt.co.uk) by dent (local) with SMTP; Wed, 28 Nov 2001 15:08:43 +0000 Received: from ip-engineering.bt.com by celiborn.ip-engineering.bt.com (8.8.8+Sun/SMI-SVR4) id PAA24809; Wed, 28 Nov 2001 15:08:44 GMT Message-Id: <200111281508.PAA24809@celiborn.ip-engineering.bt.com> X-Mailer: exmh version 2.0.3 9/28/98 To: mpls@UU.NET Subject: 52nd IETF - MPLS Maintenance Mechanisms BOF (mplsoam) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Nov 2001 15:08:43 +0000 From: Peter Willis Sender: owner-mpls@UU.NET Precedence: bulk 52nd IETF - MPLS Maintenance Mechanisms BOF (mplsoam) The purpose of the MPLS OAM BOF is to determine what type of operations and maintenance tools are required for MPLS networks. The BOF will address if traceroute and ping are sufficient operations and maintenance tools for MPLS network operators. The BOF will consider the need for other types of OAM tools for MPLS networks. The agenda for this BOF is available at: http://www.ietf.org/ietf/01dec/mplsoam.txt Regards, Peter Willis. BTexact Technologies. From owner-mpls@UU.NET Wed Nov 28 10:46:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15285 for ; Wed, 28 Nov 2001 10:46:44 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrco28623; Wed, 28 Nov 2001 15:43:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrco22214 for mpls-outgoing; Wed, 28 Nov 2001 15:43:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrco22209 for ; Wed, 28 Nov 2001 15:43:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrco28857 for ; Wed, 28 Nov 2001 15:43:05 GMT Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQlrco27594 for ; Wed, 28 Nov 2001 15:43:12 GMT Received: from avici.com (swdev78.avici.com [10.2.21.78]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id fASFh3x03827; Wed, 28 Nov 2001 10:43:03 -0500 (EST) Message-Id: <200111281543.fASFh3x03827@mailhost.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: David Charlap cc: mpls@UU.NET Subject: Re: RSVP Path without ADSPEC In-reply-to: Your message of "Tue, 27 Nov 2001 11:04:04 EST." <3C03B974.D996CE96@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Nov 2001 10:43:02 -0500 Sender: owner-mpls@UU.NET Precedence: bulk > What type of reservation should an egress router generate when it > receives an IntServ TSPEC and no ADSPEC? > > If the TSpec is using the deprecated CoS C-Type, it is obvious that > best-effort is being requested. It is similarly obvious if the TSpec is > using the IntServ Null service instead of the Token Bucket TSpec > parameters. agreed > When the TSpec is using the Token Bucket TSpec parameters, the kind of > reservation (Guaranteed, Controlled-Load or best-effort) is supposed to > be determined by the presence or absence of service-specific fragments > in the ADSPEC. RFC 2210 explicitly states that an egress router should > not make a reservation using a particular service if that service's > fragment is missing from the ADSPEC. > > But it appears that some vendors (broken, perhaps) generate ADSPEC > objects with no service fragments, or they generate Path messages > without ADSPEC objects altogether. What kind of service should the > egress router reserve in this case? > > IMO, this means that the choice of service is "don't care", and the > egress is free to choose any kind it wants. I personally think that > best-effort is the best thing to do in this case, since it imposes the > least impact on the rest of the network. > > I have been informed, however, that some implementations respond to this > situation (missing ADSPEC or ADSPEC with no service fragments) by making > a Controlled Load reservation, and that these implementation actually > generate missing-ADSPEC Path messages when they want to request > Controlled Load - meaning they are expecting everybody else to handle > this ambiguous situation in the same way they do. > > What is this group's opinion here? I'm especially interested in hearing > from the RSVP-TE draft authors in this regard. > I think it's best to be pragmatic here and look at implementations that are deployed and known to interoperate. Current practice is to use the intserv tspec and the Controlled Load service flowspec. So when you get an intserv tspec, it's best to respond with a Controlled Load flowspec unless there is very clear indication that the sender wants something else (e.g. by sending along an ADSPEC with only a Guaranteed service fragment). Also, you can essentially ignore everything in the token bucket spec except for the bandwidth (token bucket rate). Some implementations make an effort to handle the max pkt size parameter correctly (for Path MTU discovery), all other token bucket parameters are not really of interest. > > Finally, is there a way to signal best-effort other than Null service > and the deprecated CoS object? I currently understand the IntServ RFCs > such that a zero parameter means "don't care", therefore a > Controlled-Load FLOWSPEC with all zeros for parameters should be > synonymous with best-effort. Is this correct or should this actually > imply a Controlled-Load reservation for zero resources (which is > effectively a black-hole if traffic is policed.) The latest iterations of the RSVP-TE spec suggest that a CoS object or the Null service be used to signal best-effort. However, all the implementations that I'm aware of don't do it that way. Instead, an intserv tspec with zero bandwidth and a Controlled Load flowspec with zero bandwidth are used to signal best-effort. I believe this is actually a violation of the intserv specs but it works just fine. And if you want to be sure to interoperate, this is the way to go. I know implementations that will handle CoS objects correctly when they receive them but I don't think anybody sends a CoS object by default when requesting best-effort. That would cause interoperabilty problems. I'm not sure about the support for the Null service in current implementations. The changes in the RSVP-TE spec dealing with best-effort signaling (first the introduction of the CoS object and then it's replacement with the Null service) were rather unfortunate. It really was just a change in syntax, not any technical improvement. The good thing is that the Null service promoted in the latest spec looks like the aesthetically most pleasant solution, the bad thing is that these syntax changes are just a waste of time for everybody involved and an interoperability hazard. Markus From owner-mpls@UU.NET Wed Nov 28 11:14:10 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17207 for ; Wed, 28 Nov 2001 11:14:09 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrcq23197; Wed, 28 Nov 2001 16:11:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrcq13374 for mpls-outgoing; Wed, 28 Nov 2001 16:11:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrcq13312 for ; Wed, 28 Nov 2001 16:11: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 QQlrcq17877 for ; Wed, 28 Nov 2001 16:09:42 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrcq10144 for ; Wed, 28 Nov 2001 16:09:48 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA07274 for ; Wed, 28 Nov 2001 11:09:41 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA01284 for mpls@uu.net; Wed, 28 Nov 2001 11:09:41 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlqzm29891 for ; Tue, 27 Nov 2001 19:42:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlqzm01106 for ; Tue, 27 Nov 2001 19:40:56 GMT From: schultz@io.iol.unh.edu Received: from iol.unh.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: io.iol.unh.edu [132.177.123.82]) id QQlqzm03537 for ; Tue, 27 Nov 2001 19:40:42 GMT Received: from io.iol.unh.edu (IDENT:schultz@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.1/8.12.1) with ESMTP id fARJeu6D002523 for ; Tue, 27 Nov 2001 14:40:56 -0500 Received: from localhost (schultz@localhost) by io.iol.unh.edu (8.12.1/8.12.1/Submit) with ESMTP id fARJet8x002520 for ; Tue, 27 Nov 2001 14:40:56 -0500 Date: Tue, 27 Nov 2001 14:40:55 -0500 (EST) To: mpls@UU.NET Subject: Session attribute object Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello, I am experiencing difficulty understanding the following piece of the RSVP-TE draft (from section 4.7.3): "The contents of the Session Name field are a string, typically of display-able characters. The Length MUST always be a multiple of 4 and MUST be at least 8. For an object length that is not a multiple of 4, the object is padded with trailing NULL characters. The Name Length field contains the actual string length." There are 2 issues here: 1. I interpret "Length" in the second sentence to mean object length. Is that correct? Or is it name length? 2. Isn't the session name field padded with NULL characters and not the object length field? My understanding of object length fields is that they are always multiples of 4. Is this object length field an exception? I would think that the pad characters would be included in an object length field or the parser would not work. Please let me know what you think. Thanks, -Ben From owner-mpls@UU.NET Wed Nov 28 12:44:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24691 for ; Wed, 28 Nov 2001 12:44:34 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrcw12587; Wed, 28 Nov 2001 17:41:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrcw09953 for mpls-outgoing; Wed, 28 Nov 2001 17:41:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlrcw09924 for ; Wed, 28 Nov 2001 17:41:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlrcw08934 for ; Wed, 28 Nov 2001 17:41:00 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQlrcw24361 for ; Wed, 28 Nov 2001 17:40:46 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 MAA03155 for ; Wed, 28 Nov 2001 12:40: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 MAA29102 for ; Wed, 28 Nov 2001 12:40:59 -0500 (EST) Message-ID: <3C05221D.335A54EA@marconi.com> Date: Wed, 28 Nov 2001 12:42:53 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RSVP Path without ADSPEC References: <200111281543.fASFh3x03827@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 Jork wrote: > > The latest iterations of the RSVP-TE spec suggest that a CoS object > or the Null service be used to signal best-effort. What version are you reading? The CoS FLOWSPEC/TSPEC were explicitly deleted from the draft as of version -08. I haven't heard any mention any anybody putting it back. > I don't think anybody sends a CoS object by default when requesting > best-effort. There are some. > That would cause interoperabilty problems. I'm not sure about the > support for the Null service in current implementations. So far, it appears that Null service is not widely supported. CoS seems to be supported by most, but not all, platforms. > The changes in the RSVP-TE spec dealing with best-effort signaling > (first the introduction of the CoS object and then it's replacement > with the Null service) were rather unfortunate. It really was just > a change in syntax, not any technical improvement. The good thing > is that the Null service promoted in the latest spec looks like > the aesthetically most pleasant solution, the bad thing is that these > syntax changes are just a waste of time for everybody involved and > an interoperability hazard. I know. And it may be years after the spec becomes an RFC before all the major players decide to upgrade their code to support Null service. Which is why I asked my questions in the first place. -- David From owner-mpls@UU.NET Wed Nov 28 12:54:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25437 for ; Wed, 28 Nov 2001 12:54:44 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrcx22413; Wed, 28 Nov 2001 17:53:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrcx10678 for mpls-outgoing; Wed, 28 Nov 2001 17:53:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlrcx10673 for ; Wed, 28 Nov 2001 17:53: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 QQlrcx09352 for ; Wed, 28 Nov 2001 17:52:01 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 QQlrcx28883 for ; Wed, 28 Nov 2001 17:51:47 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 MAA04241 for ; Wed, 28 Nov 2001 12:51:59 -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 MAA01540 for ; Wed, 28 Nov 2001 12:52:00 -0500 (EST) Message-ID: <3C0524B2.E2E43477@marconi.com> Date: Wed, 28 Nov 2001 12:53:54 -0500 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Session attribute object References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit schultz@io.iol.unh.edu wrote: > > I am experiencing difficulty understanding the following piece of the > RSVP-TE draft (from section 4.7.3): > > "The contents of the Session Name field are a string, typically of > display-able characters. The Length MUST always be a multiple of 4 > and MUST be at least 8. For an object length that is not a multiple > of 4, the object is padded with trailing NULL characters. The Name > Length field contains the actual string length." > > There are 2 issues here: > > 1. I interpret "Length" in the second sentence to mean object > length. Is that correct? Or is it name length? Object length. > 2. Isn't the session name field padded with NULL characters and not > the object length field? Yes. Since the object length must be a multiple of 4, but the name does not, any space between the end of the name and the end of the object should be padded with NULL characters. Note, however, that if the name is a multiple of 4 bytes, then the last byte of the name is the last byte of the object. There is no requirement that there be a NULL character following the name. Be sure your code treats it as a counted string and not a null-terminated string when parsing the object. > My understanding of object length fields is that they are always > multiples of 4. Is this object length field an exception? I would > think that the pad characters would be included in an object length > field or the parser would not work. Objects are always multiples of 4 bytes long. This is a hard requirement from RFC 2205. The pad characters described exist specifically for the purpose of adhering to this requirement. -- David From owner-mpls@UU.NET Wed Nov 28 13:07:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26206 for ; Wed, 28 Nov 2001 13:07:19 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrcy00428; Wed, 28 Nov 2001 18:05:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrcy22853 for mpls-outgoing; Wed, 28 Nov 2001 18:05:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlrcy22744 for ; Wed, 28 Nov 2001 18:05:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrcy04408 for ; Wed, 28 Nov 2001 18:05:04 GMT Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQlrcy10715 for ; Wed, 28 Nov 2001 18:05:11 GMT Received: from avici.com (swdev78.avici.com [10.2.21.78]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id fASI53x23746 for ; Wed, 28 Nov 2001 13:05:04 -0500 (EST) Message-Id: <200111281805.fASI53x23746@mailhost.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: mpls@UU.NET Subject: Re: RSVP Path without ADSPEC In-reply-to: Your message of "Wed, 28 Nov 2001 12:42:53 EST." <3C05221D.335A54EA@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Nov 2001 13:05:02 -0500 Sender: owner-mpls@UU.NET Precedence: bulk David, > > The latest iterations of the RSVP-TE spec suggest that a CoS object > > or the Null service be used to signal best-effort. > > What version are you reading? The CoS FLOWSPEC/TSPEC were explicitly > deleted from the draft as of version -08. I haven't heard any mention > any anybody putting it back. The wording in that sentence wasn't very good. I did not mean to say the CoS object is still in the very latest spec. It's gone. Markus From owner-mpls@UU.NET Wed Nov 28 15:35:05 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08789 for ; Wed, 28 Nov 2001 15:35:05 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrdi13478; Wed, 28 Nov 2001 20:34:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrdi21918 for mpls-outgoing; Wed, 28 Nov 2001 20:34:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlrdi21913 for ; Wed, 28 Nov 2001 20:34: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 QQlrdi13283 for ; Wed, 28 Nov 2001 20:31:14 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrdi11493 for ; Wed, 28 Nov 2001 20:30:59 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA14257 for ; Wed, 28 Nov 2001 15:31:13 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA14102 for mpls@uu.net; Wed, 28 Nov 2001 15:31:13 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrdf00049 for ; Wed, 28 Nov 2001 19:57:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlrdf28393 for ; Wed, 28 Nov 2001 19:56:33 GMT From: schultz@io.iol.unh.edu Received: from iol.unh.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: io.iol.unh.edu [132.177.123.82]) id QQlrdf16423 for ; Wed, 28 Nov 2001 19:56:19 GMT Received: from io.iol.unh.edu (IDENT:schultz@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.1/8.12.1) with ESMTP id fASJuL6D031800; Wed, 28 Nov 2001 14:56:21 -0500 Received: from localhost (schultz@localhost) by io.iol.unh.edu (8.12.1/8.12.1/Submit) with ESMTP id fASJuLk3031797; Wed, 28 Nov 2001 14:56:21 -0500 Date: Wed, 28 Nov 2001 14:56:21 -0500 (EST) To: David Charlap cc: mpls@UU.NET Subject: Re: Session attribute object In-Reply-To: <3C0524B2.E2E43477@marconi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello David, There is an alternative interpretation that may also have meaning. Regardless of the multiple interpretations, this paragraph should be clarified in the next draft update. [From RSVP-TE] "The contents of the Session Name field are a string, typically of display-able characters. The Length MUST always be a multiple of 4 and MUST be at least 8." Here I suspect the second sentence could also be referring to the Name Field Length referred to in the first sentence. Maybe this sentence would be more clear if written in the following way: "The total length of the Session Name field must always be a multiple of 4 and MUST be at least 8." ----- [From RSVP-TE] "For an object length that is not a multiple of 4, the object is padded with trailing NULL characters. The Name Length field contains the actual string length." These two sentences could also be clarified in the following way: "For a Session Name length that is not a multiple of 4, the Session Name field is padded with trailing NULL characters. The Name Length field contains the actual string length." The reasoning here is that the object length will never not be a multiple of 4. If an object length is, the RSVP-TE draft is contradicting RFC 2205. Thanks, -Ben On Wed, 28 Nov 2001, David Charlap wrote: > schultz@io.iol.unh.edu wrote: > > > > I am experiencing difficulty understanding the following piece of the > > RSVP-TE draft (from section 4.7.3): > > > > "The contents of the Session Name field are a string, typically of > > display-able characters. The Length MUST always be a multiple of 4 > > and MUST be at least 8. For an object length that is not a multiple > > of 4, the object is padded with trailing NULL characters. The Name > > Length field contains the actual string length." > > > > There are 2 issues here: > > > > 1. I interpret "Length" in the second sentence to mean object > > length. Is that correct? Or is it name length? > > Object length. > > > 2. Isn't the session name field padded with NULL characters and not > > the object length field? > > Yes. Since the object length must be a multiple of 4, but the name does > not, any space between the end of the name and the end of the object > should be padded with NULL characters. > > Note, however, that if the name is a multiple of 4 bytes, then the last > byte of the name is the last byte of the object. There is no > requirement that there be a NULL character following the name. Be sure > your code treats it as a counted string and not a null-terminated string > when parsing the object. > > > My understanding of object length fields is that they are always > > multiples of 4. Is this object length field an exception? I would > > think that the pad characters would be included in an object length > > field or the parser would not work. > > Objects are always multiples of 4 bytes long. This is a hard > requirement from RFC 2205. The pad characters described exist > specifically for the purpose of adhering to this requirement. > > -- David > From owner-mpls@UU.NET Thu Nov 29 00:26:28 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23048 for ; Thu, 29 Nov 2001 00:26:28 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrer04271; Thu, 29 Nov 2001 05:24:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrer27695 for mpls-outgoing; Thu, 29 Nov 2001 05:24:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrer27690 for ; Thu, 29 Nov 2001 05:24:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlrer06109 for ; Thu, 29 Nov 2001 05:23:49 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQlrer20455 for ; Thu, 29 Nov 2001 05:23:33 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Nov 2001 11:01:51 +0530 Message-ID: From: "Gopinath G - CTD, Chennai." To: Thomas Nadeau , "Gopinath G - CTD, Chennai." Cc: mpls@UU.NET Subject: RE: Instance in CR-LDP Date: Thu, 29 Nov 2001 10:51:49 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17895.BEF8EF50" 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_01C17895.BEF8EF50 Content-Type: text/plain; charset="iso-8859-1" Hi Is tunnelInstanceID in TE-MIB will be used when LSP Modification is triggered ? or it is an duplicate/backup tunnel? regards gopinathg Hi Is there any relation between Instance in Tunnel table and LSP-Modification ? I don't understand the question. Do you mean the tunnelInstanceID in the MPLS TE MIB's tunnelTable? What do you mean by "LSP modification?" --Tom Thanks In Advance gopinathg ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. ------_=_NextPart_001_01C17895.BEF8EF50 Content-Type: text/html; charset="iso-8859-1"
Hi
 
      Is tunnelInstanceID in TE-MIB will be used when LSP Modification is triggered ? or it is an duplicate/backup tunnel?
 
regards
gopinathg
Hi

   Is there any relation between Instance in Tunnel table and
LSP-Modification ?

        I don't understand the question. Do you mean the tunnelInstanceID
in the MPLS TE MIB's tunnelTable?  What do you mean by "LSP
modification?"

        --Tom
Thanks In Advance

gopinathg



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.
------_=_NextPart_001_01C17895.BEF8EF50-- From owner-mpls@UU.NET Thu Nov 29 06:14:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21618 for ; Thu, 29 Nov 2001 06:14:44 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrfo29427; Thu, 29 Nov 2001 11:13:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrfo17303 for mpls-outgoing; Thu, 29 Nov 2001 11:13:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlrfo17298 for ; Thu, 29 Nov 2001 11:13:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlrfo20205 for ; Thu, 29 Nov 2001 11:13:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrfo11949 for ; Thu, 29 Nov 2001 11:12:47 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA18580 for ; Thu, 29 Nov 2001 06:13:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA22895 for mpls@uu.net; Thu, 29 Nov 2001 06:13:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlrfo16971 for ; Thu, 29 Nov 2001 11:11:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrfo07220 for ; Thu, 29 Nov 2001 11:11:01 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQlrfo25639 for ; Thu, 29 Nov 2001 11:11:08 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21129; Thu, 29 Nov 2001 06:10:57 -0500 (EST) Message-Id: <200111291110.GAA21129@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-rsvp-unnum-03.txt Date: Thu, 29 Nov 2001 06:10:56 -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 : Signalling Unnumbered Links in RSVP-TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-rsvp-unnum-03.txt Pages : 8 Date : 28-Nov-01 Current signalling used by MPLS TE doesn't provide support for unnumbered links. This document defines procedures and extensions to RSVP-TE, one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-unnum-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rsvp-unnum-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-unnum-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011128144741.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-unnum-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-unnum-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128144741.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Nov 29 06:15:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21635 for ; Thu, 29 Nov 2001 06:15:07 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrfo12461; Thu, 29 Nov 2001 11:13:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrfo17288 for mpls-outgoing; Thu, 29 Nov 2001 11:13:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlrfo17281 for ; Thu, 29 Nov 2001 11:13:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlrfo08414 for ; Thu, 29 Nov 2001 11:13:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrfo11960 for ; Thu, 29 Nov 2001 11:12:47 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA18584 for ; Thu, 29 Nov 2001 06:13:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA22908 for mpls@uu.net; Thu, 29 Nov 2001 06:13:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlrfo16972 for ; Thu, 29 Nov 2001 11:11:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrfo06855 for ; Thu, 29 Nov 2001 11:10:56 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQlrfo25528 for ; Thu, 29 Nov 2001 11:11:03 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21116; Thu, 29 Nov 2001 06:10:52 -0500 (EST) Message-Id: <200111291110.GAA21116@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-bundle-01.txt Date: Thu, 29 Nov 2001 06:10:52 -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 Bundling in MPLS Traffic Engineering Author(s) : K. Kompella, Y. Rekhter, L. Berger Filename : draft-ietf-mpls-bundle-01.txt Pages : 9 Date : 28-Nov-01 For the purpose of GMPLS signaling in certain cases a combination of is not sufficient to unambiguously identify the appropriate resource used by an LSP. Such cases are handled by using the link bundling construct which is described in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-bundle-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-bundle-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: <20011128144720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bundle-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bundle-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128144720.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Nov 29 06:16:05 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21736 for ; Thu, 29 Nov 2001 06:16:05 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrfo01263; Thu, 29 Nov 2001 11:14:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrfo17369 for mpls-outgoing; Thu, 29 Nov 2001 11:14:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrfo17350 for ; Thu, 29 Nov 2001 11:14: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 QQlrfo14999 for ; Thu, 29 Nov 2001 11:12:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrfo10667 for ; Thu, 29 Nov 2001 11:11:47 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA18546 for ; Thu, 29 Nov 2001 06:12:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA22838 for mpls@uu.net; Thu, 29 Nov 2001 06:12:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlrfo16745 for ; Thu, 29 Nov 2001 11:10:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrfo03064 for ; Thu, 29 Nov 2001 11:10:46 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQlrfo25228 for ; Thu, 29 Nov 2001 11:10:53 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21079; Thu, 29 Nov 2001 06:10:42 -0500 (EST) Message-Id: <200111291110.GAA21079@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-cr-ldp-06.txt Date: Thu, 29 Nov 2001 06:10:42 -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 : Constraint-Based LSP Setup using LDP Author(s) : B. Jamoussi et al. Filename : draft-ietf-mpls-cr-ldp-06.txt Pages : 38 Date : 28-Nov-01 Label Distribution Protocol (LDP) is defined in [1] for distribution of labels inside one MPLS domain. One of the most important services that may be offered using MPLS in general and LDP in particular is support for constraint-based routing of traffic across the routed network. Constraint-based routing offers the opportunity to extend the information used to setup paths beyond what is available for the routing protocol. For instance, an LSP can be setup based on explicit route constraints, QoS constraints, and other constraints. Constraint-based routing (CR) is a mechanism used to meet Traffic Engineering requirements that have been proposed by [2], [3] and [4]. These requirements may be met by extending LDP for support of constraint-based routed label switched paths (CR-LSPs). Other uses for CR-LSPs include MPLS-based VPNs [5]. More information about the applicability of CR-LDP can be found in [6]. This draft specifies mechanisms and TLVs for support of CR-LSPs using LDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-cr-ldp-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-cr-ldp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-cr-ldp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011128144638.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-cr-ldp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-cr-ldp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128144638.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Nov 29 06:16:48 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21764 for ; Thu, 29 Nov 2001 06:16:48 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrfo14624; Thu, 29 Nov 2001 11:14:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrfo17364 for mpls-outgoing; Thu, 29 Nov 2001 11:14:28 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrfo17348 for ; Thu, 29 Nov 2001 11:14: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 QQlrfo14997 for ; Thu, 29 Nov 2001 11:12:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrfo10666 for ; Thu, 29 Nov 2001 11:11:47 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA18545 for ; Thu, 29 Nov 2001 06:12:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA22839 for mpls@uu.net; Thu, 29 Nov 2001 06:12:01 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlrfo16773 for ; Thu, 29 Nov 2001 11:10:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrfo13570 for ; Thu, 29 Nov 2001 11:10:51 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQlrfo25352 for ; Thu, 29 Nov 2001 11:10:58 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21102; Thu, 29 Nov 2001 06:10:47 -0500 (EST) Message-Id: <200111291110.GAA21102@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsp-hierarchy-03.txt Date: Thu, 29 Nov 2001 06:10:47 -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 : LSP Hierarchy with MPLS TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-lsp-hierarchy-03.txt Pages : 11 Date : 28-Nov-01 To improve scalability of MPLS TE it may be useful to aggregate TE LSPs. The aggregation is accomplished by (a) an LSR creating a TE LSP, (b) the LSR forming a forwarding adjacency out of that LSP (advertising this LSP as a link into ISIS/OSPF), (c) allowing other LSRs to use forwarding adjacencies for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsp-hierarchy-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-lsp-hierarchy-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011128144702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-hierarchy-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-hierarchy-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128144702.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Nov 29 06:39:31 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22567 for ; Thu, 29 Nov 2001 06:39:30 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrfq17812; Thu, 29 Nov 2001 11:38:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrfq19211 for mpls-outgoing; Thu, 29 Nov 2001 11:38:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlrfq19206 for ; Thu, 29 Nov 2001 11:37:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrfq04696 for ; Thu, 29 Nov 2001 11:37:32 GMT Received: from mail.cad.zju.edu.cn by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [210.32.131.2]) id QQlrfq03151 for ; Thu, 29 Nov 2001 11:37:38 GMT Received: (qmail 18068 invoked from network); 29 Nov 2001 11:39:50 -0000 Received: from unknown (HELO cad.zju.edu.cn) (210.32.131.97) by 210.32.131.2 with SMTP; 29 Nov 2001 11:39:50 -0000 Message-ID: <3C061DDD.D18841E7@cad.zju.edu.cn> Date: Thu, 29 Nov 2001 19:37:01 +0800 From: shen jing Reply-To: jshen@cad.zju.edu.cn Organization: State Key Lab of CAD&CG X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: "IETF-Announce:;"@UU.NET, mpls@UU.NET Subject: Re: I-D ACTION:draft-ietf-mpls-lsp-hierarchy-03.txt References: <200111291110.GAA21102@ietf.org> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sorry, but the webserver says " Not Found The requested URL /internet-drafts/draft-ietf-mpls-cr-ldp-06.txt was not found on this server. Apache/1.3.20 Server at www.ietf.org Port 80" Jing > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. > > Title : LSP Hierarchy with MPLS TE > Author(s) : K. Kompella, Y. Rekhter > Filename : draft-ietf-mpls-lsp-hierarchy-03.txt > Pages : 11 > Date : 28-Nov-01 > > To improve scalability of MPLS TE it may be useful to aggregate TE > LSPs. The aggregation is accomplished by (a) an LSR creating a TE > LSP, (b) the LSR forming a forwarding adjacency out of that LSP > (advertising this LSP as a link into ISIS/OSPF), (c) allowing other > LSRs to use forwarding adjacencies for their path computation, and > (d) nesting of LSPs originated by other LSRs into that LSP (by using > the label stack construct). > This document describes the mechanisms to accomplish this. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-03.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-mpls-lsp-hierarchy-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mpls-lsp-hierarchy-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <20011128144702.I-D@ietf.org> From owner-mpls@UU.NET Thu Nov 29 08:51:51 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29630 for ; Thu, 29 Nov 2001 08:51:51 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrfz25606; Thu, 29 Nov 2001 13:50:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrfz07222 for mpls-outgoing; Thu, 29 Nov 2001 13:50:24 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrfz07217 for ; Thu, 29 Nov 2001 13:50: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 QQlrfz26579 for ; Thu, 29 Nov 2001 13:50:10 GMT Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cnxt10002.conexant.com [198.62.10.2]) id QQlrfz24825 for ; Thu, 29 Nov 2001 13:49:55 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Nov 2001 08:50:09 -0500 Message-ID: From: "Rajamanickam, Jaganbabu" To: "'mpls@UU.NET'" Subject: Regarding the RSVP and LDP in same MPLS domain Date: Wed, 28 Nov 2001 23:37:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can we have both RSVP supporting LSR's and LDP supporting LSR's in a same MPLS domain Jags From owner-mpls@UU.NET Thu Nov 29 09:14:18 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01614 for ; Thu, 29 Nov 2001 09:14:18 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrga28704; Thu, 29 Nov 2001 14:13:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrga27999 for mpls-outgoing; Thu, 29 Nov 2001 14:13:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlrga27994 for ; Thu, 29 Nov 2001 14:13:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlrga20164 for ; Thu, 29 Nov 2001 14:13:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrga27993 for ; Thu, 29 Nov 2001 14:12:47 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA29362 for ; Thu, 29 Nov 2001 09:13:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA02743 for mpls@uu.net; Thu, 29 Nov 2001 09:13:01 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlrga27866 for ; Thu, 29 Nov 2001 14:12: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 QQlrga15583 for ; Thu, 29 Nov 2001 14:11:22 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: europe.cisco.com [144.254.52.73]) id QQlrga13902 for ; Thu, 29 Nov 2001 14:11:28 GMT Received: from JVASSEUR-W2K.cisco.com (jvasseur-isdn-home.cisco.com [10.49.89.2]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA28178; Thu, 29 Nov 2001 15:10:41 +0100 (MET) Message-Id: <4.3.2.7.2.20011129150038.0179ef98@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Nov 2001 15:10:02 +0100 To: "Rajamanickam, Jaganbabu" From: Jean Philippe Vasseur Subject: Re: Regarding the RSVP and LDP in same MPLS domain Cc: "'mpls@UU.NET'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 23:37 28/11/2001 -0500, Rajamanickam, Jaganbabu wrote: >Hi, > > Can we have both RSVP supporting LSR's and LDP supporting LSR's in a same >MPLS domain Absolutely. Example 1: A----B----C----D----E (IP Cloud) You can run MPLS TE between B and D if you need to, without LDP. Example 2: A----B----C----D----E (A and D are MPLS VPN PE LSRs) Suppose A and E are PE (Provider Edge LSR) running MPLS VPN and you have setup a TE tunnel between B and D. In this case you will run LDP between A and B, D and E and over the TE tunnel (B-D). Optionnaly you can run LDP between B-C-D (recommended if the TE tunnel fails in order to have an LSP between the PE routers). JP. >Jags From owner-mpls@UU.NET Thu Nov 29 09:25:24 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02614 for ; Thu, 29 Nov 2001 09:25:24 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrgb10997; Thu, 29 Nov 2001 14:24:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrgb29157 for mpls-outgoing; Thu, 29 Nov 2001 14:24:30 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlrgb29150 for ; Thu, 29 Nov 2001 14:24:27 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 QQlrgb18894 for ; Thu, 29 Nov 2001 14:22:52 GMT From: rpapneja@gmu.edu Received: from portal.gmu.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: portalknot.gmu.edu [129.174.0.8]) id QQlrgb00895 for ; Thu, 29 Nov 2001 14:22:59 GMT Received: from gmu.edu (mail02.gmu.edu [129.174.0.10]) by portal.gmu.edu (8.8.8/8.8.8) with ESMTP id JAA23622; Thu, 29 Nov 2001 09:22:49 -0500 (EST) To: "Rajamanickam, Jaganbabu" Cc: "'mpls@UU.NET'" Message-ID: <2f2182a2f22d2a.2f22d2a2f2182a@gmu.edu> Date: Thu, 29 Nov 2001 09:22:49 -0500 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: Regarding the RSVP and LDP in same MPLS domain X-Accept-Language: en Content-Type: multipart/mixed; boundary="--675f3025625c1c7" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ----675f3025625c1c7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Yes, you can. It is actually a very interesting scenario, where you run LDP at the edge and RSVP-TE tunnels in the core. Application could be MPLS BGP VPNs, running LDP over the TE-tunnels (targeted LDP peers) . -Rajiv ----- Original Message ----- From: "Rajamanickam, Jaganbabu" Date: Wednesday, November 28, 2001 11:37 pm Subject: Regarding the RSVP and LDP in same MPLS domain > Hi, > > Can we have both RSVP supporting LSR's and LDP supporting LSR's > in a same > MPLS domain > > Jags > > ----675f3025625c1c7 Content-Type: text/x-vcard; name="rpapneja.vcf"; charset=us-ascii Content-Disposition: attachment; filename="rpapneja.vc" Content-Description: Card for Content-Transfer-Encoding: 7bit begin:vcard n:Papneja;Rajiv fn:Rajiv Papneja tel;fax:703.993.4704 tel;work:703.993.4703 org:Adavnced Internet Lab; version:2.1 email;internet:rpapneja@gmu.edu end:vcard ----675f3025625c1c7-- From owner-mpls@UU.NET Thu Nov 29 09:26:11 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02684 for ; Thu, 29 Nov 2001 09:26:10 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrgb03826; Thu, 29 Nov 2001 14:25:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrgb29162 for mpls-outgoing; Thu, 29 Nov 2001 14:24:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQlrgb29156 for ; Thu, 29 Nov 2001 14:24:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlrgb19603 for ; Thu, 29 Nov 2001 14:23:06 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrgb13240 for ; Thu, 29 Nov 2001 14:22:46 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA00448 for ; Thu, 29 Nov 2001 09:23:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03421 for mpls@uu.net; Thu, 29 Nov 2001 09:23:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlrgb29081 for ; Thu, 29 Nov 2001 14:22:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlrgb14030 for ; Thu, 29 Nov 2001 14:20:20 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQlrgb04914 for ; Thu, 29 Nov 2001 14:20:06 GMT Received: from packetexchange.net (unknown [212.113.11.114]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id B32CB15F83D; Thu, 29 Nov 2001 14:23:04 +0000 (GMT) Message-ID: <3C06447A.5420338B@packetexchange.net> Date: Thu, 29 Nov 2001 14:21:46 +0000 From: Giles Heron Reply-To: giles@packetexchange.net Organization: PacketExchange Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Rajamanickam, Jaganbabu" Cc: "'mpls@UU.NET'" Subject: Re: Regarding the RSVP and LDP in same MPLS domain References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Rajamanickam, Jaganbabu" wrote: > > Hi, > > Can we have both RSVP supporting LSR's and LDP supporting LSR's in a same > MPLS domain yes. and one LSR can support both protocols. For example you can do LDP at the edge of your network, and RSVP-TE in the core, and have your core LSRs "tunnel" LDP over RSVP-TE. In this case the label stack has an LDP assigned label "inside" the RSVP-TE assigned label, and the LDP control plane uses "extended discovery" between the core LSRs. this enables you to traffic engineer at a coarser granularity than if you ran RSVP-TE edge to edge. It also reduces the label space required in the core for the "n squared" RSVP-TE labels (since you are reducing the value of n.) It also allows you to have a hierarchical IGP (backbone and edge areas) but still to use CSPF for your RSVP-TE signalled LSPs - since these will only cross the backbone... HTH Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Thu Nov 29 09:28:50 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02886 for ; Thu, 29 Nov 2001 09:28:49 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrfw04063; Thu, 29 Nov 2001 13:04:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrfw24765 for mpls-outgoing; Thu, 29 Nov 2001 13:04:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrfw24758 for ; Thu, 29 Nov 2001 13:04:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlrfw11629 for ; Thu, 29 Nov 2001 13:03:56 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQlrfw16043 for ; Thu, 29 Nov 2001 13:03:38 GMT Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Nov 2001 18:28:05 +0530 Message-ID: <13D467F625FAD511AE2A00D0B7B917D70642C4@mailserver.netbrahma.com> From: Narasimha Swamy To: "'mpls@uu.net'" Subject: l2vpn(martini drafts) questions Date: Thu, 29 Nov 2001 18:28:04 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk 1. In martini draft, it says, vc-id together with vc-type uniquely identifies a particular VC. does this mean two VCs can have same vc-id but different vc-type? I don't think this should be the case, because group-id exists for higher hierarchy and vc-id should be different for each l2vpn circuit. 2. In case of vc-label withdraw, 4 messages have to be exchanged between 2 peers(first one being label withdraw for label corr. to this vc-id, then label release from its peer. Then label withdraw from its peer for vc-label at its end for this vc-id and lastly label release for this withdrawl). Instead, is it not better way, for one lsr to send label withdraw with vc-id set in new fec element(rather than vc-label) and its peer reply with release(implying it also is withdrawing vc-label at its end). In this way only 2 messages are exchanged. 3. what should be done if tunnel path doesn't exist, any notification msg to be sent? regards swamy From owner-mpls@UU.NET Thu Nov 29 09:41:29 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03887 for ; Thu, 29 Nov 2001 09:41:29 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrgc26827; Thu, 29 Nov 2001 14:40:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrgc00565 for mpls-outgoing; Thu, 29 Nov 2001 14:40:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlrgc00555 for ; Thu, 29 Nov 2001 14:40:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlrgc24209 for ; Thu, 29 Nov 2001 14:38:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrgc06001 for ; Thu, 29 Nov 2001 14:37:47 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA02161 for ; Thu, 29 Nov 2001 09:38:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA04592 for mpls@uu.net; Thu, 29 Nov 2001 09:38:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlrgc00446 for ; Thu, 29 Nov 2001 14:37:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQlrgc19392 for ; Thu, 29 Nov 2001 14:35:59 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQlrgc27800 for ; Thu, 29 Nov 2001 14:35:41 GMT Received: from packetexchange.net (unknown [212.113.11.114]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id BBAE515F83D; Thu, 29 Nov 2001 14:38:45 +0000 (GMT) Message-ID: <3C064827.FA2B2B67@packetexchange.net> Date: Thu, 29 Nov 2001 14:37:27 +0000 From: Giles Heron Reply-To: giles@packetexchange.net Organization: PacketExchange Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Narasimha Swamy Cc: "'mpls@uu.net'" Subject: Re: l2vpn(martini drafts) questions References: <13D467F625FAD511AE2A00D0B7B917D70642C4@mailserver.netbrahma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Narasimha Swamy wrote: > > 1. In martini draft, it says, vc-id together with vc-type uniquely > identifies a particular VC. does this mean two VCs can have same vc-id but > different vc-type? I don't think this should be the case, because group-id > exists for higher hierarchy and vc-id should be different for each l2vpn > circuit. it is valid to have "overlapping" VC ID values, as long as (VC type, VC ID) is unique for a peer PE. however it is also (AFAIK) a perfectly valid decision to implement your code such that VC ID is unique. Nobody is forcing you to support two VCs with the same VC ID but different VC types :) This is completely interoperable, the network operator just assigns a unique VC ID to each circuit between two PEs. also, please remember that while it is true to an extent that group ID creates a hierarchy, that there is no requirement for the group IDs to match at the two ends of the VC. So on a single VC, one PE could use a group id of 100, and use this to indicate a local physical interface whilst the far end could use VC 200 and use it to indicate a virtual tunnel between the two PEs. > 2. In case of vc-label withdraw, 4 messages have to be exchanged between 2 > peers(first one being label withdraw for label corr. to this vc-id, then > label release from its peer. Then label withdraw from its peer for vc-label > at its end for this vc-id and lastly label release for this withdrawl). > Instead, is it not better way, for one lsr to send label withdraw with vc-id > set in new fec element(rather than vc-label) and its peer reply with > release(implying it also is withdrawing vc-label at its end). In this way > only 2 messages are exchanged. I don't think you need to send 4 messages? Typically the far end PE doesn't need to send a VC label withdraw in response to a VC label withdraw from the PE that discovers a problem. If, for example, a PE discovers that a local physical port has gone down it will send a VC label withdraw (which may be a wildcard for a group ID in the case where group ID is used to indicate a physical interface.) The remote PEs presumably all still have active local interfaces, and will be ready to send traffic over their VCs as soon as the local PE sends a new label mapping (as a result of the interface coming back up in this example.) So it is easiest for the local PE to hold onto their label mappings. Note that draft-martini specifies liberal label retention. > 3. what should be done if tunnel path doesn't exist, any notification msg to > be sent? No. the issue in the general case is that you don't know whether the far end has a tunnel to reach you. So it is hard to use that as a basis for advertising/withdrawing labels. And even in cases where you do know if the far end has a tunnel to reach you (e.g. when using RSVP-TE for the tunnels) you wouldn't really want to be "flapping" the VC labels while the far end was busy resignalling a tunnel label? Giles > > regards > swamy -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Thu Nov 29 09:42:12 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03953 for ; Thu, 29 Nov 2001 09:42:12 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrgc06576; Thu, 29 Nov 2001 14:41:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrgc00733 for mpls-outgoing; Thu, 29 Nov 2001 14:41:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrgc00704 for ; Thu, 29 Nov 2001 14:41: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 QQlrgc26528 for ; Thu, 29 Nov 2001 14:40:55 GMT Received: from mailrelay.laurelnetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: host11.laurelnetworks.com [63.94.127.11] (may be forged)) id QQlrgc10533 for ; Thu, 29 Nov 2001 14:40:40 GMT Received: from saturn.laurelnetworks.com (IDENT:tob@saturn.laurelnetworks.com [10.0.4.108]) by mailrelay.laurelnetworks.com (8.9.3/8.9.3) with SMTP id JAA23471; Thu, 29 Nov 2001 09:40:54 -0500 To: Narasimha Swamy Cc: "'mpls@uu.net'" Subject: Re: l2vpn(martini drafts) questions References: <13D467F625FAD511AE2A00D0B7B917D70642C4@mailserver.netbrahma.com> From: Toby Smith Date: 29 Nov 2001 09:44:40 -0500 In-Reply-To: Narasimha Swamy's message of "Thu, 29 Nov 2001 18:28:04 +0530" Message-ID: <7r3d2xfxgn.fsf@saturn.laurelnetworks.com> Lines: 40 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Narasimha Swamy writes: > 1. In martini draft, it says, vc-id together with vc-type uniquely > identifies a particular VC. does this mean two VCs can have same vc-id but > different vc-type? Yes. > I don't think this should be the case, because group-id > exists for higher hierarchy and vc-id should be different for each l2vpn > circuit. Group ID has nothing to do with uniquely identifying a VC at signaling time; it exists only as a convenient way in which one LSR may signal the withdrawal of many VCs at once. > 2. In case of vc-label withdraw, 4 messages have to be exchanged between 2 > peers(first one being label withdraw for label corr. to this vc-id, then > label release from its peer. Then label withdraw from its peer for vc-label > at its end for this vc-id and lastly label release for this withdrawl). Reception of a withdraw from one LSR does not instigate the generation of a withdraw by the receiving LSR. The LSR receiving the withdraw will continue to advertise the VC information it has already sent (unless there's been a local change to the VC configuration of interface oper status). > 3. what should be done if tunnel path doesn't exist, any notification msg to > be sent? No; the signaling of the VCs is independent of the availability of an underlying data path. There was some churn on this topic on the martini draft list some time back, and this was the conclusion reached. Regards, Tob From owner-mpls@UU.NET Thu Nov 29 10:00:34 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07198 for ; Thu, 29 Nov 2001 10:00:34 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrgd03030; Thu, 29 Nov 2001 14:59:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrgd02364 for mpls-outgoing; Thu, 29 Nov 2001 14:59:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrgd02359 for ; Thu, 29 Nov 2001 14:59: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 QQlrgd18192 for ; Thu, 29 Nov 2001 14:58:35 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQlrgd23271 for ; Thu, 29 Nov 2001 14:58:42 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id fATEwU088224; Thu, 29 Nov 2001 06:58:30 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200111291458.fATEwU088224@merlot.juniper.net> To: "manoj juneja" cc: mpls@UU.NET Subject: Re: Re : changes to unnumbered and link bundling In-Reply-To: Your message of "Wed, 28 Nov 2001 02:37:33 MST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <65772.1007045910.1@juniper.net> Date: Thu, 29 Nov 2001 06:58:30 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Manoj, > Should we assume these changes as final ? Does this mean that for > establishing bi-directional LSP, if_index need to be specified and there is > no need to specify component_id_upstream/downstream for bi-directional LSP ? see draft-ietf-mpls-bundle-01.txt. Yakov. From owner-mpls@UU.NET Thu Nov 29 17:14:27 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16819 for ; Thu, 29 Nov 2001 17:14:26 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrhg02229; Thu, 29 Nov 2001 22:13:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrhg13186 for mpls-outgoing; Thu, 29 Nov 2001 22:13:15 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrhg13181 for ; Thu, 29 Nov 2001 22:13:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrhg14771 for ; Thu, 29 Nov 2001 22:12:48 GMT Received: from merlot.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQlrhg01025 for ; Thu, 29 Nov 2001 22:12:55 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id fATMCl014078; Thu, 29 Nov 2001 14:12:47 -0800 (PST) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id OAA29750; Thu, 29 Nov 2001 14:12:47 -0800 (PST) Date: Thu, 29 Nov 2001 14:12:47 -0800 (PST) From: Kireeti Kompella Message-Id: <200111292212.OAA29750@kummer.juniper.net> To: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: FW: Questions on draft-ietf-mpls-bundle-00 Sender: owner-mpls@UU.NET Precedence: bulk > see draft-ietf-mpls-bundle-01.txt In fact, it would be a good idea for those interested to look at the latest versions of the bundling, unnumbered and hierarchy drafts. There are a number of changes, and hopefully the sum total is more coherent and consistent now. Kireeti. From owner-mpls@UU.NET Thu Nov 29 21:03:53 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29841 for ; Thu, 29 Nov 2001 21:03:53 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrhw03110; Fri, 30 Nov 2001 02:03:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrhw07272 for mpls-outgoing; Fri, 30 Nov 2001 02:03:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlrhw07265 for ; Fri, 30 Nov 2001 02:03:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlrhw14036 for ; Fri, 30 Nov 2001 02:02:58 GMT Received: from exchsrv2.cosinecom.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: proxy127.cosinecom.com [63.88.104.127]) id QQlrhw02273 for ; Fri, 30 Nov 2001 02:02:34 GMT Received: by exchsrv2.cosinecom.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Nov 2001 18:01:21 -0800 Message-ID: <69BCCDDC980B4641BFC908D7BF95F184ABE982@exchsrv-eng> From: Sanjeev Tyagi To: "'mpls@UU.NET'" Subject: ORF capability on Cisco/Juniper Date: Thu, 29 Nov 2001 18:02:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17943.14EBC510" 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_01C17943.14EBC510 Content-Type: text/plain; charset="iso-8859-1" Anyone know which version of JunOS Routing Software has Extcomm based ORF support? Or any ORF support for that matter? Also, is Cisco's Extcomm based ORF out yet? -st ############################################################################ ########################## This email communication may contain CONFIDENTIAL INFORMATION and is intended only for the use of the intended recipients identified above. If you are not the intended recipient of this communication, you must not use, disclose, distribute, copy or print this email. If you have received this communication in error, please immediately notify the sender by reply email, delete the communication and destroy all copies. ############################################################################ ########################## ------_=_NextPart_001_01C17943.14EBC510 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ORF capability on Cisco/Juniper

Anyone know which version of JunOS = Routing Software has Extcomm based ORF support? Or any ORF support for = that matter?
Also, is Cisco's Extcomm based ORF = out yet?
-st
#########################################################= ############################################# This email communication = may contain CONFIDENTIAL INFORMATION and is intended only for the use = of the intended recipients identified above.  If you are not the = intended recipient of this communication, you must not use, disclose, = distribute, copy or print this email. If you have received this = communication in error, please immediately notify the sender by reply = email, delete the communication and destroy all copies. = ########################################################################= ##############################

------_=_NextPart_001_01C17943.14EBC510-- From owner-mpls@UU.NET Thu Nov 29 22:31:59 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05805 for ; Thu, 29 Nov 2001 22:31:59 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlric21918; Fri, 30 Nov 2001 03:31:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQlric12018 for mpls-outgoing; Fri, 30 Nov 2001 03:31:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlric12011 for ; Fri, 30 Nov 2001 03:31:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlric24775 for ; Fri, 30 Nov 2001 03:30:03 GMT Received: from jenna.mindvision.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: jenna.mindvision.com [216.170.22.4]) id QQlrib02985 for ; Fri, 30 Nov 2001 03:29:48 GMT Received: (from alan@localhost) by jenna.mindvision.com (8.11.1/8.11.1) id fAU2Tc129514; Thu, 29 Nov 2001 20:29:38 -0600 Date: Thu, 29 Nov 2001 20:29:38 -0600 From: Alan Hannan To: Sanjeev Tyagi Cc: "'mpls@UU.NET'" Subject: Re: ORF capability on Cisco/Juniper Message-ID: <20011129202938.B28069@routingloop.com> References: <69BCCDDC980B4641BFC908D7BF95F184ABE982@exchsrv-eng> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <69BCCDDC980B4641BFC908D7BF95F184ABE982@exchsrv-eng> Sender: owner-mpls@UU.NET Precedence: bulk Deer Mr Tyagi, I recommend you contact JunOS Tech Support and ask them. Since your note was sent to this list by error, I have deleted all copies. However, I accidently Cc:ed the same list to which you sent your note, so I apologise for disclosing and distributing your protected email. Warmest wishes, Alan Thus spake Sanjeev Tyagi (Sanjeev.Tyagi@cosinecom.com) on or about Thu, Nov 29, 2001 at 06:02:36PM -0800: > Anyone know which version of JunOS Routing Software has Extcomm based ORF > support? Or any ORF support for that matter? > Also, is Cisco's Extcomm based ORF out yet? > -st > ############################################################################ > ########################## This email communication may contain CONFIDENTIAL > INFORMATION and is intended only for the use of the intended recipients > identified above. If you are not the intended recipient of this > communication, you must not use, disclose, distribute, copy or print this > email. If you have received this communication in error, please immediately > notify the sender by reply email, delete the communication and destroy all > copies. > ############################################################################ > ########################## From owner-mpls@UU.NET Fri Nov 30 00:03:29 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08754 for ; Fri, 30 Nov 2001 00:03:29 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrii29425; Fri, 30 Nov 2001 05:02:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrii17797 for mpls-outgoing; Fri, 30 Nov 2001 05:02:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlrii17782 for ; Fri, 30 Nov 2001 05:02:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlrii27743 for ; Fri, 30 Nov 2001 05:02:09 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQlrii17437 for ; Fri, 30 Nov 2001 05:01:51 GMT Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 10:26:24 +0530 Message-ID: <13D467F625FAD511AE2A00D0B7B917D70642C5@mailserver.netbrahma.com> From: Narasimha Swamy To: "'giles@packetexchange.net'" Cc: "'mpls@uu.net'" Subject: RE: l2vpn(martini drafts) questions Date: Fri, 30 Nov 2001 10:26:23 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > Narasimha Swamy wrote: > > > > 1. In martini draft, it says, vc-id together with vc-type uniquely > > identifies a particular VC. does this mean two VCs can have same vc-id > but > > different vc-type? I don't think this should be the case, because > group-id > > exists for higher hierarchy and vc-id should be different for each l2vpn > > circuit. > > it is valid to have "overlapping" VC ID values, as long as (VC type, VC > ID) is unique for a peer PE. > > however it is also (AFAIK) a perfectly valid decision to implement your > code such that VC ID is unique. Nobody is forcing you to support two > VCs with the same VC ID but different VC types :) This is completely > interoperable, the network operator just assigns a unique VC ID to each > circuit between two PEs. > > also, please remember that while it is true to an extent that group ID > creates a hierarchy, that there is no requirement for the group IDs to > match at the two ends of the VC. > > So on a single VC, one PE could use a group id of 100, and use this to > indicate a local physical interface whilst the far end could use VC 200 > and use it to indicate a virtual tunnel between the two PEs. then is itn't necessary for wild-card vc-id label withdrawl!(all vc-labels associated with this vc-id) > > 2. In case of vc-label withdraw, 4 messages have to be exchanged between > 2 > > peers(first one being label withdraw for label corr. to this vc-id, then > > label release from its peer. Then label withdraw from its peer for > vc-label > > at its end for this vc-id and lastly label release for this withdrawl). > > Instead, is it not better way, for one lsr to send label withdraw with > vc-id > > set in new fec element(rather than vc-label) and its peer reply with > > release(implying it also is withdrawing vc-label at its end). In this > way > > only 2 messages are exchanged. > > I don't think you need to send 4 messages? Typically the far end PE > doesn't need to send a VC label withdraw in response to a VC label > withdraw from the PE that discovers a problem. > > If, for example, a PE discovers that a local physical port has gone down > it will send a VC label withdraw (which may be a wildcard for a group ID > in the case where group ID is used to indicate a physical interface.) > > The remote PEs presumably all still have active local interfaces, and > will be ready to send traffic over their VCs as soon as the local PE > sends a new label mapping (as a result of the interface coming back up > in this example.) So it is easiest for the local PE to hold onto their > label mappings. > > Note that draft-martini specifies liberal label retention. perfect! > > 3. what should be done if tunnel path doesn't exist, any notification > msg to > > be sent? > > No. > > the issue in the general case is that you don't know whether the far end > has a tunnel to reach you. So it is hard to use that as a basis for > advertising/withdrawing labels. And even in cases where you do know if > the far end has a tunnel to reach you (e.g. when using RSVP-TE for the > tunnels) you wouldn't really want to be "flapping" the VC labels while > the far end was busy resignalling a tunnel label? does this mean that vc-label advertisement should be accepted eventhough tunnel from this LSR is not there. This should be ok, as anyway this LSR wouldn't be advertising vc-label without first having tunnel, and there won't be any data exchanged on a VC unless it is configured from both sides. > Giles > > > > > regards > > swamy > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > From owner-mpls@UU.NET Fri Nov 30 06:04:55 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03187 for ; Fri, 30 Nov 2001 06:04:55 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrjg22146; Fri, 30 Nov 2001 11:03:41 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrjg08395 for mpls-outgoing; Fri, 30 Nov 2001 11:03:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlrjg08380 for ; Fri, 30 Nov 2001 11:03:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrjg00603 for ; Fri, 30 Nov 2001 11:03:02 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrjg21269 for ; Fri, 30 Nov 2001 11:03:09 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA27469 for ; Fri, 30 Nov 2001 06:03:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA29270 for mpls@uu.net; Fri, 30 Nov 2001 06:03:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlrjg08133 for ; Fri, 30 Nov 2001 11:02:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrjg27199 for ; Fri, 30 Nov 2001 11:02:18 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQlrjg20027 for ; Fri, 30 Nov 2001 11:02:26 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02808; Fri, 30 Nov 2001 06:02:13 -0500 (EST) Message-Id: <200111301102.GAA02808@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-generalized-signaling-07.txt Date: Fri, 30 Nov 2001 06:02:12 -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 : Generalized MPLS - Signaling Functional Description Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-signaling-07.txt Pages : 32 Date : 29-Nov-01 This document describes extensions to MPLS signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms are specified in [GMPLS-RSVP] and [GMPLS-LDP]. Technology specific details are expected to be specified in independent technology specific documents, e.g., [GMPLS-SONET]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-generalized-signaling-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011129144640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-signaling-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011129144640.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Nov 30 06:05:25 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03255 for ; Fri, 30 Nov 2001 06:05:25 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrjg03003; Fri, 30 Nov 2001 11:04:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrjg08459 for mpls-outgoing; Fri, 30 Nov 2001 11:04:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrjg08441 for ; Fri, 30 Nov 2001 11:04:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrjg23516 for ; Fri, 30 Nov 2001 11:04:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrjg23229 for ; Fri, 30 Nov 2001 11:04:10 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA27507 for ; Fri, 30 Nov 2001 06:04:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA29316 for mpls@uu.net; Fri, 30 Nov 2001 06:04:01 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlrjg08356 for ; Fri, 30 Nov 2001 11:02:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrjg27556 for ; Fri, 30 Nov 2001 11:02:23 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQlrjg20162 for ; Fri, 30 Nov 2001 11:02:30 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02820; Fri, 30 Nov 2001 06:02:17 -0500 (EST) Message-Id: <200111301102.GAA02820@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-generalized-cr-ldp-05.txt Date: Fri, 30 Nov 2001 06:02:17 -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 : Generalized MPLS Signaling - CR-LDP Extensions Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-cr-ldp-05.txt Pages : 23 Date : 29-Nov-01 This document describes extensions to CR-LDP signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. An RSVP-TE specific description can be found in [GMPLS- RSVP]. A generic functional description is presented in [GMPLS-SIG]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-cr-ldp-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-generalized-cr-ldp-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011129144651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-cr-ldp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011129144651.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Nov 30 06:05:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03289 for ; Fri, 30 Nov 2001 06:05:41 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrjg24731; Fri, 30 Nov 2001 11:04:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrjg08460 for mpls-outgoing; Fri, 30 Nov 2001 11:04:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrjg08442 for ; Fri, 30 Nov 2001 11:04:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrjg23538 for ; Fri, 30 Nov 2001 11:04:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrjg23236 for ; Fri, 30 Nov 2001 11:04:10 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA27511 for ; Fri, 30 Nov 2001 06:04:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA29325 for mpls@uu.net; Fri, 30 Nov 2001 06:04:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQlrjg08358 for ; Fri, 30 Nov 2001 11:02:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQlrjg27909 for ; Fri, 30 Nov 2001 11:02:28 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQlrjg20281 for ; Fri, 30 Nov 2001 11:02:35 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02832; Fri, 30 Nov 2001 06:02:22 -0500 (EST) Message-Id: <200111301102.GAA02832@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-generalized-rsvp-te-06.txt Date: Fri, 30 Nov 2001 06:02:22 -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 : Generalized MPLS Signaling - RSVP-TE Extensions Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-rsvp-te-06.txt Pages : 39 Date : 29-Nov-01 This document describes extensions to RSVP-TE signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents an RSVP-TE specific description of the extensions. A CR-LDP specific description can be found in [GMPLS-LDP]. A generic functional description is presented in [GMPLS-SIG]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-generalized-rsvp-te-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011129144705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-rsvp-te-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011129144705.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Nov 30 07:03:40 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05659 for ; Fri, 30 Nov 2001 07:03:40 -0500 (EST) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQlrjk28310; Fri, 30 Nov 2001 12:02:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQlrjk02854 for mpls-outgoing; Fri, 30 Nov 2001 12:02:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQlrjk02847 for ; Fri, 30 Nov 2001 12:02: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 QQlrjk13503 for ; Fri, 30 Nov 2001 12:02:03 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQlrjk27082 for ; Fri, 30 Nov 2001 12:02:10 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA00039 for ; Fri, 30 Nov 2001 07:02:01 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA02530 for mpls@uu.net; Fri, 30 Nov 2001 07:02:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQlrjk26261 for ; Fri, 30 Nov 2001 12:00:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQlrjk10494 for ; Fri, 30 Nov 2001 12:00:27 GMT Received: from starvin-marvin.delphi-assoc.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: starvin-marvin.delphi-assoc.co.uk [195.82.105.221]) id QQlrjk17315 for ; Fri, 30 Nov 2001 12:00:11 GMT Received: from packetexchange.net (unknown [212.113.11.114]) by starvin-marvin.delphi-assoc.co.uk (Postfix) with ESMTP id 6C57F15F83D; Fri, 30 Nov 2001 12:03:17 +0000 (GMT) Message-ID: <3C077538.4864036E@packetexchange.net> Date: Fri, 30 Nov 2001 12:02:00 +0000 From: Giles Heron Reply-To: giles@packetexchange.net Organization: PacketExchange Ltd. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Narasimha Swamy Cc: "'mpls@uu.net'" Subject: Re: l2vpn(martini drafts) questions References: <13D467F625FAD511AE2A00D0B7B917D70642C5@mailserver.netbrahma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Narasimha Swamy wrote: > > > Narasimha Swamy wrote: > > > > > > 1. In martini draft, it says, vc-id together with vc-type uniquely > > > identifies a particular VC. does this mean two VCs can have same vc-id > > but > > > different vc-type? I don't think this should be the case, because > > group-id > > > exists for higher hierarchy and vc-id should be different for each l2vpn > > > circuit. > > > > it is valid to have "overlapping" VC ID values, as long as (VC type, VC > > ID) is unique for a peer PE. > > > > however it is also (AFAIK) a perfectly valid decision to implement your > > code such that VC ID is unique. Nobody is forcing you to support two > > VCs with the same VC ID but different VC types :) This is completely > > interoperable, the network operator just assigns a unique VC ID to each > > circuit between two PEs. > > > > also, please remember that while it is true to an extent that group ID > > creates a hierarchy, that there is no requirement for the group IDs to > > match at the two ends of the VC. > > > > So on a single VC, one PE could use a group id of 100, and use this to > > indicate a local physical interface whilst the far end could use VC 200 > > and use it to indicate a virtual tunnel between the two PEs. > then is itn't necessary for wild-card vc-id label withdrawl!(all vc-labels > associated with this vc-id) I'm not sure what you mean here? there is only one VC label associated with one VC ID (unless you use the same VC ID with different VC types.) The wildcard label withdrawl is for a group ID wildcard. Each end of a VC knows the local and remote group IDs for the VC. So if a PE gets a wildcard withdraw from a peer PE it can delete every VC to that peer PE with a matching remote group ID. > > > 2. In case of vc-label withdraw, 4 messages have to be exchanged between > > 2 > > > peers(first one being label withdraw for label corr. to this vc-id, then > > > label release from its peer. Then label withdraw from its peer for > > vc-label > > > at its end for this vc-id and lastly label release for this withdrawl). > > > Instead, is it not better way, for one lsr to send label withdraw with > > vc-id > > > set in new fec element(rather than vc-label) and its peer reply with > > > release(implying it also is withdrawing vc-label at its end). In this > > way > > > only 2 messages are exchanged. > > > > I don't think you need to send 4 messages? Typically the far end PE > > doesn't need to send a VC label withdraw in response to a VC label > > withdraw from the PE that discovers a problem. > > > > If, for example, a PE discovers that a local physical port has gone down > > it will send a VC label withdraw (which may be a wildcard for a group ID > > in the case where group ID is used to indicate a physical interface.) > > > > The remote PEs presumably all still have active local interfaces, and > > will be ready to send traffic over their VCs as soon as the local PE > > sends a new label mapping (as a result of the interface coming back up > > in this example.) So it is easiest for the local PE to hold onto their > > label mappings. > > > > Note that draft-martini specifies liberal label retention. > perfect! :) > > > 3. what should be done if tunnel path doesn't exist, any notification > > msg to > > > be sent? > > > > No. > > > > the issue in the general case is that you don't know whether the far end > > has a tunnel to reach you. So it is hard to use that as a basis for > > advertising/withdrawing labels. And even in cases where you do know if > > the far end has a tunnel to reach you (e.g. when using RSVP-TE for the > > tunnels) you wouldn't really want to be "flapping" the VC labels while > > the far end was busy resignalling a tunnel label? > does this mean that vc-label advertisement should be accepted eventhough > tunnel from this LSR is not there. This should be ok, as anyway this LSR > wouldn't be advertising vc-label without first having tunnel, and there > won't be any data exchanged on a VC unless it is configured from both sides. yes. The VC label advertisement should be accepted even though there is no tunnel. Again this is a form of liberal retention - we hold onto the FEC even though we can't use it yet. And in fact the local LSR may advertise a VC label to the remote LSR even if it has no tunnel to the remote LSR. As Toby has indicated there was a fair bit of discussion on this point, and the upshot is that Luca was persuaded to remove the requirement for a tunnel from A->B before A advertised a VC label to B. The reasoning for removing the requirement was that we don't want to see labels being withdrawn and then readvertised when a routing transient occurs. So in fact it is valid to have a draft-martini circuit which is "up" - in the sense that the two ends have exchanged labels, but which is not used by one LSR because it has no tunnel to reach the remote LSR. Given that the VC labels are likely to be advertised over the tunnel LSP this should only be a transient condition. But of course this is another reason why it is "a good thing" to have LDP signalled LSPs as a last resort even when you are using RSVP-TE for your tunnel LSPs (as JP mentioned in his post on the "RSVP and LDP in the same MPLS domain" thread yesterday.) Giles > > > Giles > > > > > > > > regards > > > swamy > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" =================================================================