From owner-mpls@UU.NET Mon Apr 1 00:04:25 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07576 for ; Mon, 1 Apr 2002 00:04: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 QQmiqu03794; Mon, 1 Apr 2002 05:03:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmiqu05927 for mpls-outgoing; Mon, 1 Apr 2002 05:03:16 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 QQmiqu05918 for ; Mon, 1 Apr 2002 05:03:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmiqu17388 for ; Mon, 1 Apr 2002 05:02:23 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQmiqu01967 for ; Mon, 1 Apr 2002 05:02:17 GMT Received: from m2vwall3.wipro.com (m2vwall3.wipro.com [164.164.29.237]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g3152FG21932 for ; Mon, 1 Apr 2002 10:32:15 +0530 (IST) Received: from 192.168.2.18 by m2vwall3.wipro.com (InterScan E-Mail VirusWall NT); Mon, 01 Apr 2002 10:32:06 +0530 Received: from alcatel-gw.wipinfo.soft.net ([192.168.220.200]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GTVGAF00.NEB; Mon, 1 Apr 2002 09:55:27 +0530 Received: from soflt.alc.wipinfo.soft.net (soflt [192.168.220.205]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id FAA21770; Mon, 1 Apr 2002 05:03:27 +0530 Date: Mon, 1 Apr 2002 10:00:57 +0530 (IST) From: "chetan kumar s" X-X-Sender: Reply-To: To: Manikantan Srinivasan cc: "mpls@uu.net" Subject: RE: new draft In-Reply-To: <01C1D67C.F04DBDC0.manis@futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 28 Mar 2002, Manikantan Srinivasan wrote: > Hello Chetan, Hi Manikantan, Please find my comments embedded.. > > Good idea.. > > Following are my comments/feedback. > > 1) The advantage of the "LSPID" is not clearly mentioned. > > I understand the need of LSPID as follows. Please correct > me if I am wrong. > A tunnel interface, is treated as a point-to-point interface. > The Link TLV proposed in [OSPF-TE] provides support to > specify point-to-point interfaces. However if there are multiple > point-to-point links (They can be virtual tunnels/circuits etc.,) > originating on the same physical interface and ending on > the same physical interface between two routers, the source > IP address, destination IP address will not help distinguish > the different links. In this case a link id, or LSPID is helpful. You are right. In a case where there are multipule tunnels originate on the same physical i/f, it is not scalable to have ip numbers associated with each tunnels. So tunnels can be signalled as LSP's and LSPID can be signalled via OSPF-TE. If is this is not clear, I will update the draft. > > If am I am right, can it be added? or the actual intent. > > 2) How the LSPID helps in automated CSPF calculation is > not clearly highlighted. (I think automated CSPF for > TE Paths is the final intent). Excatly, final intent is automation of CSPF calculation. When one calculates the path from a central node (as against distributed method), calculated path would be optimal. One needs to provide full information to the central node. How the central node use this information is left to (CSPF) implementation. > > 3) Sections 4, 5 are missing. oops, the section numbering is incorrect, not that section 4 and 5 missing. I will update this.. > > with best regards > mani > /*-------------------------------------*/ > S.Manikantan > Future Communications Software, > 4300, Stevens Creek Blvd, > Suite 187, San Jose, > CA 95129 > Tel : (408) 243-3887 Extn 107 > Fax: (408) 243-0772 > email: manis@futsoft.com > /*-------------------------------------*/ > > > > > > -----Original Message----- > From: chetan kumar s [SMTP:chetan.kumar@wipro.com] > Sent: Thursday, March 28, 2002 5:56 AM > To: mpls@uu.net > Subject: new draft > > Hi, > I a new draft is avilable in TE WG. I solicit your comments on > this and like to know the list views on this.. > > Thanks > Chetan S > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Signalling LSPID's in OSPF TE > Author(s) : K. Chetan, K. Sunil > Filename : draft-chetan-lspid-ospf-00.txt > Pages : 5 > Date : 21-Mar-02 > > This draft introduces new a sub TLV to OSPF TE extensions to signal > the LSPID (Label Switch Path ID) of an LSP (Label Switch Path). > This information can be used by any mechanism (normally constraint > based path calculation (CSPF) procedures) to calculate paths that > may contain LSPID's as one its Explict Route Objects. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chetan-lspid-ospf-00.txt > From owner-mpls@UU.NET Mon Apr 1 08:26:30 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24368 for ; Mon, 1 Apr 2002 08:26:18 -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 QQmisb10695; Mon, 1 Apr 2002 13:25:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmisb10274 for mpls-outgoing; Mon, 1 Apr 2002 13:25: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 QQmisb10266 for ; Mon, 1 Apr 2002 13:25:08 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 QQmisb00476 for ; Mon, 1 Apr 2002 13:23:28 GMT Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange.movaz.com [65.205.166.141]) id QQmisb23334 for ; Mon, 1 Apr 2002 13:23:28 GMT Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 1 Apr 2002 08:23:27 -0500 Message-ID: <000801c1d980$6b9961e0$681810ac@movaz.com> From: "Adrian Farrel" To: "Sandeep B" , Cc: References: Subject: Re: mpls TE-mib Date: Mon, 1 Apr 2002 08:23:32 -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: 01 Apr 2002 13:23:27.0929 (UTC) FILETIME=[68BC3290:01C1D980] Sender: owner-mpls@UU.NET Precedence: bulk Sandeep, Youi're quite correct. This is something we have addressed in the GMPLS-TE-MIB. Cheers, Adrian ----- Original Message ----- From: "Sandeep B" To: Cc: Sent: Sunday, March 31, 2002 4:00 PM Subject: mpls TE-mib > Tom and other authors - > > Do we not need a FLAG field in ARHopTable of TE-mib since it is a direct > mapping of RRO object. > > MplsTunnelARHopEntry ::= SEQUENCE { > mplsTunnelARHopListIndex MplsPathIndex, > mplsTunnelARHopIndex MplsPathIndex, > mplsTunnelARHopAddrType INTEGER, > mplsTunnelARHopIpv4Addr InetAddressIPv4, > mplsTunnelARHopIpv4PrefixLen Unsigned32, > mplsTunnelARHopIpv6Addr InetAddressIPv6, > mplsTunnelARHopIpv6PrefixLen Unsigned32, > mplsTunnelARHopAsNumber Unsigned32, > mplsTunnelARHopLspId MplsLSPID > } > > > -Sandeep > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > From owner-mpls@UU.NET Mon Apr 1 08:31:23 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24787 for ; Mon, 1 Apr 2002 08:31:23 -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 QQmisb08613; Mon, 1 Apr 2002 13:24:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmisb10215 for mpls-outgoing; Mon, 1 Apr 2002 13:23:59 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 QQmisb10210 for ; Mon, 1 Apr 2002 13:23: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 QQmisb23288 for ; Mon, 1 Apr 2002 13:23:50 GMT Received: from atlntex01.movaz.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: exchange.movaz.com [65.205.166.141]) id QQmisb23867 for ; Mon, 1 Apr 2002 13:23:50 GMT Received: from BLIULAPTOP ([172.16.24.104]) by atlntex01.movaz.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 1 Apr 2002 08:23:50 -0500 Message-ID: <000c01c1d980$78fe7d70$681810ac@movaz.com> From: "Adrian Farrel" To: "Sandeep B" , "Thomas D. Nadeau" Cc: "'mpls@uu.net'" References: Subject: Re: mpls TE-mib Date: Mon, 1 Apr 2002 08:23:54 -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: 01 Apr 2002 13:23:50.0398 (UTC) FILETIME=[7620B1E0:01C1D980] Sender: owner-mpls@UU.NET Precedence: bulk Sandeep, You're quite correct. This is something we have addressed in the GMPLS-TE-MIB. Cheers, Adrian ----- Original Message ----- From: "Sandeep B" To: Cc: Sent: Sunday, March 31, 2002 4:00 PM Subject: mpls TE-mib > Tom and other authors - > > Do we not need a FLAG field in ARHopTable of TE-mib since it is a direct > mapping of RRO object. > > MplsTunnelARHopEntry ::= SEQUENCE { > mplsTunnelARHopListIndex MplsPathIndex, > mplsTunnelARHopIndex MplsPathIndex, > mplsTunnelARHopAddrType INTEGER, > mplsTunnelARHopIpv4Addr InetAddressIPv4, > mplsTunnelARHopIpv4PrefixLen Unsigned32, > mplsTunnelARHopIpv6Addr InetAddressIPv6, > mplsTunnelARHopIpv6PrefixLen Unsigned32, > mplsTunnelARHopAsNumber Unsigned32, > mplsTunnelARHopLspId MplsLSPID > } > > > -Sandeep > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > From owner-mpls@UU.NET Mon Apr 1 13:03:57 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08316 for ; Mon, 1 Apr 2002 13:03:57 -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 QQmisu09680; Mon, 1 Apr 2002 18:03:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmisu07962 for mpls-outgoing; Mon, 1 Apr 2002 18:03: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 QQmisu07951 for ; Mon, 1 Apr 2002 18:02:54 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 QQmisu28604 for ; Mon, 1 Apr 2002 18:02:51 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: law2-f128.hotmail.com [216.32.181.128]) id QQmisu09041 for ; Mon, 1 Apr 2002 18:02:50 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 10:02:49 -0800 Received: from 63.104.212.252 by lw2fd.hotmail.msn.com with HTTP; Mon, 01 Apr 2002 18:02:47 GMT X-Originating-IP: [63.104.212.252] From: "Sandeep B" To: afarrel@movaz.com, tnadeau@cisco.com Cc: mpls@UU.NET Subject: Re: mpls TE-mib Date: Mon, 01 Apr 2002 18:02:47 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2002 18:02:49.0911 (UTC) FILETIME=[6FA7AC70:01C1D9A7] Sender: owner-mpls@UU.NET Precedence: bulk Could we include this in next MPLS-TE draft. Thanks, Sandeep >Sandeep, >You're quite correct. > >This is something we have addressed in the GMPLS-TE-MIB. > >Cheers, >Adrian >----- Original Message ----- >From: "Sandeep B" >To: >Cc: >Sent: Sunday, March 31, 2002 4:00 PM >Subject: mpls TE-mib > > > > Tom and other authors - > > > > Do we not need a FLAG field in ARHopTable of TE-mib since it is a direct > > mapping of RRO object. > > > > MplsTunnelARHopEntry ::= SEQUENCE { > > mplsTunnelARHopListIndex MplsPathIndex, > > mplsTunnelARHopIndex MplsPathIndex, > > mplsTunnelARHopAddrType INTEGER, > > mplsTunnelARHopIpv4Addr InetAddressIPv4, > > mplsTunnelARHopIpv4PrefixLen Unsigned32, > > mplsTunnelARHopIpv6Addr InetAddressIPv6, > > mplsTunnelARHopIpv6PrefixLen Unsigned32, > > mplsTunnelARHopAsNumber Unsigned32, > > mplsTunnelARHopLspId MplsLSPID > > } > > > > > > -Sandeep > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. From owner-mpls@UU.NET Mon Apr 1 13:15:06 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08946 for ; Mon, 1 Apr 2002 13:15:06 -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 QQmisu03048; Mon, 1 Apr 2002 18:14:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmisu18597 for mpls-outgoing; Mon, 1 Apr 2002 18:14:14 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmisu18592 for ; Mon, 1 Apr 2002 18:14: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 QQmisu25986 for ; Mon, 1 Apr 2002 18:14: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 QQmisu02051 for ; Mon, 1 Apr 2002 18:14:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA12678 for ; Mon, 1 Apr 2002 13:14:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA12824 for mpls@uu.net; Mon, 1 Apr 2002 13:14: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 QQmisu18557 for ; Mon, 1 Apr 2002 18:13: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 QQmisu27444 for ; Mon, 1 Apr 2002 18:12:48 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQmisu12973 for ; Mon, 1 Apr 2002 18:12:48 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g31ID9021697; Mon, 1 Apr 2002 13:13:09 -0500 (EST) Received: from tnadeau-w2k.cisco.com (katie.cisco.com [10.83.99.126]) by bucket.cisco.com (Mirapoint) with ESMTP id AAV16356; Mon, 1 Apr 2002 13:12:45 -0500 (EST) Message-Id: <4.3.2.7.2.20020401131216.0e6f2a40@bucket> X-Sender: tnadeau@bucket X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Apr 2002 13:12:39 -0500 To: "Sandeep B" From: "Thomas D. Nadeau" Subject: Re: mpls TE-mib Cc: afarrel@movaz.com, 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 It already is included in the GMPLS-TE MIB, which will actually be the MPLS-TE MIB v2. --Tom >Could we include this in next MPLS-TE draft. > >Thanks, >Sandeep > >>Sandeep, >>You're quite correct. >> >>This is something we have addressed in the GMPLS-TE-MIB. >> >>Cheers, >>Adrian >>----- Original Message ----- >>From: "Sandeep B" >>To: >>Cc: >>Sent: Sunday, March 31, 2002 4:00 PM >>Subject: mpls TE-mib >> >> >> > Tom and other authors - >> > >> > Do we not need a FLAG field in ARHopTable of TE-mib since it is a direct >> > mapping of RRO object. >> > >> > MplsTunnelARHopEntry ::= SEQUENCE { >> > mplsTunnelARHopListIndex MplsPathIndex, >> > mplsTunnelARHopIndex MplsPathIndex, >> > mplsTunnelARHopAddrType INTEGER, >> > mplsTunnelARHopIpv4Addr InetAddressIPv4, >> > mplsTunnelARHopIpv4PrefixLen Unsigned32, >> > mplsTunnelARHopIpv6Addr InetAddressIPv6, >> > mplsTunnelARHopIpv6PrefixLen Unsigned32, >> > mplsTunnelARHopAsNumber Unsigned32, >> > mplsTunnelARHopLspId MplsLSPID >> > } >> > >> > >> > -Sandeep >> > >> > _________________________________________________________________ >> > MSN Photos is the easiest way to share and print your photos: >> > http://photos.msn.com/support/worldwide.aspx >> > >> >> >> > > > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Tue Apr 2 02:18:08 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08680 for ; Tue, 2 Apr 2002 02:18: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 QQmiuv01574; Tue, 2 Apr 2002 07:17:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmiuv19356 for mpls-outgoing; Tue, 2 Apr 2002 07:16:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmiuv19292 for ; Tue, 2 Apr 2002 07:16: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 QQmiuv20564 for ; Tue, 2 Apr 2002 07:16:08 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQmiuv04912 for ; Tue, 2 Apr 2002 07:16:07 GMT Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 12:45:43 +0530 Message-ID: <9027F68B07E7D511AE9400B0D0787DC0070453@mailserver.netbrahma.com> From: Manoj Agiwal To: "mpls@UU. NET (E-mail)" Cc: "Gmpls-Ops (E-mail)" Subject: IF_ID_RSVP_HOP object in Resv message . Date: Tue, 2 Apr 2002 12:45:34 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi , 1) Will the IF_ID RSVP_HOP object in the Path message carry both the Control plane and Data Plane as defined in the new TLV . 2) Values which IF_ID_RSVP_HOP object will carry in Resv message has been defined in two ways in drafts "The new RSVP_HOP object is used in Resv message to indicate the downstream node's usage of the indicated interface(s)." as defined in section 8.1 of generalized RSVP-TE . "A node receiving one or more TLVs in a Path message saves their values and returns them in the HOP objects of subsequent Resv messages sent to the node that originated the TLVs." as defined in section 8.1.2 of generalized RSVP-TE ." What is carried in Resv message IPV4 NHOP Address / LIH ? What is carried in Resv message new TLV ? Regards , Manoj From owner-mpls@UU.NET Tue Apr 2 02:42:38 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09057 for ; Tue, 2 Apr 2002 02:42:38 -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 QQmiuw13246; Tue, 2 Apr 2002 07:42:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmiuw20953 for mpls-outgoing; Tue, 2 Apr 2002 07:41: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 QQmiuw20939 for ; Tue, 2 Apr 2002 07:41:43 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 QQmiuw21902 for ; Tue, 2 Apr 2002 07:40:54 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f11.pav2.hotmail.com [64.4.37.11]) id QQmiuw11556 for ; Tue, 2 Apr 2002 07:40:54 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 23:40:53 -0800 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 02 Apr 2002 07:40:53 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Confusing Terms Date: Tue, 02 Apr 2002 07:40:53 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Apr 2002 07:40:53.0475 (UTC) FILETIME=[B7BD2B30:01C1DA19] Sender: owner-mpls@UU.NET Precedence: bulk Hi, Thank you for answering my questions. Okay now I am sure that the 'distribution' is a separate process from 'binding'. I was confused since I read "MPLS: Technology and Applications" by Davie & Rekhter. They introduced the terms local binding and remote binding. And of course these do not involve any distribution, just purely the origin of label binding occurance. Immediately after that, they described upstream/downstream bindings as way of populating the forwarding table with labels that are of local/remote bindings. In their description, they also mentioned the direction of label distribution. And that has caused me to confuse the true meaning of 'distribution' and 'binding' used in MPLS. Probably they mentioned the flow of label binding information just for the sake of making their statement complete. To end this paragraph, upstream/downstream binding is orthogonal to upstream/downstream distribution. Full stop. Unfortunately I am still confuse with 'distribution' terms. The downstream on demand and unsolicted downstream label distributions define how and when label is being distributed. However, independent and ordered controls also describe similar label distribution processes. And since you said ordered control can only be achieved by downstream on demand label distribution, the question is, what are their differences to warrant them with different terms? Or does ordered control mean downstream on demand? (the same is true for independent control if it can only be achieved by unsolicted downstream label distribution.) > > 3. Given the following control-driven scenario: > > > > ------a __________ > > \ / \ > > c---d---| 142.23.5 | > > / \__________/ > > ------b > > > > The diagram above shows a portion of a network. Let a, b, c and d be the > > LSRs. Let LSR d attached to network 142.23.5. At any moment LSR d >assigns a > > label #30 to an FEC which describes the address prefix 142.23.5 and > > advertises the binding to c. LSR c determines that it will use LSR d as >its > > next hop to deliver packets to 142.23.5 thus assigns label #56 and #21 >for > > that FEC and advertises to its upstream neighbours a and b respectively. > > Both upstream LSRs accept the binding information and perform the same > > binding procedures. Obviously the path establishment here uses >unsolicited > > downstream label binding. The question is, what form of distribution >control > > is this? My bet is that it should be ordered control. > >Using two different labels suggests to me you're thinking about doing this >over ATM. There you should be doing downstream on demand ordered control. >So I would be surprised to see c independently assigning labels. >If the same label were advertised to both neighbors, then MPLS over frame >is probably in place doing unsolicited unordered control. My example does not favour for any specific architecture. My question is plain; is it an ordered control or independent control label distribution? Your answer I believe is unsolicited independent control and you are the second person to give this answer after Rick Gallaher. However, I have doubt with the answer. In my example, notice that the label distribution is control-driven triggered by routing information and it starts from the egress up to the rest of the LSR in an orderly manner (it was my mistake not to clearly state this earlier but it should be obvious from my statement.) Both RFC3031 and the book "MPLS: Technology and Applications" state that if the label distribution is done in orderly fashion from any one end to another, it is an ordered control label distribution. If this is true that the example is an ordered control, then I have answer my own previous question -- ordered control does not mean downstream on demand. In Rick's reply to my questions, he pointed out that independent control can be achieved by downstream on demand but he has never seen this kind of combination before in practice. Anyone can give an example of this, please? -Tze Ven _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-mpls@UU.NET Wed Apr 3 10:15:40 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05538 for ; Wed, 3 Apr 2002 10:15: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 QQmizs03072; Wed, 3 Apr 2002 15:14:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmizs10387 for mpls-outgoing; Wed, 3 Apr 2002 15:13: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 QQmizs10382 for ; Wed, 3 Apr 2002 15:13:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmizs12771 for ; Wed, 3 Apr 2002 15:11:38 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 QQmizs06722 for ; Wed, 3 Apr 2002 15:11:33 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 KAA24430 for ; Wed, 3 Apr 2002 10:11:32 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA07676 for mpls@uu.net; Wed, 3 Apr 2002 10:11:32 -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 QQmiyq25756 for ; Wed, 3 Apr 2002 08:01:19 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 QQmiyq11203 for ; Wed, 3 Apr 2002 08:00:57 GMT Received: from tlvsdy.vim.tlt.alcatel.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tlvsdy.vim.tlt.alcatel.it [194.243.74.244]) id QQmiyq18975 for ; Wed, 3 Apr 2002 08:00:56 GMT Received: from tlvhdk.netit.alcatel.it (localhost [127.0.0.1]) by tlvsdy.vim.tlt.alcatel.it (8.9.3+Sun/8.9.3) with ESMTP id KAA13772 for ; Wed, 3 Apr 2002 10:02:26 +0200 (MET DST) Received: from ipt010 (ipt010.tndl.alcatel.it [151.98.36.75]) by tlvhdk.netit.alcatel.it (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA23853 for ; Wed, 3 Apr 2002 10:01:30 +0200 (METDST) Message-ID: <069101c1dae5$3777f960$4b246297@vim.tlt.alcatel.it> From: "Roberto Guglielmi" To: Subject: LDP Generic label spaces Date: Wed, 3 Apr 2002 09:57:34 +0200 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 everyone, I have a question regarding LDP Generic label spaces. RFC 3036, paragraph 3.5.3, pag. 59/62, states: "A receiving LSR MUST calculate the intersection between the received range and its own supported label range. The intersection is the range in which the LSR may allocate and accept labels. LSRs MUST NOT establish a session with neighbors for which the intersection of ranges is NULL. In this case, the LSR must send a Session Rejected/Parameters Label Range Notification message in response to the Initialization message and not establish the session." This is valid for ATM and FR interfaces. Suppose I use only Generic Interfaces. Peer LSRs don't exchange label ranges. Is it a manager's matter to choose the label ranges on the upside LSR and the downside LSR which intersect? Do these ranges have to be coincident? Or are labels chosen by some other means in order to accepted by the LSRs? Thanks in advance for you help. Regards, Roberto Guglielmi From owner-mpls@UU.NET Wed Apr 3 10:41:02 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06816 for ; Wed, 3 Apr 2002 10:41:02 -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 QQmizu23562; Wed, 3 Apr 2002 15:39:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmizu12964 for mpls-outgoing; Wed, 3 Apr 2002 15:39: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 QQmizu12959 for ; Wed, 3 Apr 2002 15:39:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmizu03754 for ; Wed, 3 Apr 2002 15:38:01 GMT Received: from smtp2.cluster.oleane.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.cluster.oleane.net [195.25.12.17]) id QQmizu21513 for ; Wed, 3 Apr 2002 15:38:00 GMT Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp2.cluster.oleane.net with SMTP id g33Fbxn73362 for ; Wed, 3 Apr 2002 17:37:59 +0200 (CEST) Message-ID: <002e01c1db25$f73b0e00$0701a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPLS World Date: Wed, 3 Apr 2002 17:41:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit MPLS World 2003 will stand in Paris next 4-7 February. The results of the very successfull 2002 edition are detailed at: http://www.upperside.fr/mplswc2003/mplswc03intro.htm Save 10% on sponsoring and exhibiting fees by booking before May 16th. From owner-mpls@UU.NET Thu Apr 4 04:36:01 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07798 for ; Thu, 4 Apr 2002 04:36: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 QQmjco28091; Thu, 4 Apr 2002 09:35:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjco04009 for mpls-outgoing; Thu, 4 Apr 2002 09:35:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmjco03998 for ; Thu, 4 Apr 2002 09:34: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 QQmjco06141 for ; Thu, 4 Apr 2002 09:34:15 GMT Received: from india.mercurykr.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQmjco11527 for ; Thu, 4 Apr 2002 09:34:09 GMT Received: from amar (kapil [165.133.13.19]) by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id OAA27471 for ; Thu, 4 Apr 2002 14:56:28 -0600 (GMT) Message-ID: <000c01c1dbbb$d3257820$130d85a5@dti.daewoo.co.kr> From: "Amarendra" To: References: <002e01c1db25$f73b0e00$0701a8c0@oleane.com> Subject: Label Stacking !! Date: Thu, 4 Apr 2002 15:03:45 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I am very much aware of Label Stack Encoding, but I have a few basic related queries: 1. How do we achieve label stacking using the Signalling protocols like LDP, CR-LDP or RSVP-TE ? 2. Do these protocols really play a role in Label Stacking ? I couldn't find anything specifically related to this in these specs. Has the Extended Discovery mechanism of LDP anything to do with this ? I guess I am missing something here. Could anyone please provide pointers to this ? Regards, Amarendra. From owner-mpls@UU.NET Thu Apr 4 04:45:25 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08116 for ; Thu, 4 Apr 2002 04:45:20 -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 QQmjco11401; Thu, 4 Apr 2002 09:44:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjco04689 for mpls-outgoing; Thu, 4 Apr 2002 09:44:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmjco04681 for ; Thu, 4 Apr 2002 09:44:20 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 QQmjco11453 for ; Thu, 4 Apr 2002 09:44: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 QQmjco25683 for ; Thu, 4 Apr 2002 09:44:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id EAA29099 for ; Thu, 4 Apr 2002 04:44:02 -0500 (EST) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA23683 for mpls@uu.net; Thu, 4 Apr 2002 04:44: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 QQmjco04624 for ; Thu, 4 Apr 2002 09:43:30 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 QQmjco09134 for ; Thu, 4 Apr 2002 09:43:17 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmjco20442 for ; Thu, 4 Apr 2002 09:43:16 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id <2F68AK2J>; Thu, 4 Apr 2002 15:17:48 +0530 Message-ID: From: "Vijayanand C - CTD, Chennai." To: Amarendra Cc: mpls@UU.NET Subject: RE: Label Stacking !! Date: Thu, 4 Apr 2002 15:10:11 +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 amar, Yes the signalling protocols have a role in label stacking if the labels stack is installed by them. CR LDP and RSVP-TE support multiple levels of tunnels. CR-LDP allows the use of LSPID TLV in label request message to acheive this,the remote peering feature of LDP helps in this. In RSVP-TE tunnels are used as Forwarding adjacencies to acheive label stacking/multiple levels of tunneling. Regards, Vijay -----Original Message----- From: Amarendra [mailto:amar@mercurykr.com] Sent: Thursday, April 04, 2002 3:04 PM To: mpls@UU.NET Subject: Label Stacking !! Hi all, I am very much aware of Label Stack Encoding, but I have a few basic related queries: 1. How do we achieve label stacking using the Signalling protocols like LDP, CR-LDP or RSVP-TE ? 2. Do these protocols really play a role in Label Stacking ? I couldn't find anything specifically related to this in these specs. Has the Extended Discovery mechanism of LDP anything to do with this ? I guess I am missing something here. Could anyone please provide pointers to this ? Regards, Amarendra. From owner-mpls@UU.NET Thu Apr 4 05:17:50 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08827 for ; Thu, 4 Apr 2002 05:17:50 -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 QQmjcr26025; Thu, 4 Apr 2002 10:17:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjcr28554 for mpls-outgoing; Thu, 4 Apr 2002 10:16: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 QQmjcr28547 for ; Thu, 4 Apr 2002 10:16:42 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 QQmjcr17625 for ; Thu, 4 Apr 2002 10:16:36 GMT Received: from india.mercurykr.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQmjcr10707 for ; Thu, 4 Apr 2002 10:16:25 GMT Received: from amar (kapil [165.133.13.19]) by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id PAA28905; Thu, 4 Apr 2002 15:38:00 -0600 (GMT) Message-ID: <001801c1dbc1$a0c4aee0$130d85a5@dti.daewoo.co.kr> From: "Amarendra" To: "Vijayanand C - CTD, Chennai." Cc: References: Subject: Re: Label Stacking !! Date: Thu, 4 Apr 2002 15:45:17 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Vijay, Are u talking Forwarding Adjacencies discussed in draft-ietf-mpls-lsp-hierarchy-04.txt, If yes then in this case CR-LDP or LDP can also use the same. Am I right? And does that mean OSPF or IS-IS instance running should also be MPLS aware ? Amarendra ----- Original Message ----- From: "Vijayanand C - CTD, Chennai." To: "Amarendra" Cc: Sent: Thursday, April 04, 2002 3:10 PM Subject: RE: Label Stacking !! > Hi amar, > Yes the signalling protocols have a role in label stacking if the labels > stack is installed by them. > > CR LDP and RSVP-TE support multiple levels of tunnels. CR-LDP allows the use > of LSPID TLV in label request message to acheive this,the remote peering > feature of LDP helps in this. In RSVP-TE tunnels are used as Forwarding > adjacencies to acheive label stacking/multiple levels of tunneling. > > Regards, > Vijay > > -----Original Message----- > From: Amarendra [mailto:amar@mercurykr.com] > Sent: Thursday, April 04, 2002 3:04 PM > To: mpls@UU.NET > Subject: Label Stacking !! > > > Hi all, > I am very much aware of Label Stack Encoding, but I have a few basic related > queries: > 1. How do we achieve label stacking using the Signalling protocols like LDP, > CR-LDP or RSVP-TE ? > 2. Do these protocols really play a role in Label Stacking ? I couldn't find > anything specifically related to this in these specs. Has the Extended > Discovery mechanism of LDP anything to do with this ? I guess I am missing > something here. > Could anyone please provide pointers to this ? > > Regards, > Amarendra. > > From owner-mpls@UU.NET Thu Apr 4 13:28:01 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02663 for ; Thu, 4 Apr 2002 13:28: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 QQmjdx28542; Thu, 4 Apr 2002 18:27:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjdx01850 for mpls-outgoing; Thu, 4 Apr 2002 18:26: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 QQmjdx01843 for ; Thu, 4 Apr 2002 18:26:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmjdx18695 for ; Thu, 4 Apr 2002 18:26:09 GMT Received: from mail.san.yahoo.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.san.yahoo.com [209.132.1.30]) id QQmjdx26731 for ; Thu, 4 Apr 2002 18:26:07 GMT Received: from [65.213.193.52] by mail.san.yahoo.com with HTTP; Thu, 4 Apr 2002 10:26:03 -0800 Date: Thu, 4 Apr 2002 13:26:03 -0500 Message-ID: <3CABB73600000B09@mta08.san.yahoo.com> From: "Kavita Khanna" Subject: Public MPLS Inter-Operability Demo To: mpls@UU.NET MIME-Version: 1.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 NAA02663 The 3rd Public MPLS Inter-Op demonstration will take place at the Internetworking Lab of Isocore on October 30, 2002 - immediately following the MPLS2002 International Conference (October 27-29, 2002, Washington DC). The objective of this public event is to provide an opportunity for networking and test equipment vendors to demonstrate to carriers, service providers, and large customers, new MPLS capabilities and features in a multi-vendor environment. Details are available at: http://www.mpls2002.com/interop.htm Regards, Kavita Khanna Manager, Internetworking Lab ISOCORE http://www.isocore.com From owner-mpls@UU.NET Thu Apr 4 15:48:44 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08224 for ; Thu, 4 Apr 2002 15:48:39 -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 QQmjeh23940; Thu, 4 Apr 2002 20:47:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjeh25455 for mpls-outgoing; Thu, 4 Apr 2002 20:47:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmjeh25448 for ; Thu, 4 Apr 2002 20:47: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 QQmjeh23837 for ; Thu, 4 Apr 2002 20:46:25 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 QQmjeh12154 for ; Thu, 4 Apr 2002 20:46:24 GMT Message-ID: <3CACBB9F.3080900@sandburst.com> Date: Thu, 04 Apr 2002 15:46:23 -0500 From: Eric Gray MIME-Version: 1.0 To: Amarendra Cc: "Vijayanand C - CTD, Chennai." , mpls@UU.NET Subject: Re: Label Stacking !! References: <001801c1dbc1$a0c4aee0$130d85a5@dti.daewoo.co.kr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Amarendra, It isn't actually necessary for a signaling protocol to explicitly support stacking for the signaling protocol to be useful in signaling stacked labels. Consider the case where an LSP is established bi-directionally by two LSR implementations that are (most likely) not adjacent. Now imagine that the implementations allow the combination of these two LSPs to appear as a single link between the LSRs - now making them adjacent via that link. From the implementation's perspective, this looks the same as if a new physical link has been established between the two LSRs. Protocol entities at each LSR can now treat each other as directly adjacent peers. For example, LDP peers could discover each other via this new logical link and signal labels. These labels would be stacked labels. Of course, it's not exactly as simple as that, but you can figure it out if you start there... You wrote: >Hi Vijay, > Are u talking Forwarding Adjacencies discussed in >draft-ietf-mpls-lsp-hierarchy-04.txt, If yes then in this case CR-LDP or LDP >can also use the same. Am I right? And does that mean OSPF or IS-IS instance >running should also be MPLS aware ? > >Amarendra > >----- Original Message ----- >From: "Vijayanand C - CTD, Chennai." >To: "Amarendra" >Cc: >Sent: Thursday, April 04, 2002 3:10 PM >Subject: RE: Label Stacking !! > > >>Hi amar, >>Yes the signalling protocols have a role in label stacking if the labels >>stack is installed by them. >> >>CR LDP and RSVP-TE support multiple levels of tunnels. CR-LDP allows the >> >use > >>of LSPID TLV in label request message to acheive this,the remote peering >>feature of LDP helps in this. In RSVP-TE tunnels are used as Forwarding >>adjacencies to acheive label stacking/multiple levels of tunneling. >> >>Regards, >>Vijay >> >>-----Original Message----- >>From: Amarendra [mailto:amar@mercurykr.com] >>Sent: Thursday, April 04, 2002 3:04 PM >>To: mpls@UU.NET >>Subject: Label Stacking !! >> >> >>Hi all, >>I am very much aware of Label Stack Encoding, but I have a few basic >> >related > >>queries: >>1. How do we achieve label stacking using the Signalling protocols like >> >LDP, > >>CR-LDP or RSVP-TE ? >>2. Do these protocols really play a role in Label Stacking ? I couldn't >> >find > >>anything specifically related to this in these specs. Has the Extended >>Discovery mechanism of LDP anything to do with this ? I guess I am missing >>something here. >>Could anyone please provide pointers to this ? >> >>Regards, >>Amarendra. >> >> > -- -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray From owner-mpls@UU.NET Thu Apr 4 16:07:40 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08822 for ; Thu, 4 Apr 2002 16:07: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 QQmjei23074; Thu, 4 Apr 2002 21:07:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjei16619 for mpls-outgoing; Thu, 4 Apr 2002 21:06:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmjei16408 for ; Thu, 4 Apr 2002 21:06: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 QQmjei12256 for ; Thu, 4 Apr 2002 21:06:33 GMT Received: from web14908.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14908.mail.yahoo.com [216.136.225.60]) id QQmjei12709 for ; Thu, 4 Apr 2002 21:06:33 GMT Message-ID: <20020404210632.62507.qmail@web14908.mail.yahoo.com> Received: from [131.183.19.20] by web14908.mail.yahoo.com via HTTP; Thu, 04 Apr 2002 13:06:32 PST Date: Thu, 4 Apr 2002 13:06:32 -0800 (PST) From: ravi panikkar Subject: shared backup lsp restoration using CR-LDP To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Could anyone tell me if there is a draft which talks about the restoration of shared backup LSPs using CR-LDP? There is a draft which talks about how this can be done using RSVP-TE(draft-kini-rsvp-lsp-restoration). I was wondering if the same could be done using CR-LDP extensions. Any information/pointers will be greatly appreciated Thanks Ravi __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From owner-mpls@UU.NET Thu Apr 4 23:41:20 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19292 for ; Thu, 4 Apr 2002 23:41:19 -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 QQmjfm10172; Fri, 5 Apr 2002 04:40:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjfm26886 for mpls-outgoing; Fri, 5 Apr 2002 04:40: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 QQmjfm26881 for ; Fri, 5 Apr 2002 04:40: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 QQmjfm27621 for ; Fri, 5 Apr 2002 04:39:16 GMT Received: from india.mercurykr.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQmjfm06608 for ; Fri, 5 Apr 2002 04:39:12 GMT Received: from amar (kapil [165.133.13.19]) by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id JAA19870; Fri, 5 Apr 2002 09:58:36 -0600 (GMT) Message-ID: <003b01c1dc5b$61f89420$130d85a5@dti.daewoo.co.kr> From: "Amarendra" To: "Eric Gray" Cc: "Vijayanand C - CTD, Chennai." , References: <001801c1dbc1$a0c4aee0$130d85a5@dti.daewoo.co.kr> <3CACBB9F.3080900@sandburst.com> Subject: Re: Label Stacking !! Date: Fri, 5 Apr 2002 10:05:51 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, I am agree with you. But, how can I allow the combination of these two LSPs to be used as a single link? I mean to say, How can I inform LDP about this link, so that it can use the new logical link as an actual link to discover its new peer. I think I am missing somthing. Amarendra ----- Original Message ----- From: "Eric Gray" To: "Amarendra" Cc: "Vijayanand C - CTD, Chennai." ; Sent: Friday, April 05, 2002 2:16 AM Subject: Re: Label Stacking !! > Amarendra, > > It isn't actually necessary for a signaling protocol to explicitly > support stacking for the signaling protocol to be useful in signaling > stacked labels. > > Consider the case where an LSP is established bi-directionally > by two LSR implementations that are (most likely) not adjacent. > Now imagine that the implementations allow the combination of > these two LSPs to appear as a single link between the LSRs - now > making them adjacent via that link. > > From the implementation's perspective, this looks the same as > if a new physical link has been established between the two LSRs. > Protocol entities at each LSR can now treat each other as directly > adjacent peers. For example, LDP peers could discover each other > via this new logical link and signal labels. These labels would be > stacked labels. > > Of course, it's not exactly as simple as that, but you can figure it > out if you start there... > > You wrote: > > >Hi Vijay, > > Are u talking Forwarding Adjacencies discussed in > >draft-ietf-mpls-lsp-hierarchy-04.txt, If yes then in this case CR-LDP or LDP > >can also use the same. Am I right? And does that mean OSPF or IS-IS instance > >running should also be MPLS aware ? > > > >Amarendra > > > >----- Original Message ----- > >From: "Vijayanand C - CTD, Chennai." > >To: "Amarendra" > >Cc: > >Sent: Thursday, April 04, 2002 3:10 PM > >Subject: RE: Label Stacking !! > > > > > >>Hi amar, > >>Yes the signalling protocols have a role in label stacking if the labels > >>stack is installed by them. > >> > >>CR LDP and RSVP-TE support multiple levels of tunnels. CR-LDP allows the > >> > >use > > > >>of LSPID TLV in label request message to acheive this,the remote peering > >>feature of LDP helps in this. In RSVP-TE tunnels are used as Forwarding > >>adjacencies to acheive label stacking/multiple levels of tunneling. > >> > >>Regards, > >>Vijay > >> > >>-----Original Message----- > >>From: Amarendra [mailto:amar@mercurykr.com] > >>Sent: Thursday, April 04, 2002 3:04 PM > >>To: mpls@UU.NET > >>Subject: Label Stacking !! > >> > >> > >>Hi all, > >>I am very much aware of Label Stack Encoding, but I have a few basic > >> > >related > > > >>queries: > >>1. How do we achieve label stacking using the Signalling protocols like > >> > >LDP, > > > >>CR-LDP or RSVP-TE ? > >>2. Do these protocols really play a role in Label Stacking ? I couldn't > >> > >find > > > >>anything specifically related to this in these specs. Has the Extended > >>Discovery mechanism of LDP anything to do with this ? I guess I am missing > >>something here. > >>Could anyone please provide pointers to this ? > >> > >>Regards, > >>Amarendra. > >> > >> > > > > > -- > -- > Eric Gray (mailto:eric.gray@sandburst.com) > http://www.mindspring.com/~ewgray > > > > From owner-mpls@UU.NET Fri Apr 5 03:09:56 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29920 for ; Fri, 5 Apr 2002 03:09:55 -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 QQmjga15641; Fri, 5 Apr 2002 08:09:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjga05657 for mpls-outgoing; Fri, 5 Apr 2002 08:08: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 QQmjga05652 for ; Fri, 5 Apr 2002 08:08:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmjga22082 for ; Fri, 5 Apr 2002 08:08:16 GMT Received: from india.mercurykr.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQmjga16303 for ; Fri, 5 Apr 2002 08:08:10 GMT Received: from amar (kapil [165.133.13.19]) by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id NAA01689 for ; Fri, 5 Apr 2002 13:30:28 -0600 (GMT) Message-ID: <004201c1dc78$fb26e120$130d85a5@dti.daewoo.co.kr> From: "Amarendra" To: References: <001801c1dbc1$a0c4aee0$130d85a5@dti.daewoo.co.kr> <3CACBB9F.3080900@sandburst.com> Subject: Re: Label Stacking !! Date: Fri, 5 Apr 2002 13:37:44 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric, I am agree with you. But, how can I allow the combination of these two LSPs to be used as a single link? I mean to say, How can I inform LDP about this link, so that it can use the new logical link as an actual link to discover its new peer. I think I am missing somthing. ----- Original Message ----- From: "Eric Gray" To: "Amarendra" Cc: "Vijayanand C - CTD, Chennai." ; Sent: Friday, April 05, 2002 2:16 AM Subject: Re: Label Stacking !! > Amarendra, > > It isn't actually necessary for a signaling protocol to explicitly > support stacking for the signaling protocol to be useful in signaling > stacked labels. > > Consider the case where an LSP is established bi-directionally > by two LSR implementations that are (most likely) not adjacent. > Now imagine that the implementations allow the combination of > these two LSPs to appear as a single link between the LSRs - now > making them adjacent via that link. > > From the implementation's perspective, this looks the same as > if a new physical link has been established between the two LSRs. > Protocol entities at each LSR can now treat each other as directly > adjacent peers. For example, LDP peers could discover each other > via this new logical link and signal labels. These labels would be > stacked labels. > > Of course, it's not exactly as simple as that, but you can figure it > out if you start there... > > You wrote: > > >Hi Vijay, > > Are u talking Forwarding Adjacencies discussed in > >draft-ietf-mpls-lsp-hierarchy-04.txt, If yes then in this case CR-LDP or LDP > >can also use the same. Am I right? And does that mean OSPF or IS-IS instance > >running should also be MPLS aware ? > > > >Amarendra > > > >----- Original Message ----- > >From: "Vijayanand C - CTD, Chennai." > >To: "Amarendra" > >Cc: > >Sent: Thursday, April 04, 2002 3:10 PM > >Subject: RE: Label Stacking !! > > > > > >>Hi amar, > >>Yes the signalling protocols have a role in label stacking if the labels > >>stack is installed by them. > >> > >>CR LDP and RSVP-TE support multiple levels of tunnels. CR-LDP allows the > >> > >use > > > >>of LSPID TLV in label request message to acheive this,the remote peering > >>feature of LDP helps in this. In RSVP-TE tunnels are used as Forwarding > >>adjacencies to acheive label stacking/multiple levels of tunneling. > >> > >>Regards, > >>Vijay > >> > >>-----Original Message----- > >>From: Amarendra [mailto:amar@mercurykr.com] > >>Sent: Thursday, April 04, 2002 3:04 PM > >>To: mpls@UU.NET > >>Subject: Label Stacking !! > >> > >> > >>Hi all, > >>I am very much aware of Label Stack Encoding, but I have a few basic > >> > >related > > > >>queries: > >>1. How do we achieve label stacking using the Signalling protocols like > >> > >LDP, > > > >>CR-LDP or RSVP-TE ? > >>2. Do these protocols really play a role in Label Stacking ? I couldn't > >> > >find > > > >>anything specifically related to this in these specs. Has the Extended > >>Discovery mechanism of LDP anything to do with this ? I guess I am missing > >>something here. > >>Could anyone please provide pointers to this ? > >> > >>Regards, > >>Amarendra. > >> > >> > > > > > -- > -- > Eric Gray (mailto:eric.gray@sandburst.com) > http://www.mindspring.com/~ewgray > > > > From owner-mpls@UU.NET Fri Apr 5 13:50:11 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13040 for ; Fri, 5 Apr 2002 13:50: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 QQmjhr21637; Fri, 5 Apr 2002 18:49:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjhr27107 for mpls-outgoing; Fri, 5 Apr 2002 18:48:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmjhr27102 for ; Fri, 5 Apr 2002 18:48: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 QQmjhr20793 for ; Fri, 5 Apr 2002 18:48:01 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQmjhr22442 for ; Fri, 5 Apr 2002 18:48:00 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 g35IlrT10815; Fri, 5 Apr 2002 10:47:58 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200204051847.g35IlrT10815@merlot.juniper.net> To: Nabil Seddigh cc: mpls@UU.NET Subject: Re: -04 version In-Reply-To: Your message of "Fri, 29 Mar 2002 16:30:26 EST." <3CA4DCF2.83529BDE@tropicnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <50775.1018032472.1@juniper.net> Date: Fri, 05 Apr 2002 10:47:53 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Nabil, > In addition to the changes mentioned below, there is one more > fundamental issue with the Unnumbered Interfaces draft. > > >From previous discussion on this list, it appears that the > Interface ID field of the unnumbered ERO subobject is intended > to represent the incoming interface of the next hop router. > If this is the case, it should be explicitly stated at > the beginning of section 6. > If the intention is to leave it open such that it is either > incoming or outgoing interface then a bit from the reserved > field of the sub-object should indicate which of the two > choices is being used. The intention is to allow either incoming or outgoing. Please show me an example where you think there is a need need for the bit to indicate "which of the two choices is being used". Yakov. > > In the absence of one of the above two alternatives, we would > appear to have a case of ambiguity by design - not usually > preferred when you are standardizing something. > > Best, > Nabil Seddigh > > > Yakov Rekhter wrote: > > > > Nabil, > > > > > Yakov, > > > > > > I suggest adding a section with title error handling - between > > > section 6.2 and section 7. Having its own section is good as one > > > would typically expect a note on error handling in this kind of > > > a draft. The section could indicate something like: > > > > > > Section 7.0 > > > ----------- > > > "In order to indicate the interfaces on which a particular error > > > occured, a new IF_ID ERROR_SPEC object is defined. The definitions > > > can be found in draft-ietf-mpls-generalized-rsvp-te-06.txt and > > > draft-ietf-mpls-generalized-signaling-07.txt" > > > > > > Also section 6.1 indicates that the LSR should return error. > > > However, it does not specify whether the PathErr message > > > will contain an existing error code or a new one to > > > be defined by IANA. Could you clarify. > > > > -05 version of the draft (just announced) addresses this. > > > > Yakov. > > > > > > > > --- > > > Best, > > > Nabil Seddigh > > > nseddigh@tropicnetworks.com > > > > > > > > > > > 2. Also, if the unnum draft is not going to talk about error spec > > > > > it should reference the draft that defines the new > > > > > error_spec object for unnumbered links - > > > > > draft-ietf-mpls-generalized-rsvp-te-06.txt > > > > > > > > please tell me where would you like to insert the reference, > > > > and I'll add it. > > > > > > > > Yakov. > > > > From owner-mpls@UU.NET Fri Apr 5 17:20:12 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02285 for ; Fri, 5 Apr 2002 17:20: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 QQmjif22542; Fri, 5 Apr 2002 22:18:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjif07610 for mpls-outgoing; Fri, 5 Apr 2002 22:18: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 QQmjif07605 for ; Fri, 5 Apr 2002 22:18:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmjif07626 for ; Fri, 5 Apr 2002 22:15:41 GMT Received: from zcars04f.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmjif15683 for ; Fri, 5 Apr 2002 22:15:41 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g35MFNe26018; Fri, 5 Apr 2002 17:15:23 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Apr 2002 17:15:23 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3402A5E8E5@zcard0ka.ca.nortel.com> From: "David Allan" To: ravi panikkar , mpls@UU.NET Subject: RE: shared backup lsp restoration using CR-LDP Date: Fri, 5 Apr 2002 17:15:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCEF.5B73F006" 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_01C1DCEF.5B73F006 Content-Type: text/plain; charset="iso-8859-1" Hi Ravi: To the best of my knowledge, the topic of FRR via local repair has not been addressed by any drafts associated with CR-LDP. We've focused more on fast restoration using feedback. As to whether extensions to CR-LDP can be defined to permit shared mesh restoration (avoiding double booking of backup resources diverse with sets of diverse paths), the answer should be yes. I'm not aware that any work has actually been done. cheers Dave > -----Original Message----- > From: ravi panikkar [mailto:ravi_panikkar@yahoo.com] > Sent: Thursday, April 04, 2002 4:07 PM > To: mpls@UU.NET > Subject: shared backup lsp restoration using CR-LDP > > > Hi > Could anyone tell me if there is a draft which talks > about the restoration of shared backup LSPs using > CR-LDP? There is a draft which talks about how this > can be done using > RSVP-TE(draft-kini-rsvp-lsp-restoration). I was > wondering if the same could be done using CR-LDP > extensions. > > Any information/pointers will be greatly appreciated > > Thanks > Ravi > > __________________________________________________ > Do You Yahoo!? > Yahoo! Tax Center - online filing with TurboTax > http://taxes.yahoo.com/ > ------_=_NextPart_001_01C1DCEF.5B73F006 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: shared backup lsp restoration using CR-LDP

Hi Ravi:

To the best of my knowledge, the topic of FRR via = local repair has not been addressed by any drafts associated with = CR-LDP. We've focused more on fast restoration using = feedback.

As to whether extensions to CR-LDP can be defined to = permit shared mesh restoration (avoiding double booking of backup = resources diverse with sets of diverse paths), the answer should be = yes. I'm not aware that any work has actually been done.

cheers
Dave



> -----Original Message-----
> From: ravi panikkar [mailto:ravi_panikkar@yahoo.com]
> Sent: Thursday, April 04, 2002 4:07 PM
> To: mpls@UU.NET
> Subject: shared backup lsp restoration using = CR-LDP
>
>
> Hi
> Could anyone tell me if there is a draft which = talks
> about the restoration of shared backup LSPs = using
> CR-LDP? There is a draft which talks about how = this
> can be done using
> RSVP-TE(draft-kini-rsvp-lsp-restoration). I = was
> wondering if the same could be done using = CR-LDP
> extensions.
>
> Any information/pointers will be greatly = appreciated
>
> Thanks
> Ravi
>
> = __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with = TurboTax
> http://taxes.yahoo.com/
>

------_=_NextPart_001_01C1DCEF.5B73F006-- From owner-mpls@UU.NET Fri Apr 5 20:44:56 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17146 for ; Fri, 5 Apr 2002 20:44:56 -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 QQmjis03156; Sat, 6 Apr 2002 01:44:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjis25702 for mpls-outgoing; Sat, 6 Apr 2002 01:44: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 QQmjis25692 for ; Sat, 6 Apr 2002 01:43: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 QQmjis26550 for ; Sat, 6 Apr 2002 01:43:57 GMT Received: from 21cn.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [61.140.60.248]) id QQmjis14569 for ; Sat, 6 Apr 2002 01:43:54 GMT Received: from 21cn.com([10.2.1.2]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jmc13cae919b; Sat, 06 Apr 2002 09:40:19 +0800 Received: from cmr0.ash.ops.us.uu.net([198.5.241.38]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm10e3ca99aee; Tue, 02 Apr 2002 15:40:37 +0800 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 QQmiuw14352; Tue, 2 Apr 2002 07:42:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmiuw20953 for mpls-outgoing; Tue, 2 Apr 2002 07:41: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 QQmiuw20939 for ; Tue, 2 Apr 2002 07:41:43 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 QQmiuw21902 for ; Tue, 2 Apr 2002 07:40:54 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f11.pav2.hotmail.com [64.4.37.11]) id QQmiuw11556 for ; Tue, 2 Apr 2002 07:40:54 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 1 Apr 2002 23:40:53 -0800 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 02 Apr 2002 07:40:53 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Confusing Terms Date: Tue, 02 Apr 2002 07:40:53 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Apr 2002 07:40:53.0475 (UTC) FILETIME=[B7BD2B30:01C1DA19] Sender: owner-mpls@UU.NET Precedence: bulk Hi, Thank you for answering my questions. Okay now I am sure that the 'distribution' is a separate process from 'binding'. I was confused since I read "MPLS: Technology and Applications" by Davie & Rekhter. They introduced the terms local binding and remote binding. And of course these do not involve any distribution, just purely the origin of label binding occurance. Immediately after that, they described upstream/downstream bindings as way of populating the forwarding table with labels that are of local/remote bindings. In their description, they also mentioned the direction of label distribution. And that has caused me to confuse the true meaning of 'distribution' and 'binding' used in MPLS. Probably they mentioned the flow of label binding information just for the sake of making their statement complete. To end this paragraph, upstream/downstream binding is orthogonal to upstream/downstream distribution. Full stop. Unfortunately I am still confuse with 'distribution' terms. The downstream on demand and unsolicted downstream label distributions define how and when label is being distributed. However, independent and ordered controls also describe similar label distribution processes. And since you said ordered control can only be achieved by downstream on demand label distribution, the question is, what are their differences to warrant them with different terms? Or does ordered control mean downstream on demand? (the same is true for independent control if it can only be achieved by unsolicted downstream label distribution.) > > 3. Given the following control-driven scenario: > > > > ------a __________ > > \ / \ > > c---d---| 142.23.5 | > > / \__________/ > > ------b > > > > The diagram above shows a portion of a network. Let a, b, c and d be the > > LSRs. Let LSR d attached to network 142.23.5. At any moment LSR d >assigns a > > label #30 to an FEC which describes the address prefix 142.23.5 and > > advertises the binding to c. LSR c determines that it will use LSR d as >its > > next hop to deliver packets to 142.23.5 thus assigns label #56 and #21 >for > > that FEC and advertises to its upstream neighbours a and b respectively. > > Both upstream LSRs accept the binding information and perform the same > > binding procedures. Obviously the path establishment here uses >unsolicited > > downstream label binding. The question is, what form of distribution >control > > is this? My bet is that it should be ordered control. > >Using two different labels suggests to me you're thinking about doing this >over ATM. There you should be doing downstream on demand ordered control. >So I would be surprised to see c independently assigning labels. >If the same label were advertised to both neighbors, then MPLS over frame >is probably in place doing unsolicited unordered control. My example does not favour for any specific architecture. My question is plain; is it an ordered control or independent control label distribution? Your answer I believe is unsolicited independent control and you are the second person to give this answer after Rick Gallaher. However, I have doubt with the answer. In my example, notice that the label distribution is control-driven triggered by routing information and it starts from the egress up to the rest of the LSR in an orderly manner (it was my mistake not to clearly state this earlier but it should be obvious from my statement.) Both RFC3031 and the book "MPLS: Technology and Applications" state that if the label distribution is done in orderly fashion from any one end to another, it is an ordered control label distribution. If this is true that the example is an ordered control, then I have answer my own previous question -- ordered control does not mean downstream on demand. In Rick's reply to my questions, he pointed out that independent control can be achieved by downstream on demand but he has never seen this kind of combination before in practice. Anyone can give an example of this, please? -Tze Ven _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-mpls@UU.NET Sat Apr 6 10:02:11 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11648 for ; Sat, 6 Apr 2002 10:02: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 QQmjku18343; Sat, 6 Apr 2002 15:01:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjku02816 for mpls-outgoing; Sat, 6 Apr 2002 15:01:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmjku02691 for ; Sat, 6 Apr 2002 15:01: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 QQmjku16477 for ; Sat, 6 Apr 2002 15:00:38 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f92.pav2.hotmail.com [64.4.37.92]) id QQmjku06174 for ; Sat, 6 Apr 2002 15:00:37 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 6 Apr 2002 07:00:36 -0800 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Sat, 06 Apr 2002 15:00:36 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: mpls-ops@mplsrc.com, mpls@UU.NET Date: Sat, 06 Apr 2002 15:00:36 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Apr 2002 15:00:36.0875 (UTC) FILETIME=[CF1F85B0:01C1DD7B] Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a question, In RFC3036, it mentions that full address of an Address Prefix is treated differently from Host Address. As far as I understood from the document, if a packet cannot be matched with any FEC, and it is known that the packet must traverse a particular egress router to reach the destination, then it is allowable to map the packet to LSP whose Address Prefix FEC element is the address of that egress router, but not to LSP whose Host Address FEC element is the address of that similar egress. Why it is a necessity to distinguish between a full address prefix with a similar host address? A little help would be very much appreciated. -Tze Ven _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Sun Apr 7 01:31:26 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22467 for ; Sun, 7 Apr 2002 01:31: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 QQmjne04325; Sun, 7 Apr 2002 06:30:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjne12376 for mpls-outgoing; Sun, 7 Apr 2002 06:30: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 QQmjne12369 for ; Sun, 7 Apr 2002 06:30:29 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 QQmjne24655 for ; Sun, 7 Apr 2002 06:30:12 GMT Received: from 21cn.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [61.140.60.248]) id QQmjne12313 for ; Sun, 7 Apr 2002 06:30:09 GMT Message-Id: Received: from wxd([202.120.8.31]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm153caffd29; Sun, 07 Apr 2002 14:31:01 +0800 Date: Sun, 7 Apr 2002 14:35:14 +0800 From: "X.D.Wang" To: "mpls-ops@mplsrc.com" , "mpls@UU.net" Subject: Is it a fault? 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: In RFC3215 'LDP State Machine', 3.9.2 : State -- "ESTABLISHED" State: ESTABLISHED Event: LDP withdraw New State: IDLE Actions For each Upstream_LSP_control_block for this FEC, pass event `Internal downstream Withdraw' to its state machine. Send a LDP Withdraw downstream. I think it should be 'send a ldp release downstream', am I right? thanks wang From owner-mpls@UU.NET Sun Apr 7 23:38:40 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06379 for ; Sun, 7 Apr 2002 23:38:40 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmjqk04596; Mon, 8 Apr 2002 03:38:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjqk07106 for mpls-outgoing; Mon, 8 Apr 2002 03:37: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 QQmjqk07101 for ; Mon, 8 Apr 2002 03:37: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 QQmjqk09732 for ; Mon, 8 Apr 2002 03:37:18 GMT Received: from 21cn.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [61.140.60.248]) id QQmjqk22038 for ; Mon, 8 Apr 2002 03:37:16 GMT Received: from 21cn.com([10.2.1.1]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm93cb12ff0; Mon, 08 Apr 2002 11:36:30 +0800 Received: from cmr1.ash.ops.us.uu.net([198.5.241.39]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm353cac4f1e; Thr, 04 Apr 2002 17:35:26 +0800 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 QQmjco29174; Thu, 4 Apr 2002 09:36:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjco04009 for mpls-outgoing; Thu, 4 Apr 2002 09:35:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmjco03998 for ; Thu, 4 Apr 2002 09:34: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 QQmjco06141 for ; Thu, 4 Apr 2002 09:34:15 GMT Received: from india.mercurykr.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [165.133.13.60]) id QQmjco11527 for ; Thu, 4 Apr 2002 09:34:09 GMT Received: from amar (kapil [165.133.13.19]) by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id OAA27471 for ; Thu, 4 Apr 2002 14:56:28 -0600 (GMT) Message-ID: <000c01c1dbbb$d3257820$130d85a5@dti.daewoo.co.kr> From: "Amarendra" To: References: <002e01c1db25$f73b0e00$0701a8c0@oleane.com> Subject: Label Stacking !! Date: Thu, 4 Apr 2002 15:03:45 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I am very much aware of Label Stack Encoding, but I have a few basic related queries: 1. How do we achieve label stacking using the Signalling protocols like LDP, CR-LDP or RSVP-TE ? 2. Do these protocols really play a role in Label Stacking ? I couldn't find anything specifically related to this in these specs. Has the Extended Discovery mechanism of LDP anything to do with this ? I guess I am missing something here. Could anyone please provide pointers to this ? Regards, Amarendra. From owner-mpls@UU.NET Mon Apr 8 05:17:08 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18366 for ; Mon, 8 Apr 2002 05:17:08 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmjrh26374; Mon, 8 Apr 2002 09:15:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjrg08028 for mpls-outgoing; Mon, 8 Apr 2002 09:14:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmjrg08023 for ; Mon, 8 Apr 2002 09:14:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmjrg14946 for ; Mon, 8 Apr 2002 09:14:41 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe51.law9.hotmail.com [64.4.8.40]) id QQmjrg17184 for ; Mon, 8 Apr 2002 09:14:40 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Apr 2002 02:14:40 -0700 X-Originating-IP: [212.199.233.65] From: "Doug Degan" To: Subject: Fast reroute - problematic scenario Date: Mon, 8 Apr 2002 12:14:35 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C1DEF6.F2BB3240" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 08 Apr 2002 09:14:40.0301 (UTC) FILETIME=[D0112DD0:01C1DEDD] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C1DEF6.F2BB3240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable After a protected primary LSP 'P' was established using bypass tunnel = 'B' in a certain PLR - (and signaling to the Ingress using the RRO that the LSP is protected = there) what will happen when shutting down tunnel X ? (manually or because of = topology change/failures) what about signaling to the Ingress? what about PLR actions? - like trying to find another bypass. thanks again=20 doug ------=_NextPart_000_0014_01C1DEF6.F2BB3240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
After a protected primary LSP 'P' was = established=20 using bypass tunnel 'B' in a certain PLR -
(and signaling to the Ingress using the = RRO that=20 the LSP is protected there)
what will happen when shutting down = tunnel X ?=20 (manually or because of topology change/failures)
 
what about signaling to the = Ingress?
what about PLR actions? - like trying = to find=20 another bypass.
 
 
thanks again
doug
 
 
 
------=_NextPart_000_0014_01C1DEF6.F2BB3240-- From owner-mpls@UU.NET Mon Apr 8 05:26:32 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18461 for ; Mon, 8 Apr 2002 05:26:32 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmjrh03668; Mon, 8 Apr 2002 09:20:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjrh08643 for mpls-outgoing; Mon, 8 Apr 2002 09:19:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmjrh08638 for ; Mon, 8 Apr 2002 09:19:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmjrh26468 for ; Mon, 8 Apr 2002 09:19:45 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f156.pav2.hotmail.com [64.4.37.156]) id QQmjrh24409 for ; Mon, 8 Apr 2002 09:19:44 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Apr 2002 02:19:44 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Mon, 08 Apr 2002 09:19:43 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: Label Stacking !! Date: Mon, 08 Apr 2002 09:19:43 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Apr 2002 09:19:44.0039 (UTC) FILETIME=[851BEB70:01C1DEDE] Sender: owner-mpls@UU.NET Precedence: bulk Hi, Are you questioning how an LSR knows when to label stack? If that is your question IMHO, if the LSR in question awares that it is not directly linked to its peer, meaning that it is connected to the peer via a logical link that might have been established by means of traffic engineering where there exist one or more intermediate LSRs between the peer and itself, then it must perform label stacking. In this case, the LSR of interest must have engaged with its peer through LDP session found via extended discovery mechanism. All label exchanges within this session are associated with label stacking. Although the LSR, at some point, views and treats the logical link as though it is one hop away link, but in actual fact it is a path. Why two non-directly connected peers must perform label stacking is very obvious. The first level label (top label) is used to tunnel a packet through the logical link, the second level label is used by the receiving LSR at the other end of the tunnel for further label switching. I may be wrong, but that is how I understand it. You may want to confirm this yourself. Please refer to RFC 3036 pg.10. -Tze Ven. >From: "Amarendra" >To: >Subject: Label Stacking !! >Date: Thu, 4 Apr 2002 15:03:45 +0530 > >Hi all, >I am very much aware of Label Stack Encoding, but I have a few basic >related >queries: >1. How do we achieve label stacking using the Signalling protocols like >LDP, >CR-LDP or RSVP-TE ? >2. Do these protocols really play a role in Label Stacking ? I couldn't >find >anything specifically related to this in these specs. Has the Extended >Discovery mechanism of LDP anything to do with this ? I guess I am missing >something here. >Could anyone please provide pointers to this ? > >Regards, >Amarendra. > _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-mpls@UU.NET Mon Apr 8 05:48:32 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18676 for ; Mon, 8 Apr 2002 05:48:32 -0400 (EDT) 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 QQmjri26465; Mon, 8 Apr 2002 09:41:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjri10198 for mpls-outgoing; Mon, 8 Apr 2002 09:41:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmjri10193 for ; Mon, 8 Apr 2002 09:41:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmjri09213 for ; Mon, 8 Apr 2002 09:41:34 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f26.pav2.hotmail.com [64.4.37.26]) id QQmjri25856 for ; Mon, 8 Apr 2002 09:41:33 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Apr 2002 02:41:33 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Mon, 08 Apr 2002 09:41:32 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RFC 3036: Missing Section Date: Mon, 08 Apr 2002 09:41:32 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Apr 2002 09:41:33.0309 (UTC) FILETIME=[917EAAD0:01C1DEE1] Sender: owner-mpls@UU.NET Precedence: bulk Hi, On page 49, section 3.5.1.2.2. of RFC 3036 refers reader to a missing section -- "Unknown TLV in Known Message Type". Is this section accidentally excluded? -Tze Ven _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-mpls@UU.NET Mon Apr 8 06:02:58 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18861 for ; Mon, 8 Apr 2002 06:02:57 -0400 (EDT) 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 QQmjrj20164; Mon, 8 Apr 2002 09:58:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjrj11571 for mpls-outgoing; Mon, 8 Apr 2002 09:58:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmjrj11566 for ; Mon, 8 Apr 2002 09:57:54 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 QQmjrj28117 for ; Mon, 8 Apr 2002 09:57:37 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe14.law9.hotmail.com [64.4.8.118]) id QQmjrj19182 for ; Mon, 8 Apr 2002 09:57:37 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Apr 2002 02:57:36 -0700 X-Originating-IP: [212.199.233.65] From: "Doug Degan" To: "Jean Philippe Vasseur" Cc: References: <4.3.2.7.2.20020408112234.05620eb8@paris.cisco.com> Subject: Re: Fast reroute - problematic scenario Date: Mon, 8 Apr 2002 12:57:35 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C1DEFC.F42736A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 08 Apr 2002 09:57:36.0793 (UTC) FILETIME=[CFC6A890:01C1DEE3] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C1DEFC.F42736A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ill try. in the bypass method it is assumed that PLR choose from pre-established = bypass enabled tunnels when getting request to establish a protected = LSP. then it signals back to the Ingress of the primary LSP that it is localy = protected at this point. now if the used bypass tunnel become not active (doesn't matter how) = what should the PLR do? 1) to signal the Ingress that the primary protected LSP is not protected = at this point? or not? 2) to try to choose another tunnel to be used as bypass? or not? 3) to send path error to the ingress for the protected LSP? or not? 4) to ignore the failure of the bypass LSP?=20 thanks. dd. ----- Original Message -----=20 From: Jean Philippe Vasseur=20 To: Doug Degan=20 Cc: mpls@UU.NET=20 Sent: Monday, April 08, 2002 12:24 PM Subject: Re: Fast reroute - problematic scenario Hi, At 12:14 08/04/2002 +0300, Doug Degan wrote: After a protected primary LSP 'P' was established using bypass = tunnel 'B' in a certain PLR - (and signaling to the Ingress using the RRO that the LSP is = protected there) what will happen when shutting down tunnel X ? (manually or because = of topology change/failures) your question is not 100% clear. Could you elaborate ? what about signaling to the Ingress? what about PLR actions? - like trying to find another bypass. =20 =20 thanks again=20 doug =20 =20 =20 ------=_NextPart_000_0034_01C1DEFC.F42736A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ill try.
in the bypass method it is assumed that = PLR choose=20 from pre-established bypass enabled tunnels when getting request to = establish a=20 protected LSP.
then it signals back to the Ingress of = the primary=20 LSP that it is localy protected at this point.
 
now if the used bypass tunnel become = not active=20 (doesn't matter how) what should the PLR do?
 
1) to signal the Ingress that the = primary protected=20 LSP is not protected at this point? or not?
2) to try to choose another tunnel to = be used as=20 bypass? or not?
3) to send path error to the ingress = for the=20 protected LSP? or not?
4) to ignore the failure of the bypass = LSP?=20
 
thanks.
dd.
----- Original Message -----
From:=20 Jean = Philippe=20 Vasseur
To: Doug=20 Degan
Sent: Monday, April 08, 2002 = 12:24=20 PM
Subject: Re: Fast reroute - = problematic=20 scenario

Hi,

At 12:14 08/04/2002 +0300, Doug Degan = wrote:
After a = protected=20 primary LSP 'P' was established using bypass tunnel 'B' in a certain = PLR=20 -
(and signaling to the = Ingress using the=20 RRO that the LSP is protected there)
what=20 will happen when shutting down tunnel X ? (manually or because of = topology=20 change/failures)

your question is not = 100% clear.=20 Could you elaborate ?


what = about=20 signaling to the Ingress?
what = about PLR=20 actions? - like trying to find another=20 bypass.
 
 
thanks again=20
doug
 
 
 
------=_NextPart_000_0034_01C1DEFC.F42736A0-- From owner-mpls@UU.NET Mon Apr 8 10:31:58 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25184 for ; Mon, 8 Apr 2002 10:31:58 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmjsb26502; Mon, 8 Apr 2002 14:28:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjsb17217 for mpls-outgoing; Mon, 8 Apr 2002 14:27:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmjsb17212 for ; Mon, 8 Apr 2002 14:27:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmjsb00821 for ; Mon, 8 Apr 2002 14:26:50 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 QQmjsb24794 for ; Mon, 8 Apr 2002 14:26: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 KAA03822 for ; Mon, 8 Apr 2002 10:26:49 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA04253 for mpls@uu.net; Mon, 8 Apr 2002 10:26:49 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmjgy29534 for ; Fri, 5 Apr 2002 14:03:24 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmjgy28617 for ; Fri, 5 Apr 2002 14:02:56 GMT Received: from tlvsdy.vim.tlt.alcatel.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tlvsdy.vim.tlt.alcatel.it [194.243.74.244]) id QQmjgy03815 for ; Fri, 5 Apr 2002 14:02:55 GMT Received: from tlvhdk.netit.alcatel.it (localhost [127.0.0.1]) by tlvsdy.vim.tlt.alcatel.it (8.9.3+Sun/8.9.3) with ESMTP id QAA28519 for ; Fri, 5 Apr 2002 16:04:24 +0200 (MET DST) Received: from ipt010 (ipt010.tndl.alcatel.it [151.98.36.75]) by tlvhdk.netit.alcatel.it (8.8.6 (PHNE_17135)/8.8.6) with SMTP id QAA07913 for ; Fri, 5 Apr 2002 16:03:28 +0200 (METDST) Message-ID: <095b01c1dcaa$17144540$4b246297@vim.tlt.alcatel.it> From: "Roberto Guglielmi" To: Subject: Need help!! Label Space issue Date: Fri, 5 Apr 2002 15:59:22 +0200 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, I would appreciate your help to clear my doubt regarding LDP Generic label spaces. RFC 3036, paragraph 3.5.3, pag. 59/62, states: "A receiving LSR MUST calculate the intersection between the received range and its own supported label range. The intersection is the range in which the LSR may allocate and accept labels. LSRs MUST NOT establish a session with neighbors for which the intersection of ranges is NULL. In this case, the LSR must send a Session Rejected/Parameters Label Range Notification message in response to the Initialization message and not establish the session." This is valid for ATM and FR interfaces. Suppose I use only Generic Interfaces. In this case peer LSRs don't exchange label ranges. Which of the following solutions is correct? 1) Is the node upstream supposed to accept any label the node downstream chooses? 2) Is it a manager's matter to choose the consistent label ranges on the upside LSR and the downside LSR? If so, do these ranges have to be coincident? Thanks in advance for you help. Regards, Roberto Guglielmi From owner-mpls@UU.NET Mon Apr 8 11:39:32 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27277 for ; Mon, 8 Apr 2002 11:39:32 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmjsg29555; Mon, 8 Apr 2002 15:35:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjsg13861 for mpls-outgoing; Mon, 8 Apr 2002 15:34:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmjsg13848 for ; Mon, 8 Apr 2002 15:34:54 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 QQmjsg08462 for ; Mon, 8 Apr 2002 15:33:50 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 QQmjsg27835 for ; Mon, 8 Apr 2002 15:33:50 GMT Message-ID: <3CB1B85C.3050306@sandburst.com> Date: Mon, 08 Apr 2002 11:33:48 -0400 From: Eric Gray MIME-Version: 1.0 To: Roberto Guglielmi Cc: mpls@UU.NET Subject: Re: Need help!! Label Space issue References: <095b01c1dcaa$17144540$4b246297@vim.tlt.alcatel.it> Content-Type: multipart/related; boundary="------------050409060508090005000308" Sender: owner-mpls@UU.NET Precedence: bulk --------------050409060508090005000308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Roberto, Same question, same answer. > There are presumably lots of clever things a vendor could do by > partitioning the range of generic labels. The question is: why make > every other implementation pay for this cleverness in terms of the > protocol complexity and interoperability issues? Might as well ask > your friends to wear horse costumes so that you'll be taken more > seriously then they will. [:-)] > > Since the generic labels are just 20-bit numbers that are inserted > in the packet (shim) header, there is only one obvious reason why we > may not expect that the upstream LSR can insert whatever number > we want it to. That reason is if the upstream LSR wants separate > labels so that it can (for some reason) treat the traffic distinctly. It > is obvious that this reason has nothing to do with ranging labels and > it is handled easily enough by the fact that the downstream LSR is > not allowed to return the same label for separate label requests (or > for any label requests if DU distribution is in use). > > Otherwise, yes we do expect the upstream LSR to be able to use > any label we tell it to. If it cannot, it can try again, get a different > label and release the first one. But I know of no reason why LSRs > would need to do this and this will not work for range problems... You wrote: >Hi all, >I would appreciate your help to clear my doubt regarding LDP Generic label >spaces. > >RFC 3036, paragraph 3.5.3, pag. 59/62, states: > "A receiving LSR MUST calculate the intersection between the > received range and its own supported label range. The > intersection is the range in which the LSR may allocate and > accept labels. LSRs MUST NOT establish a session with > neighbors for which the intersection of ranges is NULL. In > this case, the LSR must send a Session Rejected/Parameters > Label Range Notification message in response to the > Initialization message and not establish the session." > >This is valid for ATM and FR interfaces. > >Suppose I use only Generic Interfaces. In this case peer LSRs don't exchange >label >ranges. Which of the following solutions is correct? > >1) Is the node upstream supposed to accept any label the node downstream >chooses? > Yes. > > >2) Is it a manager's matter to choose the consistent label ranges on the >upside LSR and the downside LSR? If so, do these ranges have to be coincident? > Yes, for ATM and FR. Ranges are not defined/supported for Generic labels, so it is very likely implementations will not provide a means to configure label ranges. > > >Thanks in advance for you help. >Regards, >Roberto Guglielmi > > > -- -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray --------------050409060508090005000308-- From owner-mpls@UU.NET Mon Apr 8 12:36:16 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29293 for ; Mon, 8 Apr 2002 12:36:16 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmjsk22128; Mon, 8 Apr 2002 16:33:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjsk09484 for mpls-outgoing; Mon, 8 Apr 2002 16:33:37 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 QQmjsk09477 for ; Mon, 8 Apr 2002 16:33: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 QQmjsk28354 for ; Mon, 8 Apr 2002 16:33:00 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmjsk20324 for ; Mon, 8 Apr 2002 16:33:00 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA12085 for ; Mon, 8 Apr 2002 12:32:59 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA06485 for mpls@uu.net; Mon, 8 Apr 2002 12:32:57 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmjrh08998 for ; Mon, 8 Apr 2002 09:25: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 QQmjrh28494 for ; Mon, 8 Apr 2002 09:24:34 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 QQmjrh08297 for ; Mon, 8 Apr 2002 09:24:34 GMT Received: from JVASSEUR-W2K.cisco.com (ams-clip-vpn-dhcp4144.cisco.com [10.50.16.47]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA19407; Mon, 8 Apr 2002 11:24:30 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020408112234.05620eb8@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Apr 2002 11:24:29 +0200 To: "Doug Degan" From: Jean Philippe Vasseur Subject: Re: Fast reroute - problematic scenario Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8380810==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_8380810==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, At 12:14 08/04/2002 +0300, Doug Degan wrote: >After a protected primary LSP 'P' was established using bypass tunnel 'B' >in a certain PLR - >(and signaling to the Ingress using the RRO that the LSP is protected there) >what will happen when shutting down tunnel X ? (manually or because of >topology change/failures) your question is not 100% clear. Could you elaborate ? > >what about signaling to the Ingress? >what about PLR actions? - like trying to find another bypass. > > >thanks again >doug > > > --=====================_8380810==_.ALT Content-Type: text/html; charset="us-ascii" Hi,

At 12:14 08/04/2002 +0300, Doug Degan wrote:
After a protected primary LSP 'P' was established using bypass tunnel 'B' in a certain PLR -
(and signaling to the Ingress using the RRO that the LSP is protected there)
what will happen when shutting down tunnel X ? (manually or because of topology change/failures)

your question is not 100% clear. Could you elaborate ?

 
what about signaling to the Ingress?
what about PLR actions? - like trying to find another bypass.
 
 
thanks again
doug
 
 
 
--=====================_8380810==_.ALT-- From owner-mpls@UU.NET Mon Apr 8 12:36:50 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29313 for ; Mon, 8 Apr 2002 12:36:45 -0400 (EDT) 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 QQmjsk28297; Mon, 8 Apr 2002 16:34:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjsk09496 for mpls-outgoing; Mon, 8 Apr 2002 16:33: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 QQmjsk09486 for ; Mon, 8 Apr 2002 16:33:38 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmjsk22802 for ; Mon, 8 Apr 2002 16:33:22 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmjsk20799 for ; Mon, 8 Apr 2002 16:33: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 MAA12110 for ; Mon, 8 Apr 2002 12:33:21 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA07272 for mpls@uu.net; Mon, 8 Apr 2002 12:33:21 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmjrm05478 for ; Mon, 8 Apr 2002 10:39:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmjrm23249 for ; Mon, 8 Apr 2002 10:38:58 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 QQmjrm18219 for ; Mon, 8 Apr 2002 10:38:58 GMT Received: from rhthomas-u10.cisco.com (rhthomas-u10.cisco.com [161.44.134.132]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA25770; Mon, 8 Apr 2002 06:38:57 -0400 (EDT) Received: from localhost (rhthomas@localhost) by rhthomas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id GAA22813; Mon, 8 Apr 2002 06:38:57 -0400 (EDT) Message-Id: <200204081038.GAA22813@rhthomas-u10.cisco.com> X-Authentication-Warning: rhthomas-u10.cisco.com: rhthomas owned process doing -bs To: "wu min" cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: RFC 3036: Missing Section In-reply-to: Your message of "Mon, 08 Apr 2002 09:41:32 -0000." Date: Mon, 08 Apr 2002 06:38:57 -0400 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Tze Ven, > On page 49, section 3.5.1.2.2. of RFC 3036 refers reader to a missing > section -- "Unknown TLV in Known Message Type". Is this section accidentally > excluded? No. The sentence in question should have been deleted. It refers to a section that was deleted in a version of the I-D that led to the RFC. Bob From owner-mpls@UU.NET Mon Apr 8 12:42:03 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29445 for ; Mon, 8 Apr 2002 12:42:03 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmjsk26136; Mon, 8 Apr 2002 16:36:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjsk09830 for mpls-outgoing; Mon, 8 Apr 2002 16:36: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 QQmjsk09721 for ; Mon, 8 Apr 2002 16:35:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmjsk26540 for ; Mon, 8 Apr 2002 16:33:23 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmjsk20813 for ; Mon, 8 Apr 2002 16:33: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 MAA12116 for ; Mon, 8 Apr 2002 12:33:22 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA07308 for mpls@uu.net; Mon, 8 Apr 2002 12:33:22 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmjrp29775 for ; Mon, 8 Apr 2002 11:17:13 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 QQmjrp25047 for ; Mon, 8 Apr 2002 11:15:53 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 QQmjrp05183 for ; Mon, 8 Apr 2002 11:15:52 GMT Received: from JVASSEUR-W2K.cisco.com (ams-clip-vpn-dhcp4144.cisco.com [10.50.16.47]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA01057; Mon, 8 Apr 2002 13:15:48 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020408125934.04b40dc0@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Apr 2002 13:15:46 +0200 To: "Doug Degan" From: Jean Philippe Vasseur Subject: Re: Fast reroute - problematic scenario Cc: In-Reply-To: References: <4.3.2.7.2.20020408112234.05620eb8@paris.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_15058152==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_15058152==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, At 12:57 08/04/2002 +0300, Doug Degan wrote: >Ill try. >in the bypass method it is assumed that PLR choose from pre-established >bypass enabled tunnels when getting request to establish a protected LSP. >then it signals back to the Ingress of the primary LSP that it is localy >protected at this point. correct. > >now if the used bypass tunnel become not active (doesn't matter how) what >should the PLR do? > >1) to signal the Ingress that the primary protected LSP is not protected >at this point? or not? >2) to try to choose another tunnel to be used as bypass? or not? >3) to send path error to the ingress for the protected LSP? or not? >4) to ignore the failure of the bypass LSP? Now this is a local decision. The PLR should certainly not ignore the failure of the BYPASS. We mentioned in the draft that the PLR mentions in the RRO whether the TE LSP is protected or not. Now the PLR behavior will depend on the implementation. A possible behavior could be for the PLR to look for another BYPASS tunnel and update the RRO appropriately to reflect the result. JP. > >thanks. >dd. >>----- Original Message ----- >>From: Jean Philippe Vasseur >>To: Doug Degan >>Cc: mpls@UU.NET >>Sent: Monday, April 08, 2002 12:24 PM >>Subject: Re: Fast reroute - problematic scenario >> >>Hi, >> >>At 12:14 08/04/2002 +0300, Doug Degan wrote: >>>After a protected primary LSP 'P' was established using bypass tunnel >>>'B' in a certain PLR - >>>(and signaling to the Ingress using the RRO that the LSP is protected there) >>>what will happen when shutting down tunnel X ? (manually or because of >>>topology change/failures) >> >>your question is not 100% clear. Could you elaborate ? >> >>> >>>what about signaling to the Ingress? >>>what about PLR actions? - like trying to find another bypass. >>> >>> >>>thanks again >>>doug >>> >>> >>> --=====================_15058152==_.ALT Content-Type: text/html; charset="us-ascii" Hi,

At 12:57 08/04/2002 +0300, Doug Degan wrote:
Ill try.
in the bypass method it is assumed that PLR choose from pre-established bypass enabled tunnels when getting request to establish a protected LSP.
then it signals back to the Ingress of the primary LSP that it is localy protected at this point.

correct.

 
now if the used bypass tunnel become not active (doesn't matter how) what should the PLR do?
 
1) to signal the Ingress that the primary protected LSP is not protected at this point? or not?
2) to try to choose another tunnel to be used as bypass? or not?
3) to send path error to the ingress for the protected LSP? or not?
4) to ignore the failure of the bypass LSP?

Now this is a local decision. The PLR should certainly not ignore the failure of the BYPASS. We mentioned in the draft that the PLR mentions in the RRO whether the TE LSP is protected or not. Now the PLR behavior will depend on the implementation. A possible behavior could be for the PLR to look for another BYPASS tunnel and update the RRO appropriately to reflect the result.

JP.

 
thanks.
dd.
----- Original Message -----
From: Jean Philippe Vasseur
To: Doug Degan
Cc: mpls@UU.NET
Sent: Monday, April 08, 2002 12:24 PM
Subject: Re: Fast reroute - problematic scenario

Hi,

At 12:14 08/04/2002 +0300, Doug Degan wrote:
After a protected primary LSP 'P' was established using bypass tunnel 'B' in a certain PLR -
(and signaling to the Ingress using the RRO that the LSP is protected there)
what will happen when shutting down tunnel X ? (manually or because of topology change/failures)

your question is not 100% clear. Could you elaborate ?


what about signaling to the Ingress?
what about PLR actions? - like trying to find another bypass.
 
 
thanks again
doug
 
 
 
--=====================_15058152==_.ALT-- From owner-mpls@UU.NET Mon Apr 8 20:07:10 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10901 for ; Mon, 8 Apr 2002 20:07:09 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmjto26112; Tue, 9 Apr 2002 00:06:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjto01018 for mpls-outgoing; Tue, 9 Apr 2002 00:06: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 QQmjto01011 for ; Tue, 9 Apr 2002 00:06:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmjto26743 for ; Tue, 9 Apr 2002 00:06:23 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: yarilo.pluris.com [208.227.9.200]) id QQmjto06193 for ; Tue, 9 Apr 2002 00:06:22 GMT Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA11333 for ; Mon, 8 Apr 2002 17:06:19 -0700 (PDT) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Apr 2002 17:06:19 -0700 Message-ID: <17C81AD1F1FED411991E006008F6D1CA013D480E@avalon.pluris.com> From: Sundara Murugan To: mpls@UU.NET Subject: RSVP authentication - interoperability with JunOs Date: Mon, 8 Apr 2002 17:06:10 -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 RSVP authentication is specified in RFC2747. The integrity object length is 36 bytes (4 bytes obj hdr + 1byte flag + 1 unused + 6 bytes key + 8 bytes seq# + 16 bytes MD5 digest). This object from JunOs (5.2R2.3) is 32 bytes in length and is different from what is specified in 2747. Did any of you encounter an issue with this? Is there any other draft or RFC that describes RSVP authentication? sundara From owner-mpls@UU.NET Wed Apr 10 03:15:00 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12872 for ; Wed, 10 Apr 2002 03:15:00 -0400 (EDT) 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 QQmjyi28128; Wed, 10 Apr 2002 07:08:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjyi11313 for mpls-outgoing; Wed, 10 Apr 2002 07:08:36 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 QQmjyi11308 for ; Wed, 10 Apr 2002 07:08:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmjyi06142 for ; Wed, 10 Apr 2002 07:08:11 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f221.pav2.hotmail.com [64.4.37.221]) id QQmjyi26891 for ; Wed, 10 Apr 2002 07:08:11 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Apr 2002 00:08:10 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 10 Apr 2002 07:08:10 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: rhthomas@cisco.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RFC 3036: Missing TLV Date: Wed, 10 Apr 2002 07:08:10 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Apr 2002 07:08:10.0818 (UTC) FILETIME=[79357A20:01C1E05E] Sender: owner-mpls@UU.NET Precedence: bulk To Bob, I think the document does not contain subsection that describes the structure of Label Request Message ID TLV. -Tze Ven _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-mpls@UU.NET Wed Apr 10 10:14:41 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20354 for ; Wed, 10 Apr 2002 10:14:41 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmjzk20071; Wed, 10 Apr 2002 14:13:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjzk11347 for mpls-outgoing; Wed, 10 Apr 2002 14:13:31 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 QQmjzk11342 for ; Wed, 10 Apr 2002 14:13:25 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 QQmjzk28387 for ; Wed, 10 Apr 2002 14:13: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 QQmjzk12267 for ; Wed, 10 Apr 2002 14:13:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA20882 for ; Wed, 10 Apr 2002 10:13:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA27820 for mpls@uu.net; Wed, 10 Apr 2002 10:13:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmjzk11321 for ; Wed, 10 Apr 2002 14:12:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmjzk27595 for ; Wed, 10 Apr 2002 14:12:33 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 QQmjzk11644 for ; Wed, 10 Apr 2002 14:12:33 GMT Received: from rhthomas-u10.cisco.com (rhthomas-u10.cisco.com [161.44.134.132]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA20835; Wed, 10 Apr 2002 10:12:32 -0400 (EDT) Received: from localhost (rhthomas@localhost) by rhthomas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA25202; Wed, 10 Apr 2002 10:12:32 -0400 (EDT) Message-Id: <200204101412.KAA25202@rhthomas-u10.cisco.com> X-Authentication-Warning: rhthomas-u10.cisco.com: rhthomas owned process doing -bs To: "wu min" cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: RFC 3036: Missing TLV In-reply-to: Your message of "Wed, 10 Apr 2002 07:08:10 -0000." Date: Wed, 10 Apr 2002 10:12:32 -0400 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Tze Ven, > I think the document does not contain subsection that describes the > structure of Label Request Message ID TLV. This TLV is specified in Section 3.5.7 Label Mapping Message. The TLV is so simple in structure that we felt it was unnecessary to have a separate section to specify it. Bob From owner-mpls@UU.NET Wed Apr 10 12:15:26 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23931 for ; Wed, 10 Apr 2002 12:15:26 -0400 (EDT) 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 QQmjzs26918; Wed, 10 Apr 2002 16:14:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjzs02865 for mpls-outgoing; Wed, 10 Apr 2002 16:14:36 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmjzs02860 for ; Wed, 10 Apr 2002 16:14:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmjzs16483 for ; Wed, 10 Apr 2002 16:12:40 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmjzs11593 for ; Wed, 10 Apr 2002 16:12:40 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 MAA02238 for ; Wed, 10 Apr 2002 12:12:39 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA09663 for mpls@uu.net; Wed, 10 Apr 2002 12:12:39 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmjzr10820 for ; Wed, 10 Apr 2002 15:59:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmjzr26220 for ; Wed, 10 Apr 2002 15:58:50 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f122.law12.hotmail.com [64.4.19.122]) id QQmjzr13802 for ; Wed, 10 Apr 2002 15:58:49 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Apr 2002 08:58:49 -0700 Received: from 216.175.99.3 by lw12fd.law12.hotmail.msn.com with HTTP; Wed, 10 Apr 2002 15:58:48 GMT X-Originating-IP: [216.175.99.3] From: "Hariom P" To: mpls@UU.NET Subject: Hierarchical TUNNEL setup using RSVP Date: Wed, 10 Apr 2002 08:58:48 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Apr 2002 15:58:49.0220 (UTC) FILETIME=[9A601440:01C1E0A8] Sender: owner-mpls@UU.NET Precedence: bulk I have a question, would really appreciate if anyone can throw some light on this.. I would like to setup a hirarchical LSP ( which is actually tunneled through a regular RSVP-TE LSP ). I plan to setup the inner LSP with a new session between ingress & egress using the "IF_ID RSVP_HOP" rsvp object with path msg addressed directly to the egress and with router-alert option NOT set. RSVP_HOP -- ifId = ctrl channel ifIdx -- TLVs : = data channel ( tunnel LSP interface ) ifIdx; With the TLVs defined in G-MPLS-SIG i can only send the ifId, ipaddr of the data channel. This info is NOT good enough to validate the data-channel association on the egress hop. I felt the need to extend the TLV definition to include session attr of the data channel ( rsvp LSP in this case, something like T = LSP-if, Len = 'x', Val = relevant attr of tunnel-LSP session ) so that the egress hop can actually validate whether any LSP with session attr specified in the IF_ID TLVs is terminating or not and accordingly it can accept or reject the request.. Let me know if i am missing anything.. with regards, hmp _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-mpls@UU.NET Thu Apr 11 08:55:22 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26098 for ; Thu, 11 Apr 2002 08:55:22 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkcx24073; Thu, 11 Apr 2002 12:54:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkcx07066 for mpls-outgoing; Thu, 11 Apr 2002 12:54: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 QQmkcx07059 for ; Thu, 11 Apr 2002 12:54:24 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 QQmkcx05153 for ; Thu, 11 Apr 2002 12:54:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmkcx15721 for ; Thu, 11 Apr 2002 12:54:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA27599 for ; Thu, 11 Apr 2002 08:54:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA07840 for mpls@uu.net; Thu, 11 Apr 2002 08:54:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmkcx07011 for ; Thu, 11 Apr 2002 12:53: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 QQmkcx00507 for ; Thu, 11 Apr 2002 12:52:07 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmkcx01194 for ; Thu, 11 Apr 2002 12:52:06 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id <2SSVK6J8>; Thu, 11 Apr 2002 18:28:09 +0530 Message-ID: From: "Vijayanand C - CTD, Chennai." To: mpls@UU.NET Subject: CR LDP fast reroute - New draft Date: Thu, 11 Apr 2002 18:20:12 +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 Hello all, A new draft has on CR LDP fast reroute has been posted whose details are given below. I invite your comments on this draft. Regards, Vijay A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Fast Reroute Extensions to CRLDP Author(s) : C. Vijayanand Filename : draft-vijay-mpls-crldp-fastreroute-00.txt Pages : 10 Date : 10-Apr-02 This document describes the use of CR-LDP [CRLDP] to establish backup LSP tunnels for local repair of LSP tunnels established by CR-LDP. This document proposes extensions to existing CR-LDP for setting up backup tunnels for protecting LSPs on an exclusive bandwidth basis or shared bandwidth basis as desired by the initiator of the tunnel at the head end node. Several backup segments are maintained for a single LSP and they are meant to provide link and node failure protection along various segments of the LSP. Sharing of backup segments across multiple LSPs is also facilitated to achieve scalability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vijay-mpls-crldp-fastreroute-00.tx t From owner-mpls@UU.NET Thu Apr 11 23:46:12 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12795 for ; Thu, 11 Apr 2002 23:46:12 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkff26877; Fri, 12 Apr 2002 03:45:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkff29707 for mpls-outgoing; Fri, 12 Apr 2002 03:45:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmkfe29442 for ; Fri, 12 Apr 2002 03:44:46 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 QQmkfe11641 for ; Fri, 12 Apr 2002 03:43:59 GMT Received: from 21cn.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [61.140.60.248]) id QQmkfe12892 for ; Fri, 12 Apr 2002 03:43:55 GMT Received: from 21cn.com([10.2.1.2]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm263cb69898; Fri, 12 Apr 2002 11:45:12 +0800 Received: from cmr0.ash.ops.us.uu.net([198.5.241.38]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm3b3cb1bb0c; Mon, 08 Apr 2002 17:40:53 +0800 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 QQmjri27492; Mon, 8 Apr 2002 09:42:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmjri10198 for mpls-outgoing; Mon, 8 Apr 2002 09:41:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmjri10193 for ; Mon, 8 Apr 2002 09:41:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmjri09213 for ; Mon, 8 Apr 2002 09:41:34 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f26.pav2.hotmail.com [64.4.37.26]) id QQmjri25856 for ; Mon, 8 Apr 2002 09:41:33 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Apr 2002 02:41:33 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Mon, 08 Apr 2002 09:41:32 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RFC 3036: Missing Section Date: Mon, 08 Apr 2002 09:41:32 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Apr 2002 09:41:33.0309 (UTC) FILETIME=[917EAAD0:01C1DEE1] Sender: owner-mpls@UU.NET Precedence: bulk Hi, On page 49, section 3.5.1.2.2. of RFC 3036 refers reader to a missing section -- "Unknown TLV in Known Message Type". Is this section accidentally excluded? -Tze Ven _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-mpls@UU.NET Fri Apr 12 06:03:02 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00238 for ; Fri, 12 Apr 2002 06:03:02 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkge19907; Fri, 12 Apr 2002 10:02:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkge11596 for mpls-outgoing; Fri, 12 Apr 2002 10:01: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 QQmkge10487 for ; Fri, 12 Apr 2002 10:01: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 QQmkge07258 for ; Fri, 12 Apr 2002 10:01:33 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQmkge23518 for ; Fri, 12 Apr 2002 10:01:30 GMT Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19) id <2YYVYNW9>; Fri, 12 Apr 2002 15:30:48 +0530 Message-ID: <9027F68B07E7D511AE9400B0D0787DC00627E9@mailserver.netbrahma.com> From: Khuzema Pithewan To: "mpls@UU. NET (E-mail)" Subject: Admin Status Object Date: Fri, 12 Apr 2002 15:30:47 +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, In gmpls signalling(draft-ietf-mpls-generalized-signlling-07), AdminStatus Object conveys the current status of the LSP. In case of RSVP, My doubt is if in Resv Message I have multiple Filter specs then how will I associate Adminstatus object with the filter specs. Do we need to have admin status object per filter spec in Resv Message? Regards, Khuzema. From owner-mpls@UU.NET Fri Apr 12 07:04:33 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06986 for ; Fri, 12 Apr 2002 07:04:33 -0400 (EDT) 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 QQmkgi24242; Fri, 12 Apr 2002 11:03:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkgi10564 for mpls-outgoing; Fri, 12 Apr 2002 11:03: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 QQmkgi10553 for ; Fri, 12 Apr 2002 11:03:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkgi19456 for ; Fri, 12 Apr 2002 11:03:09 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQmkgi23078 for ; Fri, 12 Apr 2002 11:03:05 GMT Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19) id <2YYVYNZS>; Fri, 12 Apr 2002 16:32:23 +0530 Message-ID: <9027F68B07E7D511AE9400B0D0787DC00627EA@mailserver.netbrahma.com> From: Khuzema Pithewan To: "mpls@UU. NET (E-mail)" Subject: SE style in optical neyworks Date: Fri, 12 Apr 2002 16:32:22 +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, How does SE style of RSVP signalling fits in the optical nature of network i.e. in wavelength, TDM switching etc. In other words, How two lsp can share resource in optical networks?? Regards, Khuzema. From owner-mpls@UU.NET Fri Apr 12 08:09:00 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13365 for ; Fri, 12 Apr 2002 08:08:59 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkgm04868; Fri, 12 Apr 2002 12:08:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkgm15194 for mpls-outgoing; Fri, 12 Apr 2002 12:07:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmkgm15189 for ; Fri, 12 Apr 2002 12:07:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkgm06104 for ; Fri, 12 Apr 2002 12:06:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmkgm29230 for ; Fri, 12 Apr 2002 12:06:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA08669 for ; Fri, 12 Apr 2002 08:06:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA21107 for mpls@uu.net; Fri, 12 Apr 2002 08:06:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmkgm10275 for ; Fri, 12 Apr 2002 12:05:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkgm08417 for ; Fri, 12 Apr 2002 12:03:27 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 QQmkgm25730 for ; Fri, 12 Apr 2002 12:03:27 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12744; Fri, 12 Apr 2002 08:03:24 -0400 (EDT) Message-Id: <200204121203.IAA12744@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-08.txt Date: Fri, 12 Apr 2002 08:03:24 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : 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-08.txt Pages : 29 Date : 11-Apr-02 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-08.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-08.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-08.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: <20020411133016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-multicast-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-multicast-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020411133016.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Apr 12 09:43:57 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23392 for ; Fri, 12 Apr 2002 09:43:52 -0400 (EDT) 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 QQmkgs15641; Fri, 12 Apr 2002 13:41:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkgs15174 for mpls-outgoing; Fri, 12 Apr 2002 13:41: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 QQmkgs15075 for ; Fri, 12 Apr 2002 13:41:00 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 QQmkgs26031 for ; Fri, 12 Apr 2002 13:40: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 QQmkgs10218 for ; Fri, 12 Apr 2002 13:40:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA13141 for ; Fri, 12 Apr 2002 09:40:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA00419 for mpls@uu.net; Fri, 12 Apr 2002 09:40:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmkdq12737 for ; Thu, 11 Apr 2002 17:32: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 QQmkdq04289 for ; Thu, 11 Apr 2002 17:31:08 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f36.law12.hotmail.com [64.4.19.36]) id QQmkdq02814 for ; Thu, 11 Apr 2002 17:31:08 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Apr 2002 10:31:07 -0700 Received: from 206.54.51.125 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 11 Apr 2002 17:31:07 GMT X-Originating-IP: [206.54.51.125] From: "Hariom P" To: mpls@UU.NET Subject: RE: Hierarchical TUNNEL setup using RSVP Date: Thu, 11 Apr 2002 10:31:07 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Apr 2002 17:31:07.0653 (UTC) FILETIME=[A9F3A350:01C1E17E] Sender: owner-mpls@UU.NET Precedence: bulk All, Could anybody( atleast any of the authors of G-MPLS-SIG draft ) please comment on this to say it makes sense or otherwise. If this has already been discussed please throw me a pointer to the thread. ( i did try to trace back archives but could'nt find anything relevant ). Thanks.. with regards, hmp -----Original Message----- From: Hariom P [mailto:hmp123@hotmail.com] Sent: Wednesday, April 10, 2002 8:59 AM To: mpls@UU.NET Subject: Hierarchical TUNNEL setup using RSVP I have a question, would really appreciate if anyone can throw some light on this.. I would like to setup a hirarchical LSP ( which is actually tunneled through a regular RSVP-TE LSP ). I plan to setup the inner LSP with a new session between ingress & egress using the "IF_ID RSVP_HOP" rsvp object with path msg addressed directly to the egress and with router-alert option NOT set. RSVP_HOP -- ifId = ctrl channel ifIdx -- TLVs : = data channel ( tunnel LSP interface ) ifIdx; With the TLVs defined in G-MPLS-SIG i can only send the ifId, ipaddr of the data channel. This info is NOT good enough to validate the data-channel association on the egress hop. I felt the need to extend the TLV definition to include session attr of the data channel ( rsvp LSP in this case, something like T = LSP-if, Len = 'x', Val = relevant attr of tunnel-LSP session ) so that the egress hop can actually validate whether any LSP with session attr specified in the IF_ID TLVs is terminating or not and accordingly it can accept or reject the request.. Let me know if i am missing anything.. with regards, hmp _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Fri Apr 12 12:26:15 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14870 for ; Fri, 12 Apr 2002 12:26:15 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkhd29442; Fri, 12 Apr 2002 16:25:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkhd00750 for mpls-outgoing; Fri, 12 Apr 2002 16:25:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmkhd00730 for ; Fri, 12 Apr 2002 16:25:18 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 QQmkhd25597 for ; Fri, 12 Apr 2002 16:24:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmkhd27282 for ; Fri, 12 Apr 2002 16:24:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA19864 for ; Fri, 12 Apr 2002 12:24:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA16754 for mpls@uu.net; Fri, 12 Apr 2002 12:24:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmkhd00556 for ; Fri, 12 Apr 2002 16:22:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkhd27152 for ; Fri, 12 Apr 2002 16:22:15 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQmkhd26431 for ; Fri, 12 Apr 2002 16:22:14 GMT Received: from mira1.cisco.com (IDENT:mirapoint@mira1.cisco.com [64.101.14.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3CGM9q6009804; Fri, 12 Apr 2002 09:22:09 -0700 (PDT) Received: from SKATUKAM-W2K2.cisco.com (skatukam-w2k2.cisco.com [64.101.9.148]) by mira1.cisco.com (Mirapoint) with ESMTP id AAV25010; Fri, 12 Apr 2002 09:22:25 -0700 (PDT) Message-Id: <4.3.2.7.2.20020412092022.00b99108@mira1.cisco.com> X-Sender: skatukam@mira1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Apr 2002 09:22:08 -0700 To: Khuzema Pithewan From: Suresh Katukam Subject: Re: SE style in optical neyworks Cc: "mpls@UU. NET (E-mail)" In-Reply-To: <9027F68B07E7D511AE9400B0D0787DC00627EA@mailserver.netbrahm a.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk This can be used to set up Protected circuits which may contain 1+1 lines and 1+1 path protected segments. So on 1+1 line protected segments, you Share the bandwidth among primary and alternate paths. Setting up protected circuits is not considered in detail so far. Hopefully, P&R design team will consider this.. Thanks, Suresh At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote: >Hi, > >How does SE style of RSVP signalling fits in the optical nature of network >i.e. in wavelength, TDM switching etc. > > In other words, How two lsp can share resource in optical networks?? > >Regards, >Khuzema. From owner-mpls@UU.NET Fri Apr 12 12:52:03 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18173 for ; Fri, 12 Apr 2002 12:52:03 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkhf07965; Fri, 12 Apr 2002 16:51:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkhf03182 for mpls-outgoing; Fri, 12 Apr 2002 16:51: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 QQmkhf03143 for ; Fri, 12 Apr 2002 16:51: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 QQmkhf25149 for ; Fri, 12 Apr 2002 16:50:05 GMT Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQmkhf29499 for ; Fri, 12 Apr 2002 16:50:03 GMT Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g3CGo2s04689 for ; Fri, 12 Apr 2002 12:50:02 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA22418; Fri, 12 Apr 2002 12:50:01 -0400 Message-ID: <3CB71040.408@lucent.com> Date: Fri, 12 Apr 2002 12:50:08 -0400 From: John Ellson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mpls@UU. NET (E-mail)" Subject: Re: SE style in optical neyworks References: <4.3.2.7.2.20020412092022.00b99108@mira1.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 I'm a lurker on this list, but I do know something about protection in circuit networks, so I feel a need to comment on this. Perhaps a terminology confusion, but if you have an end-system which can share bandwidth across two connections, why do you want 1+1 protection? 1:1 and 1:N architectures (as opposed to 1+1) can provide an "extra-traffic" feature for carrying "low-priority" traffic on the protection connection when it is not being used to protect a working channel. However, if you share bandwidth across a working and an extra-traffic connection, at the time of a fault not only will you see your bandwidth drop by half, but you will also incur a traffic hit from the switching operation on the remaining half of your bandwidth. 1+1 systems duplicate the traffic on working and protection, they don't share it. It seems to me that bandwidth sharing is an alternative survivabilty strategy to protection switching, not in addition too. John Ellson Suresh Katukam wrote: > > This can be used to set up Protected circuits which may contain > 1+1 lines and 1+1 path protected segments. So on 1+1 line > protected segments, you Share the bandwidth among primary > and alternate paths. Setting up protected circuits is not considered > in detail so far. Hopefully, P&R design team will consider this.. > > Thanks, > Suresh > > At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote: > >> Hi, >> >> How does SE style of RSVP signalling fits in the optical nature of >> network >> i.e. in wavelength, TDM switching etc. >> >> In other words, How two lsp can share resource in optical networks?? >> >> Regards, >> Khuzema. > From owner-mpls@UU.NET Fri Apr 12 13:00:33 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19423 for ; Fri, 12 Apr 2002 13:00:32 -0400 (EDT) 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 QQmkhf12756; Fri, 12 Apr 2002 16:58:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkhf03684 for mpls-outgoing; Fri, 12 Apr 2002 16:58:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkhf03678 for ; Fri, 12 Apr 2002 16:58:18 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 QQmkhf22051 for ; Fri, 12 Apr 2002 16:56:59 GMT Received: from ihemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQmkhf16038 for ; Fri, 12 Apr 2002 16:56:59 GMT Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g3CGuvs07368; Fri, 12 Apr 2002 12:56:57 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA22831; Fri, 12 Apr 2002 12:56:57 -0400 Message-ID: <3CB711D9.2040200@lucent.com> Date: Fri, 12 Apr 2002 12:56:57 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suresh Katukam CC: Khuzema Pithewan , "mpls@UU. NET (E-mail)" Subject: Re: SE style in optical neyworks References: <4.3.2.7.2.20020412092022.00b99108@mira1.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 Hi Suresh, I may be wrong, but I think the way 1+1 works is not quite what SE specifies... 1+1 is the same traffic at the head-end been carried by two separate LSPs, while SE is sort of the converse of that... Zhi Suresh Katukam wrote: > > This can be used to set up Protected circuits which may contain > 1+1 lines and 1+1 path protected segments. So on 1+1 line > protected segments, you Share the bandwidth among primary > and alternate paths. Setting up protected circuits is not considered > in detail so far. Hopefully, P&R design team will consider this.. > > Thanks, > Suresh > > At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote: > >> Hi, >> >> How does SE style of RSVP signalling fits in the optical nature of >> network >> i.e. in wavelength, TDM switching etc. >> >> In other words, How two lsp can share resource in optical networks?? >> >> Regards, >> Khuzema. > > From owner-mpls@UU.NET Fri Apr 12 13:09:01 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20427 for ; Fri, 12 Apr 2002 13:09:01 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkhg28816; Fri, 12 Apr 2002 17:08:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkhg24433 for mpls-outgoing; Fri, 12 Apr 2002 17:07: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 QQmkhg24428 for ; Fri, 12 Apr 2002 17:07:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmkhg16580 for ; Fri, 12 Apr 2002 17:07: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 QQmkhg00685 for ; Fri, 12 Apr 2002 17:07:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA22693 for ; Fri, 12 Apr 2002 13:07:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA21748 for mpls@uu.net; Fri, 12 Apr 2002 13:07:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmkhg23577 for ; Fri, 12 Apr 2002 17:05:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkhg06137 for ; Fri, 12 Apr 2002 17:05:41 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQmkhg25229 for ; Fri, 12 Apr 2002 17:05:40 GMT Received: from mira1.cisco.com (IDENT:mirapoint@mira1.cisco.com [64.101.14.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3CH5Zq6006614; Fri, 12 Apr 2002 10:05:35 -0700 (PDT) Received: from SKATUKAM-W2K2.cisco.com (skatukam-w2k2.cisco.com [64.101.9.148]) by mira1.cisco.com (Mirapoint) with ESMTP id AAV25810; Fri, 12 Apr 2002 10:05:50 -0700 (PDT) Message-Id: <4.3.2.7.2.20020412100347.00ba2478@mira1.cisco.com> X-Sender: skatukam@mira1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Apr 2002 10:05:33 -0700 To: Zhi-Wei Lin From: Suresh Katukam Subject: Re: SE style in optical neyworks Cc: Khuzema Pithewan , "mpls@UU. NET (E-mail)" In-Reply-To: <3CB711D9.2040200@lucent.com> References: <4.3.2.7.2.20020412092022.00b99108@mira1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Zhi, You are correct about 1+1 path protected... But if you have a LSP that is protected by some 1+1 links and some UPSRs, BLSRs etc.. then this LSP contains mixed protection schemes (I am not sure what you call this LSP - 1+1 protected, just Protected circuit). In this case, SE style can be used.. -- Suresh At 12:56 PM 4/12/2002 -0400, Zhi-Wei Lin wrote: >Hi Suresh, > >I may be wrong, but I think the way 1+1 works is not quite what SE >specifies... > >1+1 is the same traffic at the head-end been carried by two separate LSPs, >while SE is sort of the converse of that... > >Zhi > > >Suresh Katukam wrote: > >> >>This can be used to set up Protected circuits which may contain >>1+1 lines and 1+1 path protected segments. So on 1+1 line >>protected segments, you Share the bandwidth among primary >>and alternate paths. Setting up protected circuits is not considered >>in detail so far. Hopefully, P&R design team will consider this.. >> >>Thanks, >>Suresh >> >>At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote: >> >>>Hi, >>> >>>How does SE style of RSVP signalling fits in the optical nature of network >>>i.e. in wavelength, TDM switching etc. >>> >>> In other words, How two lsp can share resource in optical networks?? >>> >>>Regards, >>>Khuzema. >> > From owner-mpls@UU.NET Fri Apr 12 13:19:26 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21836 for ; Fri, 12 Apr 2002 13:19:25 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkhh14534; Fri, 12 Apr 2002 17:18:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkhh26481 for mpls-outgoing; Fri, 12 Apr 2002 17:18:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmkhh26476 for ; Fri, 12 Apr 2002 17:18: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 QQmkhh05514 for ; Fri, 12 Apr 2002 17:18:06 GMT Received: from server.nayna.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 67-89-191-66.customer.algx.net [67.89.191.66]) id QQmkhh10506 for ; Fri, 12 Apr 2002 17:18:04 GMT Received: from relay.nayna.com (relay.nayna.com [10.0.128.11]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA09558; Fri, 12 Apr 2002 10:18:04 -0700 Received: from nayna.com (dhcp-131-104.nayna.com [10.0.131.104]) by relay.nayna.com (8.9.3/8.9.3) with ESMTP id KAA10272; Fri, 12 Apr 2002 10:17:34 -0700 Message-ID: <3CB71668.B746459B@nayna.com> Date: Fri, 12 Apr 2002 10:16:24 -0700 From: Sudheer Dharanikota X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Zhi-Wei Lin CC: Suresh Katukam , Khuzema Pithewan , "mpls@UU. NET (E-mail)" Subject: Re: SE style in optical neyworks References: <4.3.2.7.2.20020412092022.00b99108@mira1.cisco.com> <3CB711D9.2040200@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit My opinion... SE is more for M:N. Also we have to be careful in devising these extensions. We need to consider - Reservation with/without pre-established backup paths (these are typical in transport networks - to reduce the switchover time). - Reservations with/wothout extra traffic (typical again to transport network to better use the backup resources) - sudheer Zhi-Wei Lin wrote: > Hi Suresh, > > I may be wrong, but I think the way 1+1 works is not quite what SE > specifies... > > 1+1 is the same traffic at the head-end been carried by two separate > LSPs, while SE is sort of the converse of that... > > Zhi > > Suresh Katukam wrote: > > > > > This can be used to set up Protected circuits which may contain > > 1+1 lines and 1+1 path protected segments. So on 1+1 line > > protected segments, you Share the bandwidth among primary > > and alternate paths. Setting up protected circuits is not considered > > in detail so far. Hopefully, P&R design team will consider this.. > > > > Thanks, > > Suresh > > > > At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote: > > > >> Hi, > >> > >> How does SE style of RSVP signalling fits in the optical nature of > >> network > >> i.e. in wavelength, TDM switching etc. > >> > >> In other words, How two lsp can share resource in optical networks?? > >> > >> Regards, > >> Khuzema. > > > > From owner-mpls@UU.NET Fri Apr 12 13:22:26 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22283 for ; Fri, 12 Apr 2002 13:22:26 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkhh22315; Fri, 12 Apr 2002 17:21:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkhh26644 for mpls-outgoing; Fri, 12 Apr 2002 17:21: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 QQmkhh26635 for ; Fri, 12 Apr 2002 17:21:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkhh04212 for ; Fri, 12 Apr 2002 17:21:21 GMT Received: from server.nayna.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 67-89-191-66.customer.algx.net [67.89.191.66]) id QQmkhh19093 for ; Fri, 12 Apr 2002 17:21:21 GMT Received: from relay.nayna.com (relay.nayna.com [10.0.128.11]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA09731; Fri, 12 Apr 2002 10:21:20 -0700 Received: from nayna.com (dhcp-131-104.nayna.com [10.0.131.104]) by relay.nayna.com (8.9.3/8.9.3) with ESMTP id KAA10308; Fri, 12 Apr 2002 10:20:50 -0700 Message-ID: <3CB7172C.AB654BAE@nayna.com> Date: Fri, 12 Apr 2002 10:19:41 -0700 From: Sudheer Dharanikota X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Suresh Katukam CC: Zhi-Wei Lin , Khuzema Pithewan , "mpls@UU. NET (E-mail)" Subject: Re: SE style in optical neyworks References: <4.3.2.7.2.20020412092022.00b99108@mira1.cisco.com> <4.3.2.7.2.20020412100347.00ba2478@mira1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Suresh: Suresh Katukam wrote: > Zhi, > > You are correct about 1+1 path protected... > > But if you have a LSP that is protected by some 1+1 links and some > UPSRs, BLSRs etc.. then this LSP contains mixed protection schemes > (I am not sure what you call this LSP - 1+1 protected, just Protected circuit). > In this case, SE style can be used.. > I think we should not call this 1+1. In this specific case recovery is segment by segment. - sudheer > > -- Suresh > > At 12:56 PM 4/12/2002 -0400, Zhi-Wei Lin wrote: > >Hi Suresh, > > > >I may be wrong, but I think the way 1+1 works is not quite what SE > >specifies... > > > >1+1 is the same traffic at the head-end been carried by two separate LSPs, > >while SE is sort of the converse of that... > > > >Zhi > > > > > >Suresh Katukam wrote: > > > >> > >>This can be used to set up Protected circuits which may contain > >>1+1 lines and 1+1 path protected segments. So on 1+1 line > >>protected segments, you Share the bandwidth among primary > >>and alternate paths. Setting up protected circuits is not considered > >>in detail so far. Hopefully, P&R design team will consider this.. > >> > >>Thanks, > >>Suresh > >> > >>At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote: > >> > >>>Hi, > >>> > >>>How does SE style of RSVP signalling fits in the optical nature of network > >>>i.e. in wavelength, TDM switching etc. > >>> > >>> In other words, How two lsp can share resource in optical networks?? > >>> > >>>Regards, > >>>Khuzema. > >> > > From owner-mpls@UU.NET Fri Apr 12 13:32:24 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23530 for ; Fri, 12 Apr 2002 13:32:24 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkhi04504; Fri, 12 Apr 2002 17:31:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkhi27499 for mpls-outgoing; Fri, 12 Apr 2002 17:31: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 QQmkhi27444 for ; Fri, 12 Apr 2002 17:31: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 QQmkhh07063 for ; Fri, 12 Apr 2002 17:29:00 GMT Received: from ihemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQmkhh02265 for ; Fri, 12 Apr 2002 17:29:00 GMT Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g3CHSws19604; Fri, 12 Apr 2002 13:28:58 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA24984; Fri, 12 Apr 2002 13:28:58 -0400 Message-ID: <3CB7195A.2090008@lucent.com> Date: Fri, 12 Apr 2002 13:28:58 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suresh Katukam CC: Khuzema Pithewan , "mpls@UU. NET (E-mail)" Subject: Re: SE style in optical neyworks References: <4.3.2.7.2.20020412092022.00b99108@mira1.cisco.com> <4.3.2.7.2.20020412100347.00ba2478@mira1.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 Hi Suresh, Your example is the case of nested protections. So clarifying your example, I'm interpreting it to say: A --- B --- C --- D \ \ / / \ E / \------F--/ Ring A-B-C-D-F is a UPSR ring, running over a B-C-E BLSR ring (possibly with B-C as dual-node interconnect or simply as points of interconnect). Even in such case the LSP of interest is still only carrying a single traffic, not merged traffic. Even in the case of 1:1 (John Ellson's email) where you may have extra traffic, that LSP is also carrying single traffic at any instance not merged traffic (either-or, not and) I think SE style is something that a circuit network doesn't really handle. The circuit itself may be carrying traffic that is aggregated from, e.g., an IP router (where merging may occur), but the circuit itself (which is of interest) does not really merge...so from a circuit world perspective merging is an "upper layer" or application layer capability... Zhi Suresh Katukam wrote: > > Zhi, > > You are correct about 1+1 path protected... > > But if you have a LSP that is protected by some 1+1 links and some > UPSRs, BLSRs etc.. then this LSP contains mixed protection schemes > (I am not sure what you call this LSP - 1+1 protected, just Protected > circuit). > In this case, SE style can be used.. > > -- Suresh > > At 12:56 PM 4/12/2002 -0400, Zhi-Wei Lin wrote: > >> Hi Suresh, >> >> I may be wrong, but I think the way 1+1 works is not quite what SE >> specifies... >> >> 1+1 is the same traffic at the head-end been carried by two separate >> LSPs, while SE is sort of the converse of that... >> >> Zhi >> >> >> Suresh Katukam wrote: >> >>> >>> This can be used to set up Protected circuits which may contain >>> 1+1 lines and 1+1 path protected segments. So on 1+1 line >>> protected segments, you Share the bandwidth among primary >>> and alternate paths. Setting up protected circuits is not considered >>> in detail so far. Hopefully, P&R design team will consider this.. >>> >>> Thanks, >>> Suresh >>> >>> At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote: >>> >>>> Hi, >>>> >>>> How does SE style of RSVP signalling fits in the optical nature of >>>> network >>>> i.e. in wavelength, TDM switching etc. >>>> >>>> In other words, How two lsp can share resource in optical networks?? >>>> >>>> Regards, >>>> Khuzema. >>> >>> >> > From owner-mpls@UU.NET Fri Apr 12 13:33:01 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23636 for ; Fri, 12 Apr 2002 13:33:01 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkhi04125; Fri, 12 Apr 2002 17:31:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkhi27487 for mpls-outgoing; Fri, 12 Apr 2002 17:31: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 QQmkhi27440 for ; Fri, 12 Apr 2002 17:31: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 QQmkhh07780 for ; Fri, 12 Apr 2002 17:29:18 GMT Received: from ihemail1.firewall.lucent.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQmkhh02609 for ; Fri, 12 Apr 2002 17:29:17 GMT Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g3CHTGs19718; Fri, 12 Apr 2002 13:29:16 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA24992; Fri, 12 Apr 2002 13:29:16 -0400 Message-ID: <3CB71973.10901@lucent.com> Date: Fri, 12 Apr 2002 13:29:23 -0400 From: John Ellson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suresh Katukam CC: Zhi-Wei Lin , Khuzema Pithewan , "mpls@UU. NET (E-mail)" Subject: Re: SE style in optical neyworks References: <4.3.2.7.2.20020412092022.00b99108@mira1.cisco.com> <4.3.2.7.2.20020412100347.00ba2478@mira1.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 Suresh Katukam wrote: > > Zhi, > > You are correct about 1+1 path protected... > > But if you have a LSP that is protected by some 1+1 links and some > UPSRs, BLSRs etc.. then this LSP contains mixed protection schemes > (I am not sure what you call this LSP - 1+1 protected, just Protected > circuit). > In this case, SE style can be used.. If you're talking about nodes other than the nodes that are at the the ends of the protection span, then I suggest that you just refer to it as a "reliable segment". It shouldn't matter to the end-systems how that segment reliability is achieved. Protection is only interesting to nodes that have to take part in it, otherwise its just a segment of a connection with a greater or lesser propensity to failure. John Ellson From owner-mpls@UU.NET Fri Apr 12 14:44:07 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00115 for ; Fri, 12 Apr 2002 14:44:07 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkhm14260; Fri, 12 Apr 2002 18:42:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkhm23689 for mpls-outgoing; Fri, 12 Apr 2002 18:42: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 QQmkhm23684 for ; Fri, 12 Apr 2002 18:42:02 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 QQmkhm13901 for ; Fri, 12 Apr 2002 18:41:24 GMT Received: from zcars04e.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQmkhm12857 for ; Fri, 12 Apr 2002 18:41:23 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3CIbFD10594; Fri, 12 Apr 2002 14:37:15 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJANQ9D>; Fri, 12 Apr 2002 14:37:15 -0400 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E601FB64A6@zcard0ke.ca.nortel.com> From: "Don Fedyk" To: Zhi-Wei Lin , Suresh Katukam Cc: Khuzema Pithewan , "mpls@UU. NET (E-mail)" Subject: RE: SE style in optical neyworks Date: Fri, 12 Apr 2002 14:37:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E251.10612F7C" 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_01C1E251.10612F7C Content-Type: text/plain; charset="iso-8859-1" Zhi-Wei Lin wrote: >I think SE style is something that a circuit network doesn't really >handle. I'll second that. Don ------_=_NextPart_001_01C1E251.10612F7C Content-Type: text/html; charset="iso-8859-1" RE: SE style in optical neyworks

Zhi-Wei Lin wrote:

>I think SE style is something that a circuit network doesn't really
>handle.

I'll second that.

Don

------_=_NextPart_001_01C1E251.10612F7C-- From owner-mpls@UU.NET Fri Apr 12 16:45:07 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03843 for ; Fri, 12 Apr 2002 16:45:07 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkhu09157; Fri, 12 Apr 2002 20:44:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkhu15325 for mpls-outgoing; Fri, 12 Apr 2002 20:43: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 QQmkhu15320 for ; Fri, 12 Apr 2002 20:43:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkhu28039 for ; Fri, 12 Apr 2002 20:43:11 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmkhu26596 for ; Fri, 12 Apr 2002 20:43: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 QAA09349 for ; Fri, 12 Apr 2002 16:43:10 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA14603 for mpls@uu.net; Fri, 12 Apr 2002 16:43:10 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkhk03420 for ; Fri, 12 Apr 2002 18:00: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 QQmkhj21607 for ; Fri, 12 Apr 2002 17:59:51 GMT Received: from web21009.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web21009.mail.yahoo.com [216.136.227.63]) id QQmkhj15770 for ; Fri, 12 Apr 2002 17:59:51 GMT Message-ID: <20020412175950.51384.qmail@web21009.mail.yahoo.com> Received: from [63.67.101.5] by web21009.mail.yahoo.com via HTTP; Fri, 12 Apr 2002 10:59:50 PDT Date: Fri, 12 Apr 2002 10:59:50 -0700 (PDT) From: S Leung Subject: Support of Null Service (RFC 2997) for RSVP-TE To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have a few questions regarding the Null Service described in RFC 3209. Would very much appreciate if you can share some lights with me. 1) According to RFC 2997, Section 2 (Operational Overview): Network nodes receiving these PATH messages interpret the service type to indicate that the application is requesting no specific service type or quantifiable resources. However in Section 3.1 (ADSPEC Generation) and 3.2 (RSVP SENDER_TSPEC object), there describe that network nodes may include guaranteed or controlled load services in the ADSPEC and the TSPEC. Questions: a) What does a NULL service with guaranteed or controlled load services represent? b) How should the network node behave? 2) I searched through the Cisco website and found that the Catalyst 6000 product seems to support the RSVP Null Service. Question: a) Any other Cisco product support the RSVP Null Service? If yes, which software release? b) Assuming I have such a product in my lab, can anyone suggest how to test Null Service in the lab? Any link I can read? Is a separate PDP/PEP device required? 3) I searched through the Juniper website but didn't seem to find any reference to RFC 2997 nor Null Service. Questions: 1) Anyone knows if JUNOS 5.3 supports the Null Service or not? Thanks very much for your time in advance. Regards, S. Leung --- S Leung wrote: > Hi, > > I have a question regarding RFC 3209. One > difference > between RFC 3209 and the RSVP-TE draft-07 was the > introduction of the Null Service (RFC 2997), which > replaced the CoS Service. > > Anyone knows if any vendor out there implements the > Null Service for RSVP-TE? If yes, which vendor and > which software version? > > Thanks very much for your answers in advance. > > S. Leung __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From owner-mpls@UU.NET Fri Apr 12 16:46:39 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03870 for ; Fri, 12 Apr 2002 16:46:39 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkhv11714; Fri, 12 Apr 2002 20:45:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkhv15796 for mpls-outgoing; Fri, 12 Apr 2002 20:45:14 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 QQmkhv15779 for ; Fri, 12 Apr 2002 20:45:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkhv21934 for ; Fri, 12 Apr 2002 20:45:06 GMT Received: from newdev.harvard.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212]) id QQmkhv02110 for ; Fri, 12 Apr 2002 20:45:06 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g3CKioq25985 for mpls@uu.net; Fri, 12 Apr 2002 16:44:50 -0400 (EDT) Date: Fri, 12 Apr 2002 16:44:50 -0400 (EDT) From: Scott Bradner Message-Id: <200204122044.g3CKioq25985@newdev.harvard.edu> To: mpls@UU.NET Subject: response to ITU-T SG13 Sender: owner-mpls@UU.NET Precedence: bulk This is the response to http://www.ietf.org/IESG/LIAISON/ITU-SG13-MPLS-OAM.txt that was discussed during the MPLS session in Minneapolis that I plan to send early next week unless the WG has a problem with that. (Thanks to George for the draft that this is based on) Scott --------- SOURCE: IETF Sub-IP Area - Scott Bradner, Area co-Director TITLE: Response to "Communication on the status of the request on the assignment of a reserved label value for MPLS OAM packet identification" The MPLS working group discussed SG 13's request for the assignment of a reserved label value for MPLS OAM packet identification (draft-ohta-mpls-label-value-01.txt) during the MPLS session during the recent IETF meeting in Minneapolis. There was some disagreement during the discussion about the long term implications of the IETF granting this request. During the discussion it was noted that there are a number of references to modifications to IETF protocols in Y.1711. In particular, Section 6.1 states, "Ideally this should be done automatically via LSP signaling at LSP set-up time (e.g. via a CR-LDP or RSVP control-plane mechanism), but it could also be configured manually. The mechanism for achieving this configuration is outside the scope of this Recommendation." Since manual configuration is probably not an option for anything beyond a very limited deployment the implication is that the ITU will require the IETF to change CR-LDP and RSVP before Y.1711 would be seen as a complete solution. Also in section 6.3, Forward Defect Indication, the following text may be read as indicating an assumption of future changes in IETF protocols dealing with LSP signaling. "It is important that the LSP sink point knows (for the duration that the LSP is in service) any server->client LSP label mappings that were in existence prior to the defect. Although the exact means for achieving this are outside the scope of this Recommendation, some examples of how these server-> client layer label mappings could be configured are as follows: o manually, via the NMS say; o automatically on LSP set-up via extensions to LSP signaling ..." In order to understand the possible consequences of allocating an MPLS codepoint in response to the request in draft-ohta-mpls-label-value-01.txt the MPLS working group would like to understand the full scope and extent of the modifications that SG13 may be assuming to other IETF protocols, including LDP, CR-LDP, RSVP, PIM and BGP. A further concern is the impact on the MPLS forwarding plane as currently defined. In certain points in a MPLS network, based on an incoming label, the label is removed and the packet is forwarded with no further inspection of subsequent headers (be it another MPLS label or some other header). Y.1711 seems to imply that the above behavior would not satisfy Y.1711. Specifically, there are some cases where Y.1711 would expect a network element to intercept an OAM packet. This raises issues of backward compatibility with existing MPLS systems and ASICs. The MPLS working group would like to understand if Y.1711 assumes functionally that could not be supported by simply changing software in existing MPLS implementations. From owner-mpls@UU.NET Fri Apr 12 18:06:34 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05235 for ; Fri, 12 Apr 2002 18:06:33 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkia25196; Fri, 12 Apr 2002 22:05:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkia23917 for mpls-outgoing; Fri, 12 Apr 2002 22: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 QQmkia23910 for ; Fri, 12 Apr 2002 22:05: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 QQmkia01818 for ; Fri, 12 Apr 2002 22:05: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 QQmkia27342 for ; Fri, 12 Apr 2002 22:05:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA13719 for ; Fri, 12 Apr 2002 18:05:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA23060 for mpls@uu.net; Fri, 12 Apr 2002 18:05:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkia22802 for ; Fri, 12 Apr 2002 22:03: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 QQmkia12512 for ; Fri, 12 Apr 2002 22:03:49 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQmkia29485 for ; Fri, 12 Apr 2002 22:03:49 GMT Received: from mira1.cisco.com (IDENT:mirapoint@mira1.cisco.com [64.101.14.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3CM3m87013586; Fri, 12 Apr 2002 15:03:48 -0700 (PDT) Received: from SKATUKAM-W2K2.cisco.com (skatukam-w2k2.cisco.com [64.101.9.148]) by mira1.cisco.com (Mirapoint) with ESMTP id AAV31024; Fri, 12 Apr 2002 15:04:03 -0700 (PDT) Message-Id: <4.3.2.7.2.20020412150328.00b782a0@mira1.cisco.com> X-Sender: skatukam@mira1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Apr 2002 15:03:46 -0700 To: ccamp@ops.ietf.org, mpls@UU.NET From: Suresh Katukam Subject: Fwd: Re: SE style in optical neyworks Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk > >Tom and all, > >I think everyone seemed to pick on my terminology or misinterpreted >what I said. > >Here is an example: > > 1+1 1+1 >A ----------------B --------- C ------------D > \ / > \ / > E > > >A - B & C - D 1+1 line protected >B - C, C - E, B - E are all unprotected links. > >Say, one wants to create a protected LSP from A to D. >then, you would create one primary LSP from A to D via >A - B - C - D, and then you would create another LSP >from A to D using SE style ( to indicate that this is an >alternate path for same Tunnel ) via A - B - E - C - D. >This way B - C is protected by B - E - C. > >B - C - E is not configured as a UPSR. All unprotected links. >Virtual UPSR can be created such a way that B has a bridge >and C has a selector. Ofcourse, for bidirectional LSP, you need >the same thing in the opposite direction too. > >Now, what do you call this kind of protection? Protected LSP? >But not 1+1 path protected - since it is not end-to-end path >protected. > >To clarify again, this is when you would use SE style. > >Thanks >Suresh > > >At 01:17 PM 4/12/2002 -0400, Thomas D. Nadeau wrote: > > >>>This can be used to set up Protected circuits which may contain >>>1+1 lines and 1+1 path protected segments. So on 1+1 line >>>protected segments, you Share the bandwidth among primary >>>and alternate paths. >> >> You do not share the bandwidth across 1+1 circuits. You >>double-book the bandwidth because the same packets are >>sent twice: once over each LSP. You only share bandwidth >>with 1:N. >> >> --Tom >> >> >>>Setting up protected circuits is not considered >>>in detail so far. Hopefully, P&R design team will consider this.. >>> >>>Thanks, >>>Suresh >>> >>>At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote: >>>>Hi, >>>> >>>>How does SE style of RSVP signalling fits in the optical nature of network >>>>i.e. in wavelength, TDM switching etc. >>>> >>>> In other words, How two lsp can share resource in optical networks?? >>>> >>>>Regards, >>>>Khuzema. >> >> >> >>------------------------------------------------------------------------ >>Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Fri Apr 12 18:39:13 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05816 for ; Fri, 12 Apr 2002 18:39:13 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkic08749; Fri, 12 Apr 2002 22:38:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkic06413 for mpls-outgoing; Fri, 12 Apr 2002 22:38: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 QQmkic06408 for ; Fri, 12 Apr 2002 22:37: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 QQmkic06463 for ; Fri, 12 Apr 2002 22:37:42 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 QQmkic12837 for ; Fri, 12 Apr 2002 22:37: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 SAA02680 for ; Fri, 12 Apr 2002 18:37:40 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA03718 for ; Fri, 12 Apr 2002 18:37:42 -0400 (EDT) Message-ID: <3CB761BE.B82CC0C2@marconi.com> Date: Fri, 12 Apr 2002 18:37:50 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Support of Null Service (RFC 2997) for RSVP-TE References: <20020412175950.51384.qmail@web21009.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 S Leung wrote: > > I have a few questions regarding the Null Service described in RFC > 3209. Would very much appreciate if you can share some lights with > me. I can tell you what I'm doing. If it's incorrect, hopefully one of the authors can correct me. > 1) According to RFC 2997, Section 2 (Operational Overview): > Network nodes receiving these PATH messages interpret the > service type to indicate that the application is requesting no > specific service type or quantifiable resources. Correct. Null service means best-effort (in the absence of other QoS information, like DiffServ data, of course.) > However in Section 3.1 (ADSPEC Generation) and 3.2 (RSVP > SENDER_TSPEC object), there describe that network nodes may > include guaranteed or controlled load services in the ADSPEC and > the TSPEC. First off, guaranteed service and controlled load service are never specified in the TSPEC. There are two different varieties of TSpec that are valid - the "default/general parameters" which specify values appropriate for all IntServ types, and Null service, which is only applicable for Null service reservations. The ADSPEC's design allows it to contain service fragments with multiple services specified. The egress node, upon receiving an ADSPEC is supposed to select a service from among those present. It is legal to pick any represented service. > Questions: > a) What does a NULL service with guaranteed or > controlled load services represent? > b) How should the network node behave? My assumptions are: - If the TSpec indicates Null service, then a Null service reservation is made, regardless of the Adspec. I see this as mandatory, because the Null service TSpec doesn't have enough information for making a CL or GS reservation. - If the TSpec indicates general/default parameters, then the reservation should be chosen from the services that are present in the Adspec. My rule of thumb is to prefer the more strict verison: - If there is a GS service, make a GS reservation - If there is no GS, but there is CL, make a CL reservation - If there is no GS and no CL, but there is Null service, make a Null service best-effort reservation. - There is still the issue of what to do if there is a general/default parameter TSpec and the Adspec contains no supported services (or no services at all), or if the Adspec is missing. While this is technically malformed, I don't reject it, because there are some vendors who generate Path messages like this. Instead, I put a configurable option on the switch, to allow this to be interpreted as GS, CL or best-effort. This will allow for some degree of interoperability. > 2) I searched through the Cisco website and found that > the Catalyst 6000 product seems to support the RSVP > Null Service. OK. Not everybody supports this yet. In version -07 of the RSVP-TE draft, there was a "class of service" version of the TSpec and Flowspec objects, which was preferred for signaling best-effort. This object was removed from version -08, and is not present in the RFC. Null service should be used instead. Not all products have been upgraded, however. This means that backwards compatibility with the other methods of requesting best-effort service must be implemented as well. The other two methods are: - The class-of-service TSpec/Flowspec objects. (RSVP-TE drafts -01 through -07) - A controlled-load request with the bandwidth parameters of the TSpec (r and p) set to zero (which means "don't care" in IntServ objects). In order to interoperate with those routers that don't yet support Null service, a transit router must recognize and handle all three formats. An egress router must respond with the Flowspec that matches the incoming Path message. An ingress router must be able to make a best-effort request using all three formats. (Probably via a configurable option.) > Question: > a) Any other Cisco product support the RSVP Null > Service? If yes, which software release? You should ask about this on a Cisco mailing list. This list is meant for those people working on developing MPLS protocols, not for information about specific commercial products. > b) Assuming I have such a product in my lab, can > anyone suggest how to test Null Service in the > lab? Any link I can read? Is a separate PDP/PEP > device required? Can't help you here. I don't think any current RSVP test equipment yet recognizes this object. You may have to roll your own. > 3) I searched through the Juniper website but didn't > seem to find any reference to RFC 2997 nor Null > Service. > > Questions: > 1) Anyone knows if JUNOS 5.3 supports the Null Service > or not? You should ask about this on a Juniper mailing list. -- David From owner-mpls@UU.NET Sat Apr 13 10:49:15 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25369 for ; Sat, 13 Apr 2002 10:49:15 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkkp26697; Sat, 13 Apr 2002 14:48:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkkp24668 for mpls-outgoing; Sat, 13 Apr 2002 14:48:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmkkp24651 for ; Sat, 13 Apr 2002 14:48:10 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 QQmkkp10049 for ; Sat, 13 Apr 2002 14:47:40 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe53.law7.hotmail.com [216.33.236.89]) id QQmkkp29703 for ; Sat, 13 Apr 2002 14:47:39 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 13 Apr 2002 07:47:39 -0700 X-Originating-IP: [139.92.208.151] From: "yarie23" To: Subject: interface tunnel correlation to phyisical layers Date: Sat, 13 Apr 2002 17:47:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 13 Apr 2002 14:47:39.0095 (UTC) FILETIME=[286BF670:01C1E2FA] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I am currently investigating the correlation between TE interface tunnel to its underlying interfaces. I would appreciate your input on: 1)Would it be right to say (lets take Cisco tunnel interfaces): Interface tunnel out-label is determined by the out-label assigned to the FEC of the destination IP in the tunnel? 2) the actual out-int for traffic going to the tunnel is the physical int-out assigned to the destination IP FEC of the tunnel? also, can someone demonstrate in an example? Thanks, Yaron From owner-mpls@UU.NET Sat Apr 13 11:12:27 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25628 for ; Sat, 13 Apr 2002 11:12:27 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkkq13703; Sat, 13 Apr 2002 15:11:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkkq17135 for mpls-outgoing; Sat, 13 Apr 2002 15:11:32 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmkkq17066 for ; Sat, 13 Apr 2002 15:11: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 QQmkkq00858 for ; Sat, 13 Apr 2002 15:11:01 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe70.law7.hotmail.com [216.33.236.209]) id QQmkkq00438 for ; Sat, 13 Apr 2002 15:11:00 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 13 Apr 2002 08:10:59 -0700 X-Originating-IP: [139.92.208.151] From: "Yaron E" To: Subject: Difrentiation betenn protocols Date: Sat, 13 Apr 2002 18:10:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 13 Apr 2002 15:10:59.0936 (UTC) FILETIME=[6B635600:01C1E2FD] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I am a bit confused of the major responsibilities of MPLS protocols. Would it be right to say that: 1. Before LSP is created, we need a IGP routing table based on OSPF/IS-IS/CSPF (CSPF would be OSPF with some extensions) 2. simple LSPs are created based on LDP (DOD or DOU) via LDP protocol, no signaling is necessary? (RSVP/CR-LDP) 3. if we want to create a tunnel with administrator constraints, like explicit path, we would need path signaling like RSVP/CR-LDP? Am I totally out of the loop here or not? :-) Thanks, Yaron From owner-mpls@UU.NET Sat Apr 13 12:07:21 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26737 for ; Sat, 13 Apr 2002 12:07:21 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkku09226; Sat, 13 Apr 2002 16:06:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkku10878 for mpls-outgoing; Sat, 13 Apr 2002 16:06:31 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 QQmkku10854 for ; Sat, 13 Apr 2002 16:06:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkku14028 for ; Sat, 13 Apr 2002 16:05:42 GMT Received: from eel.ece.ucdavis.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: eel.ece.ucdavis.edu [169.237.32.164]) id QQmkku07842 for ; Sat, 13 Apr 2002 16:05:41 GMT Received: from localhost (wswen@localhost) by eel.ece.ucdavis.edu (8.9.3/8.9.3) with ESMTP id JAA20011; Sat, 13 Apr 2002 09:05:32 -0700 (PDT) Date: Sat, 13 Apr 2002 09:05:32 -0700 (PDT) From: Wushao Wen To: Yaron E cc: mpls@UU.NET Subject: Re: Difrentiation betenn protocols In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Please read comments inline. > Hi all, > I am a bit confused of the major responsibilities of MPLS protocols. > Would it be right to say that: > 1. Before LSP is created, we need a IGP routing table based on > OSPF/IS-IS/CSPF (CSPF would be OSPF with some extensions) Yes. MPLS is mainly a signaling protocols. Of course, it change the next hop selection mechanism from the traditional IP network. > 2. simple LSPs are created based on LDP (DOD or DOU) via LDP protocol, no > signaling is necessary? (RSVP/CR-LDP) LDP is a signaling protocols, so are RSVP and CR-LDP. LDP creates LDP via IP next hop routing table. CR-LDP uses source routing. RSVP is similar as LDP. > 3. if we want to create a tunnel with administrator constraints, like > explicit path, we would need path signaling like RSVP/CR-LDP? Yes. Traditional IP routing cannot create an explicit route because the routing is only based on the destination address. Wushao > > Am I totally out of the loop here or not? :-) > > Thanks, > > Yaron > From owner-mpls@UU.NET Sat Apr 13 21:19:43 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01614 for ; Sat, 13 Apr 2002 21:19:43 -0400 (EDT) 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 QQmkmf08905; Sun, 14 Apr 2002 01:18:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkmf02355 for mpls-outgoing; Sun, 14 Apr 2002 01:18:32 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmkmf02350 for ; Sun, 14 Apr 2002 01:18:28 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 QQmkmf29648 for ; Sun, 14 Apr 2002 01:17:31 GMT Received: from merlot.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQmkmf06966 for ; Sun, 14 Apr 2002 01:17:31 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g3E1HPT44370; Sat, 13 Apr 2002 18:17:25 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.11.6) with ESMTP id g3E1HPQ71988; Sat, 13 Apr 2002 18:17:25 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Sat, 13 Apr 2002 18:17:25 -0700 (PDT) From: Kireeti Kompella To: Scott Bradner cc: Subject: Re: response to ITU-T SG13 In-Reply-To: <200204122044.g3CKioq25985@newdev.harvard.edu> Message-ID: <20020413180913.B71980-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 12 Apr 2002, Scott Bradner wrote: The text in general looks very good. A couple of minor nits: > In order to understand the possible consequences of allocating an MPLS > codepoint in response to the request in draft-ohta-mpls-label-value-01.txt > the MPLS working group would like to understand the full scope and extent > of the modifications that SG13 may be assuming to other IETF protocols, > including LDP, CR-LDP, RSVP, PIM and BGP. Where did PIM come in? > A further concern is the impact on the MPLS forwarding plane as currently > defined. In certain points in a MPLS network, based on an incoming label, > the label is removed and the packet is forwarded with no further inspection > of subsequent headers (be it another MPLS label or some other header). > Y.1711 seems to imply that the above behavior would not satisfy Y.1711. > Specifically, there are some cases where Y.1711 would expect a network > element to intercept an OAM packet. This raises issues of backward > compatibility with existing MPLS systems and ASICs. A deeper question is the implication of different forwarding decisions for OAM and non-OAM packets. In particular, if OAM packets are treated differently, how valuable is feedback from those forwarding decisions on the forwarding of regular packets? And isn't the whole point just that -- to know what "regular forwarding" is doing? > The MPLS working group would like to understand if Y.1711 assumes > functionally that could not be supported by simply changing software in ^^^^^^^^^^^^ functionality? > existing MPLS implementations. Kireeti. From owner-mpls@UU.NET Sun Apr 14 01:26:02 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05923 for ; Sun, 14 Apr 2002 01:26:02 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkmv07470; Sun, 14 Apr 2002 05:25:21 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkmv14777 for mpls-outgoing; Sun, 14 Apr 2002 05:25:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmkmv14768 for ; Sun, 14 Apr 2002 05:25:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkmv14045 for ; Sun, 14 Apr 2002 05:24:50 GMT Received: from hongkong.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.84.12.153]) id QQmkmv15793 for ; Sun, 14 Apr 2002 05:24:49 GMT Received: from hongkong.com([10.1.7.100]) by hongkong.com(JetMail 2.5.3.0) with SMTP id jm423cb93afd; Sun, 14 Apr 2002 05:09:26 -0000 Received: from host.secure4-hosting.net([209.239.41.31]) by hongkong.com(JetMail 2.5.3.0) with SMTP id jmb53cb464f8; Wed, 10 Apr 2002 08:06:05 -0000 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id g3A7buF28743 for newsupdate@hongkong.com; Wed, 10 Apr 2002 03:37:56 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f X-Originating-IP: [155.245.254.253] From: "wu min" To: rhthomas@cisco.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Date: Wed, 10 Apr 2002 07:08:10 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Apr 2002 07:08:10.0818 (UTC) FILETIME=[79357A20:01C1E05E] Subject: [MPLS-OPS]: RFC 3036: Missing TLV X-Mailing-List: archive/latest/3731 X-Loop: mpls-ops@mplsrc.com X-Auto-Forward: newsupdate@hongkong.com dannylau@hkicable.com Sender: owner-mpls@UU.NET Precedence: bulk To Bob, I think the document does not contain subsection that describes the structure of Label Request Message ID TLV. -Tze Ven _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ------- 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 Mon Apr 15 00:58:36 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28642 for ; Mon, 15 Apr 2002 00:58:36 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkql22287; Mon, 15 Apr 2002 04:57:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkql02198 for mpls-outgoing; Mon, 15 Apr 2002 04:57: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 QQmkql02192 for ; Mon, 15 Apr 2002 04:57:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmkql01759 for ; Mon, 15 Apr 2002 04:55:56 GMT Received: from web13705.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13705.mail.yahoo.com [216.136.175.138]) id QQmkql27258 for ; Mon, 15 Apr 2002 04:55:56 GMT Message-ID: <20020415045551.94063.qmail@web13705.mail.yahoo.com> Received: from [164.164.56.2] by web13705.mail.yahoo.com via HTTP; Sun, 14 Apr 2002 21:55:51 PDT Date: Sun, 14 Apr 2002 21:55:51 -0700 (PDT) From: gmpls gmpls Subject: Re: SE style in optical neyworks To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, I need some more clarification on this regard. The OIF UNI v1.0 standard says UNI only supports the FF style of reservation. Since Optical network which main purpose is to provide service for UNI clients, would have to support same set reservation styles which UNI needs. So Is there a need for supporting SE style of reservation in the optical domain? Regards __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From owner-mpls@UU.NET Mon Apr 15 04:34:06 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10092 for ; Mon, 15 Apr 2002 04:34:06 -0400 (EDT) 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 QQmkra19909; Mon, 15 Apr 2002 08:33:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkra11827 for mpls-outgoing; Mon, 15 Apr 2002 08:32:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmkra11822 for ; Mon, 15 Apr 2002 08:32:57 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 QQmkra19961 for ; Mon, 15 Apr 2002 08:31:55 GMT From: neil.2.harrison@bt.com Received: from cbibipnt03.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmkra17858 for ; Mon, 15 Apr 2002 08:31:54 GMT Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id <2XKF8CLC>; Mon, 15 Apr 2002 09:31:30 +0100 Message-ID: To: kireeti@juniper.net, sob@harvard.edu Cc: mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 09:31:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Kireeti, Thanks for raising this. I too had some concerns about one of the comments you have picked-up on.....please see in-line below. > > > A further concern is the impact on the MPLS forwarding > plane as currently > > defined. In certain points in a MPLS network, based on an > incoming label, > > the label is removed and the packet is forwarded with no > further inspection > > of subsequent headers (be it another MPLS label or some > other header). > > Y.1711 seems to imply that the above behavior would not > satisfy Y.1711. > > Specifically, there are some cases where Y.1711 would > expect a network > > element to intercept an OAM packet. This raises issues of backward > > compatibility with existing MPLS systems and ASICs. > > A deeper question is the implication of different forwarding decisions > for OAM and non-OAM packets. In particular, if OAM packets are > treated differently, how valuable is feedback from those forwarding > decisions on the forwarding of regular packets? And isn't the whole > point just that -- to know what "regular forwarding" is doing? NH=> Quick back-track to explain rationale of what is in Y.1711: - main focus is distributed, automatic and as-simple-as-possible defect detection/handling - ad hoc diagnostics tools come later......and IMO these are functionally distinct from the above and also require a conscious decision to invoke, eg a trail-tracing function would fit this class. To that end only 1 OAM pkt is required whilst in the up-state....the CV pkt (this is functionally just a 'hello'). And there are 2 pkts that 'come-on' when a defect is detected.....FDI/BDI which are intended to flow forwards/backwards to given indications to client layer(s) and LSP head-ends respectively. This is all pretty standard/well-known stuff that operators need for fault handling. A key behavioural tenet of the defect detection/handling OAM CV pkt, is that it must be treated as normal traffic and is therefore only ever relevant to the LSP source/sink points.....it is completely transparent to intermediate LSRs. This is nothing unusual, but normal/required behaviour in layered networks. And each LSP is independent in this respect, ie 1 or more LSPs can form a client=>server relationship with a lower level LSP, thus each LSP has its own independent CV flow. This is achieved by adding a (lower) extra labelled header to the normal traffic on an LSP when a CV pkt is sent. The key differences (from normal traffic) are: - S bit is now only set on OAM alert labelled header - OAM alert labelled header carries globally unique label (14 is suggested) to identify the payload as an OAM pkt.....this is what was discussed on the list over 12 months ago now, and seemed the only non-contentious solution to the problem of not having a PID field in the MPLS header. So, in summary: - the CV pkt is only visible to LSP source/sink points - it is treated as 'normal traffic' by intermediate LSRs - each LSP is independent of other LSPs - since there is no PID in the MPLS header the only way to identify OAM pkts is via a globally unique/reserved label. Hope that clarifies. regards, Neil From owner-mpls@UU.NET Mon Apr 15 07:11:17 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12819 for ; Mon, 15 Apr 2002 07:11:17 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkrk18979; Mon, 15 Apr 2002 11:10:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkrk25686 for mpls-outgoing; Mon, 15 Apr 2002 11:09: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 QQmkrk25667 for ; Mon, 15 Apr 2002 11:09:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmkrk17512 for ; Mon, 15 Apr 2002 11:08:45 GMT Received: from rincewind.office.packetexchange.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmkrk16928 for ; Mon, 15 Apr 2002 11:08:43 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 16x4LV-0003g9-00; Mon, 15 Apr 2002 12:08:29 +0100 Subject: RE: response to ITU-T SG13 From: Giles Heron To: neil.2.harrison@bt.com Cc: kireeti@juniper.net, sob@harvard.edu, mpls@UU.NET In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 15 Apr 2002 12:08:55 +0000 Message-Id: <1018872535.1131.45.camel@gizzer> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-04-15 at 08:31, neil.2.harrison@bt.com wrote: [snip] > A key behavioural tenet of the defect detection/handling OAM CV pkt, is that > it must be treated as normal traffic and is therefore only ever relevant to > the LSP source/sink points.....it is completely transparent to intermediate > LSRs. This is nothing unusual, but normal/required behaviour in layered > networks. And each LSP is independent in this respect, ie 1 or more LSPs > can form a client=>server relationship with a lower level LSP, thus each LSP > has its own independent CV flow. > > This is achieved by adding a (lower) extra labelled header to the normal > traffic on an LSP when a CV pkt is sent. The key differences (from normal > traffic) are: > - S bit is now only set on OAM alert labelled header > - OAM alert labelled header carries globally unique label (14 is > suggested) to identify the payload as an OAM pkt.....this is what was > discussed on the list over 12 months ago now, and seemed the only > non-contentious solution to the problem of not having a PID field in the > MPLS header. which means that intermediate LSRs that use a hash to load balance MPLS traffic over equal cost links/paths have to be careful to exclude the S bit from any hash. I'm not sure that this is the case for all current implementations... In fact this also would seem to imply that you have to hash over a fixed number of labels (to ensure that both the OAM traffic and the user traffic get the same hash value). This coarsens the load balancing granularity somewhat :( The alternatives would be either to preclude hashed load-balancing or to require OAM-aware core LSRs. Neither of these options is acceptable IMO. Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Mon Apr 15 08:36:16 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15014 for ; Mon, 15 Apr 2002 08:36:16 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkrq10876; Mon, 15 Apr 2002 12:31:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkrq23695 for mpls-outgoing; Mon, 15 Apr 2002 12:30: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 QQmkrq23690 for ; Mon, 15 Apr 2002 12:30: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 QQmkrq06200 for ; Mon, 15 Apr 2002 12:30:35 GMT From: neil.2.harrison@bt.com Received: from cbibipnt03.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmkrq03704 for ; Mon, 15 Apr 2002 12:30:34 GMT Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id <2XKF86LV>; Mon, 15 Apr 2002 13:30:48 +0100 Message-ID: To: giles@packetexchange.net Cc: mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 13:30:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Giles Heron wrote 15 April 2002 13:09 > On Mon, 2002-04-15 at 08:31, neil.2.harrison@bt.com wrote: > [snip] > > A key behavioural tenet of the defect detection/handling > OAM CV pkt, is that > > it must be treated as normal traffic and is therefore only > ever relevant to > > the LSP source/sink points.....it is completely transparent > to intermediate > > LSRs. This is nothing unusual, but normal/required > behaviour in layered > > networks. And each LSP is independent in this respect, ie > 1 or more LSPs > > can form a client=>server relationship with a lower level > LSP, thus each LSP > > has its own independent CV flow. > > > > This is achieved by adding a (lower) extra labelled header > to the normal > > traffic on an LSP when a CV pkt is sent. The key > differences (from normal > > traffic) are: > > - S bit is now only set on OAM alert labelled header > > - OAM alert labelled header carries globally unique label (14 is > > suggested) to identify the payload as an OAM pkt.....this > is what was > > discussed on the list over 12 months ago now, and seemed the only > > non-contentious solution to the problem of not having a PID > field in the > > MPLS header. > > which means that intermediate LSRs that use a hash to load > balance MPLS > traffic over equal cost links/paths have to be careful to > exclude the S > bit from any hash. > > I'm not sure that this is the case for all current implementations... > > In fact this also would seem to imply that you have to hash > over a fixed > number of labels (to ensure that both the OAM traffic and the user > traffic get the same hash value). This coarsens the load balancing > granularity somewhat :( > > The alternatives would be either to preclude hashed > load-balancing or to > require OAM-aware core LSRs. Neither of these options is acceptable > IMO. > NH=>I understand your point Giles, but if you do as you suggest you don't have a single trail between source and sink any longer but multiple parallel trails.....each of which I would argue should be managed as a trail in its own right. regards, Neil From owner-mpls@UU.NET Mon Apr 15 08:59:19 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15892 for ; Mon, 15 Apr 2002 08:59:19 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkrr17767; Mon, 15 Apr 2002 12:58:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkrr26134 for mpls-outgoing; Mon, 15 Apr 2002 12:58: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 QQmkrr26129 for ; Mon, 15 Apr 2002 12:58:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkrr29220 for ; Mon, 15 Apr 2002 12:56:18 GMT Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmkrr11462 for ; Mon, 15 Apr 2002 12:56:16 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 16x61i-0003wE-00; Mon, 15 Apr 2002 13:56:10 +0100 Subject: RE: response to ITU-T SG13 From: Giles Heron To: neil.2.harrison@bt.com Cc: mpls@UU.NET In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 15 Apr 2002 13:56:36 +0000 Message-Id: <1018878996.1130.88.camel@gizzer> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-04-15 at 12:30, neil.2.harrison@bt.com wrote: > Giles Heron wrote 15 April 2002 13:09 > > > On Mon, 2002-04-15 at 08:31, neil.2.harrison@bt.com wrote: > > [snip] > > > A key behavioural tenet of the defect detection/handling > > OAM CV pkt, is that > > > it must be treated as normal traffic and is therefore only > > ever relevant to > > > the LSP source/sink points.....it is completely transparent > > to intermediate > > > LSRs. This is nothing unusual, but normal/required > > behaviour in layered > > > networks. And each LSP is independent in this respect, ie > > 1 or more LSPs > > > can form a client=>server relationship with a lower level > > LSP, thus each LSP > > > has its own independent CV flow. > > > > > > This is achieved by adding a (lower) extra labelled header > > to the normal > > > traffic on an LSP when a CV pkt is sent. The key > > differences (from normal > > > traffic) are: > > > - S bit is now only set on OAM alert labelled header > > > - OAM alert labelled header carries globally unique label (14 is > > > suggested) to identify the payload as an OAM pkt.....this > > is what was > > > discussed on the list over 12 months ago now, and seemed the only > > > non-contentious solution to the problem of not having a PID > > field in the > > > MPLS header. > > > > which means that intermediate LSRs that use a hash to load > > balance MPLS > > traffic over equal cost links/paths have to be careful to > > exclude the S > > bit from any hash. > > > > I'm not sure that this is the case for all current implementations... > > > > In fact this also would seem to imply that you have to hash > > over a fixed > > number of labels (to ensure that both the OAM traffic and the user > > traffic get the same hash value). This coarsens the load balancing > > granularity somewhat :( > > > > The alternatives would be either to preclude hashed > > load-balancing or to > > require OAM-aware core LSRs. Neither of these options is acceptable > > IMO. > > > NH=>I understand your point Giles, but if you do as you suggest you don't > have a single trail between source and sink any longer but multiple parallel > trails.....each of which I would argue should be managed as a trail in its > own right. so you're effectively saying that in order to apply OAM at a higher layer trail you need strictly CO trails at all lower layers? Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Mon Apr 15 09:37:16 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16978 for ; Mon, 15 Apr 2002 09:37:11 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkru07908; Mon, 15 Apr 2002 13:35:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkru19767 for mpls-outgoing; Mon, 15 Apr 2002 13:35: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 QQmkru19762 for ; Mon, 15 Apr 2002 13:35:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkru02666 for ; Mon, 15 Apr 2002 13:35:04 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmkru06957 for ; Mon, 15 Apr 2002 13:35:04 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FDYka15511; Mon, 15 Apr 2002 09:34:47 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJA3FDP>; Mon, 15 Apr 2002 09:34:47 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402C0AFAE@zcard0ka.ca.nortel.com> From: "David Allan" To: Scott Bradner , mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 09:34:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E482.538A8374" 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_01C1E482.538A8374 Content-Type: text/plain; charset="iso-8859-1" Hi Scott: I think readability would be enhanced if the third paragraph was deleted..."Since manual configuration .... before Y.1711 would be seen as a complete solution."....The third para discusses if changes to CR-LDP and RSVP are expected and a few paragraphs later the question is enlarged to include LDP, PIM and BGP. I'll plead ignorance, but I'm not sure why PIM is on the list...? cheers Dave > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Friday, April 12, 2002 4:45 PM > To: mpls@UU.NET > Subject: response to ITU-T SG13 > > > > This is the response to > http://www.ietf.org/IESG/LIAISON/ITU-SG13-MPLS-OAM.txt > that was discussed during the MPLS session in Minneapolis > that I plan to > send early next week unless the WG has a problem with that. > (Thanks to George for the draft that this is based on) > > Scott > > --------- > > SOURCE: IETF Sub-IP Area - Scott Bradner, Area co-Director > TITLE: Response to "Communication on the status of the request on the > assignment of a reserved label value for MPLS OAM packet > identification" > > The MPLS working group discussed SG 13's request for the > assignment of a > reserved label value for MPLS OAM packet identification > (draft-ohta-mpls-label-value-01.txt) during the MPLS session > during the > recent IETF meeting in Minneapolis. There was some > disagreement during the > discussion about the long term implications of the IETF granting this > request. > > During the discussion it was noted that there are a number of > references to > modifications to IETF protocols in Y.1711. In particular, Section 6.1 > states, "Ideally this should be done automatically via LSP > signaling at > LSP set-up time (e.g. via a CR-LDP or RSVP control-plane > mechanism), but > it could also be configured manually. The mechanism for > achieving this > configuration is outside the scope of this Recommendation." > > Since manual configuration is probably not an option for > anything beyond a > very limited deployment the implication is that the ITU will > require the > IETF to change CR-LDP and RSVP before Y.1711 would be seen as > a complete > solution. > > Also in section 6.3, Forward Defect Indication, the following > text may be > read as indicating an assumption of future changes in IETF protocols > dealing with LSP signaling. > > "It is important that the LSP sink point knows (for the > duration that the > LSP is in service) any server->client LSP label mappings that were in > existence prior to the defect. Although the exact means for > achieving this > are outside the scope of this Recommendation, some examples > of how these > server-> client layer label mappings could be configured are > as follows: > o manually, via the NMS say; > o automatically on LSP set-up via extensions to LSP signaling ..." > > In order to understand the possible consequences of allocating an MPLS > codepoint in response to the request in > draft-ohta-mpls-label-value-01.txt > the MPLS working group would like to understand the full > scope and extent > of the modifications that SG13 may be assuming to other IETF > protocols, > including LDP, CR-LDP, RSVP, PIM and BGP. > > A further concern is the impact on the MPLS forwarding plane > as currently > defined. In certain points in a MPLS network, based on an > incoming label, > the label is removed and the packet is forwarded with no > further inspection > of subsequent headers (be it another MPLS label or some other header). > Y.1711 seems to imply that the above behavior would not > satisfy Y.1711. > Specifically, there are some cases where Y.1711 would expect a network > element to intercept an OAM packet. This raises issues of backward > compatibility with existing MPLS systems and ASICs. > > The MPLS working group would like to understand if Y.1711 assumes > functionally that could not be supported by simply changing > software in > existing MPLS implementations. > > > ------_=_NextPart_001_01C1E482.538A8374 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: response to ITU-T SG13

Hi Scott:

I think readability would be enhanced if the third = paragraph was deleted..."Since manual configuration .... before = Y.1711 would be seen as a complete solution."....The third para = discusses if changes to CR-LDP and RSVP are expected and a few = paragraphs later the question is enlarged to include LDP, PIM and = BGP.

I'll plead ignorance, but I'm not sure why PIM is on = the list...?

cheers
Dave


> -----Original Message-----
> From: Scott Bradner [mailto:sob@harvard.edu]
> Sent: Friday, April 12, 2002 4:45 PM
> To: mpls@UU.NET
> Subject: response to ITU-T SG13
>
>
>
> This is the response to
> http://www.ietf.org/IESG/LIAISON/ITU-SG13-MPLS-OAM.txt=
> that was discussed during the MPLS session in = Minneapolis
> that I plan to
> send early next week unless the WG has a = problem with that.
> (Thanks to George for the draft that this is = based on)
>
> Scott
>
> ---------
>
> SOURCE: IETF Sub-IP Area - Scott Bradner, Area = co-Director
> TITLE: Response to "Communication on the = status of the request on the
>   assignment of a reserved label = value for MPLS OAM packet
> identification"
>
> The MPLS working group discussed SG 13's = request for the
> assignment of a
> reserved label value for MPLS OAM packet = identification
> (draft-ohta-mpls-label-value-01.txt) during the = MPLS session
> during the
> recent IETF meeting in Minneapolis.  There = was some
> disagreement during the
> discussion about the long term = implications  of the IETF granting this
> request.
>
> During the discussion it was noted that there = are a number of
> references to
> modifications to IETF protocols in = Y.1711.  In particular, Section 6.1
> states, "Ideally this should be done = automatically  via LSP
> signaling at
> LSP set-up time (e.g. via a CR-LDP or = RSVP  control-plane
> mechanism), but
> it could also be configured = manually.   The mechanism for
> achieving this
> configuration is outside the scope of this = Recommendation."
>
> Since manual configuration is probably not an = option for
> anything beyond a
> very limited deployment the implication is that = the ITU will
> require the
> IETF to change CR-LDP and RSVP before Y.1711 = would be seen as
> a complete
> solution.
>
> Also in section 6.3, Forward Defect Indication, = the following
> text may be
> read as indicating an assumption of future = changes in  IETF protocols
> dealing with LSP signaling.
>
> "It is important that the LSP sink point = knows (for the
> duration that the
> LSP is in service) any server->client LSP = label mappings that were in
> existence prior to the defect.  Although = the exact means for
> achieving this
> are outside the scope of this Recommendation, = some examples
> of how these
> server-> client layer label mappings could = be configured are
> as follows:
>    o manually, via the NMS = say; 
>    o automatically on LSP set-up = via extensions to LSP signaling ..."
>
> In order to understand the possible = consequences of allocating an MPLS
> codepoint in response to the request in  =
> draft-ohta-mpls-label-value-01.txt
> the MPLS working group would like to understand = the full
> scope and extent
> of the modifications that SG13 may be assuming = to other IETF
> protocols,
> including LDP, CR-LDP, RSVP, PIM and = BGP.
>
> A further concern is the impact on the MPLS = forwarding plane
> as currently
> defined.  In certain points in a MPLS = network, based on an
> incoming label,
> the label is removed and the packet is = forwarded with no
> further inspection
> of subsequent headers (be it another MPLS label = or some other header).
> Y.1711 seems to imply that the above behavior = would not
> satisfy Y.1711.
> Specifically, there are some cases where Y.1711 = would expect a network
> element to intercept an OAM packet. This raises = issues of backward
> compatibility with existing MPLS systems and = ASICs. 
>
> The MPLS working group would like to understand = if Y.1711 assumes
> functionally that could not be supported by = simply changing
> software in
> existing MPLS implementations.
>
> 
>

------_=_NextPart_001_01C1E482.538A8374-- From owner-mpls@UU.NET Mon Apr 15 09:42:39 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17080 for ; Mon, 15 Apr 2002 09:42:39 -0400 (EDT) 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 QQmkru18782; Mon, 15 Apr 2002 13:41:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkru20356 for mpls-outgoing; Mon, 15 Apr 2002 13:41: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 QQmkru20346 for ; Mon, 15 Apr 2002 13:41: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 QQmkru02612 for ; Mon, 15 Apr 2002 13:40:42 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmkru14899 for ; Mon, 15 Apr 2002 13:40:41 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FDeDa16046; Mon, 15 Apr 2002 09:40:13 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJA3FMX>; Mon, 15 Apr 2002 09:40:14 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402C0AFCD@zcard0ka.ca.nortel.com> From: "David Allan" To: Giles Heron , neil.2.harrison@bt.com Cc: kireeti@juniper.net, sob@harvard.edu, mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 09:40:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E483.15A3545E" 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_01C1E483.15A3545E Content-Type: text/plain; charset="iso-8859-1" Giles: A clarification... > which means that intermediate LSRs that use a hash to load > balance MPLS > traffic over equal cost links/paths have to be careful to > exclude the S > bit from any hash. If I am inverse muxing an LSP at an intermadiate LSR, is this not on the basis of some hashing on the payload for the current label, which could be more labels...I'm not quite getting your example. Dave ------_=_NextPart_001_01C1E483.15A3545E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: response to ITU-T SG13

Giles:

A clarification...

> which means that intermediate LSRs that use a = hash to load
> balance MPLS
> traffic over equal cost links/paths have to be = careful to
> exclude the S
> bit from any hash.

If I am inverse muxing an LSP at an intermadiate LSR, = is this not on the basis of some hashing on the payload for the current = label, which could be more labels...I'm not quite getting your = example.

Dave

 

------_=_NextPart_001_01C1E483.15A3545E-- From owner-mpls@UU.NET Mon Apr 15 09:42:56 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17105 for ; Mon, 15 Apr 2002 09:42:56 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkru16907; Mon, 15 Apr 2002 13:42:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkru20357 for mpls-outgoing; Mon, 15 Apr 2002 13:41: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 QQmkru20347 for ; Mon, 15 Apr 2002 13:41:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkru03714 for ; Mon, 15 Apr 2002 13:41:11 GMT Received: from hoemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQmkru17617 for ; Mon, 15 Apr 2002 13:41:11 GMT Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g3FDfAL22282; Mon, 15 Apr 2002 09:41:10 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA28511; Mon, 15 Apr 2002 09:41:09 -0400 Message-ID: <3CBAD87E.4030403@lucent.com> Date: Mon, 15 Apr 2002 09:41:18 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Suresh Katukam CC: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: Fwd: Re: SE style in optical neyworks References: <4.3.2.7.2.20020412150328.00b782a0@mira1.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 Hi Suresh, Sorry. Wasn't picking on terminology, anyway, some more comments below... Suresh Katukam wrote: > >> >> Tom and all, >> >> I think everyone seemed to pick on my terminology or misinterpreted >> what I said. >> >> Here is an example: >> >> 1+1 1+1 >> A ----------------B --------- C ------------D >> \ / >> \ / >> E >> >> >> A - B & C - D 1+1 line protected >> B - C, C - E, B - E are all unprotected links. > So this network you drew assumes a single point of interconnect at B and C...that's fine >> >> Say, one wants to create a protected LSP from A to D. >> then, you would create one primary LSP from A to D via >> A - B - C - D, and then you would create another LSP >> from A to D using SE style ( to indicate that this is an >> alternate path for same Tunnel ) via A - B - E - C - D. >> This way B - C is protected by B - E - C. > By creating a new LSP A-B-E-C-D, this circuit is completely separate from the original A-B-C-D circuit. There is no sharing at all. It is just incidental that they carry the same traffic (i.e., you just happen to have set up the A-B-E-C-D to carry the same traffic as in A-B-C-D). Again this is not merging (as represented by SE), unless you are re-defining what SE means... >> >> >> B - C - E is not configured as a UPSR. All unprotected links. >> Virtual UPSR can be created such a way that B has a bridge >> and C has a selector. Ofcourse, for bidirectional LSP, you need >> the same thing in the opposite direction too. > Yes, just as the two LSPs making up the 1+1 from A-B are both unprotected LSPs, but taken together provide the 1+1 service. As such, if B-E-C is carrying the same traffic as B-C *all the time*, then it's still 1+1, but more specifically, it is a 1+1 SNC (sub-network connection). 1+1 doesn't necessary only apply to 1+1 path (when you say path, I think you mean trail? -- G.805 terminology). However, if B-E-C is not carrying the same traffic, but may be used to support *extra traffic*, then this is a 1:1 type protection. And if B-E-C LSP is actually supporting multiple LSPs going over B-C, then it's 1:N protection. However, note that even in this case it is still NOT SE, since the B-E-C LSP at any given time is only ever carrying one single traffic. Hope this clarifies. Zhi >> >> Now, what do you call this kind of protection? Protected LSP? >> But not 1+1 path protected - since it is not end-to-end path >> protected. >> >> To clarify again, this is when you would use SE style. >> >> Thanks >> Suresh >> >> >> At 01:17 PM 4/12/2002 -0400, Thomas D. Nadeau wrote: >> >> >>>> This can be used to set up Protected circuits which may contain >>>> 1+1 lines and 1+1 path protected segments. So on 1+1 line >>>> protected segments, you Share the bandwidth among primary >>>> and alternate paths. >>> >>> >>> You do not share the bandwidth across 1+1 circuits. You >>> double-book the bandwidth because the same packets are >>> sent twice: once over each LSP. You only share bandwidth >>> with 1:N. >>> >>> --Tom >>> >>> >>>> Setting up protected circuits is not considered >>>> in detail so far. Hopefully, P&R design team will consider this.. >>>> >>>> Thanks, >>>> Suresh >>>> >>>> At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote: >>>> >>>>> Hi, >>>>> >>>>> How does SE style of RSVP signalling fits in the optical nature of >>>>> network >>>>> i.e. in wavelength, TDM switching etc. >>>>> >>>>> In other words, How two lsp can share resource in optical networks?? >>>>> >>>>> Regards, >>>>> Khuzema. >>>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> Mathematics is the supreme nostalgia of our time. >> > > From owner-mpls@UU.NET Mon Apr 15 09:52:05 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17560 for ; Mon, 15 Apr 2002 09:52:05 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkrv03292; Mon, 15 Apr 2002 13:51:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkrv21293 for mpls-outgoing; Mon, 15 Apr 2002 13:50: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 QQmkrv21288 for ; Mon, 15 Apr 2002 13:50:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkrv23674 for ; Mon, 15 Apr 2002 13:50:07 GMT Received: from hoemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQmkrv00839 for ; Mon, 15 Apr 2002 13:50:07 GMT Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g3FDo5L26730; Mon, 15 Apr 2002 09:50:06 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA29649; Mon, 15 Apr 2002 09:50:05 -0400 Message-ID: <3CBADA96.5060501@lucent.com> Date: Mon, 15 Apr 2002 09:50:14 -0400 From: Zhi-Wei Lin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gmpls gmpls CC: mpls@UU.NET Subject: Re: SE style in optical neyworks References: <20020415045551.94063.qmail@web13705.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, This implication doesn't necessary apply. What the UNI requests requires that the network be able to support. But this doesn't necessarily imply that what UNI has translates to what the network must also have and no more... The SE style discussion is orthogonal to this... Zhi gmpls gmpls wrote: >Hi, > >I need some more clarification on this regard. >The OIF UNI v1.0 standard says UNI only supports the >FF style of reservation. Since Optical network which >main purpose is to provide service for UNI clients, >would have to support same set reservation styles >which UNI needs. > >So Is there a need for supporting SE style of >reservation in the optical domain? > >Regards > > >__________________________________________________ >Do You Yahoo!? >Yahoo! Tax Center - online filing with TurboTax >http://taxes.yahoo.com/ > From owner-mpls@UU.NET Mon Apr 15 10:03:47 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17963 for ; Mon, 15 Apr 2002 10:03:47 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkrw18469; Mon, 15 Apr 2002 14:01:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkrw27091 for mpls-outgoing; Mon, 15 Apr 2002 14:01: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 QQmkrw26794 for ; Mon, 15 Apr 2002 14:01:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkrw25025 for ; Mon, 15 Apr 2002 14:00:43 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQmkrw13176 for ; Mon, 15 Apr 2002 14:00: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 KAA20150 for ; Mon, 15 Apr 2002 10:00:37 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17642 for ; Mon, 15 Apr 2002 10:00:38 -0400 (EDT) Message-ID: <3CBADD18.939B522A@marconi.com> Date: Mon, 15 Apr 2002 10:00:56 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: SE style in optical neyworks References: <20020415045551.94063.qmail@web13705.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 gmpls gmpls wrote: > > I need some more clarification on this regard. > The OIF UNI v1.0 standard says UNI only supports the > FF style of reservation. Since Optical network which > main purpose is to provide service for UNI clients, > would have to support same set reservation styles > which UNI needs. > > So Is there a need for supporting SE style of > reservation in the optical domain? What's the point? In an optical network, you are signaling wavelengths or time slices. How could you conceivably have two time-slices share resources? Or two wavelengths? The whole concept of SE on optical networks doesn't make sense in the first place. -- David From owner-mpls@UU.NET Mon Apr 15 10:09:02 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18139 for ; Mon, 15 Apr 2002 10:09:01 -0400 (EDT) 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 QQmkrw26980; Mon, 15 Apr 2002 14:08:08 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkrw03761 for mpls-outgoing; Mon, 15 Apr 2002 14:07:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmkrw03756 for ; Mon, 15 Apr 2002 14:07:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkrw16053 for ; Mon, 15 Apr 2002 14:07:43 GMT Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmkrw26243 for ; Mon, 15 Apr 2002 14:07:42 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 16x78I-000469-00; Mon, 15 Apr 2002 15:07:02 +0100 Subject: RE: response to ITU-T SG13 From: Giles Heron To: David Allan Cc: neil.2.harrison@bt.com, kireeti@juniper.net, sob@harvard.edu, mpls@UU.NET In-Reply-To: <3549C09B853DD5119B540002A52CDD3402C0AFCD@zcard0ka.ca.nortel.com> References: <3549C09B853DD5119B540002A52CDD3402C0AFCD@zcard0ka.ca.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 15 Apr 2002 15:07:27 +0000 Message-Id: <1018883247.1131.123.camel@gizzer> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-04-15 at 13:40, David Allan wrote: > Giles: > > A clarification... > > > which means that intermediate LSRs that use a hash to load > > balance MPLS > > traffic over equal cost links/paths have to be careful to > > exclude the S > > bit from any hash. > > If I am inverse muxing an LSP at an intermadiate LSR, is this not on the > basis of some hashing on the payload for the current label, which could be > more labels...I'm not quite getting your example. effectively yes, you are hashing on the payload for the current label - given that it includes more labels. So, for example, an LSR switching based on an LDP-assigned label might have a set of equal cost next hops in its IGP - across which it could load balance traffic based on a hash which includes the draft-martini label inside that LDP assigned label (though of course it wouldn't know whether the inner label was being used for draft-martini, for MPLS VPN, or for something else...) Giles > > Dave > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Mon Apr 15 10:16:55 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18382 for ; Mon, 15 Apr 2002 10:16:55 -0400 (EDT) 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 QQmkrw07754; Mon, 15 Apr 2002 14:14:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkrw13776 for mpls-outgoing; Mon, 15 Apr 2002 14:14: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 QQmkrw13759 for ; Mon, 15 Apr 2002 14:14:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkrw02220 for ; Mon, 15 Apr 2002 14:13:57 GMT Received: from web13708.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13708.mail.yahoo.com [216.136.175.141]) id QQmkrw06724 for ; Mon, 15 Apr 2002 14:13:57 GMT Message-ID: <20020415141356.89320.qmail@web13708.mail.yahoo.com> Received: from [164.164.56.2] by web13708.mail.yahoo.com via HTTP; Mon, 15 Apr 2002 07:13:56 PDT Date: Mon, 15 Apr 2002 07:13:56 -0700 (PDT) From: gmpls gmpls Subject: Re: SE style in optical neyworks To: Zhi-Wei Lin Cc: mpls@UU.NET In-Reply-To: <3CBADA96.5060501@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Thanks Zhi for ur clarification. This has led to another question Is optical network providing service other than UNI clients. If not, why do we have to provide other style of reservation, which is not going to used at all? Regards --- Zhi-Wei Lin wrote: > Hi, > > This implication doesn't necessary apply. What the > UNI requests requires > that the network be able to support. But this > doesn't necessarily imply > that what UNI has translates to what the network > must also have and no > more... > > The SE style discussion is orthogonal to this... > > Zhi > > > gmpls gmpls wrote: > > >Hi, > > > >I need some more clarification on this regard. > >The OIF UNI v1.0 standard says UNI only supports > the > >FF style of reservation. Since Optical network > which > >main purpose is to provide service for UNI clients, > >would have to support same set reservation styles > >which UNI needs. > > > >So Is there a need for supporting SE style of > >reservation in the optical domain? > > > >Regards > > > > > >__________________________________________________ > >Do You Yahoo!? > >Yahoo! Tax Center - online filing with TurboTax > >http://taxes.yahoo.com/ > > > > __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From owner-mpls@UU.NET Mon Apr 15 10:29:08 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18866 for ; Mon, 15 Apr 2002 10:29:08 -0400 (EDT) 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 QQmkrx27652; Mon, 15 Apr 2002 14:27:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkrx15437 for mpls-outgoing; Mon, 15 Apr 2002 14:27: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 QQmkrx15430 for ; Mon, 15 Apr 2002 14:27:40 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 QQmkrx19238 for ; Mon, 15 Apr 2002 14:27: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 QQmkrx26267 for ; Mon, 15 Apr 2002 14:27:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA24802 for ; Mon, 15 Apr 2002 10:27:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA05528 for mpls@uu.net; Mon, 15 Apr 2002 10:27:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmkre08038 for ; Mon, 15 Apr 2002 09:41:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkre07521 for ; Mon, 15 Apr 2002 09:41:20 GMT Received: from mailweb17.rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [203.199.83.29]) id QQmkre01291 for ; Mon, 15 Apr 2002 09:41:19 GMT Received: (qmail 20266 invoked by uid 510); 15 Apr 2002 09:35:19 -0000 Date: 15 Apr 2002 09:35:19 -0000 Message-ID: <20020415093519.20265.qmail@mailweb17.rediffmail.com> Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 15 Apr 2002 09:35:19 -0000 MIME-Version: 1.0 From: "George Thomas" Reply-To: "George Thomas" To: mpls@UU.NET Subject: Queries regarding RFC 3032 Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi, I have two queries regarding MPLS Label Encapsulation. can someone answer these. 1. If there is no LSP associated with a destination (Unicast/Multicast), whether it is mandatory to use NULL Label Encapsulation, and encoding the ethertype value to 0x8847/0x8848. or Is it valid to send as Native IP packet with Ethertype value as 0x800 in the MPLS network. 2. If NULL label is Mandatory, for a broadcast packet, what ethertype value should be used? Whether the Mulitcast ethertype value can be used? If NULL label is not mandatory, it implies that any native IP packet can be sent with ethertype value as 0x800 in a MPLS domain without Label encapsulation. Am i right? Regards George From owner-mpls@UU.NET Mon Apr 15 10:49:17 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19531 for ; Mon, 15 Apr 2002 10:49:17 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkrz23426; Mon, 15 Apr 2002 14:46:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkrz16688 for mpls-outgoing; Mon, 15 Apr 2002 14:46:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmkrz16683 for ; Mon, 15 Apr 2002 14:46:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkrz14957 for ; Mon, 15 Apr 2002 14:45: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 QQmkrz23280 for ; Mon, 15 Apr 2002 14:45:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA26933 for ; Mon, 15 Apr 2002 10:45:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA08081 for mpls@uu.net; Mon, 15 Apr 2002 10:45:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmkry16238 for ; Mon, 15 Apr 2002 14:43:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkry08747 for ; Mon, 15 Apr 2002 14:43:10 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmkry20561 for ; Mon, 15 Apr 2002 14:43:09 GMT Received: (qmail 10799 invoked by uid 104); 15 Apr 2002 14:43:08 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4196. . Clean. Processed in 0.455406 secs); 15 Apr 2002 14:43:08 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 15 Apr 2002 14:43:08 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g3FEh5p18911; Mon, 15 Apr 2002 07:43:05 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 07:43:09 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A6F2@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Scott Bradner'" , mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 07:43:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Scott, Here are my comments/questions: > -----Original Message----- > From: Scott Bradner [mailto:sob@harvard.edu] > Sent: Friday, April 12, 2002 4:45 PM > To: mpls@UU.NET > Subject: response to ITU-T SG13 > > > > This is the response to > http://www.ietf.org/IESG/LIAISON/ITU-SG13-MPLS-OAM.txt > that was discussed during the MPLS session in Minneapolis > that I plan to > send early next week unless the WG has a problem with that. > (Thanks to George for the draft that this is based on) > > Scott > > --------- > > SOURCE: IETF Sub-IP Area - Scott Bradner, Area co-Director > TITLE: Response to "Communication on the status of the request on the > assignment of a reserved label value for MPLS OAM packet > identification" > > The MPLS working group discussed SG 13's request for the > assignment of a > reserved label value for MPLS OAM packet identification > (draft-ohta-mpls-label-value-01.txt) during the MPLS session > during the > recent IETF meeting in Minneapolis. There was some > disagreement during the > discussion about the long term implications of the IETF granting this > request. > > During the discussion it was noted that there are a number of > references to > modifications to IETF protocols in Y.1711. In particular, Section 6.1 > states, "Ideally this should be done automatically via LSP > signaling at > LSP set-up time (e.g. via a CR-LDP or RSVP control-plane > mechanism), but > it could also be configured manually. The mechanism for > achieving this > configuration is outside the scope of this Recommendation." > > Since manual configuration is probably not an option for > anything beyond a > very limited deployment the implication is that the ITU will > require the > IETF to change CR-LDP and RSVP before Y.1711 would be seen as > a complete > solution. Why are optional extensions to CR-LDP and RSVP-TE a concern for IETF? After all these protocols are constantly being extended (e.g. GMPLS, DS-TE, etc.) > > Also in section 6.3, Forward Defect Indication, the following > text may be > read as indicating an assumption of future changes in IETF protocols > dealing with LSP signaling. > > "It is important that the LSP sink point knows (for the > duration that the > LSP is in service) any server->client LSP label mappings that were in > existence prior to the defect. Although the exact means for > achieving this > are outside the scope of this Recommendation, some examples > of how these > server-> client layer label mappings could be configured are > as follows: > o manually, via the NMS say; > o automatically on LSP set-up via extensions to LSP signaling ..." > > In order to understand the possible consequences of allocating an MPLS > codepoint in response to the request in > draft-ohta-mpls-label-value-01.txt > the MPLS working group would like to understand the full > scope and extent > of the modifications that SG13 may be assuming to other IETF > protocols, > including LDP, CR-LDP, RSVP, PIM and BGP. Why PIM? > > A further concern is the impact on the MPLS forwarding plane > as currently > defined. In certain points in a MPLS network, based on an > incoming label, > the label is removed and the packet is forwarded with no > further inspection > of subsequent headers (be it another MPLS label or some other header). I assume this is talking about PHP. > Y.1711 seems to imply that the above behavior would not > satisfy Y.1711. > Specifically, there are some cases where Y.1711 would expect a network > element to intercept an OAM packet. This raises issues of backward > compatibility with existing MPLS systems and ASICs. >From which part of the Y.1711 did you get this impression? No where in Y.1711 is any requirement for intercepting OAM packets, not even at the PHP point. The OAM packet is only visible at the ingress and egress LSRs. I suggest removing this paragraph, becasue it shows a lack of understanding of Y.1711. > > The MPLS working group would like to understand if Y.1711 assumes > functionally that could not be supported by simply changing > software in > existing MPLS implementations. Some vendors may have implemented their MPLS data-plane in hardware and some in software. Why should a vendor's implementation be a concern for a standard body such as IETF? I therefore suggest removing this paragraph. Yours, -Shahram > > > From owner-mpls@UU.NET Mon Apr 15 10:54:29 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19647 for ; Mon, 15 Apr 2002 10:54:29 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkrz24512; Mon, 15 Apr 2002 14:52:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkrz17323 for mpls-outgoing; Mon, 15 Apr 2002 14:52:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmkrz17316 for ; Mon, 15 Apr 2002 14:52:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkrz05406 for ; Mon, 15 Apr 2002 14:51:22 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 QQmkrz22787 for ; Mon, 15 Apr 2002 14:51:21 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 KAA28447 for ; Mon, 15 Apr 2002 10:51:08 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA06876 for ; Mon, 15 Apr 2002 10:51:08 -0400 (EDT) Message-ID: <3CBAE8EE.D6F14CE6@marconi.com> Date: Mon, 15 Apr 2002 10:51:26 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Queries regarding RFC 3032 References: <20020415093519.20265.qmail@mailweb17.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George Thomas wrote: > > 1. If there is no LSP associated with a destination (Unicast/ > Multicast), whether it is mandatory to use NULL Label > Encapsulation, and encoding the ethertype value to 0x8847/0x8848. > or Is it valid to send as Native IP packet with Ethertype > value as 0x800 in the MPLS network. If an LER receives an unlabeled packet, and there is no forwarding table information descrbing what LSP to send the packet on, then the behavior is beyond the scope of MPLS. It would be legal to forward the packet hop-by-hop, as a non-MPLS router would. It would also be legal to drop the packet and generate an ICMP error (treating it as a non-MPLS router would if there is no route to the destination.) I would not expect a NULL label to be used in this situation. > 2. If NULL label is Mandatory, for a broadcast packet, what > ethertype value should be used? Whether the Mulitcast ethertype > value can be used? > > If NULL label is not mandatory, it implies that any native IP > packet can be sent with ethertype value as 0x800 in a MPLS domain > without Label encapsulation. Am i right? MPLS routers have to be able to send and receive non-labeled packets. That's how the routing and signaling protocols all work. Whether they also have the capability of forwarding unlabeled packets is up to the design of the router, of course. I think such capability is required for some protocol features (like extended-discovery LDP peering), however. Of course, Ethertypes are only valid on those interfaces that use Ethertypes. Other interfaces would use whatever layer-2 types are appropriate for the IP packet. -- David From owner-mpls@UU.NET Mon Apr 15 11:40:09 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20666 for ; Mon, 15 Apr 2002 11:40:09 -0400 (EDT) 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 QQmksc18015; Mon, 15 Apr 2002 15:39:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksc11088 for mpls-outgoing; Mon, 15 Apr 2002 15:39:00 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmksc11081 for ; Mon, 15 Apr 2002 15:38:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmksc08575 for ; Mon, 15 Apr 2002 15:38:18 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 QQmksc08163 for ; Mon, 15 Apr 2002 15:38:16 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g3FFc3405230; Mon, 15 Apr 2002 21:08:03 +0530 (IST) Received: from sushanth (pcsva235.sasken.com [10.1.65.235]) by sunsv2.sasken.com (8.11.6/8.11.6) with SMTP id g3FFc2B02943; Mon, 15 Apr 2002 21:08:02 +0530 (IST) From: "sushantm" To: Cc: Subject: Control plane and data plane adjacency Date: Mon, 15 Apr 2002 21:09:39 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: High Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have few doubts regarding control channel adjacency being different from the data channel adjacency Suppose,take a case as shown in the figure +---(R1)---(R2)----+ +---(R3)---(R4)----+ | | | | | | | | | | | | | | | | +----------+---+ +---+--+-----+ +--+---------+ | +----------+ +---------+ | | +----------+ +---------+ | | OXC1 +----------+ OXC2 +---------+ OXC3 | | +----------+ +---------+ | | | | | | | +--------------+ +------------+ +------------+ R1,R2,R3,R4 - Router provding the control channel adajceny In this case OXC1-OXC2 control channel adjaceny is OXC1-R1-R2-OXC2.Similarly between OXC2 and OXC3 thro R3 and R4. Requirement is setup LSP between OXC1 and OXC3. 1. Routing table would provide me Next hop information in the control plane. How do we get the information about the Next hop Node in the Dataplane. LMP will provide me with information, for instance,at OXC2 what are the dataplane adjacent nodes, but will not provide me with data plane routing information. How do OXC1 knows to select OXC2 for the LSP setup, where OXC1 could have been connected to more than one neighbors. From where do I get the Data plane route information? 2. Suppose R2 had connection to OXC2 as well as OXC3. Then the signaling information received at R3 will be forwarded directly to OX3 without getting processed at OXC2, which is not correct. How do we take care of this problem. The [GMPLS-SIG] or [GMPLS-RSVP] does not discuss this issue. Is there any references to this issue. Answer would be very much appreciated. Regards, Sushanth Sushanth.M Sasken Technologies Communication Limited Phone: 5355501,5355503 Exth:6358 E-mail: sushantm@sasken.com From owner-mpls@UU.NET Mon Apr 15 12:24:08 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22511 for ; Mon, 15 Apr 2002 12:24:07 -0400 (EDT) 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 QQmksf24692; Mon, 15 Apr 2002 16:22:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksf05235 for mpls-outgoing; Mon, 15 Apr 2002 16:22:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmksf05230 for ; Mon, 15 Apr 2002 16:22:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmksf00410 for ; Mon, 15 Apr 2002 16:22:17 GMT From: neil.2.harrison@bt.com Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmksf23919 for ; Mon, 15 Apr 2002 16:22:17 GMT Received: by mbibipnt08.hc.bt.com with Internet Mail Service (5.5.2653.19) id <2XKCCTCX>; Mon, 15 Apr 2002 17:22:22 +0100 Message-ID: To: giles@packetexchange.net Cc: mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 17:21:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Giles Heron wrote 15 April 2002 14:57 > > so you're effectively saying that in order to apply OAM at a higher > layer trail you need strictly CO trails at all lower layers? NH=> There are 3 basic network types: - cnls - co pkt-sw - co cct-sw Each has a generic 'network solution' irrespective of particular technology across data/control/management-plane facets. Below IP all technologies are either co pkt-sw or co cct-sw. What do you think IP routers are connected with across the WAN?.....physical wide area connectivity must ultimately use a CO technology, eg SDH/SONET, PDH, WDM, OTN. So, assuming we can manage all these layers independently, the trite answer to your question is 'yes'. regards, Neil From owner-mpls@UU.NET Mon Apr 15 12:37:43 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24712 for ; Mon, 15 Apr 2002 12:37:43 -0400 (EDT) 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 QQmksg15751; Mon, 15 Apr 2002 16:36:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksg06430 for mpls-outgoing; Mon, 15 Apr 2002 16:36:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmksg06425 for ; Mon, 15 Apr 2002 16:36:27 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 QQmksg15873 for ; Mon, 15 Apr 2002 16:35:29 GMT Received: from ihemail1.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQmksg18765 for ; Mon, 15 Apr 2002 16:35:28 GMT Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with SMTP id g3FGYrT25800; Mon, 15 Apr 2002 12:34:54 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA12937; Mon, 15 Apr 2002 12:34:53 -0400 Message-ID: <3CBB0136.4090806@lucent.com> Date: Mon, 15 Apr 2002 12:35:02 -0400 From: John Ellson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sushantm CC: mpls@UU.NET, gmpls-ops@mplsrc.com Subject: Re: Control plane and data plane adjacency References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit sushantm wrote: > Hi, > > I have few doubts regarding control channel adjacency being different from > the data channel > adjacency > > Suppose,take a case as shown in the figure > > +---(R1)---(R2)----+ +---(R3)---(R4)----+ > | | | | > | | | | > | | | | > | | | | > +----------+---+ +---+--+-----+ +--+---------+ > | +----------+ +---------+ | > | +----------+ +---------+ | > | OXC1 +----------+ OXC2 +---------+ OXC3 | > | +----------+ +---------+ | > | | | | | | > +--------------+ +------------+ +------------+ > > R1,R2,R3,R4 - Router provding the control channel adajceny > > In this case OXC1-OXC2 control channel adjaceny is > OXC1-R1-R2-OXC2.Similarly between OXC2 and > OXC3 thro R3 and R4. > > Requirement is setup LSP between OXC1 and OXC3. > > 1. > Routing table would provide me Next hop information in the control plane. > How do we get the > information about the Next hop Node in the Dataplane. LMP will provide me > with information, > for instance,at OXC2 what are the dataplane adjacent nodes, but will not > provide me with data > plane routing information. How do OXC1 knows to select OXC2 for the LSP > setup, where OXC1 could > have been connected to more than one neighbors. > > From where do I get the Data plane route information? Not sure why you want data plane routing information, but the next system IP address will presumably be found from a DNS lookup, just like any other data network conection. > 2. > Suppose R2 had connection to OXC2 as well as OXC3. > Then the signaling information received at R3 will be forwarded directly to > OX3 without getting > processed at OXC2, which is not correct. How do we take care of this > problem. The [GMPLS-SIG] or > [GMPLS-RSVP] does not discuss this issue. Is there any references to this > issue. If optical-routing information needs to be processed by a routing application at OX2, then the messages will be addressed to "ox2.my.net" (or whatever). From there the routing application will do its thing and may send additional messages to OX3. i.e. its an application level forwarding problem, not a level 3 data-forwarding. John Ellson From owner-mpls@UU.NET Mon Apr 15 12:59:57 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27747 for ; Mon, 15 Apr 2002 12:59:56 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmksh19234; Mon, 15 Apr 2002 16:58:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksh08352 for mpls-outgoing; Mon, 15 Apr 2002 16:58: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 QQmksh08347 for ; Mon, 15 Apr 2002 16:57:57 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 QQmksh08279 for ; Mon, 15 Apr 2002 16:56: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 QQmksh17238 for ; Mon, 15 Apr 2002 16:56:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA06225 for ; Mon, 15 Apr 2002 12:56:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA22373 for mpls@uu.net; Mon, 15 Apr 2002 12:56:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmksh08019 for ; Mon, 15 Apr 2002 16:54: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 QQmksh04788 for ; Mon, 15 Apr 2002 16:54:26 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQmksh20008 for ; Mon, 15 Apr 2002 16:54:25 GMT Received: from mira1.cisco.com (IDENT:mirapoint@mira1.cisco.com [64.101.14.50]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3FGs9HO022459; Mon, 15 Apr 2002 09:54:20 -0700 (PDT) Received: from SKATUKAM-W2K2.cisco.com (dhcp-171-69-52-158.cisco.com [171.69.52.158]) by mira1.cisco.com (Mirapoint) with ESMTP id AAV42293; Mon, 15 Apr 2002 09:54:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20020415093011.00b55d08@mira1.cisco.com> X-Sender: skatukam@mira1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Apr 2002 09:54:02 -0700 To: mpls@UU.NET From: Suresh Katukam Subject: Re: Fwd: Re: SE style in optical networks Cc: ccamp@ops.ietf.org In-Reply-To: <4.3.2.7.2.20020412150328.00b782a0@mira1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Zhi, Sudheer and others, Looks like this was lost in all other mails.. So please take a look at this.. At 03:03 PM 4/12/2002 -0700, Suresh Katukam wrote: >>Tom and all, >> >>I think everyone seemed to pick on my terminology or misinterpreted >>what I said. >> >>Here is an example: >> >> 1+1 1+1 >>A ----------------B --------- C ------------D >> \ / >> \ / >> E >> >> >>A - B & C - D 1+1 line protected >>B - C, C - E, B - E are all unprotected links. >> >>Say, one wants to create a protected LSP from A to D. >>then, you would create one primary LSP from A to D via >>A - B - C - D, and then you would create another LSP >>from A to D using SE style ( to indicate that this is an >>alternate path for same Tunnel ) via A - B - E - C - D. >>This way B - C is protected by B - E - C. >> >>B - C - E is not configured as a UPSR. All unprotected links. >>Virtual UPSR can be created such a way that B has a bridge >>and C has a selector. Ofcourse, for bidirectional LSP, you need >>the same thing in the opposite direction too. >> >>Now, what do you call this kind of protection? Protected LSP? >>But not 1+1 path protected - since it is not end-to-end path >>protected. >> >>To clarify again, this is when you would use SE style. >> >>Thanks >>Suresh >> >> >>At 01:17 PM 4/12/2002 -0400, Thomas D. Nadeau wrote: >> >> >>>>This can be used to set up Protected circuits which may contain >>>>1+1 lines and 1+1 path protected segments. So on 1+1 line >>>>protected segments, you Share the bandwidth among primary >>>>and alternate paths. >>> >>> You do not share the bandwidth across 1+1 circuits. You >>>double-book the bandwidth because the same packets are >>>sent twice: once over each LSP. You only share bandwidth >>>with 1:N. >>> >>> --Tom >>> >>> >>>>Setting up protected circuits is not considered >>>>in detail so far. Hopefully, P&R design team will consider this.. >>>> >>>>Thanks, >>>>Suresh >>>> >>>>At 04:32 PM 4/12/2002 +0530, Khuzema Pithewan wrote: >>>>>Hi, >>>>> >>>>>How does SE style of RSVP signalling fits in the optical nature of network >>>>>i.e. in wavelength, TDM switching etc. >>>>> >>>>> In other words, How two lsp can share resource in optical networks?? >>>>> >>>>>Regards, >>>>>Khuzema. >>> >>> >>> >>>------------------------------------------------------------------------ >>>Mathematics is the supreme nostalgia of our time. > From owner-mpls@UU.NET Mon Apr 15 13:03:56 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27871 for ; Mon, 15 Apr 2002 13:03:56 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmksi01638; Mon, 15 Apr 2002 17:03:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksi19793 for mpls-outgoing; Mon, 15 Apr 2002 17:02:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmksi19756 for ; Mon, 15 Apr 2002 17:02:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmksi00884 for ; Mon, 15 Apr 2002 17:01:57 GMT Received: from rincewind.office.packetexchange.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmksi00027 for ; Mon, 15 Apr 2002 17:01:56 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 16x9rT-0004Uh-00; Mon, 15 Apr 2002 18:01:51 +0100 Subject: RE: response to ITU-T SG13 From: Giles Heron To: neil.2.harrison@bt.com Cc: mpls@UU.NET In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 15 Apr 2002 18:02:16 +0000 Message-Id: <1018893736.1130.258.camel@gizzer> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Neil, On Mon, 2002-04-15 at 16:21, neil.2.harrison@bt.com wrote: > Giles Heron wrote 15 April 2002 14:57 > > > > > so you're effectively saying that in order to apply OAM at a higher > > layer trail you need strictly CO trails at all lower layers? > > NH=> There are 3 basic network types: > - cnls > - co pkt-sw > - co cct-sw > Each has a generic 'network solution' irrespective of particular technology > across data/control/management-plane facets. Below IP all technologies are > either co pkt-sw or co cct-sw. What do you think IP routers are connected > with across the WAN?.....physical wide area connectivity must ultimately use > a CO technology, eg SDH/SONET, PDH, WDM, OTN. So, assuming we can manage > all these layers independently, the trite answer to your question is 'yes'. Not all technologies below IP are CO. What about the most common link layer for IP - Ethernet? Sure, Ethernets run over wires (which are inherently CO). But then what about 802.11b wireless LANs? Not much CO going on there AFAIK. But yes, as someone who connects IP routers for a living, I am well aware that in the wide area IP runs over CO technologies ;-) At any rate, your "yes" answer gives me cause for concern. If you require strictly CO trails (i.e. TE) at *all* lower layers in order to use OAM at a higher layer then OAM would seem to have quite limited utility? Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Mon Apr 15 13:04:33 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27902 for ; Mon, 15 Apr 2002 13:04:32 -0400 (EDT) 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 QQmksi29462; Mon, 15 Apr 2002 17:03:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksi19882 for mpls-outgoing; Mon, 15 Apr 2002 17:03: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 QQmksi19869 for ; Mon, 15 Apr 2002 17:03: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 QQmksh15957 for ; Mon, 15 Apr 2002 16:59:50 GMT Received: from zcars04e.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQmksh21414 for ; Mon, 15 Apr 2002 16:59:50 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FGxLO27131; Mon, 15 Apr 2002 12:59:21 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJA3MLA>; Mon, 15 Apr 2002 12:59:22 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402C0B41E@zcard0ka.ca.nortel.com> From: "David Allan" To: Giles Heron Cc: neil.2.harrison@bt.com, kireeti@juniper.net, sob@harvard.edu, mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 12:59:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E49E.E30E3C72" 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_01C1E49E.E30E3C72 Content-Type: text/plain; charset="iso-8859-1" Giles: So then why does whether or not the S bit is set matter? Seem to me that both scenarios need to be covered unless I was producing a very specialized implementation.... - the current label is also the bottom label - the current label is not the bottom label and the label underneath may be transport or reserved. cheers Dave > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Monday, April 15, 2002 11:07 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu; > mpls@UU.NET > Subject: RE: response to ITU-T SG13 > > > On Mon, 2002-04-15 at 13:40, David Allan wrote: > > Giles: > > > > A clarification... > > > > > which means that intermediate LSRs that use a hash to load > > > balance MPLS > > > traffic over equal cost links/paths have to be careful to > > > exclude the S > > > bit from any hash. > > > > If I am inverse muxing an LSP at an intermadiate LSR, is > this not on the > > basis of some hashing on the payload for the current label, > which could be > > more labels...I'm not quite getting your example. > > effectively yes, you are hashing on the payload for the > current label - > given that it includes more labels. So, for example, an LSR switching > based on an LDP-assigned label might have a set of equal cost > next hops > in its IGP - across which it could load balance traffic based > on a hash > which includes the draft-martini label inside that LDP assigned label > (though of course it wouldn't know whether the inner label was being > used for draft-martini, for MPLS VPN, or for something else...) > > Giles > > > > > Dave > > > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > > ------_=_NextPart_001_01C1E49E.E30E3C72 Content-Type: text/html; charset="iso-8859-1" RE: response to ITU-T SG13

Giles:

So then why does whether or not the S bit is set matter?

Seem to me that both scenarios need to be covered unless I was producing a very specialized implementation....
- the current label is also the bottom label
- the current label is not the bottom label and the label underneath may be transport or reserved.

cheers
Dave


> -----Original Message-----
> From: Giles Heron [mailto:giles@packetexchange.net]
> Sent: Monday, April 15, 2002 11:07 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu;
> mpls@UU.NET
> Subject: RE: response to ITU-T SG13
>
>
> On Mon, 2002-04-15 at 13:40, David Allan wrote:
> > Giles:
> >
> > A clarification...
> >
> > > which means that intermediate LSRs that use a hash to load
> > > balance MPLS
> > > traffic over equal cost links/paths have to be careful to
> > > exclude the S
> > > bit from any hash.
> >
> > If I am inverse muxing an LSP at an intermadiate LSR, is
> this not on the
> > basis of some hashing on the payload for the current label,
> which could be
> > more labels...I'm not quite getting your example.
>
> effectively yes, you are hashing on the payload for the
> current label -
> given that it includes more labels.  So, for example, an LSR switching
> based on an LDP-assigned label might have a set of equal cost
> next hops
> in its IGP - across which it could load balance traffic based
> on a hash
> which includes the draft-martini label inside that LDP assigned label
> (though of course it wouldn't know whether the inner label was being
> used for draft-martini, for MPLS VPN, or for something else...)
>
> Giles
>
> >
> > Dave
> >
> > 
> --
> =================================================================
> Giles Heron    Principal Network Architect    PacketExchange Ltd.
> ph: +44 7880 506185              "if you build it they will yawn"
> =================================================================
>
>

------_=_NextPart_001_01C1E49E.E30E3C72-- From owner-mpls@UU.NET Mon Apr 15 13:18:26 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28619 for ; Mon, 15 Apr 2002 13:18:26 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkry01770; Mon, 15 Apr 2002 14:36:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkry15871 for mpls-outgoing; Mon, 15 Apr 2002 14:35: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 QQmkry15863 for ; Mon, 15 Apr 2002 14:35:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkry12550 for ; Mon, 15 Apr 2002 14:35:06 GMT Received: from tomp.smb.utfors.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQmkry29747 for ; Mon, 15 Apr 2002 14:35:05 GMT Received: from utfors.se ([172.20.0.76]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GUM61X00.5BL; Mon, 15 Apr 2002 16:39:33 +0200 Message-ID: <3CBAE514.30006@utfors.se> Date: Mon, 15 Apr 2002 16:35:00 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: David Allan CC: Scott Bradner , mpls@UU.NET Subject: Re: response to ITU-T SG13 References: <3549C09B853DD5119B540002A52CDD3402C0AFAE@zcard0ka.ca.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit All, did read this before it was sent. I thought that PIM came in via the mpls multicast framework, just now processed by the IESG to the rfc-editor. See e.g. page 18 in the framework: "a) Multicast routing messages: protocols as PIM-SM and CBT have explicit Join messages which could carry the label mappings. This approach is described in [FARI]. When different multicast routing protocols are deployed, an extension to each of these protocols has to be defined." But I might be wrong. The [FARI] did not go anywhere did it? /loa David Allan wrote: > Hi Scott: > > I think readability would be enhanced if the third paragraph was > deleted..."Since manual configuration .... before Y.1711 would be seen > as a complete solution."....The third para discusses if changes to > CR-LDP and RSVP are expected and a few paragraphs later the question is > enlarged to include LDP, PIM and BGP. > > I'll plead ignorance, but I'm not sure why PIM is on the list...? > > cheers > Dave > > > > -----Original Message----- > > From: Scott Bradner [mailto:sob@harvard.edu] > > Sent: Friday, April 12, 2002 4:45 PM > > To: mpls@UU.NET > > Subject: response to ITU-T SG13 > > > > > > > > This is the response to > > http://www.ietf.org/IESG/LIAISON/ITU-SG13-MPLS-OAM.txt > > that was discussed during the MPLS session in Minneapolis > > that I plan to > > send early next week unless the WG has a problem with that. > > (Thanks to George for the draft that this is based on) > > > > Scott > > > > --------- > > > > SOURCE: IETF Sub-IP Area - Scott Bradner, Area co-Director > > TITLE: Response to "Communication on the status of the request on the > > assignment of a reserved label value for MPLS OAM packet > > identification" > > > > The MPLS working group discussed SG 13's request for the > > assignment of a > > reserved label value for MPLS OAM packet identification > > (draft-ohta-mpls-label-value-01.txt) during the MPLS session > > during the > > recent IETF meeting in Minneapolis. There was some > > disagreement during the > > discussion about the long term implications of the IETF granting this > > request. > > > > During the discussion it was noted that there are a number of > > references to > > modifications to IETF protocols in Y.1711. In particular, Section 6.1 > > states, "Ideally this should be done automatically via LSP > > signaling at > > LSP set-up time (e.g. via a CR-LDP or RSVP control-plane > > mechanism), but > > it could also be configured manually. The mechanism for > > achieving this > > configuration is outside the scope of this Recommendation." > > > > Since manual configuration is probably not an option for > > anything beyond a > > very limited deployment the implication is that the ITU will > > require the > > IETF to change CR-LDP and RSVP before Y.1711 would be seen as > > a complete > > solution. > > > > Also in section 6.3, Forward Defect Indication, the following > > text may be > > read as indicating an assumption of future changes in IETF protocols > > dealing with LSP signaling. > > > > "It is important that the LSP sink point knows (for the > > duration that the > > LSP is in service) any server->client LSP label mappings that were in > > existence prior to the defect. Although the exact means for > > achieving this > > are outside the scope of this Recommendation, some examples > > of how these > > server-> client layer label mappings could be configured are > > as follows: > > o manually, via the NMS say; > > o automatically on LSP set-up via extensions to LSP signaling ..." > > > > In order to understand the possible consequences of allocating an MPLS > > codepoint in response to the request in > > draft-ohta-mpls-label-value-01.txt > > the MPLS working group would like to understand the full > > scope and extent > > of the modifications that SG13 may be assuming to other IETF > > protocols, > > including LDP, CR-LDP, RSVP, PIM and BGP. > > > > A further concern is the impact on the MPLS forwarding plane > > as currently > > defined. In certain points in a MPLS network, based on an > > incoming label, > > the label is removed and the packet is forwarded with no > > further inspection > > of subsequent headers (be it another MPLS label or some other header). > > Y.1711 seems to imply that the above behavior would not > > satisfy Y.1711. > > Specifically, there are some cases where Y.1711 would expect a network > > element to intercept an OAM packet. This raises issues of backward > > compatibility with existing MPLS systems and ASICs. > > > > The MPLS working group would like to understand if Y.1711 assumes > > functionally that could not be supported by simply changing > > software in > > existing MPLS implementations. > > > > > > > -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Mon Apr 15 13:28:22 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28895 for ; Mon, 15 Apr 2002 13:28:22 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmksj00585; Mon, 15 Apr 2002 17:27:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksj01843 for mpls-outgoing; Mon, 15 Apr 2002 17:27:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmksj01838 for ; Mon, 15 Apr 2002 17:27:21 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 QQmksj17966 for ; Mon, 15 Apr 2002 17:27:19 GMT Received: from rincewind.office.packetexchange.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmksj04831 for ; Mon, 15 Apr 2002 17:27:19 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 16xAFv-0004Xg-00; Mon, 15 Apr 2002 18:27:07 +0100 Subject: RE: response to ITU-T SG13 From: Giles Heron To: David Allan Cc: neil.2.harrison@bt.com, kireeti@juniper.net, sob@harvard.edu, mpls@UU.NET In-Reply-To: <3549C09B853DD5119B540002A52CDD3402C0B41E@zcard0ka.ca.nortel.com> References: <3549C09B853DD5119B540002A52CDD3402C0B41E@zcard0ka.ca.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 15 Apr 2002 18:27:32 +0000 Message-Id: <1018895252.1130.285.camel@gizzer> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-04-15 at 16:59, David Allan wrote: > Giles: > > So then why does whether or not the S bit is set matter? perhaps a picture would help? Say an LSR switches a packet with the following stack: |--------|--------| | X, S=0 | Y, S=1 | |--------|--------| It has an L-FIB entry for X that has n equal cost paths. What we would like to be able to do is to hash across the entire stack. This way a second packet with the following stack: |--------|--------| | X, S=0 | Z, S=1 | |--------|--------| can use a different one of the n equal cost paths (depending on the hash function and the values of Y and Z of course). However the problem arises if you have MPLS OAM and the following packet is sent: |--------|--------|--------| | X, S=0 | Y, S=0 |14, S=1 | |--------|--------|--------| If the hash includes the S bit then this will most likely be sent on a different link to the first packet. Likewise if the hash includes *all* labels then this will most likely be sent on a different link. So what you need is to know a-priori the minimal depth of stack for non-OAM traffic and hash over that number of labels. But this coarsens the granularity of the load balancing, and also requires configuration - unless you take the most simplistic approach and hash only using the first label (which barely qualifies as load balancing). > Seem to me that both scenarios need to be covered unless I was producing a > very specialized implementation.... > - the current label is also the bottom label > - the current label is not the bottom label and the label underneath may be > transport or reserved. not sure what you mean by "current" label. Do you mean the label you are switching on? Giles > cheers > Dave > > > > -----Original Message----- > > From: Giles Heron [mailto:giles@packetexchange.net] > > Sent: Monday, April 15, 2002 11:07 AM > > To: Allan, David [CAR:NS00:EXCH] > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu; > > mpls@UU.NET > > Subject: RE: response to ITU-T SG13 > > > > > > On Mon, 2002-04-15 at 13:40, David Allan wrote: > > > Giles: > > > > > > A clarification... > > > > > > > which means that intermediate LSRs that use a hash to load > > > > balance MPLS > > > > traffic over equal cost links/paths have to be careful to > > > > exclude the S > > > > bit from any hash. > > > > > > If I am inverse muxing an LSP at an intermadiate LSR, is > > this not on the > > > basis of some hashing on the payload for the current label, > > which could be > > > more labels...I'm not quite getting your example. > > > > effectively yes, you are hashing on the payload for the > > current label - > > given that it includes more labels. So, for example, an LSR switching > > based on an LDP-assigned label might have a set of equal cost > > next hops > > in its IGP - across which it could load balance traffic based > > on a hash > > which includes the draft-martini label inside that LDP assigned label > > (though of course it wouldn't know whether the inner label was being > > used for draft-martini, for MPLS VPN, or for something else...) > > > > Giles > > > > > > > > Dave > > > > > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Mon Apr 15 13:45:30 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29684 for ; Mon, 15 Apr 2002 13:45:30 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmksk25653; Mon, 15 Apr 2002 17:44:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksk03010 for mpls-outgoing; Mon, 15 Apr 2002 17:44:31 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 QQmksk03005 for ; Mon, 15 Apr 2002 17:44:27 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 QQmksk24583 for ; Mon, 15 Apr 2002 17:44: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 QQmksk01796 for ; Mon, 15 Apr 2002 17:44: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 NAA09244 for ; Mon, 15 Apr 2002 13:44:05 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA28259 for mpls@uu.net; Mon, 15 Apr 2002 13:44:05 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmksk02930 for ; Mon, 15 Apr 2002 17:43: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 QQmksk18660 for ; Mon, 15 Apr 2002 17:41:41 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmksk24501 for ; Mon, 15 Apr 2002 17:41:35 GMT Received: (qmail 27457 invoked by uid 104); 15 Apr 2002 17:41:34 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4196. . Clean. Processed in 0.457823 secs); 15 Apr 2002 17:41:34 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 15 Apr 2002 17:41:33 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g3FHfUp23534; Mon, 15 Apr 2002 10:41:30 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 10:41:35 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A6F9@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Giles Heron'" , neil.2.harrison@bt.com Cc: kireeti@juniper.net, sob@harvard.edu, mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 10:41:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Giles, > which means that intermediate LSRs that use a hash to load > balance MPLS > traffic over equal cost links/paths have to be careful to > exclude the S > bit from any hash. An more logical method is for the hash result to point to the same region of the hash key when S=0 or S=1 in the bottom-most label. > > I'm not sure that this is the case for all current implementations... I don't think specific implementations should be a concern for a standard body such as IETF. You could always find a specific implementations that can't support a new function. Any objection regarding backward compatibility should be based on a standard. AFAIK there is no standard for hash-based ECMP MPLS switching. > > In fact this also would seem to imply that you have to hash > over a fixed > number of labels (to ensure that both the OAM traffic and the user > traffic get the same hash value). This coarsens the load balancing > granularity somewhat :( If only 0.1% of a single label range is used, you could still select up to ~1000 different flows using that "single" label. I am not sure of how coarse this is!!! > > The alternatives would be either to preclude hashed > load-balancing or to > require OAM-aware core LSRs. Neither of these options is acceptable > IMO. > Giles, even MPLS-ping that is carried over non-IP carrying LSP uses an extra label (Explicit Null label). So I don't think you can find any solution that can satisfy the restricted implementations in your boxes. Yours, -Shahram > Giles > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > From owner-mpls@UU.NET Mon Apr 15 13:48:59 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29808 for ; Mon, 15 Apr 2002 13:48:59 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmksk24651; Mon, 15 Apr 2002 17:41:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksk02829 for mpls-outgoing; Mon, 15 Apr 2002 17:41: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 QQmksk02824 for ; Mon, 15 Apr 2002 17:41:18 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 QQmksk12662 for ; Mon, 15 Apr 2002 17:38:56 GMT Received: from zcars04e.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQmksk20886 for ; Mon, 15 Apr 2002 17:38:55 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FHcMO00589; Mon, 15 Apr 2002 13:38:22 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJA3NS5>; Mon, 15 Apr 2002 13:38:22 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402C6E4C3@zcard0ka.ca.nortel.com> From: "David Allan" To: Giles Heron Cc: neil.2.harrison@bt.com, kireeti@juniper.net, sob@harvard.edu, mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 13:38:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4A4.53EC4B6E" 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_01C1E4A4.53EC4B6E Content-Type: text/plain; charset="iso-8859-1" Thanks Giles, I understand the scenario you are discussing and the S bit is a legit issue. To re-use your pictures, I was considering when y=OAM alert, not OAM alert under 'y'. But ultimately I think the problem exists independently of the OAM alert label. It would also be true if any reserved label (e.g. explicit V4 label) was used, and suggests that for stuff to function correctly your implementation should only be looking one label further into the stack and MUST ignore the S bit. The existence of reserved labels means that hashing more than one label deep has problems, and including the S bit has problems. Implementation wise this may not be the case today, but live and learn ;-) This preserves any detection properties for any tools employed regardless of the type used, payload used etc. cheers Dave > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Monday, April 15, 2002 2:28 PM > To: Allan, David [CAR:NS00:EXCH] > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu; > mpls@UU.NET > Subject: RE: response to ITU-T SG13 > > > On Mon, 2002-04-15 at 16:59, David Allan wrote: > > Giles: > > > > So then why does whether or not the S bit is set matter? > > perhaps a picture would help? > > Say an LSR switches a packet with the following stack: > > |--------|--------| > | X, S=0 | Y, S=1 | > |--------|--------| > > It has an L-FIB entry for X that has n equal cost paths. > > What we would like to be able to do is to hash across the > entire stack. > This way a second packet with the following stack: > > |--------|--------| > | X, S=0 | Z, S=1 | > |--------|--------| > > can use a different one of the n equal cost paths (depending > on the hash > function and the values of Y and Z of course). > > However the problem arises if you have MPLS OAM and the > following packet > is sent: > > |--------|--------|--------| > | X, S=0 | Y, S=0 |14, S=1 | > |--------|--------|--------| > > If the hash includes the S bit then this will most likely be sent on a > different link to the first packet. > > Likewise if the hash includes *all* labels then this will > most likely be > sent on a different link. > > So what you need is to know a-priori the minimal depth of stack for > non-OAM traffic and hash over that number of labels. But > this coarsens > the granularity of the load balancing, and also requires > configuration - > unless you take the most simplistic approach and hash only using the > first label (which barely qualifies as load balancing). > > > Seem to me that both scenarios need to be covered unless I > was producing a > > very specialized implementation.... > > - the current label is also the bottom label > > - the current label is not the bottom label and the label > underneath may be > > transport or reserved. > > not sure what you mean by "current" label. Do you mean the label you > are switching on? > > Giles > > > cheers > > Dave > > > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > Sent: Monday, April 15, 2002 11:07 AM > > > To: Allan, David [CAR:NS00:EXCH] > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu; > > > mpls@UU.NET > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > On Mon, 2002-04-15 at 13:40, David Allan wrote: > > > > Giles: > > > > > > > > A clarification... > > > > > > > > > which means that intermediate LSRs that use a hash to load > > > > > balance MPLS > > > > > traffic over equal cost links/paths have to be careful to > > > > > exclude the S > > > > > bit from any hash. > > > > > > > > If I am inverse muxing an LSP at an intermadiate LSR, is > > > this not on the > > > > basis of some hashing on the payload for the current label, > > > which could be > > > > more labels...I'm not quite getting your example. > > > > > > effectively yes, you are hashing on the payload for the > > > current label - > > > given that it includes more labels. So, for example, an > LSR switching > > > based on an LDP-assigned label might have a set of equal cost > > > next hops > > > in its IGP - across which it could load balance traffic based > > > on a hash > > > which includes the draft-martini label inside that LDP > assigned label > > > (though of course it wouldn't know whether the inner > label was being > > > used for draft-martini, for MPLS VPN, or for something else...) > > > > > > Giles > > > > > > > > > > > Dave > > > > > > > > > > > -- > > > ================================================================= > > > 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" > ================================================================= > > ------_=_NextPart_001_01C1E4A4.53EC4B6E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: response to ITU-T SG13

Thanks Giles,

I understand the scenario you are discussing and the = S bit is a legit issue. To re-use your pictures, I was considering when = y=3DOAM alert, not OAM alert under 'y'.

But ultimately I think the problem exists = independently of the OAM alert label. It would also be true if any = reserved label (e.g. explicit V4 label) was used, and suggests that for = stuff to function correctly your implementation should only be looking = one label further into the stack and MUST ignore the S bit. The = existence of reserved labels means that hashing more than one label = deep has problems, and including the S bit has problems. Implementation = wise this may not be the case today, but live and learn ;-)

This preserves any detection properties for any tools = employed regardless of the type used, payload used etc.

cheers
Dave

> -----Original Message-----
> From: Giles Heron [mailto:giles@packetexchange.net= ]
> Sent: Monday, April 15, 2002 2:28 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: neil.2.harrison@bt.com; = kireeti@juniper.net; sob@harvard.edu;
> mpls@UU.NET
> Subject: RE: response to ITU-T SG13
>
>
> On Mon, 2002-04-15 at 16:59, David Allan = wrote:
> > Giles:
> >
> > So then why does whether or not the S bit = is set matter?
>
> perhaps a picture would help?
>
> Say an LSR switches a packet with the following = stack:
>
> |--------|--------|
> | X, S=3D0 | Y, S=3D1 |
> |--------|--------|
>
> It has an L-FIB entry for X that has n equal = cost paths.
>
> What we would like to be able to do is to hash = across the
> entire stack.
> This way a second packet with the following = stack:
>
> |--------|--------|
> | X, S=3D0 | Z, S=3D1 |
> |--------|--------|
>
> can use a different one of the n equal cost = paths (depending
> on the hash
> function and the values of Y and Z of = course).
>
> However the problem arises if you have MPLS OAM = and the
> following packet
> is sent:
>
> |--------|--------|--------|
> | X, S=3D0 | Y, S=3D0 |14, S=3D1 |
> |--------|--------|--------|
>
> If the hash includes the S bit then this will = most likely be sent on a
> different link to the first packet.
>
> Likewise if the hash includes *all* labels then = this will
> most likely be
> sent on a different link.
>
> So what you need is to know a-priori the = minimal depth of stack for
> non-OAM traffic and hash over that number of = labels.  But
> this coarsens
> the granularity of the load balancing, and also = requires
> configuration -
> unless you take the most simplistic approach = and hash only using the
> first label (which barely qualifies as load = balancing).
>
> > Seem to me that both scenarios need to be = covered unless I
> was producing a
> > very specialized implementation....
> > - the current label is also the bottom = label
> > - the current label is not the bottom = label and the label
> underneath may be
> > transport or reserved.
>
> not sure what you mean by "current" = label.  Do you mean the label you
> are switching on?
>
> Giles
>
> > cheers
> > Dave
> >
> >
> > > -----Original Message-----
> > > From: Giles Heron [mailto:giles@packetexchange.net= ]
> > > Sent: Monday, April 15, 2002 11:07 = AM
> > > To: Allan, David = [CAR:NS00:EXCH]
> > > Cc: neil.2.harrison@bt.com; = kireeti@juniper.net; sob@harvard.edu;
> > > mpls@UU.NET
> > > Subject: RE: response to ITU-T = SG13
> > >
> > >
> > > On Mon, 2002-04-15 at 13:40, David = Allan wrote:
> > > > Giles:
> > > >
> > > > A clarification...
> > > >
> > > > > which means that = intermediate LSRs that use a hash to load
> > > > > balance MPLS
> > > > > traffic over equal cost = links/paths have to be careful to
> > > > > exclude the S
> > > > > bit from any hash.
> > > >
> > > > If I am inverse muxing an LSP at = an intermadiate LSR, is
> > > this not on the
> > > > basis of some hashing on the = payload for the current label,
> > > which could be
> > > > more labels...I'm not quite = getting your example.
> > >
> > > effectively yes, you are hashing on = the payload for the
> > > current label -
> > > given that it includes more = labels.  So, for example, an
> LSR switching
> > > based on an LDP-assigned label might = have a set of equal cost
> > > next hops
> > > in its IGP - across which it could = load balance traffic based
> > > on a hash
> > > which includes the draft-martini = label inside that LDP
> assigned label
> > > (though of course it wouldn't know = whether the inner
> label was being
> > > used for draft-martini, for MPLS VPN, = or for something else...)
> > >
> > > Giles
> > >
> > > >
> > > > Dave
> > > >
> > > > 
> > > --
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > Giles Heron    = Principal Network Architect    PacketExchange = Ltd.
> > > ph: +44 7880 = 506185           =    "if you build it they will yawn"
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >
> > >
> --
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Giles Heron    Principal Network = Architect    PacketExchange Ltd.
> ph: +44 7880 = 506185           =    "if you build it they will yawn"
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>

------_=_NextPart_001_01C1E4A4.53EC4B6E-- From owner-mpls@UU.NET Mon Apr 15 13:49:09 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29821 for ; Mon, 15 Apr 2002 13:49:09 -0400 (EDT) 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 QQmksl07361; Mon, 15 Apr 2002 17:47:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksl03712 for mpls-outgoing; Mon, 15 Apr 2002 17:47: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 QQmksl03705 for ; Mon, 15 Apr 2002 17:47:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmksl19420 for ; Mon, 15 Apr 2002 17:46:46 GMT Received: from rincewind.office.packetexchange.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmksl29029 for ; Mon, 15 Apr 2002 17:46:46 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 16xAYY-0004aI-00; Mon, 15 Apr 2002 18:46:22 +0100 Subject: RE: response to ITU-T SG13 From: Giles Heron To: David Allan Cc: neil.2.harrison@bt.com, kireeti@juniper.net, sob@harvard.edu, mpls@UU.NET In-Reply-To: <3549C09B853DD5119B540002A52CDD3402C6E4C3@zcard0ka.ca.nortel.com> References: <3549C09B853DD5119B540002A52CDD3402C6E4C3@zcard0ka.ca.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 15 Apr 2002 18:46:47 +0000 Message-Id: <1018896407.1131.297.camel@gizzer> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-04-15 at 17:38, David Allan wrote: > Thanks Giles, > > I understand the scenario you are discussing and the S bit is a legit issue. > To re-use your pictures, I was considering when y=OAM alert, not OAM alert > under 'y'. > > But ultimately I think the problem exists independently of the OAM alert > label. It would also be true if any reserved label (e.g. explicit V4 label) > was used, and suggests that for stuff to function correctly your > implementation should only be looking one label further into the stack and > MUST ignore the S bit. The existence of reserved labels means that hashing > more than one label deep has problems, and including the S bit has problems. > Implementation wise this may not be the case today, but live and learn ;-) Yes, this "problem" exists for other traffic, but it only matters in the OAM case - where the aim is for the OAM traffic to follow the same path as the user traffic. If I have Internet traffic from PE A to PE B and this follows a different path to a draft-martini circuit from PE A to PE B (i.e. where there is an extra label) then I don't care. All I care about is that all the traffic for a given draft-martini circuit between A and B follows the same path. Giles > This preserves any detection properties for any tools employed regardless of > the type used, payload used etc. > > cheers > Dave > > > -----Original Message----- > > From: Giles Heron [mailto:giles@packetexchange.net] > > Sent: Monday, April 15, 2002 2:28 PM > > To: Allan, David [CAR:NS00:EXCH] > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu; > > mpls@UU.NET > > Subject: RE: response to ITU-T SG13 > > > > > > On Mon, 2002-04-15 at 16:59, David Allan wrote: > > > Giles: > > > > > > So then why does whether or not the S bit is set matter? > > > > perhaps a picture would help? > > > > Say an LSR switches a packet with the following stack: > > > > |--------|--------| > > | X, S=0 | Y, S=1 | > > |--------|--------| > > > > It has an L-FIB entry for X that has n equal cost paths. > > > > What we would like to be able to do is to hash across the > > entire stack. > > This way a second packet with the following stack: > > > > |--------|--------| > > | X, S=0 | Z, S=1 | > > |--------|--------| > > > > can use a different one of the n equal cost paths (depending > > on the hash > > function and the values of Y and Z of course). > > > > However the problem arises if you have MPLS OAM and the > > following packet > > is sent: > > > > |--------|--------|--------| > > | X, S=0 | Y, S=0 |14, S=1 | > > |--------|--------|--------| > > > > If the hash includes the S bit then this will most likely be sent on a > > different link to the first packet. > > > > Likewise if the hash includes *all* labels then this will > > most likely be > > sent on a different link. > > > > So what you need is to know a-priori the minimal depth of stack for > > non-OAM traffic and hash over that number of labels. But > > this coarsens > > the granularity of the load balancing, and also requires > > configuration - > > unless you take the most simplistic approach and hash only using the > > first label (which barely qualifies as load balancing). > > > > > Seem to me that both scenarios need to be covered unless I > > was producing a > > > very specialized implementation.... > > > - the current label is also the bottom label > > > - the current label is not the bottom label and the label > > underneath may be > > > transport or reserved. > > > > not sure what you mean by "current" label. Do you mean the label you > > are switching on? > > > > Giles > > > > > cheers > > > Dave > > > > > > > > > > -----Original Message----- > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > Sent: Monday, April 15, 2002 11:07 AM > > > > To: Allan, David [CAR:NS00:EXCH] > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu; > > > > mpls@UU.NET > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > On Mon, 2002-04-15 at 13:40, David Allan wrote: > > > > > Giles: > > > > > > > > > > A clarification... > > > > > > > > > > > which means that intermediate LSRs that use a hash to load > > > > > > balance MPLS > > > > > > traffic over equal cost links/paths have to be careful to > > > > > > exclude the S > > > > > > bit from any hash. > > > > > > > > > > If I am inverse muxing an LSP at an intermadiate LSR, is > > > > this not on the > > > > > basis of some hashing on the payload for the current label, > > > > which could be > > > > > more labels...I'm not quite getting your example. > > > > > > > > effectively yes, you are hashing on the payload for the > > > > current label - > > > > given that it includes more labels. So, for example, an > > LSR switching > > > > based on an LDP-assigned label might have a set of equal cost > > > > next hops > > > > in its IGP - across which it could load balance traffic based > > > > on a hash > > > > which includes the draft-martini label inside that LDP > > assigned label > > > > (though of course it wouldn't know whether the inner > > label was being > > > > used for draft-martini, for MPLS VPN, or for something else...) > > > > > > > > Giles > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > -- > > > > ================================================================= > > > > Giles Heron Principal Network Architect PacketExchange Ltd. > > > > ph: +44 7880 506185 "if you build it they will yawn" > > > > ================================================================= > > > > > > > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Mon Apr 15 14:02:04 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00363 for ; Mon, 15 Apr 2002 14:02:03 -0400 (EDT) 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 QQmksm29482; Mon, 15 Apr 2002 18:01:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksm08068 for mpls-outgoing; Mon, 15 Apr 2002 18:00:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmksm07881 for ; Mon, 15 Apr 2002 18:00:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmksl02118 for ; Mon, 15 Apr 2002 17:59:45 GMT Received: from zcars04e.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQmksl19290 for ; Mon, 15 Apr 2002 17:59:44 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FHxeO05263; Mon, 15 Apr 2002 13:59:40 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJA33KD>; Mon, 15 Apr 2002 13:59:40 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402C6E52F@zcard0ka.ca.nortel.com> From: "David Allan" To: Giles Heron Cc: mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 13:59:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4A7.50852E02" 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_01C1E4A7.50852E02 Content-Type: text/plain; charset="iso-8859-1" My comment was that this would be true for any detection/diagnotic tool discussed. e.g. use of explicit V4 label to permit ICMP ping to be used for non-IP LSPs or use GTTP to explore non-IP LSPs or to measure anything such as DSCP RTT. That to me is sufficient reason to suggest that in a load sharing scenario, the answer should be the same for the combination of label and exp bits. S bit and TTL MUST be excluded.... cheers Dave > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Monday, April 15, 2002 2:47 PM > To: Allan, David [CAR:NS00:EXCH] > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu; > mpls@UU.NET > Subject: RE: response to ITU-T SG13 > > > On Mon, 2002-04-15 at 17:38, David Allan wrote: > > Thanks Giles, > > > > I understand the scenario you are discussing and the S bit > is a legit issue. > > To re-use your pictures, I was considering when y=OAM > alert, not OAM alert > > under 'y'. > > > > But ultimately I think the problem exists independently of > the OAM alert > > label. It would also be true if any reserved label (e.g. > explicit V4 label) > > was used, and suggests that for stuff to function correctly your > > implementation should only be looking one label further > into the stack and > > MUST ignore the S bit. The existence of reserved labels > means that hashing > > more than one label deep has problems, and including the S > bit has problems. > > Implementation wise this may not be the case today, but > live and learn ;-) > > Yes, this "problem" exists for other traffic, but it only > matters in the > OAM case - where the aim is for the OAM traffic to follow the > same path > as the user traffic. > > If I have Internet traffic from PE A to PE B and this follows a > different path to a draft-martini circuit from PE A to PE B > (i.e. where > there is an extra label) then I don't care. All I care about is that > all the traffic for a given draft-martini circuit between A and B > follows the same path. > > Giles > > > This preserves any detection properties for any tools > employed regardless of > > the type used, payload used etc. > > > > cheers > > Dave > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > Sent: Monday, April 15, 2002 2:28 PM > > > To: Allan, David [CAR:NS00:EXCH] > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu; > > > mpls@UU.NET > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > On Mon, 2002-04-15 at 16:59, David Allan wrote: > > > > Giles: > > > > > > > > So then why does whether or not the S bit is set matter? > > > > > > perhaps a picture would help? > > > > > > Say an LSR switches a packet with the following stack: > > > > > > |--------|--------| > > > | X, S=0 | Y, S=1 | > > > |--------|--------| > > > > > > It has an L-FIB entry for X that has n equal cost paths. > > > > > > What we would like to be able to do is to hash across the > > > entire stack. > > > This way a second packet with the following stack: > > > > > > |--------|--------| > > > | X, S=0 | Z, S=1 | > > > |--------|--------| > > > > > > can use a different one of the n equal cost paths (depending > > > on the hash > > > function and the values of Y and Z of course). > > > > > > However the problem arises if you have MPLS OAM and the > > > following packet > > > is sent: > > > > > > |--------|--------|--------| > > > | X, S=0 | Y, S=0 |14, S=1 | > > > |--------|--------|--------| > > > > > > If the hash includes the S bit then this will most likely > be sent on a > > > different link to the first packet. > > > > > > Likewise if the hash includes *all* labels then this will > > > most likely be > > > sent on a different link. > > > > > > So what you need is to know a-priori the minimal depth of > stack for > > > non-OAM traffic and hash over that number of labels. But > > > this coarsens > > > the granularity of the load balancing, and also requires > > > configuration - > > > unless you take the most simplistic approach and hash > only using the > > > first label (which barely qualifies as load balancing). > > > > > > > Seem to me that both scenarios need to be covered unless I > > > was producing a > > > > very specialized implementation.... > > > > - the current label is also the bottom label > > > > - the current label is not the bottom label and the label > > > underneath may be > > > > transport or reserved. > > > > > > not sure what you mean by "current" label. Do you mean > the label you > > > are switching on? > > > > > > Giles > > > > > > > cheers > > > > Dave > > > > > > > > > > > > > -----Original Message----- > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > Sent: Monday, April 15, 2002 11:07 AM > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > sob@harvard.edu; > > > > > mpls@UU.NET > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 13:40, David Allan wrote: > > > > > > Giles: > > > > > > > > > > > > A clarification... > > > > > > > > > > > > > which means that intermediate LSRs that use a > hash to load > > > > > > > balance MPLS > > > > > > > traffic over equal cost links/paths have to be careful to > > > > > > > exclude the S > > > > > > > bit from any hash. > > > > > > > > > > > > If I am inverse muxing an LSP at an intermadiate LSR, is > > > > > this not on the > > > > > > basis of some hashing on the payload for the current label, > > > > > which could be > > > > > > more labels...I'm not quite getting your example. > > > > > > > > > > effectively yes, you are hashing on the payload for the > > > > > current label - > > > > > given that it includes more labels. So, for example, an > > > LSR switching > > > > > based on an LDP-assigned label might have a set of equal cost > > > > > next hops > > > > > in its IGP - across which it could load balance traffic based > > > > > on a hash > > > > > which includes the draft-martini label inside that LDP > > > assigned label > > > > > (though of course it wouldn't know whether the inner > > > label was being > > > > > used for draft-martini, for MPLS VPN, or for > something else...) > > > > > > > > > > Giles > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > -- > > > > > > ================================================================= > > > > > Giles Heron Principal Network Architect > PacketExchange Ltd. > > > > > ph: +44 7880 506185 "if you build it > they will yawn" > > > > > > ================================================================= > > > > > > > > > > > > > -- > > > ================================================================= > > > Giles Heron Principal Network Architect PacketExchange Ltd. > > > ph: +44 7880 506185 "if you build it they will yawn" > > > ================================================================= > > > > > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > > ------_=_NextPart_001_01C1E4A7.50852E02 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: response to ITU-T SG13

My comment was that this would be true for any = detection/diagnotic tool discussed. e.g. use of explicit V4 label to = permit ICMP ping to be used for non-IP LSPs or use GTTP to explore = non-IP LSPs or to measure anything such as DSCP RTT.

That to me is sufficient reason to suggest that in a = load sharing scenario, the answer should be the same for the = combination of label and exp bits. S bit and TTL MUST be = excluded....

cheers
Dave



> -----Original Message-----
> From: Giles Heron [mailto:giles@packetexchange.net= ]
> Sent: Monday, April 15, 2002 2:47 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: neil.2.harrison@bt.com; = kireeti@juniper.net; sob@harvard.edu;
> mpls@UU.NET
> Subject: RE: response to ITU-T SG13
>
>
> On Mon, 2002-04-15 at 17:38, David Allan = wrote:
> > Thanks Giles,
> >
> > I understand the scenario you are = discussing and the S bit
> is a legit issue.
> > To re-use your pictures, I was considering = when y=3DOAM
> alert, not OAM alert
> > under 'y'.
> >
> > But ultimately I think the problem exists = independently of
> the OAM alert
> > label. It would also be true if any = reserved label (e.g.
> explicit V4 label)
> > was used, and suggests that for stuff to = function correctly your
> > implementation should only be looking one = label further
> into the stack and
> > MUST ignore the S bit. The existence of = reserved labels
> means that hashing
> > more than one label deep has problems, and = including the S
> bit has problems.
> > Implementation wise this may not be the = case today, but
> live and learn ;-)
>
> Yes, this "problem" exists for other = traffic, but it only
> matters in the
> OAM case - where the aim is for the OAM traffic = to follow the
> same path
> as the user traffic.
>
> If I have Internet traffic from PE A to PE B = and this follows a
> different path to a draft-martini circuit from = PE A to PE B
> (i.e. where
> there is an extra label) then I don't = care.  All I care about is that
> all the traffic for a given draft-martini = circuit between A and B
> follows the same path.
>
> Giles
>
> > This preserves any detection properties = for any tools
> employed regardless of
> > the type used, payload used etc.
> >
> > cheers
> > Dave
> >
> > > -----Original Message-----
> > > From: Giles Heron [mailto:giles@packetexchange.net= ]
> > > Sent: Monday, April 15, 2002 2:28 = PM
> > > To: Allan, David = [CAR:NS00:EXCH]
> > > Cc: neil.2.harrison@bt.com; = kireeti@juniper.net; sob@harvard.edu;
> > > mpls@UU.NET
> > > Subject: RE: response to ITU-T = SG13
> > >
> > >
> > > On Mon, 2002-04-15 at 16:59, David = Allan wrote:
> > > > Giles:
> > > >
> > > > So then why does whether or not = the S bit is set matter?
> > >
> > > perhaps a picture would help?
> > >
> > > Say an LSR switches a packet with the = following stack:
> > >
> > > |--------|--------|
> > > | X, S=3D0 | Y, S=3D1 |
> > > |--------|--------|
> > >
> > > It has an L-FIB entry for X that has = n equal cost paths.
> > >
> > > What we would like to be able to do = is to hash across the
> > > entire stack.
> > > This way a second packet with the = following stack:
> > >
> > > |--------|--------|
> > > | X, S=3D0 | Z, S=3D1 |
> > > |--------|--------|
> > >
> > > can use a different one of the n = equal cost paths (depending
> > > on the hash
> > > function and the values of Y and Z of = course).
> > >
> > > However the problem arises if you = have MPLS OAM and the
> > > following packet
> > > is sent:
> > >
> > > |--------|--------|--------|
> > > | X, S=3D0 | Y, S=3D0 |14, S=3D1 = |
> > > |--------|--------|--------|
> > >
> > > If the hash includes the S bit then = this will most likely
> be sent on a
> > > different link to the first = packet.
> > >
> > > Likewise if the hash includes *all* = labels then this will
> > > most likely be
> > > sent on a different link.
> > >
> > > So what you need is to know a-priori = the minimal depth of
> stack for
> > > non-OAM traffic and hash over that = number of labels.  But
> > > this coarsens
> > > the granularity of the load = balancing, and also requires
> > > configuration -
> > > unless you take the most simplistic = approach and hash
> only using the
> > > first label (which barely qualifies = as load balancing).
> > >
> > > > Seem to me that both scenarios = need to be covered unless I
> > > was producing a
> > > > very specialized = implementation....
> > > > - the current label is also the = bottom label
> > > > - the current label is not the = bottom label and the label
> > > underneath may be
> > > > transport or reserved.
> > >
> > > not sure what you mean by = "current" label.  Do you mean
> the label you
> > > are switching on?
> > >
> > > Giles
> > >
> > > > cheers
> > > > Dave
> > > >
> > > >
> > > > > -----Original = Message-----
> > > > > From: Giles Heron [mailto:giles@packetexchange.net= ]
> > > > > Sent: Monday, April 15, = 2002 11:07 AM
> > > > > To: Allan, David = [CAR:NS00:EXCH]
> > > > > Cc: neil.2.harrison@bt.com; = kireeti@juniper.net;
> sob@harvard.edu;
> > > > > mpls@UU.NET
> > > > > Subject: RE: response to = ITU-T SG13
> > > > >
> > > > >
> > > > > On Mon, 2002-04-15 at = 13:40, David Allan wrote:
> > > > > > Giles:
> > > > > >
> > > > > > A = clarification...
> > > > > >
> > > > > > > which means that = intermediate LSRs that use a
> hash to load
> > > > > > > balance = MPLS
> > > > > > > traffic over = equal cost links/paths have to be careful to
> > > > > > > exclude the = S
> > > > > > > bit from any = hash.
> > > > > >
> > > > > > If I am inverse muxing = an LSP at an intermadiate LSR, is
> > > > > this not on the
> > > > > > basis of some hashing = on the payload for the current label,
> > > > > which could be
> > > > > > more labels...I'm not = quite getting your example.
> > > > >
> > > > > effectively yes, you are = hashing on the payload for the
> > > > > current label -
> > > > > given that it includes more = labels.  So, for example, an
> > > LSR switching
> > > > > based on an LDP-assigned = label might have a set of equal cost
> > > > > next hops
> > > > > in its IGP - across which = it could load balance traffic based
> > > > > on a hash
> > > > > which includes the = draft-martini label inside that LDP
> > > assigned label
> > > > > (though of course it = wouldn't know whether the inner
> > > label was being
> > > > > used for draft-martini, for = MPLS VPN, or for
> something else...)
> > > > >
> > > > > Giles
> > > > >
> > > > > >
> > > > > > Dave
> > > > > >
> > > > > > 
> > > > > --
> > > > >
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > Giles = Heron    Principal Network Architect    =
> PacketExchange Ltd.
> > > > > ph: +44 7880 = 506185           =    "if you build it
> they will yawn"
> > > > >
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > >
> > > > >
> > > --
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > Giles Heron    = Principal Network Architect    PacketExchange = Ltd.
> > > ph: +44 7880 = 506185           =    "if you build it they will yawn"
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >
> > >
> --
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Giles Heron    Principal Network = Architect    PacketExchange Ltd.
> ph: +44 7880 = 506185           =    "if you build it they will yawn"
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>

------_=_NextPart_001_01C1E4A7.50852E02-- From owner-mpls@UU.NET Mon Apr 15 14:12:06 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00716 for ; Mon, 15 Apr 2002 14:12:06 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmksm05072; Mon, 15 Apr 2002 18:11:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksm25816 for mpls-outgoing; Mon, 15 Apr 2002 18:10: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 QQmksm25684 for ; Mon, 15 Apr 2002 18:10: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 QQmksm05705 for ; Mon, 15 Apr 2002 18:10:22 GMT Received: from server.nayna.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 67-89-191-66.customer.algx.net [67.89.191.66]) id QQmksm03823 for ; Mon, 15 Apr 2002 18:10:22 GMT Received: from relay.nayna.com (relay.nayna.com [10.0.128.11]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA13928; Mon, 15 Apr 2002 11:10:21 -0700 Received: from nayna.com (dhcp-131-104.nayna.com [10.0.131.104]) by relay.nayna.com (8.9.3/8.9.3) with ESMTP id LAA19086; Mon, 15 Apr 2002 11:09:51 -0700 Message-ID: <3CBB1708.BE7C32E8@nayna.com> Date: Mon, 15 Apr 2002 11:08:08 -0700 From: Sudheer Dharanikota X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: David Charlap CC: mpls@UU.NET Subject: Re: SE style in optical neyworks References: <20020415045551.94063.qmail@web13705.mail.yahoo.com> <3CBADD18.939B522A@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi David: David Charlap wrote: > gmpls gmpls wrote: > > > > I need some more clarification on this regard. > > The OIF UNI v1.0 standard says UNI only supports the > > FF style of reservation. Since Optical network which > > main purpose is to provide service for UNI clients, > > would have to support same set reservation styles > > which UNI needs. > > > > So Is there a need for supporting SE style of > > reservation in the optical domain? > > What's the point? > > In an optical network, you are signaling wavelengths or time slices. > How could you conceivably have two time-slices share resources? Or two > wavelengths? Only to imply that a time-slice can be allocated to one of the *backup* paths when a primary path fails. - sudheer > > > The whole concept of SE on optical networks doesn't make sense in the > first place. > > -- David From owner-mpls@UU.NET Mon Apr 15 14:20:39 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00961 for ; Mon, 15 Apr 2002 14:20:39 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmksn15804; Mon, 15 Apr 2002 18:19:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksn27349 for mpls-outgoing; Mon, 15 Apr 2002 18:19: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 QQmksn27340 for ; Mon, 15 Apr 2002 18:19:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmksn27181 for ; Mon, 15 Apr 2002 18:17:07 GMT Received: from rincewind.office.packetexchange.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmksn11935 for ; Mon, 15 Apr 2002 18:17:06 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 16xB24-0004dQ-00; Mon, 15 Apr 2002 19:16:52 +0100 Subject: RE: response to ITU-T SG13 From: Giles Heron To: Shahram Davari Cc: neil.2.harrison@bt.com, kireeti@juniper.net, sob@harvard.edu, mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE84A6F9@nt-exch-yow.pmc-sierra.bc.ca> References: <4B6D09F3B826D411A67300D0B706EFDE84A6F9@nt-exch-yow.pmc-sierra.bc.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 15 Apr 2002 19:17:17 +0000 Message-Id: <1018898238.1131.328.camel@gizzer> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-04-15 at 17:41, Shahram Davari wrote: > Hi Giles, > > > > which means that intermediate LSRs that use a hash to load > > balance MPLS > > traffic over equal cost links/paths have to be careful to > > exclude the S > > bit from any hash. > > An more logical method is for the hash result > to point to the same region of the hash key > when S=0 or S=1 in the bottom-most label. but if S=0 then it isn't the bottom-most label? > > > > I'm not sure that this is the case for all current implementations... > > I don't think specific implementations should be a concern for a standard > body such as IETF. You could always find a specific implementations that can't > support a new function. Any objection regarding backward compatibility should be > based on a standard. AFAIK there is no standard for hash-based ECMP MPLS switching. no, of course there is no standard - this is something that happens inside the switch. Every vendor will implement this as they see fit. but IMO we should be trying to avoid inventing things that break existing hardware in a different part of the network - or at least to note the caveats when we do so. > > In fact this also would seem to imply that you have to hash > > over a fixed > > number of labels (to ensure that both the OAM traffic and the user > > traffic get the same hash value). This coarsens the load balancing > > granularity somewhat :( > > If only 0.1% of a single label range is used, you could still select up to ~1000 different flows using that "single" label. I am not sure of how coarse this is!!! that depends on the size of the flows. My aim is to avoid hashing at a granularity where all traffic to a given PE has to end up on a given link in the network. Even with OC-192c links this may be a problem if there are two large and heavily loaded PEs :( > > The alternatives would be either to preclude hashed > > load-balancing or to > > require OAM-aware core LSRs. Neither of these options is acceptable > > IMO. > > > > Giles, even MPLS-ping that is carried over non-IP carrying LSP uses > an extra label (Explicit Null label). So I don't think you can find > any solution that can satisfy the restricted implementations in your boxes. True, LSP ping will require the extra label for non-IP carrying LSPs. In fact I don't think there is a solution to this that is internal to the MPLS network and that works in the presence of load-balancing that hashes different non-IP carrying LSPs onto different links unless you: 1) know the stack depth a-priori, OR 2) write a hash algorithm that hashes (label Y, S=1) onto the same link as label [label Y, S=0][OAM, S=1] (or [Y, S=0][Explicit NULL, S=1]). In any case I'm not sure that using phrases like "restricted implementations in your boxes" is helpful when I am describing a general problem with MPLS OAM that Neil, for one, has the grace to concede? Giles -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Mon Apr 15 14:21:25 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00994 for ; Mon, 15 Apr 2002 14:21:25 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmksn18064; Mon, 15 Apr 2002 18:20:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksn27368 for mpls-outgoing; Mon, 15 Apr 2002 18:20:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmksn27357 for ; Mon, 15 Apr 2002 18:19:55 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 QQmksn21561 for ; Mon, 15 Apr 2002 18:19:31 GMT Received: from rincewind.office.packetexchange.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmksn16957 for ; Mon, 15 Apr 2002 18:19:31 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 16xB4V-0004df-00; Mon, 15 Apr 2002 19:19:23 +0100 Subject: RE: response to ITU-T SG13 From: Giles Heron To: David Allan Cc: mpls@UU.NET In-Reply-To: <3549C09B853DD5119B540002A52CDD3402C6E52F@zcard0ka.ca.nortel.com> References: <3549C09B853DD5119B540002A52CDD3402C6E52F@zcard0ka.ca.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 15 Apr 2002 19:19:48 +0000 Message-Id: <1018898388.1130.332.camel@gizzer> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-04-15 at 17:59, David Allan wrote: > My comment was that this would be true for any detection/diagnotic tool > discussed. e.g. use of explicit V4 label to permit ICMP ping to be used for > non-IP LSPs or use GTTP to explore non-IP LSPs or to measure anything such > as DSCP RTT. oh, okay. > That to me is sufficient reason to suggest that in a load sharing scenario, > the answer should be the same for the combination of label and exp bits. S > bit and TTL MUST be excluded.... in fact it should probably just be the label (and not the EXP bits) as the EXP bits may be describing different drop precedences within the same queue? but we still have the problem of needing to know the stack depth a-priori (or of figuring out a way to make [Y, S=1] hash to the same link as [Y, S=0][OAM, S=1]). Giles > cheers > Dave > > > > > -----Original Message----- > > From: Giles Heron [mailto:giles@packetexchange.net] > > Sent: Monday, April 15, 2002 2:47 PM > > To: Allan, David [CAR:NS00:EXCH] > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu; > > mpls@UU.NET > > Subject: RE: response to ITU-T SG13 > > > > > > On Mon, 2002-04-15 at 17:38, David Allan wrote: > > > Thanks Giles, > > > > > > I understand the scenario you are discussing and the S bit > > is a legit issue. > > > To re-use your pictures, I was considering when y=OAM > > alert, not OAM alert > > > under 'y'. > > > > > > But ultimately I think the problem exists independently of > > the OAM alert > > > label. It would also be true if any reserved label (e.g. > > explicit V4 label) > > > was used, and suggests that for stuff to function correctly your > > > implementation should only be looking one label further > > into the stack and > > > MUST ignore the S bit. The existence of reserved labels > > means that hashing > > > more than one label deep has problems, and including the S > > bit has problems. > > > Implementation wise this may not be the case today, but > > live and learn ;-) > > > > Yes, this "problem" exists for other traffic, but it only > > matters in the > > OAM case - where the aim is for the OAM traffic to follow the > > same path > > as the user traffic. > > > > If I have Internet traffic from PE A to PE B and this follows a > > different path to a draft-martini circuit from PE A to PE B > > (i.e. where > > there is an extra label) then I don't care. All I care about is that > > all the traffic for a given draft-martini circuit between A and B > > follows the same path. > > > > Giles > > > > > This preserves any detection properties for any tools > > employed regardless of > > > the type used, payload used etc. > > > > > > cheers > > > Dave > > > > > > > -----Original Message----- > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > Sent: Monday, April 15, 2002 2:28 PM > > > > To: Allan, David [CAR:NS00:EXCH] > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu; > > > > mpls@UU.NET > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > On Mon, 2002-04-15 at 16:59, David Allan wrote: > > > > > Giles: > > > > > > > > > > So then why does whether or not the S bit is set matter? > > > > > > > > perhaps a picture would help? > > > > > > > > Say an LSR switches a packet with the following stack: > > > > > > > > |--------|--------| > > > > | X, S=0 | Y, S=1 | > > > > |--------|--------| > > > > > > > > It has an L-FIB entry for X that has n equal cost paths. > > > > > > > > What we would like to be able to do is to hash across the > > > > entire stack. > > > > This way a second packet with the following stack: > > > > > > > > |--------|--------| > > > > | X, S=0 | Z, S=1 | > > > > |--------|--------| > > > > > > > > can use a different one of the n equal cost paths (depending > > > > on the hash > > > > function and the values of Y and Z of course). > > > > > > > > However the problem arises if you have MPLS OAM and the > > > > following packet > > > > is sent: > > > > > > > > |--------|--------|--------| > > > > | X, S=0 | Y, S=0 |14, S=1 | > > > > |--------|--------|--------| > > > > > > > > If the hash includes the S bit then this will most likely > > be sent on a > > > > different link to the first packet. > > > > > > > > Likewise if the hash includes *all* labels then this will > > > > most likely be > > > > sent on a different link. > > > > > > > > So what you need is to know a-priori the minimal depth of > > stack for > > > > non-OAM traffic and hash over that number of labels. But > > > > this coarsens > > > > the granularity of the load balancing, and also requires > > > > configuration - > > > > unless you take the most simplistic approach and hash > > only using the > > > > first label (which barely qualifies as load balancing). > > > > > > > > > Seem to me that both scenarios need to be covered unless I > > > > was producing a > > > > > very specialized implementation.... > > > > > - the current label is also the bottom label > > > > > - the current label is not the bottom label and the label > > > > underneath may be > > > > > transport or reserved. > > > > > > > > not sure what you mean by "current" label. Do you mean > > the label you > > > > are switching on? > > > > > > > > Giles > > > > > > > > > cheers > > > > > Dave > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > > Sent: Monday, April 15, 2002 11:07 AM > > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > > sob@harvard.edu; > > > > > > mpls@UU.NET > > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 13:40, David Allan wrote: > > > > > > > Giles: > > > > > > > > > > > > > > A clarification... > > > > > > > > > > > > > > > which means that intermediate LSRs that use a > > hash to load > > > > > > > > balance MPLS > > > > > > > > traffic over equal cost links/paths have to be careful to > > > > > > > > exclude the S > > > > > > > > bit from any hash. > > > > > > > > > > > > > > If I am inverse muxing an LSP at an intermadiate LSR, is > > > > > > this not on the > > > > > > > basis of some hashing on the payload for the current label, > > > > > > which could be > > > > > > > more labels...I'm not quite getting your example. > > > > > > > > > > > > effectively yes, you are hashing on the payload for the > > > > > > current label - > > > > > > given that it includes more labels. So, for example, an > > > > LSR switching > > > > > > based on an LDP-assigned label might have a set of equal cost > > > > > > next hops > > > > > > in its IGP - across which it could load balance traffic based > > > > > > on a hash > > > > > > which includes the draft-martini label inside that LDP > > > > assigned label > > > > > > (though of course it wouldn't know whether the inner > > > > label was being > > > > > > used for draft-martini, for MPLS VPN, or for > > something else...) > > > > > > > > > > > > Giles > > > > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > ================================================================= > > > > > > Giles Heron Principal Network Architect > > PacketExchange Ltd. > > > > > > ph: +44 7880 506185 "if you build it > > they will yawn" > > > > > > > > ================================================================= > > > > > > > > > > > > > > > > -- > > > > ================================================================= > > > > Giles Heron Principal Network Architect PacketExchange Ltd. > > > > ph: +44 7880 506185 "if you build it they will yawn" > > > > ================================================================= > > > > > > > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Mon Apr 15 14:21:51 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01041 for ; Mon, 15 Apr 2002 14:21:51 -0400 (EDT) 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 QQmksn00474; Mon, 15 Apr 2002 18:21:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksn27412 for mpls-outgoing; Mon, 15 Apr 2002 18:20:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmksn27405 for ; Mon, 15 Apr 2002 18:20:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmksn22194 for ; Mon, 15 Apr 2002 18:19: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 QQmksn28321 for ; Mon, 15 Apr 2002 18:19: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 OAA11346; Mon, 15 Apr 2002 14:19:37 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA03228; Mon, 15 Apr 2002 14:19:37 -0400 (EDT) Message-Id: <200204151819.OAA03228@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Shahram Davari cc: "'Scott Bradner'" , mpls@UU.NET Subject: Re: response to ITU-T SG13 In-reply-to: Your message of Mon, 15 Apr 2002 07:43:06 -0700. <4B6D09F3B826D411A67300D0B706EFDE84A6F2@nt-exch-yow.pmc-sierra.bc.ca> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 15 Apr 2002 14:19:37 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Shahram> Some vendors may have implemented their MPLS data-plane in hardware Shahram> and some in software. Why should a vendor's implementation be a Shahram> concern for a standard body such as IETF? Shahram> I don't think specific implementations should be a concern for a Shahram> standard body such as IETF. You could always find a specific Shahram> implementations that can't support a new function. Any objection Shahram> regarding backward compatibility should be based on a standard. Are you saying that the characteristics of existing deployments and implementations should deliberately be ignored by the WG as it makes its decisions? I'd have to disagree. If one is trying to produce solutions which solve real problems for real people, and which will be adopted by the real market, then one is well-advised to take the existing situation into consideration. I am not aware of any IETF policy or precedent that says to ignore existing implementations or deployments. From owner-mpls@UU.NET Mon Apr 15 14:27:25 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01263 for ; Mon, 15 Apr 2002 14:27:24 -0400 (EDT) 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 QQmksn08645; Mon, 15 Apr 2002 18:26:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksn27770 for mpls-outgoing; Mon, 15 Apr 2002 18:26:03 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmksn27738 for ; Mon, 15 Apr 2002 18:25: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 QQmksn05676 for ; Mon, 15 Apr 2002 18:25:10 GMT Received: from zcars04e.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04e.nortelnetworks.com [47.129.242.56]) id QQmksn06730 for ; Mon, 15 Apr 2002 18:25:10 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FIP6O07899; Mon, 15 Apr 2002 14:25:06 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJA3PDK>; Mon, 15 Apr 2002 14:25:06 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402C6E59C@zcard0ka.ca.nortel.com> From: "David Allan" To: Giles Heron Cc: mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 14:25:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4AA.DDDF76EC" 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_01C1E4AA.DDDF76EC Content-Type: text/plain; charset="iso-8859-1" Giles: Agreed that EXP drop preference is an issue. Looks like we may converge on the label only... IMHO some of this should be captured in sect 3.12 of 3031 when it comes around. I thought [y, s=1] hashed the same as [y, s=0] if we simply skipped 's' ;-) later Dave > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Monday, April 15, 2002 3:20 PM > To: Allan, David [CAR:NS00:EXCH] > Cc: mpls@UU.NET > Subject: RE: response to ITU-T SG13 > > > On Mon, 2002-04-15 at 17:59, David Allan wrote: > > My comment was that this would be true for any > detection/diagnotic tool > > discussed. e.g. use of explicit V4 label to permit ICMP > ping to be used for > > non-IP LSPs or use GTTP to explore non-IP LSPs or to > measure anything such > > as DSCP RTT. > > oh, okay. > > > That to me is sufficient reason to suggest that in a load > sharing scenario, > > the answer should be the same for the combination of label > and exp bits. S > > bit and TTL MUST be excluded.... > > in fact it should probably just be the label (and not the EXP bits) as > the EXP bits may be describing different drop precedences within the > same queue? > > but we still have the problem of needing to know the stack depth > a-priori (or of figuring out a way to make [Y, S=1] hash to the same > link as [Y, S=0][OAM, S=1]). > > Giles > > > cheers > > Dave > > > > > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > Sent: Monday, April 15, 2002 2:47 PM > > > To: Allan, David [CAR:NS00:EXCH] > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu; > > > mpls@UU.NET > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > On Mon, 2002-04-15 at 17:38, David Allan wrote: > > > > Thanks Giles, > > > > > > > > I understand the scenario you are discussing and the S bit > > > is a legit issue. > > > > To re-use your pictures, I was considering when y=OAM > > > alert, not OAM alert > > > > under 'y'. > > > > > > > > But ultimately I think the problem exists independently of > > > the OAM alert > > > > label. It would also be true if any reserved label (e.g. > > > explicit V4 label) > > > > was used, and suggests that for stuff to function correctly your > > > > implementation should only be looking one label further > > > into the stack and > > > > MUST ignore the S bit. The existence of reserved labels > > > means that hashing > > > > more than one label deep has problems, and including the S > > > bit has problems. > > > > Implementation wise this may not be the case today, but > > > live and learn ;-) > > > > > > Yes, this "problem" exists for other traffic, but it only > > > matters in the > > > OAM case - where the aim is for the OAM traffic to follow the > > > same path > > > as the user traffic. > > > > > > If I have Internet traffic from PE A to PE B and this follows a > > > different path to a draft-martini circuit from PE A to PE B > > > (i.e. where > > > there is an extra label) then I don't care. All I care > about is that > > > all the traffic for a given draft-martini circuit between A and B > > > follows the same path. > > > > > > Giles > > > > > > > This preserves any detection properties for any tools > > > employed regardless of > > > > the type used, payload used etc. > > > > > > > > cheers > > > > Dave > > > > > > > > > -----Original Message----- > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > Sent: Monday, April 15, 2002 2:28 PM > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > sob@harvard.edu; > > > > > mpls@UU.NET > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 16:59, David Allan wrote: > > > > > > Giles: > > > > > > > > > > > > So then why does whether or not the S bit is set matter? > > > > > > > > > > perhaps a picture would help? > > > > > > > > > > Say an LSR switches a packet with the following stack: > > > > > > > > > > |--------|--------| > > > > > | X, S=0 | Y, S=1 | > > > > > |--------|--------| > > > > > > > > > > It has an L-FIB entry for X that has n equal cost paths. > > > > > > > > > > What we would like to be able to do is to hash across the > > > > > entire stack. > > > > > This way a second packet with the following stack: > > > > > > > > > > |--------|--------| > > > > > | X, S=0 | Z, S=1 | > > > > > |--------|--------| > > > > > > > > > > can use a different one of the n equal cost paths (depending > > > > > on the hash > > > > > function and the values of Y and Z of course). > > > > > > > > > > However the problem arises if you have MPLS OAM and the > > > > > following packet > > > > > is sent: > > > > > > > > > > |--------|--------|--------| > > > > > | X, S=0 | Y, S=0 |14, S=1 | > > > > > |--------|--------|--------| > > > > > > > > > > If the hash includes the S bit then this will most likely > > > be sent on a > > > > > different link to the first packet. > > > > > > > > > > Likewise if the hash includes *all* labels then this will > > > > > most likely be > > > > > sent on a different link. > > > > > > > > > > So what you need is to know a-priori the minimal depth of > > > stack for > > > > > non-OAM traffic and hash over that number of labels. But > > > > > this coarsens > > > > > the granularity of the load balancing, and also requires > > > > > configuration - > > > > > unless you take the most simplistic approach and hash > > > only using the > > > > > first label (which barely qualifies as load balancing). > > > > > > > > > > > Seem to me that both scenarios need to be covered unless I > > > > > was producing a > > > > > > very specialized implementation.... > > > > > > - the current label is also the bottom label > > > > > > - the current label is not the bottom label and the label > > > > > underneath may be > > > > > > transport or reserved. > > > > > > > > > > not sure what you mean by "current" label. Do you mean > > > the label you > > > > > are switching on? > > > > > > > > > > Giles > > > > > > > > > > > cheers > > > > > > Dave > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > > > Sent: Monday, April 15, 2002 11:07 AM > > > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > > > sob@harvard.edu; > > > > > > > mpls@UU.NET > > > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 13:40, David Allan wrote: > > > > > > > > Giles: > > > > > > > > > > > > > > > > A clarification... > > > > > > > > > > > > > > > > > which means that intermediate LSRs that use a > > > hash to load > > > > > > > > > balance MPLS > > > > > > > > > traffic over equal cost links/paths have to > be careful to > > > > > > > > > exclude the S > > > > > > > > > bit from any hash. > > > > > > > > > > > > > > > > If I am inverse muxing an LSP at an > intermadiate LSR, is > > > > > > > this not on the > > > > > > > > basis of some hashing on the payload for the > current label, > > > > > > > which could be > > > > > > > > more labels...I'm not quite getting your example. > > > > > > > > > > > > > > effectively yes, you are hashing on the payload for the > > > > > > > current label - > > > > > > > given that it includes more labels. So, for example, an > > > > > LSR switching > > > > > > > based on an LDP-assigned label might have a set > of equal cost > > > > > > > next hops > > > > > > > in its IGP - across which it could load balance > traffic based > > > > > > > on a hash > > > > > > > which includes the draft-martini label inside that LDP > > > > > assigned label > > > > > > > (though of course it wouldn't know whether the inner > > > > > label was being > > > > > > > used for draft-martini, for MPLS VPN, or for > > > something else...) > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > ================================================================= > > > > > > > Giles Heron Principal Network Architect > > > PacketExchange Ltd. > > > > > > > ph: +44 7880 506185 "if you build it > > > they will yawn" > > > > > > > > > > ================================================================= > > > > > > > > > > > > > > > > > > > -- > > > > > > ================================================================= > > > > > Giles Heron Principal Network Architect > PacketExchange Ltd. > > > > > ph: +44 7880 506185 "if you build it > they will yawn" > > > > > > ================================================================= > > > > > > > > > > > > > -- > > > ================================================================= > > > Giles Heron Principal Network Architect PacketExchange Ltd. > > > ph: +44 7880 506185 "if you build it they will yawn" > > > ================================================================= > > > > > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= > > ------_=_NextPart_001_01C1E4AA.DDDF76EC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: response to ITU-T SG13

Giles:

Agreed that EXP drop preference is an issue. Looks = like we may converge on the label only... IMHO some of this should be = captured in sect 3.12 of 3031 when it comes around.

I thought [y, s=3D1] hashed the same as [y, s=3D0] if = we simply skipped 's' ;-)

later
Dave

> -----Original Message-----
> From: Giles Heron [mailto:giles@packetexchange.net= ]
> Sent: Monday, April 15, 2002 3:20 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: mpls@UU.NET
> Subject: RE: response to ITU-T SG13
>
>
> On Mon, 2002-04-15 at 17:59, David Allan = wrote:
> > My comment was that this would be true for = any
> detection/diagnotic tool
> > discussed. e.g. use of explicit V4 label = to permit ICMP
> ping to be used for
> > non-IP LSPs or use GTTP to explore non-IP = LSPs or to
> measure anything such
> > as DSCP RTT.
>
> oh, okay.
>
> > That to me is sufficient reason to suggest = that in a load
> sharing scenario,
> > the answer should be the same for the = combination of label
> and exp bits. S
> > bit and TTL MUST be excluded....
>
> in fact it should probably just be the label = (and not the EXP bits) as
> the EXP bits may be describing different drop = precedences within the
> same queue?
>
> but we still have the problem of needing to = know the stack depth
> a-priori (or of figuring out a way to make [Y, = S=3D1] hash to the same
> link as [Y, S=3D0][OAM, S=3D1]).
>
> Giles
> 
> > cheers
> > Dave
> >
> >
> >
> > > -----Original Message-----
> > > From: Giles Heron [mailto:giles@packetexchange.net= ]
> > > Sent: Monday, April 15, 2002 2:47 = PM
> > > To: Allan, David = [CAR:NS00:EXCH]
> > > Cc: neil.2.harrison@bt.com; = kireeti@juniper.net; sob@harvard.edu;
> > > mpls@UU.NET
> > > Subject: RE: response to ITU-T = SG13
> > >
> > >
> > > On Mon, 2002-04-15 at 17:38, David = Allan wrote:
> > > > Thanks Giles,
> > > >
> > > > I understand the scenario you = are discussing and the S bit
> > > is a legit issue.
> > > > To re-use your pictures, I was = considering when y=3DOAM
> > > alert, not OAM alert
> > > > under 'y'.
> > > >
> > > > But ultimately I think the = problem exists independently of
> > > the OAM alert
> > > > label. It would also be true if = any reserved label (e.g.
> > > explicit V4 label)
> > > > was used, and suggests that for = stuff to function correctly your
> > > > implementation should only be = looking one label further
> > > into the stack and
> > > > MUST ignore the S bit. The = existence of reserved labels
> > > means that hashing
> > > > more than one label deep has = problems, and including the S
> > > bit has problems.
> > > > Implementation wise this may not = be the case today, but
> > > live and learn ;-)
> > >
> > > Yes, this "problem" exists = for other traffic, but it only
> > > matters in the
> > > OAM case - where the aim is for the = OAM traffic to follow the
> > > same path
> > > as the user traffic.
> > >
> > > If I have Internet traffic from PE A = to PE B and this follows a
> > > different path to a draft-martini = circuit from PE A to PE B
> > > (i.e. where
> > > there is an extra label) then I don't = care.  All I care
> about is that
> > > all the traffic for a given = draft-martini circuit between A and B
> > > follows the same path.
> > >
> > > Giles
> > >
> > > > This preserves any detection = properties for any tools
> > > employed regardless of
> > > > the type used, payload used etc. =
> > > >
> > > > cheers
> > > > Dave
> > > >
> > > > > -----Original = Message-----
> > > > > From: Giles Heron [mailto:giles@packetexchange.net= ]
> > > > > Sent: Monday, April 15, = 2002 2:28 PM
> > > > > To: Allan, David = [CAR:NS00:EXCH]
> > > > > Cc: neil.2.harrison@bt.com; = kireeti@juniper.net;
> sob@harvard.edu;
> > > > > mpls@UU.NET
> > > > > Subject: RE: response to = ITU-T SG13
> > > > >
> > > > >
> > > > > On Mon, 2002-04-15 at = 16:59, David Allan wrote:
> > > > > > Giles:
> > > > > >
> > > > > > So then why does = whether or not the S bit is set matter?
> > > > >
> > > > > perhaps a picture would = help?
> > > > >
> > > > > Say an LSR switches a = packet with the following stack:
> > > > >
> > > > > |--------|--------|
> > > > > | X, S=3D0 | Y, S=3D1 = |
> > > > > |--------|--------|
> > > > >
> > > > > It has an L-FIB entry for X = that has n equal cost paths.
> > > > >
> > > > > What we would like to be = able to do is to hash across the
> > > > > entire stack.
> > > > > This way a second packet = with the following stack:
> > > > >
> > > > > |--------|--------|
> > > > > | X, S=3D0 | Z, S=3D1 = |
> > > > > |--------|--------|
> > > > >
> > > > > can use a different one of = the n equal cost paths (depending
> > > > > on the hash
> > > > > function and the values of = Y and Z of course).
> > > > >
> > > > > However the problem arises = if you have MPLS OAM and the
> > > > > following packet
> > > > > is sent:
> > > > >
> > > > > = |--------|--------|--------|
> > > > > | X, S=3D0 | Y, S=3D0 |14, = S=3D1 |
> > > > > = |--------|--------|--------|
> > > > >
> > > > > If the hash includes the S = bit then this will most likely
> > > be sent on a
> > > > > different link to the first = packet.
> > > > >
> > > > > Likewise if the hash = includes *all* labels then this will
> > > > > most likely be
> > > > > sent on a different = link.
> > > > >
> > > > > So what you need is to know = a-priori the minimal depth of
> > > stack for
> > > > > non-OAM traffic and hash = over that number of labels.  But
> > > > > this coarsens
> > > > > the granularity of the load = balancing, and also requires
> > > > > configuration -
> > > > > unless you take the most = simplistic approach and hash
> > > only using the
> > > > > first label (which barely = qualifies as load balancing).
> > > > >
> > > > > > Seem to me that both = scenarios need to be covered unless I
> > > > > was producing a
> > > > > > very specialized = implementation....
> > > > > > - the current label is = also the bottom label
> > > > > > - the current label is = not the bottom label and the label
> > > > > underneath may be
> > > > > > transport or = reserved.
> > > > >
> > > > > not sure what you mean by = "current" label.  Do you mean
> > > the label you
> > > > > are switching on?
> > > > >
> > > > > Giles
> > > > >
> > > > > > cheers
> > > > > > Dave
> > > > > >
> > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: Giles Heron = [mailto:giles@packetexchange.net= ]
> > > > > > > Sent: Monday, = April 15, 2002 11:07 AM
> > > > > > > To: Allan, David = [CAR:NS00:EXCH]
> > > > > > > Cc: = neil.2.harrison@bt.com; kireeti@juniper.net;
> > > sob@harvard.edu;
> > > > > > > = mpls@UU.NET
> > > > > > > Subject: RE: = response to ITU-T SG13
> > > > > > >
> > > > > > >
> > > > > > > On Mon, = 2002-04-15 at 13:40, David Allan wrote:
> > > > > > > > = Giles:
> > > > > > > >
> > > > > > > > A = clarification...
> > > > > > > >
> > > > > > > > > which = means that intermediate LSRs that use a
> > > hash to load
> > > > > > > > > balance = MPLS
> > > > > > > > > traffic = over equal cost links/paths have to
> be careful to
> > > > > > > > > exclude = the S
> > > > > > > > > bit = from any hash.
> > > > > > > >
> > > > > > > > If I am = inverse muxing an LSP at an
> intermadiate LSR, is
> > > > > > > this not on = the
> > > > > > > > basis of = some hashing on the payload for the
> current label,
> > > > > > > which could = be
> > > > > > > > more = labels...I'm not quite getting your example.
> > > > > > >
> > > > > > > effectively yes, = you are hashing on the payload for the
> > > > > > > current label = -
> > > > > > > given that it = includes more labels.  So, for example, an
> > > > > LSR switching
> > > > > > > based on an = LDP-assigned label might have a set
> of equal cost
> > > > > > > next hops
> > > > > > > in its IGP - = across which it could load balance
> traffic based
> > > > > > > on a hash
> > > > > > > which includes = the draft-martini label inside that LDP
> > > > > assigned label
> > > > > > > (though of course = it wouldn't know whether the inner
> > > > > label was being
> > > > > > > used for = draft-martini, for MPLS VPN, or for
> > > something else...)
> > > > > > >
> > > > > > > Giles
> > > > > > >
> > > > > > > >
> > > > > > > > Dave
> > > > > > > >
> > > > > > > >  =
> > > > > > > --
> > > > > > >
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > > Giles = Heron    Principal Network Architect    =
> > > PacketExchange Ltd.
> > > > > > > ph: +44 7880 = 506185           =    "if you build it
> > > they will yawn"
> > > > > > >
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > >
> > > > > > >
> > > > > --
> > > > >
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > Giles = Heron    Principal Network Architect    =
> PacketExchange Ltd.
> > > > > ph: +44 7880 = 506185           =    "if you build it
> they will yawn"
> > > > >
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > >
> > > > >
> > > --
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > Giles Heron    = Principal Network Architect    PacketExchange = Ltd.
> > > ph: +44 7880 = 506185           =    "if you build it they will yawn"
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >
> > >
> --
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Giles Heron    Principal Network = Architect    PacketExchange Ltd.
> ph: +44 7880 = 506185           =    "if you build it they will yawn"
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>

------_=_NextPart_001_01C1E4AA.DDDF76EC-- From owner-mpls@UU.NET Mon Apr 15 14:27:53 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01283 for ; Mon, 15 Apr 2002 14:27:53 -0400 (EDT) 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 QQmksn10026; Mon, 15 Apr 2002 18:27:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksn27803 for mpls-outgoing; Mon, 15 Apr 2002 18:26:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmksn27796 for ; Mon, 15 Apr 2002 18:26:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmksn07933 for ; Mon, 15 Apr 2002 18:26:09 GMT Received: from server.nayna.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 67-89-191-66.customer.algx.net [67.89.191.66]) id QQmksn24655 for ; Mon, 15 Apr 2002 18:26:08 GMT Received: from relay.nayna.com (relay.nayna.com [10.0.128.11]) by server.nayna.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA14516; Mon, 15 Apr 2002 11:26:07 -0700 Received: from nayna.com (dhcp-131-104.nayna.com [10.0.131.104]) by relay.nayna.com (8.9.3/8.9.3) with ESMTP id LAA19252; Mon, 15 Apr 2002 11:25:37 -0700 Message-ID: <3CBB1ABB.4B93EE8E@nayna.com> Date: Mon, 15 Apr 2002 11:23:55 -0700 From: Sudheer Dharanikota X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: gmpls gmpls CC: Zhi-Wei Lin , mpls@UU.NET Subject: Re: SE style in optical neyworks References: <20020415141356.89320.qmail@web13708.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 gmpls gmpls wrote: > Thanks Zhi for ur clarification. > This has led to another question > Is optical network providing service other than UNI > clients. If not, why do we have to provide other style > of reservation, which is not going to used at all? Hi gmpls gmpls: UNI is at the unser-to-network interface. It does not talk about inside the network, which is what we are talking about in SE style. Also, if have some questions regarding OIF UNI please post it in oif mailing list. Regards, sudheer > > > Regards > > --- Zhi-Wei Lin wrote: > > Hi, > > > > This implication doesn't necessary apply. What the > > UNI requests requires > > that the network be able to support. But this > > doesn't necessarily imply > > that what UNI has translates to what the network > > must also have and no > > more... > > > > The SE style discussion is orthogonal to this... > > > > Zhi > > > > > > gmpls gmpls wrote: > > > > >Hi, > > > > > >I need some more clarification on this regard. > > >The OIF UNI v1.0 standard says UNI only supports > > the > > >FF style of reservation. Since Optical network > > which > > >main purpose is to provide service for UNI clients, > > >would have to support same set reservation styles > > >which UNI needs. > > > > > >So Is there a need for supporting SE style of > > >reservation in the optical domain? > > > > > >Regards > > > > > > > > >__________________________________________________ > > >Do You Yahoo!? > > >Yahoo! Tax Center - online filing with TurboTax > > >http://taxes.yahoo.com/ > > > > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Tax Center - online filing with TurboTax > http://taxes.yahoo.com/ From owner-mpls@UU.NET Mon Apr 15 14:38:16 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02149 for ; Mon, 15 Apr 2002 14:38:16 -0400 (EDT) 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 QQmkso25466; Mon, 15 Apr 2002 18:37:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkso28329 for mpls-outgoing; Mon, 15 Apr 2002 18:37: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 QQmkso28324 for ; Mon, 15 Apr 2002 18:37:07 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 QQmkso29027 for ; Mon, 15 Apr 2002 18:36:59 GMT Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmkso24569 for ; Mon, 15 Apr 2002 18:36:58 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 16xBHp-0004fX-00; Mon, 15 Apr 2002 19:33:09 +0100 Subject: RE: response to ITU-T SG13 From: Giles Heron To: David Allan Cc: mpls@UU.NET In-Reply-To: <3549C09B853DD5119B540002A52CDD3402C6E59C@zcard0ka.ca.nortel.com> References: <3549C09B853DD5119B540002A52CDD3402C6E59C@zcard0ka.ca.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 15 Apr 2002 19:33:34 +0000 Message-Id: <1018899214.1131.336.camel@gizzer> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-04-15 at 18:25, David Allan wrote: > Giles: > > Agreed that EXP drop preference is an issue. Looks like we may converge on > the label only... IMHO some of this should be captured in sect 3.12 of 3031 > when it comes around. possibly - or 3032? > I thought [y, s=1] hashed the same as [y, s=0] if we simply skipped 's' ;-) it does. but not the same as [y, s=0][z, s=1]. > later > Dave > > > -----Original Message----- > > From: Giles Heron [mailto:giles@packetexchange.net] > > Sent: Monday, April 15, 2002 3:20 PM > > To: Allan, David [CAR:NS00:EXCH] > > Cc: mpls@UU.NET > > Subject: RE: response to ITU-T SG13 > > > > > > On Mon, 2002-04-15 at 17:59, David Allan wrote: > > > My comment was that this would be true for any > > detection/diagnotic tool > > > discussed. e.g. use of explicit V4 label to permit ICMP > > ping to be used for > > > non-IP LSPs or use GTTP to explore non-IP LSPs or to > > measure anything such > > > as DSCP RTT. > > > > oh, okay. > > > > > That to me is sufficient reason to suggest that in a load > > sharing scenario, > > > the answer should be the same for the combination of label > > and exp bits. S > > > bit and TTL MUST be excluded.... > > > > in fact it should probably just be the label (and not the EXP bits) as > > the EXP bits may be describing different drop precedences within the > > same queue? > > > > but we still have the problem of needing to know the stack depth > > a-priori (or of figuring out a way to make [Y, S=1] hash to the same > > link as [Y, S=0][OAM, S=1]). > > > > Giles > > > > > cheers > > > Dave > > > > > > > > > > > > > -----Original Message----- > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > Sent: Monday, April 15, 2002 2:47 PM > > > > To: Allan, David [CAR:NS00:EXCH] > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; sob@harvard.edu; > > > > mpls@UU.NET > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > On Mon, 2002-04-15 at 17:38, David Allan wrote: > > > > > Thanks Giles, > > > > > > > > > > I understand the scenario you are discussing and the S bit > > > > is a legit issue. > > > > > To re-use your pictures, I was considering when y=OAM > > > > alert, not OAM alert > > > > > under 'y'. > > > > > > > > > > But ultimately I think the problem exists independently of > > > > the OAM alert > > > > > label. It would also be true if any reserved label (e.g. > > > > explicit V4 label) > > > > > was used, and suggests that for stuff to function correctly your > > > > > implementation should only be looking one label further > > > > into the stack and > > > > > MUST ignore the S bit. The existence of reserved labels > > > > means that hashing > > > > > more than one label deep has problems, and including the S > > > > bit has problems. > > > > > Implementation wise this may not be the case today, but > > > > live and learn ;-) > > > > > > > > Yes, this "problem" exists for other traffic, but it only > > > > matters in the > > > > OAM case - where the aim is for the OAM traffic to follow the > > > > same path > > > > as the user traffic. > > > > > > > > If I have Internet traffic from PE A to PE B and this follows a > > > > different path to a draft-martini circuit from PE A to PE B > > > > (i.e. where > > > > there is an extra label) then I don't care. All I care > > about is that > > > > all the traffic for a given draft-martini circuit between A and B > > > > follows the same path. > > > > > > > > Giles > > > > > > > > > This preserves any detection properties for any tools > > > > employed regardless of > > > > > the type used, payload used etc. > > > > > > > > > > cheers > > > > > Dave > > > > > > > > > > > -----Original Message----- > > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > > Sent: Monday, April 15, 2002 2:28 PM > > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > > sob@harvard.edu; > > > > > > mpls@UU.NET > > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 16:59, David Allan wrote: > > > > > > > Giles: > > > > > > > > > > > > > > So then why does whether or not the S bit is set matter? > > > > > > > > > > > > perhaps a picture would help? > > > > > > > > > > > > Say an LSR switches a packet with the following stack: > > > > > > > > > > > > |--------|--------| > > > > > > | X, S=0 | Y, S=1 | > > > > > > |--------|--------| > > > > > > > > > > > > It has an L-FIB entry for X that has n equal cost paths. > > > > > > > > > > > > What we would like to be able to do is to hash across the > > > > > > entire stack. > > > > > > This way a second packet with the following stack: > > > > > > > > > > > > |--------|--------| > > > > > > | X, S=0 | Z, S=1 | > > > > > > |--------|--------| > > > > > > > > > > > > can use a different one of the n equal cost paths (depending > > > > > > on the hash > > > > > > function and the values of Y and Z of course). > > > > > > > > > > > > However the problem arises if you have MPLS OAM and the > > > > > > following packet > > > > > > is sent: > > > > > > > > > > > > |--------|--------|--------| > > > > > > | X, S=0 | Y, S=0 |14, S=1 | > > > > > > |--------|--------|--------| > > > > > > > > > > > > If the hash includes the S bit then this will most likely > > > > be sent on a > > > > > > different link to the first packet. > > > > > > > > > > > > Likewise if the hash includes *all* labels then this will > > > > > > most likely be > > > > > > sent on a different link. > > > > > > > > > > > > So what you need is to know a-priori the minimal depth of > > > > stack for > > > > > > non-OAM traffic and hash over that number of labels. But > > > > > > this coarsens > > > > > > the granularity of the load balancing, and also requires > > > > > > configuration - > > > > > > unless you take the most simplistic approach and hash > > > > only using the > > > > > > first label (which barely qualifies as load balancing). > > > > > > > > > > > > > Seem to me that both scenarios need to be covered unless I > > > > > > was producing a > > > > > > > very specialized implementation.... > > > > > > > - the current label is also the bottom label > > > > > > > - the current label is not the bottom label and the label > > > > > > underneath may be > > > > > > > transport or reserved. > > > > > > > > > > > > not sure what you mean by "current" label. Do you mean > > > > the label you > > > > > > are switching on? > > > > > > > > > > > > Giles > > > > > > > > > > > > > cheers > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > > > > Sent: Monday, April 15, 2002 11:07 AM > > > > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > > > > sob@harvard.edu; > > > > > > > > mpls@UU.NET > > > > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 13:40, David Allan wrote: > > > > > > > > > Giles: > > > > > > > > > > > > > > > > > > A clarification... > > > > > > > > > > > > > > > > > > > which means that intermediate LSRs that use a > > > > hash to load > > > > > > > > > > balance MPLS > > > > > > > > > > traffic over equal cost links/paths have to > > be careful to > > > > > > > > > > exclude the S > > > > > > > > > > bit from any hash. > > > > > > > > > > > > > > > > > > If I am inverse muxing an LSP at an > > intermadiate LSR, is > > > > > > > > this not on the > > > > > > > > > basis of some hashing on the payload for the > > current label, > > > > > > > > which could be > > > > > > > > > more labels...I'm not quite getting your example. > > > > > > > > > > > > > > > > effectively yes, you are hashing on the payload for the > > > > > > > > current label - > > > > > > > > given that it includes more labels. So, for example, an > > > > > > LSR switching > > > > > > > > based on an LDP-assigned label might have a set > > of equal cost > > > > > > > > next hops > > > > > > > > in its IGP - across which it could load balance > > traffic based > > > > > > > > on a hash > > > > > > > > which includes the draft-martini label inside that LDP > > > > > > assigned label > > > > > > > > (though of course it wouldn't know whether the inner > > > > > > label was being > > > > > > > > used for draft-martini, for MPLS VPN, or for > > > > something else...) > > > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > ================================================================= > > > > > > > > Giles Heron Principal Network Architect > > > > PacketExchange Ltd. > > > > > > > > ph: +44 7880 506185 "if you build it > > > > they will yawn" > > > > > > > > > > > > ================================================================= > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > ================================================================= > > > > > > Giles Heron Principal Network Architect > > PacketExchange Ltd. > > > > > > ph: +44 7880 506185 "if you build it > > they will yawn" > > > > > > > > ================================================================= > > > > > > > > > > > > > > > > -- > > > > ================================================================= > > > > Giles Heron Principal Network Architect PacketExchange Ltd. > > > > ph: +44 7880 506185 "if you build it they will yawn" > > > > ================================================================= > > > > > > > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Mon Apr 15 14:43:18 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02342 for ; Mon, 15 Apr 2002 14:43:18 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkso16979; Mon, 15 Apr 2002 18:42:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkso28567 for mpls-outgoing; Mon, 15 Apr 2002 18:42:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmkso28558 for ; Mon, 15 Apr 2002 18:42: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 QQmkso13906 for ; Mon, 15 Apr 2002 18:41: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 QQmkso01946 for ; Mon, 15 Apr 2002 18:41:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA12649 for ; Mon, 15 Apr 2002 14:41:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA06640 for mpls@uu.net; Mon, 15 Apr 2002 14:41:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkso28434 for ; Mon, 15 Apr 2002 18:39:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkso11905 for ; Mon, 15 Apr 2002 18:39:17 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 QQmkso29144 for ; Mon, 15 Apr 2002 18:39:17 GMT Received: from eosborne-u10.cisco.com (eosborne-u10.cisco.com [161.44.134.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA12544; Mon, 15 Apr 2002 14:39:16 -0400 (EDT) Received: (eosborne@localhost) by eosborne-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA03966; Mon, 15 Apr 2002 14:39:16 -0400 (EDT) Date: Mon, 15 Apr 2002 14:39:16 -0400 From: Eric Osborne To: Shahram Davari Cc: "'Giles Heron'" , neil.2.harrison@bt.com, kireeti@juniper.net, sob@harvard.edu, mpls@UU.NET Subject: Re: response to ITU-T SG13 Message-ID: <20020415143916.D3752@eosborne-u10.cisco.com> References: <4B6D09F3B826D411A67300D0B706EFDE84A6F9@nt-exch-yow.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE84A6F9@nt-exch-yow.pmc-sierra.bc.ca>; from Shahram_Davari@pmc-sierra.com on Mon, Apr 15, 2002 at 10:41:32AM -0700 X-GPG-Fingerprint: 6412 0836 E440 B3EA 980C 4951 611E 1819 2E71 8562 Sender: owner-mpls@UU.NET Precedence: bulk On Mon, Apr 15, 2002 at 10:41:32AM -0700, Shahram Davari wrote: > Hi Giles, > > > > which means that intermediate LSRs that use a hash to load > > balance MPLS > > traffic over equal cost links/paths have to be careful to > > exclude the S > > bit from any hash. > > An more logical method is for the hash result > to point to the same region of the hash key > when S=0 or S=1 in the bottom-most label. > Maybe I'm missing something. If you set S=0 in the bottom-most label of the stack, how do you know where the stack ends and the payload starts? eric > > > > I'm not sure that this is the case for all current implementations... > > I don't think specific implementations should be a concern for a standard > body such as IETF. You could always find a specific implementations that can't > support a new function. Any objection regarding backward compatibility should be > based on a standard. AFAIK there is no standard for hash-based ECMP MPLS switching. > > > > > In fact this also would seem to imply that you have to hash > > over a fixed > > number of labels (to ensure that both the OAM traffic and the user > > traffic get the same hash value). This coarsens the load balancing > > granularity somewhat :( > > If only 0.1% of a single label range is used, you could still select up to ~1000 different flows using that "single" label. I am not sure of how coarse this is!!! > > > > > The alternatives would be either to preclude hashed > > load-balancing or to > > require OAM-aware core LSRs. Neither of these options is acceptable > > IMO. > > > > Giles, even MPLS-ping that is carried over non-IP carrying LSP uses > an extra label (Explicit Null label). So I don't think you can find > any solution that can satisfy the restricted implementations in your boxes. > > Yours, > -Shahram > > > Giles > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > From owner-mpls@UU.NET Mon Apr 15 14:47:58 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02563 for ; Mon, 15 Apr 2002 14:47:58 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmksp02385; Mon, 15 Apr 2002 18:46:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksp29166 for mpls-outgoing; Mon, 15 Apr 2002 18:46: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 QQmksp29149 for ; Mon, 15 Apr 2002 18:46:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmksp29410 for ; Mon, 15 Apr 2002 18:45:09 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 QQmksp08108 for ; Mon, 15 Apr 2002 18:45:08 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA12884 for ; Mon, 15 Apr 2002 14:45:08 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA07256 for mpls@uu.net; Mon, 15 Apr 2002 14:45:03 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmkso28664 for ; Mon, 15 Apr 2002 18:43:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkso19465 for ; Mon, 15 Apr 2002 18:42:06 GMT Received: from father.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmkso03675 for ; Mon, 15 Apr 2002 18:42:05 GMT Received: (qmail 14309 invoked by uid 104); 15 Apr 2002 18:42:04 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4196. . Clean. Processed in 0.503162 secs); 15 Apr 2002 18:42:04 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 15 Apr 2002 18:42:03 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g3FIg0p02972; Mon, 15 Apr 2002 11:42:00 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 11:42:05 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A6FC@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Eric Osborne'" Cc: "'Giles Heron'" , neil.2.harrison@bt.com, kireeti@juniper.net, sob@harvard.edu, mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 11:42:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric/Giles, > -----Original Message----- > From: Eric Osborne [mailto:eosborne@cisco.com] > Sent: Monday, April 15, 2002 2:39 PM > To: Shahram Davari > Cc: 'Giles Heron'; neil.2.harrison@bt.com; kireeti@juniper.net; > sob@harvard.edu; mpls@UU.NET > Subject: Re: response to ITU-T SG13 > > > On Mon, Apr 15, 2002 at 10:41:32AM -0700, Shahram Davari wrote: > > Hi Giles, > > > > > > > which means that intermediate LSRs that use a hash to load > > > balance MPLS > > > traffic over equal cost links/paths have to be careful to > > > exclude the S > > > bit from any hash. > > > > An more logical method is for the hash result > > to point to the same region of the hash key > > when S=0 or S=1 in the bottom-most label. > > Maybe I'm missing something. If you set S=0 in the bottom-most label > of the stack, how do you know where the stack ends and the payload > starts? > By Bottom-most label I meant the last label when you parse a fixed number of labels from the stack. For example if you have 5 labels and you parse only 3 labels the 3rd label is the one that I was referring to. -Shahram > > > eric > > > > > > > I'm not sure that this is the case for all current > implementations... > > > > I don't think specific implementations should be a concern > for a standard > > body such as IETF. You could always find a specific > implementations that can't > > support a new function. Any objection regarding backward > compatibility should be > > based on a standard. AFAIK there is no standard for > hash-based ECMP MPLS switching. > > > > > > > > In fact this also would seem to imply that you have to hash > > > over a fixed > > > number of labels (to ensure that both the OAM traffic and the user > > > traffic get the same hash value). This coarsens the load > balancing > > > granularity somewhat :( > > > > If only 0.1% of a single label range is used, you could > still select up to ~1000 different flows using that "single" > label. I am not sure of how coarse this is!!! > > > > > > > > The alternatives would be either to preclude hashed > > > load-balancing or to > > > require OAM-aware core LSRs. Neither of these options is > acceptable > > > IMO. > > > > > > > Giles, even MPLS-ping that is carried over non-IP carrying LSP uses > > an extra label (Explicit Null label). So I don't think you can find > > any solution that can satisfy the restricted > implementations in your boxes. > > > > Yours, > > -Shahram > > > > > Giles > > > > > > -- > > > ================================================================= > > > Giles Heron Principal Network Architect PacketExchange Ltd. > > > ph: +44 7880 506185 "if you build it they will yawn" > > > ================================================================= > > > > From owner-mpls@UU.NET Mon Apr 15 14:53:44 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02772 for ; Mon, 15 Apr 2002 14:53:43 -0400 (EDT) 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 QQmksp19249; Mon, 15 Apr 2002 18:52:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksp29789 for mpls-outgoing; Mon, 15 Apr 2002 18:52: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 QQmksp29756 for ; Mon, 15 Apr 2002 18:52:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmksp17471 for ; Mon, 15 Apr 2002 18:51:28 GMT Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmksp17239 for ; Mon, 15 Apr 2002 18:51:27 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FIpOa15379; Mon, 15 Apr 2002 14:51:24 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJA3P90>; Mon, 15 Apr 2002 14:51:24 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402C6E63B@zcard0ka.ca.nortel.com> From: "David Allan" To: Giles Heron Cc: mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 14:51:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4AE.89C37E9C" 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_01C1E4AE.89C37E9C Content-Type: text/plain; charset="iso-8859-1" Okay, I'll bite, If the goal is that [y,s=0] and [y,s=1] have common forwarding for things to work, where does [y,s=0][z,s=1] enter the picture? I understand YOU want to hash more than one label deep, and if folks agree that this is required to get the sort of "smoothness" they want (implying some binding of quantity of traffic to existence of a label) then we need a solution like: [y,s=1] or [y,s=0 & z <16] should hash to the same outgoing label... In order to ensure that there are no future collisions between your hashing algorithm and the reserved label space. I could go for that! cheers Dave > -----Original Message----- > From: Giles Heron [mailto:giles@packetexchange.net] > Sent: Monday, April 15, 2002 3:34 PM > To: Allan, David [CAR:NS00:EXCH] > Cc: mpls@UU.NET > Subject: RE: response to ITU-T SG13 > > > On Mon, 2002-04-15 at 18:25, David Allan wrote: > > Giles: > > > > Agreed that EXP drop preference is an issue. Looks like we > may converge on > > the label only... IMHO some of this should be captured in > sect 3.12 of 3031 > > when it comes around. > > possibly - or 3032? > > > I thought [y, s=1] hashed the same as [y, s=0] if we simply > skipped 's' ;-) > > it does. > > but not the same as [y, s=0][z, s=1]. > > > later > > Dave > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > Sent: Monday, April 15, 2002 3:20 PM > > > To: Allan, David [CAR:NS00:EXCH] > > > Cc: mpls@UU.NET > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > On Mon, 2002-04-15 at 17:59, David Allan wrote: > > > > My comment was that this would be true for any > > > detection/diagnotic tool > > > > discussed. e.g. use of explicit V4 label to permit ICMP > > > ping to be used for > > > > non-IP LSPs or use GTTP to explore non-IP LSPs or to > > > measure anything such > > > > as DSCP RTT. > > > > > > oh, okay. > > > > > > > That to me is sufficient reason to suggest that in a load > > > sharing scenario, > > > > the answer should be the same for the combination of label > > > and exp bits. S > > > > bit and TTL MUST be excluded.... > > > > > > in fact it should probably just be the label (and not the > EXP bits) as > > > the EXP bits may be describing different drop precedences > within the > > > same queue? > > > > > > but we still have the problem of needing to know the stack depth > > > a-priori (or of figuring out a way to make [Y, S=1] hash > to the same > > > link as [Y, S=0][OAM, S=1]). > > > > > > Giles > > > > > > > cheers > > > > Dave > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > Sent: Monday, April 15, 2002 2:47 PM > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > sob@harvard.edu; > > > > > mpls@UU.NET > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 17:38, David Allan wrote: > > > > > > Thanks Giles, > > > > > > > > > > > > I understand the scenario you are discussing and the S bit > > > > > is a legit issue. > > > > > > To re-use your pictures, I was considering when y=OAM > > > > > alert, not OAM alert > > > > > > under 'y'. > > > > > > > > > > > > But ultimately I think the problem exists independently of > > > > > the OAM alert > > > > > > label. It would also be true if any reserved label (e.g. > > > > > explicit V4 label) > > > > > > was used, and suggests that for stuff to function > correctly your > > > > > > implementation should only be looking one label further > > > > > into the stack and > > > > > > MUST ignore the S bit. The existence of reserved labels > > > > > means that hashing > > > > > > more than one label deep has problems, and including the S > > > > > bit has problems. > > > > > > Implementation wise this may not be the case today, but > > > > > live and learn ;-) > > > > > > > > > > Yes, this "problem" exists for other traffic, but it only > > > > > matters in the > > > > > OAM case - where the aim is for the OAM traffic to follow the > > > > > same path > > > > > as the user traffic. > > > > > > > > > > If I have Internet traffic from PE A to PE B and this > follows a > > > > > different path to a draft-martini circuit from PE A to PE B > > > > > (i.e. where > > > > > there is an extra label) then I don't care. All I care > > > about is that > > > > > all the traffic for a given draft-martini circuit > between A and B > > > > > follows the same path. > > > > > > > > > > Giles > > > > > > > > > > > This preserves any detection properties for any tools > > > > > employed regardless of > > > > > > the type used, payload used etc. > > > > > > > > > > > > cheers > > > > > > Dave > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > > > Sent: Monday, April 15, 2002 2:28 PM > > > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > > > sob@harvard.edu; > > > > > > > mpls@UU.NET > > > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 16:59, David Allan wrote: > > > > > > > > Giles: > > > > > > > > > > > > > > > > So then why does whether or not the S bit is > set matter? > > > > > > > > > > > > > > perhaps a picture would help? > > > > > > > > > > > > > > Say an LSR switches a packet with the following stack: > > > > > > > > > > > > > > |--------|--------| > > > > > > > | X, S=0 | Y, S=1 | > > > > > > > |--------|--------| > > > > > > > > > > > > > > It has an L-FIB entry for X that has n equal cost paths. > > > > > > > > > > > > > > What we would like to be able to do is to hash across the > > > > > > > entire stack. > > > > > > > This way a second packet with the following stack: > > > > > > > > > > > > > > |--------|--------| > > > > > > > | X, S=0 | Z, S=1 | > > > > > > > |--------|--------| > > > > > > > > > > > > > > can use a different one of the n equal cost paths > (depending > > > > > > > on the hash > > > > > > > function and the values of Y and Z of course). > > > > > > > > > > > > > > However the problem arises if you have MPLS OAM and the > > > > > > > following packet > > > > > > > is sent: > > > > > > > > > > > > > > |--------|--------|--------| > > > > > > > | X, S=0 | Y, S=0 |14, S=1 | > > > > > > > |--------|--------|--------| > > > > > > > > > > > > > > If the hash includes the S bit then this will most likely > > > > > be sent on a > > > > > > > different link to the first packet. > > > > > > > > > > > > > > Likewise if the hash includes *all* labels then this will > > > > > > > most likely be > > > > > > > sent on a different link. > > > > > > > > > > > > > > So what you need is to know a-priori the minimal depth of > > > > > stack for > > > > > > > non-OAM traffic and hash over that number of labels. But > > > > > > > this coarsens > > > > > > > the granularity of the load balancing, and also requires > > > > > > > configuration - > > > > > > > unless you take the most simplistic approach and hash > > > > > only using the > > > > > > > first label (which barely qualifies as load balancing). > > > > > > > > > > > > > > > Seem to me that both scenarios need to be > covered unless I > > > > > > > was producing a > > > > > > > > very specialized implementation.... > > > > > > > > - the current label is also the bottom label > > > > > > > > - the current label is not the bottom label and > the label > > > > > > > underneath may be > > > > > > > > transport or reserved. > > > > > > > > > > > > > > not sure what you mean by "current" label. Do you mean > > > > > the label you > > > > > > > are switching on? > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > > cheers > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > > > > > Sent: Monday, April 15, 2002 11:07 AM > > > > > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > > > > > sob@harvard.edu; > > > > > > > > > mpls@UU.NET > > > > > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 13:40, David Allan wrote: > > > > > > > > > > Giles: > > > > > > > > > > > > > > > > > > > > A clarification... > > > > > > > > > > > > > > > > > > > > > which means that intermediate LSRs that use a > > > > > hash to load > > > > > > > > > > > balance MPLS > > > > > > > > > > > traffic over equal cost links/paths have to > > > be careful to > > > > > > > > > > > exclude the S > > > > > > > > > > > bit from any hash. > > > > > > > > > > > > > > > > > > > > If I am inverse muxing an LSP at an > > > intermadiate LSR, is > > > > > > > > > this not on the > > > > > > > > > > basis of some hashing on the payload for the > > > current label, > > > > > > > > > which could be > > > > > > > > > > more labels...I'm not quite getting your example. > > > > > > > > > > > > > > > > > > effectively yes, you are hashing on the > payload for the > > > > > > > > > current label - > > > > > > > > > given that it includes more labels. So, for > example, an > > > > > > > LSR switching > > > > > > > > > based on an LDP-assigned label might have a set > > > of equal cost > > > > > > > > > next hops > > > > > > > > > in its IGP - across which it could load balance > > > traffic based > > > > > > > > > on a hash > > > > > > > > > which includes the draft-martini label inside > that LDP > > > > > > > assigned label > > > > > > > > > (though of course it wouldn't know whether the inner > > > > > > > label was being > > > > > > > > > used for draft-martini, for MPLS VPN, or for > > > > > something else...) > > > > > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > ================================================================= > > > > > > > > > Giles Heron Principal Network Architect > > > > > PacketExchange Ltd. > > > > > > > > > ph: +44 7880 506185 "if you build it > > > > > they will yawn" > > > > > > > > > > > > > > > ================================================================= > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > ================================================================= > > > > > > > Giles Heron Principal Network Architect > > > PacketExchange Ltd. > > > > > > > ph: +44 7880 506185 "if you build it > > > they will yawn" > > > > > > > > > > ================================================================= > > > > > > > > > > > > > > > > > > > -- > > > > > > ================================================================= > > > > > Giles Heron Principal Network Architect > PacketExchange Ltd. > > > > > ph: +44 7880 506185 "if you build it > they will yawn" > > > > > > ================================================================= > > > > > > > > > > > > > -- > > > ================================================================= > > > 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" > ================================================================= > ------_=_NextPart_001_01C1E4AE.89C37E9C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: response to ITU-T SG13

Okay, I'll bite,

If the goal is that [y,s=3D0] and [y,s=3D1] have = common forwarding for things to work, where does [y,s=3D0][z,s=3D1] = enter the picture?

I understand YOU want to hash more than one label = deep, and if folks agree that this is required to get the sort of = "smoothness" they want (implying some binding of quantity of = traffic to existence of a label) then we need a solution = like:

        [y,s=3D1] = or [y,s=3D0 & z <16] should hash to the same outgoing = label...

In order to ensure that there are no future = collisions between your hashing algorithm and the reserved label space. = I could go for that!

cheers
Dave

> -----Original Message-----
> From: Giles Heron [mailto:giles@packetexchange.net= ]
> Sent: Monday, April 15, 2002 3:34 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: mpls@UU.NET
> Subject: RE: response to ITU-T SG13
>
>
> On Mon, 2002-04-15 at 18:25, David Allan = wrote:
> > Giles:
> >
> > Agreed that EXP drop preference is an = issue. Looks like we
> may converge on
> > the label only... IMHO some of this should = be captured in
> sect 3.12 of 3031
> > when it comes around.
>
> possibly - or 3032?
> 
> > I thought [y, s=3D1] hashed the same as = [y, s=3D0] if we simply
> skipped 's' ;-)
>
> it does.
>
> but not the same as [y, s=3D0][z, = s=3D1].
>
> > later
> > Dave
> >
> > > -----Original Message-----
> > > From: Giles Heron [mailto:giles@packetexchange.net= ]
> > > Sent: Monday, April 15, 2002 3:20 = PM
> > > To: Allan, David = [CAR:NS00:EXCH]
> > > Cc: mpls@UU.NET
> > > Subject: RE: response to ITU-T = SG13
> > >
> > >
> > > On Mon, 2002-04-15 at 17:59, David = Allan wrote:
> > > > My comment was that this would = be true for any
> > > detection/diagnotic tool
> > > > discussed. e.g. use of explicit = V4 label to permit ICMP
> > > ping to be used for
> > > > non-IP LSPs or use GTTP to = explore non-IP LSPs or to
> > > measure anything such
> > > > as DSCP RTT.
> > >
> > > oh, okay.
> > >
> > > > That to me is sufficient reason = to suggest that in a load
> > > sharing scenario,
> > > > the answer should be the same = for the combination of label
> > > and exp bits. S
> > > > bit and TTL MUST be = excluded....
> > >
> > > in fact it should probably just be = the label (and not the
> EXP bits) as
> > > the EXP bits may be describing = different drop precedences
> within the
> > > same queue?
> > >
> > > but we still have the problem of = needing to know the stack depth
> > > a-priori (or of figuring out a way to = make [Y, S=3D1] hash
> to the same
> > > link as [Y, S=3D0][OAM, = S=3D1]).
> > >
> > > Giles
> > > 
> > > > cheers
> > > > Dave
> > > >
> > > >
> > > >
> > > > > -----Original = Message-----
> > > > > From: Giles Heron [mailto:giles@packetexchange.net= ]
> > > > > Sent: Monday, April 15, = 2002 2:47 PM
> > > > > To: Allan, David = [CAR:NS00:EXCH]
> > > > > Cc: neil.2.harrison@bt.com; = kireeti@juniper.net;
> sob@harvard.edu;
> > > > > mpls@UU.NET
> > > > > Subject: RE: response to = ITU-T SG13
> > > > >
> > > > >
> > > > > On Mon, 2002-04-15 at = 17:38, David Allan wrote:
> > > > > > Thanks Giles,
> > > > > >
> > > > > > I understand the = scenario you are discussing and the S bit
> > > > > is a legit issue.
> > > > > > To re-use your = pictures, I was considering when y=3DOAM
> > > > > alert, not OAM alert
> > > > > > under 'y'.
> > > > > >
> > > > > > But ultimately I think = the problem exists independently of
> > > > > the OAM alert
> > > > > > label. It would also = be true if any reserved label (e.g.
> > > > > explicit V4 label)
> > > > > > was used, and suggests = that for stuff to function
> correctly your
> > > > > > implementation should = only be looking one label further
> > > > > into the stack and
> > > > > > MUST ignore the S bit. = The existence of reserved labels
> > > > > means that hashing
> > > > > > more than one label = deep has problems, and including the S
> > > > > bit has problems.
> > > > > > Implementation wise = this may not be the case today, but
> > > > > live and learn ;-)
> > > > >
> > > > > Yes, this = "problem" exists for other traffic, but it only
> > > > > matters in the
> > > > > OAM case - where the aim is = for the OAM traffic to follow the
> > > > > same path
> > > > > as the user traffic.
> > > > >
> > > > > If I have Internet traffic = from PE A to PE B and this
> follows a
> > > > > different path to a = draft-martini circuit from PE A to PE B
> > > > > (i.e. where
> > > > > there is an extra label) = then I don't care.  All I care
> > > about is that
> > > > > all the traffic for a given = draft-martini circuit
> between A and B
> > > > > follows the same = path.
> > > > >
> > > > > Giles
> > > > >
> > > > > > This preserves any = detection properties for any tools
> > > > > employed regardless = of
> > > > > > the type used, payload = used etc.
> > > > > >
> > > > > > cheers
> > > > > > Dave
> > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: Giles Heron = [mailto:giles@packetexchange.net= ]
> > > > > > > Sent: Monday, = April 15, 2002 2:28 PM
> > > > > > > To: Allan, David = [CAR:NS00:EXCH]
> > > > > > > Cc: = neil.2.harrison@bt.com; kireeti@juniper.net;
> > > sob@harvard.edu;
> > > > > > > = mpls@UU.NET
> > > > > > > Subject: RE: = response to ITU-T SG13
> > > > > > >
> > > > > > >
> > > > > > > On Mon, = 2002-04-15 at 16:59, David Allan wrote:
> > > > > > > > = Giles:
> > > > > > > >
> > > > > > > > So then why = does whether or not the S bit is
> set matter?
> > > > > > >
> > > > > > > perhaps a picture = would help?
> > > > > > >
> > > > > > > Say an LSR = switches a packet with the following stack:
> > > > > > >
> > > > > > > = |--------|--------|
> > > > > > > | X, S=3D0 | Y, = S=3D1 |
> > > > > > > = |--------|--------|
> > > > > > >
> > > > > > > It has an L-FIB = entry for X that has n equal cost paths.
> > > > > > >
> > > > > > > What we would = like to be able to do is to hash across the
> > > > > > > entire stack. =
> > > > > > > This way a second = packet with the following stack:
> > > > > > >
> > > > > > > = |--------|--------|
> > > > > > > | X, S=3D0 | Z, = S=3D1 |
> > > > > > > = |--------|--------|
> > > > > > >
> > > > > > > can use a = different one of the n equal cost paths
> (depending
> > > > > > > on the = hash
> > > > > > > function and the = values of Y and Z of course).
> > > > > > >
> > > > > > > However the = problem arises if you have MPLS OAM and the
> > > > > > > following = packet
> > > > > > > is sent:
> > > > > > >
> > > > > > > = |--------|--------|--------|
> > > > > > > | X, S=3D0 | Y, = S=3D0 |14, S=3D1 |
> > > > > > > = |--------|--------|--------|
> > > > > > >
> > > > > > > If the hash = includes the S bit then this will most likely
> > > > > be sent on a
> > > > > > > different link to = the first packet.
> > > > > > >
> > > > > > > Likewise if the = hash includes *all* labels then this will
> > > > > > > most likely = be
> > > > > > > sent on a = different link.
> > > > > > >
> > > > > > > So what you need = is to know a-priori the minimal depth of
> > > > > stack for
> > > > > > > non-OAM traffic = and hash over that number of labels.  But
> > > > > > > this = coarsens
> > > > > > > the granularity = of the load balancing, and also requires
> > > > > > > configuration = -
> > > > > > > unless you take = the most simplistic approach and hash
> > > > > only using the
> > > > > > > first label = (which barely qualifies as load balancing).
> > > > > > >
> > > > > > > > Seem to me = that both scenarios need to be
> covered unless I
> > > > > > > was producing = a
> > > > > > > > very = specialized implementation....
> > > > > > > > - the = current label is also the bottom label
> > > > > > > > - the = current label is not the bottom label and
> the label
> > > > > > > underneath may = be
> > > > > > > > transport or = reserved.
> > > > > > >
> > > > > > > not sure what you = mean by "current" label.  Do you mean
> > > > > the label you
> > > > > > > are switching = on?
> > > > > > >
> > > > > > > Giles
> > > > > > >
> > > > > > > > = cheers
> > > > > > > > Dave
> > > > > > > >
> > > > > > > >
> > > > > > > > > = -----Original Message-----
> > > > > > > > > From: = Giles Heron [mailto:giles@packetexchange.net= ]
> > > > > > > > > Sent: = Monday, April 15, 2002 11:07 AM
> > > > > > > > > To: = Allan, David [CAR:NS00:EXCH]
> > > > > > > > > Cc: = neil.2.harrison@bt.com; kireeti@juniper.net;
> > > > > sob@harvard.edu;
> > > > > > > > > = mpls@UU.NET
> > > > > > > > > = Subject: RE: response to ITU-T SG13
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, = 2002-04-15 at 13:40, David Allan wrote:
> > > > > > > > > > = Giles:
> > > > > > > > > > =
> > > > > > > > > > A = clarification...
> > > > > > > > > > =
> > > > > > > > > > = > which means that intermediate LSRs that use a
> > > > > hash to load
> > > > > > > > > > = > balance MPLS
> > > > > > > > > > = > traffic over equal cost links/paths have to
> > > be careful to
> > > > > > > > > > = > exclude the S
> > > > > > > > > > = > bit from any hash.
> > > > > > > > > > =
> > > > > > > > > > If = I am inverse muxing an LSP at an
> > > intermadiate LSR, is
> > > > > > > > > this = not on the
> > > > > > > > > > = basis of some hashing on the payload for the
> > > current label,
> > > > > > > > > which = could be
> > > > > > > > > > = more labels...I'm not quite getting your example.
> > > > > > > > >
> > > > > > > > > = effectively yes, you are hashing on the
> payload for the
> > > > > > > > > current = label -
> > > > > > > > > given = that it includes more labels.  So, for
> example, an
> > > > > > > LSR = switching
> > > > > > > > > based = on an LDP-assigned label might have a set
> > > of equal cost
> > > > > > > > > next = hops
> > > > > > > > > in its = IGP - across which it could load balance
> > > traffic based
> > > > > > > > > on a = hash
> > > > > > > > > which = includes the draft-martini label inside
> that LDP
> > > > > > > assigned = label
> > > > > > > > > (though = of course it wouldn't know whether the inner
> > > > > > > label was = being
> > > > > > > > > used = for draft-martini, for MPLS VPN, or for
> > > > > something else...)
> > > > > > > > >
> > > > > > > > > = Giles
> > > > > > > > >
> > > > > > > > > > =
> > > > > > > > > > = Dave
> > > > > > > > > > =
> > > > > > > > > = > 
> > > > > > > > > -- =
> > > > > > > > >
> > > > >
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > > > > Giles = Heron    Principal Network Architect    =
> > > > > PacketExchange Ltd.
> > > > > > > > > ph: +44 = 7880 = 506185           =    "if you build it
> > > > > they will yawn"
> > > > > > > > >
> > > > >
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > > > >
> > > > > > > > >
> > > > > > > --
> > > > > > >
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > > Giles = Heron    Principal Network Architect    =
> > > PacketExchange Ltd.
> > > > > > > ph: +44 7880 = 506185           =    "if you build it
> > > they will yawn"
> > > > > > >
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > >
> > > > > > >
> > > > > --
> > > > >
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > Giles = Heron    Principal Network Architect    =
> PacketExchange Ltd.
> > > > > ph: +44 7880 = 506185           =    "if you build it
> they will yawn"
> > > > >
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > >
> > > > >
> > > --
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > Giles Heron    = Principal Network Architect    PacketExchange = Ltd.
> > > ph: +44 7880 = 506185           =    "if you build it they will yawn"
> > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >
> > >
> --
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Giles Heron    Principal Network = Architect    PacketExchange Ltd.
> ph: +44 7880 = 506185           =    "if you build it they will yawn"
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>

------_=_NextPart_001_01C1E4AE.89C37E9C-- From owner-mpls@UU.NET Mon Apr 15 15:01:38 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03003 for ; Mon, 15 Apr 2002 15:01:38 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmksq12694; Mon, 15 Apr 2002 19:00:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksq01867 for mpls-outgoing; Mon, 15 Apr 2002 19:00: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 QQmksq01417 for ; Mon, 15 Apr 2002 19:00:07 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 QQmksp21180 for ; Mon, 15 Apr 2002 18:59:03 GMT Received: from rincewind.office.packetexchange.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmksp28807 for ; Mon, 15 Apr 2002 18:59:02 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 16xBgk-0004i3-00; Mon, 15 Apr 2002 19:58:54 +0100 Subject: RE: response to ITU-T SG13 From: Giles Heron To: David Allan Cc: mpls@UU.NET In-Reply-To: <1018900607.1131.359.camel@gizzer> References: <3549C09B853DD5119B540002A52CDD3402C6E63B@zcard0ka.ca.nortel.com> <1018900607.1131.359.camel@gizzer> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 15 Apr 2002 19:59:19 +0000 Message-Id: <1018900759.1131.364.camel@gizzer> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > I understand YOU want to hash more than one label deep, and if folks agree > > that this is required to get the sort of "smoothness" they want (implying > > some binding of quantity of traffic to existence of a label) then we need a > > solution like: > > > > [y,s=1] or [y,s=0 & z <16] should hash to the same outgoing label... > > > > In order to ensure that there are no future collisions between your hashing > > algorithm and the reserved label space. I could go for that! > > that might work. (but of course would require changes in the core - so not such a great idea...) I'm replying to myself now - probably time I left this thread! Giles > In any case I think in general people want to hash the entire stack - > since this gives maximum "smoothness" with minimum "configuration" :) > > Giles > > > cheers > > Dave > > > > > -----Original Message----- > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > Sent: Monday, April 15, 2002 3:34 PM > > > To: Allan, David [CAR:NS00:EXCH] > > > Cc: mpls@UU.NET > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > On Mon, 2002-04-15 at 18:25, David Allan wrote: > > > > Giles: > > > > > > > > Agreed that EXP drop preference is an issue. Looks like we > > > may converge on > > > > the label only... IMHO some of this should be captured in > > > sect 3.12 of 3031 > > > > when it comes around. > > > > > > possibly - or 3032? > > > > > > > I thought [y, s=1] hashed the same as [y, s=0] if we simply > > > skipped 's' ;-) > > > > > > it does. > > > > > > but not the same as [y, s=0][z, s=1]. > > > > > > > later > > > > Dave > > > > > > > > > -----Original Message----- > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > Sent: Monday, April 15, 2002 3:20 PM > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > Cc: mpls@UU.NET > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 17:59, David Allan wrote: > > > > > > My comment was that this would be true for any > > > > > detection/diagnotic tool > > > > > > discussed. e.g. use of explicit V4 label to permit ICMP > > > > > ping to be used for > > > > > > non-IP LSPs or use GTTP to explore non-IP LSPs or to > > > > > measure anything such > > > > > > as DSCP RTT. > > > > > > > > > > oh, okay. > > > > > > > > > > > That to me is sufficient reason to suggest that in a load > > > > > sharing scenario, > > > > > > the answer should be the same for the combination of label > > > > > and exp bits. S > > > > > > bit and TTL MUST be excluded.... > > > > > > > > > > in fact it should probably just be the label (and not the > > > EXP bits) as > > > > > the EXP bits may be describing different drop precedences > > > within the > > > > > same queue? > > > > > > > > > > but we still have the problem of needing to know the stack depth > > > > > a-priori (or of figuring out a way to make [Y, S=1] hash > > > to the same > > > > > link as [Y, S=0][OAM, S=1]). > > > > > > > > > > Giles > > > > > > > > > > > cheers > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > > > Sent: Monday, April 15, 2002 2:47 PM > > > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > > > sob@harvard.edu; > > > > > > > mpls@UU.NET > > > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 17:38, David Allan wrote: > > > > > > > > Thanks Giles, > > > > > > > > > > > > > > > > I understand the scenario you are discussing and the S bit > > > > > > > is a legit issue. > > > > > > > > To re-use your pictures, I was considering when y=OAM > > > > > > > alert, not OAM alert > > > > > > > > under 'y'. > > > > > > > > > > > > > > > > But ultimately I think the problem exists independently of > > > > > > > the OAM alert > > > > > > > > label. It would also be true if any reserved label (e.g. > > > > > > > explicit V4 label) > > > > > > > > was used, and suggests that for stuff to function > > > correctly your > > > > > > > > implementation should only be looking one label further > > > > > > > into the stack and > > > > > > > > MUST ignore the S bit. The existence of reserved labels > > > > > > > means that hashing > > > > > > > > more than one label deep has problems, and including the S > > > > > > > bit has problems. > > > > > > > > Implementation wise this may not be the case today, but > > > > > > > live and learn ;-) > > > > > > > > > > > > > > Yes, this "problem" exists for other traffic, but it only > > > > > > > matters in the > > > > > > > OAM case - where the aim is for the OAM traffic to follow the > > > > > > > same path > > > > > > > as the user traffic. > > > > > > > > > > > > > > If I have Internet traffic from PE A to PE B and this > > > follows a > > > > > > > different path to a draft-martini circuit from PE A to PE B > > > > > > > (i.e. where > > > > > > > there is an extra label) then I don't care. All I care > > > > > about is that > > > > > > > all the traffic for a given draft-martini circuit > > > between A and B > > > > > > > follows the same path. > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > > This preserves any detection properties for any tools > > > > > > > employed regardless of > > > > > > > > the type used, payload used etc. > > > > > > > > > > > > > > > > cheers > > > > > > > > Dave > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > > > > > Sent: Monday, April 15, 2002 2:28 PM > > > > > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > > > > > sob@harvard.edu; > > > > > > > > > mpls@UU.NET > > > > > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 16:59, David Allan wrote: > > > > > > > > > > Giles: > > > > > > > > > > > > > > > > > > > > So then why does whether or not the S bit is > > > set matter? > > > > > > > > > > > > > > > > > > perhaps a picture would help? > > > > > > > > > > > > > > > > > > Say an LSR switches a packet with the following stack: > > > > > > > > > > > > > > > > > > |--------|--------| > > > > > > > > > | X, S=0 | Y, S=1 | > > > > > > > > > |--------|--------| > > > > > > > > > > > > > > > > > > It has an L-FIB entry for X that has n equal cost paths. > > > > > > > > > > > > > > > > > > What we would like to be able to do is to hash across the > > > > > > > > > entire stack. > > > > > > > > > This way a second packet with the following stack: > > > > > > > > > > > > > > > > > > |--------|--------| > > > > > > > > > | X, S=0 | Z, S=1 | > > > > > > > > > |--------|--------| > > > > > > > > > > > > > > > > > > can use a different one of the n equal cost paths > > > (depending > > > > > > > > > on the hash > > > > > > > > > function and the values of Y and Z of course). > > > > > > > > > > > > > > > > > > However the problem arises if you have MPLS OAM and the > > > > > > > > > following packet > > > > > > > > > is sent: > > > > > > > > > > > > > > > > > > |--------|--------|--------| > > > > > > > > > | X, S=0 | Y, S=0 |14, S=1 | > > > > > > > > > |--------|--------|--------| > > > > > > > > > > > > > > > > > > If the hash includes the S bit then this will most likely > > > > > > > be sent on a > > > > > > > > > different link to the first packet. > > > > > > > > > > > > > > > > > > Likewise if the hash includes *all* labels then this will > > > > > > > > > most likely be > > > > > > > > > sent on a different link. > > > > > > > > > > > > > > > > > > So what you need is to know a-priori the minimal depth of > > > > > > > stack for > > > > > > > > > non-OAM traffic and hash over that number of labels. But > > > > > > > > > this coarsens > > > > > > > > > the granularity of the load balancing, and also requires > > > > > > > > > configuration - > > > > > > > > > unless you take the most simplistic approach and hash > > > > > > > only using the > > > > > > > > > first label (which barely qualifies as load balancing). > > > > > > > > > > > > > > > > > > > Seem to me that both scenarios need to be > > > covered unless I > > > > > > > > > was producing a > > > > > > > > > > very specialized implementation.... > > > > > > > > > > - the current label is also the bottom label > > > > > > > > > > - the current label is not the bottom label and > > > the label > > > > > > > > > underneath may be > > > > > > > > > > transport or reserved. > > > > > > > > > > > > > > > > > > not sure what you mean by "current" label. Do you mean > > > > > > > the label you > > > > > > > > > are switching on? > > > > > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > > > > > > cheers > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > > > > > > > Sent: Monday, April 15, 2002 11:07 AM > > > > > > > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > > > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > > > > > > > sob@harvard.edu; > > > > > > > > > > > mpls@UU.NET > > > > > > > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 13:40, David Allan wrote: > > > > > > > > > > > > Giles: > > > > > > > > > > > > > > > > > > > > > > > > A clarification... > > > > > > > > > > > > > > > > > > > > > > > > > which means that intermediate LSRs that use a > > > > > > > hash to load > > > > > > > > > > > > > balance MPLS > > > > > > > > > > > > > traffic over equal cost links/paths have to > > > > > be careful to > > > > > > > > > > > > > exclude the S > > > > > > > > > > > > > bit from any hash. > > > > > > > > > > > > > > > > > > > > > > > > If I am inverse muxing an LSP at an > > > > > intermadiate LSR, is > > > > > > > > > > > this not on the > > > > > > > > > > > > basis of some hashing on the payload for the > > > > > current label, > > > > > > > > > > > which could be > > > > > > > > > > > > more labels...I'm not quite getting your example. > > > > > > > > > > > > > > > > > > > > > > effectively yes, you are hashing on the > > > payload for the > > > > > > > > > > > current label - > > > > > > > > > > > given that it includes more labels. So, for > > > example, an > > > > > > > > > LSR switching > > > > > > > > > > > based on an LDP-assigned label might have a set > > > > > of equal cost > > > > > > > > > > > next hops > > > > > > > > > > > in its IGP - across which it could load balance > > > > > traffic based > > > > > > > > > > > on a hash > > > > > > > > > > > which includes the draft-martini label inside > > > that LDP > > > > > > > > > assigned label > > > > > > > > > > > (though of course it wouldn't know whether the inner > > > > > > > > > label was being > > > > > > > > > > > used for draft-martini, for MPLS VPN, or for > > > > > > > something else...) > > > > > > > > > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > ================================================================= > > > > > > > > > > > Giles Heron Principal Network Architect > > > > > > > PacketExchange Ltd. > > > > > > > > > > > ph: +44 7880 506185 "if you build it > > > > > > > they will yawn" > > > > > > > > > > > > > > > > > > > > > ================================================================= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > ================================================================= > > > > > > > > > Giles Heron Principal Network Architect > > > > > PacketExchange Ltd. > > > > > > > > > ph: +44 7880 506185 "if you build it > > > > > they will yawn" > > > > > > > > > > > > > > ================================================================= > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > ================================================================= > > > > > > > Giles Heron Principal Network Architect > > > PacketExchange Ltd. > > > > > > > ph: +44 7880 506185 "if you build it > > > they will yawn" > > > > > > > > > > ================================================================= > > > > > > > > > > > > > > > > > > > -- > > > > > ================================================================= > > > > > Giles Heron Principal Network Architect PacketExchange Ltd. > > > > > ph: +44 7880 506185 "if you build it they will yawn" > > > > > ================================================================= > > > > > > > > > > > > > -- > > > ================================================================= > > > Giles Heron Principal Network Architect PacketExchange Ltd. > > > ph: +44 7880 506185 "if you build it they will yawn" > > > ================================================================= > > > > -- > ================================================================= > Giles Heron Principal Network Architect PacketExchange Ltd. > ph: +44 7880 506185 "if you build it they will yawn" > ================================================================= -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Mon Apr 15 15:07:14 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03254 for ; Mon, 15 Apr 2002 15:07:14 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmksq25403; Mon, 15 Apr 2002 19:02:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksq05905 for mpls-outgoing; Mon, 15 Apr 2002 19:01: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 QQmksq05689 for ; Mon, 15 Apr 2002 19:01: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 QQmksq26501 for ; Mon, 15 Apr 2002 19:01:15 GMT Received: from rincewind.office.packetexchange.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [212.113.11.114]) id QQmksq13872 for ; Mon, 15 Apr 2002 19:01:14 GMT Received: from [80.253.97.67] (helo=gizpad.packetexchange.net) by rincewind.office.packetexchange.net with esmtp (Exim 3.12 #1 (Debian)) id 16xBeI-0004hv-00; Mon, 15 Apr 2002 19:56:22 +0100 Subject: RE: response to ITU-T SG13 From: Giles Heron To: David Allan Cc: mpls@UU.NET In-Reply-To: <3549C09B853DD5119B540002A52CDD3402C6E63B@zcard0ka.ca.nortel.com> References: <3549C09B853DD5119B540002A52CDD3402C6E63B@zcard0ka.ca.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 15 Apr 2002 19:56:47 +0000 Message-Id: <1018900607.1131.359.camel@gizzer> Mime-Version: 1.0 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2002-04-15 at 18:51, David Allan wrote: > Okay, I'll bite, > > If the goal is that [y,s=0] and [y,s=1] have common forwarding for things to > work, where does [y,s=0][z,s=1] enter the picture? because z is the OAM label (or explicit null in the LSP ping case). (common forwarding for [y, s=0] and [y, s=1] is not a goal of mine for arbitrary labels following z - since the only way to do this is to decide a-priori the depth of hash you want to use). > I understand YOU want to hash more than one label deep, and if folks agree > that this is required to get the sort of "smoothness" they want (implying > some binding of quantity of traffic to existence of a label) then we need a > solution like: > > [y,s=1] or [y,s=0 & z <16] should hash to the same outgoing label... > > In order to ensure that there are no future collisions between your hashing > algorithm and the reserved label space. I could go for that! that might work. In any case I think in general people want to hash the entire stack - since this gives maximum "smoothness" with minimum "configuration" :) Giles > cheers > Dave > > > -----Original Message----- > > From: Giles Heron [mailto:giles@packetexchange.net] > > Sent: Monday, April 15, 2002 3:34 PM > > To: Allan, David [CAR:NS00:EXCH] > > Cc: mpls@UU.NET > > Subject: RE: response to ITU-T SG13 > > > > > > On Mon, 2002-04-15 at 18:25, David Allan wrote: > > > Giles: > > > > > > Agreed that EXP drop preference is an issue. Looks like we > > may converge on > > > the label only... IMHO some of this should be captured in > > sect 3.12 of 3031 > > > when it comes around. > > > > possibly - or 3032? > > > > > I thought [y, s=1] hashed the same as [y, s=0] if we simply > > skipped 's' ;-) > > > > it does. > > > > but not the same as [y, s=0][z, s=1]. > > > > > later > > > Dave > > > > > > > -----Original Message----- > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > Sent: Monday, April 15, 2002 3:20 PM > > > > To: Allan, David [CAR:NS00:EXCH] > > > > Cc: mpls@UU.NET > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > On Mon, 2002-04-15 at 17:59, David Allan wrote: > > > > > My comment was that this would be true for any > > > > detection/diagnotic tool > > > > > discussed. e.g. use of explicit V4 label to permit ICMP > > > > ping to be used for > > > > > non-IP LSPs or use GTTP to explore non-IP LSPs or to > > > > measure anything such > > > > > as DSCP RTT. > > > > > > > > oh, okay. > > > > > > > > > That to me is sufficient reason to suggest that in a load > > > > sharing scenario, > > > > > the answer should be the same for the combination of label > > > > and exp bits. S > > > > > bit and TTL MUST be excluded.... > > > > > > > > in fact it should probably just be the label (and not the > > EXP bits) as > > > > the EXP bits may be describing different drop precedences > > within the > > > > same queue? > > > > > > > > but we still have the problem of needing to know the stack depth > > > > a-priori (or of figuring out a way to make [Y, S=1] hash > > to the same > > > > link as [Y, S=0][OAM, S=1]). > > > > > > > > Giles > > > > > > > > > cheers > > > > > Dave > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > > Sent: Monday, April 15, 2002 2:47 PM > > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > > sob@harvard.edu; > > > > > > mpls@UU.NET > > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 17:38, David Allan wrote: > > > > > > > Thanks Giles, > > > > > > > > > > > > > > I understand the scenario you are discussing and the S bit > > > > > > is a legit issue. > > > > > > > To re-use your pictures, I was considering when y=OAM > > > > > > alert, not OAM alert > > > > > > > under 'y'. > > > > > > > > > > > > > > But ultimately I think the problem exists independently of > > > > > > the OAM alert > > > > > > > label. It would also be true if any reserved label (e.g. > > > > > > explicit V4 label) > > > > > > > was used, and suggests that for stuff to function > > correctly your > > > > > > > implementation should only be looking one label further > > > > > > into the stack and > > > > > > > MUST ignore the S bit. The existence of reserved labels > > > > > > means that hashing > > > > > > > more than one label deep has problems, and including the S > > > > > > bit has problems. > > > > > > > Implementation wise this may not be the case today, but > > > > > > live and learn ;-) > > > > > > > > > > > > Yes, this "problem" exists for other traffic, but it only > > > > > > matters in the > > > > > > OAM case - where the aim is for the OAM traffic to follow the > > > > > > same path > > > > > > as the user traffic. > > > > > > > > > > > > If I have Internet traffic from PE A to PE B and this > > follows a > > > > > > different path to a draft-martini circuit from PE A to PE B > > > > > > (i.e. where > > > > > > there is an extra label) then I don't care. All I care > > > > about is that > > > > > > all the traffic for a given draft-martini circuit > > between A and B > > > > > > follows the same path. > > > > > > > > > > > > Giles > > > > > > > > > > > > > This preserves any detection properties for any tools > > > > > > employed regardless of > > > > > > > the type used, payload used etc. > > > > > > > > > > > > > > cheers > > > > > > > Dave > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > > > > Sent: Monday, April 15, 2002 2:28 PM > > > > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > > > > sob@harvard.edu; > > > > > > > > mpls@UU.NET > > > > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 16:59, David Allan wrote: > > > > > > > > > Giles: > > > > > > > > > > > > > > > > > > So then why does whether or not the S bit is > > set matter? > > > > > > > > > > > > > > > > perhaps a picture would help? > > > > > > > > > > > > > > > > Say an LSR switches a packet with the following stack: > > > > > > > > > > > > > > > > |--------|--------| > > > > > > > > | X, S=0 | Y, S=1 | > > > > > > > > |--------|--------| > > > > > > > > > > > > > > > > It has an L-FIB entry for X that has n equal cost paths. > > > > > > > > > > > > > > > > What we would like to be able to do is to hash across the > > > > > > > > entire stack. > > > > > > > > This way a second packet with the following stack: > > > > > > > > > > > > > > > > |--------|--------| > > > > > > > > | X, S=0 | Z, S=1 | > > > > > > > > |--------|--------| > > > > > > > > > > > > > > > > can use a different one of the n equal cost paths > > (depending > > > > > > > > on the hash > > > > > > > > function and the values of Y and Z of course). > > > > > > > > > > > > > > > > However the problem arises if you have MPLS OAM and the > > > > > > > > following packet > > > > > > > > is sent: > > > > > > > > > > > > > > > > |--------|--------|--------| > > > > > > > > | X, S=0 | Y, S=0 |14, S=1 | > > > > > > > > |--------|--------|--------| > > > > > > > > > > > > > > > > If the hash includes the S bit then this will most likely > > > > > > be sent on a > > > > > > > > different link to the first packet. > > > > > > > > > > > > > > > > Likewise if the hash includes *all* labels then this will > > > > > > > > most likely be > > > > > > > > sent on a different link. > > > > > > > > > > > > > > > > So what you need is to know a-priori the minimal depth of > > > > > > stack for > > > > > > > > non-OAM traffic and hash over that number of labels. But > > > > > > > > this coarsens > > > > > > > > the granularity of the load balancing, and also requires > > > > > > > > configuration - > > > > > > > > unless you take the most simplistic approach and hash > > > > > > only using the > > > > > > > > first label (which barely qualifies as load balancing). > > > > > > > > > > > > > > > > > Seem to me that both scenarios need to be > > covered unless I > > > > > > > > was producing a > > > > > > > > > very specialized implementation.... > > > > > > > > > - the current label is also the bottom label > > > > > > > > > - the current label is not the bottom label and > > the label > > > > > > > > underneath may be > > > > > > > > > transport or reserved. > > > > > > > > > > > > > > > > not sure what you mean by "current" label. Do you mean > > > > > > the label you > > > > > > > > are switching on? > > > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > > > > cheers > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Giles Heron [mailto:giles@packetexchange.net] > > > > > > > > > > Sent: Monday, April 15, 2002 11:07 AM > > > > > > > > > > To: Allan, David [CAR:NS00:EXCH] > > > > > > > > > > Cc: neil.2.harrison@bt.com; kireeti@juniper.net; > > > > > > sob@harvard.edu; > > > > > > > > > > mpls@UU.NET > > > > > > > > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 2002-04-15 at 13:40, David Allan wrote: > > > > > > > > > > > Giles: > > > > > > > > > > > > > > > > > > > > > > A clarification... > > > > > > > > > > > > > > > > > > > > > > > which means that intermediate LSRs that use a > > > > > > hash to load > > > > > > > > > > > > balance MPLS > > > > > > > > > > > > traffic over equal cost links/paths have to > > > > be careful to > > > > > > > > > > > > exclude the S > > > > > > > > > > > > bit from any hash. > > > > > > > > > > > > > > > > > > > > > > If I am inverse muxing an LSP at an > > > > intermadiate LSR, is > > > > > > > > > > this not on the > > > > > > > > > > > basis of some hashing on the payload for the > > > > current label, > > > > > > > > > > which could be > > > > > > > > > > > more labels...I'm not quite getting your example. > > > > > > > > > > > > > > > > > > > > effectively yes, you are hashing on the > > payload for the > > > > > > > > > > current label - > > > > > > > > > > given that it includes more labels. So, for > > example, an > > > > > > > > LSR switching > > > > > > > > > > based on an LDP-assigned label might have a set > > > > of equal cost > > > > > > > > > > next hops > > > > > > > > > > in its IGP - across which it could load balance > > > > traffic based > > > > > > > > > > on a hash > > > > > > > > > > which includes the draft-martini label inside > > that LDP > > > > > > > > assigned label > > > > > > > > > > (though of course it wouldn't know whether the inner > > > > > > > > label was being > > > > > > > > > > used for draft-martini, for MPLS VPN, or for > > > > > > something else...) > > > > > > > > > > > > > > > > > > > > Giles > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > ================================================================= > > > > > > > > > > Giles Heron Principal Network Architect > > > > > > PacketExchange Ltd. > > > > > > > > > > ph: +44 7880 506185 "if you build it > > > > > > they will yawn" > > > > > > > > > > > > > > > > > > ================================================================= > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > ================================================================= > > > > > > > > Giles Heron Principal Network Architect > > > > PacketExchange Ltd. > > > > > > > > ph: +44 7880 506185 "if you build it > > > > they will yawn" > > > > > > > > > > > > ================================================================= > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > ================================================================= > > > > > > Giles Heron Principal Network Architect > > PacketExchange Ltd. > > > > > > ph: +44 7880 506185 "if you build it > > they will yawn" > > > > > > > > ================================================================= > > > > > > > > > > > > > > > > -- > > > > ================================================================= > > > > Giles Heron Principal Network Architect PacketExchange Ltd. > > > > ph: +44 7880 506185 "if you build it they will yawn" > > > > ================================================================= > > > > > > > > > > -- > > ================================================================= > > Giles Heron Principal Network Architect PacketExchange Ltd. > > ph: +44 7880 506185 "if you build it they will yawn" > > ================================================================= > > -- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" ================================================================= From owner-mpls@UU.NET Mon Apr 15 15:32:46 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04117 for ; Mon, 15 Apr 2002 15:32:46 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkss08366; Mon, 15 Apr 2002 19:31:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkss23823 for mpls-outgoing; Mon, 15 Apr 2002 19:30:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmkss23816 for ; Mon, 15 Apr 2002 19:30:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkss22264 for ; Mon, 15 Apr 2002 19:30:05 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmkss15423 for ; Mon, 15 Apr 2002 19:30:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA15715 for ; Mon, 15 Apr 2002 15:30:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA13579 for mpls@uu.net; Mon, 15 Apr 2002 15:30:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmksn27843 for ; Mon, 15 Apr 2002 18:27:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmksn28697 for ; Mon, 15 Apr 2002 18:27:02 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmksn28076 for ; Mon, 15 Apr 2002 18:27:01 GMT Received: (qmail 17200 invoked by uid 104); 15 Apr 2002 18:26:57 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4196. . Clean. Processed in 0.470068 secs); 15 Apr 2002 18:26:57 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 15 Apr 2002 18:26:56 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g3FIQqp23615; Mon, 15 Apr 2002 11:26:53 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Apr 2002 11:26:57 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A6FB@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" Cc: "'Scott Bradner'" , mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 11:26:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric, > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Monday, April 15, 2002 2:20 PM > To: Shahram Davari > Cc: 'Scott Bradner'; mpls@UU.NET > Subject: Re: response to ITU-T SG13 > > > > Shahram> Some vendors may have implemented their MPLS > data-plane in hardware > Shahram> and some in software. Why should a vendor's > implementation be a > Shahram> concern for a standard body such as IETF? > > Shahram> I don't think specific implementations should be a > concern for a > Shahram> standard body such as IETF. You could always > find a specific > Shahram> implementations that can't support a new function. > Any objection > Shahram> regarding backward compatibility should be based on > a standard. > > Are you saying that the characteristics of existing > deployments and > implementations should deliberately be ignored by the WG > as it makes its > decisions? No. I am saying that a specific implementation by a specific vendor/ operator should not be the basis for any standard argument. If most vendors/operators implement a function in the same manner, then that is a different story. But still an alternative solution should exist, otherwise it is best to have a solution rather than nothing at all. > > I'd have to disagree. If one is trying to produce > solutions which solve > real problems for real people, and which will be adopted by > the real market, > then one is well-advised to take the existing situation into > consideration. > > I am not aware of any IETF policy or precedent that says to > ignore existing > implementations or deployments. I am not also aware of any IETF policy that says take to account vendor "X"'s implementation. -Shahram > From owner-mpls@UU.NET Mon Apr 15 15:50:52 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04664 for ; Mon, 15 Apr 2002 15:50:52 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkst04744; Mon, 15 Apr 2002 19:48:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkst25571 for mpls-outgoing; Mon, 15 Apr 2002 19:48: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 QQmkst25566 for ; Mon, 15 Apr 2002 19:48: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 QQmkst15013 for ; Mon, 15 Apr 2002 19:47:33 GMT From: neil.2.harrison@bt.com Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmkst11351 for ; Mon, 15 Apr 2002 19:47:32 GMT Received: by mbibipnt08.hc.bt.com with Internet Mail Service (5.5.2653.19) id <2XKCCWGH>; Mon, 15 Apr 2002 20:47:38 +0100 Message-ID: To: giles@packetexchange.net Cc: mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 20:47:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Giles Heron wrote 15 April 2002 19:02 > > Not all technologies below IP are CO. What about the most common link > layer for IP - Ethernet? > > Sure, Ethernets run over wires (which are inherently CO). > But then what > about 802.11b wireless LANs? Not much CO going on there AFAIK. > > But yes, as someone who connects IP routers for a living, I am well > aware that in the wide area IP runs over CO technologies ;-) NH=> You answered your own question I see, and this is why I stated WAN connectivity for this reason.....as ethernet, being broadcast in true native mode, cannot span the wide area. BTW - Not sure if you are aware but IEEE are looking at OAM for ethernet....I assume in a p2p mode.....and I understand similar connectivity verification checks are being considered, though I have not had the time to look at the details. > > At any rate, your "yes" answer gives me cause for concern. If you > require strictly CO trails (i.e. TE) at *all* lower layers in order to > use OAM at a higher layer then OAM would seem to have quite limited > utility? NH=> My answer 'yes' was in respect of the need for *independent trail management* of a client/server set of lower level co trails. But of course you don't have to run, or maybe you can't run, OAM on all of these. One obvious example is where you are virtualising link-connectivity at layer N (which you own say) by leasing a trail at layer N+1 (which you don't own).....and as I am sure you know this happens all the time between operators when they want to increase their geographic reach and don't own all the layers to the duct. The one thing you should not do however, is ask the OAM functions of 1 layer network to proxy for such functionality which is missing in either a client or server layer network. Not only is there a layer network ownership issue as in the example above, but the trails won't usually be congruent (ie the server trail is only a link-connection, ie 1-hop, in the client layer network trail), and its a layer violation anyway. No doubt you will recall we discussed such a problem on the PWE3 list recently in respect of the Brayley draft, which has just such a violation in asking SDH/Sonet FDI to proxy for ATM layer failures. However, if you ran p2p LSPs over mp2p LSPs (which is what rfc2547 VPNs using a server LDP-based layer is) then in theory you could run OAM on the top layer LSPs (to check their connectivity) and not use OAM on the lower layer LSPs. regards, Neil From owner-mpls@UU.NET Mon Apr 15 16:00:32 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05069 for ; Mon, 15 Apr 2002 16:00:32 -0400 (EDT) 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 QQmkst29822; Mon, 15 Apr 2002 19:59:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkst26317 for mpls-outgoing; Mon, 15 Apr 2002 19:59:17 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 QQmkst26312 for ; Mon, 15 Apr 2002 19:59:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmkst09909 for ; Mon, 15 Apr 2002 19:58:12 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQmkst18986 for ; Mon, 15 Apr 2002 19:58:12 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05581 for ; Mon, 15 Apr 2002 15:58:09 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA01132 for ; Mon, 15 Apr 2002 15:58:11 -0400 (EDT) Message-ID: <3CBB30E5.F76B0159@marconi.com> Date: Mon, 15 Apr 2002 15:58:29 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: SE style in optical neyworks References: <20020415045551.94063.qmail@web13705.mail.yahoo.com> <3CBADD18.939B522A@marconi.com> <3CBB1708.BE7C32E8@nayna.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sudheer Dharanikota wrote: > David Charlap wrote: >> >> What's the point? >> >> In an optical network, you are signaling wavelengths or time >> slices. How could you conceivably have two time-slices share >> resources? Or two wavelengths? > > Only to imply that a time-slice can be allocated to one of the > *backup* paths when a primary path fails. That's not the definition of SE style. SE style may be used for many things other than signaling backup paths. To assume that SE style can only be used in the way you want is unwarranted. You may end up with undefined behavior if you do. If you need a mechanism for explicitly indicating which LSPs serve as backups for others, then you should use a mechanism that is meant to do this. If none exists, then you should define one and use this working group to make it into a standard. Unilaterally assigning a new and undocumented meaning to an existing construct is never a good idea. -- David From owner-mpls@UU.NET Mon Apr 15 16:31:40 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06011 for ; Mon, 15 Apr 2002 16:31:39 -0400 (EDT) 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 QQmksw18492; Mon, 15 Apr 2002 20:30:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksw19609 for mpls-outgoing; Mon, 15 Apr 2002 20:30:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmksw19604 for ; Mon, 15 Apr 2002 20:30:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmksw05458 for ; Mon, 15 Apr 2002 20:30:29 GMT From: neil.2.harrison@bt.com Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmksw17727 for ; Mon, 15 Apr 2002 20:30:28 GMT Received: by mbibipnt08.hc.bt.com with Internet Mail Service (5.5.2653.19) id <2XKCCWRF>; Mon, 15 Apr 2002 21:30:34 +0100 Message-ID: To: giles@packetexchange.net, dallan@nortelnetworks.com Cc: mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 21:30:17 +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 Hi Giles.....you wrote 15 April 2002 20:20 > > > but we still have the problem of needing to know the stack depth > a-priori (or of figuring out a way to make [Y, S=1] hash to the same > link as [Y, S=0][OAM, S=1]). > NH=> Well I guess we can thank the orignal MPLS architects for this. Fault management of MPLS was clearly never given sufficient consideration at the outset.....so there is no overhead function which indicates that the payload is not traffic but OAM (or something else). If we had such an overhead function then we would not need to stack labels like this. When we debated this over a year ago I initially wanted to avoid this label stacking by reviewing the need for a whole 8 bit TTL.....256 hops is way overkill IMO. We could have taken a couple of bits out of this to give some ability to indicate a 'non-traffic payload'. However this was deemed unacceptable......and that's why we are where we are now. regards, Neil From owner-mpls@UU.NET Mon Apr 15 16:41:22 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06181 for ; Mon, 15 Apr 2002 16:41:21 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmksw29434; Mon, 15 Apr 2002 20:40:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksw20340 for mpls-outgoing; Mon, 15 Apr 2002 20:40: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 QQmksw20335 for ; Mon, 15 Apr 2002 20:40:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmksw07551 for ; Mon, 15 Apr 2002 20:40:09 GMT Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmksw02765 for ; Mon, 15 Apr 2002 20:40:04 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FKdsa23195; Mon, 15 Apr 2002 16:39:54 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJA3TFG>; Mon, 15 Apr 2002 16:39:54 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402C6E7F1@zcard0ka.ca.nortel.com> From: "David Allan" To: Loa Andersson Cc: Scott Bradner , mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Mon, 15 Apr 2002 16:39:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4BD.B263A552" 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_01C1E4BD.B263A552 Content-Type: text/plain; charset="iso-8859-1" Hi Loa: Thanks for having done due dilligence on the PIM reference. The rest of my comments are directed towards the list in general... Last time I looked, MPLS multicast was a completely separate protocol potentially employing a separate forwarding plane/fabric (having a different PID and label space which by definition would have to be disjoint from the unicast MPLS space). I politely flagged this one as I think it is a bit of a stretch to ask the ITU to comment on the effects of Y.1711 on stuff that does not exist and has not yet been specified. This is in addition to asking it's impact on proprietary implementations where to date there has been under-specification (the reserved labels issue with PHP and multi-link load sharing have been raised so far), as well as what protocol extensions may be required to synchronize using this tool (which George/co-chair noted was a trivial issue on the list back on March 21st). I'm really curious to know how any reasonable response to the liaison will be/can be interpreted. What if the techology is OK but study group 13's crystal ball is found wanting? Would that be a good reason to hold things up...I don't think so. cheers Dave > -----Original Message----- > From: Loa Andersson [mailto:loa.andersson@utfors.se] > Sent: Monday, April 15, 2002 10:35 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: Scott Bradner; mpls@UU.NET > Subject: Re: response to ITU-T SG13 > > > All, > > did read this before it was sent. I thought that PIM came in via the > mpls multicast framework, just now processed by the IESG to the > rfc-editor. See e.g. page 18 in the framework: > > "a) Multicast routing messages: protocols as PIM-SM and CBT have > explicit Join messages which could carry the label mappings. This > approach is described in [FARI]. When different multicast routing > protocols are deployed, an extension to each of these > protocols has > to be defined." > > But I might be wrong. The [FARI] did not go anywhere did it? > > /loa > > David Allan wrote: > > > Hi Scott: > > > > I think readability would be enhanced if the third paragraph was > > deleted..."Since manual configuration .... before Y.1711 > would be seen > > as a complete solution."....The third para discusses if changes to > > CR-LDP and RSVP are expected and a few paragraphs later the > question is > > enlarged to include LDP, PIM and BGP. > > > > I'll plead ignorance, but I'm not sure why PIM is on the list...? > > > > cheers > > Dave > > > > > > > -----Original Message----- > > > From: Scott Bradner [mailto:sob@harvard.edu] > > > Sent: Friday, April 12, 2002 4:45 PM > > > To: mpls@UU.NET > > > Subject: response to ITU-T SG13 > > > > > > > > > > > > This is the response to > > > http://www.ietf.org/IESG/LIAISON/ITU-SG13-MPLS-OAM.txt > > > that was discussed during the MPLS session in Minneapolis > > > that I plan to > > > send early next week unless the WG has a problem with that. > > > (Thanks to George for the draft that this is based on) > > > > > > Scott > > > > > > --------- > > > > > > SOURCE: IETF Sub-IP Area - Scott Bradner, Area co-Director > > > TITLE: Response to "Communication on the status of the > request on the > > > assignment of a reserved label value for MPLS OAM packet > > > identification" > > > > > > The MPLS working group discussed SG 13's request for the > > > assignment of a > > > reserved label value for MPLS OAM packet identification > > > (draft-ohta-mpls-label-value-01.txt) during the MPLS session > > > during the > > > recent IETF meeting in Minneapolis. There was some > > > disagreement during the > > > discussion about the long term implications of the IETF > granting this > > > request. > > > > > > During the discussion it was noted that there are a number of > > > references to > > > modifications to IETF protocols in Y.1711. In > particular, Section 6.1 > > > states, "Ideally this should be done automatically via LSP > > > signaling at > > > LSP set-up time (e.g. via a CR-LDP or RSVP control-plane > > > mechanism), but > > > it could also be configured manually. The mechanism for > > > achieving this > > > configuration is outside the scope of this Recommendation." > > > > > > Since manual configuration is probably not an option for > > > anything beyond a > > > very limited deployment the implication is that the ITU will > > > require the > > > IETF to change CR-LDP and RSVP before Y.1711 would be seen as > > > a complete > > > solution. > > > > > > Also in section 6.3, Forward Defect Indication, the following > > > text may be > > > read as indicating an assumption of future changes in > IETF protocols > > > dealing with LSP signaling. > > > > > > "It is important that the LSP sink point knows (for the > > > duration that the > > > LSP is in service) any server->client LSP label mappings > that were in > > > existence prior to the defect. Although the exact means for > > > achieving this > > > are outside the scope of this Recommendation, some examples > > > of how these > > > server-> client layer label mappings could be configured are > > > as follows: > > > o manually, via the NMS say; > > > o automatically on LSP set-up via extensions to LSP > signaling ..." > > > > > > In order to understand the possible consequences of > allocating an MPLS > > > codepoint in response to the request in > > > draft-ohta-mpls-label-value-01.txt > > > the MPLS working group would like to understand the full > > > scope and extent > > > of the modifications that SG13 may be assuming to other IETF > > > protocols, > > > including LDP, CR-LDP, RSVP, PIM and BGP. > > > > > > A further concern is the impact on the MPLS forwarding plane > > > as currently > > > defined. In certain points in a MPLS network, based on an > > > incoming label, > > > the label is removed and the packet is forwarded with no > > > further inspection > > > of subsequent headers (be it another MPLS label or some > other header). > > > Y.1711 seems to imply that the above behavior would not > > > satisfy Y.1711. > > > Specifically, there are some cases where Y.1711 would > expect a network > > > element to intercept an OAM packet. This raises issues > of backward > > > compatibility with existing MPLS systems and ASICs. > > > > > > The MPLS working group would like to understand if Y.1711 assumes > > > functionally that could not be supported by simply changing > > > software in > > > existing MPLS implementations. > > > > > > > > > > > > > > -- > Loa Andersson > Chief Architect, > Utfors Research, Architecture and Future Lab (URAX) > Utfors AB > Råsundavägen 12 > Box 525, 169 29 Solna > Office +46 8 5270 2000 > Office direct +46 8 5270 5038 > Mobile +46 70 848 5038 > Email loa.andersson@utfors.se > WWW www.utfors.se > > ------_=_NextPart_001_01C1E4BD.B263A552 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: response to ITU-T SG13

Hi Loa:

Thanks for having done due dilligence on the PIM = reference. The rest of my comments are directed towards the list in = general...

Last time I looked, MPLS multicast was a completely = separate protocol potentially employing a separate forwarding = plane/fabric (having a different PID and label space which by = definition would have to be disjoint from the unicast MPLS space). =

I politely flagged this one as I think it is a bit of = a stretch to ask the ITU to comment on the effects of Y.1711 on stuff = that does not exist and has not yet been specified. This is in addition = to asking it's impact on proprietary implementations where to date = there has been under-specification (the reserved labels issue with PHP = and multi-link load sharing have been raised so far), as well as what = protocol extensions may be required to synchronize using this tool = (which George/co-chair noted was a trivial issue on the list back on = March 21st).

I'm really curious to know how any reasonable = response to the liaison will be/can be interpreted. What if the = techology is OK but study group 13's crystal ball is found wanting? = Would that be a good reason to hold things up...I don't think = so.

cheers
Dave



> -----Original Message-----
> From: Loa Andersson [mailto:loa.andersson@utfors.se]
> Sent: Monday, April 15, 2002 10:35 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: Scott Bradner; mpls@UU.NET
> Subject: Re: response to ITU-T SG13
>
>
> All,
>
> did read this before it was sent. I thought = that PIM came in via the
> mpls multicast framework, just now processed by = the IESG to the
> rfc-editor. See e.g. page 18 in the = framework:
>
> "a) Multicast routing messages: protocols = as PIM-SM and CBT have
>     explicit Join messages = which could carry the label mappings.  This
>     approach is described = in [FARI].  When different multicast routing
>     protocols are deployed, = an extension to each of these
> protocols has
>     to be = defined."
>
> But I might be wrong. The [FARI] did not go = anywhere did it?
>
> /loa
>
> David Allan wrote:
>
> > Hi Scott:
> >
> > I think readability would be enhanced if = the third paragraph was
> > deleted..."Since manual configuration = .... before Y.1711
> would be seen
> > as a complete solution."....The third = para discusses if changes to
> > CR-LDP and RSVP are expected and a few = paragraphs later the
> question is
> > enlarged to include LDP, PIM and = BGP.
> >
> > I'll plead ignorance, but I'm not sure why = PIM is on the list...?
> >
> > cheers
> > Dave
> >
> >
> >  > -----Original = Message-----
> >  > From: Scott Bradner [mailto:sob@harvard.edu]
> >  > Sent: Friday, April 12, 2002 = 4:45 PM
> >  > To: mpls@UU.NET
> >  > Subject: response to ITU-T = SG13
> >  >
> >  >
> >  >
> >  > This is the response to
> >  > http://www.ietf.org/IESG/LIAISON/ITU-SG13-MPLS-OAM.txt=
> >  > that was discussed during the = MPLS session in Minneapolis
> >  > that I plan to
> >  > send early next week unless the = WG has a problem with that.
> >  > (Thanks to George for the draft = that this is based on)
> >  >
> >  > Scott
> >  >
> >  > ---------
> >  >
> >  > SOURCE: IETF Sub-IP Area - = Scott Bradner, Area co-Director
> >  > TITLE: Response to = "Communication on the status of the
> request on the
> >  >   assignment of a = reserved label value for MPLS OAM packet
> >  > identification"
> >  >
> >  > The MPLS working group = discussed SG 13's request for the
> >  > assignment of a
> >  > reserved label value for MPLS = OAM packet identification
> >  > = (draft-ohta-mpls-label-value-01.txt) during the MPLS session
> >  > during the
> >  > recent IETF meeting in = Minneapolis.  There was some
> >  > disagreement during the
> >  > discussion about the long term = implications  of the IETF
> granting this
> >  > request.
> >  >
> >  > During the discussion it was = noted that there are a number of
> >  > references to
> >  > modifications to IETF protocols = in Y.1711.  In
> particular, Section 6.1
> >  > states, "Ideally this = should be done automatically  via LSP
> >  > signaling at
> >  > LSP set-up time (e.g. via a = CR-LDP or RSVP  control-plane
> >  > mechanism), but
> >  > it could also be configured = manually.   The mechanism for
> >  > achieving this
> >  > configuration is outside the = scope of this Recommendation."
> >  >
> >  > Since manual configuration is = probably not an option for
> >  > anything beyond a
> >  > very limited deployment the = implication is that the ITU will
> >  > require the
> >  > IETF to change CR-LDP and RSVP = before Y.1711 would be seen as
> >  > a complete
> >  > solution.
> >  >
> >  > Also in section 6.3, Forward = Defect Indication, the following
> >  > text may be
> >  > read as indicating an = assumption of future changes in 
> IETF protocols
> >  > dealing with LSP = signaling.
> >  >
> >  > "It is important that the = LSP sink point knows (for the
> >  > duration that the
> >  > LSP is in service) any = server->client LSP label mappings
> that were in
> >  > existence prior to the = defect.  Although the exact means for
> >  > achieving this
> >  > are outside the scope of this = Recommendation, some examples
> >  > of how these
> >  > server-> client layer label = mappings could be configured are
> >  > as follows:
> >  >    o manually, = via the NMS say;
> >  >    o = automatically on LSP set-up via extensions to LSP
> signaling ..."
> >  >
> >  > In order to understand the = possible consequences of
> allocating an MPLS
> >  > codepoint in response to the = request in
> >  > = draft-ohta-mpls-label-value-01.txt
> >  > the MPLS working group would = like to understand the full
> >  > scope and extent
> >  > of the modifications that SG13 = may be assuming to other IETF
> >  > protocols,
> >  > including LDP, CR-LDP, RSVP, = PIM and BGP.
> >  >
> >  > A further concern is the impact = on the MPLS forwarding plane
> >  > as currently
> >  > defined.  In certain = points in a MPLS network, based on an
> >  > incoming label,
> >  > the label is removed and the = packet is forwarded with no
> >  > further inspection
> >  > of subsequent headers (be it = another MPLS label or some
> other header).
> >  > Y.1711 seems to imply that the = above behavior would not
> >  > satisfy Y.1711.
> >  > Specifically, there are some = cases where Y.1711 would
> expect a network
> >  > element to intercept an OAM = packet. This raises issues
> of backward
> >  > compatibility with existing = MPLS systems and ASICs.
> >  >
> >  > The MPLS working group would = like to understand if Y.1711 assumes
> >  > functionally that could not be = supported by simply changing
> >  > software in
> >  > existing MPLS = implementations.
> >  >
> >  >
> >  >
> >
>
>
> --
> Loa Andersson
> Chief Architect,
> Utfors Research, Architecture and Future Lab = (URAX)
> Utfors AB
> R=E5sundav=E4gen 12
> Box 525, 169 29 Solna
> = Office          +46 8 5270 = 2000
> Office direct   +46 8 5270 = 5038
> = Mobile          +46 70 848 = 5038
> = Email           = loa.andersson@utfors.se
> = WWW           &nb= sp; www.utfors.se
>
>

------_=_NextPart_001_01C1E4BD.B263A552-- From owner-mpls@UU.NET Mon Apr 15 17:28:39 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07048 for ; Mon, 15 Apr 2002 17:28:39 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmksz07241; Mon, 15 Apr 2002 21:27:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQmksz15350 for mpls-outgoing; Mon, 15 Apr 2002 21:27: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 QQmksz15345 for ; Mon, 15 Apr 2002 21:27:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmksz06047 for ; Mon, 15 Apr 2002 21:27:24 GMT Received: from smtp1.opnet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.opnet.com [141.156.71.6]) id QQmksz06413 for ; Mon, 15 Apr 2002 21:27:24 GMT Received: from wtn10216.opnet.com (unverified) by smtp1.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Mon, 15 Apr 2002 17:27:19 -0400 Message-Id: <5.0.0.25.2.20020415172501.02b6cd60@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 15 Apr 2002 17:27:20 -0400 To: mpls@UU.NET From: Sachin Kalra Subject: BGP/MPLS VPNs. Draft 2547bis Jan 2002 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Dear All: I would appreciate if I can get answer to the following: If we have two sites "A" and "B" belonging to same VPN "Yellow_VPN", and connected to same PE (different physical interfaces), [CE-site A] / / ......[PE] \ \ [CE-site B] then: 1. Can we specify different Export/Import route targets for each of the site "A" and "B"? Does "Cisco/Juniper/Any other vendor" supports this? I could not find any example (Or just command) for configuring such scenario. Thanks for your response. Sachin Kalra From owner-mpls@UU.NET Mon Apr 15 17:56:42 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07575 for ; Mon, 15 Apr 2002 17:56:41 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmktb17247; Mon, 15 Apr 2002 21:56:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmktb16737 for mpls-outgoing; Mon, 15 Apr 2002 21:55: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 QQmktb16732 for ; Mon, 15 Apr 2002 21:55: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 QQmktb08219 for ; Mon, 15 Apr 2002 21:55: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 QQmktb15942 for ; Mon, 15 Apr 2002 21:55:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA24239 for ; Mon, 15 Apr 2002 17:55:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA29138 for mpls@uu.net; Mon, 15 Apr 2002 17:55:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmktb16518 for ; Mon, 15 Apr 2002 21:51:27 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 QQmktb29962 for ; Mon, 15 Apr 2002 21:50:58 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 QQmktb10425 for ; Mon, 15 Apr 2002 21:50:57 GMT Received: from JVASSEUR-W2K.cisco.com (ams-clip-vpn-dhcp15.cisco.com [10.50.0.14]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA16669; Mon, 15 Apr 2002 23:50:48 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020415235022.04be2d08@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Apr 2002 23:50:41 +0200 To: Sachin Kalra From: Jean Philippe Vasseur Subject: Re: BGP/MPLS VPNs. Draft 2547bis Jan 2002 Cc: mpls@UU.NET In-Reply-To: <5.0.0.25.2.20020415172501.02b6cd60@mail.opnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 17:27 15/04/2002 -0400, Sachin Kalra wrote: >Dear All: > >I would appreciate if I can get answer to the following: > >If we have two sites "A" and "B" belonging to same VPN "Yellow_VPN", and >connected to same PE (different physical interfaces), > > [CE-site A] > / > / >......[PE] > \ > \ > [CE-site B] > >then: >1. Can we specify different Export/Import route targets for each of the >site "A" and "B"? What are you trying to do ? JP. >Does "Cisco/Juniper/Any other vendor" supports this? I could not find any >example (Or just command) for configuring such scenario. > >Thanks for your response. >Sachin Kalra From owner-mpls@UU.NET Mon Apr 15 20:50:24 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10213 for ; Mon, 15 Apr 2002 20:50:23 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmktn20985; Tue, 16 Apr 2002 00:49:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmktn03178 for mpls-outgoing; Tue, 16 Apr 2002 00:49: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 QQmktn03171 for ; Tue, 16 Apr 2002 00:49:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmktn21720 for ; Tue, 16 Apr 2002 00:49: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 QQmktn06192 for ; Tue, 16 Apr 2002 00:49:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA00306 for ; Mon, 15 Apr 2002 20:49:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA15634 for mpls@uu.net; Mon, 15 Apr 2002 20:49:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmktn03045 for ; Tue, 16 Apr 2002 00:47: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 QQmktn27657 for ; Tue, 16 Apr 2002 00:47:35 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQmktn03714 for ; Tue, 16 Apr 2002 00:47:34 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3G0lmej016385; Mon, 15 Apr 2002 20:47:48 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (katie.cisco.com [10.83.99.126]) by bucket.cisco.com (Mirapoint) with ESMTP id AAW91055; Mon, 15 Apr 2002 20:47:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20020415204534.0244d778@bucket> X-Sender: tnadeau@bucket X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 15 Apr 2002 20:47:21 -0400 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: response to ITU-T SG13 Cc: "'erosen@cisco.com'" , "'Scott Bradner'" , mpls@UU.NET In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE84A6FB@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:26 AM 4/15/2002 -0700, Shahram Davari wrote: >Eric, > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Monday, April 15, 2002 2:20 PM > > To: Shahram Davari > > Cc: 'Scott Bradner'; mpls@UU.NET > > Subject: Re: response to ITU-T SG13 > > > > > > > > Shahram> Some vendors may have implemented their MPLS > > data-plane in hardware > > Shahram> and some in software. Why should a vendor's > > implementation be a > > Shahram> concern for a standard body such as IETF? > > > > Shahram> I don't think specific implementations should be a > > concern for a > > Shahram> standard body such as IETF. You could always > > find a specific > > Shahram> implementations that can't support a new function. > > Any objection > > Shahram> regarding backward compatibility should be based on > > a standard. > > > > Are you saying that the characteristics of existing > > deployments and > > implementations should deliberately be ignored by the WG > > as it makes its > > decisions? > >No. I am saying that a specific implementation by a specific vendor/ >operator should not be the basis for any standard argument. If most >vendors/operators >implement a function in the same manner, then that is a different story. >But still an alternative solution should exist, otherwise it is best to have >a solution rather than nothing at all. Why not? The mantra at the IETF is "working code and rough consensus." Sounds like we base things on real implementations around here to me. > > I'd have to disagree. If one is trying to produce > > solutions which solve real problems for real people, and which will be > adopted by > > the real market, then one is well-advised to take the existing > situation into > > consideration. > > > > I am not aware of any IETF policy or precedent that says to > > ignore existing implementations or deployments. > >I am not also aware of any IETF policy that says take to account >vendor "X"'s implementation. See above. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Tue Apr 16 01:40:20 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16033 for ; Tue, 16 Apr 2002 01:40:20 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkug06034; Tue, 16 Apr 2002 05:39:06 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkug09764 for mpls-outgoing; Tue, 16 Apr 2002 05:38:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmkug09759 for ; Tue, 16 Apr 2002 05:38: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 QQmkug15369 for ; Tue, 16 Apr 2002 05:37:11 GMT Received: from samar.sasken.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQmkug04030 for ; Tue, 16 Apr 2002 05:37:08 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g3G5at423964; Tue, 16 Apr 2002 11:06:57 +0530 (IST) Received: from sushanth (pcsva235.sasken.com [10.1.65.235]) by sunsv2.sasken.com (8.11.6/8.11.6) with SMTP id g3G5aqB10948; Tue, 16 Apr 2002 11:06:52 +0530 (IST) From: "sushantm" To: "John Ellson" Cc: , Subject: RE: Control plane and data plane adjacency Date: Tue, 16 Apr 2002 11:08:31 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: High In-Reply-To: <3CBB0136.4090806@lucent.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, You wrote: " Not sure why you want data plane routing information, but the next system IP address will presumably be found from a DNS lookup, just like any other data network conection. " I don't know whether I made myself clear. The issue here is not to get the IP addr of the system, but to find out the system. Lets assume the OCX1 is got more than one neigbhor OCX2,OCX4,OXC5,OXC5. OXC2 neigbhor is OXC3. The LSP has to be setup from OXC1 to OXC3. If RSVP signaling is used I would forward this message to R1 ( This information I would get from the routing table). In the Path message, I need fill up the IF_ID information, which contains the Data channel identifier. At OXC1 there may be many data channels connected many neigbors. I have to choose a data channel Id , which is connected to OXC2. How does the OXC1 takes decision. The OXC1 can take this decision only if it is aware of the data plane topology. Is this problem addressed ? As you have said " If optical-routing information needs to be processed by a routing application at OX2, then the messages will be addressed to "ox2.my.net" (or whatever). From there the routing application will do its thing and may send additional messages to OX3. i.e. its an application level forwarding problem, not a level 3 data-forwarding. " The message should be addressed to OXC2 for setting up a LSP between OXC1 and OXC3. How does OXC1 decides this? Regarding Your second part of your answer, Is this the standard way of Implementation.There can be other way of Implementation. And if it is not standard way, then Interoperability would be an issue. Regards, Sushanth -----Original Message----- From: John Ellson [mailto:ellson@lucent.com] Sent: Monday, April 15, 2002 10:05 PM To: sushantm Cc: mpls@UU.NET; gmpls-ops@mplsrc.com Subject: Re: Control plane and data plane adjacency sushantm wrote: > Hi, > > I have few doubts regarding control channel adjacency being different from > the data channel > adjacency > > Suppose,take a case as shown in the figure > > +---(R1)---(R2)----+ +---(R3)---(R4)----+ > | | | | > | | | | > | | | | > | | | | > +----------+---+ +---+--+-----+ +--+---------+ > | +----------+ +---------+ | > | +----------+ +---------+ | > | OXC1 +----------+ OXC2 +---------+ OXC3 | > | +----------+ +---------+ | > | | | | | | > +--------------+ +------------+ +------------+ > > R1,R2,R3,R4 - Router provding the control channel adajceny > > In this case OXC1-OXC2 control channel adjaceny is > OXC1-R1-R2-OXC2.Similarly between OXC2 and > OXC3 thro R3 and R4. > > Requirement is setup LSP between OXC1 and OXC3. > > 1. > Routing table would provide me Next hop information in the control plane. > How do we get the > information about the Next hop Node in the Dataplane. LMP will provide me > with information, > for instance,at OXC2 what are the dataplane adjacent nodes, but will not > provide me with data > plane routing information. How do OXC1 knows to select OXC2 for the LSP > setup, where OXC1 could > have been connected to more than one neighbors. > > From where do I get the Data plane route information? Not sure why you want data plane routing information, but the next system IP address will presumably be found from a DNS lookup, just like any other data network conection. > 2. > Suppose R2 had connection to OXC2 as well as OXC3. > Then the signaling information received at R3 will be forwarded directly to > OX3 without getting > processed at OXC2, which is not correct. How do we take care of this > problem. The [GMPLS-SIG] or > [GMPLS-RSVP] does not discuss this issue. Is there any references to this > issue. If optical-routing information needs to be processed by a routing application at OX2, then the messages will be addressed to "ox2.my.net" (or whatever). From there the routing application will do its thing and may send additional messages to OX3. i.e. its an application level forwarding problem, not a level 3 data-forwarding. John Ellson From owner-mpls@UU.NET Tue Apr 16 03:13:23 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25444 for ; Tue, 16 Apr 2002 03:13:18 -0400 (EDT) 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 QQmkum14386; Tue, 16 Apr 2002 07:12:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkum28940 for mpls-outgoing; Tue, 16 Apr 2002 07:11:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmkum28935 for ; Tue, 16 Apr 2002 07:11: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 QQmkum12763 for ; Tue, 16 Apr 2002 07:11:40 GMT Received: from tsmtp4.mail.isp by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [195.235.113.151]) id QQmkum08661 for ; Tue, 16 Apr 2002 07:11:40 GMT Received: from teleline.es ([10.10.21.43]) by tsmtp4.mail.isp (Netscape Messaging Server 4.15 tsmtp4 Jul 26 2001 13:10:38) with ESMTP id GUNFYT01.XNL; Tue, 16 Apr 2002 09:11:17 +0200 From: "JAVI.PLL" To: Sachin Kalra , mpls@UU.NET Message-ID: <1154ac1154b3.1154b31154ac@teleline.es> Date: Tue, 16 Apr 2002 09:11:17 +0200 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: Re: BGP/MPLS VPNs. Draft 2547bis Jan 2002 X-Accept-Language: es Content-Type: multipart/mixed; boundary="--ede754837d41478" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ----ede754837d41478 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, In Cisco, at least 2 options a) 2 VRF, one per site b) Selectve export and import (using route-maps) Cheers ----- Mensaje Original ----- De: Sachin Kalra Fecha: Lunes, Abril 15, 2002 11:27 pm Asunto: BGP/MPLS VPNs. Draft 2547bis Jan 2002 > Dear All: > > I would appreciate if I can get answer to the following: > > If we have two sites "A" and "B" belonging to same VPN > "Yellow_VPN", and > connected to same PE (different physical interfaces), > > [CE-site A] > / > / > ......[PE] > \ > \ > [CE-site B] > > then: > 1. Can we specify different Export/Import route targets for each > of the > site "A" and "B"? Does "Cisco/Junipecould not find any example (Or > just command) for configuring such scenario. > > Thanks for your response. > Sachin Kalra > > ----ede754837d41478 Content-Type: text/x-vcard; name="JAVI.PLL.terra.es.vcf"; charset="iso-8859-1" Content-Disposition: attachment; filename="JAVI.PLL.terra.es.vcf" Content-Description: Card for "JAVI.PLL" Content-Transfer-Encoding: quoted-printable begin=3Avcard n=3AP=E9rez Lledo=3BJavier fn=3AJavier P=E9rez Lledo version=3A2=2E1 email=3Binternet=3AJAVI=2EPLL=40terra=2Ees title=3AIngeniero Telecomunicaciones end=3Avcard ----ede754837d41478-- From owner-mpls@UU.NET Tue Apr 16 03:19:18 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25519 for ; Tue, 16 Apr 2002 03:19:18 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkun17858; Tue, 16 Apr 2002 07:18:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkun29654 for mpls-outgoing; Tue, 16 Apr 2002 07:18:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkun29648 for ; Tue, 16 Apr 2002 07:18:10 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkun02959 for ; Tue, 16 Apr 2002 07:18:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmkun23009 for ; Tue, 16 Apr 2002 07:18:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA14902 for ; Tue, 16 Apr 2002 03:18:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id DAA22643 for mpls@uu.net; Tue, 16 Apr 2002 03:18:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmkun29621 for ; Tue, 16 Apr 2002 07:17:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkun28276 for ; Tue, 16 Apr 2002 07:16:40 GMT Received: from hermes.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmr01.intel.com [192.55.52.18]) id QQmkun21069 for ; Tue, 16 Apr 2002 07:16:40 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.39 2002/04/15 17:47:23 root Exp $) with ESMTP id g3G7Hll19464 for ; Tue, 16 Apr 2002 07:17:47 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.16 2002/04/15 17:47:00 root Exp $) with SMTP id g3G7FAW21957 for ; Tue, 16 Apr 2002 07:15:10 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041600203720752 ; Tue, 16 Apr 2002 00:20:37 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2HL0HZMN>; Tue, 16 Apr 2002 00:16:36 -0700 Message-ID: From: "Gowda, Sidde" To: "'sushantm'" , John Ellson Cc: mpls@UU.NET, gmpls-ops@mplsrc.com Subject: RE: [GMPLS-OPS]: RE: Control plane and data plane adjacency Date: Tue, 16 Apr 2002 00:12:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, A copy of the forwarding information built in the control plane should be available in the data plane too. Data plane contain the forwarding table. You get the next hop and outgoing interface from this table. Does this help you? Siddu -----Original Message----- From: sushantm [mailto:sushantm@sasken.com] Sent: Tuesday, April 16, 2002 11:09 AM To: John Ellson Cc: mpls@UU.NET; gmpls-ops@mplsrc.com Subject: [GMPLS-OPS]: RE: Control plane and data plane adjacency Importance: High Hi John, You wrote: " Not sure why you want data plane routing information, but the next system IP address will presumably be found from a DNS lookup, just like any other data network conection. " I don't know whether I made myself clear. The issue here is not to get the IP addr of the system, but to find out the system. Lets assume the OCX1 is got more than one neigbhor OCX2,OCX4,OXC5,OXC5. OXC2 neigbhor is OXC3. The LSP has to be setup from OXC1 to OXC3. If RSVP signaling is used I would forward this message to R1 ( This information I would get from the routing table). In the Path message, I need fill up the IF_ID information, which contains the Data channel identifier. At OXC1 there may be many data channels connected many neigbors. I have to choose a data channel Id , which is connected to OXC2. How does the OXC1 takes decision. The OXC1 can take this decision only if it is aware of the data plane topology. Is this problem addressed ? As you have said " If optical-routing information needs to be processed by a routing application at OX2, then the messages will be addressed to "ox2.my.net" (or whatever). From there the routing application will do its thing and may send additional messages to OX3. i.e. its an application level forwarding problem, not a level 3 data-forwarding. " The message should be addressed to OXC2 for setting up a LSP between OXC1 and OXC3. How does OXC1 decides this? Regarding Your second part of your answer, Is this the standard way of Implementation.There can be other way of Implementation. And if it is not standard way, then Interoperability would be an issue. Regards, Sushanth -----Original Message----- From: John Ellson [mailto:ellson@lucent.com] Sent: Monday, April 15, 2002 10:05 PM To: sushantm Cc: mpls@UU.NET; gmpls-ops@mplsrc.com Subject: Re: Control plane and data plane adjacency sushantm wrote: > Hi, > > I have few doubts regarding control channel adjacency being different from > the data channel > adjacency > > Suppose,take a case as shown in the figure > > +---(R1)---(R2)----+ +---(R3)---(R4)----+ > | | | | > | | | | > | | | | > | | | | > +----------+---+ +---+--+-----+ +--+---------+ > | +----------+ +---------+ | > | +----------+ +---------+ | > | OXC1 +----------+ OXC2 +---------+ OXC3 | > | +----------+ +---------+ | > | | | | | | > +--------------+ +------------+ +------------+ > > R1,R2,R3,R4 - Router provding the control channel adajceny > > In this case OXC1-OXC2 control channel adjaceny is > OXC1-R1-R2-OXC2.Similarly between OXC2 and > OXC3 thro R3 and R4. > > Requirement is setup LSP between OXC1 and OXC3. > > 1. > Routing table would provide me Next hop information in the control plane. > How do we get the > information about the Next hop Node in the Dataplane. LMP will provide me > with information, > for instance,at OXC2 what are the dataplane adjacent nodes, but will not > provide me with data > plane routing information. How do OXC1 knows to select OXC2 for the LSP > setup, where OXC1 could > have been connected to more than one neighbors. > > From where do I get the Data plane route information? Not sure why you want data plane routing information, but the next system IP address will presumably be found from a DNS lookup, just like any other data network conection. > 2. > Suppose R2 had connection to OXC2 as well as OXC3. > Then the signaling information received at R3 will be forwarded directly to > OX3 without getting > processed at OXC2, which is not correct. How do we take care of this > problem. The [GMPLS-SIG] or > [GMPLS-RSVP] does not discuss this issue. Is there any references to this > issue. If optical-routing information needs to be processed by a routing application at OX2, then the messages will be addressed to "ox2.my.net" (or whatever). From there the routing application will do its thing and may send additional messages to OX3. i.e. its an application level forwarding problem, not a level 3 data-forwarding. John Ellson ------- The GMPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/gmpls-ops.shtml From owner-mpls@UU.NET Tue Apr 16 05:08:31 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26766 for ; Tue, 16 Apr 2002 05:08:31 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkuu11214; Tue, 16 Apr 2002 09:07:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkuu18599 for mpls-outgoing; Tue, 16 Apr 2002 09:06: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 QQmkuu18504 for ; Tue, 16 Apr 2002 09:06:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkuu13950 for ; Tue, 16 Apr 2002 09:06:12 GMT Received: from mailserver.in.huawei.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.167]) id QQmkuu09697 for ; Tue, 16 Apr 2002 09:06:10 GMT Received: from Unknown [10.18.1.2] by mailserver.in.huawei.com - SuperScout Email Filter ; Tuesday, 16 April 2002, 14:30:59 Message-ID: <751B6DD7A243D511AB9F0002557C5687036EC162@huaweimail> From: Pradeepa Shastry To: Sachin Kalra , mpls@UU.NET Date: Tue, 16 Apr 2002 14:39:20 +0530 Subject: RE: BGP/MPLS VPNs. Draft 2547bis Jan 2002 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_NextPart_ST_14_30_59_Tuesday_April_16_2002_14791" X-Mailer: Internet Mail Service (5.5.2653.19) 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_ST_14_30_59_Tuesday_April_16_2002_14791 Content-Type: text/plain; charset="iso-8859-1" Hi, In the hub and spoke VPN topology you can use different Export/Import policies. Juniper does support this please see the URL http://www.juniper.net/techcenter/techpapers/200012-02.html Thanks and Regards -Pradeep Shastry -----Original Message----- From: Sachin Kalra [mailto:skalra@opnet.com] Sent: Tuesday, April 16, 2002 2:57 AM To: mpls@UU.NET Subject: BGP/MPLS VPNs. Draft 2547bis Jan 2002 Dear All: I would appreciate if I can get answer to the following: If we have two sites "A" and "B" belonging to same VPN "Yellow_VPN", and connected to same PE (different physical interfaces), [CE-site A] / / .....[PE] \ \ [CE-site B] then: 1. Can we specify different Export/Import route targets for each of the site "A" and "B"? Does "Cisco/Juniper/Any other vendor" supports this? I could not find any example (Or just command) for configuring such scenario. Thanks for your response. Sachin Kalra -------------------------------------------------------------------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Huawei Technologies India Pvt. Ltd. ----=_NextPart_ST_14_30_59_Tuesday_April_16_2002_14791 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: BGP/MPLS VPNs. Draft 2547bis Jan 2002

Hi,

In the hub and spoke VPN topology you can use different E= xport/Import policies. Juniper does support this please see the URL<= /P>

http://www.juniper.net/techcenter/techpape= rs/200012-02.html

Thanks and Regards
-Pradeep Shastry
 

-----Original Message-----
From: Sachin Kalra [= mailto:skalra@opnet.com]
Sent: Tuesday, April 16, 2002 2:57 AM
To: mpls@UU.NET
Subject: BGP/MPLS VPNs. Draft 2547bis Jan 2002


Dear All:

I would appreciate if I can get answer to the following:<= /FONT>

If we have two sites "A" and "B" belo= nging to same VPN "Yellow_VPN", and
connected to same PE (different physical interfaces),

         &nb= sp;      [CE-site A]
         &n= bsp;     /
         &n= bsp;    /
......[PE]
         &n= bsp;    \
         &n= bsp;     \
         &n= bsp;      [CE-site B]

then:
1. Can we specify different Export/Import route targets = for each of the
site "A" and "B"? Does "Cisco/J= uniper/Any other vendor" supports this? I
could not find any example (Or just command) for configu= ring such scenario.

Thanks for your response.
Sachin Kalra

---------------------------------------------------------------------------= -----------------------------------------
This email and any files trans= mitted with it are confidential and
intended solely for the use of the i= ndividual or entity to whom
they are addressed. If you have received thi= s email in error please notify the
originator of the message.

An= y views expressed in this message are those of the individual
sender, ex= cept where the sender specifies and with authority,
states them to be th= e views of Huawei Technologies India Pvt. Ltd. ----=_NextPart_ST_14_30_59_Tuesday_April_16_2002_14791-- From owner-mpls@UU.NET Tue Apr 16 05:22:14 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27350 for ; Tue, 16 Apr 2002 05:22:14 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkuv09089; Tue, 16 Apr 2002 09:21:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkuv21063 for mpls-outgoing; Tue, 16 Apr 2002 09:20:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmkuv21058 for ; Tue, 16 Apr 2002 09:20:56 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 QQmkuv26947 for ; Tue, 16 Apr 2002 09:19:58 GMT Received: from samar.sasken.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQmkuv21590 for ; Tue, 16 Apr 2002 09:19:55 GMT Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g3G9Jj405710; Tue, 16 Apr 2002 14:49:45 +0530 (IST) Received: from sushanth (pcsva235.sasken.com [10.1.65.235]) by sunsv2.sasken.com (8.11.6/8.11.6) with SMTP id g3G9JiB16422; Tue, 16 Apr 2002 14:49:44 +0530 (IST) From: "sushantm" To: "Gowda, Sidde" , "John Ellson" Cc: , Subject: RE: [GMPLS-OPS]: RE: Control plane and data plane adjacency Date: Tue, 16 Apr 2002 14:51:22 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: High In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Siddu, Who builds the forwarding information of the Data plane in the control plane. OSPF collects all TED information but does not implement any SPF algorithm as these information are opaque LSA. This info used by CSPF to generate ERO objects. But as such Data plane routing information is not available in the control plane. Regards, Sushanth -----Original Message----- From: Gowda, Sidde [mailto:s_gowda@trillium.com] Sent: Tuesday, April 16, 2002 12:43 PM To: 'sushantm'; John Ellson Cc: mpls@UU.NET; gmpls-ops@mplsrc.com Subject: RE: [GMPLS-OPS]: RE: Control plane and data plane adjacency Hi, A copy of the forwarding information built in the control plane should be available in the data plane too. Data plane contain the forwarding table. You get the next hop and outgoing interface from this table. Does this help you? Siddu -----Original Message----- From: sushantm [mailto:sushantm@sasken.com] Sent: Tuesday, April 16, 2002 11:09 AM To: John Ellson Cc: mpls@UU.NET; gmpls-ops@mplsrc.com Subject: [GMPLS-OPS]: RE: Control plane and data plane adjacency Importance: High Hi John, You wrote: " Not sure why you want data plane routing information, but the next system IP address will presumably be found from a DNS lookup, just like any other data network conection. " I don't know whether I made myself clear. The issue here is not to get the IP addr of the system, but to find out the system. Lets assume the OCX1 is got more than one neigbhor OCX2,OCX4,OXC5,OXC5. OXC2 neigbhor is OXC3. The LSP has to be setup from OXC1 to OXC3. If RSVP signaling is used I would forward this message to R1 ( This information I would get from the routing table). In the Path message, I need fill up the IF_ID information, which contains the Data channel identifier. At OXC1 there may be many data channels connected many neigbors. I have to choose a data channel Id , which is connected to OXC2. How does the OXC1 takes decision. The OXC1 can take this decision only if it is aware of the data plane topology. Is this problem addressed ? As you have said " If optical-routing information needs to be processed by a routing application at OX2, then the messages will be addressed to "ox2.my.net" (or whatever). From there the routing application will do its thing and may send additional messages to OX3. i.e. its an application level forwarding problem, not a level 3 data-forwarding. " The message should be addressed to OXC2 for setting up a LSP between OXC1 and OXC3. How does OXC1 decides this? Regarding Your second part of your answer, Is this the standard way of Implementation.There can be other way of Implementation. And if it is not standard way, then Interoperability would be an issue. Regards, Sushanth -----Original Message----- From: John Ellson [mailto:ellson@lucent.com] Sent: Monday, April 15, 2002 10:05 PM To: sushantm Cc: mpls@UU.NET; gmpls-ops@mplsrc.com Subject: Re: Control plane and data plane adjacency sushantm wrote: > Hi, > > I have few doubts regarding control channel adjacency being different from > the data channel > adjacency > > Suppose,take a case as shown in the figure > > +---(R1)---(R2)----+ +---(R3)---(R4)----+ > | | | | > | | | | > | | | | > | | | | > +----------+---+ +---+--+-----+ +--+---------+ > | +----------+ +---------+ | > | +----------+ +---------+ | > | OXC1 +----------+ OXC2 +---------+ OXC3 | > | +----------+ +---------+ | > | | | | | | > +--------------+ +------------+ +------------+ > > R1,R2,R3,R4 - Router provding the control channel adajceny > > In this case OXC1-OXC2 control channel adjaceny is > OXC1-R1-R2-OXC2.Similarly between OXC2 and > OXC3 thro R3 and R4. > > Requirement is setup LSP between OXC1 and OXC3. > > 1. > Routing table would provide me Next hop information in the control plane. > How do we get the > information about the Next hop Node in the Dataplane. LMP will provide me > with information, > for instance,at OXC2 what are the dataplane adjacent nodes, but will not > provide me with data > plane routing information. How do OXC1 knows to select OXC2 for the LSP > setup, where OXC1 could > have been connected to more than one neighbors. > > From where do I get the Data plane route information? Not sure why you want data plane routing information, but the next system IP address will presumably be found from a DNS lookup, just like any other data network conection. > 2. > Suppose R2 had connection to OXC2 as well as OXC3. > Then the signaling information received at R3 will be forwarded directly to > OX3 without getting > processed at OXC2, which is not correct. How do we take care of this > problem. The [GMPLS-SIG] or > [GMPLS-RSVP] does not discuss this issue. Is there any references to this > issue. If optical-routing information needs to be processed by a routing application at OX2, then the messages will be addressed to "ox2.my.net" (or whatever). From there the routing application will do its thing and may send additional messages to OX3. i.e. its an application level forwarding problem, not a level 3 data-forwarding. John Ellson ------- The GMPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/gmpls-ops.shtml From owner-mpls@UU.NET Tue Apr 16 09:44:40 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03896 for ; Tue, 16 Apr 2002 09:44:40 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkvm23705; Tue, 16 Apr 2002 13:43:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkvm05833 for mpls-outgoing; Tue, 16 Apr 2002 13:43: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 QQmkvm05828 for ; Tue, 16 Apr 2002 13:43:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmkvm26223 for ; Tue, 16 Apr 2002 13:43:06 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmkvm03981 for ; Tue, 16 Apr 2002 13:43: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 JAA26063 for ; Tue, 16 Apr 2002 09:43:06 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA29499 for mpls@uu.net; Tue, 16 Apr 2002 09:43:06 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmkvd12304 for ; Tue, 16 Apr 2002 11:24:33 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 QQmkvd21674 for ; Tue, 16 Apr 2002 11:24:04 GMT Received: from webmail21.rediffmail.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: webmail21.rediffmail.com [203.199.83.31] (may be forged)) id QQmkvd17613 for ; Tue, 16 Apr 2002 11:24:03 GMT Received: (qmail 685 invoked by uid 510); 16 Apr 2002 11:18:40 -0000 Date: 16 Apr 2002 11:18:40 -0000 Message-ID: <20020416111840.684.qmail@webmail21.rediffmail.com> Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 16 Apr 2002 11:18:40 -0000 MIME-Version: 1.0 From: "George Thomas" Reply-To: "George Thomas" To: David.Charlap@marconi.com Cc: mpls@UU.NET Subject: Re: Queries regarding RFC 3032 Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi, Thanks for your response. If there is no LSP associated with the destination, (say for e.g. unicast/muticast/broadcast packet), the packet can be sent as native IP packet without NULL label encapsulation in a MPLS domain or it can be discarded, based on the design of the router. This is my understanding from your response. Then i would like to know when NULL label encapsulation is to be used? My initial understanding was: In a MPLS domain, for IP packets which cannot be associated with a LSP, those packets should be sent to the IP next hop with NULL label encapsulation in a LAN media and it should not be sent as native IP packet. Please clarify. Regards George. George Thomas wrote: > >1. If there is no LSP associated with a destination (Unicast/ > Multicast), whether it is mandatory to use NULL Label >Encapsulation, and encoding the ethertype value to >0x8847/0x8848. >or Is it valid to send as Native IP packet with Ethertype >value as 0x800 in the MPLS network. If an LER receives an unlabeled packet, and there is no forwarding table information descrbing what LSP to send the packet on, then the behavior is beyond the scope of MPLS. It would be legal to forward the packet hop-by-hop, as a non-MPLS router would. It would also be legal to drop the packet and generate an ICMP error (treating it as a non-MPLS router would if there is no route to the destination.) I would not expect a NULL label to be used in this situation. >2. If NULL label is Mandatory, for a broadcast packet, what >ethertype value should be used? Whether the Mulitcast ethertype >value can be used? > >If NULL label is not mandatory, it implies that any native IP >packet can be sent with ethertype value as 0x800 in a MPLS >domain >without Label encapsulation. Am i right? MPLS routers have to be able to send and receive non-labeled packets. That's how the routing and signaling protocols all work. Whether they also have the capability of forwarding unlabeled packets is up to the design of the router, of course. I think such capability is required for some protocol features (like extended-discovery LDP peering), however. Of course, Ethertypes are only valid on those interfaces that use Ethertypes. Other interfaces would use whatever layer-2 types are appropriate for the IP packet. -- David From owner-mpls@UU.NET Tue Apr 16 10:05:29 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05164 for ; Tue, 16 Apr 2002 10:05:29 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkvo22981; Tue, 16 Apr 2002 14:04:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkvo18729 for mpls-outgoing; Tue, 16 Apr 2002 14:04:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmkvo18722 for ; Tue, 16 Apr 2002 14:04: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 QQmkvo25178 for ; Tue, 16 Apr 2002 14:02:58 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 QQmkvo20573 for ; Tue, 16 Apr 2002 14:02:58 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 KAA07725 for ; Tue, 16 Apr 2002 10:02:56 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16259 for ; Tue, 16 Apr 2002 10:02:55 -0400 (EDT) Message-ID: <3CBC2F25.E9B0496F@marconi.com> Date: Tue, 16 Apr 2002 10:03:17 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Queries regarding RFC 3032 References: <20020416111840.684.qmail@webmail21.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George Thomas wrote: > > If there is no LSP associated with the destination, (say for e.g. > unicast/muticast/broadcast packet), the packet can be sent as > native IP packet without NULL label encapsulation in a MPLS domain > or it can be discarded, based on the design of the router. This is > my understanding from your response. Correct. > Then i would like to know when NULL label encapsulation is to be > used? A router that isn't capable of popping a label stack may be required to do so. In this situation, it can swap to NULL. When this happens, the next-hop router is expected to pop off that NULL label prior to processing the packet. > My initial understanding was: In a MPLS domain, for IP packets > which cannot be associated with a LSP, those packets should be > sent to the IP next hop with NULL label encapsulation in a LAN > media and it should not be sent as native IP packet. NULL labels are a workaround to get around some kinds of hardware restrictions. I don't think they were ever meant to be the primary means of forwarding unlabeled traffic. -- David From owner-mpls@UU.NET Tue Apr 16 10:08:42 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05377 for ; Tue, 16 Apr 2002 10:08:42 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkvo27697; Tue, 16 Apr 2002 14:07:43 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkvo26825 for mpls-outgoing; Tue, 16 Apr 2002 14:07:29 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 QQmkvo26727 for ; Tue, 16 Apr 2002 14:07: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 QQmkvo01832 for ; Tue, 16 Apr 2002 14:05:47 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 QQmkvo05799 for ; Tue, 16 Apr 2002 14:05: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 KAA27697; Tue, 16 Apr 2002 10:05:46 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA02131; Tue, 16 Apr 2002 10:05:46 -0400 (EDT) Message-Id: <200204161405.KAA02131@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: "David Allan" cc: Loa Andersson , Scott Bradner , mpls@UU.NET Subject: Re: response to ITU-T SG13 In-reply-to: Your message of Mon, 15 Apr 2002 16:39:53 -0400. <3549C09B853DD5119B540002A52CDD3402C6E7F1@zcard0ka.ca.nortel.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Apr 2002 10:05:46 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk David> I politely flagged this one as I think it is a bit of a stretch to David> ask the ITU to comment on the effects of Y.1711 on stuff that does David> not exist and has not yet been specified. This is in addition to David> asking it's impact on proprietary implementations where to date there David> has been under-specification It is perfectly reasonable to ask whether the ITU foresees extending the OAM mechanisms in such a way as to impact any of the existing or even foreseen label distribution and/or routing protocols and mechanisms. It is also perfectly reasonable to ask about the impact of those mechanisms on existing deployments and implementations. One can of course offer a bunch of trumped up excuses for not wanting to answer the question, but perhaps that is an answer in itself. From owner-mpls@UU.NET Tue Apr 16 10:34:42 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06357 for ; Tue, 16 Apr 2002 10:34:42 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkvq02043; Tue, 16 Apr 2002 14:32:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkvq00848 for mpls-outgoing; Tue, 16 Apr 2002 14:31: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 QQmkvq00843 for ; Tue, 16 Apr 2002 14:31:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmkvq24416 for ; Tue, 16 Apr 2002 14:31:01 GMT Received: from zcars04f.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmkvq10187 for ; Tue, 16 Apr 2002 14:31:00 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3GEUYe29082; Tue, 16 Apr 2002 10:30:34 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <2WJA38LV>; Tue, 16 Apr 2002 10:30:34 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402C6EEF9@zcard0ka.ca.nortel.com> From: "David Allan" To: erosen@cisco.com Cc: Loa Andersson , Scott Bradner , mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Tue, 16 Apr 2002 10:30:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E553.438D2798" 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_01C1E553.438D2798 Content-Type: text/plain; charset="iso-8859-1" Eric, you're on the wrong tack. I am concerned that there are other hidden gotcha's out there with existing implementations, and would like to see them all out ASAP. For example, IMHO the discussion with Giles on hashing for load balancing was genuinely useful and if followed up upon, we'll all be better off. When it comes to outlining concerns with the current state of implementation to SG13, it would be nice if one comprehensive exchange settled concerns, rather than an on-going parade. In that regard I consider the discussion so far (w.r.t implementation) to have made us all better. In fact, going back through some of the earlier discussion, there were also concerns about hardware impacts of potentially using y.1711 for protection switching that came up on the list during the last IETF that are not reflected in this liaison, and probably should be in the interest of complete transparency. George noted, and I agree that merely adding an LSP attribute as to whether fault detection is enabled will be fairly trivial and I'd observe that code points have been given out for less and with less scrutiny. I consider the impact on existing deployments much more interesting/important. It is not the reasonableness of the impact on implementation aspects of the request I question. It is apparent arbitrary hurdle set by the some of the more far-seeing aspects.... cheers Dave > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Tuesday, April 16, 2002 10:06 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: Loa Andersson; Scott Bradner; mpls@UU.NET > Subject: Re: response to ITU-T SG13 > > > > David> I politely flagged this one as I think it is a bit > of a stretch to > David> ask the ITU to comment on the effects of Y.1711 on > stuff that does > David> not exist and has not yet been specified. This is > in addition to > David> asking it's impact on proprietary implementations > where to date there > David> has been under-specification > > It is perfectly reasonable to ask whether the ITU foresees > extending the OAM > mechanisms in such a way as to impact any of the existing > or even foreseen > label distribution and/or routing protocols and > mechanisms. It is also > perfectly reasonable to ask about the impact of those > mechanisms on existing > deployments and implementations. One can of course offer a > bunch of trumped > up excuses for not wanting to answer the question, but > perhaps that is an > answer in itself. > > ------_=_NextPart_001_01C1E553.438D2798 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: response to ITU-T SG13

Eric,

you're on the wrong tack.

I am concerned that there are other hidden gotcha's = out there with existing implementations, and would like to see them all = out ASAP. For example, IMHO the discussion with Giles on hashing for = load balancing was genuinely useful and if followed up upon, we'll all = be better off.  When it comes to outlining concerns with the = current state of implementation to SG13, it would be nice if one = comprehensive exchange settled concerns, rather than an on-going = parade.

In that regard I consider the discussion so far = (w.r.t implementation) to have made us all better. In fact, going back = through some of the earlier discussion, there were also concerns about = hardware impacts of potentially using y.1711 for protection switching = that came up on the list during the last IETF that are not reflected in = this liaison, and probably should be in the interest of complete = transparency.

George noted, and I agree that merely adding an LSP = attribute as to whether fault detection is enabled will be fairly = trivial and I'd observe that code points have been given out for less = and with less scrutiny. I consider the impact on existing deployments = much more interesting/important.

It is not the reasonableness of the impact on = implementation aspects of the request I question. It is apparent = arbitrary hurdle set by the some of the more far-seeing = aspects....

cheers
Dave

> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Tuesday, April 16, 2002 10:06 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: Loa Andersson; Scott Bradner; = mpls@UU.NET
> Subject: Re: response to ITU-T SG13
>
>
>
> David> I politely flagged  this one as = I think  it is a bit
> of  a stretch to
> David> ask the  ITU to comment on = the  effects of Y.1711 on 
> stuff that does
> David> not exist  and has  not = yet  been specified. This  is
> in  addition to
> David> asking it's impact on proprietary = implementations
> where to date there
> David> has been under-specification
>
> It is perfectly reasonable to ask whether the = ITU foresees
> extending the OAM
> mechanisms in such a  way as to impact any = of the  existing
> or even foreseen
> label  distribution and/or  routing = protocols  and
> mechanisms.   It  is also
> perfectly reasonable to ask about the impact of = those
> mechanisms on existing
> deployments and implementations.  One can = of course offer a
> bunch of trumped
> up excuses  for not wanting to = answer  the question, but
> perhaps  that is an
> answer in itself.
>
>

------_=_NextPart_001_01C1E553.438D2798-- From owner-mpls@UU.NET Tue Apr 16 12:01:37 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11407 for ; Tue, 16 Apr 2002 12:01:37 -0400 (EDT) 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 QQmkvw29865; Tue, 16 Apr 2002 16:00:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkvw29576 for mpls-outgoing; Tue, 16 Apr 2002 16:00:05 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 QQmkvw29443 for ; Tue, 16 Apr 2002 16:00:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkvv23919 for ; Tue, 16 Apr 2002 15:57:45 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 QQmkvv25956 for ; Tue, 16 Apr 2002 15:57:45 GMT Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id A20399F67 for ; Tue, 16 Apr 2002 09:57:44 -0600 (MDT) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 4FE761B6 for ; Tue, 16 Apr 2002 09:57:44 -0600 (MDT) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 16 Apr 2002 09:57:43 -0600 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id <262BX6XP>; Tue, 16 Apr 2002 09:57:43 -0600 Message-ID: <0D9185CE635BD511ACA50090277A6FCF517C7A@axcs18.cos.agilent.com> From: "SUBRAMANIAN,ANU (A-Portsmouth,ex1)" To: mpls@UU.NET Subject: RE: Queries regarding RFC 3032 Date: Tue, 16 Apr 2002 09:57:40 -0600 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 Hello, Can someone tell me if route targets should be included or not when BGP update messages are created for VPN routes withdrawl? Can you also point me to a draft or RFC which talks about this? Thanks, Anu. From owner-mpls@UU.NET Tue Apr 16 16:54:57 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17909 for ; Tue, 16 Apr 2002 16:54:57 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkwp25282; Tue, 16 Apr 2002 20:53:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkwp06963 for mpls-outgoing; Tue, 16 Apr 2002 20:53:43 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmkwp06956 for ; Tue, 16 Apr 2002 20:53: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 QQmkwp16696 for ; Tue, 16 Apr 2002 20:52: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 QQmkwp27266 for ; Tue, 16 Apr 2002 20:52:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA29986 for ; Tue, 16 Apr 2002 16:52:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA12023 for mpls@uu.net; Tue, 16 Apr 2002 16:52:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkwp06801 for ; Tue, 16 Apr 2002 20:50:54 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 QQmkwp04297 for ; Tue, 16 Apr 2002 20:49:58 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmkwp24486 for ; Tue, 16 Apr 2002 20:49:57 GMT Received: (qmail 14696 invoked by uid 104); 16 Apr 2002 20:49:51 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4196. . Clean. Processed in 0.45389 secs); 16 Apr 2002 20:49:51 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 16 Apr 2002 20:49:51 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g3GKnip11912; Tue, 16 Apr 2002 13:49:44 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 13:49:48 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A701@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau '" Cc: "''erosen@cisco.com' '" , "''Scott Bradner' '" , "'mpls@UU.NET '" Subject: RE: response to ITU-T SG13 Date: Tue, 16 Apr 2002 13:49:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk -----Original Message----- From: Thomas D. Nadeau To: Shahram Davari Cc: 'erosen@cisco.com'; 'Scott Bradner'; mpls@UU.NET Sent: 15/04/02 5:47 PM Subject: RE: response to ITU-T SG13 At 11:26 AM 4/15/2002 -0700, Shahram Davari wrote: >Eric, > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Monday, April 15, 2002 2:20 PM > > To: Shahram Davari > > Cc: 'Scott Bradner'; mpls@UU.NET > > Subject: Re: response to ITU-T SG13 > > > > > > > > Shahram> Some vendors may have implemented their MPLS > > data-plane in hardware > > Shahram> and some in software. Why should a vendor's > > implementation be a > > Shahram> concern for a standard body such as IETF? > > > > Shahram> I don't think specific implementations should be a > > concern for a > > Shahram> standard body such as IETF. You could always > > find a specific > > Shahram> implementations that can't support a new function. > > Any objection > > Shahram> regarding backward compatibility should be based on > > a standard. > > > > Are you saying that the characteristics of existing > > deployments and > > implementations should deliberately be ignored by the WG > > as it makes its > > decisions? > >No. I am saying that a specific implementation by a specific vendor/ >operator should not be the basis for any standard argument. If most >vendors/operators >implement a function in the same manner, then that is a different story. >But still an alternative solution should exist, otherwise it is best to have >a solution rather than nothing at all. Why not? The mantra at the IETF is "working code and rough consensus." Sounds like we base things on real implementations around here to me. Rough consensus is not = Cisco consensus > > I'd have to disagree. If one is trying to produce > > solutions which solve real problems for real people, and which will be > adopted by > > the real market, then one is well-advised to take the existing > situation into > > consideration. > > > > I am not aware of any IETF policy or precedent that says to > > ignore existing implementations or deployments. > >I am not also aware of any IETF policy that says take to account >vendor "X"'s implementation. See above. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Tue Apr 16 17:07:07 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19603 for ; Tue, 16 Apr 2002 17:07:07 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkwq11847; Tue, 16 Apr 2002 21:06:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkwq19615 for mpls-outgoing; Tue, 16 Apr 2002 21:05:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkwq19492 for ; Tue, 16 Apr 2002 21:05:36 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 QQmkwq11177 for ; Tue, 16 Apr 2002 21:05: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 QQmkwq14699 for ; Tue, 16 Apr 2002 21:05:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA01268 for ; Tue, 16 Apr 2002 17:05:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA14128 for mpls@uu.net; Tue, 16 Apr 2002 17:05:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkwq18985 for ; Tue, 16 Apr 2002 21:04:31 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 QQmkwq09022 for ; Tue, 16 Apr 2002 21:04:12 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQmkwq13639 for ; Tue, 16 Apr 2002 21:04:12 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3GL4QCa027184; Tue, 16 Apr 2002 17:04:26 -0400 (EDT) Received: from tnadeau-w2k.cisco.com ([161.44.171.5]) by bucket.cisco.com (Mirapoint) with ESMTP id AAX04719; Tue, 16 Apr 2002 17:03:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20020416165518.03ab4048@bucket> X-Sender: tnadeau@bucket X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Apr 2002 17:03:51 -0400 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: response to ITU-T SG13 Cc: "''erosen@cisco.com' '" , "''Scott Bradner' '" , "'mpls@UU.NET '" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE84A701@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >-----Original Message----- >From: Thomas D. Nadeau >To: Shahram Davari >Cc: 'erosen@cisco.com'; 'Scott Bradner'; mpls@UU.NET >Sent: 15/04/02 5:47 PM >Subject: RE: response to ITU-T SG13 > >At 11:26 AM 4/15/2002 -0700, Shahram Davari wrote: > >Eric, > > > > > -----Original Message----- > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > Sent: Monday, April 15, 2002 2:20 PM > > > To: Shahram Davari > > > Cc: 'Scott Bradner'; mpls@UU.NET > > > Subject: Re: response to ITU-T SG13 > > > > > > > > > > > > Shahram> Some vendors may have implemented their MPLS > > > data-plane in hardware > > > Shahram> and some in software. Why should a vendor's > > > implementation be a > > > Shahram> concern for a standard body such as IETF? > > > > > > Shahram> I don't think specific implementations should be a > > > concern for a > > > Shahram> standard body such as IETF. You could always > > > find a specific > > > Shahram> implementations that can't support a new function. > > > Any objection > > > Shahram> regarding backward compatibility should be based on > > > a standard. > > > > > > Are you saying that the characteristics of existing > > > deployments and > > > implementations should deliberately be ignored by the WG > > > as it makes its > > > decisions? > > > >No. I am saying that a specific implementation by a specific vendor/ > >operator should not be the basis for any standard argument. If most > >vendors/operators > >implement a function in the same manner, then that is a different >story. > >But still an alternative solution should exist, otherwise it is best to >have > >a solution rather than nothing at all. > > Why not? The mantra at the IETF is "working code and rough >consensus." >Sounds like we base things on real implementations around here to me. > >Rough consensus is not = Cisco consensus Working code and rough consensus often comes from a variety of fine device vendors. If it happens to include some that you don't particularly like, that really isn't the point, is it? --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Tue Apr 16 22:37:21 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24599 for ; Tue, 16 Apr 2002 22:37:21 -0400 (EDT) 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 QQmkxm07193; Wed, 17 Apr 2002 02:36:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkxm08886 for mpls-outgoing; Wed, 17 Apr 2002 02:36: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 QQmkxm08820 for ; Wed, 17 Apr 2002 02:35:58 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 QQmkxm03578 for ; Wed, 17 Apr 2002 02:35:14 GMT Received: from hermes.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmr01.intel.com [192.55.52.18]) id QQmkxm05122 for ; Wed, 17 Apr 2002 02:35:12 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.39 2002/04/15 17:47:23 root Exp $) with ESMTP id g3H2aHS14868 for ; Wed, 17 Apr 2002 02:36:17 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.16 2002/04/15 17:47:00 root Exp $) with SMTP id g3H2XeM25666 for ; Wed, 17 Apr 2002 02:33:40 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041619391216446 ; Tue, 16 Apr 2002 19:39:12 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2HL02435>; Tue, 16 Apr 2002 19:35:09 -0700 Message-ID: <9678C2B4D848D41187450090276D1FAE0BC301A6@FMSMSX32> From: "Sharma, Prashant" To: "'mpls@UU.NET'" Cc: "'eric.gray@sandburst.com'" Subject: Doubt In Session Estb. Procedure... Date: Tue, 16 Apr 2002 19:35:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have one doubt regarding session establishment procedure in LDP. If a node is an active node, then it first sends Initialization message and the passive node responds with Initialization message of its own. My question is, is it mandatory for the passive node to send the negotiated parameters in its initialization message. In other words, is it permitted that passive node sends its configured (and not negotiated parameters) in its Initialization message.In this case active node will also be able to know the peer's configuration (like loop detection), if it needs to take some action based on it. The two nodes can always calculate the negotiated value on receiving the peers Initialization message. RFC is not very clear on this. I require this information to decide the behavior of active node on receiving peers Initialization message. Thanks for your help in advance. Regards Prashant. From owner-mpls@UU.NET Wed Apr 17 00:48:08 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02089 for ; Wed, 17 Apr 2002 00:48:07 -0400 (EDT) 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 QQmkxv04295; Wed, 17 Apr 2002 04:45:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkxu00506 for mpls-outgoing; Wed, 17 Apr 2002 04:44:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkxu00501 for ; Wed, 17 Apr 2002 04:44:27 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 QQmkxu07979 for ; Wed, 17 Apr 2002 04:44:09 GMT Received: from smtp.huawei.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [61.144.161.21]) id QQmkxu12323 for ; Wed, 17 Apr 2002 04:44:08 GMT Received: from f26719 ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GUP3P300.B5P; Wed, 17 Apr 2002 12:41:27 +0800 Message-ID: <007901c1e5ca$1850fd80$03426e0a@f26719.HUAWEI.COM> From: "fan zhiqiang" To: , "Sachin Kalra" Subject: =?gb2312?B?u9i4tDogQkdQL01QTFMgVlBOcy4gRHJhZnQgMjU0N2JpcyBKYW4gMjAwMg==?= Date: Wed, 17 Apr 2002 12:41:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hi,in the case that from the view of external sites, siteA & siteB is always bounded together, and always to belong the same vpn(s),configure one VRF at PE then bound this two sites to its "interface list" is ok. in the case else, Export & Import target use to control the connectivity of siteA & siteB. regards, cusofour. -----Original Message----- ·¢¼þÈË: Sachin Kalra ÊÕ¼þÈË: mpls@UU.NET ÈÕÆÚ: 2002Äê4ÔÂ16ÈÕ 5:28 Ö÷Ìâ: BGP/MPLS VPNs. Draft 2547bis Jan 2002 >Dear All: > >I would appreciate if I can get answer to the following: > >If we have two sites "A" and "B" belonging to same VPN "Yellow_VPN", and >connected to same PE (different physical interfaces), > > [CE-site A] > / > / >......[PE] > \ > \ > [CE-site B] > >then: >1. Can we specify different Export/Import route targets for each of the >site "A" and "B"? Does "Cisco/Juniper/Any other vendor" supports this? I >could not find any example (Or just command) for configuring such scenario. > >Thanks for your response. >Sachin Kalra > From owner-mpls@UU.NET Wed Apr 17 01:18:45 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02336 for ; Wed, 17 Apr 2002 01:18:45 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkxx26917; Wed, 17 Apr 2002 05:17:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkxx24419 for mpls-outgoing; Wed, 17 Apr 2002 05:17:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkxx24414 for ; Wed, 17 Apr 2002 05:17:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkxx25923 for ; Wed, 17 Apr 2002 05:17:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmkxx17947 for ; Wed, 17 Apr 2002 05:17:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA23014 for ; Wed, 17 Apr 2002 01:17:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA01679 for mpls@uu.net; Wed, 17 Apr 2002 01:17:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmkxx24195 for ; Wed, 17 Apr 2002 05:15:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkxx11562 for ; Wed, 17 Apr 2002 05:15:23 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmkxx15649 for ; Wed, 17 Apr 2002 05:15:22 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 10:52:20 +0530 Message-ID: From: "Vijayanand C - CTD, Chennai." To: "Sharma, Prashant" Cc: mpls@UU.NET Subject: RE: Doubt In Session Estb. Procedure... Date: Wed, 17 Apr 2002 10:43:33 +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 Hello prashant, I think the RFC is pretty clear on this that the second Init( sent by the passive node) will go with the negotiated value. This ensures that the negotiation is over in a single Init by each node. What you are suggesting is an alternative protocol. This way it will take more than a single Init by each node. Also, if its decided that the negotiated value is going to be the lower of the two configurations, what is the point in passive node sending its configuration? Regards, Vijay -----Original Message----- From: Sharma, Prashant [mailto:prashant_sharma@trillium.com] Sent: Wednesday, April 17, 2002 8:05 AM To: 'mpls@UU.NET' Cc: 'eric.gray@sandburst.com' Subject: Doubt In Session Estb. Procedure... Hi, I have one doubt regarding session establishment procedure in LDP. If a node is an active node, then it first sends Initialization message and the passive node responds with Initialization message of its own. My question is, is it mandatory for the passive node to send the negotiated parameters in its initialization message. In other words, is it permitted that passive node sends its configured (and not negotiated parameters) in its Initialization message.In this case active node will also be able to know the peer's configuration (like loop detection), if it needs to take some action based on it. The two nodes can always calculate the negotiated value on receiving the peers Initialization message. RFC is not very clear on this. I require this information to decide the behavior of active node on receiving peers Initialization message. Thanks for your help in advance. Regards Prashant. From owner-mpls@UU.NET Wed Apr 17 02:04:25 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08424 for ; Wed, 17 Apr 2002 02:04:25 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkya25948; Wed, 17 Apr 2002 06:03:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkya08755 for mpls-outgoing; Wed, 17 Apr 2002 06: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 QQmkya08750 for ; Wed, 17 Apr 2002 06:03:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmkya16665 for ; Wed, 17 Apr 2002 06:02:50 GMT From: francis.arts@alcatel.be Received: from bt0g2p.god.bel.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQmkya25904 for ; Wed, 17 Apr 2002 06:02:49 GMT Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g3H61Tb25024 for ; Wed, 17 Apr 2002 08:01:29 +0200 To: mpls@UU.NET Subject: TE MIB MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 17 Apr 2002 08:02:37 +0200 X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/17/2002 08:02:39, Serialize complete at 04/17/2002 08:02:39 Content-Type: multipart/alternative; boundary="=_alternative 002132CDC1256B9E_=" Sender: owner-mpls@UU.NET Precedence: bulk This is a multipart message in MIME format. --=_alternative 002132CDC1256B9E_= Content-Type: text/plain; charset="us-ascii" Hello, I have a question on the MPLS TE MIB described in . When reading the MIB and from the past discussions on the mpls mailing list I understand that the ifIndex of the mpls tunnel is stacked on the ifIndex of the outgoing mpls interface. However, what happens now if the mpls tunnel corresponds to 2 LSPs of equal priority? Then the traffic is load balanced over both LSPs. Does this then mean that the ifIndex of the mpls tunnel shows up in the ifStack table as the higher layer of 2 interface stacks (1 for each of the 2 outgoing mpls interfaces)? Thanks for any clarification you can provide, Francis. --=_alternative 002132CDC1256B9E_= Content-Type: text/html; charset="us-ascii"
Hello,

I have a question on the MPLS TE MIB described in <draft-ietf-mpls-te-mib>. When reading the MIB and from the past discussions on the mpls mailing list I understand that the ifIndex of the mpls tunnel is stacked on the ifIndex of the outgoing mpls interface.

However, what happens now if the mpls tunnel corresponds to 2 LSPs of equal priority? Then the traffic is load balanced over both LSPs. Does this then mean that the ifIndex of the mpls tunnel shows up in the ifStack table as the higher layer of 2 interface stacks (1 for each of the 2 outgoing mpls interfaces)?

Thanks for any clarification you can provide,

        Francis. --=_alternative 002132CDC1256B9E_=-- From owner-mpls@UU.NET Wed Apr 17 05:10:10 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12948 for ; Wed, 17 Apr 2002 05:10:10 -0400 (EDT) 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 QQmkym15704; Wed, 17 Apr 2002 09:07:59 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkym04347 for mpls-outgoing; Wed, 17 Apr 2002 09:07: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 QQmkym04342 for ; Wed, 17 Apr 2002 09:07:43 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 QQmkym10382 for ; Wed, 17 Apr 2002 09:07:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmkym04134 for ; Wed, 17 Apr 2002 09:07:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA01002 for ; Wed, 17 Apr 2002 05:07:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id FAA24134 for mpls@uu.net; Wed, 17 Apr 2002 05:07:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmkym03605 for ; Wed, 17 Apr 2002 09:06:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkym14703 for ; Wed, 17 Apr 2002 09:04:54 GMT Received: from caduceus.fm.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmr02.intel.com [192.55.52.25]) id QQmkym24570 for ; Wed, 17 Apr 2002 09:04:03 GMT Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.39 2002/04/15 17:47:23 root Exp $) with ESMTP id g3H7DhH09556 for ; Wed, 17 Apr 2002 07:13:43 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.16 2002/04/15 17:47:00 root Exp $) with SMTP id g3H7CqL25432 for ; Wed, 17 Apr 2002 07:12:52 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041700132532310 ; Wed, 17 Apr 2002 00:13:26 -0700 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2XMGA082>; Wed, 17 Apr 2002 00:14:20 -0700 Message-ID: From: "Gowda, Sidde" To: "'sushantm'" , "Gowda, Sidde", John Ellson Cc: mpls@UU.NET, gmpls-ops@mplsrc.com Subject: RE: [GMPLS-OPS]: RE: Control plane and data plane adjacency Date: Wed, 17 Apr 2002 00:12:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Signalling protocol like LDP. LDP module will have LIB. The forwarding plane will also have a copy of it (LIB cache) --------------------------------------- RSVP TE <------->LIB<-------->LDP CR --|------------------------------------ | TCP/UDP | ------- \|/ IP --------------------------------------- LIB cache<------->MPLS forwarder --------------------------------------- siddu -----Original Message----- From: sushantm [mailto:sushantm@sasken.com] Sent: Tuesday, April 16, 2002 2:51 PM To: Gowda, Sidde; John Ellson Cc: mpls@UU.NET; gmpls-ops@mplsrc.com Subject: RE: [GMPLS-OPS]: RE: Control plane and data plane adjacency Importance: High Hi Siddu, Who builds the forwarding information of the Data plane in the control plane. OSPF collects all TED information but does not implement any SPF algorithm as these information are opaque LSA. This info used by CSPF to generate ERO objects. But as such Data plane routing information is not available in the control plane. Regards, Sushanth -----Original Message----- From: Gowda, Sidde [mailto:s_gowda@trillium.com] Sent: Tuesday, April 16, 2002 12:43 PM To: 'sushantm'; John Ellson Cc: mpls@UU.NET; gmpls-ops@mplsrc.com Subject: RE: [GMPLS-OPS]: RE: Control plane and data plane adjacency Hi, A copy of the forwarding information built in the control plane should be available in the data plane too. Data plane contain the forwarding table. You get the next hop and outgoing interface from this table. Does this help you? Siddu -----Original Message----- From: sushantm [mailto:sushantm@sasken.com] Sent: Tuesday, April 16, 2002 11:09 AM To: John Ellson Cc: mpls@UU.NET; gmpls-ops@mplsrc.com Subject: [GMPLS-OPS]: RE: Control plane and data plane adjacency Importance: High Hi John, You wrote: " Not sure why you want data plane routing information, but the next system IP address will presumably be found from a DNS lookup, just like any other data network conection. " I don't know whether I made myself clear. The issue here is not to get the IP addr of the system, but to find out the system. Lets assume the OCX1 is got more than one neigbhor OCX2,OCX4,OXC5,OXC5. OXC2 neigbhor is OXC3. The LSP has to be setup from OXC1 to OXC3. If RSVP signaling is used I would forward this message to R1 ( This information I would get from the routing table). In the Path message, I need fill up the IF_ID information, which contains the Data channel identifier. At OXC1 there may be many data channels connected many neigbors. I have to choose a data channel Id , which is connected to OXC2. How does the OXC1 takes decision. The OXC1 can take this decision only if it is aware of the data plane topology. Is this problem addressed ? As you have said " If optical-routing information needs to be processed by a routing application at OX2, then the messages will be addressed to "ox2.my.net" (or whatever). From there the routing application will do its thing and may send additional messages to OX3. i.e. its an application level forwarding problem, not a level 3 data-forwarding. " The message should be addressed to OXC2 for setting up a LSP between OXC1 and OXC3. How does OXC1 decides this? Regarding Your second part of your answer, Is this the standard way of Implementation.There can be other way of Implementation. And if it is not standard way, then Interoperability would be an issue. Regards, Sushanth -----Original Message----- From: John Ellson [mailto:ellson@lucent.com] Sent: Monday, April 15, 2002 10:05 PM To: sushantm Cc: mpls@UU.NET; gmpls-ops@mplsrc.com Subject: Re: Control plane and data plane adjacency sushantm wrote: > Hi, > > I have few doubts regarding control channel adjacency being different from > the data channel > adjacency > > Suppose,take a case as shown in the figure > > +---(R1)---(R2)----+ +---(R3)---(R4)----+ > | | | | > | | | | > | | | | > | | | | > +----------+---+ +---+--+-----+ +--+---------+ > | +----------+ +---------+ | > | +----------+ +---------+ | > | OXC1 +----------+ OXC2 +---------+ OXC3 | > | +----------+ +---------+ | > | | | | | | > +--------------+ +------------+ +------------+ > > R1,R2,R3,R4 - Router provding the control channel adajceny > > In this case OXC1-OXC2 control channel adjaceny is > OXC1-R1-R2-OXC2.Similarly between OXC2 and > OXC3 thro R3 and R4. > > Requirement is setup LSP between OXC1 and OXC3. > > 1. > Routing table would provide me Next hop information in the control plane. > How do we get the > information about the Next hop Node in the Dataplane. LMP will provide me > with information, > for instance,at OXC2 what are the dataplane adjacent nodes, but will not > provide me with data > plane routing information. How do OXC1 knows to select OXC2 for the LSP > setup, where OXC1 could > have been connected to more than one neighbors. > > From where do I get the Data plane route information? Not sure why you want data plane routing information, but the next system IP address will presumably be found from a DNS lookup, just like any other data network conection. > 2. > Suppose R2 had connection to OXC2 as well as OXC3. > Then the signaling information received at R3 will be forwarded directly to > OX3 without getting > processed at OXC2, which is not correct. How do we take care of this > problem. The [GMPLS-SIG] or > [GMPLS-RSVP] does not discuss this issue. Is there any references to this > issue. If optical-routing information needs to be processed by a routing application at OX2, then the messages will be addressed to "ox2.my.net" (or whatever). From there the routing application will do its thing and may send additional messages to OX3. i.e. its an application level forwarding problem, not a level 3 data-forwarding. John Ellson ------- The GMPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/gmpls-ops.shtml ------- The GMPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/gmpls-ops.shtml From owner-mpls@UU.NET Wed Apr 17 09:50:54 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17414 for ; Wed, 17 Apr 2002 09:50:54 -0400 (EDT) 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 QQmkzf26772; Wed, 17 Apr 2002 13:49:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkzf24991 for mpls-outgoing; Wed, 17 Apr 2002 13:49:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmkzf24985 for ; Wed, 17 Apr 2002 13:49:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkzf18296 for ; Wed, 17 Apr 2002 13:49: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 QQmkzf15476 for ; Wed, 17 Apr 2002 13:49:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA11783 for ; Wed, 17 Apr 2002 09:49:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA21858 for mpls@uu.net; Wed, 17 Apr 2002 09:49:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkzf24836 for ; Wed, 17 Apr 2002 13:47: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 QQmkzf22405 for ; Wed, 17 Apr 2002 13:47:40 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmkzf18630 for ; Wed, 17 Apr 2002 13:47:39 GMT Received: (qmail 14439 invoked by uid 104); 17 Apr 2002 13:47:38 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4196. . Clean. Processed in 0.459447 secs); 17 Apr 2002 13:47:38 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 17 Apr 2002 13:47:38 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g3HDlYp07365; Wed, 17 Apr 2002 06:47:34 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 06:47:38 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A706@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" Cc: "''erosen@cisco.com' '" , "''Scott Bradner' '" , "'mpls@UU.NET '" Subject: RE: response to ITU-T SG13 Date: Wed, 17 Apr 2002 06:47:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Tuesday, April 16, 2002 5:04 PM > To: Shahram Davari > Cc: ''erosen@cisco.com' '; ''Scott Bradner' '; 'mpls@UU.NET ' > Subject: RE: response to ITU-T SG13 > > > > > >-----Original Message----- > >From: Thomas D. Nadeau > >To: Shahram Davari > >Cc: 'erosen@cisco.com'; 'Scott Bradner'; mpls@UU.NET > >Sent: 15/04/02 5:47 PM > >Subject: RE: response to ITU-T SG13 > > > >At 11:26 AM 4/15/2002 -0700, Shahram Davari wrote: > > >Eric, > > > > > > > -----Original Message----- > > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > > Sent: Monday, April 15, 2002 2:20 PM > > > > To: Shahram Davari > > > > Cc: 'Scott Bradner'; mpls@UU.NET > > > > Subject: Re: response to ITU-T SG13 > > > > > > > > > > > > > > > > Shahram> Some vendors may have implemented their MPLS > > > > data-plane in hardware > > > > Shahram> and some in software. Why should a vendor's > > > > implementation be a > > > > Shahram> concern for a standard body such as IETF? > > > > > > > > Shahram> I don't think specific implementations should be a > > > > concern for a > > > > Shahram> standard body such as IETF. You could always > > > > find a specific > > > > Shahram> implementations that can't support a new function. > > > > Any objection > > > > Shahram> regarding backward compatibility should be based on > > > > a standard. > > > > > > > > Are you saying that the characteristics of existing > > > > deployments and > > > > implementations should deliberately be ignored by the WG > > > > as it makes its > > > > decisions? > > > > > >No. I am saying that a specific implementation by a > specific vendor/ > > >operator should not be the basis for any standard argument. If most > > >vendors/operators > > >implement a function in the same manner, then that is a different > >story. > > >But still an alternative solution should exist, otherwise > it is best to > >have > > >a solution rather than nothing at all. > > > > Why not? The mantra at the IETF is "working code and rough > >consensus." > >Sounds like we base things on real implementations around here to me. > > > >Rough consensus is not = Cisco consensus > > Working code and rough consensus often > comes from a variety of fine device vendors. If it happens > to include some that you don't particularly like, that really > isn't the > point, is it? > > Unfortunately you didn't get my point. My point was that one company's implementation is not enough for consensus. It has nothing to do with liking or disliking or being a fine vendor or not. -Shahram --Tom > > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > From owner-mpls@UU.NET Wed Apr 17 09:52:01 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17439 for ; Wed, 17 Apr 2002 09:52:00 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkzf23431; Wed, 17 Apr 2002 13:50:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkzf25159 for mpls-outgoing; Wed, 17 Apr 2002 13:50:42 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkzf25146 for ; Wed, 17 Apr 2002 13:50:40 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 QQmkzf28511 for ; Wed, 17 Apr 2002 13:50:19 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmkzf17321 for ; Wed, 17 Apr 2002 13:50:18 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 JAA11865 for ; Wed, 17 Apr 2002 09:50:18 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA22189 for mpls@uu.net; Wed, 17 Apr 2002 09:50:18 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkzf24763 for ; Wed, 17 Apr 2002 13:46:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmkzf19744 for ; Wed, 17 Apr 2002 13:46:34 GMT Received: from fe170.worldonline.dk by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: fe170.worldonline.dk [212.54.64.199]) id QQmkzf21638 for ; Wed, 17 Apr 2002 13:46:34 GMT Received: (qmail 17615 invoked by uid 99); 17 Apr 2002 13:45:06 -0000 Message-ID: <20020417134506.17611.qmail@fe170.worldonline.dk> X-Remote: 62.242.242.14 From: "Per F Hansen" To: tli@juniper.net Cc: mpls@UU.NET Subject: IBM MPLS patent Date: Wed, 17 Apr 2002 13:45:06 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Sender: perfhans@tiscali.dk Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello I saw an email from you 22/2-1999 related to the IBM mpls patent claim discussions. Can you or any other give an update about what has happened since. Do people pay IBM a fee, or have the MPLS stadards been changed to come around IBM, or were there practically a technical implementation way to come around IBM and still be MPLS compliant. Per From owner-mpls@UU.NET Wed Apr 17 09:52:39 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17458 for ; Wed, 17 Apr 2002 09:52:39 -0400 (EDT) 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 QQmkzf22540; Wed, 17 Apr 2002 13:47:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkzf24797 for mpls-outgoing; Wed, 17 Apr 2002 13:47: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 QQmkzf24765 for ; Wed, 17 Apr 2002 13:46: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 QQmkzf14985 for ; Wed, 17 Apr 2002 13:46: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 QQmkzf11990 for ; Wed, 17 Apr 2002 13:46:25 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 JAA11594 for ; Wed, 17 Apr 2002 09:46:25 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA21527 for mpls@uu.net; Wed, 17 Apr 2002 09:46:25 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkyu10146 for ; Wed, 17 Apr 2002 11:01:14 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmkyu17825 for ; Wed, 17 Apr 2002 11:00:50 GMT Received: from web13001.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web13001.mail.yahoo.com [216.136.174.11]) id QQmkyu09761 for ; Wed, 17 Apr 2002 11:00:50 GMT Message-ID: <20020417070048.40550.qmail@web13001.mail.yahoo.com> Received: from [211.167.238.106] by web13001.mail.yahoo.com via HTTP; Wed, 17 Apr 2002 00:00:48 PDT Date: Wed, 17 Apr 2002 00:00:48 -0700 (PDT) From: Jianwu HE Subject: about TE link (GMPLS) and SNPP link (ASON) To: Zhi-Wei Lin Cc: ccamp@ops.ietf.org, mpls@UU.NET In-Reply-To: <3CBAD87E.4030403@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Dr Lin, In GMPLS architecture, TE Link is defined, and in G.8080(ASON), SNPP Link is defined. I think TE Link and SNPP link have many same characteristics, all for routing. Can you described this problem in detail Jianwu HE jianwuhe@hotmail.com Beijing Univ.of Posts and Telecomm. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From owner-mpls@UU.NET Wed Apr 17 10:32:18 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20480 for ; Wed, 17 Apr 2002 10:32:18 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkzi13560; Wed, 17 Apr 2002 14:31:25 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkzi19338 for mpls-outgoing; Wed, 17 Apr 2002 14:31: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 QQmkzi19333 for ; Wed, 17 Apr 2002 14:31: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 QQmkzi26290 for ; Wed, 17 Apr 2002 14:30:20 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 QQmkzi17326 for ; Wed, 17 Apr 2002 14:30:19 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 KAA01374 for ; Wed, 17 Apr 2002 10:30:17 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26633 for ; Wed, 17 Apr 2002 10:30:18 -0400 (EDT) Message-ID: <3CBD8714.4DC4DD1@marconi.com> Date: Wed, 17 Apr 2002 10:30:44 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: RSVP-TE: DIFFSERV object class Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The diff-ext draft still lists the class number for the DIFFSERV object as "TBD". Is there any particular class number that people are using for their products while waiting for an IANA-assigned number? -- David From owner-mpls@UU.NET Wed Apr 17 11:02:48 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21947 for ; Wed, 17 Apr 2002 11:02:48 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkzk24026; Wed, 17 Apr 2002 15:01:39 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkzk26786 for mpls-outgoing; Wed, 17 Apr 2002 15:01:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkzk26775 for ; Wed, 17 Apr 2002 15:01:18 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 QQmkzk18259 for ; Wed, 17 Apr 2002 15:01: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 QQmkzk28436 for ; Wed, 17 Apr 2002 15:01:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA18894 for ; Wed, 17 Apr 2002 11:01:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA00809 for mpls@uu.net; Wed, 17 Apr 2002 11:01:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmkzk23191 for ; Wed, 17 Apr 2002 15:00:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkzk05605 for ; Wed, 17 Apr 2002 15:00:04 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [161.44.168.94]) id QQmkzk21763 for ; Wed, 17 Apr 2002 15:00:04 GMT Received: from pilgrim.cisco.com (localhost [127.0.0.1]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA28461; Wed, 17 Apr 2002 10:58:41 -0400 (EDT) Message-Id: <200204171458.KAA28461@pilgrim.cisco.com> To: "David Allan" cc: mpls@UU.NET Subject: Re: response to ITU-T SG13 In-reply-to: Your message of "Tue, 16 Apr 2002 10:30:32 EDT." <3549C09B853DD5119B540002A52CDD3402C6EEF9@zcard0ka.ca.nortel.com> Date: Wed, 17 Apr 2002 10:58:41 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk David - Since I was the one who put PIM on the list, let me explain. I don't consider it an unreasonable hurdle. The question is simply this. First an implementation of MPLS with PIM exists. Since PIM itself is not yet standard, there has been little pressure to push the former along. But it isn't completely a future consideration. MPLS (unlike ATM) has a unified dataplane which can be directly accessed by multiple control planes. If an OAM scheme depends on moving information through the control plane, and if OAM support is presummed on every LSP as my reading of Y.1711 seems to imply then presummably *every* MPLS control plane (current, in progress, or future) needs some level of OAM awareness and interaction. So I'd like to understand where this is To: "David Allan" cc: mpls@UU.NET Fcc: outbox Subject: Re: response to ITU-T SG13 In-reply-to: Your message of "Tue, 16 Apr 2002 10:30:32 EDT." <3549C09B853DD5119B540002A52CDD3402C6EEF9@zcard0ka.ca.nortel.com> -------- David - Since I was the one who put PIM on the list, let me explain. I don't consider it an unreasonable hurdle. First an implementation of MPLS with PIM exists. Since PIM itself is not yet standard, there has been little pressure to push the former along. But it isn't completely a future consideration. The question is simply this. MPLS (unlike ATM) has a unified dataplane which can be directly accessed by multiple control planes. If an OAM scheme depends on moving information through the control plane, and if OAM support is presummed on every LSP as my reading of Y.1711 seems to imply, then presummably *every* MPLS control plane (current, in progress, or future) needs some level of OAM awareness and interaction. So I'd like to understand where this is headed. If the ITU is envisioning ubiquitous OAM support, it gets very onerous. Not only do I have to worry about supporting it in many protocols, but I also have to worry about the interactions between protocols, like when I run LDP across a tunnel created by RSVP. If on the other hand OAM can be deployed on a limited basis, then things aren't as bad. So the question is intended to get at the scope of what the ITU is up to. ///George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Apr 17 11:19:49 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22724 for ; Wed, 17 Apr 2002 11:19:49 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkzl21214; Wed, 17 Apr 2002 15:17:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkzl14465 for mpls-outgoing; Wed, 17 Apr 2002 15:16: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 QQmkzl14458 for ; Wed, 17 Apr 2002 15:16: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 QQmkzl17002 for ; Wed, 17 Apr 2002 15:15:18 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmkzl12583 for ; Wed, 17 Apr 2002 15:15:18 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3HFF7h08476; Wed, 17 Apr 2002 11:15:08 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 11:15:08 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402CC6F1D@zcard0ka.ca.nortel.com> From: "David Allan" To: George Swallow Cc: mpls@UU.NET Subject: RE: response to ITU-T SG13 Date: Wed, 17 Apr 2002 11:15:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E622.A59AADBE" 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_01C1E622.A59AADBE Content-Type: text/plain; charset="ISO-8859-1" Thanks George, So for my understanding and clarification as to exactly what we're discussing...... The multicast MPLS protocol used with PIM presumably is a PPP PID of 0x283 and the unicast MPLS protocol used with the other control planes is a PPP PID of 0x281? thanks Dave > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Wednesday, April 17, 2002 10:59 AM > To: Allan, David [CAR:NS00:EXCH] > Cc: mpls@UU.NET > Subject: Re: response to ITU-T SG13 > > > David - > > Since I was the one who put PIM on the list, let me explain. I don't > consider it an unreasonable hurdle. The question is simply this. > > First an implementation of MPLS with PIM exists. Since PIM itself is > not yet standard, there has been little pressure to push the former > along. But it isn't completely a future consideration. > > MPLS (unlike ATM) has a unified dataplane which can be directly > accessed by multiple control planes. If an OAM scheme depends on > moving information through the control plane, and if OAM support is > presummed on every LSP as my reading of Y.1711 seems to imply then > presummably *every* MPLS control plane (current, in progress, or > future) needs some level of OAM awareness and interaction. So I'd > like to understand where this is To: "David Allan" > > cc: mpls@UU.NET > Fcc: outbox > Subject: Re: response to ITU-T SG13 > In-reply-to: Your message of "Tue, 16 Apr 2002 10:30:32 EDT." > > <3549C09B853DD5119B540002A52CDD3402C6EEF9@zcard0ka.ca.nortel.com> > -------- > David - > > Since I was the one who put PIM on the list, let me explain. I don't > consider it an unreasonable hurdle. > > First an implementation of MPLS with PIM exists. Since PIM itself is > not yet standard, there has been little pressure to push the former > along. But it isn't completely a future consideration. > > The question is simply this. > > MPLS (unlike ATM) has a unified dataplane which can be directly > accessed by multiple control planes. If an OAM scheme depends on > moving information through the control plane, and if OAM support is > presummed on every LSP as my reading of Y.1711 seems to imply, then > presummably *every* MPLS control plane (current, in progress, or > future) needs some level of OAM awareness and interaction. So I'd > like to understand where this is headed. If the ITU is envisioning > ubiquitous OAM support, it gets very onerous. Not only do I have to > worry about supporting it in many protocols, but I also have to worry > about the interactions between protocols, like when I run LDP across > a tunnel created by RSVP. > > If on the other hand OAM can be deployed on a limited basis, then > things aren't as bad. So the question is intended to get at the scope > of what the ITU is up to. > > ///George > > ================================================================== > George Swallow Cisco Systems (978) 497-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > > > > > > > ------_=_NextPart_001_01C1E622.A59AADBE Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: response to ITU-T SG13

Thanks George,

So for my understanding and clarification as to = exactly what we're discussing...... The multicast MPLS protocol used = with PIM presumably is a PPP PID of 0x283 and the unicast MPLS protocol = used with the other control planes is a PPP PID of 0x281?

thanks
Dave


> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Wednesday, April 17, 2002 10:59 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: mpls@UU.NET
> Subject: Re: response to ITU-T SG13
>
>
> David -
>
> Since I was the one who put PIM on the list, = let me explain.  I don't
> consider it an unreasonable hurdle.  The = question is simply this.
>
> First an implementation of MPLS with PIM = exists.  Since PIM itself is
> not yet standard, there has been little = pressure to push the former
> along.  But it isn't completely a future = consideration.
>
> MPLS (unlike ATM) has a unified dataplane which = can be directly
> accessed by multiple control planes.  If = an OAM scheme depends on
> moving information through the control plane, = and if OAM support is
> presummed on every LSP as my reading of Y.1711 = seems to imply then
> presummably *every* MPLS control plane = (current, in progress, or
> future) needs some level of OAM awareness and = interaction.  So I'd
> like to understand where this is To: = "David Allan"
> <dallan@nortelnetworks.com>
> cc: mpls@UU.NET
> Fcc: outbox
> Subject: Re: response to ITU-T SG13
> In-reply-to: Your message of "Tue, 16 Apr = 2002 10:30:32 EDT."
>          = ;   
> = <3549C09B853DD5119B540002A52CDD3402C6EEF9@zcard0ka.ca.nortel.com> =
> --------
> David -
>
> Since I was the one who put PIM on the list, = let me explain.  I don't
> consider it an unreasonable hurdle.  =
>
> First an implementation of MPLS with PIM = exists.  Since PIM itself is
> not yet standard, there has been little = pressure to push the former
> along.  But it isn't completely a future = consideration.
>
> The question is simply this.
>
> MPLS (unlike ATM) has a unified dataplane which = can be directly
> accessed by multiple control planes.  If = an OAM scheme depends on
> moving information through the control plane, = and if OAM support is
> presummed on every LSP as my reading of Y.1711 = seems to imply, then
> presummably *every* MPLS control plane = (current, in progress, or
> future) needs some level of OAM awareness and = interaction.  So I'd
> like to understand where this is headed.  = If the ITU is envisioning
> ubiquitous OAM support, it gets very = onerous.  Not only do I have to
> worry about supporting it in many protocols, = but I also have to worry
> about the interactions between protocols, like = when I run LDP across
> a tunnel created by RSVP. 
>
> If on the other hand OAM can be deployed on a = limited basis, then
> things aren't as bad.  So the question is = intended to get at the scope
> of what the ITU is up to.
>
> ///George
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> George = Swallow       Cisco = Systems           = ;       (978) 497-8143
>          = ;            250 = Apollo Drive
>          = ;            = Chelmsford, Ma 01824
>
>
>
>
>
>
>
>
>

------_=_NextPart_001_01C1E622.A59AADBE-- From owner-mpls@UU.NET Wed Apr 17 11:38:52 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23592 for ; Wed, 17 Apr 2002 11:38:52 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkzm12534; Wed, 17 Apr 2002 15:37:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkzm15797 for mpls-outgoing; Wed, 17 Apr 2002 15:36: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 QQmkzm15790 for ; Wed, 17 Apr 2002 15:36:41 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 QQmkzm14015 for ; Wed, 17 Apr 2002 15:35: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 QQmkzm15832 for ; Wed, 17 Apr 2002 15:35:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA21762 for ; Wed, 17 Apr 2002 11:35:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA04605 for mpls@uu.net; Wed, 17 Apr 2002 11:35:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmkzm15468 for ; Wed, 17 Apr 2002 15:34:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkzm08642 for ; Wed, 17 Apr 2002 15:33:21 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [161.44.168.94]) id QQmkzm07631 for ; Wed, 17 Apr 2002 15:33:20 GMT Received: from pilgrim.cisco.com (localhost [127.0.0.1]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA01930; Wed, 17 Apr 2002 11:33:13 -0400 (EDT) Message-Id: <200204171533.LAA01930@pilgrim.cisco.com> To: "David Allan" cc: George Swallow , mpls@UU.NET, swallow@cisco.com Subject: Re: response to ITU-T SG13 In-reply-to: Your message of "Wed, 17 Apr 2002 11:15:02 EDT." <3549C09B853DD5119B540002A52CDD3402CC6F1D@zcard0ka.ca.nortel.com> Date: Wed, 17 Apr 2002 11:33:12 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk > So for my understanding and clarification as to exactly what we're > discussing...... The multicast MPLS protocol used with PIM presumably is a > PPP PID of 0x283 and the unicast MPLS protocol used with the other control > planes is a PPP PID of 0x281? Yes. Except for ATM which doesn't use PPP encaps. ///George ================================================================== George Swallow Cisco Systems (978) 497-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Apr 17 11:49:40 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23939 for ; Wed, 17 Apr 2002 11:49:40 -0400 (EDT) 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 QQmkzn16967; Wed, 17 Apr 2002 15:48:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkzn16882 for mpls-outgoing; Wed, 17 Apr 2002 15:48: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 QQmkzn16877 for ; Wed, 17 Apr 2002 15:48:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmkzn05835 for ; Wed, 17 Apr 2002 15:47: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 QQmkzn01836 for ; Wed, 17 Apr 2002 15:47:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA22519 for ; Wed, 17 Apr 2002 11:47:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA06111 for mpls@uu.net; Wed, 17 Apr 2002 11:47:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmkzn16709 for ; Wed, 17 Apr 2002 15:46:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmkzn21036 for ; Wed, 17 Apr 2002 15:45:10 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQmkzn29356 for ; Wed, 17 Apr 2002 15:45:10 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3HFjOql009258; Wed, 17 Apr 2002 11:45:24 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (katie.cisco.com [10.83.99.126]) by bucket.cisco.com (Mirapoint) with ESMTP id AAX14402; Wed, 17 Apr 2002 11:44:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20020417114203.0252ae90@bucket> X-Sender: tnadeau@bucket X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Apr 2002 11:44:57 -0400 To: Shahram Davari From: "Thomas D. Nadeau" Subject: RE: response to ITU-T SG13 Cc: "''erosen@cisco.com' '" , "''Scott Bradner' '" , "'mpls@UU.NET '" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE84A706@nt-exch-yow.pmc-sie rra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 06:47 AM 4/17/2002 -0700, Shahram Davari wrote: > > -----Original Message----- > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > Sent: Tuesday, April 16, 2002 5:04 PM > > To: Shahram Davari > > Cc: ''erosen@cisco.com' '; ''Scott Bradner' '; 'mpls@UU.NET ' > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > >-----Original Message----- > > >From: Thomas D. Nadeau > > >To: Shahram Davari > > >Cc: 'erosen@cisco.com'; 'Scott Bradner'; mpls@UU.NET > > >Sent: 15/04/02 5:47 PM > > >Subject: RE: response to ITU-T SG13 > > > > > >At 11:26 AM 4/15/2002 -0700, Shahram Davari wrote: > > > >Eric, > > > > > > > > > -----Original Message----- > > > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > > > Sent: Monday, April 15, 2002 2:20 PM > > > > > To: Shahram Davari > > > > > Cc: 'Scott Bradner'; mpls@UU.NET > > > > > Subject: Re: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > > > Shahram> Some vendors may have implemented their MPLS > > > > > data-plane in hardware > > > > > Shahram> and some in software. Why should a vendor's > > > > > implementation be a > > > > > Shahram> concern for a standard body such as IETF? > > > > > > > > > > Shahram> I don't think specific implementations should be a > > > > > concern for a > > > > > Shahram> standard body such as IETF. You could always > > > > > find a specific > > > > > Shahram> implementations that can't support a new function. > > > > > Any objection > > > > > Shahram> regarding backward compatibility should be based on > > > > > a standard. > > > > > > > > > > Are you saying that the characteristics of existing > > > > > deployments and > > > > > implementations should deliberately be ignored by the WG > > > > > as it makes its > > > > > decisions? > > > > > > > >No. I am saying that a specific implementation by a > > specific vendor/ > > > >operator should not be the basis for any standard argument. If most > > > >vendors/operators > > > >implement a function in the same manner, then that is a different > > >story. > > > >But still an alternative solution should exist, otherwise > > it is best to > > >have > > > >a solution rather than nothing at all. > > > > > > Why not? The mantra at the IETF is "working code and rough > > >consensus." > > >Sounds like we base things on real implementations around here to me. > > > > > >Rough consensus is not = Cisco consensus > > > > Working code and rough consensus often > > comes from a variety of fine device vendors. If it happens > > to include some that you don't particularly like, that really > > isn't the > > point, is it? > > > > > >Unfortunately you didn't get my point. My point was that one company's >implementation is not enough for consensus. It has nothing to do with liking >or disliking or being a fine vendor or not. If your point was indeed that more than one vendor needs to implement the OAM that was discussed at the last MPLS WG meeting, I believe that there are at least 3 vendors doing that and more on the way from what I understand. So your assertion that the solution the we have been discussing is a one vendor solution, then I think that your assertion is flawed. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Wed Apr 17 11:57:07 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24216 for ; Wed, 17 Apr 2002 11:57:02 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmkzn09208; Wed, 17 Apr 2002 15:56:11 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkzn17381 for mpls-outgoing; Wed, 17 Apr 2002 15:55:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmkzn17376 for ; Wed, 17 Apr 2002 15:55:47 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 QQmkzn25400 for ; Wed, 17 Apr 2002 15:55:08 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmkzn12838 for ; Wed, 17 Apr 2002 15:55:07 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA23079 for ; Wed, 17 Apr 2002 11:55:07 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA07277 for mpls@uu.net; Wed, 17 Apr 2002 11:55:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmkzn17245 for ; Wed, 17 Apr 2002 15:54:18 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 QQmkzn10126 for ; Wed, 17 Apr 2002 15:54:03 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmkzn11381 for ; Wed, 17 Apr 2002 15:54:02 GMT Received: (qmail 28048 invoked by uid 104); 17 Apr 2002 15:54:02 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4196. . Clean. Processed in 0.451607 secs); 17 Apr 2002 15:54:02 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 17 Apr 2002 15:54:01 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g3HFrwp28273; Wed, 17 Apr 2002 08:53:58 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Apr 2002 08:54:02 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A70A@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Thomas D. Nadeau'" Cc: "''erosen@cisco.com' '" , "''Scott Bradner' '" , "'mpls@UU.NET '" Subject: RE: response to ITU-T SG13 Date: Wed, 17 Apr 2002 08:53:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Wednesday, April 17, 2002 11:45 AM > To: Shahram Davari > Cc: ''erosen@cisco.com' '; ''Scott Bradner' '; 'mpls@UU.NET ' > Subject: RE: response to ITU-T SG13 > > > At 06:47 AM 4/17/2002 -0700, Shahram Davari wrote: > > > > > -----Original Message----- > > > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > > > Sent: Tuesday, April 16, 2002 5:04 PM > > > To: Shahram Davari > > > Cc: ''erosen@cisco.com' '; ''Scott Bradner' '; 'mpls@UU.NET ' > > > Subject: RE: response to ITU-T SG13 > > > > > > > > > > > > > > > >-----Original Message----- > > > >From: Thomas D. Nadeau > > > >To: Shahram Davari > > > >Cc: 'erosen@cisco.com'; 'Scott Bradner'; mpls@UU.NET > > > >Sent: 15/04/02 5:47 PM > > > >Subject: RE: response to ITU-T SG13 > > > > > > > >At 11:26 AM 4/15/2002 -0700, Shahram Davari wrote: > > > > >Eric, > > > > > > > > > > > -----Original Message----- > > > > > > From: Eric Rosen [mailto:erosen@cisco.com] > > > > > > Sent: Monday, April 15, 2002 2:20 PM > > > > > > To: Shahram Davari > > > > > > Cc: 'Scott Bradner'; mpls@UU.NET > > > > > > Subject: Re: response to ITU-T SG13 > > > > > > > > > > > > > > > > > > > > > > > > Shahram> Some vendors may have implemented their MPLS > > > > > > data-plane in hardware > > > > > > Shahram> and some in software. Why should a vendor's > > > > > > implementation be a > > > > > > Shahram> concern for a standard body such as IETF? > > > > > > > > > > > > Shahram> I don't think specific implementations > should be a > > > > > > concern for a > > > > > > Shahram> standard body such as IETF. You could always > > > > > > find a specific > > > > > > Shahram> implementations that can't support a new > function. > > > > > > Any objection > > > > > > Shahram> regarding backward compatibility should be based on > > > > > > a standard. > > > > > > > > > > > > Are you saying that the characteristics of existing > > > > > > deployments and > > > > > > implementations should deliberately be ignored by the WG > > > > > > as it makes its > > > > > > decisions? > > > > > > > > > >No. I am saying that a specific implementation by a > > > specific vendor/ > > > > >operator should not be the basis for any standard > argument. If most > > > > >vendors/operators > > > > >implement a function in the same manner, then that is > a different > > > >story. > > > > >But still an alternative solution should exist, otherwise > > > it is best to > > > >have > > > > >a solution rather than nothing at all. > > > > > > > > Why not? The mantra at the IETF is "working > code and rough > > > >consensus." > > > >Sounds like we base things on real implementations > around here to me. > > > > > > > >Rough consensus is not = Cisco consensus > > > > > > Working code and rough consensus often > > > comes from a variety of fine device vendors. If it happens > > > to include some that you don't particularly like, that really > > > isn't the > > > point, is it? > > > > > > > > > >Unfortunately you didn't get my point. My point was that one > company's > >implementation is not enough for consensus. It has nothing > to do with liking > >or disliking or being a fine vendor or not. > > If your point was indeed that more than one vendor > needs to implement > the OAM that was discussed at the last MPLS WG meeting, I believe that > there are at least 3 vendors doing that and more on the way from what > I understand. So your assertion that the solution the we > have been discussing > is a one vendor solution, then I think that your assertion is flawed. Nobody was talking about this. I suggest that you read the contents of the emails before commenting. -Shahram > > --Tom > > > > > -------------------------------------------------------------- > ---------- > Mathematics is the supreme nostalgia of our time. > From owner-mpls@UU.NET Wed Apr 17 15:15:21 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02572 for ; Wed, 17 Apr 2002 15:15:20 -0400 (EDT) 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 QQmlaa14678; Wed, 17 Apr 2002 19:14:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlaa26657 for mpls-outgoing; Wed, 17 Apr 2002 19:13: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 QQmlaa26652 for ; Wed, 17 Apr 2002 19:13:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlaa28254 for ; Wed, 17 Apr 2002 19:13:37 GMT From: francis.arts@alcatel.be Received: from bt0g2p.god.bel.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc250.alcatel.be [195.207.101.250]) id QQmlaa13660 for ; Wed, 17 Apr 2002 19:13:36 GMT Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by bt0g2p.god.bel.alcatel.be (8.11.0/8.11.4) with ESMTP id g3HJCLE06045 for ; Wed, 17 Apr 2002 21:12:21 +0200 To: mpls@UU.NET Subject: PHP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Wed, 17 Apr 2002 21:13:29 +0200 X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/17/2002 21:13:31, Serialize complete at 04/17/2002 21:13:31 Content-Type: multipart/alternative; boundary="=_alternative 006999C6C1256B9E_=" Sender: owner-mpls@UU.NET Precedence: bulk This is a multipart message in MIME format. --=_alternative 006999C6C1256B9E_= Content-Type: text/plain; charset="us-ascii" Hello, I have a question on RFC 3209 (RSVP-TE spec.). Section 4.2.4 (handling of LABEL REQUEST object) states the following: > If the receiver cannot support the protocol L3PID, it SHOULD send a > PathErr with the error code "Routing problem" and the error value > "Unsupported L3PID." This causes the RSVP session to fail. Does this mean that a **transit** LSR should reject the LSP setup, even though it never sees the data beneath the mpls label? Thanks for any help you can provide, Francis. --=_alternative 006999C6C1256B9E_= Content-Type: text/html; charset="us-ascii"
Hello,

I have a question on RFC 3209 (RSVP-TE spec.). Section 4.2.4 (handling of LABEL REQUEST object) states the following:

> If the receiver cannot support the protocol L3PID, it SHOULD send a
>   PathErr with the error code "Routing problem" and the error value
 >  "Unsupported L3PID."  This causes the RSVP session to fail.

Does this mean that a **transit** LSR should reject the LSP setup, even though it never sees the data beneath the mpls label?

Thanks for any help you can provide,

        Francis. --=_alternative 006999C6C1256B9E_=-- From owner-mpls@UU.NET Wed Apr 17 15:17:19 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02624 for ; Wed, 17 Apr 2002 15:17:19 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlab14719; Wed, 17 Apr 2002 19:16:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlab27477 for mpls-outgoing; Wed, 17 Apr 2002 19: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 QQmlab27384 for ; Wed, 17 Apr 2002 19:15:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlab03431 for ; Wed, 17 Apr 2002 19:15:13 GMT Received: from mail.itri.org.tw by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [140.96.157.2]) id QQmlab20278 for ; Wed, 17 Apr 2002 19:15:06 GMT Received: from itrismtp (localhost [127.0.0.1]) by mail.itri.org.tw (8.9.3+Sun/8.9.1) with ESMTP id DAA08599; Thu, 18 Apr 2002 03:09:23 +0800 (CST) Received: from mail2000.com.tw ([140.96.254.153]) by ms2.itri.org.tw (Lotus Domino Release 5.0.9a) with ESMTP id 2002041803133066:18723 ; Thu, 18 Apr 2002 03:13:30 +0800 Message-ID: <3CBDC9C4.89DC1EB6@mail2000.com.tw> Date: Thu, 18 Apr 2002 03:15:16 +0800 From: "Chang, Chong Yie" Organization: ITRI X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: mpls@UU.NET Subject: Re: Queries regarding RFC 3032 X-MIMETrack: Itemize by SMTP Server on MS2/ITRI(Release 5.0.9a |January 7, 2002) at 2002-04-18 03:13:30 AM, Serialize by Router on ITRISMTP/ITRI(Release 5.0.9 |November 16, 2001) at 2002/04/18 03:13:50 AM, Serialize complete at 2002/04/18 03:13:50 AM Content-Type: multipart/mixed; boundary="------------682E4AEF986500E09BEB7B9F" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------682E4AEF986500E09BEB7B9F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I got some different view from NULL and implicit NULL label. From my view, if a downstream LSR is not capable of handling MPLS encoded packets but it needs the upstream LSR utilize the function of label forwarding, it will distribute implicit NULL label to its upstream. If the downstream need the upstream forward packets according to packet layer 3 address, it will distribute explicit NULL label (0). Am I right or wrong? Best regards, Chang, Chong Yie David Charlap wrote: George Thomas wrote: If there is no LSP associated with the destination, (say for e.g. unicast/muticast/broadcast packet), the packet can be sent as native IP packet without NULL label encapsulation in a MPLS domain or it can be discarded, based on the design of the router. This is my understanding from your response. Correct. Then i would like to know when NULL label encapsulation is to be used? A router that isn't capable of popping a label stack may be required to do so. In this situation, it can swap to NULL. When this happens, the next-hop router is expected to pop off that NULL label prior to processing the packet. My initial understanding was: In a MPLS domain, for IP packets which cannot be associated with a LSP, those packets should be sent to the IP next hop with NULL label encapsulation in a LAN media and it should not be sent as native IP packet. NULL labels are a workaround to get around some kinds of hardware restrictions. I don't think they were ever meant to be the primary means of forwarding unlabeled traffic. -- David . --------------682E4AEF986500E09BEB7B9F Content-Type: text/x-vcard; charset=us-ascii; name="chongyie.vcf" Content-Description: Card for Chang, Chong Yie Content-Disposition: attachment; filename="chongyie.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Chang;Chong Yie x-mozilla-html:FALSE url:www.itri.org.tw org:Industrial Technology Research Institute;Computer & Communication Research Laoratories adr:;;;Hsin Chu;;;Taiwan version:2.1 email;internet:chongyie@mail2000.com.tw title:Associated Engineer fn:Chong Yie Chang end:vcard --------------682E4AEF986500E09BEB7B9F-- From owner-mpls@UU.NET Wed Apr 17 15:36:34 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03512 for ; Wed, 17 Apr 2002 15:36:34 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlac18355; Wed, 17 Apr 2002 19:35:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlac28696 for mpls-outgoing; Wed, 17 Apr 2002 19:35:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmlac28657 for ; Wed, 17 Apr 2002 19:35: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 QQmlac08670 for ; Wed, 17 Apr 2002 19:34:38 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: law2-f15.hotmail.com [216.32.181.15]) id QQmlac15324 for ; Wed, 17 Apr 2002 19:34:38 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Apr 2002 12:34:38 -0700 Received: from 63.104.212.252 by lw2fd.hotmail.msn.com with HTTP; Wed, 17 Apr 2002 19:34:37 GMT X-Originating-IP: [63.104.212.252] From: "Sandeep B" To: francis.arts@alcatel.be, mpls@UU.NET Subject: PHP Date: Wed, 17 Apr 2002 19:34:37 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Apr 2002 19:34:38.0039 (UTC) FILETIME=[E95D4E70:01C1E646] Sender: owner-mpls@UU.NET Precedence: bulk Francis, If all vendors support MPLS as it was intended, only egress and penultimate hop should be checking for L3PID. No intermediate LSR should be even noticing what is inside the label. Few of the biggest names in industry do check on L3PID at every LSR and reject if its not IP. Due to this all other implementations of MPLS based VPNs signal L3PID as 0x800 (IP) even when it is suppose to be 0x8847. my 2 cents. -Sandeep Hello, I have a question on RFC 3209 (RSVP-TE spec.). Section 4.2.4 (handling of LABEL REQUEST object) states the following: >If the receiver cannot support the protocol L3PID, it SHOULD send a >PathErr with the error code "Routing problem" and the error value > "Unsupported L3PID." This causes the RSVP session to fail. Does this mean that a **transit** LSR should reject the LSP setup, even though it never sees the data beneath the mpls label? Thanks for any help you can provide, Francis. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Wed Apr 17 15:55:54 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04572 for ; Wed, 17 Apr 2002 15:55:54 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlad07171; Wed, 17 Apr 2002 19:54:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlad00306 for mpls-outgoing; Wed, 17 Apr 2002 19:54: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 QQmlad00291 for ; Wed, 17 Apr 2002 19:54: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 QQmlad13789 for ; Wed, 17 Apr 2002 19:52:57 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 QQmlad12178 for ; Wed, 17 Apr 2002 19:52:55 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA08166 for ; Wed, 17 Apr 2002 15:52:52 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17789 for ; Wed, 17 Apr 2002 15:52:52 -0400 (EDT) Message-ID: <3CBDD2AF.BBF6E745@marconi.com> Date: Wed, 17 Apr 2002 15:53:19 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PHP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sandeep B wrote: > > If all vendors support MPLS as it was intended, only egress and > penultimate hop should be checking for L3PID. No intermediate LSR > should be even noticing what is inside the label. Absolutely correct. A transit router shouldn't care at all what's inside the packets. Only nodes that pop labels (and really only those that pop the last label off the stack) need to know about the L3PID, since they are the only nodes who will be responsible for forming an appropriate layer-2 header. > Few of the biggest names in industry do check on L3PID at every > LSR and reject if its not IP. Due to this all other > implementations of MPLS based VPNs signal L3PID as 0x800 (IP) even > when it is suppose to be 0x8847. Your conclusion does not follow from the premise. Even if nobody has a transit router validating L3PID, it is still illegal to use a PPP protcol ID in that field. RFC 3209 explicitly defines this field as an Ethernet type: 4.2.1. Label Request without Label Range ... L3PID an identifier of the layer 3 protocol using this path. Standard Ethertype values are used. It doesn't matter if the ingress/egress nodes are using PPP encapsulation. If the L3 content is IP, the the L3PID field should be 0x0800. It is the responsibility of the ingress and egress nodes to be able to map between the interface's local encapsulation (PPP, or whatever) and standard Ethertype values. To continue this thread just a bit further, it is illogical to have an ingress node use whatever ID its local interface might be using. There is no guarantee that an arbitrary layer-2 will use a 16-bit value for its layer-3 protocol IDs. There is also no guarantee that the egress node will use the same encapsulation as the ingress node. What if the egress node is different? How will it know that the L3PID it was given is supposed to be PPP instead of Ethernet or something else? If it blindly uses the value as-is, then it will be impossible to use ingress/egress interfaces that have different layer-2 technologies, which violates several basic rules of router operation. -- David From owner-mpls@UU.NET Wed Apr 17 16:06:10 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05269 for ; Wed, 17 Apr 2002 16:06:10 -0400 (EDT) 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 QQmlae02741; Wed, 17 Apr 2002 20:04:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlae12192 for mpls-outgoing; Wed, 17 Apr 2002 20:04:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmlae12185 for ; Wed, 17 Apr 2002 20:04: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 QQmlae05818 for ; Wed, 17 Apr 2002 20:04:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmlae20081 for ; Wed, 17 Apr 2002 20:04:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA11027 for ; Wed, 17 Apr 2002 16:04:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA03253 for mpls@uu.net; Wed, 17 Apr 2002 16:04:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmlae11941 for ; Wed, 17 Apr 2002 20:02:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlae15933 for ; Wed, 17 Apr 2002 20:02:37 GMT Received: from hermes.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmr01.intel.com [192.55.52.18]) id QQmlae29314 for ; Wed, 17 Apr 2002 20:02:36 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.39 2002/04/15 17:47:23 root Exp $) with ESMTP id g3HK1WY18417 for ; Wed, 17 Apr 2002 20:01:32 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.16 2002/04/15 17:47:00 root Exp $) with SMTP id g3HJwWn12705 for ; Wed, 17 Apr 2002 19:58:32 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041713040300100 ; Wed, 17 Apr 2002 13:04:03 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id <2HL0J2ZH>; Wed, 17 Apr 2002 13:00:00 -0700 Message-ID: From: "Sharma, Prem" To: "'Vijayanand C - CTD, Chennai.'" , "'eric.gray@sandburst.com'" Cc: mpls@UU.NET Subject: RE: Doubt In Session Estb. Procedure... Date: Wed, 17 Apr 2002 12:59:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, If we look at the following excerpt from the RFC 3036: If the maximum PDU length determined this way is unacceptable to an LSR, it must send a Session Rejected/Parameters Max PDU Length Notification message in response to the Initialization message and not establish the session. If the passive node is sending the negotiated parameters, may be smaller of the two (MIN(proposed by active one, proposed by itself)), then the above condition will always pass at the active LSR and hence the session will always establish - and hence this statements will always be redundant for the active one. Shouldn't it be that way that Passive one sends its own configured values too rather than negotiated ones AND both active and passive run the same algorithm to derive the negotiated values to use over the session. If the derived parameters are not acceptable because of some reason or other than the active and passive ones may terminate the session independently. This will also help in cases where garbled parameters are received from the passive one in response to INIT msg. from active one. Thanks. Prem -----Original Message----- From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com] Sent: Tuesday, April 16, 2002 10:14 PM To: Sharma, Prashant Cc: mpls@UU.NET Subject: RE: Doubt In Session Estb. Procedure... Hello prashant, I think the RFC is pretty clear on this that the second Init( sent by the passive node) will go with the negotiated value. This ensures that the negotiation is over in a single Init by each node. What you are suggesting is an alternative protocol. This way it will take more than a single Init by each node. Also, if its decided that the negotiated value is going to be the lower of the two configurations, what is the point in passive node sending its configuration? Regards, Vijay -----Original Message----- From: Sharma, Prashant [mailto:prashant_sharma@trillium.com] Sent: Wednesday, April 17, 2002 8:05 AM To: 'mpls@UU.NET' Cc: 'eric.gray@sandburst.com' Subject: Doubt In Session Estb. Procedure... Hi, I have one doubt regarding session establishment procedure in LDP. If a node is an active node, then it first sends Initialization message and the passive node responds with Initialization message of its own. My question is, is it mandatory for the passive node to send the negotiated parameters in its initialization message. In other words, is it permitted that passive node sends its configured (and not negotiated parameters) in its Initialization message.In this case active node will also be able to know the peer's configuration (like loop detection), if it needs to take some action based on it. The two nodes can always calculate the negotiated value on receiving the peers Initialization message. RFC is not very clear on this. I require this information to decide the behavior of active node on receiving peers Initialization message. Thanks for your help in advance. Regards Prashant. From owner-mpls@UU.NET Wed Apr 17 16:20:17 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05887 for ; Wed, 17 Apr 2002 16:20:17 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlaf10164; Wed, 17 Apr 2002 20:18:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlaf23523 for mpls-outgoing; Wed, 17 Apr 2002 20:18: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 QQmlaf23517 for ; Wed, 17 Apr 2002 20:18:20 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 QQmlaf22017 for ; Wed, 17 Apr 2002 20:17:58 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 QQmlaf15835 for ; Wed, 17 Apr 2002 20:17:57 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA10630 for ; Wed, 17 Apr 2002 16:17:54 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22908 for ; Wed, 17 Apr 2002 16:17:55 -0400 (EDT) Message-ID: <3CBDD88E.1F9F2EDD@marconi.com> Date: Wed, 17 Apr 2002 16:18:22 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PHP References: <3CBDD2AF.BBF6E745@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 Charlap wrote: > Sandeep B wrote: >> >> If all vendors support MPLS as it was intended, only egress and >> penultimate hop should be checking for L3PID. No intermediate LSR >> should be even noticing what is inside the label. > > Absolutely correct. A transit router shouldn't care at all what's > inside the packets. Only nodes that pop labels (and really only > those that pop the last label off the stack) need to know about the > L3PID, since they are the only nodes who will be responsible for > forming an appropriate layer-2 header. > >> Few of the biggest names in industry do check on L3PID at every >> LSR and reject if its not IP. I should just add that this isn't necessarily unreasonable. Due to the nature of RSVP, a router does not know whether or not it will have to pop a label during Path processing. Yes, it will know if it is the egress node, but if it's not, it can't know in advance if it will be given a label to swap to or a request to pop the label (implicit NULL). Also note that when the route table changes, a pure transit router may become a penultimate-hop router. In other words, a router can't know for certain that it will never be asked to pop a label stack. The result is that it may make sense to validate the L3PID at the time of Path processing. It could wait for the Resv message, and only validate L3PID if it has to do a pop, but that may not be efficient for all implementations. It would also increase the overhead of cleanup after generating the error. But none of this has anythng to do with the fact that RSVP's L3PID must be an Ethernet protcol ID. -- David From owner-mpls@UU.NET Wed Apr 17 16:37:02 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06600 for ; Wed, 17 Apr 2002 16:37:01 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlag04491; Wed, 17 Apr 2002 20:36:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlag24608 for mpls-outgoing; Wed, 17 Apr 2002 20:35: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 QQmlag24603 for ; Wed, 17 Apr 2002 20:35:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlag23389 for ; Wed, 17 Apr 2002 20:34:50 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 QQmlag08781 for ; Wed, 17 Apr 2002 20:34: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 QAA12405 for ; Wed, 17 Apr 2002 16:34:47 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA29043 for ; Wed, 17 Apr 2002 16:34:33 -0400 (EDT) Message-ID: <3CBDDC73.F08E38E5@marconi.com> Date: Wed, 17 Apr 2002 16:34:59 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Queries regarding RFC 3032 References: <3CBDC9C4.89DC1EB6@mail2000.com.tw> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Chang, Chong Yie" wrote: > > I got some different view from NULL and implicit NULL label. > From my view, if a downstream LSR is not capable of handling > MPLS encoded packets but it needs the upstream LSR utilize the > function of label forwarding, it will distribute implicit NULL label > to its upstream. If the downstream LSR is incapable of forwarding labeled traffic, then it has no business participating in MPLS signaling ;-) If an egress router can not pop the label stack, then it may send an implicit NULL upstream - requesting that the upstream router pop the stack before sending the packet. This may result in the egress router receiving a labeled packet (if it's terminating the innermost LSP of a hierarchicl LSP) or an unlabeled packet (if the next-hop is beyond the edge of the MPLS cloud.) > If the downstream need the upstream forward packets according > to packet layer 3 address, it will distribute explicit NULL label > (0). From the standpoint of packet forwarding, implicit NULL is the same as explicit NULL. In both cases, the egress router must forward the packet based on its contents after popping the label stack. With implicit NULL, the previous-hop router does the pop. With explicit NULL, the next-hop router does the pop. There is no other significant difference. -- David From owner-mpls@UU.NET Wed Apr 17 16:37:22 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06630 for ; Wed, 17 Apr 2002 16:37:21 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlag11211; Wed, 17 Apr 2002 20:36:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlag24693 for mpls-outgoing; Wed, 17 Apr 2002 20:36: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 QQmlag24610 for ; Wed, 17 Apr 2002 20:35:58 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 QQmlag13963 for ; Wed, 17 Apr 2002 20:35:34 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: law2-f66.hotmail.com [216.32.181.66]) id QQmlag18652 for ; Wed, 17 Apr 2002 20:35:33 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 17 Apr 2002 13:35:32 -0700 Received: from 63.104.212.252 by lw2fd.hotmail.msn.com with HTTP; Wed, 17 Apr 2002 20:35:32 GMT X-Originating-IP: [63.104.212.252] From: "Sandeep B" To: David.Charlap@marconi.com, mpls@UU.NET Subject: PHP Date: Wed, 17 Apr 2002 20:35:32 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Apr 2002 20:35:32.0960 (UTC) FILETIME=[6BDDFE00:01C1E64F] Sender: owner-mpls@UU.NET Precedence: bulk David, You mention using 0x0800 as L3PID no matter what intermediate L2 protocol is carrying this traffic. Lets say we have a LDP session running over another RSVP Session and this session is a VPN for a frame relay circuit carrying IP traffic. Wouldn't we use a L3PID of LDP-MPLS (0x8847) instead of IP for the RSVP session. My understanding was that this particular RSVP session should get information from LDP protocol on ingress that this session would be used for MPLS traffic and it should setup LSP with L3PID of MPLS. I assume this is what you meant by - David> "It is the responsibility of the ingress and egress nodes to be able to map between the interface's local encapsulation (PPP, or whatever) and standard Ethertype values" -Sandeep _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-mpls@UU.NET Wed Apr 17 17:05:29 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07881 for ; Wed, 17 Apr 2002 17:05:29 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlai14026; Wed, 17 Apr 2002 21:04:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlai08328 for mpls-outgoing; Wed, 17 Apr 2002 21:04: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 QQmlai08321 for ; Wed, 17 Apr 2002 21:04: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 QQmlai04055 for ; Wed, 17 Apr 2002 21:04:01 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQmlai12877 for ; Wed, 17 Apr 2002 21:04:00 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15314 for ; Wed, 17 Apr 2002 17:03:58 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA05757 for ; Wed, 17 Apr 2002 17:03:59 -0400 (EDT) Message-ID: <3CBDE35A.22C1AAB6@marconi.com> Date: Wed, 17 Apr 2002 17:04:27 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PHP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sandeep B wrote: > > You mention using 0x0800 as L3PID no matter what intermediate L2 > protocol is carrying this traffic. Lets say we have a LDP session > running over another RSVP Session and this session is a VPN for a > frame relay circuit carrying IP traffic. Wouldn't we use a L3PID of > LDP-MPLS (0x8847) instead of IP for the RSVP session. No. When you tunnel one LSP through another, you should push a new label onto the label stack. The labeled packet's payload is still IP. You do not send the entire labeled packet - headers and all - into the inner LSP. For example, given this topology: /\ /\ /\ /\ ____/ A\_____/ B\__________/ C\_____/ D\____ 1 \ / 2 \ / 3 \ / 4 \ / 5 \/ \/ \/ \/ Router A is an ingress router for the outer LSP. Router B is an ingress router for the inner LSP. Router C is an egress router for the inner LSP. Router D is an egress router for the outer LSP. An unlabeled IP packet arrives at router A on segment 1. The packet that is sent from A to B on segment 2 should be a labeled packet with one label. Assuming an interface that uses generic encapsulation, it will look like: SHIM HEADER (with one label) IP packet The packet that is sent from B to C on segment three should be a labeled packet with two labels. It should look like: SHIM HEADER (with two labels) IP packet Please note that the payload under the shim header is still the IP packet. Which is why the L3PID should still be 0x0800. It is not what you were describing: SHIM HEADER (with one label) SHIM HEADER (with one label) IP packet In this configuration, the payload of the first shim header would be another shim header - making the L3PID for the inner LSP 0x8847. But this is not how hierarchical LSPs are supposed to be established. -- David From owner-mpls@UU.NET Wed Apr 17 17:33:01 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08566 for ; Wed, 17 Apr 2002 17:33:01 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlak21528; Wed, 17 Apr 2002 21:32:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlak20446 for mpls-outgoing; Wed, 17 Apr 2002 21:31:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmlak20441 for ; Wed, 17 Apr 2002 21:31:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlak05562 for ; Wed, 17 Apr 2002 21:31:35 GMT Received: from mail.timetra.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.timetra.com [63.104.212.2]) id QQmlak12518 for ; Wed, 17 Apr 2002 21:31:34 GMT Received: from vkompella ([192.168.1.253]) by mail.timetra.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 17 Apr 2002 14:29:57 -0700 From: "Vach Kompella" To: "David Charlap" , Subject: RE: PHP Date: Wed, 17 Apr 2002 14:31:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3CBDE35A.22C1AAB6@marconi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 17 Apr 2002 21:29:57.0641 (UTC) FILETIME=[05C4C790:01C1E657] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, So what if they are not "IP packets" but "Ethernet packets" or "Frame Relay packets" in the PWE3 sense of the word. As the PE LER for, say, a martini ethernet pipe, do you want to know about the protocol of the customer packet? If you penultimate-pop the outer label, you end up with a VC label. As the penultimate hop, you certainly don't want to mess with the VC label. You just want to pass it on to the next hop and let it send it down the appropriate PE-CE link. What do you say is the "ethertype" of the packet with the VC label? I think I understand your point about the label stack being treated as a single stack, but it precludes different meanings being given to a label, as in forwarding label vs. demux label. -Vach > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David > Charlap > Sent: Wednesday, April 17, 2002 2:04 PM > To: mpls@UU.NET > Subject: Re: PHP > > > Sandeep B wrote: > > > > You mention using 0x0800 as L3PID no matter what intermediate L2 > > protocol is carrying this traffic. Lets say we have a LDP session > > running over another RSVP Session and this session is a VPN for a > > frame relay circuit carrying IP traffic. Wouldn't we use a L3PID of > > LDP-MPLS (0x8847) instead of IP for the RSVP session. > > No. When you tunnel one LSP through another, you should push a new > label onto the label stack. The labeled packet's payload is still IP. > > You do not send the entire labeled packet - headers and all - into the > inner LSP. > > For example, given this topology: > > /\ /\ /\ /\ > ____/ A\_____/ B\__________/ C\_____/ D\____ > 1 \ / 2 \ / 3 \ / 4 \ / 5 > \/ \/ \/ \/ > > Router A is an ingress router for the outer LSP. > Router B is an ingress router for the inner LSP. > Router C is an egress router for the inner LSP. > Router D is an egress router for the outer LSP. > > An unlabeled IP packet arrives at router A on segment 1. > > The packet that is sent from A to B on segment 2 should be a labeled > packet with one label. Assuming an interface that uses generic > encapsulation, it will look like: > > SHIM HEADER (with one label) > IP packet > > The packet that is sent from B to C on segment three should be a labeled > packet with two labels. It should look like: > > SHIM HEADER (with two labels) > IP packet > > Please note that the payload under the shim header is still the IP > packet. Which is why the L3PID should still be 0x0800. > > It is not what you were describing: > > SHIM HEADER (with one label) > SHIM HEADER (with one label) > IP packet > > In this configuration, the payload of the first shim header would be > another shim header - making the L3PID for the inner LSP 0x8847. But > this is not how hierarchical LSPs are supposed to be established. > > -- David From owner-mpls@UU.NET Wed Apr 17 19:30:59 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10930 for ; Wed, 17 Apr 2002 19:30:53 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlas11013; Wed, 17 Apr 2002 23:30:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlar12669 for mpls-outgoing; Wed, 17 Apr 2002 23:29: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 QQmlar12664 for ; Wed, 17 Apr 2002 23:29: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 QQmlar25955 for ; Wed, 17 Apr 2002 23:29:06 GMT Received: from mail.itri.org.tw by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [140.96.157.2]) id QQmlar09404 for ; Wed, 17 Apr 2002 23:29:04 GMT Received: from itrismtp (localhost [127.0.0.1]) by mail.itri.org.tw (8.9.3+Sun/8.9.1) with ESMTP id HAA15037; Thu, 18 Apr 2002 07:23:12 +0800 (CST) Received: from mail2000.com.tw ([140.96.254.153]) by ms1.itri.org.tw (Lotus Domino Release 5.0.9a) with ESMTP id 2002041807272089:19093 ; Thu, 18 Apr 2002 07:27:20 +0800 Message-ID: <3CBE0541.EE8F928@mail2000.com.tw> Date: Thu, 18 Apr 2002 07:29:05 +0800 From: "Chang, Chong Yie" Organization: ITRI X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: MPLS Discussion X-MIMETrack: Itemize by SMTP Server on MS1/ITRI(Release 5.0.9a |January 7, 2002) at 2002-04-18 07:27:21 AM, Serialize by Router on ITRISMTP/ITRI(Release 5.0.9 |November 16, 2001) at 2002/04/18 07:27:39 AM, Serialize complete at 2002/04/18 07:27:39 AM Subject: pernultimate LSR Content-Type: multipart/mixed; boundary="------------A8622418D666B45B52B23192" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------A8622418D666B45B52B23192 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear David: David Charlap wrote: "Chang, Chong Yie" wrote: I got some different view from NULL and implicit NULL label. From my view, if a downstream LSR is not capable of handling MPLS encoded packets but it needs the upstream LSR utilize the function of label forwarding, it will distribute implicit NULL label to its upstream. If the downstream LSR is incapable of forwarding labeled traffic, then it has no business participating in MPLS signaling ;-) If an egress router can not pop the label stack, then it may send an implicit NULL upstream - requesting that the upstream router pop the stack before sending the packet. This may result in the egress router receiving a labeled packet (if it's terminating the innermost LSP of a hierarchical LSP) or an unlabeled packet (if the next-hop is beyond the edge of the MPLS cloud.) I agree your explanation and thanks. If the downstream need the upstream forward packets according to packet layer 3 address, it will distribute explicit NULL label (0). >From the standpoint of packet forwarding, implicit NULL is the same as explicit NULL. In both cases, the egress router must forward the packet based on its contents after popping the label stack. With implicit NULL, the previous-hop router does the pop. With explicit NULL, the next-hop router does the pop. There is no other significant difference. The penultimate may pop out the last label to reduce the effort of egress LSR (according to Uyless Black's book). If the penultimate knows that it can pop out the last label and it can find out the outgoing port from the incoming label as the index. The penultimate LSR may also knows that it must pop out the label and forward to the specific port (This is defined in NHLFE). I believe that it can reduce the effort of penultimate LSR and egress LSR. It is more like the name label switching. Best regards, Chang, Chong Yie -- David . --------------A8622418D666B45B52B23192 Content-Type: text/x-vcard; charset=us-ascii; name="chongyie.vcf" Content-Description: Card for Chang, Chong Yie Content-Disposition: attachment; filename="chongyie.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Chang;Chong Yie x-mozilla-html:FALSE url:www.itri.org.tw org:Industrial Technology Research Institute;Computer & Communication Research Laoratories adr:;;;Hsin Chu;;;Taiwan version:2.1 email;internet:chongyie@mail2000.com.tw title:Associated Engineer fn:Chong Yie Chang end:vcard --------------A8622418D666B45B52B23192-- From owner-mpls@UU.NET Thu Apr 18 01:17:48 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17979 for ; Thu, 18 Apr 2002 01:17:47 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlbp08494; Thu, 18 Apr 2002 05:16:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlbp15316 for mpls-outgoing; Thu, 18 Apr 2002 05:16:29 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 QQmlbp15311 for ; Thu, 18 Apr 2002 05:16: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 QQmlbo03764 for ; Thu, 18 Apr 2002 05:14: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 QQmlbo02032 for ; Thu, 18 Apr 2002 05:14:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA06843 for ; Thu, 18 Apr 2002 01:14:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id BAA28038 for mpls@uu.net; Thu, 18 Apr 2002 01:14:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmlbo14754 for ; Thu, 18 Apr 2002 05:13:01 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 QQmlbo17764 for ; Thu, 18 Apr 2002 05:11:27 GMT Received: from ganesh.ctd.hctech.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.64.2]) id QQmlbo21010 for ; Thu, 18 Apr 2002 05:11:26 GMT Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Apr 2002 10:48:24 +0530 Message-ID: From: "Vijayanand C - CTD, Chennai." To: "Sharma, Prem" Cc: mpls@UU.NET Subject: RE: Doubt In Session Estb. Procedure... Date: Thu, 18 Apr 2002 10:39:41 +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 Prem, As per the protocol the lower value should be choosen if a diff values are proposed.If either of them cant support this ( this is the key issue which is the difference between the two LSRs) lower value , they can close the session. Normally , the lower value is accepted and it works as though the same algorithm is running at both the places. The protocol tell what to do when an LSR cant accept the negotiated value. Its one more level of flexibility. Regards, Vijay -----Original Message----- From: Sharma, Prem [mailto:p_sharma@trillium.com] Sent: Thursday, April 18, 2002 1:30 AM To: 'Vijayanand C - CTD, Chennai.'; 'eric.gray@sandburst.com' Cc: mpls@UU.NET Subject: RE: Doubt In Session Estb. Procedure... Hi, If we look at the following excerpt from the RFC 3036: If the maximum PDU length determined this way is unacceptable to an LSR, it must send a Session Rejected/Parameters Max PDU Length Notification message in response to the Initialization message and not establish the session. If the passive node is sending the negotiated parameters, may be smaller of the two (MIN(proposed by active one, proposed by itself)), then the above condition will always pass at the active LSR and hence the session will always establish - and hence this statements will always be redundant for the active one. Shouldn't it be that way that Passive one sends its own configured values too rather than negotiated ones AND both active and passive run the same algorithm to derive the negotiated values to use over the session. If the derived parameters are not acceptable because of some reason or other than the active and passive ones may terminate the session independently. This will also help in cases where garbled parameters are received from the passive one in response to INIT msg. from active one. Thanks. Prem -----Original Message----- From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com] Sent: Tuesday, April 16, 2002 10:14 PM To: Sharma, Prashant Cc: mpls@UU.NET Subject: RE: Doubt In Session Estb. Procedure... Hello prashant, I think the RFC is pretty clear on this that the second Init( sent by the passive node) will go with the negotiated value. This ensures that the negotiation is over in a single Init by each node. What you are suggesting is an alternative protocol. This way it will take more than a single Init by each node. Also, if its decided that the negotiated value is going to be the lower of the two configurations, what is the point in passive node sending its configuration? Regards, Vijay -----Original Message----- From: Sharma, Prashant [mailto:prashant_sharma@trillium.com] Sent: Wednesday, April 17, 2002 8:05 AM To: 'mpls@UU.NET' Cc: 'eric.gray@sandburst.com' Subject: Doubt In Session Estb. Procedure... Hi, I have one doubt regarding session establishment procedure in LDP. If a node is an active node, then it first sends Initialization message and the passive node responds with Initialization message of its own. My question is, is it mandatory for the passive node to send the negotiated parameters in its initialization message. In other words, is it permitted that passive node sends its configured (and not negotiated parameters) in its Initialization message.In this case active node will also be able to know the peer's configuration (like loop detection), if it needs to take some action based on it. The two nodes can always calculate the negotiated value on receiving the peers Initialization message. RFC is not very clear on this. I require this information to decide the behavior of active node on receiving peers Initialization message. Thanks for your help in advance. Regards Prashant. From owner-mpls@UU.NET Thu Apr 18 04:37:44 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29059 for ; Thu, 18 Apr 2002 04:37:44 -0400 (EDT) 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 QQmlbx20599; Thu, 18 Apr 2002 07:27:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlbx06934 for mpls-outgoing; Thu, 18 Apr 2002 07:27:14 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 QQmlbx06929 for ; Thu, 18 Apr 2002 07:27: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 QQmlbx24898 for ; Thu, 18 Apr 2002 07:26:30 GMT Received: from merlot.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: natint.juniper.net [207.17.136.129]) id QQmlbx14410 for ; Thu, 18 Apr 2002 07:26:29 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 g3I7QPT17801; Thu, 18 Apr 2002 00:26:25 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g3I7QPf84284; Thu, 18 Apr 2002 00:26:25 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 18 Apr 2002 00:26:25 -0700 (PDT) From: Kireeti Kompella To: Vach Kompella cc: David Charlap , Subject: RE: PHP In-Reply-To: Message-ID: <20020418001303.N84254-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 17 Apr 2002, Vach Kompella wrote: > So what if they are not "IP packets" but "Ethernet packets" or "Frame Relay > packets" in the PWE3 sense of the word. Perhaps you are all agreeing, in different ways (not unusual). David wrote: > Please note that the payload under the shim header is still the IP > packet. Which is why the L3PID should still be 0x0800. David's point is, an LSP used to carry IP is signaled with an L3PID of 0x0800, no matter what L2 protocol the LSP is carried *over* and no matter how deep the label stack is (correct me if I misread you, David). However, if an L2 protocol is carried *over* the LSP (e.g., Frame Relay over MPLS using draft-martini), then the LSP should not be signaled (strictly speaking) with an L3PID of IP. (Note: the payload under the shim header (label stack) is no longer IP.) > What do you say is the "ethertype" of the packet with the VC label? One could use the convention of "ethertype of 0x8847 means dunno", and signal LSPs used for draft-martini with 0x8847. Kireeti. From owner-mpls@UU.NET Thu Apr 18 08:08:50 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02194 for ; Thu, 18 Apr 2002 08:08:49 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlcq07642; Thu, 18 Apr 2002 12:07:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlcq11900 for mpls-outgoing; Thu, 18 Apr 2002 12:07: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 QQmlcq11895 for ; Thu, 18 Apr 2002 12:07:32 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 QQmlcq08859 for ; Thu, 18 Apr 2002 12:06:34 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQmlcq23532 for ; Thu, 18 Apr 2002 12:06:31 GMT Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19) id <2YYVYTM3>; Thu, 18 Apr 2002 17:35:42 +0530 Message-ID: <9027F68B07E7D511AE9400B0D0787DC006282B@mailserver.netbrahma.com> From: Khuzema Pithewan To: mpls@UU.NET Subject: FF style in gmpls Date: Thu, 18 Apr 2002 17:35:33 +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, In gmpls signalling, (RSVP) Can one session contain multiple LSPs i.e. multiple Flow Descriptor (FF style) coming in the Resv Message? If yes, then how multiple filterSpecs can be associated with one set of AdminStatus and IF_ID RSVP_HOP's data channels ? Lets say, if AdminStatus object has 'D' bit set then which LSP should assume 'Deletion in progress' ? Regards, Khuzema ---------------------------------------------------------------------------- Net Brahma Technologies KhuzemaP@netbrahma.com www.netbrahma.com Tel : 91.80. 552 1451 Extn 233 Fax : 91.80. 553 7233 ---------------------------------------------------------------------------- From owner-mpls@UU.NET Thu Apr 18 08:12:21 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02281 for ; Thu, 18 Apr 2002 08:12:21 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlcq12937; Thu, 18 Apr 2002 12:11:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlcq12762 for mpls-outgoing; Thu, 18 Apr 2002 12:10:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmlcq12675 for ; Thu, 18 Apr 2002 12:10: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 QQmlcq18401 for ; Thu, 18 Apr 2002 12:10:31 GMT Received: from hyse.g36.hia.no by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: hyse.grm.hia.no [128.39.202.21]) id QQmlcq28969 for ; Thu, 18 Apr 2002 12:10:30 GMT Received: from malle.siving.hia.no ([128.39.202.26]) by hyse.g36.hia.no with Trend Micro InterScan Messaging Security Suite for SMTP v5; Thu, 18 Apr 2002 14:10:28 +0200 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E6D2.0715731D" Subject: Definition of LIB and LFIB X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 18 Apr 2002 14:10:27 +0200 Message-ID: <63AD1AC95D52D311AEB700500483F0009E86DA@malle.siving.hia.no> Thread-Topic: Definition of LIB and LFIB Thread-Index: AcHmDu2jRof2yO9MSBayGEPbIOIygQAABkMwADC4raA= From: "Hallstein Lohne" To: Cc: "Johannes Vea" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1E6D2.0715731D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have found out that Label Forwarding Information Base (LFIB) is a subset of Label Information Base (LIB). I have not been able to find out exactly what information these two information bases contain. =20 So far I found out LFIB contains: - Incoming Label - Outgoing Label - Next Hop - Outgoing Interface =20 1. Is this correct and are there any other fields? =20 I have not found any content specification for LIB. RFC 3036, LDP Specification, explain that this information base contains, among other things, address prefix. 2. What is address prefix? =20 I assume this address is from the Forwarding Equivalence Class (FEC). 3. Is this prefix also in the LFIB? 4. What other parameters are in the LIB in addition to Incoming label, outgoing label and Interface? =20 These should be explained in detail in RFC's but I've not found any information at IETF on this subject at all. =20 =20 =20 Any answers will be appreciated. The questions have been enumerated. =20 Best regards, =20 Johannes Vea Hallstein Lohne Agder University College, Norway ------_=_NextPart_001_01C1E6D2.0715731D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
I have found out that Label = Forwarding=20 Information Base (LFIB) is a subset of Label Information Base (LIB). I = have not=20 been able to find out exactly what information these two information = bases=20 contain.
 
So far I found out LFIB = contains:
   =20 -          Incoming=20 Label
   =20 -          Outgoing=20 Label
   =20 -          Next=20 Hop
   =20 -          Outgoing=20 Interface
 
1. Is=20 this correct and are there any other fields?
 
I have not found any content = specification for=20 LIB.  RFC 3036, LDP Specification, explain that this information = base=20 contains, among other things, address prefix.
2. What is address=20 prefix?
 
I assume this address is from the = Forwarding=20 Equivalence Class (FEC).
3. Is this prefix also in the=20 LFIB?
4. What=20 other parameters are in the LIB in addition to Incoming label, outgoing = label=20 and Interface?
 
These should be explained in = detail in RFC's=20 but I've not found any information at = IETF on=20 this subject at all.
 
 
 
Any answers will be = appreciated. The questions have been=20 enumerated.
 
Best regards,
 
Johannes Vea
Hallstein Lohne
Agder University College,=20 Norway
=00 ------_=_NextPart_001_01C1E6D2.0715731D-- From owner-mpls@UU.NET Thu Apr 18 08:18:32 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02558 for ; Thu, 18 Apr 2002 08:18:32 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlcr10245; Thu, 18 Apr 2002 12:17:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlcr13922 for mpls-outgoing; Thu, 18 Apr 2002 12:17: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 QQmlcr13916 for ; Thu, 18 Apr 2002 12:17: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 QQmlcr02712 for ; Thu, 18 Apr 2002 12:16:41 GMT Received: from ariadne.dt.fee.unicamp.br by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dt.fee.unicamp.br [143.106.8.45]) id QQmlcr08828 for ; Thu, 18 Apr 2002 12:16:37 GMT Received: from athenas.dt.fee.unicamp.br (athenas.dt.fee.unicamp.br [143.106.12.40]) by ariadne.dt.fee.unicamp.br (8.9.3/8.9.3) with SMTP id JAA25817 for ; Thu, 18 Apr 2002 09:06:55 -0300 (EST) Message-Id: <200204181206.JAA25817@ariadne.dt.fee.unicamp.br> Date: Thu, 18 Apr 2002 09:13:56 -0300 (EST) From: Marcos Antonio De Almeida Cora Reply-To: Marcos Antonio De Almeida Cora Subject: Modeling in MPLS To: mpls@UU.NET MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: dkPKXQPs5zoTVS7EgsCvTQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id IAA02558 Hi, My name is Marcos, I'm Msc Student of State University of Campinas / Brazil. I intend to work in my thesis with Modeling and Formal Specification using languages as UML (Unified Modeling Language) and SDL (Specification and Description Language) on MPLS (Multiprotocol Label Switching) The question is, I would like to know if somebody have a suggestion or opinion about it ??? I don't know where accurately I could to apply this analysis into MPLS ??? Where this analysis would be useful into MPLS ??? If somebody will have a suggestion, I'll be grateful. Best Regards, Marcos ______________________________________________________________________ Marcos Antônio de Almeida Corá e-mail: cora@dt.fee.unicamp.br Department of Telematics School of Electrical Engineering and Computation State University of Campinas/Brazil - UNICAMP Others e-mails: marcoscora@zipmail.com.br , marcos.cora@bol.com.br ______________________________________________________________________ From owner-mpls@UU.NET Thu Apr 18 10:05:42 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06684 for ; Thu, 18 Apr 2002 10:05:41 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlcy19452; Thu, 18 Apr 2002 14:04:31 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlcy24059 for mpls-outgoing; Thu, 18 Apr 2002 14: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 QQmlcy24050 for ; Thu, 18 Apr 2002 14:04: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 QQmlcy17276 for ; Thu, 18 Apr 2002 14:04: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 QQmlcy09634 for ; Thu, 18 Apr 2002 14:04:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA23977 for ; Thu, 18 Apr 2002 10:04:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA19815 for mpls@uu.net; Thu, 18 Apr 2002 10:04:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmlcy23997 for ; Thu, 18 Apr 2002 14:03:20 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 QQmlcy19864 for ; Thu, 18 Apr 2002 14:02:43 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQmlcy17117 for ; Thu, 18 Apr 2002 14:02:42 GMT Received: from bucket.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3IE2SHx021891; Thu, 18 Apr 2002 10:02:29 -0400 (EDT) Received: from tnadeau-w2k.cisco.com (katie.cisco.com [10.83.99.126]) by bucket.cisco.com (Mirapoint) with ESMTP id AAX28103; Thu, 18 Apr 2002 10:02:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20020418100137.02029b90@bucket> X-Sender: tnadeau@bucket X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Apr 2002 10:02:02 -0400 To: Marcos Antonio De Almeida Cora From: "Thomas D. Nadeau" Subject: Re: Modeling in MPLS Cc: mpls@UU.NET In-Reply-To: <200204181206.JAA25817@ariadne.dt.fee.unicamp.br> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 09:13 AM 4/18/2002 -0300, Marcos Antonio De Almeida Cora wrote: >Hi, > >My name is Marcos, I'm Msc Student of State University of Campinas / Brazil. >I intend to work in my thesis with Modeling and Formal Specification using >languages as UML (Unified Modeling Language) and SDL (Specification and >Description Language) on MPLS (Multiprotocol Label Switching) > >The question is, I would like to know if somebody have a suggestion or >opinion >about it ??? I don't know where accurately I could to apply this analysis >into >MPLS ??? Where this analysis would be useful into MPLS ??? Modeling work for MPLS has been ongoing in the DMTF for about a year now. Check over there for more information. --Tom ------------------------------------------------------------------------ Mathematics is the supreme nostalgia of our time. From owner-mpls@UU.NET Thu Apr 18 10:17:50 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07271 for ; Thu, 18 Apr 2002 10:17:49 -0400 (EDT) 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 QQmlcz28554; Thu, 18 Apr 2002 14:16:46 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlcz05919 for mpls-outgoing; Thu, 18 Apr 2002 14:16: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 QQmlcz05891 for ; Thu, 18 Apr 2002 14:16: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 QQmlcz13888 for ; Thu, 18 Apr 2002 14:15:07 GMT Received: from alpha.tellium.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [65.119.210.16]) id QQmlcz26208 for ; Thu, 18 Apr 2002 14:15:06 GMT Received: from mail1.tellium.com (unverified) by alpha.tellium.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Apr 2002 10:09:43 -0400 Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id <2VTY222C>; Thu, 18 Apr 2002 10:07:34 -0400 Message-ID: <05707214338CD5119BFF0040A5B170D301176125@mail3.tellium.com> From: Sudipta Sengupta To: "'Marcos Antonio De Almeida Cora'" , mpls@UU.NET Subject: RE: Modeling in MPLS Date: Thu, 18 Apr 2002 10:00:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA07271 marcos, a compiler for converting MPLS powerpoint presentations and internet drafts into source code would be very useful. --sudipta -----Original Message----- From: Marcos Antonio De Almeida Cora [mailto:cora@dt.fee.unicamp.br] Sent: Thursday, April 18, 2002 8:14 AM To: mpls@UU.NET Subject: Modeling in MPLS Hi, My name is Marcos, I'm Msc Student of State University of Campinas / Brazil. I intend to work in my thesis with Modeling and Formal Specification using languages as UML (Unified Modeling Language) and SDL (Specification and Description Language) on MPLS (Multiprotocol Label Switching) The question is, I would like to know if somebody have a suggestion or opinion about it ??? I don't know where accurately I could to apply this analysis into MPLS ??? Where this analysis would be useful into MPLS ??? If somebody will have a suggestion, I'll be grateful. Best Regards, Marcos ______________________________________________________________________ Marcos Antônio de Almeida Corá e-mail: cora@dt.fee.unicamp.br Department of Telematics School of Electrical Engineering and Computation State University of Campinas/Brazil - UNICAMP Others e-mails: marcoscora@zipmail.com.br , marcos.cora@bol.com.br ______________________________________________________________________ From owner-mpls@UU.NET Thu Apr 18 10:39:51 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08611 for ; Thu, 18 Apr 2002 10:39:51 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlda08156; Thu, 18 Apr 2002 14:38:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlda07551 for mpls-outgoing; Thu, 18 Apr 2002 14:38: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 QQmlda07542 for ; Thu, 18 Apr 2002 14:38:21 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 QQmlda08358 for ; Thu, 18 Apr 2002 14:38:05 GMT Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQmlda22965 for ; Thu, 18 Apr 2002 14:38:04 GMT Received: from avici.com (swdev105.avici.com [10.2.21.105]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id g3IEbwW16902; Thu, 18 Apr 2002 10:37:58 -0400 (EDT) Message-Id: <200204181437.g3IEbwW16902@mailhost.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: Kireeti Kompella cc: Vach Kompella , David Charlap , mpls@UU.NET Subject: Re: PHP In-reply-to: Your message of "Thu, 18 Apr 2002 00:26:25 PDT." <20020418001303.N84254-100000@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Apr 2002 10:37:59 -0400 Sender: owner-mpls@UU.NET Precedence: bulk > > On Wed, 17 Apr 2002, Vach Kompella wrote: > > > So what if they are not "IP packets" but "Ethernet packets" or "Frame Relay > > packets" in the PWE3 sense of the word. > > Perhaps you are all agreeing, in different ways (not unusual). > > David wrote: > > > Please note that the payload under the shim header is still the IP > > packet. Which is why the L3PID should still be 0x0800. > > David's point is, an LSP used to carry IP is signaled with an L3PID of > 0x0800, no matter what L2 protocol the LSP is carried *over* and no > matter how deep the label stack is (correct me if I misread you, David). > > However, if an L2 protocol is carried *over* the LSP (e.g., Frame > Relay over MPLS using draft-martini), then the LSP should not be signaled > (strictly speaking) with an L3PID of IP. (Note: the payload under the > shim header (label stack) is no longer IP.) > > > What do you say is the "ethertype" of the packet with the VC label? > > One could use the convention of "ethertype of 0x8847 means dunno", > and signal LSPs used for draft-martini with 0x8847. > > Kireeti. > It looks to me as if the L3PID signaling seemed like a good idea at the time but turned out to be not particularly useful. The problem is that it is often unknown what type of traffic is carried on an LSP. For example an RSVP LSP can be used to carry IP traffic and at the same time also labeled traffic from a targeted LDP session that runs over the RSVP LSP. The type of traffic underneath the LDP label (either IP or some L2 protocol) cannot be known by the RSVP ingress router. So part of the traffic across the RSVP LSP is known to be IP, the other part is unknown. What L3PID is the right one to use? Currently, these LSPs are signaled with a L3PID of IP. The L3PID as currently defined in RSVP-TE does not have any practical value as far as I can tell. Maybe it should be redefined to only apply to packets with a label stack of 1 while all other packets on the LSP with label stack > 1 are simply of unknown protocol type. That way the L3PID is at least useful for the penultimate hop to check whether it's ok to do PHP. Markus From owner-mpls@UU.NET Thu Apr 18 10:47:18 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08828 for ; Thu, 18 Apr 2002 10:47:17 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmldb19352; Thu, 18 Apr 2002 14:46:22 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldb08342 for mpls-outgoing; Thu, 18 Apr 2002 14:45: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 QQmldb08330 for ; Thu, 18 Apr 2002 14:45:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmldb02876 for ; Thu, 18 Apr 2002 14:45:42 GMT Received: from auds953.usa.alcatel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: auds953.usa.alcatel.com [143.209.238.6]) id QQmldb03305 for ; Thu, 18 Apr 2002 14:45:41 GMT Received: from morgoth.pet.usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3IEje615768; Thu, 18 Apr 2002 09:45:40 -0500 (CDT) Received: from alcatel.com (localhost [127.0.0.1]) by morgoth.pet.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g3IEjeW16146; Thu, 18 Apr 2002 07:45:41 -0700 (PDT) Message-ID: <3CBEDC10.1C6A6A9D@alcatel.com> Date: Thu, 18 Apr 2002 07:45:36 -0700 From: Mudhafar Hassan-Ali Organization: Alcatel, USA X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Marcos Antonio De Almeida Cora CC: mpls@UU.NET Subject: Re: Modeling in MPLS References: <200204181206.JAA25817@ariadne.dt.fee.unicamp.br> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Not sure if you are pursuing the modeling of the signaling part or the traffic engineering part (Queuing Modeling). In any case, there are at least two things possible: 1. Though rather classical; it may be interesting to model the performance of bandwidth and queues in LSP merging (label stacking). 2. The performance of LSP switch over during protection switching; in order to determine whether it can meet tight switching time (50 msec). Mudhafar Marcos Antonio De Almeida Cora wrote: > Hi, > > My name is Marcos, I'm Msc Student of State University of Campinas / Brazil. > I intend to work in my thesis with Modeling and Formal Specification using > languages as UML (Unified Modeling Language) and SDL (Specification and > Description Language) on MPLS (Multiprotocol Label Switching) > > The question is, I would like to know if somebody have a suggestion or opinion > about it ??? I don't know where accurately I could to apply this analysis into > MPLS ??? Where this analysis would be useful into MPLS ??? > > If somebody will have a suggestion, I'll be grateful. > > Best Regards, > > Marcos > > ______________________________________________________________________ > > Marcos Antônio de Almeida Corá e-mail: cora@dt.fee.unicamp.br > Department of Telematics > School of Electrical Engineering and Computation > State University of Campinas/Brazil - UNICAMP > Others e-mails: marcoscora@zipmail.com.br , marcos.cora@bol.com.br > ______________________________________________________________________ From owner-mpls@UU.NET Thu Apr 18 11:05:15 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09593 for ; Thu, 18 Apr 2002 11:05:15 -0400 (EDT) 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 QQmldc08764; Thu, 18 Apr 2002 15:03:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldc20844 for mpls-outgoing; Thu, 18 Apr 2002 15:03:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmldc20817 for ; Thu, 18 Apr 2002 15:03: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 QQmldc07399 for ; Thu, 18 Apr 2002 15:02:32 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 QQmldc07160 for ; Thu, 18 Apr 2002 15:02:31 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 LAA00549 for ; Thu, 18 Apr 2002 11:02:31 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA26604 for mpls@uu.net; Thu, 18 Apr 2002 11:02:31 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmlcx11935 for ; Thu, 18 Apr 2002 13:46:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlcx27174 for ; Thu, 18 Apr 2002 13:46:04 GMT Received: from tama5.ecl.ntt.co.jp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQmlcx13917 for ; Thu, 18 Apr 2002 13:46:02 GMT Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/31/02) with ESMTP id WAA23600 for ; Thu, 18 Apr 2002 22:45:46 +0900 (JST) (envelope-from ohta.hiroshi@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.2/8.12.2) with ESMTP id g3IDjjQl001210 for ; Thu, 18 Apr 2002 22:45:45 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.2/8.12.2) with ESMTP id g3IDjiuu012896 for ; Thu, 18 Apr 2002 22:45:45 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id WAA16480 for ; Thu, 18 Apr 2002 22:45:44 +0900 (JST) Received: from HIROSHI-TP2 by imf.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id WAA12784 for ; Thu, 18 Apr 2002 22:45:43 +0900 (JST) Message-Id: <4.2.0.58.J.20020418221303.03a99528@imf.m.ecl.ntt.co.jp> X-Sender: ho016@imf.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 18 Apr 2002 22:44:21 +0900 To: mpls@UU.NET From: Hiroshi Ohta Subject: Re: response to ITU-T SG13 In-Reply-To: <200204122044.g3CKioq25985@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Scott, You indicated your concern on potential future modifications to IETF protocols. Would you clarify what the real problem is? Now, what ITU-T SG13 is asking is only a code point assignment. ITU-T Rec. Y.1711 could be operated without any more modifications to IETF protocols. In order to operate MPLS OAM functions better, modifications to IETF protocols may be proposed in the future. In this case, proposer/mover will submit an I-D. If it is agreed, protocols are modified. If it is rejected, nothing happens. It is nothing more than what is going on in the usual IETF activities. So, I do not think this potential future modification proposals is a problem. Best regards, Hiroshi At 16:44 02/04/12 -0400, you wrote: >This is the response to http://www.ietf.org/IESG/LIAISON/ITU-SG13-MPLS-OAM.txt >that was discussed during the MPLS session in Minneapolis that I plan to >send early next week unless the WG has a problem with that. >(Thanks to George for the draft that this is based on) > >Scott > >--------- > >SOURCE: IETF Sub-IP Area - Scott Bradner, Area co-Director >TITLE: Response to "Communication on the status of the request on the > assignment of a reserved label value for MPLS OAM packet identification" > >The MPLS working group discussed SG 13's request for the assignment of a >reserved label value for MPLS OAM packet identification >(draft-ohta-mpls-label-value-01.txt) during the MPLS session during the >recent IETF meeting in Minneapolis. There was some disagreement during the >discussion about the long term implications of the IETF granting this >request. > >During the discussion it was noted that there are a number of references to >modifications to IETF protocols in Y.1711. In particular, Section 6.1 >states, "Ideally this should be done automatically via LSP signaling at >LSP set-up time (e.g. via a CR-LDP or RSVP control-plane mechanism), but >it could also be configured manually. The mechanism for achieving this >configuration is outside the scope of this Recommendation." > >Since manual configuration is probably not an option for anything beyond a >very limited deployment the implication is that the ITU will require the >IETF to change CR-LDP and RSVP before Y.1711 would be seen as a complete >solution. > >Also in section 6.3, Forward Defect Indication, the following text may be >read as indicating an assumption of future changes in IETF protocols >dealing with LSP signaling. > >"It is important that the LSP sink point knows (for the duration that the >LSP is in service) any server->client LSP label mappings that were in >existence prior to the defect. Although the exact means for achieving this >are outside the scope of this Recommendation, some examples of how these >server-> client layer label mappings could be configured are as follows: > o manually, via the NMS say; > o automatically on LSP set-up via extensions to LSP signaling ..." > >In order to understand the possible consequences of allocating an MPLS >codepoint in response to the request in draft-ohta-mpls-label-value-01.txt >the MPLS working group would like to understand the full scope and extent >of the modifications that SG13 may be assuming to other IETF protocols, >including LDP, CR-LDP, RSVP, PIM and BGP. > >A further concern is the impact on the MPLS forwarding plane as currently >defined. In certain points in a MPLS network, based on an incoming label, >the label is removed and the packet is forwarded with no further inspection >of subsequent headers (be it another MPLS label or some other header). >Y.1711 seems to imply that the above behavior would not satisfy Y.1711. >Specifically, there are some cases where Y.1711 would expect a network >element to intercept an OAM packet. This raises issues of backward >compatibility with existing MPLS systems and ASICs. > >The MPLS working group would like to understand if Y.1711 assumes >functionally that could not be supported by simply changing software in >existing MPLS implementations. > > From owner-mpls@UU.NET Thu Apr 18 11:28:14 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10612 for ; Thu, 18 Apr 2002 11:28:14 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmldd19654; Thu, 18 Apr 2002 15:27:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldd03395 for mpls-outgoing; Thu, 18 Apr 2002 15:27:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmldd03388 for ; Thu, 18 Apr 2002 15:27:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmldd03860 for ; Thu, 18 Apr 2002 15:26:42 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQmldd13603 for ; Thu, 18 Apr 2002 15:26: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 LAA28512 for ; Thu, 18 Apr 2002 11:26:33 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08494 for ; Thu, 18 Apr 2002 11:26:32 -0400 (EDT) Message-ID: <3CBEE5C6.E5D606AD@marconi.com> Date: Thu, 18 Apr 2002 11:27:02 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PHP References: <20020418001303.N84254-100000@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti Kompella wrote: > David wrote: > >> Please note that the payload under the shim header is still the IP >> packet. Which is why the L3PID should still be 0x0800. > > David's point is, an LSP used to carry IP is signaled with an L3PID > of 0x0800, no matter what L2 protocol the LSP is carried *over* and > no matter how deep the label stack is (correct me if I misread you, > David). That would be correct. > However, if an L2 protocol is carried *over* the LSP (e.g., Frame > Relay over MPLS using draft-martini), then the LSP should not be > signaled (strictly speaking) with an L3PID of IP. (Note: the > payload under the shim header (label stack) is no longer IP.) Also correct. If they payload is non-IP, then the L3PID should represent whatever that payload is. >> What do you say is the "ethertype" of the packet with the VC label? > > One could use the convention of "ethertype of 0x8847 means dunno", > and signal LSPs used for draft-martini with 0x8847. If the LSP is carrying L2 traffic, then obviously the concept of ethertypes is meaningless, since Ethernet is an L2 protocol. Ideally, I'd think that a new object, used to indicate the presence of a non-L3 payload (with various C-Types specifying different layers, and the object payload indicating the protocol ID at that layer) should be introduced. Perhaps something like this: C-TYPE = 1 --> L1 LSP payload = parameters defining the L1 characteristics. This would include the L1 type (SONET, SDH, RS-232, etc.), and parameters for defining the configuration of that L1 type (bit-rate, framing params, etc.) This would be useful for signaling circuit-emulation LSPs, C-TYPE = 2 --> L2 LSP payload = ID's indicating L2PID (Ethernet, 802.11, PPP, etc.) C-TYPE = 3 --> L3 LSP payload = IDs indicating L3PID (IP, AppleTalk, etc.) This object would be redundant with the L3PID in LABEL_REQUEST, but is here for completeness. C-TYPE = 4 --> L4 LSP payload = IDs indicating L4PID (TCP, UDP, etc.) It might someday be convenient for these kinds of protocols to run directly over MPLS, without the IP layer. Imagine a proxy that establishes an LSP with a matching proxy somewhere else. This C-TYPE would be a placeholder for such future functionality. It might make sense to define C-TYPEs for all 7 layers, but I can't imagine what an L5, L6, or L7 LSP might be used for. -- David From owner-mpls@UU.NET Thu Apr 18 11:36:21 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11025 for ; Thu, 18 Apr 2002 11:36:20 -0400 (EDT) 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 QQmlde24876; Thu, 18 Apr 2002 15:34:32 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlde03833 for mpls-outgoing; Thu, 18 Apr 2002 15:34: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 QQmlde03824 for ; Thu, 18 Apr 2002 15:34: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 QQmlde15247 for ; Thu, 18 Apr 2002 15:33:08 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 QQmlde22720 for ; Thu, 18 Apr 2002 15:33:08 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 LAA29398 for ; Thu, 18 Apr 2002 11:33:01 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10612 for ; Thu, 18 Apr 2002 11:32:54 -0400 (EDT) Message-ID: <3CBEE744.7690958C@marconi.com> Date: Thu, 18 Apr 2002 11:33:24 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PHP References: <200204181437.g3IEbwW16902@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: > > It looks to me as if the L3PID signaling seemed like a good idea at > the time but turned out to be not particularly useful. The problem > is that it is often unknown what type of traffic is carried on an > LSP. For example an RSVP LSP can be used to carry IP traffic and > at the same time also labeled traffic from a targeted LDP session > that runs over the RSVP LSP. The L3PID of the inner LSP is known, because it is signaled as IP. The ingress router for the inner LSP also knows the L3PID of the outer LSP, since it must participate in the signaling for the outer LSP. I would argue that it should not shunt incompatible traffic into that LSP. Don't allow a non-IP LSP to tunnel through an IP-LSP. If the inner LSP is meant to carry traffic of many different types, then it should be signaled as such. With an L3PID meaning "unknown". Which would mean, of course, that the egress of such an LSP would not be able to handle a packet that only has one label - since it won't know the actual L3PID after popping that last label. But this would be OK, if there's another label on the stack - either indicating an outer LSP to use for forwarding, or indicating the L2/L3 PID. Of course, the whole argument falls apart when you realize that the two LSPs (inner and outer) don't both have to be RSVP. I don't think L3PID is signaled with LDP or CR-LDP. -- David From owner-mpls@UU.NET Thu Apr 18 11:58:13 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11992 for ; Thu, 18 Apr 2002 11:58:13 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmldf14513; Thu, 18 Apr 2002 15:57:03 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldf05786 for mpls-outgoing; Thu, 18 Apr 2002 15:56: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 QQmldf05776 for ; Thu, 18 Apr 2002 15:56:37 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 QQmldf23475 for ; Thu, 18 Apr 2002 15:56:17 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f226.pav2.hotmail.com [64.4.37.226]) id QQmldf29655 for ; Thu, 18 Apr 2002 15:56:17 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Apr 2002 08:56:16 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 18 Apr 2002 15:56:16 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Prefix Mismatch Date: Thu, 18 Apr 2002 15:56:16 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Apr 2002 15:56:16.0869 (UTC) FILETIME=[92DF2950:01C1E6F1] Sender: owner-mpls@UU.NET Precedence: bulk Hi, I have questions regarding longest prefix address. The following is from section 4.1.3. of RFC 3031: ". . Note that a packet's LSP can extend only until it encounters a router whose forwarding tables have a longer best match address prefix for the packet's destination address. At that point, the LSP must end and the best match algorithm must be performed again. Suppose, for example, that packet P, with destination address 10.2.153.178 needs to go from R1 to R2 to R3. Suppose also that R2 advertises address prefix 10.2/16 to R1, but R3 advertises 10.2.153/23, 10.2.154/23, and 10.2/16 to R2. That is, R2 is advertising an "aggregated route" to R1. In this situation, packet P can be label Switched until it reaches R2, but since R2 has performed route aggregation, it must execute the best match algorithm to find P's FEC." Questions: ---------- 1. Does it mean R2 has to terminate LSP for FEC with 10.2/16 address prefix by means of stripping the top label (the only label) and look into IP header to determine its finer FEC and then label the packet again with the appropriate outgoing label. Is this true? 2. Suppose the LSP is being used as a tunnel that ends after R2 and if the answer for my question (1) is true, then stripping the top label will never reveal the IP header yet since there will still be 1 or more labels. Is this situation valid? If so, can R2 still manage to terminate the LSP and perform best match algorithm? If yes, then how? 3. Since R3 also advertised a coarser granularity prefix address, 10.2/16, to R2; can R2 safely maps its own 10.2/16 prefix with R3's equivalent prefix regardless of the existent of the finer granularity prefixes? What are the consequences if it does not follow the rules. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-mpls@UU.NET Thu Apr 18 12:20:42 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13269 for ; Thu, 18 Apr 2002 12:20:42 -0400 (EDT) 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 QQmldh00774; Thu, 18 Apr 2002 16:19:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldh28950 for mpls-outgoing; Thu, 18 Apr 2002 16:19: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 QQmldh28945 for ; Thu, 18 Apr 2002 16:19:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmldh17237 for ; Thu, 18 Apr 2002 16:18:51 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 QQmldh16243 for ; Thu, 18 Apr 2002 16:18: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 MAA06392; Thu, 18 Apr 2002 12:18:50 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA05674; Thu, 18 Apr 2002 12:18:49 -0400 (EDT) Message-Id: <200204181618.MAA05674@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: David Charlap cc: mpls@UU.NET Subject: Re: PHP In-reply-to: Your message of Thu, 18 Apr 2002 11:33:24 -0400. <3CBEE744.7690958C@marconi.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 18 Apr 2002 12:18:49 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk David> I would argue that it should not shunt incompatible traffic into that David> LSP. Don't allow a non-IP LSP to tunnel through an IP-LSP. What would be the point of this? I admit I've never quite understood the role of the L3PID in RSVP-TE signaling. In practice, the only situations in which PHP causes a packet's bottom label to be popped off are situations in which the payload is an "ordinary" IP packet. If the payload is a layer 2 frame encapsulated via draft-martini, or a VPN packet encapsulated according to one of the L3VPN schemes, then PHP will never result in the bottom label being popped off. So in practice, PHP always results in either an IP packet or an MPLS packet, and the appropriate ethertype (IP or MPLS) can then be applied before the packet is transmitted to its next hop. From owner-mpls@UU.NET Thu Apr 18 13:24:14 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15681 for ; Thu, 18 Apr 2002 13:24:13 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmldl28112; Thu, 18 Apr 2002 17:23:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldl24792 for mpls-outgoing; Thu, 18 Apr 2002 17:22:55 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmldl24787 for ; Thu, 18 Apr 2002 17:22:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmldl10910 for ; Thu, 18 Apr 2002 17:22:46 GMT From: neil.2.harrison@bt.com Received: from cbibipnt02.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmldl07001 for ; Thu, 18 Apr 2002 17:22:45 GMT Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Thu, 18 Apr 2002 18:22:56 +0100 Message-ID: To: David.Charlap@marconi.com, mpls@UU.NET Subject: RE: PHP Date: Thu, 18 Apr 2002 18:22:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk David, please see below. regards, Neil > -----Original Message----- > From: David Charlap [mailto:David.Charlap@marconi.com] > Sent: 17 April 2002 22:04 > To: mpls@UU.NET > Subject: Re: PHP > > > Sandeep B wrote: > > > > You mention using 0x0800 as L3PID no matter what intermediate L2 > > protocol is carrying this traffic. Lets say we have a LDP session > > running over another RSVP Session and this session is a VPN for a > > frame relay circuit carrying IP traffic. Wouldn't we use a L3PID of > > LDP-MPLS (0x8847) instead of IP for the RSVP session. > > No. When you tunnel one LSP through another, you should push a new > label onto the label stack. The labeled packet's payload is still IP. NH=> This does not make any sense to me wrt XoverMPLS....where X can be FR, ATM, ethernet or even SDH. IMO a given LSP of level N should only care about the immediate payload it carries. From owner-mpls@UU.NET Thu Apr 18 13:27:08 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15742 for ; Thu, 18 Apr 2002 13:27:08 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmldl00669; Thu, 18 Apr 2002 17:24:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldl24908 for mpls-outgoing; Thu, 18 Apr 2002 17:24:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmldl24886 for ; Thu, 18 Apr 2002 17:24: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 QQmldl15898 for ; Thu, 18 Apr 2002 17:24:20 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 QQmldl29788 for ; Thu, 18 Apr 2002 17:24:20 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 NAA14879; Thu, 18 Apr 2002 13:24:17 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12602; Thu, 18 Apr 2002 13:24:17 -0400 (EDT) Message-ID: <3CBF015F.CE9A357@marconi.com> Date: Thu, 18 Apr 2002 13:24:47 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: erosen@cisco.com CC: mpls@UU.NET Subject: Re: PHP References: <200204181618.MAA05674@erosen-u10.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Rosen wrote: > > I admit I've never quite understood the role of the L3PID in > RSVP-TE signaling. It's so the egress router will know what to do with the packet after popping the last label. If you don't provide this (like LDP doesn't) then you must either assume everything is IP, or you must use some out-of-band mechanism for distributing this information. Either way, it pretty much defeats the multiprotocol capabilities of MPLS. > In practice, the only situations in which PHP causes a packet's > bottom label to be popped off are situations in which the payload > is an "ordinary" IP packet. Why are you forcing it to be IP? Why can't people using other L3 protocols also send traffic through LSPs? > If the payload is a layer 2 frame encapsulated via draft-martini, > or a VPN packet encapsulated according to one of the L3VPN schemes, > then PHP will never result in the bottom label being popped off. There are more non-IP protocols than VPNs. And why is it so superior to carry the L3 protocol ID in every single packet, instead of signaling it once when the LSP is established? -- David From owner-mpls@UU.NET Thu Apr 18 13:28:32 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15802 for ; Thu, 18 Apr 2002 13:28:31 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmldl04856; Thu, 18 Apr 2002 17:27:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldl25301 for mpls-outgoing; Thu, 18 Apr 2002 17:27:32 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmldl25289 for ; Thu, 18 Apr 2002 17:27:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmldl01322 for ; Thu, 18 Apr 2002 17:27:16 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQmldl04179 for ; Thu, 18 Apr 2002 17:27:15 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 NAA15321 for ; Thu, 18 Apr 2002 13:27:07 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA13399 for ; Thu, 18 Apr 2002 13:27:07 -0400 (EDT) Message-ID: <3CBF0209.F39F2D6C@marconi.com> Date: Thu, 18 Apr 2002 13:27:37 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PHP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit neil.2.harrison@bt.com wrote: > David Charlap wrote: >> Sandeep B wrote: >>> >>> You mention using 0x0800 as L3PID no matter what intermediate L2 >>> protocol is carrying this traffic. Lets say we have a LDP session >>> running over another RSVP Session and this session is a VPN for a >>> frame relay circuit carrying IP traffic. Wouldn't we use a L3PID >>> of LDP-MPLS (0x8847) instead of IP for the RSVP session. >> >> No. When you tunnel one LSP through another, you should push a >> new label onto the label stack. The labeled packet's payload is >> still IP. > > This does not make any sense to me wrt XoverMPLS....where X can be > FR, ATM, ethernet or even SDH. None of these are MPLS frames, so 0x8847 is still wrong. -- David From owner-mpls@UU.NET Thu Apr 18 13:42:13 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16614 for ; Thu, 18 Apr 2002 13:42:13 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmldm06037; Thu, 18 Apr 2002 17:41:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldm26329 for mpls-outgoing; Thu, 18 Apr 2002 17:40:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmldm26324 for ; Thu, 18 Apr 2002 17:40:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmldm25595 for ; Thu, 18 Apr 2002 17:39:20 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f106.pav2.hotmail.com [64.4.37.106]) id QQmldm02650 for ; Thu, 18 Apr 2002 17:39:19 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Apr 2002 10:39:18 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 18 Apr 2002 17:39:18 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Definition of LIB and LFIB Date: Thu, 18 Apr 2002 17:39:18 +0000 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_43b7_1580_231e" Message-ID: X-OriginalArrivalTime: 18 Apr 2002 17:39:18.0905 (UTC) FILETIME=[F7A6FE90:01C1E6FF] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_43b7_1580_231e Content-Type: text/plain; format=flowed Hi, In my opinion LFIB and LIB mean the same. LFIB/LIB contains information as what Johannes listed. However I think I have encountered a reference which did not treat them as the same. In my opinion the reference refers LIB as a pool of labels that an LSR may use for label binding. The pool may contain several sets of valid label range. I might be wrong here, but I think they are used inconsistently. Here are some references that you might want to see for yourself the usage of the terms LFIB and LIB: 1. http://students.cs.byu.edu/~cs460ta/cs560/slides/mpls-osbourne.ppt 2. http://flower.ce.cnu.ac.kr/~fog1/mns/mns1.0/MNS_v1.0_arch.pdf Another term that is commonly used is FIB. IMHO, FIB is the normal L3 routing table. Other documents use ILM(Incoming Label Mapping), FTN(FEC-to-NHLFE), and NHLFE(Next Hop Label Forwarding Entry) to mean somewhat finer detail of LFIB/LIB. Ignore this message if am incorrect at all. -Tze Ven >Roger Williams wrote: >Johannes, it is my understanding that the LFIB contains what is >actually being used to forward packets via label swapping, whereas the >LIB contains all possible routes (generated by the underlying routing >Link State Protocol) with labels already assigned (assuming frame mode >MPLS). The LFIB is the outcome of an OS decision as to which route >really is the Shortest Path. LFIB has only labels and interface >information, with no IP information. The LIB has IP information, label >and interface information, but no indication of which is the shortest >path to the given destination. >Any route in the LFIB will also be in the LIB, but not the other way >around. The LFIB is a subset of the LIB, based on SPF algorithm >calculation. >Johannes wrote: >I have found out that Label Forwarding Information Base (LFIB) is a >subset of Label Information Base (LIB). I have not been able to find >out exactly what information these two information bases contain. > >So far I found out LFIB contains: > - Incoming Label > - Outgoing Label > - Next Hop > - Outgoing Interface > >1. Is this correct and are there any other fields? > >I have not found any content specification for LIB. RFC 3036, LDP >Specification, explain that this information base contains, among >other things, address prefix. > >2. What is address prefix? > >I assume this address is from the Forwarding Equivalence Class (FEC). >3. Is this prefix also in the LFIB? >4. What other parameters are in the LIB in addition to Incoming >label, outgoing label and Interface? > >These should be explained in detail in RFC's but I've not found any >information at IETF on this subject at all. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com ------=_NextPart_000_43b7_1580_231e Content-Type: message/rfc822 Received: from [209.239.41.31] by hotmail.com (3.2) with ESMTP id MHotMailBE87FDDF001740043255D1EF291F09AF0; Thu, 18 Apr 2002 04:50:21 -0700 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id g3IBno008975; Thu, 18 Apr 2002 07:49:50 -0400 Resent-Date: Thu, 18 Apr 2002 07:49:50 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Message-Id: <5.0.2.1.2.20020417101133.00b08a88@207.69.200.110> X-Sender: rogerw@together.net@207.69.200.110 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 17 Apr 2002 10:18:34 -0400 To: mpls-ops@mplsrc.com From: Roger Clark Williams Subject: Re: [MPLS-OPS]: Definition of LIB and LFIB In-Reply-To: <63AD1AC95D52D311AEB700500483F0009E86CE@malle.siving.hia.no > Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Resent-Message-ID: <"nbHrMB.A.Ag.Zoqv8"@host.secure4-hosting.net> Resent-From: mpls-ops@mplsrc.com X-Mailing-List: archive/latest/3812 X-Loop: mpls-ops@mplsrc.com Precedence: list Resent-Sender: mpls-ops-request@mplsrc.com Johannes, it is my understanding that the LFIB contains what is actually being used to forward packets via label swapping, whereas the LIB contains all possible routes (generated by the underlying routing Link State Protocol) with labels already assigned (assuming frame mode MPLS). The LFIB is the outcome of an OS decision as to which route really is the Shortest Path. LFIB has only labels and interface information, with no IP information. The LIB has IP information, label and interface information, but no indication of which is the shortest path to the given destination.

Any route in the LFIB will also be in the LIB, but not the other way around. The LFIB is a subset of the LIB, based on SPF algorithm calculation.

Roger Williams


At 03:02 PM 4/17/2002, you wrote:
Hi,
 
I have found out that Label Forwarding Information Base (LFIB) is a subset of Label Information Base (LIB). I have not been able to find out exactly what information these two information bases contain.
 
So far I found out LFIB contains:
    -          Incoming Label
    -          Outgoing Label
    -          Next Hop
    -          Outgoing Interface
 
1. Is this correct and are there any other fields?
 
I have not found any content specification for LIB.  RFC 3036, LDP Specification, explain that this information base contains, among other things, address prefix.
2. What is address prefix?
 
I assume this address is from the Forwarding Equivalence Class (FEC).
3. Is this prefix also in the LFIB?
4. What other parameters are in the LIB in addition to Incoming label, outgoing label and Interface?
 
These should be explained in detail in RFC's but I've not found any information at IETF on this subject at all.
 
 
 
Any answers will be appreciated. The questions have been enumerated.
 
Best regards,
 
Johannes Vea
Hallstein Lohne
Agder University College, Norway
------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------=_NextPart_000_43b7_1580_231e-- From owner-mpls@UU.NET Thu Apr 18 13:51:49 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16977 for ; Thu, 18 Apr 2002 13:51:49 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmldn04792; Thu, 18 Apr 2002 17:49:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldn27335 for mpls-outgoing; Thu, 18 Apr 2002 17:48: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 QQmldn27330 for ; Thu, 18 Apr 2002 17:48:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmldn01567 for ; Thu, 18 Apr 2002 17:48:11 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmldn03204 for ; Thu, 18 Apr 2002 17:48: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 NAA12412; Thu, 18 Apr 2002 13:48:10 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA15747; Thu, 18 Apr 2002 13:48:10 -0400 (EDT) Message-Id: <200204181748.NAA15747@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: David Charlap cc: mpls@UU.NET Subject: Re: PHP In-reply-to: Your message of Thu, 18 Apr 2002 13:24:47 -0400. <3CBF015F.CE9A357@marconi.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 18 Apr 2002 13:48:10 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Eric> I admit I've never quite understood the role of the L3PID in Eric> RSVP-TE signaling. David> It's so the egress router will know what to do with the packet after David> popping the last label. ... assuming that the bottom label represents the RSVP-TE tunnel, rather than a route of some particular L3 protocol. If you run, say, directed LDP through the RSVP-TE tunnel to assign labels to L3 routes (of various L3 protocols), then you don't need the L3PID, since the bottom label will identify the L3 protocol. David> If you don't provide this (like LDP doesn't) then you must either David> assume everything is IP, or you must use some out-of-band mechanism David> for distributing this information. Either way, it pretty much David> defeats the multiprotocol capabilities of MPLS. It's not that you have to assume that everything is IP, it's just IP gets special treatment; it's the only sort of unlabeled packet that can be put into an RSVP-TE tunnel. Other L3s just need to get labeled first. (Another alternative, if you wanted to put multiple L3s into a single RSVP-TE tunnel, would be to require that L3 packets in the tunnel first get encapsulated in something that provides an L3PID.) David> And why is it so superior to carry the L3 protocol ID in every single David> packet, instead of signaling it once when the LSP is established? Carrying the L3 protocol id in ever packet allows packets of multiple L3 protocols to use a single RSVP-TE tunnel. Signaling the L3PID "once" for each protocol requires multiple RSVP-TE tunnels. As these tunnels create state in the core routers, it seems like a very bad idea to set up an extra RSVP-TE tunnel simply to help with the L3 identification. From owner-mpls@UU.NET Thu Apr 18 15:29:33 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20234 for ; Thu, 18 Apr 2002 15:29:33 -0400 (EDT) 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 QQmldt10369; Thu, 18 Apr 2002 19:27:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldt17024 for mpls-outgoing; Thu, 18 Apr 2002 19:27: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 QQmldt17019 for ; Thu, 18 Apr 2002 19:26: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 QQmldt02043 for ; Thu, 18 Apr 2002 19:25:46 GMT Received: from relais-inet-02.francetelecom.fr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: relais-inet-02.francetelecom.fr [195.6.68.191]) id QQmldt08163 for ; Thu, 18 Apr 2002 19:25:46 GMT Received: from [193.248.188.42] by relais-filtrant-02.francetelecom.fr with ESMTP for mpls@UU.NET; Thu, 18 Apr 2002 21:25:45 +0200 Received: from fedft02a.francetelecom.fr by relais-filtrant-02.francetelecom.fr with ESMTP for mpls@UU.NET; Thu, 18 Apr 2002 21:25:44 +0200 Received: from [193.249.133.11] by fedft02a.francetelecom.fr with ESMTP for mpls@UU.NET; Thu, 18 Apr 2002 21:25:43 +0200 Received: from francetelecom.com ([10.239.24.38]) by smtp2.smtpft.francetelecom.fr (Netscape Messaging Server 4.15) with ESMTP id GUS3AU01.I5L; Thu, 18 Apr 2002 21:25:42 +0200 Message-Id: <3CBF1DEB.A0DB4A32@francetelecom.com> Date: Thu, 18 Apr 2002 15:26:35 -0400 From: "LIAN Franklin FTLD/IAP" Organization: France Telecom Long Distance X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh-CN,zh,zh-TW MIME-Version: 1.0 To: wu min CC: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: Prefix Mismatch References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit Hello, Wu Min I am sure someone can correct me if I am wrong. Please see my comments interleaved below. wu min wrote: > > Hi, > > I have questions regarding longest prefix address. > > The following is from section 4.1.3. of RFC 3031: > ". . > Note that a packet's LSP can extend only until it encounters a router whose > forwarding tables have a longer best match address prefix for the packet's > destination address. At that point, the LSP must end and the best match > algorithm must be performed again. > > Suppose, for example, that packet P, with destination address 10.2.153.178 > needs to go from R1 to R2 to R3. Suppose also that R2 advertises address > prefix 10.2/16 to R1, but R3 advertises 10.2.153/23, 10.2.154/23, and > 10.2/16 to R2. That is, R2 is advertising an "aggregated route" to R1. In > this situation, packet P can be label Switched until it reaches R2, but > since R2 has performed route aggregation, it must execute the best match > algorithm to find P's FEC." > > Questions: > ---------- > 1. Does it mean R2 has to terminate LSP for FEC with 10.2/16 address prefix > by means of stripping the top label (the only label) and look into IP header > to determine its finer FEC and then label the packet again with the > appropriate outgoing label. Is this true? My understanding of the RFC is the LSP for 10.2/16 stops at R2. The the packet may or may not be label switched after R2. > > 2. Suppose the LSP is being used as a tunnel that ends after R2 and if the > answer for my question (1) is true, then stripping the top label will never > reveal the IP header yet since there will still be 1 or more labels. Is this > situation valid? If so, can R2 still manage to terminate the LSP and perform > best match algorithm? If yes, then how? I don't think you can build an LSP beyond R2 in this case, in another word, I don't know how you can have a tunnel that ends after R2. > > 3. Since R3 also advertised a coarser granularity prefix address, 10.2/16, > to R2; can R2 safely maps its own 10.2/16 prefix with R3's equivalent prefix > regardless of the existent of the finer granularity prefixes? What are the > consequences if it does not follow the rules. I think the reason for not using the aggregate route is trying to avoid routing loop. Building the LSP by ignoring the longest prefix route is conflict with the original intention. > > _________________________________________________________________ > Join the world’s largest e-mail service with MSN Hotmail. > http://www.hotmail.com From owner-mpls@UU.NET Thu Apr 18 15:37:47 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20513 for ; Thu, 18 Apr 2002 15:37:47 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmldu11717; Thu, 18 Apr 2002 19:36:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldu17721 for mpls-outgoing; Thu, 18 Apr 2002 19:36: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 QQmldu17716 for ; Thu, 18 Apr 2002 19:36: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 QQmldu09107 for ; Thu, 18 Apr 2002 19:35:48 GMT From: neil.2.harrison@bt.com Received: from cbibipnt02.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmldu22737 for ; Thu, 18 Apr 2002 19:35:48 GMT Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Thu, 18 Apr 2002 20:35:59 +0100 Message-ID: To: David.Charlap@marconi.com, mpls@UU.NET Subject: RE: PHP Date: Thu, 18 Apr 2002 20:35:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk David Charlap wrote18 April 2002 16:33 > > Markus Jork wrote: > > > > It looks to me as if the L3PID signaling seemed like a good idea at > > the time but turned out to be not particularly useful. The problem > > is that it is often unknown what type of traffic is carried on an > > LSP. For example an RSVP LSP can be used to carry IP traffic and > > at the same time also labeled traffic from a targeted LDP session > > that runs over the RSVP LSP. > > The L3PID of the inner LSP is known, because it is signaled as IP. > > The ingress router for the inner LSP also knows the L3PID of the outer > LSP, since it must participate in the signaling for the outer LSP. > > I would argue that it should not shunt incompatible traffic into that > LSP. Don't allow a non-IP LSP to tunnel through an IP-LSP. > > If the inner LSP is meant to carry traffic of many different > types, then > it should be signaled as such. With an L3PID meaning > "unknown". Which > would mean, of course, that the egress of such an LSP would > not be able > to handle a packet that only has one label - since it won't know the > actual L3PID after popping that last label. But this would be OK, if > there's another label on the stack - either indicating an outer LSP to > use for forwarding, or indicating the L2/L3 PID. > > Of course, the whole argument falls apart when you realize > that the two > LSPs (inner and outer) don't both have to be RSVP. I don't > think L3PID > is signaled with LDP or CR-LDP. NH=> Can I just check something here David.....in the martini-trans ID I believe only LDP is allowed for signalling XoverMPLS LSPs. If so, then how can we signal the payload 'X' of the LSP for such XoverMPLS cases? I always assumed that the 'multiprotocol' aspects would be taken care of by label semantics in lieu of no PID field in the MPLS header. So am I right one cannot signal this and only configure it? And why is RSVP-TE say prohibited for the setting up the inner LSP? Any enlightenment/corrections would be much appreciated. regards, Neil From owner-mpls@UU.NET Thu Apr 18 15:56:59 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21181 for ; Thu, 18 Apr 2002 15:56:58 -0400 (EDT) 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 QQmldv21509; Thu, 18 Apr 2002 19:56:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldv19169 for mpls-outgoing; Thu, 18 Apr 2002 19:55: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 QQmldv19164 for ; Thu, 18 Apr 2002 19:55: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 QQmldv27305 for ; Thu, 18 Apr 2002 19:55:10 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 QQmldv08307 for ; Thu, 18 Apr 2002 19:55:09 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 PAA07060 for ; Thu, 18 Apr 2002 15:55:05 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24065 for ; Thu, 18 Apr 2002 15:54:51 -0400 (EDT) Message-ID: <3CBF24A9.6853144A@marconi.com> Date: Thu, 18 Apr 2002 15:55:21 -0400 From: David Charlap X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: PHP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit neil.2.harrison@bt.com wrote: > > Can I just check something here David.....in the martini-trans ID > I believe only LDP is allowed for signalling XoverMPLS LSPs. If > so, then how can we signal the payload 'X' of the LSP for such > XoverMPLS cases? I always assumed that the 'multiprotocol' aspects > would be taken care of by label semantics in lieu of no PID field > in the MPLS header. That would be correct. > So am I right one cannot signal this and only configure it? I don't know of any way to signal an association between these labels and the protocols they represent. If they're not pre-defined by standards, they will have to be configured. > And why is RSVP-TE say prohibited for the setting up the inner > LSP? It's not. But the inner LSP isn't going to be able to know a-priority that it will only be used for tunneling other LSPs through it. It will have to be able to correctly de-encapsulate a packat that arrives at the egress node with only one label on it. In RSVP-TE, the L3PID field in the LABEL_REQUEST tells it how to do this. If you signal the LSP with something that the egress switch can't de-encapsulate, the LSP will probably be rejected. If you know that the egress switch will never receive a one-label packet (which is beyond the scope of signaling protocols), then you can simply set up the inner LSP as an IP tunnel. Now, it will behave the way LDP does - requiring that a protocol-identifying label be at the bottom of the label stack. In LDP, it is assumed that this packet must be IP, so the problem never comes up. Anything that's not IP must have a second protocol- identifying label on the stack. -- David From owner-mpls@UU.NET Thu Apr 18 16:02:27 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21334 for ; Thu, 18 Apr 2002 16:02:27 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmldw08457; Thu, 18 Apr 2002 20:01:36 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldw24357 for mpls-outgoing; Thu, 18 Apr 2002 20:01:16 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 QQmldw24342 for ; Thu, 18 Apr 2002 20:01:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmldw21278 for ; Thu, 18 Apr 2002 20:00:49 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 QQmldw07300 for ; Thu, 18 Apr 2002 20:00: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 QAA22317; Thu, 18 Apr 2002 16:00:48 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA29644; Thu, 18 Apr 2002 16:00:48 -0400 (EDT) Message-Id: <200204182000.QAA29644@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: neil.2.harrison@bt.com cc: David.Charlap@marconi.com, mpls@UU.NET Subject: Re: PHP In-reply-to: Your message of Thu, 18 Apr 2002 20:35:44 +0100. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 18 Apr 2002 16:00:48 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Neil> in the martini-trans ID I believe only LDP is allowed for signalling Neil> XoverMPLS LSPs. If so, then how can we signal the payload 'X' of the Neil> LSP for such XoverMPLS cases? Martini signaling (using LDP) does signal the X, it's the VC type (i.e. it's part of the FEC). But the fact that a particular Martini LSP is carrying protocol X is only known at the two endpoints of that LSP. An RSVP-TE tunnel whose head is at some arbitrary place in the network will not know this. Neil> I always assumed that the 'multiprotocol' aspects would be taken care Neil> of by label semantics in lieu of no PID field in the MPLS header. Yes, when a packet is within a tunnel, you may not be able to determine the payload type by examining the header. If it is a Martini packet, you need to get to the node that assigned the bottom label before you can determine the payload type. From owner-mpls@UU.NET Thu Apr 18 17:00:15 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22769 for ; Thu, 18 Apr 2002 17:00:14 -0400 (EDT) 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 QQmldz21938; Thu, 18 Apr 2002 20:58:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQmldz15495 for mpls-outgoing; Thu, 18 Apr 2002 20:57:42 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmldz15490 for ; Thu, 18 Apr 2002 20:57:40 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 QQmldz12785 for ; Thu, 18 Apr 2002 20:57: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 QQmldz25711 for ; Thu, 18 Apr 2002 20:57:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA26300 for ; Thu, 18 Apr 2002 16:57:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA05732 for mpls@uu.net; Thu, 18 Apr 2002 16:57:03 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmldz15236 for ; Thu, 18 Apr 2002 20:55:57 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 QQmldz20632 for ; Thu, 18 Apr 2002 20:54:44 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQmldz17064 for ; Thu, 18 Apr 2002 20:54:43 GMT Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3IKshOQ016716 for ; Thu, 18 Apr 2002 13:54:43 -0700 (PDT) Received: from cisco.com (dhcp-171-71-60-66.cisco.com [171.71.60.66]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADP13457; Thu, 18 Apr 2002 13:52:04 -0700 (PDT) Message-ID: <3CBF3292.B84048B0@cisco.com> Date: Thu, 18 Apr 2002 13:54:42 -0700 From: hginjpal X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Unsubscribe References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit UNSUBSCRI BE From owner-mpls@UU.NET Thu Apr 18 18:09:01 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24309 for ; Thu, 18 Apr 2002 18:09:01 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlee15795; Thu, 18 Apr 2002 22:08:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlee01435 for mpls-outgoing; Thu, 18 Apr 2002 22:07: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 QQmlee01428 for ; Thu, 18 Apr 2002 22:07:46 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 QQmlee26699 for ; Thu, 18 Apr 2002 22:05:33 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 QQmlee01748 for ; Thu, 18 Apr 2002 22:05:33 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 g3IM5WT61285; Thu, 18 Apr 2002 15:05:32 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g3IM5W187167; Thu, 18 Apr 2002 15:05:32 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 18 Apr 2002 15:05:32 -0700 (PDT) From: Kireeti Kompella To: David Charlap cc: Subject: Re: PHP In-Reply-To: <3CBEE5C6.E5D606AD@marconi.com> Message-ID: <20020418150439.X87151-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 18 Apr 2002, David Charlap wrote: > Ideally, I'd think that a new object, used to indicate the presence of a > non-L3 payload (with various C-Types specifying different layers, and > the object payload indicating the protocol ID at that layer) should be > introduced. Perhaps something like this: It's been done -- check out the G-PID in generalized signaling (only for L1 and L2). Kireeti. From owner-mpls@UU.NET Thu Apr 18 18:10:28 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24374 for ; Thu, 18 Apr 2002 18:10:28 -0400 (EDT) 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 QQmlee05931; Thu, 18 Apr 2002 22:09:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlee01975 for mpls-outgoing; Thu, 18 Apr 2002 22:08: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 QQmlee01956 for ; Thu, 18 Apr 2002 22:08:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlee03785 for ; Thu, 18 Apr 2002 22:08:34 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 QQmlee05892 for ; Thu, 18 Apr 2002 22:08:34 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 g3IM8XT61483; Thu, 18 Apr 2002 15:08:33 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g3IM8Ss87186; Thu, 18 Apr 2002 15:08:28 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 18 Apr 2002 15:08:28 -0700 (PDT) From: Kireeti Kompella To: Markus Jork cc: Vach Kompella , David Charlap , Subject: Re: PHP In-Reply-To: <200204181437.g3IEbwW16902@mailhost.avici.com> Message-ID: <20020418150539.L87151-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 18 Apr 2002, Markus Jork wrote: > It looks to me as if the L3PID signaling seemed like a good idea at the > time but turned out to be not particularly useful. It's not that bad, but it is less than optimal. One could use IP LSPs for IP, IP VPNs, etc., where the payload is IP; and establish a parallel set of LSPs for non-IP traffic. > Maybe it should be redefined to only > apply to packets with a label stack of 1 while all other packets on > the LSP with label stack > 1 are simply of unknown protocol type. That was my suggestion when this topic came up 2+ years ago, got little traction. I still like it, though :-) Kireeti. From owner-mpls@UU.NET Thu Apr 18 18:17:57 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24503 for ; Thu, 18 Apr 2002 18:17:57 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlef28706; Thu, 18 Apr 2002 22:17:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlef03796 for mpls-outgoing; Thu, 18 Apr 2002 22:15:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmlef03791 for ; Thu, 18 Apr 2002 22:15:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlef28672 for ; Thu, 18 Apr 2002 22:15:38 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 QQmlef16127 for ; Thu, 18 Apr 2002 22:15:37 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 g3IMFbT61990; Thu, 18 Apr 2002 15:15:37 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g3IMFbC87242; Thu, 18 Apr 2002 15:15:37 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Thu, 18 Apr 2002 15:15:37 -0700 (PDT) From: Kireeti Kompella To: Eric Rosen cc: Subject: Re: PHP In-Reply-To: <200204181618.MAA05674@erosen-u10.cisco.com> Message-ID: <20020418151416.V87151-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 18 Apr 2002, Eric Rosen wrote: > So in practice, PHP always results in either an IP packet or an MPLS packet, > and the appropriate ethertype (IP or MPLS) can then be applied before the > packet is transmitted to its next hop. How does one distinguish IPv4 from IPv6? One could use the 'check first nibble' hack :-( It would be neater to use the L3PID. Kireeti. From owner-mpls@UU.NET Thu Apr 18 18:27:42 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24637 for ; Thu, 18 Apr 2002 18:27:42 -0400 (EDT) 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 QQmlef01535; Thu, 18 Apr 2002 22:27:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlef04685 for mpls-outgoing; Thu, 18 Apr 2002 22:26:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmlef04676 for ; Thu, 18 Apr 2002 22:26:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlef15220 for ; Thu, 18 Apr 2002 22:25:50 GMT Received: from mail.timetra.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.timetra.com [63.104.212.2]) id QQmlef29628 for ; Thu, 18 Apr 2002 22:25:49 GMT Received: from vkompella ([192.168.1.253]) by mail.timetra.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 18 Apr 2002 15:24:02 -0700 From: "Vach Kompella" To: "Kireeti Kompella" , "Markus Jork" Cc: "David Charlap" , Subject: RE: PHP Date: Thu, 18 Apr 2002 15:26:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20020418150539.L87151-100000@kummer.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 18 Apr 2002 22:24:02.0964 (UTC) FILETIME=[BE8B8540:01C1E727] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I like that idea. Since, from a need-to-know point of view, the outer LSP doesn't care, why make it visible? -Vach > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Thursday, April 18, 2002 3:08 PM > To: Markus Jork > Cc: Vach Kompella; David Charlap; mpls@UU.NET > Subject: Re: PHP > > > > On Thu, 18 Apr 2002, Markus Jork wrote: > > > It looks to me as if the L3PID signaling seemed like a good idea at the > > time but turned out to be not particularly useful. > > It's not that bad, but it is less than optimal. One could use IP > LSPs for IP, IP VPNs, etc., where the payload is IP; and establish a > parallel set of LSPs for non-IP traffic. > > > Maybe it should be redefined to only > > apply to packets with a label stack of 1 while all other packets on > > the LSP with label stack > 1 are simply of unknown protocol type. > > That was my suggestion when this topic came up 2+ years ago, got > little traction. I still like it, though :-) > > Kireeti. > From owner-mpls@UU.NET Thu Apr 18 22:11:03 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28797 for ; Thu, 18 Apr 2002 22:11:02 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmleu08184; Fri, 19 Apr 2002 02:10:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmleu14227 for mpls-outgoing; Fri, 19 Apr 2002 02:09: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 QQmleu14220 for ; Fri, 19 Apr 2002 02:09:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmleu11037 for ; Fri, 19 Apr 2002 02:09:09 GMT Received: from scutsv39.scut.edu.cn by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.38.193.39]) id QQmleu08661 for ; Fri, 19 Apr 2002 02:09:07 GMT Received: from letterbox.scut.edu.cn (mail.scut.edu.cn [202.38.193.69]) by scutsv39.scut.edu.cn (8.9.3/8.9.3) with ESMTP id KAA04848 for ; Fri, 19 Apr 2002 10:05:44 +0800 (CST) Received: from hchang ([202.38.197.20]) by letterbox.scut.edu.cn (8.9.3+Sun/8.9.3) with SMTP id JAA24930 for ; Fri, 19 Apr 2002 09:56:40 +0800 (CST) Message-Id: <200204190156.JAA24930@letterbox.scut.edu.cn> Date: Fri, 19 Apr 2002 10:11:15 +0800 From: hchang To: MPLS X-mailer: FoxMail 3.0 beta 2 [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, sorry to bother you:) i am a student pursueing my doctor degree in south China University of Technology. i want to do some research about Traffic Engineering such as QOS routing , Packet Scheduling Algorithms and Network planning etc. for my lab have not any project in this topic,so i am very puzzled and i can not make much progress for my study. can somebody give me some advice about the study? thank you very much!!!! From owner-mpls@UU.NET Fri Apr 19 03:43:07 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12669 for ; Fri, 19 Apr 2002 03:43:06 -0400 (EDT) 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 QQmlfq17951; Fri, 19 Apr 2002 07:41:57 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlfq25370 for mpls-outgoing; Fri, 19 Apr 2002 07:41:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmlfq25365 for ; Fri, 19 Apr 2002 07:41: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 QQmlfq05957 for ; Fri, 19 Apr 2002 07:40:16 GMT Received: from scutsv39.scut.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.38.193.39]) id QQmlfq02638 for ; Fri, 19 Apr 2002 07:40:15 GMT Received: from letterbox.scut.edu.cn (mail.scut.edu.cn [202.38.193.69]) by scutsv39.scut.edu.cn (8.9.3/8.9.3) with ESMTP id PAA16993 for ; Fri, 19 Apr 2002 15:36:53 +0800 (CST) Received: from hchang ([202.38.197.20]) by letterbox.scut.edu.cn (8.9.3+Sun/8.9.3) with SMTP id PAA12419 for ; Fri, 19 Apr 2002 15:27:49 +0800 (CST) Message-Id: <200204190727.PAA12419@letterbox.scut.edu.cn> Date: Fri, 19 Apr 2002 15:42:24 +0800 From: hchang To: MPLS X-mailer: FoxMail 3.0 beta 2 [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, can someone tell me that where can i discuss the questions and comments about the QOS routing and Packet Scheduling Algorithms? I have many questions about these aspects. thank you very much!!!! From owner-mpls@UU.NET Fri Apr 19 09:14:49 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18901 for ; Fri, 19 Apr 2002 09:14:48 -0400 (EDT) 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 QQmlgm01531; Fri, 19 Apr 2002 13:13:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlgm26641 for mpls-outgoing; Fri, 19 Apr 2002 13:13: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 QQmlgm26636 for ; Fri, 19 Apr 2002 13:13: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 QQmlgm09698 for ; Fri, 19 Apr 2002 13:13:10 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f59.pav2.hotmail.com [64.4.37.59]) id QQmlgm00757 for ; Fri, 19 Apr 2002 13:13:10 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Apr 2002 06:13:09 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 19 Apr 2002 13:13:09 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: rogerw@nordlink.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Definition of LIB and LFIB Date: Fri, 19 Apr 2002 13:13:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 13:13:09.0725 (UTC) FILETIME=[F3B140D0:01C1E7A3] Sender: owner-mpls@UU.NET Precedence: bulk Hi, >Roger Williams wrote: >Tze, you may be correct, but Cisco says otherwise, at least in their >training material. The LFIB is derived from the LIB, it is a subset of >the LIB. Also the LFIB contains no IP information whereas the LIB does >hold IP information. Cisco says the LFIB is generated when the actual >shortest path to a destination is chosen. Hence, in the LFIB there >will be one label pair for a destination (or FEC), whereas the LIB >holds all possible paths to the destination. > >All this is based on the MPLS Tech Essentials, AMVS, MPLS >Implementation, and VPNSC courses as issued by Cisco. Do I have any >*real* proof? Not really, I'm just passing on what they say and what >shows up in the various "show.." commands. Yeah, I must admit that you are right about it. From the way RFC3036 explains about LIB in section 2.7., it seems to agree with what you have just mentioned as it pointed out that when an LSR operates in downstream unsolicited mode, it would keep a collection of label binding info that it has learned in the LIB. When a label is needed, it will first consult the LIB to retrieve one to be used for forwarding (which I presume that it meant LFIB). I believe LIB is only significant when operating in such mode with liberal label retention mode combined. I also agree with Johannes that no clear defination of such terms are widely available. It is also not listed under MPLS Acronym Dictionary in http://mplsrc.com/dictionary.shtml web page. Thanks for this constructive argument. -Tze Ven. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Fri Apr 19 11:24:52 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23522 for ; Fri, 19 Apr 2002 11:24:51 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlgv19236; Fri, 19 Apr 2002 15:24:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlgv19162 for mpls-outgoing; Fri, 19 Apr 2002 15:23: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 QQmlgv19157 for ; Fri, 19 Apr 2002 15:23:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlgv29160 for ; Fri, 19 Apr 2002 15:21:56 GMT Received: from relais-inet-05.francetelecom.fr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: relais-inet-02.francetelecom.fr [195.6.68.191]) id QQmlgv04745 for ; Fri, 19 Apr 2002 15:21:55 GMT Received: from [193.248.188.48] by relais-filtrant-05.francetelecom.fr with ESMTP for mpls@UU.NET; Fri, 19 Apr 2002 17:21:50 +0200 Received: from fedft02a.francetelecom.fr by relais-filtrant-05.francetelecom.fr with ESMTP for mpls@UU.NET; Fri, 19 Apr 2002 17:21:49 +0200 Received: from [193.249.133.11] by fedft02a.francetelecom.fr with ESMTP for mpls@UU.NET; Fri, 19 Apr 2002 17:17:35 +0200 Received: from francetelecom.com ([10.239.24.38]) by smtp2.smtpft.francetelecom.fr (Netscape Messaging Server 4.15) with ESMTP id GUTMH701.PXE; Fri, 19 Apr 2002 17:17:31 +0200 Message-Id: <3CC03543.65DD1BE4@francetelecom.com> Date: Fri, 19 Apr 2002 11:18:27 -0400 From: "LIAN Franklin FTLD/IAP" Organization: France Telecom Long Distance X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh-CN,zh,zh-TW MIME-Version: 1.0 To: wu min CC: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: Prefix Mismatch References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit wu min wrote: > > The last few lines of the RFC3031 snippet from my previous message reads, > "....In this situation, packet P can be label Switched until it reaches R2, > but since R2 has performed route aggregation, it must execute the best match > algorithm to find P's FEC." > > It indicated that the best match algorithm must be executed to find the next > appropriate FEC to be used for further label switching. In my opinion, > surely this does not stop it from label switching further, right? > Sure, if there is another LSP built for the more granular FEC, but you don't know if there is one or not. > > > 2. Suppose the LSP is being used as a tunnel that ends after R2 and if > >the > > > answer for my question (1) is true, then stripping the top label will > >never > > > reveal the IP header yet since there will still be 1 or more labels. Is > >this > > > situation valid? If so, can R2 still manage to terminate the LSP and > >perform > > > best match algorithm? If yes, then how? > > > >I don't think you can build an LSP beyond R2 in this case, in another > >word, I don't know how you can have a tunnel that ends after R2. > > What I meant is, take for example an LSR with address 10.2.153.178 is a > remote peer and the LSP in the example is the hop-by-hop routed tunnel used > for this peering. Obviously here the LSR is after the LSR2. With LDP, you can try to build a tunnel to 10.2.153.178, but if the tunnel LSP is broken in the middle, you won't know. If you run MPLS VPN over the broken tunnel, you blackhole the traffic. I think you just gave one example why it is necessary to have /32 tunnel termination point for MPLS VPN with LDP. > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-mpls@UU.NET Fri Apr 19 11:53:19 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24732 for ; Fri, 19 Apr 2002 11:53:19 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlgt06600; Fri, 19 Apr 2002 14:52:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlgt25706 for mpls-outgoing; Fri, 19 Apr 2002 14:52:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmlgt25668 for ; Fri, 19 Apr 2002 14:51:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlgt26537 for ; Fri, 19 Apr 2002 14:51:36 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f178.pav2.hotmail.com [64.4.37.178]) id QQmlgt22025 for ; Fri, 19 Apr 2002 14:51:35 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Apr 2002 07:51:35 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 19 Apr 2002 14:51:34 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: franklin.lian@francetelecom.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: Prefix Mismatch Date: Fri, 19 Apr 2002 14:51:34 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 14:51:35.0236 (UTC) FILETIME=[B3A6B840:01C1E7B1] Sender: owner-mpls@UU.NET Precedence: bulk Hello again, > > Questions: > > ---------- > > 1. Does it mean R2 has to terminate LSP for FEC with 10.2/16 address >prefix > > by means of stripping the top label (the only label) and look into IP >header > > to determine its finer FEC and then label the packet again with the > > appropriate outgoing label. Is this true? > >My understanding of the RFC is the LSP for 10.2/16 stops at R2. The >the packet may or may not be label switched after R2. The last few lines of the RFC3031 snippet from my previous message reads, "....In this situation, packet P can be label Switched until it reaches R2, but since R2 has performed route aggregation, it must execute the best match algorithm to find P's FEC." It indicated that the best match algorithm must be executed to find the next appropriate FEC to be used for further label switching. In my opinion, surely this does not stop it from label switching further, right? > > 2. Suppose the LSP is being used as a tunnel that ends after R2 and if >the > > answer for my question (1) is true, then stripping the top label will >never > > reveal the IP header yet since there will still be 1 or more labels. Is >this > > situation valid? If so, can R2 still manage to terminate the LSP and >perform > > best match algorithm? If yes, then how? > >I don't think you can build an LSP beyond R2 in this case, in another >word, I don't know how you can have a tunnel that ends after R2. What I meant is, take for example an LSR with address 10.2.153.178 is a remote peer and the LSP in the example is the hop-by-hop routed tunnel used for this peering. Obviously here the LSR is after the LSR2. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-mpls@UU.NET Fri Apr 19 13:42:26 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08980 for ; Fri, 19 Apr 2002 13:42:26 -0400 (EDT) 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 QQmlhe26521; Fri, 19 Apr 2002 17:41:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlhe11898 for mpls-outgoing; Fri, 19 Apr 2002 17:41: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 QQmlhe11875 for ; Fri, 19 Apr 2002 17:41: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 QQmlhe24276 for ; Fri, 19 Apr 2002 17:41:00 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f110.pav2.hotmail.com [64.4.37.110]) id QQmlhe25922 for ; Fri, 19 Apr 2002 17:40:59 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Apr 2002 10:40:59 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 19 Apr 2002 17:40:59 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: franklin.lian@francetelecom.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: Prefix Mismatch Date: Fri, 19 Apr 2002 17:40:59 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 17:40:59.0203 (UTC) FILETIME=[5DD90130:01C1E7C9] Sender: owner-mpls@UU.NET Precedence: bulk >wu min wrote: > > > > The last few lines of the RFC3031 snippet from my previous message >reads, > > "....In this situation, packet P can be label Switched until it reaches >R2, > > but since R2 has performed route aggregation, it must execute the best >match > > algorithm to find P's FEC." > > > > It indicated that the best match algorithm must be executed to find the >next > > appropriate FEC to be used for further label switching. In my opinion, > > surely this does not stop it from label switching further, right? > > > >Sure, if there is another LSP built for the more granular FEC, but you >don't know if there is one or not. Do you mean 'more granular FEC' = 'finer granularity'? If you mean that, then R2 should have known there exists such FECs since R3 advertised 10.2.153/23 and 10.2.154/23 prefixes to it. I am not sure whether I understand your comment correctly. Please clarify. > > > > 2. Suppose the LSP is being used as a tunnel that ends after R2 and >if > > >the > > > > answer for my question (1) is true, then stripping the top label >will > > >never > > > > reveal the IP header yet since there will still be 1 or more labels. >Is > > >this > > > > situation valid? If so, can R2 still manage to terminate the LSP and > > >perform > > > > best match algorithm? If yes, then how? > > > > > >I don't think you can build an LSP beyond R2 in this case, in another > > >word, I don't know how you can have a tunnel that ends after R2. > > > > What I meant is, take for example an LSR with address 10.2.153.178 is a > > remote peer and the LSP in the example is the hop-by-hop routed tunnel >used > > for this peering. Obviously here the LSR is after the LSR2. > >With LDP, you can try to build a tunnel to 10.2.153.178, but if the >tunnel LSP is broken in the middle, you won't know. If you run MPLS VPN >over the broken tunnel, you blackhole the traffic. If you mean 'broken' = 'transparent FEC remapping', then I would agree with you. If you mean 'broken' = 'total disconnection' then eventually LSRs at both ends of the tunnel would know the tunnel is broken. Anyway my previous question narrowed down just to R2 only regardless of whether LSRs at both ends of the tunnel aware of any 'FEC remapping' at the middle of the tunnel or not. I am just wondering whether R2 would still be able to execute the best match algorithm to find better FEC for the affected packets since in the 'tunnel' case, stripping the top label would not immediately reveal the IP header (R2 will never know whether the LSP is also being used for tunnelling or not), but a second level label that it does not undestand at all. -Tze Ven _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Fri Apr 19 17:25:06 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05379 for ; Fri, 19 Apr 2002 17:25:05 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlht01606; Fri, 19 Apr 2002 21:24:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlht23889 for mpls-outgoing; Fri, 19 Apr 2002 21:23: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 QQmlht23867 for ; Fri, 19 Apr 2002 21:23:29 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmlht26578 for ; Fri, 19 Apr 2002 21:22:53 GMT Received: from smtp1.opnet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.opnet.com [141.156.71.6]) id QQmlht06957 for ; Fri, 19 Apr 2002 21:22:53 GMT Received: from wtn10216.opnet.com (unverified) by smtp1.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Fri, 19 Apr 2002 17:22:42 -0400 Message-Id: <5.0.0.25.2.20020419171446.00a8be70@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 19 Apr 2002 17:22:44 -0400 To: mpls@UU.NET From: Sachin Kalra Subject: Question about ppvpn-rfc2547bis-01 January 2002 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hey Group: I would appreciate if I can get answer to the following. In Draft 2547bis, ppvpn-rfc2547bis-01 January 2002. Pg 12, Section# 4.2, three different kinds of Route Distinguisher encoding schemes are described. Does anybody know which scheme is most widely used? Thanks for your response. Sachin Kalra From owner-mpls@UU.NET Fri Apr 19 18:54:53 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15048 for ; Fri, 19 Apr 2002 18:54:53 -0400 (EDT) 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 QQmlhz06450; Fri, 19 Apr 2002 22:53:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlhz22228 for mpls-outgoing; Fri, 19 Apr 2002 22:53: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 QQmlhz22223 for ; Fri, 19 Apr 2002 22:53:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlhz15415 for ; Fri, 19 Apr 2002 22:52: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 QQmlhz02783 for ; Fri, 19 Apr 2002 22:52:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA09556 for ; Fri, 19 Apr 2002 18:52:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA06376 for mpls@uu.net; Fri, 19 Apr 2002 18:52:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmlhz22087 for ; Fri, 19 Apr 2002 22:50: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 QQmlhz19441 for ; Fri, 19 Apr 2002 22:50:07 GMT Received: from caduceus.fm.intel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmr02.intel.com [192.55.52.25]) id QQmlhz28451 for ; Fri, 19 Apr 2002 22:50:04 GMT Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.39 2002/04/15 17:47:23 root Exp $) with ESMTP id g3JMnKh21459 for ; Fri, 19 Apr 2002 22:49:20 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.16 2002/04/15 17:47:00 root Exp $) with SMTP id g3JMpw016481 for ; Fri, 19 Apr 2002 22:51:58 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002041915502619398 ; Fri, 19 Apr 2002 15:50:26 -0700 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id <28FP29RZ>; Fri, 19 Apr 2002 15:50:03 -0700 Message-ID: From: "Sharma, Prem" To: "'wu min'" , franklin.lian@francetelecom.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: RE: Prefix Mismatch Date: Fri, 19 Apr 2002 15:50:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Wu Min, Some comments inline: >wu min wrote: > > > > The last few lines of the RFC3031 snippet from my previous message >reads, > > "....In this situation, packet P can be label Switched until it reaches >R2, > > but since R2 has performed route aggregation, it must execute the best >match > > algorithm to find P's FEC." > > > > It indicated that the best match algorithm must be executed to find the >next > > appropriate FEC to be used for further label switching. In my opinion, > > surely this does not stop it from label switching further, right? > > > >Sure, if there is another LSP built for the more granular FEC, but you >don't know if there is one or not. >Do you mean 'more granular FEC' = 'finer granularity'? If you mean that, >then R2 should have known there exists such FECs since R3 advertised >10.2.153/23 and 10.2.154/23 prefixes to it. I am not sure whether I >understand your comment correctly. Please clarify. [PREM]: Though R3 is advertising these address prefixes but there may or may not be LSPs for these prefixes going towards R3. These new LSPs (LSPs for these address prefixes) would originate from R2 and may terminate on or after R3. So, from R1-R2 the labelled data transfer would take place on some LSP let's LSP1. After the data has been received at R2 (over LSP1), how does the rest of packet journey will take place till the final destination, is now known. Should it again go out on some LSP, that LSP would be different from LSP1. That LSP MAY BE considered a continuation/extension of LSP1 (depending on system implementation) but in actual protocol sense, the extended segment will not be part of LSP1. Now coming to clarification of the following stmts. from RFC 3031, ... it must execute the best match algorithm to find P's FEC. ... This is exactly the same operation that takes place at the ingress node - classification of the packet and mapping to a particular FEC. So, hopefully this would be clear now. -Prem > > > > 2. Suppose the LSP is being used as a tunnel that ends after R2 and >if > > >the > > > > answer for my question (1) is true, then stripping the top label >will > > >never > > > > reveal the IP header yet since there will still be 1 or more labels. >Is > > >this > > > > situation valid? If so, can R2 still manage to terminate the LSP and > > >perform > > > > best match algorithm? If yes, then how? > > > > > >I don't think you can build an LSP beyond R2 in this case, in another > > >word, I don't know how you can have a tunnel that ends after R2. > > > > What I meant is, take for example an LSR with address 10.2.153.178 is a > > remote peer and the LSP in the example is the hop-by-hop routed tunnel >used > > for this peering. Obviously here the LSR is after the LSR2. > >With LDP, you can try to build a tunnel to 10.2.153.178, but if the >tunnel LSP is broken in the middle, you won't know. If you run MPLS VPN >over the broken tunnel, you blackhole the traffic. If you mean 'broken' = 'transparent FEC remapping', then I would agree with you. If you mean 'broken' = 'total disconnection' then eventually LSRs at both ends of the tunnel would know the tunnel is broken. Anyway my previous question narrowed down just to R2 only regardless of whether LSRs at both ends of the tunnel aware of any 'FEC remapping' at the middle of the tunnel or not. I am just wondering whether R2 would still be able to execute the best match algorithm to find better FEC for the affected packets since in the 'tunnel' case, stripping the top label would not immediately reveal the IP header (R2 will never know whether the LSP is also being used for tunnelling or not), but a second level label that it does not undestand at all. -Tze Ven _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Fri Apr 19 23:13:52 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13336 for ; Fri, 19 Apr 2002 23:13:51 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmliq12012; Sat, 20 Apr 2002 03:12:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQmliq27007 for mpls-outgoing; Sat, 20 Apr 2002 03:12: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 QQmliq27000 for ; Sat, 20 Apr 2002 03:12:02 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmliq29448 for ; Sat, 20 Apr 2002 03:10:41 GMT Received: from 21cn.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [61.140.60.248]) id QQmliq15387 for ; Sat, 20 Apr 2002 03:10:35 GMT Received: from 21cn.com([10.2.1.8]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm443cc0f15a; Sat, 20 Apr 2002 11:18:18 +0800 Received: from cmr2.ash.ops.us.uu.net([198.5.241.40]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm63cbbfd14; Tue, 16 Apr 2002 17:06:54 +0800 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 QQmkuu12292; Tue, 16 Apr 2002 09:07:55 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkuu18599 for mpls-outgoing; Tue, 16 Apr 2002 09:06: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 QQmkuu18504 for ; Tue, 16 Apr 2002 09:06:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmkuu13950 for ; Tue, 16 Apr 2002 09:06:12 GMT Received: from mailserver.in.huawei.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.168.167]) id QQmkuu09697 for ; Tue, 16 Apr 2002 09:06:10 GMT Received: from Unknown [10.18.1.2] by mailserver.in.huawei.com - SuperScout Email Filter ; Tuesday, 16 April 2002, 14:30:59 Message-ID: <751B6DD7A243D511AB9F0002557C5687036EC162@huaweimail> From: Pradeepa Shastry To: Sachin Kalra , mpls@UU.NET Date: Tue, 16 Apr 2002 14:39:20 +0530 Subject: RE: BGP/MPLS VPNs. Draft 2547bis Jan 2002 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--=_NextPart_ST_14_30_59_Tuesday_April_16_2002_14791" X-Mailer: Internet Mail Service (5.5.2653.19) 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_ST_14_30_59_Tuesday_April_16_2002_14791 Content-Type: text/plain; charset="iso-8859-1" Hi, In the hub and spoke VPN topology you can use different Export/Import policies. Juniper does support this please see the URL http://www.juniper.net/techcenter/techpapers/200012-02.html Thanks and Regards -Pradeep Shastry -----Original Message----- From: Sachin Kalra [mailto:skalra@opnet.com] Sent: Tuesday, April 16, 2002 2:57 AM To: mpls@UU.NET Subject: BGP/MPLS VPNs. Draft 2547bis Jan 2002 Dear All: I would appreciate if I can get answer to the following: If we have two sites "A" and "B" belonging to same VPN "Yellow_VPN", and connected to same PE (different physical interfaces), [CE-site A] / / .....[PE] \ \ [CE-site B] then: 1. Can we specify different Export/Import route targets for each of the site "A" and "B"? Does "Cisco/Juniper/Any other vendor" supports this? I could not find any example (Or just command) for configuring such scenario. Thanks for your response. Sachin Kalra -------------------------------------------------------------------------------------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Huawei Technologies India Pvt. Ltd. ----=_NextPart_ST_14_30_59_Tuesday_April_16_2002_14791 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: BGP/MPLS VPNs. Draft 2547bis Jan 2002

Hi,

In the hub and spoke VPN topology you can use different E= xport/Import policies. Juniper does support this please see the URL<= /P>

http://www.juniper.net/techcenter/techpape= rs/200012-02.html

Thanks and Regards
-Pradeep Shastry
 

-----Original Message-----
From: Sachin Kalra [= mailto:skalra@opnet.com]
Sent: Tuesday, April 16, 2002 2:57 AM
To: mpls@UU.NET
Subject: BGP/MPLS VPNs. Draft 2547bis Jan 2002


Dear All:

I would appreciate if I can get answer to the following:<= /FONT>

If we have two sites "A" and "B" belo= nging to same VPN "Yellow_VPN", and
connected to same PE (different physical interfaces),

         &nb= sp;      [CE-site A]
         &n= bsp;     /
         &n= bsp;    /
......[PE]
         &n= bsp;    \
         &n= bsp;     \
         &n= bsp;      [CE-site B]

then:
1. Can we specify different Export/Import route targets = for each of the
site "A" and "B"? Does "Cisco/J= uniper/Any other vendor" supports this? I
could not find any example (Or just command) for configu= ring such scenario.

Thanks for your response.
Sachin Kalra

---------------------------------------------------------------------------= -----------------------------------------
This email and any files trans= mitted with it are confidential and
intended solely for the use of the i= ndividual or entity to whom
they are addressed. If you have received thi= s email in error please notify the
originator of the message.

An= y views expressed in this message are those of the individual
sender, ex= cept where the sender specifies and with authority,
states them to be th= e views of Huawei Technologies India Pvt. Ltd. ----=_NextPart_ST_14_30_59_Tuesday_April_16_2002_14791-- From owner-mpls@UU.NET Sat Apr 20 04:15:56 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29533 for ; Sat, 20 Apr 2002 04:15:55 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmljk26020; Sat, 20 Apr 2002 08:14:38 GMT Received: by mail-control.ash.ops.us.uu.net id QQmljk04337 for mpls-outgoing; Sat, 20 Apr 2002 08:14:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmljk04332 for ; Sat, 20 Apr 2002 08:14:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmljk24011 for ; Sat, 20 Apr 2002 08:13:40 GMT Received: from 21cn.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [61.140.60.248]) id QQmljk17873 for ; Sat, 20 Apr 2002 08:13:36 GMT Received: from 21cn.com([10.2.1.8]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm1b43cc12d36; Sat, 20 Apr 2002 16:09:56 +0800 Received: from cmr2.ash.ops.us.uu.net([198.5.241.40]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm803cbc9111; Tue, 16 Apr 2002 22:06:49 +0800 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 QQmkvo28838; Tue, 16 Apr 2002 14:08:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmkvo26825 for mpls-outgoing; Tue, 16 Apr 2002 14:07:29 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 QQmkvo26727 for ; Tue, 16 Apr 2002 14:07: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 QQmkvo01832 for ; Tue, 16 Apr 2002 14:05:47 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 QQmkvo05799 for ; Tue, 16 Apr 2002 14:05: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 KAA27697; Tue, 16 Apr 2002 10:05:46 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA02131; Tue, 16 Apr 2002 10:05:46 -0400 (EDT) Message-Id: <200204161405.KAA02131@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: "David Allan" cc: Loa Andersson , Scott Bradner , mpls@UU.NET Subject: Re: response to ITU-T SG13 In-reply-to: Your message of Mon, 15 Apr 2002 16:39:53 -0400. <3549C09B853DD5119B540002A52CDD3402C6E7F1@zcard0ka.ca.nortel.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Apr 2002 10:05:46 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk David> I politely flagged this one as I think it is a bit of a stretch to David> ask the ITU to comment on the effects of Y.1711 on stuff that does David> not exist and has not yet been specified. This is in addition to David> asking it's impact on proprietary implementations where to date there David> has been under-specification It is perfectly reasonable to ask whether the ITU foresees extending the OAM mechanisms in such a way as to impact any of the existing or even foreseen label distribution and/or routing protocols and mechanisms. It is also perfectly reasonable to ask about the impact of those mechanisms on existing deployments and implementations. One can of course offer a bunch of trumped up excuses for not wanting to answer the question, but perhaps that is an answer in itself. From owner-mpls@UU.NET Sun Apr 21 13:12:54 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28538 for ; Sun, 21 Apr 2002 13:12:53 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlom21931; Sun, 21 Apr 2002 17:11:44 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlom16504 for mpls-outgoing; Sun, 21 Apr 2002 17:11: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 QQmlom16370 for ; Sun, 21 Apr 2002 17:11:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlom26409 for ; Sun, 21 Apr 2002 17:10:56 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe31.law9.hotmail.com [64.4.8.88]) id QQmlom03221 for ; Sun, 21 Apr 2002 17:10:56 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 21 Apr 2002 10:10:55 -0700 X-Originating-IP: [212.199.233.65] From: "Doug Degan" To: Subject: fast-reroute usage (implementation question) Date: Sun, 21 Apr 2002 20:10:40 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C1E970.9C2D7BC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 21 Apr 2002 17:10:55.0743 (UTC) FILETIME=[7FBA58F0:01C1E957] Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C1E970.9C2D7BC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable when a protected LSP had a failure and now the bypass is in use - what = should the ingress do when he gets the news about the failure? if it can't find alternative path for tha protected LSP - should it shut = the protected LSP??? should it shut it after some timeout? say 3 minutes ? yours=20 doug. ------=_NextPart_000_0007_01C1E970.9C2D7BC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
when a protected LSP had a failure and = now the=20 bypass is in use - what should the ingress do when he gets the news=20 about the failure?
 
if it can't find alternative path for = tha protected=20 LSP - should it shut the protected LSP???
should it shut it after some timeout? = say 3 minutes=20 ?
 
yours
    doug.
 
 
 
 
------=_NextPart_000_0007_01C1E970.9C2D7BC0-- From owner-mpls@UU.NET Sun Apr 21 14:58:38 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00188 for ; Sun, 21 Apr 2002 14:58:38 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlot09038; Sun, 21 Apr 2002 18:57:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlot15674 for mpls-outgoing; Sun, 21 Apr 2002 18:57: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 QQmlot15669 for ; Sun, 21 Apr 2002 18:57: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 QQmlot12664 for ; Sun, 21 Apr 2002 18:56:19 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmlot09295 for ; Sun, 21 Apr 2002 18:56:19 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3LIuBE11807; Sun, 21 Apr 2002 14:56:11 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 21 Apr 2002 14:56:13 -0400 Message-ID: <710197BD5AF9D4119E4400508BCFA13603E110CC@zcard04u.ca.nortel.com> From: "Osama Aboul-Magd" To: te-wg@ops.ietf.org, mpls@UU.NET, diffserv@ietf.org Date: Sun, 21 Apr 2002 14:56:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E966.354BD424" 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_01C1E966.354BD424 Content-Type: text/plain; charset="ISO-8859-1" Call for Papers Minitrack on Quality of Service in the Internet Software Technology Track Hawaii International Conference on Systems Science January 6-9, 2003 Hilton Waikoloa Village Big Island, Hawaii Web page: http://www.ee.iastate.edu/~kamal/HICSS36 Overview: A large number of network applications, differing in requirements and traffic characteristics have been introduced in the past few years. As such, the Internet is now moving from being a best-effort service provider, to a provider of assured service qualities. This requires the development of new protocols, both inside subnetworks, and on end-to-end levels. Such protocols should deal with issues as service differentiation, pricing, congestion control, QoS routing, resource reservation, service provisioning, etc. The Internet Engineering Task Force (IETF), as the main standard body for IP protocol has been working on those issues. A new and lightweight service paradigm, namely, the Differentiated Services (DiffServ) approach has been proposed by IETF and active research is underway to define architectures and strategies for QoS within the Internet. Several issues still need to be worked on, such as end-to-end service interworking, actual protocol mechanisms and implementation, classification and marking, the service level agreement and the service guarantees. Scope: The minitrack will concentrate on complete or ongoing research in the area of Internet Quality of Service. Areas of interest include, but are not limited to: - Traffic characterization - Differentiated services protocols and signaling - Multiprotocol Label Switching (MPLS) - Asynchronous Transfer Mode (ATM) QoS - Layer 2 QoS, e.g., IEEE 802.1Q VLAN - Scheduling algorithms - End-to-end service interworking - Congestion control strategies in DiffServ networks - Active queue management - Resource reservation - Pricing - Performance evaluation Minitrack Co-Chairs: Ahmed E. Kamal Dept. of Electrical & Computer Eng. Iowa State University Ames, IA 50011 U.S.A. Tel: (515) 294-3580
Fax: (515) 294-8432
E-mail: kamal@iastate.edu Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y - 4H7 CANADA Tel: 613-763-5827 Fax: 613-763-2697 E-mail: osama@nortelnetworks.com Important Deadlines: March 31, 2002 A 300-word abstract April 19, 2002 Feedback to author on abstract June 1, 2002 Eight copies of the manuscript August 31, 2002 Notification of accepted papers October 1, 2002 Camera-ready copies of accepted manuscripts Instructions for Authors: Submit a 300-word abstract to either of the two co-chairs (kamal@iastate.edu or osama@nortelnetworks.com) by March 31, 2002. The preferred method of submission is e-mail. However, submissions by regular mail, or fax will also be considered. Feedback on the appropriateness of the abstract will be sent to the authors by April 19, 2002. Submit the full manuscript by June 1, 2002. Manuscripts should have an abstract and be 22-25 typeset, double-spaced pages in length. Papers must not have been previously presented or published, nor currently submitted for publication. Each manuscript will be peer-reviewed, and accepted manuscripts will be published in the conference proceedings. If you have more questions, or want to find out more about HICSS36, please go to the Software Technology Track homepage, http://www.engr.smu.edu/~rewini/cfp-stt-h36.html or contact either of the co-chairs. ------_=_NextPart_001_01C1E966.354BD424 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

           &n= bsp;           &n= bsp;   Call for Papers

           &n= bsp;    Minitrack on Quality of Service in the = Internet

           &n= bsp;           &n= bsp; Software Technology Track

           &n= bsp; Hawaii International Conference on Systems Science

           &n= bsp;           &n= bsp;     January 6-9, 2003

           &n= bsp;           &n= bsp;  Hilton Waikoloa Village

           &n= bsp;           &n= bsp;     Big Island, Hawaii

           &n= bsp; Web page: http://www.ee.iastate.edu/~kamal/HICSS36

Overview:

A large number of network applications, differing in requirements = and traffic

characteristics have been introduced in the past few years.  = As such, the

Internet is now moving from being a best-effort service provider, = to a provider

of assured service qualities.  This requires the development = of new

protocols, both inside subnetworks, and on end-to-end levels.  = Such protocols

should deal with issues as service differentiation, pricing, = congestion

control, QoS routing, resource reservation, service provisioning, = etc.   The

Internet Engineering Task Force (IETF), as the main standard body = for IP

protocol has been working on those issues.

A new and lightweight service paradigm, namely, the Differentiated = Services

(DiffServ) approach has been proposed by IETF and active research = is underway

to define architectures and strategies for QoS within the = Internet.  Several

issues still need to be worked on, such as end-to-end = service

interworking, actual protocol mechanisms and = implementation,

classification and marking, the service level agreement and the = service

guarantees.

Scope:

The minitrack will concentrate on complete or ongoing research in = the area

of Internet Quality of Service.  Areas of interest include, = but are not

limited to:

- Traffic characterization

- Differentiated services protocols and signaling

- Multiprotocol Label Switching (MPLS)

- Asynchronous Transfer Mode (ATM) QoS

- Layer 2 QoS, e.g., IEEE 802.1Q VLAN

- Scheduling algorithms

- End-to-end service interworking

- Congestion control strategies in DiffServ networks

- Active queue management

- Resource reservation

- Pricing

- Performance evaluation

Minitrack Co-Chairs:

Ahmed E. Kamal

Dept. of Electrical & Computer Eng.

Iowa State University

Ames, IA 50011

U.S.A.

Tel: (515) 294-3580<br>

Fax: (515) 294-8432<br>

E-mail: kamal@iastate.edu

Osama Aboul-Magd

Nortel Networks

P.O. Box 3511, Station C

Ottawa, ON K1Y - 4H7

CANADA

Tel: 613-763-5827

Fax: 613-763-2697

E-mail: osama@nortelnetworks.com

Important Deadlines:

March 31, 2002      A 300-word = abstract

April 19, 2002      Feedback to author on = abstract

June 1, 2002        Eight copies = of the manuscript

August 31, 2002     Notification of accepted = papers

October 1, 2002     Camera-ready copies of = accepted manuscripts

           &n= bsp;       

Instructions for Authors:

Submit a 300-word abstract to either of the two co-chairs = (kamal@iastate.edu

or osama@nortelnetworks.com) by March 31, 2002.  The preferred = method of

submission is e-mail.  However, submissions by regular mail, = or fax will

also be considered.  Feedback on the appropriateness of the = abstract will

be sent to the authors by April 19, 2002. Submit the full = manuscript by

June 1, 2002. Manuscripts should have an abstract and be 22-25 = typeset,

double-spaced pages in length.  Papers must not have been = previously

presented or published, nor currently submitted for publication. =

Each manuscript will be peer-reviewed, and accepted manuscripts = will be

published in the conference proceedings.

If you have more questions, or want to find out more about = HICSS36,

please go to the Software Technology Track homepage,

http://www.engr.smu.edu/~rewini/cfp-stt-h36.html

or contact either of the co-chairs.



------_=_NextPart_001_01C1E966.354BD424-- From owner-mpls@UU.NET Sun Apr 21 16:48:09 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01654 for ; Sun, 21 Apr 2002 16:48:09 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlpb06264; Sun, 21 Apr 2002 20:47:13 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlpb05976 for mpls-outgoing; Sun, 21 Apr 2002 20:46:58 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 QQmlpb05971 for ; Sun, 21 Apr 2002 20:46:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlpb23916 for ; Sun, 21 Apr 2002 20:46:07 GMT Received: from horkos.telenet-ops.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: horkos.telenet-ops.be [195.130.132.45]) id QQmlpb04783 for ; Sun, 21 Apr 2002 20:46:05 GMT Received: from localhost (localhost.localdomain [127.0.0.1]) by horkos.telenet-ops.be (Postfix) with SMTP id 0A6F083C05 for ; Sun, 21 Apr 2002 22:46:05 +0200 (CEST) Received: from dwilma (D5768FB8.kabel.telenet.be [213.118.143.184]) by horkos.telenet-ops.be (Postfix) with SMTP id D1613841D2 for ; Sun, 21 Apr 2002 22:46:04 +0200 (CEST) Message-ID: <002601c1e975$2d8152a0$a100a8c0@dwilma> From: "dirk @pandora" To: Subject: fast rerouting Date: Sun, 21 Apr 2002 22:43:22 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01C1E985.F0ED24C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C1E985.F0ED24C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi to all, On this moment i'm working on a project on implementing fast rerouting = on a MPLS network. the test are not that succesfull. when their's a TE tunnel between two PE routers and i'm protecting a = link between two P routers on the LSP, everithing is working perfect. = traffic is swapped on the backup tunnel. ---PE----------------P------------------------P-------------PE \ / \ / ------------------ backup path The problem is when the TE tunnel and the backup tunnels haed end is the = same router, on this moment i'm loosing packets the moment the interface = goes down, and the backup path is taken. I Is it not possible to protect the link between two routers if the head = end of the main tunnel and the backup tunnel are the same ??? Thanks for your response. Dirk Wilmaerts ------=_NextPart_000_0023_01C1E985.F0ED24C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi to all,
 
On this moment i'm working on a = project on=20 implementing fast rerouting on a MPLS network.
 
the test are not that = succesfull.
 
when their's a TE tunnel between two PE = routers and=20 i'm protecting a link between two P routers on the LSP, everithing is = working=20 perfect. traffic is swapped on the backup tunnel.
 
 
 
---PE----------------P------------------------P-------------PE
          &nbs= p;            = ;=20 \            =            =20 /
          &nbs= p;            = ; =20 \            =         =20 /
          &nbs= p;            = ;   =20 ------------------
          &nbs= p;            = ;  =20 backup path
 
The problem is when the TE tunnel and = the backup=20 tunnels haed end is the same router, on this moment i'm loosing packets = the=20 moment the interface goes down, and the backup path is = taken.
I
 
Is it not possible to protect the link = between two=20 routers if the head end of the main tunnel and the backup tunnel are the = same=20 ???
 
 
Thanks for your response.
 
Dirk Wilmaerts
 
 
------=_NextPart_000_0023_01C1E985.F0ED24C0-- From owner-mpls@UU.NET Mon Apr 22 07:34:35 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21933 for ; Mon, 22 Apr 2002 07:34:34 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlrh22624; Mon, 22 Apr 2002 11:28:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlrh27798 for mpls-outgoing; Mon, 22 Apr 2002 11:28:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmlrh27793 for ; Mon, 22 Apr 2002 11:28:12 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 QQmlrh15836 for ; Mon, 22 Apr 2002 11:28: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 QQmlrh21345 for ; Mon, 22 Apr 2002 11:28:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA11473 for ; Mon, 22 Apr 2002 07:28:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA24315 for mpls@uu.net; Mon, 22 Apr 2002 07:28:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmlrh27734 for ; Mon, 22 Apr 2002 11:27:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlrh22261 for ; Mon, 22 Apr 2002 11:26:06 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 QQmlrh17570 for ; Mon, 22 Apr 2002 11:26:06 GMT Received: from JVASSEUR-W2K.cisco.com (ams-clip-vpn-dhcp27.cisco.com [10.50.0.26]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA12835; Mon, 22 Apr 2002 13:26:04 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020422132536.06d95e78@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Apr 2002 13:26:02 +0200 To: "dirk @pandora" From: Jean Philippe Vasseur Subject: Re: fast rerouting Cc: In-Reply-To: <002601c1e975$2d8152a0$a100a8c0@dwilma> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_70717065==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_70717065==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 22:43 21/04/2002 +0200, dirk @pandora wrote: >Hi to all, > >On this moment i'm working on a project on implementing fast rerouting on >a MPLS network. > >the test are not that succesfull. > >when their's a TE tunnel between two PE routers and i'm protecting a link >between two P routers on the LSP, everithing is working perfect. traffic >is swapped on the backup tunnel. > > > >---PE----------------P------------------------P-------------PE > \ / > \ / > ------------------ > backup path > >The problem is when the TE tunnel and the backup tunnels haed end is the >same router, on this moment i'm loosing packets the moment the interface >goes down, and the backup path is taken. >I > >Is it not possible to protect the link between two routers if the head end >of the main tunnel and the backup tunnel are the same ??? This is of course possible. JP. > > >Thanks for your response. > >Dirk Wilmaerts > > --=====================_70717065==_.ALT Content-Type: text/html; charset="us-ascii" At 22:43 21/04/2002 +0200, dirk @pandora wrote:
Hi to all,
 
On this moment i'm working on a project on implementing fast rerouting on a MPLS network.
 
the test are not that succesfull.
 
when their's a TE tunnel between two PE routers and i'm protecting a link between two P routers on the LSP, everithing is working perfect. traffic is swapped on the backup tunnel.
 
 
 
---PE----------------P------------------------P-------------PE
                        \                        /
                         \                     /
                           ------------------
                          backup path
 
The problem is when the TE tunnel and the backup tunnels haed end is the same router, on this moment i'm loosing packets the moment the interface goes down, and the backup path is taken.
I
 
Is it not possible to protect the link between two routers if the head end of the main tunnel and the backup tunnel are the same ???

This is of course possible.

JP.

 
 
Thanks for your response.
 
Dirk Wilmaerts
 
 
--=====================_70717065==_.ALT-- From owner-mpls@UU.NET Mon Apr 22 07:42:13 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22082 for ; Mon, 22 Apr 2002 07:42:13 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlri28132; Mon, 22 Apr 2002 11:31:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlri28125 for mpls-outgoing; Mon, 22 Apr 2002 11:31: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 QQmlri28115 for ; Mon, 22 Apr 2002 11:31:06 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlri22754 for ; Mon, 22 Apr 2002 11:30:06 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmlri25806 for ; Mon, 22 Apr 2002 11:30: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 HAA11542 for ; Mon, 22 Apr 2002 07:30:04 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA24546 for mpls@uu.net; Mon, 22 Apr 2002 07:30:04 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmlrh27844 for ; Mon, 22 Apr 2002 11:29: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 QQmlrh18366 for ; Mon, 22 Apr 2002 11:28:50 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 QQmlrh23538 for ; Mon, 22 Apr 2002 11:28:49 GMT Received: from JVASSEUR-W2K.cisco.com (ams-clip-vpn-dhcp27.cisco.com [10.50.0.26]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA13850; Mon, 22 Apr 2002 13:28:46 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020422132623.06f9b330@paris.cisco.com> X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 22 Apr 2002 13:28:44 +0200 To: "Doug Degan" From: Jean Philippe Vasseur Subject: Re: fast-reroute usage (implementation question) Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_70878728==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_70878728==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 20:10 21/04/2002 +0300, Doug Degan wrote: >when a protected LSP had a failure and now the bypass is in use - what >should the ingress do when he gets the news about the failure? > >if it can't find alternative path for tha protected LSP - should it shut >the protected LSP??? >should it shut it after some timeout? say 3 minutes ? > Your question is an implementation question. You should see with your vendor. A possible implementation is: - when the head-end receives the Path Error "Tunnel locally repaired", it can trigger a reoptimization, - if the TE LSP cannot be reoptimized, the head-end can still use the TE LSP without shutting it down. JP. >yours > doug. > > > > --=====================_70878728==_.ALT Content-Type: text/html; charset="us-ascii" At 20:10 21/04/2002 +0300, Doug Degan wrote:
when a protected LSP had a failure and now the bypass is in use - what should the ingress do when he gets the news about the failure?
 
if it can't find alternative path for tha protected LSP - should it shut the protected LSP???
should it shut it after some timeout? say 3 minutes ?
 

Your question is an implementation question. You should see with your vendor.
A possible implementation is:
- when the head-end receives the Path Error "Tunnel locally repaired", it can trigger a reoptimization,
- if the TE LSP cannot be reoptimized, the head-end can still use the TE LSP without shutting it down.

JP.

yours
    doug.
 
 
 
 
--=====================_70878728==_.ALT-- From owner-mpls@UU.NET Mon Apr 22 08:10:24 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22798 for ; Mon, 22 Apr 2002 08:10:23 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlrk17484; Mon, 22 Apr 2002 12:09:37 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlrk21079 for mpls-outgoing; Mon, 22 Apr 2002 12:09: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 QQmlrk21074 for ; Mon, 22 Apr 2002 12:09:19 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 QQmlrk04786 for ; Mon, 22 Apr 2002 12:09:17 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 QQmlrk28848 for ; Mon, 22 Apr 2002 12:09:16 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA12739 for ; Mon, 22 Apr 2002 08:09:16 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA29125 for mpls@uu.net; Mon, 22 Apr 2002 08:09:16 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmlff10073 for ; Fri, 19 Apr 2002 04:54:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlff16810 for ; Fri, 19 Apr 2002 04:52:53 GMT Received: from tama5.ecl.ntt.co.jp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQmlff22667 for ; Fri, 19 Apr 2002 04:52:52 GMT Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/31/02) with ESMTP id NAA06857; Fri, 19 Apr 2002 13:52:33 +0900 (JST) (envelope-from ohta.hiroshi@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.2/8.12.2) with ESMTP id g3J4qXQl017552; Fri, 19 Apr 2002 13:52:33 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.2/8.12.2) with ESMTP id g3J4qWuu026372; Fri, 19 Apr 2002 13:52:32 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA01314; Fri, 19 Apr 2002 13:52:32 +0900 (JST) Received: from HIROSHI-TP2 by imf.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id NAA06503; Fri, 19 Apr 2002 13:52:31 +0900 (JST) Message-Id: <4.2.0.58.J.20020419133818.03a99528@imf.m.ecl.ntt.co.jp> X-Sender: ho016@imf.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Fri, 19 Apr 2002 13:51:25 +0900 To: Scott Bradner , mpls@UU.NET From: Hiroshi Ohta Subject: Re: response to ITU-T SG13 In-Reply-To: <200204182259.g3IMx9618525@newdev.harvard.edu> References: <4.2.0.58.J.20020418221303.03a99528@imf.m.ecl.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Scott, In order to operate MPLS OAM, there are several options. For example, to activate/deactivate OAM functions some options need modifications to IETF protocols and others do not. SG13 cannot give you an definite answer because it is not determined what option to take. If one (not necessarily from ITU) thinks modifications to IETF protocols are necessary, one would propose it using I-D. IETF has the choice to take it or not. It is just the same as how IETF operates. So, what is the problem? Best regards, Hiroshi At 18:59 02/04/18 -0400, Scott Bradner wrote: > > Would you clarify what the real problem is? > >exactly what I said - I want to know if SG 16 is expecting to need changes >to IETF protocols - i.e. full disclosure > >no more, no less > >Scott From owner-mpls@UU.NET Mon Apr 22 08:19:03 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23281 for ; Mon, 22 Apr 2002 08:19:03 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlrl14139; Mon, 22 Apr 2002 12:18:18 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlrl22933 for mpls-outgoing; Mon, 22 Apr 2002 12:17:59 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 QQmlrl22928 for ; Mon, 22 Apr 2002 12:17:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlrl11653 for ; Mon, 22 Apr 2002 12:17:44 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 QQmlrl13040 for ; Mon, 22 Apr 2002 12:17: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 IAA12976 for ; Mon, 22 Apr 2002 08:17:43 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA00843 for mpls@uu.net; Mon, 22 Apr 2002 08:17:43 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmlqj24178 for ; Mon, 22 Apr 2002 05:24:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmlqj28015 for ; Mon, 22 Apr 2002 05:24:34 GMT Received: from tama5.ecl.ntt.co.jp by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tama5.ecl.ntt.co.jp [129.60.39.102]) id QQmlqj05236 for ; Mon, 22 Apr 2002 05:24:33 GMT Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/31/02) with ESMTP id OAA24789; Mon, 22 Apr 2002 14:24:08 +0900 (JST) (envelope-from ohta.hiroshi@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.2/8.12.2) with ESMTP id g3M5O7Ql013945; Mon, 22 Apr 2002 14:24:08 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.2/8.12.2) with ESMTP id g3M5O7uu023854; Mon, 22 Apr 2002 14:24:07 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id OAA00765; Mon, 22 Apr 2002 14:24:07 +0900 (JST) Received: from HIROSHI-TP2 by imf.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id OAA21421; Mon, 22 Apr 2002 14:24:06 +0900 (JST) Message-Id: <4.2.0.58.J.20020422140614.03d4e1b8@imf.m.ecl.ntt.co.jp> X-Sender: ho016@imf.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 22 Apr 2002 14:22:58 +0900 To: Scott Bradner From: Hiroshi Ohta Subject: Re: response to ITU-T SG13 Cc: mpls@UU.NET In-Reply-To: <200204191118.g3JBIrB20028@newdev.harvard.edu> References: <4.2.0.58.J.20020419133818.03a99528@imf.m.ecl.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Scott, I did not say that I did not want to know what is coming next. SG13 has not decided what method to take for issues that your draft Liaison back letter brought up. I am not an expert on politics, but I think the decision on the expansion of the IETF protocol should be based on the technical discussion even if it is politically harder (I do not know why though) to reject the proposal. Best regards, Hiroshi At 07:18 02/04/19 -0400, Scott Bradner wrote: >I fail to see why you would not want to know what is coming next > >you say that the IETF can decide to accept someting later or not - yes >that is factually correct but not actually that easy - if we have >started down a path it gets politically harder to say no the further >we are down the path > >if SG13 does not know they can just say that > >Scott > >--- From owner-mpls@UU.NET Mon Apr 22 08:48:03 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23935 for ; Mon, 22 Apr 2002 08:48:03 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlrn01615; Mon, 22 Apr 2002 12:47:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlrn25798 for mpls-outgoing; Mon, 22 Apr 2002 12:46:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmlrn25684 for ; Mon, 22 Apr 2002 12:46:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlrn11869 for ; Mon, 22 Apr 2002 12:45:10 GMT Received: from mail.grandistazioni.it by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [213.255.45.210]) id QQmlrn28123 for ; Mon, 22 Apr 2002 12:45:09 GMT Received: (qmail 16721 invoked by uid 506); 22 Apr 2002 12:36:57 -0000 Received: from FLombardo@grandistazioni.it by mail by uid 503 with qmail-scanner-1.10 (F-PROT: 3.11. Clear:0. Processed in 0.105697 secs); 22 Apr 2002 12:36:57 -0000 Received: from unknown (HELO db?srv.g?stazioni.it) (192.168.0.6) by 0 with SMTP; 22 Apr 2002 12:36:57 -0000 Received: by DB_SRV with Internet Mail Service (5.5.2653.19) id <2T4C1X60>; Mon, 22 Apr 2002 14:40:29 +0200 Message-ID: From: "Lombardo, Federico" To: "'mpls@uu.net'" Subject: Newbie question Date: Mon, 22 Apr 2002 14:40:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E9FA.E22A18B0" 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_01C1E9FA.E22A18B0 Content-Type: text/plain Hi all, I'm a MPLS newbie I'm wondering if exist somewhere documentation that explain differences and advantages between ATM and MPLS solutions. Thank in advance. Lombardo Federico, Network Administrator & Security Manager Tel. +3906.47841.362 Grandi Stazioni S.p.A. Italy ------_=_NextPart_001_01C1E9FA.E22A18B0 Content-Type: text/html

Hi all, I'm a MPLS newbie

I'm wondering if exist somewhere documentation that explain differences and advantages between ATM and MPLS solutions.

 

 

Thank in advance.

 

Lombardo Federico, Network Administrator & Security Manager

Tel. +3906.47841.362 

Grandi Stazioni S.p.A. Italy

 

------_=_NextPart_001_01C1E9FA.E22A18B0-- From owner-mpls@UU.NET Mon Apr 22 09:53:28 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25782 for ; Mon, 22 Apr 2002 09:53:28 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlrr14325; Mon, 22 Apr 2002 13:52:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlrr21168 for mpls-outgoing; Mon, 22 Apr 2002 13:52:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmlrr21156 for ; Mon, 22 Apr 2002 13:51:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmlrr04591 for ; Mon, 22 Apr 2002 13:51:24 GMT Received: from brahma01.netbrahma.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQmlrr12742 for ; Mon, 22 Apr 2002 13:51:16 GMT Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19) id <2YYVYW92>; Mon, 22 Apr 2002 19:04:43 +0530 Message-ID: <9027F68B07E7D511AE9400B0D0787DC0070489@mailserver.netbrahma.com> From: Manoj Agiwal To: "'ccamp@ops.ietf.org'" , "mpls@UU. NET (E-mail)" Subject: Admin Status Object / NHOP in GMPLS Date: Mon, 22 Apr 2002 19:04:36 +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 , As per RSVP-TE ( mpls ) there can be multiple fixed filter flow descriptor in a single Resv message . As per new Generalized MPLS RSVP-TE Resv message we have just one Admin Status. There is no means of knowing this Admin Status corresponds to which Fixed Filter Flow Descriptor carried in the Resv message . Do we assume in GMPLS that RSVP Resv message carries only one Fixed Filter Flow Desc ? The same holds true for NHOP in Resv message . There can be different data links for each fixed filter flow descriptor . Generalized RSVP-TE Draft Section 8.1.2 says "A node receiving one or more TLVs in a Path message saves their values and returns them in the HOP objects of subsequent Resv messages sent to the node that originated the TLVs." In this case there are multiple Path states in the same session , all are of Type FF . Therefore which Path message IF_ID_RSVP_HOP object will be carried in the Resv message . Again do we assume in GMPLS that RSVP Resv message carries only one Fixed Filter Flow Desc ? Do we have any possibilities in GMPLS of multiple Path states in the same session , all of type FF . If yes do we send different Resv messages for each FF flow descriptor . Regards , Manoj From owner-mpls@UU.NET Mon Apr 22 10:32:02 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26961 for ; Mon, 22 Apr 2002 10:32:01 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlru10862; Mon, 22 Apr 2002 14:30:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlru15288 for mpls-outgoing; Mon, 22 Apr 2002 14:30: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 QQmlru15283 for ; Mon, 22 Apr 2002 14:30: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 QQmlrt28059 for ; Mon, 22 Apr 2002 14:28:33 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 QQmlrt10667 for ; Mon, 22 Apr 2002 14:28: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 KAA19772; Mon, 22 Apr 2002 10:28:31 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA15091; Mon, 22 Apr 2002 10:28:31 -0400 (EDT) Message-Id: <200204221428.KAA15091@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Kireeti Kompella cc: Markus Jork , Vach Kompella , David Charlap , mpls@UU.NET Subject: Re: PHP In-reply-to: Your message of Thu, 18 Apr 2002 15:08:28 -0700. <20020418150539.L87151-100000@kummer.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Mon, 22 Apr 2002 10:28:31 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Kireeti> One could use IP LSPs for IP, IP VPNs, etc., where the payload is Kireeti> IP; and establish a parallel set of LSPs for non-IP traffic. I think the impact on the core makes this one a non-starter. Markus> Maybe it should be redefined to only apply to packets with a label Markus> stack of 1 while all other packets on the LSP with label stack > 1 Markus> are simply of unknown protocol type. Isn't this really the de facto standard interpretation? Eric> So in practice, PHP always results in either an IP packet or an MPLS Eric> packet, and the appropriate ethertype (IP or MPLS) can then be applied Eric> before the packet is transmitted to its next hop. Kireeti> How does one distinguish IPv4 from IPv6? Kireeti> One could use the 'check first nibble' hack :-( It would be neater Kireeti> to use the L3PID. Well, I wouldn't want to have to set up a separate TE tunnel just to handle the IPv6 traffic, so I'd recommend the "check first nibble" hack. From owner-mpls@UU.NET Mon Apr 22 10:56:53 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28079 for ; Mon, 22 Apr 2002 10:56:53 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlrv14372; Mon, 22 Apr 2002 14:55:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlrv17764 for mpls-outgoing; Mon, 22 Apr 2002 14:54: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 QQmlrv17755 for ; Mon, 22 Apr 2002 14:54:32 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 QQmlrv17070 for ; Mon, 22 Apr 2002 14:54:11 GMT Received: from wiprom2mx1.wipro.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQmlrv23294 for ; Mon, 22 Apr 2002 14:54:10 GMT Received: from m2vwall2.wipro.com ([164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g3MEs3E29878 for ; Mon, 22 Apr 2002 20:24:04 +0530 (IST) Received: from Sonal.alc.wipinfo.soft.net ([192.168.220.119]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GUZ5DX00.M56; Mon, 22 Apr 2002 20:23:57 +0530 Message-ID: <001a01c1e9ea$28094600$77dca8c0@Sonal.alc.wipinfo.soft.net> Reply-To: "venkat" From: "Venkat Dabbara" To: "Lombardo Federico" , "'mpls@uu.net'" Subject: Re: Newbie question Date: Mon, 22 Apr 2002 20:40:43 +1000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-9f991525-55f0-11d6-af80-0080c8048dde" 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. ------=_NextPartTM-000-9f991525-55f0-11d6-af80-0080c8048dde Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lombardo, you can see this link... Might help you .. http://www.fokus.gmd.de/research/cc/tip/atm-stammtisch/protokolle/110500/= ATMSTAMM/ regards venkat -----Original Message----- From: Lombardo, Federico To: 'mpls@uu.net' Date: Monday, April 22, 2002 10:47 PM Subject: Newbie question >Hi all, I'm a MPLS newbie > >I'm wondering if exist somewhere documentation that explain differences = and >advantages between ATM and MPLS solutions. > >=20 > >=20 > >Thank in advance. > >=20 > >Lombardo Federico, Network Administrator & Security Manager=20 > >Tel. +3906.47841.362 =20 > >Grandi Stazioni S.p.A. Italy > >=20 > > ------=_NextPartTM-000-9f991525-55f0-11d6-af80-0080c8048dde Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPartTM-000-9f991525-55f0-11d6-af80-0080c8048dde-- From owner-mpls@UU.NET Mon Apr 22 15:27:37 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09655 for ; Mon, 22 Apr 2002 15:27:37 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlsn08217; Mon, 22 Apr 2002 19:26:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlsn29251 for mpls-outgoing; Mon, 22 Apr 2002 19:26: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 QQmlsn29203 for ; Mon, 22 Apr 2002 19:25:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlsn07220 for ; Mon, 22 Apr 2002 19: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 QQmlsn14619 for ; Mon, 22 Apr 2002 19:24:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA17947 for ; Mon, 22 Apr 2002 15:24:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA14310 for mpls@uu.net; Mon, 22 Apr 2002 15:24:01 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmlsn29009 for ; Mon, 22 Apr 2002 19:22:58 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 QQmlsn13716 for ; Mon, 22 Apr 2002 19:19:12 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [161.44.168.94]) id QQmlsn07240 for ; Mon, 22 Apr 2002 19:19:11 GMT Received: from pilgrim.cisco.com (localhost [127.0.0.1]) by pilgrim.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA22734 for ; Mon, 22 Apr 2002 15:19:11 -0400 (EDT) Message-Id: <200204221919.PAA22734@pilgrim.cisco.com> To: mpls@UU.NET Subject: Draft Minutes from MPLS in MPLS (Minneapolis that is) Date: Mon, 22 Apr 2002 15:19:11 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk MPLS WG Meeting Minutes IETF #53 Minneapolis, March 2002 Tuesday March 19 2002, 9.00 AM - 11.30 AM George introduced Loa Andersson (loa.andersson@utfors.se) as the new WG co-chair. Agenda bashing Loa introduced the agenda noting the addition of a discussion on the ITU Liaison on the subject of MPLS OAM to be lead by Scott Bradner. LDP to Draft Standard - Loa Anderssen Loa gave an update on status and presented representations. In order to advance to Draft Standard, we need to identify those features of LDP which are actually implemented and in use. To that end we would like to get information on all implementations of LDP. Report on the FT/Graceful restart for LDP - Andy Malis Andy updated the group on the progress of integrating the two proposals. Good progress has been made, but there is one major technical issue to resolve. If sequence are carried in both schemes this will simplify the implementation if someone needs to build both schemes. It will also make it easier to for the two schemes to interoperate. On the downside, it causes the simplier solution to be more complicated. Simplification was the original motivation for the proposal George (chair): Interoperability is important. If that can be achieved, we should go for it. Detecting Data Plane Liveliness in RSVP-TE - Kireeti Kompella Kireeti presented the draft and closed with the comment that although he would like to see it become a WG document eventually, he suggested that perhaps people should just write some code for now. George (as a co-auther and chair) suggested that it would be good for the workgroup to know what proposal folks were trying to converge on. He then asked the room. There was consensus to make a WG document. Fast Reroute Extensions to RSVP-TE for LSP Tunnels - Ping Pan Ping gave an overview of recent updates to the draft. George commented that the draft was pretty much technically stable at this point but would benefit from an editorial scrub. MPLS Traffic Engineering MIB for Fast Reroute - Riza Cetin Riza Cetin gave an overview of the draft. George: Should we use this as a basis for the FRR MIB in this WG? Room: Looks like consensus. George: Should it be adopted as WG draft? Room: Looks like consensus. Bradner: Charter process check. Is this in the charter? George: Yes. Fast-reroute is in the charter. A MIB for this is therefore appropriate. Backup Record Route for Fast Reroute Techniques in RSVP-TE - Stefan de Cnodder Stefan presented his draft and asked that it be accepted as WG document. George (not as chair): I am reluctant on both pieces presented. In the backup RRO (BRRO), a lot of management information is being moved around in RSVP. With regard to the backup ERO (BERO), we are working on mechanisms for doing FRR in a unified way. I wouldn't want to add this to the standard right now. We might want to move this around in experimental track for now. Q1: If you have a failure, is there a signaling delay? Stefan: ERO is optional. If nodes cannot follow the path suggested, then they can take alternate one. If there is a failure, then you can fall back on the original path. Q2: BRRO is important for the MIB. Customers are interested in seeing all detours in one place. Otherwise we have to go along all PLRs along path. Ping: This same information might be encapsulated in RRO. Also, should get more operator feedback before we change the RSVP protocol. Yakov: This approach will not work well (or at all) with inter-area TE. Head end needs to have all link state information, so this can become a major bottleneck. Tom: Need more experience from operators to see if they want more information in RSVP or want to just contact each node to get FRR information. George: Need more experience with this approach and feedback from operators before we can adopt this document. A method for an Optimized Online Placement of MPLS Bypass Tunnels - Jean-Louis le Roux Jean-Louis presented his draft. He then asked that this be accepted as a MPLS WG document. There was no consensus on this as the work is in a fairly early stage. George commented that he felt that this was important work and encouraged Jean-Louis to continue it. Yakov: CCAMP is working on protection restoration. The issue of shared resources are being addressed there. There may be an overlap between both pieces of work. George: These mechanisms can be made generalized. Our charter is to do specific MPLS work. (to Jean-Loius) Make sure that your work is coordinated with CCAMP. A Packet 1+1 Path Protection Service for MPLS Networks Akber Qureshi Akber: Presentation. Loa: This seems almost too good. Could you address the drawbacks associated with this proposal. Could you also address why this proposal is MPLS-specific. This looks like something done in the mid-80's for telephony. Akber: This is selection based on the packet level. This is different from traditional 1+1 because you are creating both as active and selecting one based on an identifier. This scheme is targeted towards services that have QoS requirements. If you look at other schemes that use a sliding window scheme, you can tell which next packets are accepted. The size of that window depends on how many packets you can process. Loa: I think we have to discuss this on the list a bit more. On the drawbacks: cost is double-bandwidth allocation which might be an issue for a provider who has to book 2x. Akber: The cost with any 1+1 scheme is 2x booking. Mina: Mentioned that similar work is going on in ITU study group 13 for protection switching. There is a similar proposal: Y.1720. Akber: You need OAM packets to be sent if you are doing QoS to detect failures. Mina: OAM are two different things. That doesn't mean that protection switching will not work. Q1: How will this work if part of the net is going 1+1 and the other not. Akber: The 1+1 is done on a segment basis, but maybe not end-to-end. You can do part 1+1 in the network. Q2: Do you envision this as part of some MPLS service to guarantee bandwidth or packet loss. Akber: The benefit of the select is that you can have no packet loss. Q3: Intriguing proposal. How can you trouble ticket failure with this approach? Akber: From an egress point of view, it is not detecting any failure here. Q3: If something breaks, but the service servives, want to trouble ticket. The order of the detection can be different from protection. Bradner: I think this is a good demonstration of why we shouldn't do this. Technical presentations should not be done because of time. We need to do this on the list BEFORE the meeting so that we can discuss only open questions/issues at the meeting. George: At this point, we have exhausted our time. Take it to the list. Further considerations for Forwarding Adjacency LSPs - Dimitri Papadimitriou: Dimitri: Presentation. George: I think that this work is important to get out to the community. We are always open to enhancing existing work, but we need to figure out exactly which things you want to consider doing and see how it fits into the charter. Dimitri: Since the existing MPLS document has passed last call. Should we open an new document? George: We don't want to just do a V2 of forwarding adjacencies. We need to examine what further functionality is required by the community. Dimitri: We had a list of issues seen by the community today. Is this list complete enough today to do work. George: We need to understand if this work is okay to stand on its own and then determine if these all need to go into the same draft or into multiple ones. First step: check for interest in community, second: see if it fits into the charter. Hierarchical LSP Heinrich Hummel Heinrich presented his draft. In the presentation he noted that his ideas had evolved beyond what was captured in the first version. He asked that members of the workgroup look for his updated draft and requested that it be a subject of discussion on the maillist. George said that he would like to see more of the motivation and requirements behind the draft. Heinrich replied that this had been discussed in other workgroups, but that he would also summarize and continue the discussion on the MPLS list. RSVP-TE Extension for IPv4/IPv6 Dual Stacking PE under IPv4 MPLS Core Environment - Hiroki Ishibashi Hiroki: Presentation George pointed out that there is already a means of signaling the contents of an LSP with the PID. There already exist ethertype values for IPv4 and IPv6. Francois: I think that you know that ENGTrans working group that talks about Ipv6 over a Ipv4 backhone (with MPLS or without). There is already work being done elsewhere. The existing work is more general because it works with RSVP-TE and LDP, and covers routing and signaling aspects. I don't see why we need something more than what is already being done without extensions to MPLS protocols. Hiroki: Don't want to talk about routing issue. EngTrans need miultiple extensions for BGP, but this approach doesn't need that. This approach doesn't talk about routing extensions. Francois: Need to talk about routing. Can talk about BGP tunneling approach as well. Don't see why we need to change MPLS signaling to forward Ipv6 packets over MPLS. Hiroki: I just want to augment the egress process of PE routers. Loa: It appears this may overlap with work going on elsewhere in the IETF. I recommend that you go back and see if there is a delta to add this here after you check with those working in the other space. Issues with MPLS OAM - Scott Bradner Scott introduced the topic: There has been a discussion on MPLS OAM recently (CCAMP mailing list). I want to talk about what the next steps to take are. We (IETF) received a liason statement from the ITU in February requesting two LSP label values to support the ITU document Y.1711 (MPLS OAM). This describes OAM in the telephony sense rather than the IP sense. We have had two discussions going on. First, is this area of Telephony sense interest to the IETF. The consensus is reasonably there, but that there is more interest in dealing with MPLS in the arena of transporting IETF (CCAMP, MPLS). There are tools that existing in CCAMP/MPLS for addressing this. I sent a message asking for direction to the mailing list. Options: here is your label values ITU, or should we work together on this with ITU, or should we work on it alone? No votes for the latter. A couple people noticed that 1711 has hints that it itself is not a standalone concept. To fulfill the concepts it will require changes to other IETF protocols (BGP, LDP, RSVP). This is a little bit confusing. I want to send a lieason statement back to ITU and ask for specifics of what they want to do in this area. Talk to Brian M. about what to do. We cannot go in and ask the ITU for what they want to do for now and forever, but we need to ask about the implications of working together on this or handing off LSP labels. We need to understand what the implications of doing 1711 (what protocol modifications are required). [A lengthy and somewhat heated discussion ensued.] Scott asked for a show of hands to get a feel for the consensus of the room. Below are his three proposals and the WG response. 1. IESG/IETF tell IANA to approve draft-ota as a proposed standard to make number assignments. 5 hands. 2. Suggest that the ITU play with their solution and see what market does. Some support. 3. Send liason statement asking for further clarification asking for details of their current plan. Clear majority. Scott said that such a liaison statement would be sent. From owner-mpls@UU.NET Mon Apr 22 15:32:45 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09873 for ; Mon, 22 Apr 2002 15:32:44 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlso21769; Mon, 22 Apr 2002 19:30:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlso29591 for mpls-outgoing; Mon, 22 Apr 2002 19:30:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmlso29582 for ; Mon, 22 Apr 2002 19:30:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlsn22790 for ; Mon, 22 Apr 2002 19:29:32 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f259.law14.hotmail.com [64.4.20.134]) id QQmlsn22936 for ; Mon, 22 Apr 2002 19:29:32 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 22 Apr 2002 12:29:31 -0700 Received: from 198.242.58.71 by lw14fd.law14.hotmail.msn.com with HTTP; Mon, 22 Apr 2002 19:29:31 GMT X-Originating-IP: [198.242.58.71] From: "Raju Venkatraman" To: mpls@UU.NET Cc: eric.gray@sandburst.com Subject: ldp hold timer value Date: Mon, 22 Apr 2002 19:29:31 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Apr 2002 19:29:31.0794 (UTC) FILETIME=[06E4C720:01C1EA34] Sender: owner-mpls@UU.NET Precedence: bulk Hi, I've one question on LDP hello timer value. Can the hello hold timer value carried in the LDP hello messages be changed at run time (asusming that adjacencies/sessions are well established? RFC 3036 doesn't say anything explicitely. Thanks in adavnce. Raju _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-mpls@UU.NET Mon Apr 22 16:15:52 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11450 for ; Mon, 22 Apr 2002 16:15:51 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlsq19697; Mon, 22 Apr 2002 20:14:10 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlsq25325 for mpls-outgoing; Mon, 22 Apr 2002 20:13:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmlsq25202 for ; Mon, 22 Apr 2002 20:13:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmlsq19236 for ; Mon, 22 Apr 2002 20:12:44 GMT Received: from 21cn.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [61.140.60.248]) id QQmlsq17345 for ; Mon, 22 Apr 2002 20:12:24 GMT Received: from 21cn.com([10.2.1.8]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm453cc4a947; Tue, 23 Apr 2002 04:11:35 +0800 Received: from cmr1.ash.ops.us.uu.net([198.5.241.39]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm943cbfc246; Fri, 19 Apr 2002 10:09:35 +0800 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 QQmleu09583; Fri, 19 Apr 2002 02:11:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmleu14227 for mpls-outgoing; Fri, 19 Apr 2002 02:09: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 QQmleu14220 for ; Fri, 19 Apr 2002 02:09:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmleu11037 for ; Fri, 19 Apr 2002 02:09:09 GMT Received: from scutsv39.scut.edu.cn by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.38.193.39]) id QQmleu08661 for ; Fri, 19 Apr 2002 02:09:07 GMT Received: from letterbox.scut.edu.cn (mail.scut.edu.cn [202.38.193.69]) by scutsv39.scut.edu.cn (8.9.3/8.9.3) with ESMTP id KAA04848 for ; Fri, 19 Apr 2002 10:05:44 +0800 (CST) Received: from hchang ([202.38.197.20]) by letterbox.scut.edu.cn (8.9.3+Sun/8.9.3) with SMTP id JAA24930 for ; Fri, 19 Apr 2002 09:56:40 +0800 (CST) Message-Id: <200204190156.JAA24930@letterbox.scut.edu.cn> Date: Fri, 19 Apr 2002 10:11:15 +0800 From: hchang To: MPLS X-mailer: FoxMail 3.0 beta 2 [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, sorry to bother you:) i am a student pursueing my doctor degree in south China University of Technology. i want to do some research about Traffic Engineering such as QOS routing , Packet Scheduling Algorithms and Network planning etc. for my lab have not any project in this topic,so i am very puzzled and i can not make much progress for my study. can somebody give me some advice about the study? thank you very much!!!! From owner-mpls@UU.NET Mon Apr 22 17:38:00 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14801 for ; Mon, 22 Apr 2002 17:38:00 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlsw16424; Mon, 22 Apr 2002 21:36:29 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlsw22761 for mpls-outgoing; Mon, 22 Apr 2002 21:36: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 QQmlsw22705 for ; Mon, 22 Apr 2002 21:35:55 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 QQmlsw17657 for ; Mon, 22 Apr 2002 21:35:29 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 QQmlsw18503 for ; Mon, 22 Apr 2002 21:35:29 GMT Message-ID: <3CC4821F.50005@sandburst.com> Date: Mon, 22 Apr 2002 17:35:27 -0400 From: Eric Gray MIME-Version: 1.0 To: Raju Venkatraman Cc: mpls@UU.NET Subject: Re: ldp hold timer value References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Raju, At the very least, the effect of changing it is not defined. If, for example, you want to go to a shorter hold timer, the peer may not take any action to increase the frequency of sending alive messages. You wrote: > Hi, > > I've one question on LDP hello timer value. Can the hello hold timer > value carried in the LDP hello messages be changed at run time > (asusming that adjacencies/sessions are well established? RFC 3036 > doesn't say anything explicitely. > > Thanks in adavnce. > Raju > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > -- -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray From owner-mpls@UU.NET Mon Apr 22 20:50:18 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19423 for ; Mon, 22 Apr 2002 20:50:18 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmltj12664; Tue, 23 Apr 2002 00:49:12 GMT Received: by mail-control.ash.ops.us.uu.net id QQmltj10707 for mpls-outgoing; Tue, 23 Apr 2002 00:48:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmltj10702 for ; Tue, 23 Apr 2002 00:48:38 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 QQmltj04247 for ; Tue, 23 Apr 2002 00:48: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 QQmltj11125 for ; Tue, 23 Apr 2002 00:48:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA04691 for ; Mon, 22 Apr 2002 20:48:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA16699 for mpls@uu.net; Mon, 22 Apr 2002 20:48:03 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmltj10565 for ; Tue, 23 Apr 2002 00:46:51 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmltj14727 for ; Tue, 23 Apr 2002 00:46:49 GMT Received: from sj-msg-core-4.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-4.cisco.com [171.71.163.10]) id QQmltj08302 for ; Tue, 23 Apr 2002 00:46:48 GMT Received: from mira-sjc5-4.cisco.com (IDENT:mirapoint@mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3N0kmjR013306 for ; Mon, 22 Apr 2002 17:46:48 -0700 (PDT) Received: from cisco.com (dhcp-171-71-60-66.cisco.com [171.71.60.66]) by mira-sjc5-4.cisco.com (Mirapoint) with ESMTP id ADP96413; Mon, 22 Apr 2002 17:44:09 -0700 (PDT) Message-ID: <3CC4AEF6.9E4DDC8D@cisco.com> Date: Mon, 22 Apr 2002 17:46:46 -0700 From: hginjpal X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: UNSUBSCRIBE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit UNSUBSCRIBE From owner-mpls@UU.NET Tue Apr 23 03:20:09 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08286 for ; Tue, 23 Apr 2002 03:20:08 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmluj09069; Tue, 23 Apr 2002 07:17:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmluj07607 for mpls-outgoing; Tue, 23 Apr 2002 07:17: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 QQmluj07596 for ; Tue, 23 Apr 2002 07:17:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmluj27673 for ; Tue, 23 Apr 2002 07:16:09 GMT Received: from 21cn.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: [61.140.60.248]) id QQmluj06229 for ; Tue, 23 Apr 2002 07:16:04 GMT Received: from 21cn.com([10.2.1.2]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jmc3cc52cd3; Tue, 23 Apr 2002 15:15:17 +0800 Received: from cmr0.ash.ops.us.uu.net([198.5.241.38]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm3a3cc0745d; Fri, 19 Apr 2002 21:12:28 +0800 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 QQmlgm03453; Fri, 19 Apr 2002 13:14:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlgm26641 for mpls-outgoing; Fri, 19 Apr 2002 13:13: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 QQmlgm26636 for ; Fri, 19 Apr 2002 13:13: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 QQmlgm09698 for ; Fri, 19 Apr 2002 13:13:10 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f59.pav2.hotmail.com [64.4.37.59]) id QQmlgm00757 for ; Fri, 19 Apr 2002 13:13:10 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 19 Apr 2002 06:13:09 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 19 Apr 2002 13:13:09 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: rogerw@nordlink.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Definition of LIB and LFIB Date: Fri, 19 Apr 2002 13:13:09 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 13:13:09.0725 (UTC) FILETIME=[F3B140D0:01C1E7A3] Sender: owner-mpls@UU.NET Precedence: bulk Hi, >Roger Williams wrote: >Tze, you may be correct, but Cisco says otherwise, at least in their >training material. The LFIB is derived from the LIB, it is a subset of >the LIB. Also the LFIB contains no IP information whereas the LIB does >hold IP information. Cisco says the LFIB is generated when the actual >shortest path to a destination is chosen. Hence, in the LFIB there >will be one label pair for a destination (or FEC), whereas the LIB >holds all possible paths to the destination. > >All this is based on the MPLS Tech Essentials, AMVS, MPLS >Implementation, and VPNSC courses as issued by Cisco. Do I have any >*real* proof? Not really, I'm just passing on what they say and what >shows up in the various "show.." commands. Yeah, I must admit that you are right about it. From the way RFC3036 explains about LIB in section 2.7., it seems to agree with what you have just mentioned as it pointed out that when an LSR operates in downstream unsolicited mode, it would keep a collection of label binding info that it has learned in the LIB. When a label is needed, it will first consult the LIB to retrieve one to be used for forwarding (which I presume that it meant LFIB). I believe LIB is only significant when operating in such mode with liberal label retention mode combined. I also agree with Johannes that no clear defination of such terms are widely available. It is also not listed under MPLS Acronym Dictionary in http://mplsrc.com/dictionary.shtml web page. Thanks for this constructive argument. -Tze Ven. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Tue Apr 23 07:20:22 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12403 for ; Tue, 23 Apr 2002 07:20:17 -0400 (EDT) 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 QQmluz28999; Tue, 23 Apr 2002 11:18:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmluz19888 for mpls-outgoing; Tue, 23 Apr 2002 11:17:56 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmluz19883 for ; Tue, 23 Apr 2002 11:17:49 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 QQmluz25922 for ; Tue, 23 Apr 2002 11:17: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 QQmluz10557 for ; Tue, 23 Apr 2002 11:17:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA25891 for ; Tue, 23 Apr 2002 07:17:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA16494 for mpls@uu.net; Tue, 23 Apr 2002 07:17:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmluz19848 for ; Tue, 23 Apr 2002 11:16:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmluz02183 for ; Tue, 23 Apr 2002 11:15:06 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 QQmluz08156 for ; Tue, 23 Apr 2002 11:15: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 HAA12090; Tue, 23 Apr 2002 07:15:02 -0400 (EDT) Message-Id: <200204231115.HAA12090@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-05.txt Date: Tue, 23 Apr 2002 07:15:01 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LSP Hierarchy with Generalized MPLS TE Author(s) : K. Kompella, Y. Rekhter Filename : draft-ietf-mpls-lsp-hierarchy-05.txt Pages : 12 Date : 22-Apr-02 To improve scalability of Generalized MPLS (GMPLS) TE it may be useful to aggregate TE LSPs by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) an LSR creating a TE LSP, (b) the LSR forming a forwarding adjacency out of that LSP (by advertising this LSP as a TE link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-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-lsp-hierarchy-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-lsp-hierarchy-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: <20020422135459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsp-hierarchy-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsp-hierarchy-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020422135459.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Tue Apr 23 09:36:19 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17126 for ; Tue, 23 Apr 2002 09:36:18 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlvh16961; Tue, 23 Apr 2002 13:17:19 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvh11204 for mpls-outgoing; Tue, 23 Apr 2002 13:15:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmlvh11199 for ; Tue, 23 Apr 2002 13:15:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmlvh12765 for ; Tue, 23 Apr 2002 13:15:15 GMT Received: from smtp1.opnet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.opnet.com [141.156.71.6]) id QQmlvh14067 for ; Tue, 23 Apr 2002 13:15:15 GMT Received: from wtn10159.opnet.com (unverified) by smtp1.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Tue, 23 Apr 2002 09:15:04 -0400 Message-Id: <5.1.0.14.2.20020423090104.01f23160@mail.opnet.com> X-Sender: vjeyachandran@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 09:15:01 -0400 To: mpls@UU.NET From: Vinod Jeyachandran Subject: 2547 questions . . Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk (1) Does the BGP process on a PE maintain separate RIBs for each VRF configured? I guess BGP might need to do this even if it is not the PE-CE routing protocol (2) Do any of the other PE-CE routing protocol (e.g., RIP, OSPF) processes maintain separate routing tables on the PE? -Vinod From owner-mpls@UU.NET Tue Apr 23 10:06:08 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18333 for ; Tue, 23 Apr 2002 10:06:08 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlvk21923; Tue, 23 Apr 2002 14:05:05 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvk26259 for mpls-outgoing; Tue, 23 Apr 2002 14:04: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 QQmlvk26252 for ; Tue, 23 Apr 2002 14:04:41 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlvk00195 for ; Tue, 23 Apr 2002 14:03:43 GMT Received: from kcmso2.proxy.att.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso2.att.com [192.128.134.71]) id QQmlvk22729 for ; Tue, 23 Apr 2002 14:03:41 GMT Received: from attrh1i.attrh.att.com ([135.71.62.10]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g3NE3Ef11444 for ; Tue, 23 Apr 2002 09:03:32 -0500 (CDT) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029) id 3CBB4973000576C7; Tue, 23 Apr 2002 10:02:31 -0400 content-class: urn:content-classes:message Subject: RE: 2547 questions . . Date: Tue, 23 Apr 2002 10:02:47 -0400 Message-ID: <5C2CE23B27AC4D449F75AFF4560419F602842184@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: 2547 questions . . Thread-Index: AcHqyWFIqP4HxP74Sjq9DATUA3+52wAAqx7Q From: "Liu, Chia J (Charlie), ALCNS" To: "Vinod Jeyachandran" , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA18333 > (1) Does the BGP process on a PE maintain separate RIBs for each VRF > configured? I guess BGP might need to do this even if it is not the PE-CE > routing protocol [Liu, Chia J (Charlie), ALCNS] My understanding is, in addition to its own IP RIB, each VRF has its own CEF table, in Cisco implementation, to keep routing separate. However, I am not sure whether there is a separate BGP table in VRF. > (2) Do any of the other PE-CE routing protocol (e.g., RIP, OSPF) processes > maintain separate routing tables on the PE? [Liu, Chia J (Charlie), ALCNS] In the case of OSPF, it requires separate OSPF process ID, different ID from that used for SP's IGP, and VRF name, therefore, separate routing table. C.J. (Charlie) Liu AT&T IP Network Architecture & Routing Planning From owner-mpls@UU.NET Tue Apr 23 10:22:13 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19038 for ; Tue, 23 Apr 2002 10:22:13 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlvl14375; Tue, 23 Apr 2002 14:21:07 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvl07768 for mpls-outgoing; Tue, 23 Apr 2002 14:20: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 QQmlvl07750 for ; Tue, 23 Apr 2002 14:20: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 QQmlvl06755 for ; Tue, 23 Apr 2002 14:20:02 GMT Received: from mail.san.yahoo.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.san.yahoo.com [209.132.1.30]) id QQmlvl12540 for ; Tue, 23 Apr 2002 14:20:01 GMT Received: from [65.213.193.52] by mail.san.yahoo.com with HTTP; Tue, 23 Apr 2002 07:20:23 -0700 Date: Tue, 23 Apr 2002 10:20:23 -0400 Message-ID: <3CBB5DA900007AE7@mta08.san.yahoo.com> From: "Kavita Khanna" Subject: MPLS2002: Oct. 27-30, Wash, D.C. To: mpls@UU.NET MIME-Version: 1.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 KAA19038 Dear friends, We are delighted to inform you that MPLS2002 - the 5th Annual International Conference on MPLS, co-hosted by Worldcom and the Internetworking Lab of Isocore, and supported by Cable and Wireless, France Telecom, and NTT will be held at Omni Shoreham Hotel in Washington DC, October 27-29, 2002. The conference begins with parallel tutorial sessions on Sunday, October 27 and continues with full-day technical sessions on Monday and Tuesday, October 28 and 29. A series of public Interoperability demonstrations will follow on October 30 at the Internetworking Lab. Conference information, technical program, and other details, including the testing and public interoperability events are being made available at: http://www.mpls2002.com The topics and the technical program for MPLS 2002 will be selected by the Technical Program Committee of the conference. The TPC will solicit presentations, based on the topics discussed by the committee, from experts in the selected areas and will invite them for presentation at MPSL 2002. If you wish to bring out a particular topic or a contribution to the attention of the Technical Program Committee, please send your request to TPC@MPLS2002.com. Thanks. - Kavita From owner-mpls@UU.NET Tue Apr 23 10:27:32 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19316 for ; Tue, 23 Apr 2002 10:27:32 -0400 (EDT) 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 QQmlvl20018; Tue, 23 Apr 2002 14:18:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvl07598 for mpls-outgoing; Tue, 23 Apr 2002 14:18: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 QQmlvl07591 for ; Tue, 23 Apr 2002 14:18: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 QQmlvk11548 for ; Tue, 23 Apr 2002 14:14:04 GMT Received: from funnel.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmlvk06639 for ; Tue, 23 Apr 2002 14:14: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 KAA04562 for ; Tue, 23 Apr 2002 10:14:03 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA04952 for mpls@uu.net; Tue, 23 Apr 2002 10:14:03 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmlvk06983 for ; Tue, 23 Apr 2002 14:13:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmlvk15551 for ; Tue, 23 Apr 2002 14:11:07 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmlvk00326 for ; Tue, 23 Apr 2002 14:11:03 GMT Received: (qmail 16861 invoked by uid 104); 23 Apr 2002 14:11:03 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4197. . Clean. Processed in 0.505553 secs); 23 Apr 2002 14:11:03 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 23 Apr 2002 14:11:02 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g3NEAxp09675; Tue, 23 Apr 2002 07:10:59 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 07:11:02 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A729@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'George Swallow'" , mpls@UU.NET Subject: RE: Draft Minutes from MPLS in MPLS (Minneapolis that is) Date: Tue, 23 Apr 2002 07:11:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi George, I have the following comments on the minutes. 1) I think you need to mention that draft-pan-lsp-ping-03.txt was presented instead of draft-pan-lsp-ping-02.txt and that the agenda was wrong regarding this draft. 2) Regarding the OAM discussion, the ITU has asked for 1 reserved label not 2 labels. Yours, -Shahram > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Monday, April 22, 2002 3:19 PM > To: mpls@UU.NET > Subject: Draft Minutes from MPLS in MPLS (Minneapolis that is) > > > > > MPLS WG Meeting Minutes > > IETF #53 Minneapolis, March 2002 > > > Tuesday March 19 2002, 9.00 AM - 11.30 AM > > George introduced Loa Andersson (loa.andersson@utfors.se) as the new > WG co-chair. > > > Agenda bashing > > Loa introduced the agenda noting the addition of a discussion on the > ITU Liaison on the subject of MPLS OAM to be lead by Scott Bradner. > > > LDP to Draft Standard - Loa Anderssen > > Loa gave an update on status and presented representations. > > In order to advance to Draft Standard, we need to identify those > features of LDP which are actually implemented and in use. To that > end we would like to get information on all implementations of LDP. > > > Report on the FT/Graceful restart for LDP - Andy Malis > > Andy updated the group on the progress of integrating the two > proposals. Good progress has been made, but there is one major > technical issue to resolve. If sequence are carried in both > schemes this will simplify the implementation if someone needs > to build both schemes. It will also make it easier to for the > two schemes to interoperate. On the downside, it causes the > simplier solution to be more complicated. Simplification was the > original motivation for the proposal > > George (chair): Interoperability is important. If that can be > achieved, we should go for it. > > > Detecting Data Plane Liveliness in RSVP-TE - Kireeti Kompella > > > Kireeti presented the draft and closed with the comment that > although he would like to see it become a WG document eventually, he > suggested that perhaps people should just write some code for now. > > George (as a co-auther and chair) suggested that it would be good > for the workgroup to know what proposal folks were trying to > converge on. > > He then asked the room. There was consensus to make a WG document. > > > Fast Reroute Extensions to RSVP-TE for LSP Tunnels - Ping Pan > > > Ping gave an overview of recent updates to the draft. George > commented that the draft was pretty much technically stable at this > point but would benefit from an editorial scrub. > > > MPLS Traffic Engineering MIB for Fast Reroute - Riza Cetin > > > Riza Cetin gave an overview of the draft. > > George: Should we use this as a basis for the FRR MIB in this WG? > Room: Looks like consensus. > George: Should it be adopted as WG draft? > Room: Looks like consensus. > Bradner: Charter process check. Is this in the charter? > George: Yes. Fast-reroute is in the charter. A MIB for this > is therefore appropriate. > > > Backup Record Route for Fast Reroute Techniques in RSVP-TE - > Stefan de Cnodder > > > Stefan presented his draft and asked that it be accepted as WG > document. > > > George (not as chair): I am reluctant on both pieces presented. > In the backup RRO (BRRO), a lot of management information is being > moved around in RSVP. With regard to the backup ERO (BERO), we are > working on mechanisms for doing FRR in a unified way. I wouldn't > want to add this to the standard right now. We might want to > move this around in experimental track for now. > > Q1: If you have a failure, is there a signaling delay? > > Stefan: ERO is optional. If nodes cannot follow the path > suggested, then > they can take alternate one. If there is a failure, then you > can fall > back on the original path. > > Q2: BRRO is important for the MIB. Customers are interested > in seeing > all detours in one place. Otherwise we have to go along all > PLRs along > path. > > Ping: This same information might be encapsulated in RRO. > Also, should > get more operator feedback before we change the RSVP protocol. > > Yakov: This approach will not work well (or at all) with > inter-area TE. > Head end needs to have all link state information, so this > can become a > major bottleneck. > > Tom: Need more experience from operators to see if they want more > information in RSVP or want to just contact each node to get FRR > information. > > George: Need more experience with this approach and feedback from > operators before we can adopt this document. > > > A method for an Optimized Online Placement of MPLS Bypass Tunnels - > Jean-Louis le Roux > > > Jean-Louis presented his draft. He then asked that this be accepted > as a MPLS WG document. There was no consensus on this as > the work is > in a fairly early stage. > > George commented that he felt that this was important work and > encouraged Jean-Louis to continue it. > > Yakov: CCAMP is working on protection restoration. The > issue of shared > resources are being addressed there. There may be an > overlap between both > pieces of work. > > George: These mechanisms can be made generalized. Our charter > is to do specific MPLS work. (to Jean-Loius) Make sure that your > work is coordinated with CCAMP. > > > A Packet 1+1 Path Protection Service for MPLS Networks > > > Akber Qureshi > > Akber: Presentation. > > Loa: This seems almost too good. Could you address the drawbacks > associated with this proposal. Could you also address why this > proposal is MPLS-specific. This looks like something done in the > mid-80's for telephony. > > Akber: This is selection based on the packet level. This is > different > from traditional 1+1 because you are creating both as active and > selecting one based on an identifier. This scheme is > targeted towards > services that have QoS requirements. If you look at other > schemes that > use a sliding window scheme, you can tell which next packets are > accepted. The size of that window depends on how many > packets you can > process. > > Loa: I think we have to discuss this on the list a bit more. On the > drawbacks: cost is double-bandwidth allocation which might > be an issue > for a provider who has to book 2x. > > Akber: The cost with any 1+1 scheme is 2x booking. > > Mina: Mentioned that similar work is going on in ITU study > group 13 for > protection switching. There is a similar proposal: Y.1720. > > Akber: You need OAM packets to be sent if you are doing QoS > to detect > failures. > > Mina: OAM are two different things. That doesn't mean that > protection > switching will not work. > > Q1: How will this work if part of the net is going 1+1 and > the other not. > > Akber: The 1+1 is done on a segment basis, but maybe not > end-to-end. You > can do part 1+1 in the network. > > Q2: Do you envision this as part of some MPLS service to guarantee > bandwidth or packet loss. > > Akber: The benefit of the select is that you can have no > packet loss. > > Q3: Intriguing proposal. How can you trouble ticket failure > with this > approach? > > Akber: From an egress point of view, it is not detecting any > failure here. > > Q3: If something breaks, but the service servives, want to trouble > ticket. The order of the detection can be different from protection. > Bradner: I think this is a good demonstration of why we shouldn't do > this. Technical presentations should not be done because of time. We > need to do this on the list BEFORE the meeting so that we > can discuss > only open questions/issues at the meeting. > > George: At this point, we have exhausted our time. Take it > to the list. > > > Further considerations for Forwarding Adjacency LSPs - > Dimitri Papadimitriou: > > > Dimitri: Presentation. > > George: I think that this work is important to get out to > the community. > We are always open to enhancing existing work, but we need > to figure out > exactly which things you want to consider doing and see how it fits > into the charter. > > Dimitri: Since the existing MPLS document has passed last > call. Should > we open an new document? > > George: We don't want to just do a V2 of forwarding > adjacencies. We need to > examine what further functionality is required by the community. > > Dimitri: We had a list of issues seen by the community > today. Is this > list complete enough today to do work. > > George: We need to understand if this work is okay to stand > on its own > and then determine if these all need to go into the same > draft or into > multiple ones. First step: check for interest in community, > second: see > if it fits into the charter. > > > Hierarchical LSP > > > Heinrich Hummel > > Heinrich presented his draft. In the presentation he noted that his > ideas had evolved beyond what was captured in the first version. He > asked that members of the workgroup look for his updated draft and > requested that it be a subject of discussion on the maillist. > > George said that he would like to see more of the motivation and > requirements behind the draft. Heinrich replied that this had been > discussed in other workgroups, but that he would also summarize and > continue the discussion on the MPLS list. > > > RSVP-TE Extension for IPv4/IPv6 Dual Stacking PE under IPv4 MPLS > Core Environment - Hiroki Ishibashi > > > Hiroki: Presentation > > George pointed out that there is already a means of signaling the > contents of an LSP with the PID. There already exist ethertype > values for IPv4 and IPv6. > > Francois: I think that you know that ENGTrans working group > that talks > about Ipv6 over a Ipv4 backhone (with MPLS or without). > There is already > work being done elsewhere. The existing work is more general > because it > works with RSVP-TE and LDP, and covers routing and signaling > aspects. I > don't see why we need something more than what is already being done > without extensions to MPLS protocols. > > Hiroki: Don't want to talk about routing issue. EngTrans > need miultiple > extensions for BGP, but this approach doesn't need that. > This approach > doesn't talk about routing extensions. > > Francois: Need to talk about routing. Can talk about BGP tunneling > approach as well. Don't see why we need to change MPLS signaling to > forward Ipv6 packets over MPLS. > > Hiroki: I just want to augment the egress process of PE routers. > > Loa: It appears this may overlap with work going on elsewhere in the > IETF. I recommend that you go back and see if there is a delta to > add this here after you check with those working in the other space. > > > > Issues with MPLS OAM - Scott Bradner > > Scott introduced the topic: > > There has been a discussion on MPLS OAM recently (CCAMP > mailing list). I > want to talk about what the next steps to take are. We > (IETF) received a > liason statement from the ITU in February requesting two LSP label > values to support the ITU document Y.1711 (MPLS OAM). This > describes OAM > in the telephony sense rather than the IP sense. > > We have had two discussions going on. First, is this area of > Telephony > sense interest to the IETF. The consensus is reasonably > there, but that > there is more interest in dealing with MPLS in the arena of > transporting > IETF (CCAMP, MPLS). There are tools that existing in CCAMP/MPLS for > addressing this. > > I sent a message asking for direction to the mailing list. > Options: here > is your label values ITU, or should we work together on this > with ITU, > or should we work on it alone? > No votes for the latter. > > A couple people noticed that 1711 has hints that it itself is not a > standalone concept. To fulfill the concepts it will require > changes to > other IETF protocols (BGP, LDP, RSVP). This is a little bit > confusing. I > want to send a lieason statement back to ITU and ask for > specifics of > what they want to do in this area. Talk to Brian M. about > what to do. We > cannot go in and ask the ITU for what they want to do for now and > forever, but we need to ask about the implications of > working together > on this or handing off LSP labels. We need to understand what the > implications of doing 1711 (what protocol modifications are > required). > > [A lengthy and somewhat heated discussion ensued.] > > Scott asked for a show of hands to get a feel for the consensus of > the room. Below are his three proposals and the WG response. > > > 1. IESG/IETF tell IANA to approve draft-ota as a proposed standard > to make number assignments. > > 5 hands. > > 2. Suggest that the ITU play with their solution and see what > market does. > > Some support. > > 3. Send liason statement asking for further clarification asking > for details of their current plan. > > Clear majority. > > Scott said that such a liaison statement would be sent. > > > > > > > > > > > > From owner-mpls@UU.NET Tue Apr 23 11:02:57 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21364 for ; Tue, 23 Apr 2002 11:02:56 -0400 (EDT) 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 QQmlvo26084; Tue, 23 Apr 2002 15:01:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvo14074 for mpls-outgoing; Tue, 23 Apr 2002 15:01: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 QQmlvo14051 for ; Tue, 23 Apr 2002 15:01:08 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 QQmlvo27016 for ; Tue, 23 Apr 2002 15:00:05 GMT Received: from hongkong.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [202.84.12.155]) id QQmlvo06737 for ; Tue, 23 Apr 2002 15:00:01 GMT Received: from hongkong.com([10.1.9.103]) by hongkong.com(JetMail 2.5.3.0) with SMTP id jm23cc5cf74; Tue, 23 Apr 2002 14:39:02 -0000 Received: from host.secure4-hosting.net([209.239.41.31]) by hongkong.com(JetMail 2.5.3.0) with SMTP id jm1e3cc04739; Fri, 19 Apr 2002 15:55:11 -0000 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id g3JFI1l30264 for newsupdate@hongkong.com; Fri, 19 Apr 2002 11:18:01 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f X-Originating-IP: [155.245.254.253] From: "wu min" To: franklin.lian@francetelecom.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Date: Fri, 19 Apr 2002 14:51:34 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Apr 2002 14:51:35.0236 (UTC) FILETIME=[B3A6B840:01C1E7B1] Subject: [MPLS-OPS]: Re: Prefix Mismatch X-Mailing-List: archive/latest/3829 X-Loop: mpls-ops@mplsrc.com X-Auto-Forward: newsupdate@hongkong.com Sender: owner-mpls@UU.NET Precedence: bulk Hello again, > > Questions: > > ---------- > > 1. Does it mean R2 has to terminate LSP for FEC with 10.2/16 address >prefix > > by means of stripping the top label (the only label) and look into IP >header > > to determine its finer FEC and then label the packet again with the > > appropriate outgoing label. Is this true? > >My understanding of the RFC is the LSP for 10.2/16 stops at R2. The >the packet may or may not be label switched after R2. The last few lines of the RFC3031 snippet from my previous message reads, "....In this situation, packet P can be label Switched until it reaches R2, but since R2 has performed route aggregation, it must execute the best match algorithm to find P's FEC." It indicated that the best match algorithm must be executed to find the next appropriate FEC to be used for further label switching. In my opinion, surely this does not stop it from label switching further, right? > > 2. Suppose the LSP is being used as a tunnel that ends after R2 and if >the > > answer for my question (1) is true, then stripping the top label will >never > > reveal the IP header yet since there will still be 1 or more labels. Is >this > > situation valid? If so, can R2 still manage to terminate the LSP and >perform > > best match algorithm? If yes, then how? > >I don't think you can build an LSP beyond R2 in this case, in another >word, I don't know how you can have a tunnel that ends after R2. What I meant is, take for example an LSR with address 10.2.153.178 is a remote peer and the LSP in the example is the hop-by-hop routed tunnel used for this peering. Obviously here the LSR is after the LSR2. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com ------- 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 Tue Apr 23 11:19:39 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22473 for ; Tue, 23 Apr 2002 11:19:39 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlvp02102; Tue, 23 Apr 2002 15:18:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvp03764 for mpls-outgoing; Tue, 23 Apr 2002 15:18:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmlvp03757 for ; Tue, 23 Apr 2002 15:17:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlvp20279 for ; Tue, 23 Apr 2002 15:17:30 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 QQmlvp04851 for ; Tue, 23 Apr 2002 15:17:30 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA09509; Tue, 23 Apr 2002 11:17:25 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA12825; Tue, 23 Apr 2002 11:17:25 -0400 (EDT) Message-Id: <200204231517.LAA12825@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Kireeti Kompella , Markus Jork , Vach Kompella , David Charlap , mpls@UU.NET Subject: Re: PHP In-reply-to: Your message of Mon, 22 Apr 2002 10:28:31 -0400. <200204221428.KAA15091@erosen-u10.cisco.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 23 Apr 2002 11:17:25 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Kireeti> One could use the 'check first nibble' hack :-( It would be neater Kireeti> to use the L3PID. Eric> Well, I wouldn't want to have to set up a separate TE tunnel just to Eric> handle the IPv6 traffic, so I'd recommend the "check first nibble" Eric> hack. Actually, there is a real interoperability issue lurking here which we need to get clear on. In conjunction with php, "check first nibble" could mean either of the following: 1. The penultimate node pops the last label off the stack, creates a data link layer frame with IPv4 as the protocol type, and transmits the frame. The receiver of the frame checks the first nibble to see what the IP version is and treats the packet as IPv4 or IPv6 depending on the IP version. 2. The penultimate node pops the stack, checks the first nibble to see what the IP version is, and creates a data link layer frame with either IPv4 or IPv6 as the protocol type, depending on the value of the IP version field. What I meant was 1; I'm not sure which Kireeti meant. From owner-mpls@UU.NET Tue Apr 23 11:41:54 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23873 for ; Tue, 23 Apr 2002 11:41:53 -0400 (EDT) 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 QQmlvq27700; Tue, 23 Apr 2002 15:40:26 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvq05413 for mpls-outgoing; Tue, 23 Apr 2002 15:40:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmlvq05406 for ; Tue, 23 Apr 2002 15:40: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 QQmlvq13647 for ; Tue, 23 Apr 2002 15:38:30 GMT Received: from bridge.axiowave.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ppp-64-115-125-242.broadviewnet.net [64.115.125.242] (may be forged)) id QQmlvq04464 for ; Tue, 23 Apr 2002 15:38:29 GMT Message-ID: From: Dimitry Haskin To: "'erosen@cisco.com'" , Kireeti Kompella , Markus Jork , Vach Kompella , David Charlap , mpls@UU.NET Subject: RE: PHP Date: Tue, 23 Apr 2002 11:32:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk 1 is clearly not an option. IPv6 packets are required to be sent with its own link layer code and, as far I as I know, most existing IPv6 implementations rely on this fact. Dimitry > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Tuesday, April 23, 2002 11:17 AM > To: Kireeti Kompella; Markus Jork; Vach Kompella; David Charlap; > mpls@UU.NET > Subject: Re: PHP > > > Kireeti> One could use the 'check first nibble' hack :-( It > would be neater > Kireeti> to use the L3PID. > > Eric> Well, I wouldn't want to have to set up a separate TE > tunnel just to > Eric> handle the IPv6 traffic, so I'd recommend the "check > first nibble" > Eric> hack. > > Actually, there is a real interoperability issue lurking > here which we need > to get clear on. > > In conjunction with php, "check first nibble" could mean > either of the > following: > > 1. The penultimate node pops the last label off the stack, > creates a data > link layer frame with IPv4 as the protocol type, and > transmits the frame. > The receiver of the frame checks the first nibble to > see what the IP > version is and treats the packet as IPv4 or IPv6 > depending on the IP > version. > > 2. The penultimate node pops the stack, checks the first > nibble to see what > the IP version is, and creates a data link layer frame > with either IPv4 > or IPv6 as the protocol type, depending on the value of > the IP version > field. > > What I meant was 1; I'm not sure which Kireeti meant. > > > > From owner-mpls@UU.NET Tue Apr 23 11:51:05 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24363 for ; Tue, 23 Apr 2002 11:51:04 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlvr13970; Tue, 23 Apr 2002 15:48:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvr06533 for mpls-outgoing; Tue, 23 Apr 2002 15:48: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 QQmlvr06527 for ; Tue, 23 Apr 2002 15:48: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 QQmlvr23099 for ; Tue, 23 Apr 2002 15:48:09 GMT Received: from mailhost.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQmlvr09381 for ; Tue, 23 Apr 2002 15:48:09 GMT Received: from avici.com (swdev105.avici.com [10.2.21.105]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id g3NFm0W04811; Tue, 23 Apr 2002 11:48:00 -0400 (EDT) Message-Id: <200204231548.g3NFm0W04811@mailhost.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: erosen@cisco.com cc: mpls@UU.NET Subject: Re: PHP In-reply-to: Your message of "Tue, 23 Apr 2002 11:17:25 EDT." <200204231517.LAA12825@erosen-u10.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Apr 2002 11:47:54 -0400 Sender: owner-mpls@UU.NET Precedence: bulk > Kireeti> One could use the 'check first nibble' hack :-( It would be neater > Kireeti> to use the L3PID. > > Eric> Well, I wouldn't want to have to set up a separate TE tunnel just to > Eric> handle the IPv6 traffic, so I'd recommend the "check first nibble" > Eric> hack. > > Actually, there is a real interoperability issue lurking here which we need > to get clear on. > > In conjunction with php, "check first nibble" could mean either of the > following: > > 1. The penultimate node pops the last label off the stack, creates a data > link layer frame with IPv4 as the protocol type, and transmits the frame. > The receiver of the frame checks the first nibble to see what the IP > version is and treats the packet as IPv4 or IPv6 depending on the IP > version. > > 2. The penultimate node pops the stack, checks the first nibble to see what > the IP version is, and creates a data link layer frame with either IPv4 > or IPv6 as the protocol type, depending on the value of the IP version > field. > > What I meant was 1; I'm not sure which Kireeti meant. > I certainly would have expected option 2! Markus From owner-mpls@UU.NET Tue Apr 23 11:53:44 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24475 for ; Tue, 23 Apr 2002 11:53:44 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlvr24666; Tue, 23 Apr 2002 15:52:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvr06703 for mpls-outgoing; Tue, 23 Apr 2002 15:51:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmlvr06696 for ; Tue, 23 Apr 2002 15:51:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmlvr02877 for ; Tue, 23 Apr 2002 15:51:17 GMT Received: from smtp1.opnet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.opnet.com [141.156.71.6]) id QQmlvr17615 for ; Tue, 23 Apr 2002 15:51:17 GMT Received: from wtn10216.opnet.com (unverified) by smtp1.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Tue, 23 Apr 2002 11:51:08 -0400 Message-Id: <5.0.0.25.2.20020423114844.033bc6f0@mail.opnet.com> X-Sender: skalra@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 23 Apr 2002 11:51:11 -0400 To: mpls@UU.NET From: Sachin Kalra Subject: Memory at PE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Dear Group: I would appreciate if I can get answer to the following question regarding BGP/MPLS VPNs (RFC2547bis) I understand that PE router maintains a separate VRF table for each VPN site connected to it. I wanted to know if a PE also maintain separate RIBs for each VPN site, apart from its main Local RIB? Or, does it maintain only one single RIB? Actually, I was looking from the perspective of amount of memory required at PE, if it has to maintain many VRFs and many RIBs. Thanks for your response. Sachin Kalra From owner-mpls@UU.NET Tue Apr 23 12:05:11 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25165 for ; Tue, 23 Apr 2002 12:05:10 -0400 (EDT) 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 QQmlvs01289; Tue, 23 Apr 2002 16:03:17 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvs17687 for mpls-outgoing; Tue, 23 Apr 2002 16:02:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmlvs15391 for ; Tue, 23 Apr 2002 16:02: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 QQmlvs10826 for ; Tue, 23 Apr 2002 16:02:18 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 QQmlvs02167 for ; Tue, 23 Apr 2002 16:02:14 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 MAA12916; Tue, 23 Apr 2002 12:02:13 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA18772; Tue, 23 Apr 2002 12:02:13 -0400 (EDT) Message-Id: <200204231602.MAA18772@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Markus Jork cc: mpls@UU.NET Subject: Re: PHP In-reply-to: Your message of Tue, 23 Apr 2002 11:47:54 -0400. <200204231548.g3NFm0W04811@mailhost.avici.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 23 Apr 2002 12:02:13 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Markus> I certainly would have expected option 2! Well, the problem with option 2 is that MPLS forwarding likes to obtain the data link header as a result of the label lookup. So I would say that option 2 isn't really an option. From owner-mpls@UU.NET Tue Apr 23 12:33:29 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26644 for ; Tue, 23 Apr 2002 12:33:29 -0400 (EDT) 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 QQmlvu14471; Tue, 23 Apr 2002 16:31:58 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvu00979 for mpls-outgoing; Tue, 23 Apr 2002 16:31: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 QQmlvu00972 for ; Tue, 23 Apr 2002 16:31:21 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlvu21974 for ; Tue, 23 Apr 2002 16:30:24 GMT Received: from mailhost.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQmlvu12138 for ; Tue, 23 Apr 2002 16:30:24 GMT Received: from aatlas-lt.avici.com (b2-pc16.avici.com [10.2.100.36]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id g3NGUFW09718; Tue, 23 Apr 2002 12:30:15 -0400 (EDT) Message-Id: <5.1.0.14.2.20020423122745.01f8c850@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 23 Apr 2002 12:31:05 -0400 To: erosen@cisco.com From: Alia Atlas Subject: Re: PHP Cc: Markus Jork , mpls@UU.NET In-Reply-To: <200204231602.MAA18772@erosen-u10.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 12:02 PM 4/23/2002 -0400, Eric Rosen wrote: >Markus> I certainly would have expected option 2! > >Well, the problem with option 2 is that MPLS forwarding likes to obtain the >data link header as a result of the label lookup. So I would say that >option 2 isn't really an option. But when you remove the last label, it is then necessary to do some IP header processing such as TTL decrementing or, at the least, inheriting. Granted, there are different models (uniform, pipe, short-pipe) for handling TTL, but several of the models clearly presume that the LSR popping the last label must handle the TTL. To handle the TTL, the LSR must know what type of packet is underneath (IPv4 or IPv6 or...). Could you clarify how you'd envision the appropriate behavior here if the MPLS forwarding can't look underneath the MPLS shim header, when it is popping the last one? This isn't a limitation in the MPLS forwarding layer which I am familiar with. Thanks, Alia From owner-mpls@UU.NET Tue Apr 23 12:49:34 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27180 for ; Tue, 23 Apr 2002 12:49:33 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlvv04195; Tue, 23 Apr 2002 16:47:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvv02709 for mpls-outgoing; Tue, 23 Apr 2002 16:47:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmlvv02702 for ; Tue, 23 Apr 2002 16:47:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlvv27136 for ; Tue, 23 Apr 2002 16:46:29 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: zcars04f.nortelnetworks.com [47.129.242.57]) id QQmlvv11664 for ; Tue, 23 Apr 2002 16:46:28 GMT Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3NGk8M01403; Tue, 23 Apr 2002 12:46:08 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 12:46:09 -0400 Message-ID: <3549C09B853DD5119B540002A52CDD3402E36977@zcard0ka.ca.nortel.com> From: "Mina Azad" To: George Swallow , mpls@UU.NET Subject: RE: Draft Minutes from MPLS in MPLS (Minneapolis that is) Date: Tue, 23 Apr 2002 12:46:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EAE6.5D759850" 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_01C1EAE6.5D759850 Content-Type: text/plain; charset="ISO-8859-1" George, You missed my comments on MPLS OAM. 1) My response to Scott's comment on Y.1711 being "in the telephony sense rather than the IP sense" was that all e-mail and previous IETF discussions have been on IP-centric v.s. non-IP centric requirements/solutions for OAM. And Scott conceded. 2) In response to your comments on potential for signaling changes, I said In the current version of Y.1711, CV is enabled/disabled by means of configuration only. Y.1711 mentions enabling/disabling CVs via signaling as an ideal solution, but does not mandate it. I also mentioned that there are other mechanisms to enable/disable CVs. 3) On monitoring CV on all LSPs, I pointed out that Y.1711 does not mandate such thing but mentions that ideally, to detect all misbranching and mismatching defects CV must be monitored on all LSPs. Regards, Mina > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Monday, April 22, 2002 3:19 PM > To: mpls@UU.NET > Subject: Draft Minutes from MPLS in MPLS (Minneapolis that is) > > > > > MPLS WG Meeting Minutes > > IETF #53 Minneapolis, March 2002 > > > Tuesday March 19 2002, 9.00 AM - 11.30 AM > > George introduced Loa Andersson (loa.andersson@utfors.se) as the new > WG co-chair. > > > Agenda bashing > > Loa introduced the agenda noting the addition of a discussion on the > ITU Liaison on the subject of MPLS OAM to be lead by Scott Bradner. > > > LDP to Draft Standard - Loa Anderssen > > Loa gave an update on status and presented representations. > > In order to advance to Draft Standard, we need to identify those > features of LDP which are actually implemented and in use. To that > end we would like to get information on all implementations of LDP. > > > Report on the FT/Graceful restart for LDP - Andy Malis > > Andy updated the group on the progress of integrating the two > proposals. Good progress has been made, but there is one major > technical issue to resolve. If sequence are carried in both > schemes this will simplify the implementation if someone needs > to build both schemes. It will also make it easier to for the > two schemes to interoperate. On the downside, it causes the > simplier solution to be more complicated. Simplification was the > original motivation for the proposal > > George (chair): Interoperability is important. If that can be > achieved, we should go for it. > > > Detecting Data Plane Liveliness in RSVP-TE - Kireeti Kompella > > > Kireeti presented the draft and closed with the comment that > although he would like to see it become a WG document eventually, he > suggested that perhaps people should just write some code for now. > > George (as a co-auther and chair) suggested that it would be good > for the workgroup to know what proposal folks were trying to > converge on. > > He then asked the room. There was consensus to make a WG document. > > > Fast Reroute Extensions to RSVP-TE for LSP Tunnels - Ping Pan > > > Ping gave an overview of recent updates to the draft. George > commented that the draft was pretty much technically stable at this > point but would benefit from an editorial scrub. > > > MPLS Traffic Engineering MIB for Fast Reroute - Riza Cetin > > > Riza Cetin gave an overview of the draft. > > George: Should we use this as a basis for the FRR MIB in this WG? > Room: Looks like consensus. > George: Should it be adopted as WG draft? > Room: Looks like consensus. > Bradner: Charter process check. Is this in the charter? > George: Yes. Fast-reroute is in the charter. A MIB for this > is therefore appropriate. > > > Backup Record Route for Fast Reroute Techniques in RSVP-TE - > Stefan de Cnodder > > > Stefan presented his draft and asked that it be accepted as WG > document. > > > George (not as chair): I am reluctant on both pieces presented. > In the backup RRO (BRRO), a lot of management information is being > moved around in RSVP. With regard to the backup ERO (BERO), we are > working on mechanisms for doing FRR in a unified way. I wouldn't > want to add this to the standard right now. We might want to > move this around in experimental track for now. > > Q1: If you have a failure, is there a signaling delay? > > Stefan: ERO is optional. If nodes cannot follow the path > suggested, then > they can take alternate one. If there is a failure, then you > can fall > back on the original path. > > Q2: BRRO is important for the MIB. Customers are interested > in seeing > all detours in one place. Otherwise we have to go along all > PLRs along > path. > > Ping: This same information might be encapsulated in RRO. > Also, should > get more operator feedback before we change the RSVP protocol. > > Yakov: This approach will not work well (or at all) with > inter-area TE. > Head end needs to have all link state information, so this > can become a > major bottleneck. > > Tom: Need more experience from operators to see if they want more > information in RSVP or want to just contact each node to get FRR > information. > > George: Need more experience with this approach and feedback from > operators before we can adopt this document. > > > A method for an Optimized Online Placement of MPLS Bypass Tunnels - > Jean-Louis le Roux > > > Jean-Louis presented his draft. He then asked that this be accepted > as a MPLS WG document. There was no consensus on this as > the work is > in a fairly early stage. > > George commented that he felt that this was important work and > encouraged Jean-Louis to continue it. > > Yakov: CCAMP is working on protection restoration. The > issue of shared > resources are being addressed there. There may be an > overlap between both > pieces of work. > > George: These mechanisms can be made generalized. Our charter > is to do specific MPLS work. (to Jean-Loius) Make sure that your > work is coordinated with CCAMP. > > > A Packet 1+1 Path Protection Service for MPLS Networks > > > Akber Qureshi > > Akber: Presentation. > > Loa: This seems almost too good. Could you address the drawbacks > associated with this proposal. Could you also address why this > proposal is MPLS-specific. This looks like something done in the > mid-80's for telephony. > > Akber: This is selection based on the packet level. This is > different > from traditional 1+1 because you are creating both as active and > selecting one based on an identifier. This scheme is > targeted towards > services that have QoS requirements. If you look at other > schemes that > use a sliding window scheme, you can tell which next packets are > accepted. The size of that window depends on how many > packets you can > process. > > Loa: I think we have to discuss this on the list a bit more. On the > drawbacks: cost is double-bandwidth allocation which might > be an issue > for a provider who has to book 2x. > > Akber: The cost with any 1+1 scheme is 2x booking. > > Mina: Mentioned that similar work is going on in ITU study > group 13 for > protection switching. There is a similar proposal: Y.1720. > > Akber: You need OAM packets to be sent if you are doing QoS > to detect > failures. > > Mina: OAM are two different things. That doesn't mean that > protection > switching will not work. > > Q1: How will this work if part of the net is going 1+1 and > the other not. > > Akber: The 1+1 is done on a segment basis, but maybe not > end-to-end. You > can do part 1+1 in the network. > > Q2: Do you envision this as part of some MPLS service to guarantee > bandwidth or packet loss. > > Akber: The benefit of the select is that you can have no > packet loss. > > Q3: Intriguing proposal. How can you trouble ticket failure > with this > approach? > > Akber: From an egress point of view, it is not detecting any > failure here. > > Q3: If something breaks, but the service servives, want to trouble > ticket. The order of the detection can be different from protection. > Bradner: I think this is a good demonstration of why we shouldn't do > this. Technical presentations should not be done because of time. We > need to do this on the list BEFORE the meeting so that we > can discuss > only open questions/issues at the meeting. > > George: At this point, we have exhausted our time. Take it > to the list. > > > Further considerations for Forwarding Adjacency LSPs - > Dimitri Papadimitriou: > > > Dimitri: Presentation. > > George: I think that this work is important to get out to > the community. > We are always open to enhancing existing work, but we need > to figure out > exactly which things you want to consider doing and see how it fits > into the charter. > > Dimitri: Since the existing MPLS document has passed last > call. Should > we open an new document? > > George: We don't want to just do a V2 of forwarding > adjacencies. We need to > examine what further functionality is required by the community. > > Dimitri: We had a list of issues seen by the community > today. Is this > list complete enough today to do work. > > George: We need to understand if this work is okay to stand > on its own > and then determine if these all need to go into the same > draft or into > multiple ones. First step: check for interest in community, > second: see > if it fits into the charter. > > > Hierarchical LSP > > > Heinrich Hummel > > Heinrich presented his draft. In the presentation he noted that his > ideas had evolved beyond what was captured in the first version. He > asked that members of the workgroup look for his updated draft and > requested that it be a subject of discussion on the maillist. > > George said that he would like to see more of the motivation and > requirements behind the draft. Heinrich replied that this had been > discussed in other workgroups, but that he would also summarize and > continue the discussion on the MPLS list. > > > RSVP-TE Extension for IPv4/IPv6 Dual Stacking PE under IPv4 MPLS > Core Environment - Hiroki Ishibashi > > > Hiroki: Presentation > > George pointed out that there is already a means of signaling the > contents of an LSP with the PID. There already exist ethertype > values for IPv4 and IPv6. > > Francois: I think that you know that ENGTrans working group > that talks > about Ipv6 over a Ipv4 backhone (with MPLS or without). > There is already > work being done elsewhere. The existing work is more general > because it > works with RSVP-TE and LDP, and covers routing and signaling > aspects. I > don't see why we need something more than what is already being done > without extensions to MPLS protocols. > > Hiroki: Don't want to talk about routing issue. EngTrans > need miultiple > extensions for BGP, but this approach doesn't need that. > This approach > doesn't talk about routing extensions. > > Francois: Need to talk about routing. Can talk about BGP tunneling > approach as well. Don't see why we need to change MPLS signaling to > forward Ipv6 packets over MPLS. > > Hiroki: I just want to augment the egress process of PE routers. > > Loa: It appears this may overlap with work going on elsewhere in the > IETF. I recommend that you go back and see if there is a delta to > add this here after you check with those working in the other space. > > > > Issues with MPLS OAM - Scott Bradner > > Scott introduced the topic: > > There has been a discussion on MPLS OAM recently (CCAMP > mailing list). I > want to talk about what the next steps to take are. We > (IETF) received a > liason statement from the ITU in February requesting two LSP label > values to support the ITU document Y.1711 (MPLS OAM). This > describes OAM > in the telephony sense rather than the IP sense. > > We have had two discussions going on. First, is this area of > Telephony > sense interest to the IETF. The consensus is reasonably > there, but that > there is more interest in dealing with MPLS in the arena of > transporting > IETF (CCAMP, MPLS). There are tools that existing in CCAMP/MPLS for > addressing this. > > I sent a message asking for direction to the mailing list. > Options: here > is your label values ITU, or should we work together on this > with ITU, > or should we work on it alone? > No votes for the latter. > > A couple people noticed that 1711 has hints that it itself is not a > standalone concept. To fulfill the concepts it will require > changes to > other IETF protocols (BGP, LDP, RSVP). This is a little bit > confusing. I > want to send a lieason statement back to ITU and ask for > specifics of > what they want to do in this area. Talk to Brian M. about > what to do. We > cannot go in and ask the ITU for what they want to do for now and > forever, but we need to ask about the implications of > working together > on this or handing off LSP labels. We need to understand what the > implications of doing 1711 (what protocol modifications are > required). > > [A lengthy and somewhat heated discussion ensued.] > > Scott asked for a show of hands to get a feel for the consensus of > the room. Below are his three proposals and the WG response. > > > 1. IESG/IETF tell IANA to approve draft-ota as a proposed standard > to make number assignments. > > 5 hands. > > 2. Suggest that the ITU play with their solution and see what > market does. > > Some support. > > 3. Send liason statement asking for further clarification asking > for details of their current plan. > > Clear majority. > > Scott said that such a liaison statement would be sent. > > > > > > > > > > > > > ------_=_NextPart_001_01C1EAE6.5D759850 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Draft Minutes from MPLS in MPLS (Minneapolis that = is)

George,

You missed my comments on MPLS OAM.
1) My response to Scott's comment on Y.1711 being = "in the telephony sense rather than the IP sense" was that = all e-mail and previous IETF discussions have been on IP-centric v.s. = non-IP centric requirements/solutions for OAM. And Scott = conceded.

2) In response to your comments on potential for = signaling changes, I said
   In the current version of Y.1711, CV is = enabled/disabled by means of configuration only. Y.1711 mentions = enabling/disabling CVs via signaling as an ideal solution, but does not = mandate it. I also mentioned that there are other mechanisms to = enable/disable CVs.

3) On monitoring CV on all LSPs, I pointed out that = Y.1711 does not mandate such thing but mentions that ideally, to detect = all misbranching and mismatching defects CV must be monitored on all = LSPs.

Regards,

Mina


> -----Original Message-----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Monday, April 22, 2002 3:19 PM
> To: mpls@UU.NET
> Subject: Draft Minutes from MPLS in MPLS = (Minneapolis that is)
>
>
>
>
>          = ;            = ;  MPLS WG Meeting Minutes 
>
>          = ;         IETF #53 Minneapolis, = March 2002
> 
> 
> Tuesday March 19 2002, 9.00 AM - 11.30 = AM
> 
>   George introduced Loa Andersson = (loa.andersson@utfors.se) as the new
>   WG co-chair.
>
>
> Agenda bashing
> 
>   Loa introduced the agenda noting = the addition of a discussion on the
>   ITU Liaison on the subject of MPLS = OAM to be lead by Scott Bradner.
> 
>
> LDP to Draft Standard  -  Loa = Anderssen
> 
>   Loa gave an update on status and = presented representations.
> 
>   In order to advance to Draft = Standard, we need to identify those
>   features of LDP which are actually = implemented and in use.  To that
>   end we would like to get = information on all implementations of LDP.
>
>
> Report on the FT/Graceful restart for LDP  = -  Andy Malis
>
>   Andy updated the group on the = progress of integrating the two
>   proposals.  Good progress has = been made, but there is one major
>   technical issue to resolve.  = If sequence are carried in both
>   schemes this will simplify the = implementation if someone needs
>   to build both schemes. It will also = make it easier to for the
>   two schemes to interoperate.  = On the downside, it causes the
>   simplier solution to be more = complicated.  Simplification was the
>   original motivation for the = proposal
>
>   George (chair): Interoperability is = important.  If that can be
>   achieved, we should go for = it.
> 
>
> Detecting Data Plane Liveliness in = RSVP-TE  -  Kireeti Kompella
>   = <draft-pan-lsp-ping-02.txt>
> 
>   Kireeti presented the draft and = closed with the comment that
>   although he would like to see it = become a WG document eventually, he
>   suggested that perhaps people = should just write some code for now.
>
>   George (as a co-auther and chair) = suggested that it would be good
>   for the workgroup to know what = proposal folks were trying to
>   converge on.
>
>   He then asked the room.  There = was consensus to make a WG document.
> 
>
> Fast Reroute Extensions to RSVP-TE for LSP = Tunnels  -  Ping Pan
>   = <draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt>
>
>   Ping gave an overview of recent = updates to the draft.  George
>   commented that the draft was pretty = much technically stable at this
>   point but would benefit from an = editorial scrub.
> 
>
> MPLS Traffic Engineering MIB for Fast = Reroute  -  Riza Cetin
>  = <draft-cetin-mpls-fastreroute-mib-00.txt>
> 
>   Riza Cetin gave an overview of the = draft.
>
>   George: Should we use this as a = basis for the FRR MIB in this WG?
>   Room: Looks like consensus.
>   George:  Should it be adopted = as WG draft?
>   Room: Looks like consensus.
>   Bradner: Charter process check. Is = this in the charter?
>   George: Yes.  Fast-reroute is = in the charter.  A MIB for this
>   is therefore appropriate.
> 
>
> Backup Record Route for Fast Reroute Techniques = in RSVP-TE  -
>  Stefan de Cnodder
>   <draft-decnodder-mpls-ero-rro-fas= treroute-00.txt>
> 
>   Stefan presented his draft and = asked that it be accepted as WG
>   document.
>
>
>  George (not as chair): I am reluctant on = both pieces presented.
>  In the backup RRO (BRRO), a lot of = management information is being
>  moved around in RSVP.  With regard = to the backup ERO (BERO), we are
>  working on mechanisms for doing FRR in a = unified way.  I wouldn't
>  want to add this to the standard right = now.  We might want to
>  move this around in experimental track = for now.
> 
>  Q1: If you have a failure, is there a = signaling delay?
>
>  Stefan: ERO is optional. If nodes cannot = follow the path
> suggested, then
>  they can take alternate one. If there is = a failure, then you
> can fall
>  back on the original path.
>
>  Q2: BRRO is important for the MIB. = Customers are interested
> in seeing
>  all detours in one place. Otherwise we = have to go along all
> PLRs along
>  path.
>
>  Ping: This same information might be = encapsulated in RRO.
> Also, should
>  get more operator feedback before we = change the RSVP protocol.
>
>  Yakov: This approach will not work well = (or at all) with
> inter-area TE.
>  Head end needs to have all link state = information, so this
> can become a
>  major bottleneck.
>
>  Tom: Need more experience from operators = to see if they want more
>  information in RSVP or want to just = contact each node to get FRR
>  information.
>
>  George: Need more experience with this = approach and feedback from
>  operators before we can adopt this = document.
> 
> 
> A method for an Optimized Online Placement of = MPLS Bypass Tunnels  -
>  Jean-Louis le Roux
>   = <draft-leroux-mpls-bypass-placement-00.txt>
>
>   Jean-Louis presented his = draft.  He then asked that this be accepted
>   as a MPLS WG document.  There = was no consensus on this as
> the work is
>   in a fairly early stage.
>
>   George commented that he felt that = this was important work and
>   encouraged Jean-Louis to continue = it.
>  
>   Yakov: CCAMP is working on = protection restoration.   The
> issue of shared
>   resources are being addressed there.= There may be an
> overlap between both
>   pieces of work.
>
>   George: These mechanisms can be = made generalized. Our charter
>   is to do specific MPLS work. (to = Jean-Loius) Make sure that your
>   work is coordinated with = CCAMP.
> 
>
> A Packet 1+1 Path Protection Service for MPLS = Networks
>  = <draft-nagarajan-ccamp-mpls-packet-protection-00.txt>
> 
>  Akber Qureshi
>
>  Akber: Presentation.
>
>  Loa: This seems almost too good. Could = you address the drawbacks
>  associated with this proposal. Could you = also address why this
>  proposal is MPLS-specific. This looks = like something done in the
>  mid-80's for telephony.
>
>  Akber: This is selection based on the = packet level. This is
> different
>  from traditional 1+1 because you are = creating both as active and
>  selecting one based on an identifier. = This scheme is
> targeted towards
>  services that have QoS requirements. If = you look at other
> schemes that
>  use a sliding window scheme, you can tell = which next packets are
>  accepted. The size of that window depends = on how many
> packets you can
>  process.
>
>  Loa: I think we have to discuss this on = the list a bit more. On the
>  drawbacks: cost is double-bandwidth = allocation which might
> be an issue
>  for a provider who has to book 2x.
>
>  Akber: The cost with any 1+1 scheme is 2x = booking.
>
>  Mina: Mentioned that similar work is = going on in ITU study
> group 13 for
>  protection switching. There is a similar = proposal: Y.1720.
>
>  Akber: You need OAM packets to be sent if = you are doing QoS
> to detect
>  failures.
>
>  Mina: OAM are two different things. That = doesn't mean that
> protection
>  switching will not work.
>
>  Q1: How will this work if part of the net = is going 1+1 and
> the other not.
>
>  Akber: The 1+1 is done on a segment = basis, but maybe not
> end-to-end. You
>  can do part 1+1 in the network.
>
>  Q2: Do you envision this as part of some = MPLS service to guarantee
>  bandwidth or packet loss.
>
>  Akber: The benefit of the select is that = you can have no
> packet loss.
>
>  Q3: Intriguing proposal. How can you = trouble ticket failure
> with this
>  approach?
>
>  Akber: From an egress point of view, it = is not detecting any
> failure here.
>
>  Q3: If something breaks, but the service = servives, want to trouble
>  ticket. The order of the detection can be = different from protection.
>  Bradner: I think this is a good = demonstration of why we shouldn't do
>  this. Technical presentations should not = be done because of time. We
>  need to do this on the list BEFORE the = meeting so that we
> can discuss
>  only open questions/issues at the = meeting.
>
>  George: At this point, we have exhausted = our time. Take it
> to the list.
> 
>
> Further considerations for Forwarding Adjacency = LSPs -
>  Dimitri Papadimitriou:
>  = <draft-vandenbosch-mpls-fa-considerations-00.txt>
>
>  Dimitri: Presentation.
>
>  George: I think that this work is = important to get out to
> the community.
>  We are always open to enhancing existing = work, but we need
> to figure out
>  exactly which things you want to consider = doing and see how it fits
>  into the charter.
>
>  Dimitri: Since the existing MPLS document = has passed last
> call. Should
>  we open an new document?
>
>  George: We don't want to just do a V2 of = forwarding
> adjacencies. We need to
>  examine what further functionality is = required by the community.
>
>  Dimitri: We had a list of issues seen by = the community
> today. Is this
>  list complete enough today to do = work.
>
>  George: We need to understand if this = work is okay to stand
> on its own
>  and then determine if these all need to = go into the same
> draft or into
>  multiple ones. First step: check for = interest in community,
> second: see
>  if it fits into the charter.
> 
> 
> Hierarchical LSP
>  = <draft-hummel-mpls-hierarchical-lsp-00.txt>
>
>   Heinrich Hummel
> 
>   Heinrich presented his draft.  = In the presentation he noted that his
>   ideas had evolved beyond what was = captured in the first version.  He
>   asked that members of the workgroup = look for his updated draft and
>   requested that it be a subject of = discussion on the maillist.
> 
>   George said that he would like to = see more of the motivation and
>   requirements behind the = draft.  Heinrich replied that this had been
>   discussed in other workgroups, but = that he would also summarize and
>   continue the discussion on the MPLS = list.
> 
>
> RSVP-TE Extension for IPv4/IPv6 Dual Stacking = PE under IPv4 MPLS
>  Core Environment  -  Hiroki = Ishibashi
>   = <draft-ishii-rsvp-te-ipv4-ipv6-extension-00.txt>
> 
>  Hiroki: Presentation
>
>  George pointed out that there is already = a means of signaling the
>  contents of an LSP with the PID.  = There already exist ethertype
>  values for IPv4 and IPv6.
> 
>  Francois: I think that you know that = ENGTrans working group
> that talks
>  about Ipv6 over a Ipv4 backhone (with = MPLS or without).
> There is already
>  work being done elsewhere. The existing = work is more general
> because it
>  works with RSVP-TE and LDP, and covers = routing and signaling
> aspects. I
>  don't see why we need something more than = what is already being done
>  without extensions to MPLS = protocols.
> 
>  Hiroki: Don't want to talk about routing = issue. EngTrans
> need miultiple
>  extensions for BGP, but this approach = doesn't need that.
> This approach
>  doesn't talk about routing = extensions.
> 
>  Francois: Need to talk about routing. Can = talk about BGP tunneling
>  approach as well. Don't see why we need = to change MPLS signaling to
>  forward Ipv6 packets over MPLS.
>
>  Hiroki: I just want to augment the egress = process of PE routers.
>
>  Loa: It appears this may overlap with = work going on elsewhere in the
>  IETF.  I recommend that you go back = and see if there is a delta to
>  add this here after you check with those = working in the other space.
>
> 
>
> Issues with MPLS OAM  -  Scott = Bradner
> 
>  Scott introduced the topic:
>
>  There has been a discussion on MPLS OAM = recently (CCAMP
> mailing list). I
>  want to talk about what the next steps to = take are. We
> (IETF) received a
>  liason statement from the ITU in February = requesting two LSP label
>  values to support the ITU document Y.1711 = (MPLS OAM). This
> describes OAM
>  in the telephony sense rather than the IP = sense.
> 
>  We have had two discussions going on. = First, is this area of
> Telephony
>  sense interest to the IETF. The consensus = is reasonably
> there, but that
>  there is more interest in dealing with = MPLS in the arena of
> transporting
>  IETF (CCAMP, MPLS). There are tools that = existing in CCAMP/MPLS for
>  addressing this.
> 
>  I sent a message asking for direction to = the mailing list.
> Options: here
>  is your label values ITU, or should we = work together on this
> with ITU,
>  or should we work on it alone?
>  No votes for the latter.
> 
>  A couple people noticed that 1711 has = hints that it itself is not a
>  standalone concept. To fulfill the = concepts it will require
> changes to
>  other IETF protocols (BGP, LDP, RSVP). = This is a little bit
> confusing. I
>  want to send a lieason statement back to = ITU and ask for
> specifics of
>  what they want to do in this area. Talk = to Brian M. about
> what to do. We
>  cannot go in and ask the ITU for what = they want to do for now and
>  forever, but we need to ask about the = implications of
> working together
>  on this or handing off LSP labels. We = need to understand what the
>  implications of doing 1711 (what protocol = modifications are
> required).
> 
>  [A lengthy and somewhat heated discussion = ensued.]
> 
>  Scott asked for a show of hands to get a = feel for the consensus of
>  the room.  Below are his three = proposals and the WG response.
> 
>
>  1.  IESG/IETF tell IANA to approve = draft-ota as a proposed standard
>      to make number = assignments.
> 
>      5 hands.
> 
>  2.  Suggest that the ITU play with = their solution and see what
>      market = does.
> 
>      Some = support.
> 
>  3.  Send liason statement asking for = further clarification asking
>      for details of = their current plan.
>
>      Clear = majority.
>
> Scott said that such a liaison statement would = be sent.
>
>
>
>
>
>
>
>
>
>
>
>
>

------_=_NextPart_001_01C1EAE6.5D759850-- From owner-mpls@UU.NET Tue Apr 23 12:51:33 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27282 for ; Tue, 23 Apr 2002 12:51:32 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlvv16900; Tue, 23 Apr 2002 16:50:16 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvv02908 for mpls-outgoing; Tue, 23 Apr 2002 16:49: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 QQmlvv02886 for ; Tue, 23 Apr 2002 16:49:37 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 QQmlvv04743 for ; Tue, 23 Apr 2002 16:49:34 GMT Received: from kcmso2.proxy.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: kcmso2.att.com [192.128.134.71]) id QQmlvv15782 for ; Tue, 23 Apr 2002 16:49:32 GMT Received: from attrh1i.attrh.att.com ([135.71.62.10]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g3NGnQf00067 for ; Tue, 23 Apr 2002 11:49:27 -0500 (CDT) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029) id 3CBB49730005C419; Tue, 23 Apr 2002 12:48:58 -0400 content-class: urn:content-classes:message Subject: RE: Memory at PE Date: Tue, 23 Apr 2002 12:49:16 -0400 Message-ID: <5C2CE23B27AC4D449F75AFF4560419F602842185@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Memory at PE Thread-Index: AcHq35dagpWwgr27Qn2WIumWaXnSagABEo4w From: "Liu, Chia J (Charlie), ALCNS" To: "Sachin Kalra" , Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA27282 Sachin, There are two aspects: * Memory Usage in GRP/RSP: In the lab, we saw data of ~935 bytes per VPN prefix in VRF, compared to 500-600 bytes per internet prefix in global routing table. I heard there is additional 60KB-70KB overhead per VRF. * Memory Usage in Line Card: We are particularly concerned about the VRF memory overhead in PSA/TLU of E2 16xOC-3 in GSR. It looks like the number is different in different IOS releases. I am interested in knowing if anyone has number on this. Thanx. C.J. (Charlie) Liu > -----Original Message----- > From: Sachin Kalra [SMTP:skalra@opnet.com] > Sent: Tuesday, April 23, 2002 11:51 AM > To: mpls@UU.NET > Subject: Memory at PE > > Dear Group: > > I would appreciate if I can get answer to the following question regarding > BGP/MPLS VPNs (RFC2547bis) > > I understand that PE router maintains a separate VRF table for each VPN > site connected to it. I wanted to know if a PE also maintain separate RIBs > for each VPN site, apart from its main Local RIB? Or, does it maintain only > one single RIB? > > Actually, I was looking from the perspective of amount of memory required > at PE, if it has to maintain many VRFs and many RIBs. > > Thanks for your response. > Sachin Kalra From owner-mpls@UU.NET Tue Apr 23 13:02:29 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27663 for ; Tue, 23 Apr 2002 13:02:29 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlvw02031; Tue, 23 Apr 2002 17:01:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvw08167 for mpls-outgoing; Tue, 23 Apr 2002 17:00: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 QQmlvw08136 for ; Tue, 23 Apr 2002 17:00:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlvw20803 for ; Tue, 23 Apr 2002 17:00:45 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 QQmlvw00769 for ; Tue, 23 Apr 2002 17:00:44 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 NAA17254; Tue, 23 Apr 2002 13:00:44 -0400 (EDT) Received: from localhost (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA26001; Tue, 23 Apr 2002 13:00:44 -0400 (EDT) Message-Id: <200204231700.NAA26001@erosen-u10.cisco.com> X-Authentication-Warning: erosen-u10.cisco.com: erosen owned process doing -bs To: Alia Atlas cc: Markus Jork , mpls@UU.NET Subject: Re: PHP In-reply-to: Your message of Tue, 23 Apr 2002 12:31:05 -0400. <5.1.0.14.2.20020423122745.01f8c850@mailhost.avici.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Tue, 23 Apr 2002 13:00:44 -0400 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Eric> the problem with option 2 is that MPLS forwarding likes to obtain the Eric> data link header as a result of the label lookup Alia> But when you remove the last label, it is then necessary to do some IP Alia> header processing such as TTL decrementing or, at the least, Alia> inheriting. You are correct, but that does not contradict my statement. It's clear that performing the TTL processing when you pop off the last label requires manipulating the IP header. But the MPLS specs say nothing about using the contents of the header to help choose the outgoing data link header, except in the case where the label lookup indicates that the LSR itself is the packet's next hop. So an implementation that is compliant with the existing specifications cannot necessarily be relied upon to perform option 2 when a single LSP carries both IPv4 and IPv6, and PHP is used. From owner-mpls@UU.NET Tue Apr 23 13:14:28 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28027 for ; Tue, 23 Apr 2002 13:14:28 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlvw17945; Tue, 23 Apr 2002 17:13:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvw25710 for mpls-outgoing; Tue, 23 Apr 2002 17:12: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 QQmlvw25705 for ; Tue, 23 Apr 2002 17:12:36 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlvw12611 for ; Tue, 23 Apr 2002 17:12:03 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmlvw17204 for ; Tue, 23 Apr 2002 17:12:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA18170 for ; Tue, 23 Apr 2002 13:12:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA27535 for mpls@uu.net; Tue, 23 Apr 2002 13:12:01 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmlvw25554 for ; Tue, 23 Apr 2002 17:11: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 QQmlvw07658 for ; Tue, 23 Apr 2002 17:10:28 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmlvw15040 for ; Tue, 23 Apr 2002 17:10:27 GMT Received: (qmail 16667 invoked by uid 104); 23 Apr 2002 17:10:26 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4197. . Clean. Processed in 0.540565 secs); 23 Apr 2002 17:10:26 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 23 Apr 2002 17:10:25 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g3NHAJp11525; Tue, 23 Apr 2002 10:10:19 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 10:10:23 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A730@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'erosen@cisco.com'" , Kireeti Kompella , Markus Jork , Vach Kompella , David Charlap , mpls@UU.NET Subject: RE: PHP Date: Tue, 23 Apr 2002 10:10:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Eric, > 1. The penultimate node pops the last label off the stack, > creates a data > link layer frame with IPv4 as the protocol type, and > transmits the frame. > The receiver of the frame checks the first nibble to > see what the IP > version is and treats the packet as IPv4 or IPv6 > depending on the IP > version. > > 2. The penultimate node pops the stack, checks the first > nibble to see what > the IP version is, and creates a data link layer frame > with either IPv4 > or IPv6 as the protocol type, depending on the value of > the IP version > field. > > What I meant was 1; I'm not sure which Kireeti meant. > Both these methods have architectural problems. The first method uses IPV4 L3PID for an IPV6 packet, which could create interoperability issues as was mentioned by some one on the list. The second method is not compliant with MPLS PHP (as you mentioned), since only label lookup should be done at penultimate node. There are 2 architecturally correct solutions: 3) Use a different LSP for IPV4 a IPV6. In that case the PHP knows what version of IP is the payload, without looking at IP header. 4) If you like to multiplex IPV4 and IPv6 in a single LSP, then use IPV4 and IPV6 explicit null labels. -Shahram From owner-mpls@UU.NET Tue Apr 23 13:19:03 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28206 for ; Tue, 23 Apr 2002 13:19:03 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlvx23911; Tue, 23 Apr 2002 17:17:30 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvx26620 for mpls-outgoing; Tue, 23 Apr 2002 17:17: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 QQmlvx26604 for ; Tue, 23 Apr 2002 17:17:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlvw05085 for ; Tue, 23 Apr 2002 17:14:36 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 QQmlvw19988 for ; Tue, 23 Apr 2002 17:14:36 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 g3NHEZT45084; Tue, 23 Apr 2002 10:14:35 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g3NHEZR04804; Tue, 23 Apr 2002 10:14:35 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Tue, 23 Apr 2002 10:14:35 -0700 (PDT) From: Kireeti Kompella To: Eric Rosen cc: Subject: Re: PHP In-Reply-To: <200204231517.LAA12825@erosen-u10.cisco.com> Message-ID: <20020423100333.P4695-100000@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Tue, 23 Apr 2002, Eric Rosen wrote: > 1. The penultimate node pops the last label off the stack, creates a data > link layer frame with IPv4 as the protocol type, and transmits the frame. > The receiver of the frame checks the first nibble to see what the IP > version is and treats the packet as IPv4 or IPv6 depending on the IP > version. > > 2. The penultimate node pops the stack, checks the first nibble to see what > the IP version is, and creates a data link layer frame with either IPv4 > or IPv6 as the protocol type, depending on the value of the IP version > field. > > What I meant was 1; I'm not sure which Kireeti meant. I meant 2. One could do 1, I suppose, but that pushes the hack to the IP stack. 2 keeps the hack within the MPLS stack. Kireeti. From owner-mpls@UU.NET Tue Apr 23 13:28:14 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28512 for ; Tue, 23 Apr 2002 13:28:14 -0400 (EDT) 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 QQmlvx09515; Tue, 23 Apr 2002 17:27:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvx27414 for mpls-outgoing; Tue, 23 Apr 2002 17:26:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmlvx27409 for ; Tue, 23 Apr 2002 17:26:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlvx02619 for ; Tue, 23 Apr 2002 17:26:01 GMT Received: from mailhost.avici.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQmlvx05584 for ; Tue, 23 Apr 2002 17:26:01 GMT Received: from avici.com (swdev105.avici.com [10.2.21.105]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id g3NHPkW16123; Tue, 23 Apr 2002 13:25:46 -0400 (EDT) Message-Id: <200204231725.g3NHPkW16123@mailhost.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: erosen@cisco.com cc: Alia Atlas , mpls@UU.NET Subject: Re: PHP In-reply-to: Your message of "Tue, 23 Apr 2002 13:00:44 EDT." <200204231700.NAA26001@erosen-u10.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Apr 2002 13:25:40 -0400 Sender: owner-mpls@UU.NET Precedence: bulk > Eric> the problem with option 2 is that MPLS forwarding likes to obtain the > Eric> data link header as a result of the label lookup > > Alia> But when you remove the last label, it is then necessary to do some IP > Alia> header processing such as TTL decrementing or, at the least, > Alia> inheriting. > > You are correct, but that does not contradict my statement. > > It's clear that performing the TTL processing when you pop off the last > label requires manipulating the IP header. But the MPLS specs say nothing > about using the contents of the header to help choose the outgoing data link > header, except in the case where the label lookup indicates that the LSR > itself is the packet's next hop. > > So an implementation that is compliant with the existing specifications > cannot necessarily be relied upon to perform option 2 when a single LSP > carries both IPv4 and IPv6, and PHP is used. Ok, but we are talking about bending the rules of existing specifications anyway (signaling IPv4 but sending both, IPv4 and IPv6). If you want to play tricks like that, you better have the hardware to handle it (including correct TTL processing). Markus From owner-mpls@UU.NET Tue Apr 23 14:22:29 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00351 for ; Tue, 23 Apr 2002 14:22:29 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlwb10558; Tue, 23 Apr 2002 18:21:01 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlwb22633 for mpls-outgoing; Tue, 23 Apr 2002 18:20:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmlwb22628 for ; Tue, 23 Apr 2002 18:20:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmlwb16009 for ; Tue, 23 Apr 2002 18: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 QQmlwb06305 for ; Tue, 23 Apr 2002 18:18:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA24084 for ; Tue, 23 Apr 2002 14:18:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA06064 for mpls@uu.net; Tue, 23 Apr 2002 14:18:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmlwb22508 for ; Tue, 23 Apr 2002 18:17:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlwb26257 for ; Tue, 23 Apr 2002 18:15:07 GMT Received: from father.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQmlwb10245 for ; Tue, 23 Apr 2002 18:15:06 GMT Received: (qmail 22220 invoked by uid 104); 23 Apr 2002 18:15:05 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4197. . Clean. Processed in 0.440901 secs); 23 Apr 2002 18:15:05 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 23 Apr 2002 18:15:04 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g3NIEup23427; Tue, 23 Apr 2002 11:14:56 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 11:15:00 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A731@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: Shahram Davari , "'erosen@cisco.com'" , Kireeti Kompella , Markus Jork , Vach Kompella , David Charlap , mpls@UU.NET Subject: RE: PHP Date: Tue, 23 Apr 2002 11:14:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi, Please ignore the 4th option that I mentioned, because it adds one level to the label stack and therefore defeats the purpose of the PHP. BTW, is it possible to get a new PID= IP (v4+v6) from IANA so that IPv4 and IPV6 could be multiplexed in the same LSP? -Shahram > -----Original Message----- > From: Shahram Davari > Sent: Tuesday, April 23, 2002 1:10 PM > To: 'erosen@cisco.com'; Kireeti Kompella; Markus Jork; Vach Kompella; > David Charlap; mpls@UU.NET > Subject: RE: PHP > > > Eric, > > > 1. The penultimate node pops the last label off the stack, > > creates a data > > link layer frame with IPv4 as the protocol type, and > > transmits the frame. > > The receiver of the frame checks the first nibble to > > see what the IP > > version is and treats the packet as IPv4 or IPv6 > > depending on the IP > > version. > > > > 2. The penultimate node pops the stack, checks the first > > nibble to see what > > the IP version is, and creates a data link layer frame > > with either IPv4 > > or IPv6 as the protocol type, depending on the value of > > the IP version > > field. > > > > What I meant was 1; I'm not sure which Kireeti meant. > > > > Both these methods have architectural problems. The first method > uses IPV4 L3PID for an IPV6 packet, which could create > interoperability > issues as was mentioned by some one on the list. The second method is > not compliant with MPLS PHP (as you mentioned), since only label > lookup should be done at penultimate node. > > There are 2 architecturally correct solutions: > > 3) Use a different LSP for IPV4 a IPV6. In that case the PHP > knows what > version of IP is the payload, without looking at IP header. > > 4) If you like to multiplex IPV4 and IPv6 in a single LSP, > then use IPV4 > and IPV6 explicit null labels. > > -Shahram > From owner-mpls@UU.NET Tue Apr 23 15:33:27 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03771 for ; Tue, 23 Apr 2002 15:33:22 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlwg22676; Tue, 23 Apr 2002 19:32:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlwg19487 for mpls-outgoing; Tue, 23 Apr 2002 19:31:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmlwg19480 for ; Tue, 23 Apr 2002 19:31:20 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlwg27278 for ; Tue, 23 Apr 2002 19:31:13 GMT Received: from relais-inet-05.francetelecom.fr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: relais-inet-02.francetelecom.fr [195.6.68.191]) id QQmlwg20927 for ; Tue, 23 Apr 2002 19:31:13 GMT Received: from [193.248.188.48] by relais-filtrant-05.francetelecom.fr with ESMTP for mpls@UU.NET; Tue, 23 Apr 2002 21:31:12 +0200 Received: from fedft01a.francetelecom.fr by relais-filtrant-05.francetelecom.fr with ESMTP for mpls@UU.NET; Tue, 23 Apr 2002 21:31:11 +0200 Received: from [193.249.133.11] by fedft01a.francetelecom.fr with ESMTP for mpls@UU.NET; Tue, 23 Apr 2002 21:31:10 +0200 Received: from francetelecom.com ([10.239.24.38]) by smtp2.smtpft.francetelecom.fr (Netscape Messaging Server 4.15) with ESMTP id GV1CVX01.94E; Tue, 23 Apr 2002 21:31:09 +0200 Message-Id: <3CC5B6B6.4900B6FA@francetelecom.com> Date: Tue, 23 Apr 2002 15:32:06 -0400 From: "LIAN Franklin FTLD/IAP" Organization: France Telecom Long Distance X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,zh-CN,zh,zh-TW MIME-Version: 1.0 To: wu min CC: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Re: Prefix Mismatch References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit wu min wrote: > > The last few lines of the RFC3031 snippet from my previous message reads, > "....In this situation, packet P can be label Switched until it reaches R2, > but since R2 has performed route aggregation, it must execute the best match > algorithm to find P's FEC." > > It indicated that the best match algorithm must be executed to find the next > appropriate FEC to be used for further label switching. In my opinion, > surely this does not stop it from label switching further, right? > Yes, it is true that it does not stop it from being "switched" from R2, but you will have TWO (2) LSPs involved in this case. The LSP_1 stops at R2, and LSP_2 starts at R2. When the packet is processed at R2, it is NOT a simple label swapping, there is route lookup or label pushing involved if necessary. Wish this can help Zidan > > > 2. Suppose the LSP is being used as a tunnel that ends after R2 and if > >the > > > answer for my question (1) is true, then stripping the top label will > >never > > > reveal the IP header yet since there will still be 1 or more labels. Is > >this > > > situation valid? If so, can R2 still manage to terminate the LSP and > >perform > > > best match algorithm? If yes, then how? > > > >I don't think you can build an LSP beyond R2 in this case, in another > >word, I don't know how you can have a tunnel that ends after R2. > > What I meant is, take for example an LSR with address 10.2.153.178 is a > remote peer and the LSP in the example is the hop-by-hop routed tunnel used > for this peering. Obviously here the LSR is after the LSR2. > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > ------- > 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 Tue Apr 23 20:52:01 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10655 for ; Tue, 23 Apr 2002 20:52:01 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlxb20985; Wed, 24 Apr 2002 00:50:45 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlxb29159 for mpls-outgoing; Wed, 24 Apr 2002 00:50: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 QQmlxb29149 for ; Wed, 24 Apr 2002 00:50: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 QQmlxb07075 for ; Wed, 24 Apr 2002 00:49:46 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f123.pav2.hotmail.com [64.4.37.123]) id QQmlxb15196 for ; Wed, 24 Apr 2002 00:49:46 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Apr 2002 17:49:45 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 24 Apr 2002 00:49:45 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: franklin.lian@francetelecom.com Cc: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Re: [MPLS-OPS]: Re: Prefix Mismatch Date: Wed, 24 Apr 2002 00:49:45 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Apr 2002 00:49:45.0655 (UTC) FILETIME=[EDA90C70:01C1EB29] Sender: owner-mpls@UU.NET Precedence: bulk Hi Zidan, Please see my text below following your comment. >wu min wrote: > > > > The last few lines of the RFC3031 snippet from my previous message >reads, > > "....In this situation, packet P can be label Switched until it reaches >R2, > > but since R2 has performed route aggregation, it must execute the best >match > > algorithm to find P's FEC." > > > > It indicated that the best match algorithm must be executed to find the >next > > appropriate FEC to be used for further label switching. In my opinion, > > surely this does not stop it from label switching further, right? > > > >Yes, it is true that it does not stop it from being "switched" from R2, >but you will have TWO (2) LSPs involved in this case. The LSP_1 stops >at R2, and LSP_2 starts at R2. When the packet is processed at R2, >it is NOT a simple label swapping, there is route lookup or label >pushing involved if necessary. Great! We've come to common understanding now. We both agree that R2 stop switching, but handle packet at layer 3 instead to figure out how to forward it (as explained in RFC3031). Let's come to the scenario that I have been trying to convey: Given that R0 is a label distribution peer to R1 and R1, R2 and R3 are connected and configured as the previous example. Let R3 advertises to R2 the three different prefixes and R2 advertises to R1 the aggregation of those prefixes exactly as what are described in the previous example. Let R1 advertises to R0 address prefix 10.2/16 (the only prefix that it got from R2). Now assuming that R0 initiates remote peering with another router Rn which has an address that falls within the range of one or two of the prefixes, say 10.2.153.178. Additionally, R0 has chosen not to initiate 'explicitly routed tunnel' to Rn when engaging in remote peering but rather depends on 'hop-by-hop routed tunnel' that naturally formed through routing information. Obviously here, the tunnel is the LSP that is formed by the FEC address prefixes advertised. This is illustrated below: 10.2.153/23 10.2.154/23 *10.2/16 10.2/16 R0------>R1----->R2------->R3---...-->Rn *10.2/16 *10.2/16 (10.2.153/23) (10.2.154/23) The address prefix(es) shown at each node are those received from individual successive neighbouring peer. The asterisk that precedes an address prefix indicates the FEC for the LSP that is used as tunnel. Since R2 aggregates the prefixes (shown in brackets) into 10.2/16, thus the LSP stops there. In this case R2 must pop label and process every packet that originated from the LSP at layer 3 for further forwarding decision. Note that the LSP termination at R2 is not known to R1 and R0. From R0 standpoint, the LSP continues beyond R2 until Rn. Since the LSP is used as tunnel by R0, every 'tunneled packet' will have 2 labels. When R2 received this tunneled packet, it will pop the outer label as a normal process to inspect IP header for further forwarding decision. However this will definitely fail since there is still an inner label. Furthermore, the IP address will not contain Rn address, but its ultimate destination address which may not fall within the given prefixes' range. Even R2 awares (which will never happen) of the second label, the IP header information is not valid at least in the context described in the RFC. The example given in the RFC involves a normal packet forwarding with a single label. This will not cause any problem at R2 since label popping will immediately reveals the IP header and the IP destination address will match one or more of the prefixes. But in the tunnel case, it would fail. Here I am not sure my tunnel example is valid or not. If it does, then how does R2 overcome this? -Tze Ven _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-mpls@UU.NET Wed Apr 24 05:08:42 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28041 for ; Wed, 24 Apr 2002 05:08:37 -0400 (EDT) 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 QQmlyi29068; Wed, 24 Apr 2002 09:07:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlyi14346 for mpls-outgoing; Wed, 24 Apr 2002 09:06:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmlyi14319 for ; Wed, 24 Apr 2002 09:06:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlyi04405 for ; Wed, 24 Apr 2002 09:06: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 QQmlyi27162 for ; Wed, 24 Apr 2002 09:06:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA04312 for ; Wed, 24 Apr 2002 05:06:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id FAA16282 for mpls@uu.net; Wed, 24 Apr 2002 05:06:01 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmlxu05457 for ; Wed, 24 Apr 2002 05:31:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlxu26967 for ; Wed, 24 Apr 2002 05:30:36 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmlxu21987 for ; Wed, 24 Apr 2002 05:30:34 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id BAA51887; Wed, 24 Apr 2002 01:25:59 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200204240525.BAA51887@workhorse.fictitious.org> To: David Charlap cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: SE style in optical neyworks In-reply-to: Your message of "Mon, 15 Apr 2002 15:58:29 EDT." <3CBB30E5.F76B0159@marconi.com> Date: Wed, 24 Apr 2002 01:25:58 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3CBB30E5.F76B0159@marconi.com>, David Charlap writes: > Sudheer Dharanikota wrote: > > David Charlap wrote: > >> > >> What's the point? > >> > >> In an optical network, you are signaling wavelengths or time > >> slices. How could you conceivably have two time-slices share > >> resources? Or two wavelengths? > > > > Only to imply that a time-slice can be allocated to one of the > > *backup* paths when a primary path fails. > > That's not the definition of SE style. SE style may be used for many > things other than signaling backup paths. > > To assume that SE style can only be used in the way you want is > unwarranted. You may end up with undefined behavior if you do. > > If you need a mechanism for explicitly indicating which LSPs serve as > backups for others, then you should use a mechanism that is meant to do > this. If none exists, then you should define one and use this working > group to make it into a standard. > > Unilaterally assigning a new and undocumented meaning to an existing > construct is never a good idea. > > -- David Delayed response... What SE is used for in MPLS/TE is always to indicate that resources are shared. It doesn't signal any kind of reroute but the sharing is among the primary and backup in local protection beyond the merge point (not applicable to fully disjoint paths from ingress to egress) or among the primary and another path that will be used in a make-before-break fashion. It makes perfect sense to reuse the same lambdas on some legs to overlap in make-before-break fashion and turn off one laser at the ingress (for lambdas) and turn on another and have a (very near) no impact reroute that does not require a complete teardown before the setup. It also makes sense to do a local repair this way. It also may be applicable to time slices if there was a way to send nothing on time slice on the one path not in use at any given time in the transition. This would be like sending empty sonet frames on one of two OCx and having an intermediate pick the non-empty frames from either or two ingress OCx and send them out another OCx. This is very APS like if used for repair in the TDM context. This clearly involves too much inspection for burst switching and is more like what a router or ADM can do and less like what optical burst switching can do. IMHO, the UNI is useless so direct discussion to OIF. Or devnull or anywhere but the IETF. Curtis From owner-mpls@UU.NET Wed Apr 24 08:20:47 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01197 for ; Wed, 24 Apr 2002 08:20:46 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlyv25028; Wed, 24 Apr 2002 12:19:27 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlyv03526 for mpls-outgoing; Wed, 24 Apr 2002 12:19: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 QQmlyv03521 for ; Wed, 24 Apr 2002 12:19:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmlyv11004 for ; Wed, 24 Apr 2002 12:18:49 GMT From: neil.2.harrison@bt.com Received: from mbibipnt08.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmlyv14023 for ; Wed, 24 Apr 2002 12:18:49 GMT Received: by mbibipnt08.hc.bt.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Apr 2002 13:18:59 +0100 Message-ID: To: mpls@UU.NET Subject: comments on nagarajan-ccamp-mpls-packet-protection-00.txt Date: Wed, 24 Apr 2002 13:18:24 +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 IAA01197 I noted George S asked for comments on nagarajan-ccamp-mpls-packet-protection-00.txt to be taken on the list in his notes of the MPLS WG mtg.....so here are some 1st pass comments: 1 I noted a criticism in the mtg notes that it uses 2x the BW of one LSP....well yes it is 1+1 so I'd say that's obvious. However, I think we have to place any such criticism of BW efficiency in context. For example, if I compare it with LDP as a server layer to (say) rfc2547 VPNs, then because there is no relationship between a pkt's up-state QoS forwarding treatment and a pkt's survivability requirements (vis-à-vis same or different DS-coded pkts of *any* VPN), operators are forced to over-engineer such networks and *hope* (because there is no assurance) that traffic survives under failures....a factor of 2x over-engineering on some DS classes is not uncommon. Hence, the point I want to make here is that using BW wisely to reduce/remove a complexity/problem is one thing (which I support), but asking an operator to throw BW at a problem that should not really exist (because the application/problem in question has only been partially defined, eg just the connectivity bit of VPNs) is something else. So any criticism of BW efficiency only makes sense against the context of the application/problem it is addressing IMO. 2 I noted in section 6.2 you address the practical issue of carrying the sequence number (if implemented in such a way), and suggest that it sits directly below the shim header (1st 4 octets of payload). This is possible. 2 things spring to mind here: - IMO you really need some way to be sure you have correct A-B connectivity....and this includes defects where perhaps another LSP, LSP X say, gets merged unintentionally into the LSP Y between A-B. In this case you would get some unexpected results looking for a sequence number in such mismerged pkts. I would therefore recommend you run a periodic data-plane LSP CV OAM flow on each of the LSPs to verify correct connectivity, since these contain unique LSP source identifiers and will detect all defects, not just simple breaks (and if following Y.1711, it will also invoke the correct consequent actions on failure). - You will need to configure the LSP sink points to expect LSPs containing sequence numbers. This can be done manually of course, but you may want to consider some auto signalling config...and I later noted that you have considered this aspect in section 6.4 wrt RSVP say. A further way to achieve this signalling function could be by the use of special OAM pkts....and its something being considered by those who are working on MPLS OAM in Y.1711 for automatic CV activation/deactivation. 3 Given that the scheme you are proposing seems to fit where one has a critical LSP connectivity application (like a control/management-channel say), then I think you ought to be running some solid OAM fault detection/handling function on it in any case....I gave one example above wrt mismerging and seeing arbitrary sequence number effects. Moreover, I noted later you gave an algorithm for processing the sequence number implementation case at the egress that is associated with a sliding window. I would suggest that this needs coupling with defect detection mechanisms in order to make the correct processing decisions.....one obvious cut-off point is when you would consider one of the LSPs to have become 'unavailable' (this is also defined in Y.1711). 4 Final comment....simple ideas are often the best, and this idea is certainly simple in principle. I think it could find excellent uses for critical applications. regards, Neil From owner-mpls@UU.NET Wed Apr 24 09:23:19 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03455 for ; Wed, 24 Apr 2002 09:23:19 -0400 (EDT) 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 QQmlyz21831; Wed, 24 Apr 2002 13:21:48 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlyz29456 for mpls-outgoing; Wed, 24 Apr 2002 13:21:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmlyz29449 for ; Wed, 24 Apr 2002 13:21:29 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 QQmlyz06262 for ; Wed, 24 Apr 2002 13:20:29 GMT Received: from mgw.cosinecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.88.104.199]) id QQmlyz05286 for ; Wed, 24 Apr 2002 13:20:26 GMT Received: from exchsrv2.cosinecom.com (exchsrv2.cosinecom.com [172.17.3.10]) by mgw.cosinecom.com (Mirapoint) with ESMTP id ABJ12781; Wed, 24 Apr 2002 06:20:02 -0700 (PDT) Received: by exchsrv2.cosinecom.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Apr 2002 06:17:25 -0700 Received: from awalker1-w2k.cosinecom.com (AWALKER1-W2K [172.17.145.244]) by imchub1.cosinecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HK7DQQF5; Wed, 24 Apr 2002 06:21:59 -0700 Message-ID: <5.1.0.14.2.20020423174134.0354aff8@exchsrv5.cosinecom.com> From: Andrew Walker To: Sachin Kalra , "Liu, Chia J (Charlie), ALCNS" Cc: mpls@UU.NET Subject: RE: Memory at PE Date: Wed, 24 Apr 2002 06:18:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EB93.033AF580" 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_01C1EB93.033AF580 Content-Type: text/plain; charset="iso-8859-1" Sachin, You have asked a very important question as it gets to the heart of the scalability of a PE deployment. In a traditional router architecture (e.g. Cisco, Juniper, Unisphere), although FIBs are distributed out to individual line cards, the RIB is kept on a central module. There is only one RIB and therefore all updates whether for the Local RIB, or for each VRF must go through this RIB. Obviously the RIB is divided into pieces so as to keep the VRFs separate, but the whole thing is bounded by the amount of memory and CPU cycles available to the routing plane. Prior to BGP/MPLS VPNs, update performance of the RIB was not a large concern, so the fact that it was still centralized did not matter. However BGP/MPLS VPNs place a new burden on traditional routers. VRFs are by definition specific to a particular subscriber network and must only contain routes specific to that network; traditional routers partition their RIBs and FIBs in order to maintain this separation. This can become a problem for traditional routers since the RIB is maintained in a central module and serviced by a single processor. These centralized resources (memory and CPU) become a bottleneck as the number of subscribers increases, especially when the PE-CE connections use chatty routing protocols such as RIP or computationally intensive routing protocols such as OSPF. For example, when using OSPF as the CE-PE routing protocol, a Cisco router can only sustain approx 20 to 30 instances per device. With a distributed architecture, like the CoSine IPSX platform, you can have more than 1500 such instances per blade. In a truly distributed device architecture, the RIBs are distributed with the VRFs, and new resources (CPUs and Memory) can be added as needed. Thus you avoid the limitations imposed by traditional routing architectures. The base architecture of a PE device is absolutely critical in determining how many BGP/MPLS VPNs the device can handle. Trying to retrofit an existing architecture for a new network design can lead to limitations that purposely designed hardware doesn't suffer from. -------- At 12:49 PM 4/23/2002 -0400, Liu, Chia J (Charlie), ALCNS wrote: >Sachin, > >There are two aspects: >* Memory Usage in GRP/RSP: In the lab, we saw data of ~935 bytes per VPN prefix in VRF, compared to 500-600 bytes per internet prefix in global routing table. I heard there is additional 60KB-70KB overhead per VRF. >* Memory Usage in Line Card: We are particularly concerned about the VRF memory overhead in PSA/TLU of E2 16xOC-3 in GSR. It looks like the number is different in different IOS releases. I am interested in knowing if anyone has number on this. Thanx. > >C.J. (Charlie) Liu > > >> -----Original Message----- >> From: Sachin Kalra [SMTP:skalra@opnet.com] >> Sent: Tuesday, April 23, 2002 11:51 AM >> To: mpls@UU.NET >> Subject: Memory at PE >> >> Dear Group: >> >> I would appreciate if I can get answer to the following question regarding >> BGP/MPLS VPNs (RFC2547bis) >> >> I understand that PE router maintains a separate VRF table for each VPN >> site connected to it. I wanted to know if a PE also maintain separate RIBs >> for each VPN site, apart from its main Local RIB? Or, does it maintain only >> one single RIB? >> >> Actually, I was looking from the perspective of amount of memory required >> at PE, if it has to maintain many VRFs and many RIBs. >> >> Thanks for your response. >> Sachin Kalra ############################################################################ ########################## 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_01C1EB93.033AF580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Memory at PE

Sachin,

You have asked a very important question as it gets = to the
heart of the scalability of a PE deployment. In a = traditional router
architecture (e.g. Cisco, Juniper, Unisphere), = although FIBs are
distributed out to individual line cards, the RIB is = kept on a central
module. There is only one RIB and therefore all = updates whether for the
Local RIB, or for each VRF must go through this RIB. =
Obviously the RIB is divided into pieces so as to = keep the
VRFs separate, but the whole thing is bounded by the =
amount of memory and CPU cycles available to the = routing plane.
Prior to BGP/MPLS VPNs, update performance of the = RIB was
not a large concern, so the fact that it was still = centralized did not matter.

However BGP/MPLS VPNs place a new burden on = traditional routers.
VRFs are by definition specific to a particular = subscriber network and
must only contain routes specific to that network; = traditional routers
partition their RIBs and FIBs in order to maintain = this separation. This
can become a problem for traditional routers since = the RIB is maintained
in a central module and serviced by a single = processor. These centralized
resources (memory and CPU) become a bottleneck as = the number
of subscribers increases, especially when the PE-CE = connections use chatty
routing protocols such as RIP or computationally = intensive routing protocols
such as OSPF. For example, when using OSPF as the =
CE-PE routing protocol, a Cisco router can only = sustain approx 20 to 30
instances per device. With a distributed = architecture, like the
CoSine IPSX platform, you can have more than 1500 = such instances
per blade.

In a truly distributed device architecture, the RIBs = are distributed
with the VRFs, and new resources (CPUs and Memory) = can be
added as needed.  Thus you avoid the = limitations imposed by
traditional routing architectures.

The base architecture of a PE device is absolutely = critical in
determining how many BGP/MPLS VPNs the device can = handle.
Trying to retrofit an existing architecture for a = new network design
can lead to limitations that purposely designed = hardware doesn't suffer from.
--------



At 12:49 PM 4/23/2002 -0400, Liu, Chia J (Charlie), = ALCNS wrote:
>Sachin,
>
>There are two aspects:
>*       Memory = Usage in GRP/RSP:   In the lab, we saw data of ~935 bytes per = VPN prefix in VRF, compared to 500-600 bytes per internet prefix in = global routing table.    I heard there is additional = 60KB-70KB overhead per VRF.

>*       Memory = Usage in Line Card:   We are particularly concerned about the = VRF memory overhead in PSA/TLU of E2 16xOC-3 in GSR.    = It looks like the number is different in different IOS = releases.    I am interested in knowing if anyone has = number on this.   Thanx.

>
>C.J. (Charlie) Liu
>
>
>> -----Original Message-----
>> From: Sachin Kalra = [SMTP:skalra@opnet.com]
>> Sent: Tuesday, April 23, 2002 11:51 = AM
>> To:   mpls@UU.NET
>> Subject:      = Memory at PE
>>
>> Dear Group:
>>
>> I would appreciate if I can get answer to = the following question regarding
>> BGP/MPLS VPNs (RFC2547bis)
>>
>> I understand that PE router maintains a = separate VRF table for each VPN
>> site connected to it. I wanted to know if a = PE also maintain separate RIBs
>> for each VPN site, apart from its main = Local RIB? Or, does it maintain only
>> one single RIB?
>>
>> Actually, I was looking from the = perspective of amount of memory required
>> at PE, if it has to maintain many VRFs and = many RIBs.
>>
>> Thanks for your response.
>> Sachin Kalra
###############################################################= ####################################### 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_01C1EB93.033AF580-- From owner-mpls@UU.NET Wed Apr 24 10:28:15 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09702 for ; Wed, 24 Apr 2002 10:28:14 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlzd04435; Wed, 24 Apr 2002 14:26:23 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlzd25530 for mpls-outgoing; Wed, 24 Apr 2002 14:26: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 QQmlzd25522 for ; Wed, 24 Apr 2002 14:26: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 QQmlzd27706 for ; Wed, 24 Apr 2002 14:25: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 QQmlzd03927 for ; Wed, 24 Apr 2002 14:25:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA15799 for ; Wed, 24 Apr 2002 10:25:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA17964 for mpls@uu.net; Wed, 24 Apr 2002 10:25:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmlzd25262 for ; Wed, 24 Apr 2002 14:24:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlzd24692 for ; Wed, 24 Apr 2002 14:24:04 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: london2.cisco.com [64.103.110.74]) id QQmlzd01294 for ; Wed, 24 Apr 2002 14:24:03 GMT Received: from JGUICHARW2K (ch2-dhcp134-140.cisco.com [161.44.134.140]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id PAA03573; Wed, 24 Apr 2002 15:22:06 +0100 (BST) From: "Jim Guichard" To: "Andrew Walker" , "Sachin Kalra" , "Liu, Chia J \(Charlie\), ALCNS" Cc: Subject: RE: Memory at PE Date: Wed, 24 Apr 2002 10:19:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C1EB79.87A54510" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.1.0.14.2.20020423174134.0354aff8@exchsrv5.cosinecom.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C1EB79.87A54510 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Memory at PEAndrew, I do not normally respond to these marketing type emails but I think it is important that we try and stay within the realms of reality. There are a whole bunch of things that contribute to scalability and to suggest that central CPU/memory is the bottleneck, or only consideration for scaling, is completely misleading. Jim -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Andrew Walker Sent: Wednesday, April 24, 2002 9:18 AM To: Sachin Kalra; Liu, Chia J (Charlie), ALCNS Cc: mpls@UU.NET Subject: RE: Memory at PE Sachin, You have asked a very important question as it gets to the heart of the scalability of a PE deployment. In a traditional router architecture (e.g. Cisco, Juniper, Unisphere), although FIBs are distributed out to individual line cards, the RIB is kept on a central module. There is only one RIB and therefore all updates whether for the Local RIB, or for each VRF must go through this RIB. Obviously the RIB is divided into pieces so as to keep the VRFs separate, but the whole thing is bounded by the amount of memory and CPU cycles available to the routing plane. Prior to BGP/MPLS VPNs, update performance of the RIB was not a large concern, so the fact that it was still centralized did not matter. However BGP/MPLS VPNs place a new burden on traditional routers. VRFs are by definition specific to a particular subscriber network and must only contain routes specific to that network; traditional routers partition their RIBs and FIBs in order to maintain this separation. This can become a problem for traditional routers since the RIB is maintained in a central module and serviced by a single processor. These centralized resources (memory and CPU) become a bottleneck as the number of subscribers increases, especially when the PE-CE connections use chatty routing protocols such as RIP or computationally intensive routing protocols such as OSPF. For example, when using OSPF as the CE-PE routing protocol, a Cisco router can only sustain approx 20 to 30 instances per device. With a distributed architecture, like the CoSine IPSX platform, you can have more than 1500 such instances per blade. In a truly distributed device architecture, the RIBs are distributed with the VRFs, and new resources (CPUs and Memory) can be added as needed. Thus you avoid the limitations imposed by traditional routing architectures. The base architecture of a PE device is absolutely critical in determining how many BGP/MPLS VPNs the device can handle. Trying to retrofit an existing architecture for a new network design can lead to limitations that purposely designed hardware doesn't suffer from. -------- At 12:49 PM 4/23/2002 -0400, Liu, Chia J (Charlie), ALCNS wrote: >Sachin, > >There are two aspects: >* Memory Usage in GRP/RSP: In the lab, we saw data of ~935 bytes per VPN prefix in VRF, compared to 500-600 bytes per internet prefix in global routing table. I heard there is additional 60KB-70KB overhead per VRF. >* Memory Usage in Line Card: We are particularly concerned about the VRF memory overhead in PSA/TLU of E2 16xOC-3 in GSR. It looks like the number is different in different IOS releases. I am interested in knowing if anyone has number on this. Thanx. > >C.J. (Charlie) Liu > > >> -----Original Message----- >> From: Sachin Kalra [SMTP:skalra@opnet.com] >> Sent: Tuesday, April 23, 2002 11:51 AM >> To: mpls@UU.NET >> Subject: Memory at PE >> >> Dear Group: >> >> I would appreciate if I can get answer to the following question regarding >> BGP/MPLS VPNs (RFC2547bis) >> >> I understand that PE router maintains a separate VRF table for each VPN >> site connected to it. I wanted to know if a PE also maintain separate RIBs >> for each VPN site, apart from its main Local RIB? Or, does it maintain only >> one single RIB? >> >> Actually, I was looking from the perspective of amount of memory required >> at PE, if it has to maintain many VRFs and many RIBs. >> >> Thanks for your response. >> Sachin Kalra ############################################################################ ########################## 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_000_0030_01C1EB79.87A54510 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Memory at PE
Andrew,
 
I do=20 not normally respond to these marketing type emails but I think it is = important=20 that we try and stay within the realms of reality. There are a whole = bunch of=20 things that contribute to scalability and to suggest that central=20 CPU/memory is the bottleneck, or only consideration for scaling, is = completely misleading. Jim
-----Original Message-----
From: owner-mpls@UU.NET=20 [mailto:owner-mpls@UU.NET]On Behalf Of Andrew = Walker
Sent:=20 Wednesday, April 24, 2002 9:18 AM
To: Sachin Kalra; Liu, = Chia J=20 (Charlie), ALCNS
Cc: mpls@UU.NET
Subject: RE: = Memory at=20 PE

Sachin,

You have asked a very important question as it gets = to=20 the
heart of the scalability of a PE = deployment. In a=20 traditional router
architecture (e.g. Cisco, = Juniper,=20 Unisphere), although FIBs are
distributed = out to=20 individual line cards, the RIB is kept on a central
module. There is only one RIB and therefore all updates = whether for the=20
Local RIB, or for each VRF must go through = this RIB.=20
Obviously the RIB is divided into pieces so = as to keep=20 the
VRFs separate, but the whole thing is = bounded by=20 the
amount of memory and CPU cycles = available to the=20 routing plane.
Prior to BGP/MPLS VPNs, = update=20 performance of the RIB was
not a large = concern, so the=20 fact that it was still centralized did not matter.

However BGP/MPLS VPNs place a new burden on = traditional=20 routers.
VRFs are by definition specific to = a=20 particular subscriber network and
must only = contain=20 routes specific to that network; traditional routers
partition their RIBs and FIBs in order to maintain this = separation.=20 This
can become a problem for traditional = routers=20 since the RIB is maintained
in a central = module and=20 serviced by a single processor. These centralized
resources (memory and CPU) become a bottleneck as the number=20
of subscribers increases, especially when = the PE-CE=20 connections use chatty
routing protocols = such as RIP=20 or computationally intensive routing protocols
such as=20 OSPF. For example, when using OSPF as the
CE-PE=20 routing protocol, a Cisco router can only sustain approx 20 to = 30=20
instances per device. With a distributed = architecture, like=20 the
CoSine IPSX platform, you can have more = than 1500=20 such instances
per blade.

In a truly distributed device architecture, the RIBs = are=20 distributed
with the VRFs, and new resources = (CPUs and=20 Memory) can be
added as needed.  Thus = you avoid=20 the limitations imposed by
traditional = routing=20 architectures.

The base architecture of a PE device is absolutely = critical in=20
determining how many BGP/MPLS VPNs the = device can=20 handle.
Trying to retrofit an existing = architecture=20 for a new network design
can lead to = limitations that=20 purposely designed hardware doesn't suffer from.
--------



At 12:49 PM 4/23/2002 -0400, Liu, Chia J (Charlie), = ALCNS=20 wrote:
>Sachin,
>=20
>There are two aspects:
>*       Memory Usage in=20 GRP/RSP:   In the lab, we saw data of ~935 bytes per VPN = prefix in=20 VRF, compared to 500-600 bytes per internet prefix in global routing=20 table.    I heard there is additional 60KB-70KB = overhead per=20 VRF.

>*       Memory = Usage in Line=20 Card:   We are particularly concerned about the VRF memory = overhead=20 in PSA/TLU of E2 16xOC-3 in GSR.    It looks like the = number is=20 different in different IOS releases.    I am interested = in=20 knowing if anyone has number on this.   Thanx.

>
>C.J. (Charlie) = Liu=20
>
> =
>> -----Original Message-----
>>=20 From: Sachin Kalra [SMTP:skalra@opnet.com]
>>=20 Sent: Tuesday, April 23, 2002 11:51 AM
>>=20 To:   mpls@UU.NET
>>=20 Subject:      Memory at PE
>>
>> Dear = Group:
>>
>> I would = appreciate if I can=20 get answer to the following question regarding
>> BGP/MPLS VPNs (RFC2547bis)
>>=20
>> I understand that PE router = maintains a=20 separate VRF table for each VPN
>> = site=20 connected to it. I wanted to know if a PE also maintain separate RIBs=20
>> for each VPN site, apart from its = main Local=20 RIB? Or, does it maintain only
>> one = single=20 RIB?
>>
>>=20 Actually, I was looking from the perspective of amount of memory = required=20
>> at PE, if it has to maintain many = VRFs and=20 many RIBs.
>>
>>=20 Thanks for your response.
>> Sachin = Kalra=20
################################################################= ######################################=20 This email communication may contain CONFIDENTIAL INFORMATION and is = intended=20 only for the use of the intended recipients identified above.  If = you are=20 not the intended recipient of this communication, you must not use, = disclose,=20 distribute, copy or print this email. If you have received this = communication=20 in error, please immediately notify the sender by reply email, delete = the=20 communication and destroy all copies.=20 = #########################################################################= #############################

------=_NextPart_000_0030_01C1EB79.87A54510-- From owner-mpls@UU.NET Wed Apr 24 10:57:32 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17332 for ; Wed, 24 Apr 2002 10:57:32 -0400 (EDT) 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 QQmlzf05831; Wed, 24 Apr 2002 14:51:42 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlzf27754 for mpls-outgoing; Wed, 24 Apr 2002 14:51:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmlzf27749 for ; Wed, 24 Apr 2002 14:51: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 QQmlzf27277 for ; Wed, 24 Apr 2002 14:51:02 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmlzf04924 for ; Wed, 24 Apr 2002 14:51:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA19379 for ; Wed, 24 Apr 2002 10:51:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA20908 for mpls@uu.net; Wed, 24 Apr 2002 10:51:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmlzf27693 for ; Wed, 24 Apr 2002 14:50: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 QQmlzf15916 for ; Wed, 24 Apr 2002 14:50:07 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: madrid.cisco.com [64.103.17.204]) id QQmlzf06984 for ; Wed, 24 Apr 2002 14:50:05 GMT Received: from MACHANAW2K (dhcp-mad-wer4-vl11-64-103-19-161.cisco.com [64.103.19.161]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id QAA06183; Wed, 24 Apr 2002 16:49:32 +0200 (MET DST) From: "Miguel Angel Chana" To: "'Jim Guichard'" , "'Andrew Walker'" , "'Sachin Kalra'" , "'Liu, Chia J \(Charlie\), ALCNS'" Cc: Subject: RE: Memory at PE Date: Wed, 24 Apr 2002 16:49:31 +0200 Message-ID: <002e01c1eb9f$3ee6e010$a1136740@emea.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01C1EBB0.027443F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002F_01C1EBB0.027443F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Memory at PEHello, Jim: I cannot be more in agreement with you. This kind of messages in this list are not very useful, and I think we should not discuss particular implementations. For me this should not be a place for manufacturers to discuss who does it better. Having said that, I can't resist to comment that every architecture has its own share of issues. In a virtual router architecture, if there are N instances of routing, every one receives more or less 1/N CPU process time and 1/N memory. Both resources are finite, unfortunately. Regards -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim Guichard Sent: Wednesday, April 24, 2002 4:20 PM To: Andrew Walker; Sachin Kalra; Liu, Chia J (Charlie), ALCNS Cc: mpls@UU.NET Subject: RE: Memory at PE Andrew, I do not normally respond to these marketing type emails but I think it is important that we try and stay within the realms of reality. There are a whole bunch of things that contribute to scalability and to suggest that central CPU/memory is the bottleneck, or only consideration for scaling, is completely misleading. Jim -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Andrew Walker Sent: Wednesday, April 24, 2002 9:18 AM To: Sachin Kalra; Liu, Chia J (Charlie), ALCNS Cc: mpls@UU.NET Subject: RE: Memory at PE Sachin, You have asked a very important question as it gets to the heart of the scalability of a PE deployment. In a traditional router architecture (e.g. Cisco, Juniper, Unisphere), although FIBs are distributed out to individual line cards, the RIB is kept on a central module. There is only one RIB and therefore all updates whether for the Local RIB, or for each VRF must go through this RIB. Obviously the RIB is divided into pieces so as to keep the VRFs separate, but the whole thing is bounded by the amount of memory and CPU cycles available to the routing plane. Prior to BGP/MPLS VPNs, update performance of the RIB was not a large concern, so the fact that it was still centralized did not matter. However BGP/MPLS VPNs place a new burden on traditional routers. VRFs are by definition specific to a particular subscriber network and must only contain routes specific to that network; traditional routers partition their RIBs and FIBs in order to maintain this separation. This can become a problem for traditional routers since the RIB is maintained in a central module and serviced by a single processor. These centralized resources (memory and CPU) become a bottleneck as the number of subscribers increases, especially when the PE-CE connections use chatty routing protocols such as RIP or computationally intensive routing protocols such as OSPF. For example, when using OSPF as the CE-PE routing protocol, a Cisco router can only sustain approx 20 to 30 instances per device. With a distributed architecture, like the CoSine IPSX platform, you can have more than 1500 such instances per blade. In a truly distributed device architecture, the RIBs are distributed with the VRFs, and new resources (CPUs and Memory) can be added as needed. Thus you avoid the limitations imposed by traditional routing architectures. The base architecture of a PE device is absolutely critical in determining how many BGP/MPLS VPNs the device can handle. Trying to retrofit an existing architecture for a new network design can lead to limitations that purposely designed hardware doesn't suffer from. -------- At 12:49 PM 4/23/2002 -0400, Liu, Chia J (Charlie), ALCNS wrote: >Sachin, > >There are two aspects: >* Memory Usage in GRP/RSP: In the lab, we saw data of ~935 bytes per VPN prefix in VRF, compared to 500-600 bytes per internet prefix in global routing table. I heard there is additional 60KB-70KB overhead per VRF. >* Memory Usage in Line Card: We are particularly concerned about the VRF memory overhead in PSA/TLU of E2 16xOC-3 in GSR. It looks like the number is different in different IOS releases. I am interested in knowing if anyone has number on this. Thanx. > >C.J. (Charlie) Liu > > >> -----Original Message----- >> From: Sachin Kalra [SMTP:skalra@opnet.com] >> Sent: Tuesday, April 23, 2002 11:51 AM >> To: mpls@UU.NET >> Subject: Memory at PE >> >> Dear Group: >> >> I would appreciate if I can get answer to the following question regarding >> BGP/MPLS VPNs (RFC2547bis) >> >> I understand that PE router maintains a separate VRF table for each VPN >> site connected to it. I wanted to know if a PE also maintain separate RIBs >> for each VPN site, apart from its main Local RIB? Or, does it maintain only >> one single RIB? >> >> Actually, I was looking from the perspective of amount of memory required >> at PE, if it has to maintain many VRFs and many RIBs. >> >> Thanks for your response. >> Sachin Kalra ############################################################################ ########################## 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_000_002F_01C1EBB0.027443F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Memory at PE
Hello, Jim:
 
I cannot be more in agreement with you. This kind of messages = in this=20 list are not
very useful, and I think we should not discuss particular=20 implementations. For me
this should not be a place for manufacturers to discuss who = does it=20 better.
 
Having said that, I can't resist to comment that every = architecture has=20 its own
share of issues.
 
In a virtual router architecture, if there are N instances of = routing,=20 every
one receives more or less 1/N CPU process time and 1/N memory. = Both=20 resources
are finite, unfortunately.
 
Regards
 
 
-----Original Message-----
From: owner-mpls@UU.NET=20 [mailto:owner-mpls@UU.NET]On Behalf Of Jim = Guichard
Sent:=20 Wednesday, April 24, 2002 4:20 PM
To: Andrew Walker; Sachin = Kalra;=20 Liu, Chia J (Charlie), ALCNS
Cc: = mpls@UU.NET
Subject: RE:=20 Memory at PE

Andrew,
 
I do=20 not normally respond to these marketing type emails but I think it is=20 important that we try and stay within the realms of reality. There are = a whole=20 bunch of things that contribute to scalability and to suggest = that=20 central CPU/memory is the bottleneck, or only consideration for=20 scaling, is completely misleading. Jim
-----Original Message-----
From: = owner-mpls@UU.NET=20 [mailto:owner-mpls@UU.NET]On Behalf Of Andrew = Walker
Sent:=20 Wednesday, April 24, 2002 9:18 AM
To: Sachin Kalra; Liu, = Chia J=20 (Charlie), ALCNS
Cc: mpls@UU.NET
Subject: RE: = Memory at=20 PE

Sachin,

You have asked a very important question as it = gets to=20 the
heart of the scalability of a PE = deployment. In=20 a traditional router
architecture (e.g. = Cisco,=20 Juniper, Unisphere), although FIBs are
distributed=20 out to individual line cards, the RIB is kept on a central =
module. There is only one RIB and therefore all updates = whether for=20 the
Local RIB, or for each VRF must go = through this=20 RIB.
Obviously the RIB is divided into = pieces so as=20 to keep the
VRFs separate, but the whole = thing is=20 bounded by the
amount of memory and CPU = cycles=20 available to the routing plane.
Prior to = BGP/MPLS=20 VPNs, update performance of the RIB was
not a large=20 concern, so the fact that it was still centralized did not = matter.=20

However BGP/MPLS VPNs place a new burden on = traditional=20 routers.
VRFs are by definition specific = to a=20 particular subscriber network and
must = only contain=20 routes specific to that network; traditional routers =
partition their RIBs and FIBs in order to maintain this = separation.=20 This
can become a problem for traditional = routers=20 since the RIB is maintained
in a central = module and=20 serviced by a single processor. These centralized
resources (memory and CPU) become a bottleneck as the = number=20
of subscribers increases, especially when = the PE-CE=20 connections use chatty
routing protocols = such as RIP=20 or computationally intensive routing protocols
such=20 as OSPF. For example, when using OSPF as the
CE-PE=20 routing protocol, a Cisco router can only sustain approx 20 to = 30=20
instances per device. With a distributed = architecture, like=20 the
CoSine IPSX platform, you can have = more than=20 1500 such instances
per blade.

In a truly distributed device architecture, the = RIBs are=20 distributed
with the VRFs, and new = resources (CPUs=20 and Memory) can be
added as needed.  = Thus you=20 avoid the limitations imposed by
traditional routing=20 architectures.

The base architecture of a PE device is absolutely = critical=20 in
determining how many BGP/MPLS VPNs the = device can=20 handle.
Trying to retrofit an existing = architecture=20 for a new network design
can lead to = limitations=20 that purposely designed hardware doesn't suffer from. =
--------



At 12:49 PM 4/23/2002 -0400, Liu, Chia J = (Charlie), ALCNS=20 wrote:
>Sachin,
>
>There are two = aspects:=20
>*       Memory = Usage in=20 GRP/RSP:   In the lab, we saw data of ~935 bytes per VPN = prefix in=20 VRF, compared to 500-600 bytes per internet prefix in global routing = table.    I heard there is additional 60KB-70KB = overhead per=20 VRF.

>*       Memory = Usage in=20 Line Card:   We are particularly concerned about the VRF = memory=20 overhead in PSA/TLU of E2 16xOC-3 in GSR.    It looks = like=20 the number is different in different IOS releases.    = I am=20 interested in knowing if anyone has number on this.  =20 Thanx.

>
>C.J. (Charlie) = Liu=20
>
> =
>> -----Original Message-----
>>=20 From: Sachin Kalra [SMTP:skalra@opnet.com]
>>=20 Sent: Tuesday, April 23, 2002 11:51 AM
>>=20 To:   mpls@UU.NET
>>=20 Subject:      Memory at PE
>>
>> Dear = Group:=20
>>
>> I = would=20 appreciate if I can get answer to the following question regarding=20
>> BGP/MPLS VPNs (RFC2547bis) =
>>
>> I understand = that PE router=20 maintains a separate VRF table for each VPN
>>=20 site connected to it. I wanted to know if a PE also maintain = separate RIBs=20
>> for each VPN site, apart from its = main=20 Local RIB? Or, does it maintain only
>> one=20 single RIB?
>>
>> Actually, I was looking from the perspective of = amount of=20 memory required
>> at PE, if it has = to=20 maintain many VRFs and many RIBs.
>> =
>> Thanks for your response. =
>> Sachin Kalra
################################################################= ######################################=20 This email communication may contain CONFIDENTIAL INFORMATION and is = intended only for the use of the intended recipients identified = above. =20 If you are not the intended recipient of this communication, you = must not=20 use, disclose, distribute, copy or print this email. If you have = received=20 this communication in error, please immediately notify the sender by = reply=20 email, delete the communication and destroy all copies.=20 = #########################################################################= #############################

= ------=_NextPart_000_002F_01C1EBB0.027443F0-- From owner-mpls@UU.NET Wed Apr 24 14:31:56 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17781 for ; Wed, 24 Apr 2002 14:31:56 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmlzu26028; Wed, 24 Apr 2002 18:30:02 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlzt13780 for mpls-outgoing; Wed, 24 Apr 2002 18:29: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 QQmlzt13775 for ; Wed, 24 Apr 2002 18:29:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmlzt22880 for ; Wed, 24 Apr 2002 18:29: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 QQmlzt06019 for ; Wed, 24 Apr 2002 18:29:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA07499 for ; Wed, 24 Apr 2002 14:29:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA12724 for mpls@uu.net; Wed, 24 Apr 2002 14:29:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmlzt13724 for ; Wed, 24 Apr 2002 18:28:29 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 QQmlzt25877 for ; Wed, 24 Apr 2002 18:28:04 GMT Received: from workhorse.fictitious.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmlzt05939 for ; Wed, 24 Apr 2002 18:27:55 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA54063; Wed, 24 Apr 2002 14:23:19 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200204241823.OAA54063@workhorse.fictitious.org> To: neil.2.harrison@bt.com cc: mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: comments on nagarajan-ccamp-mpls-packet-protection-00.txt In-reply-to: Your message of "Wed, 24 Apr 2002 13:18:24 BST." Date: Wed, 24 Apr 2002 14:23:19 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message , nei l.2.harrison@bt.com writes: > > 1 I noted a criticism in the mtg notes that it uses 2x the BW of one > LSP....well yes it is 1+1 so I'd say that's obvious. However, I think we > have to place any such criticism of BW efficiency in context. For example, > if I compare it with LDP as a server layer to (say) rfc2547 VPNs, then > because there is no relationship between a pkt's up-state QoS forwarding > treatment and a pkt's survivability requirements (vis-à-vis same or > different DS-coded pkts of *any* VPN), operators are forced to over-engineer > such networks and *hope* (because there is no assurance) that traffic > survives under failures....a factor of 2x over-engineering on some DS > classes is not uncommon. > > Hence, the point I want to make here is that using BW wisely to > reduce/remove a complexity/problem is one thing (which I support), but > asking an operator to throw BW at a problem that should not really exist > (because the application/problem in question has only been partially > defined, eg just the connectivity bit of VPNs) is something else. So any > criticism of BW efficiency only makes sense against the context of the > application/problem it is addressing IMO. Point of failure protection schemes (local-protect and fast-reroute) provide 50msec recovery. I'll just say FRR for short. This technique doesn't require sending double the bandwidth. Some implementations might not make the 50msec but some do. Fully disjoint paths from the ingress yield from 1/4 to 1-2 seconds recovery (depending again on who's implementation) and these require less signaling than point of failure protection. In our implementation these are called "standby" LSPs. Reservations on the backups (using either FRR or standby) at a numerically higher setup/hold priority can help avoid congestion (or completely avoid it) during the failure without impacting the traffic engineering of the primary path (on the numerically lower priority). The ISPs that I've talked to about the topic of restoration indicate that although fast restoration is highly desireable for some services, a strong requirement is efficient use of available bandwidth. The goal is to allow the most cost effective delivery of service and keep the financial bottom line in the black. This may have something to do with a competative business environment but whatever the reason, the "throw more bandwidth at it" approach does not seem to be in favor. So far signaling extensions to share the backup bandwidth have been proposed but gone nowhere (perhaps implementation will help). This would yield even better use of resources (or better avoidance of congestion if overbooking backup bandwidth was eliminated). Of course, if the payload is non-IP overbooking backups may not be an option so this then would just yield better use of resources. Of course, FRR requires that the point of failure be able to detect its own failure which may not be the case for optical devices. Doubling the bandwidth is a steep price to pay to satisfy the restoration needs. If the cost of WDM port plus optical switch port is half that of a router port, that might be fine. It still might make a lot more economic sense to use FRR to provide restoration at the PSC capable boxes outside the optical domain which will generally be plenty fast enough. IMHO - there is no need for this draft. In the end the ISPs/carriers vote with their dollars and I haven't seen any "yes" votes of that sort so I won't be coding this quite yet. As far as VPN is concerned, some providers are using (at least in trial if not production) LDP over MPLS/TE and using the MPLS/TE traffic engineering and fast recovery capabilites. This scales well if the network is divided into a core and regions keeping the number of LSPs manageable and can work well if the nodes (routers) at the borders of the core and regions are very reliable. Curtis From owner-mpls@UU.NET Wed Apr 24 23:29:07 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16730 for ; Wed, 24 Apr 2002 23:29:07 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmbd18154; Thu, 25 Apr 2002 03:27:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmbd15183 for mpls-outgoing; Thu, 25 Apr 2002 03:27: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 QQmmbd15168 for ; Thu, 25 Apr 2002 03:27:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmmbd13596 for ; Thu, 25 Apr 2002 03:27:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmmbd17037 for ; Thu, 25 Apr 2002 03:27:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA05252 for ; Wed, 24 Apr 2002 23:27:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id XAA04348 for mpls@uu.net; Wed, 24 Apr 2002 23:27:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmmbd15139 for ; Thu, 25 Apr 2002 03:26:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmmbd09028 for ; Thu, 25 Apr 2002 03:25:35 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmmbd01851 for ; Thu, 25 Apr 2002 03:25:32 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id XAA56359; Wed, 24 Apr 2002 23:20:47 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200204250320.XAA56359@workhorse.fictitious.org> To: "Per F Hansen" cc: tli@juniper.net, mpls@UU.NET Reply-To: curtis@fictitious.org Subject: Re: IBM MPLS patent In-reply-to: Your message of "Wed, 17 Apr 2002 13:45:06 GMT." <20020417134506.17611.qmail@fe170.worldonline.dk> Date: Wed, 24 Apr 2002 23:20:47 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <20020417134506.17611.qmail@fe170.worldonline.dk>, "Per F Hansen" wr ites: > Hello > > I saw an email from you 22/2-1999 related to the IBM > mpls patent claim discussions. > > Can you or any other give an update about what has > happened since. Do people pay IBM a fee, or have the > MPLS stadards been changed to come around IBM, or > were there practically a technical implementation way > to come around IBM and still be MPLS compliant. > > Per I don't think anyone pays IBM a fee for patents related to MPLS. I don't even know if they have any. At the time I think we were speculating on what IBM might be claiming to be patentable since they had made an intellectual property statement but had no patent. One can only speculate when someone claims to have something in the application stage. I am extremely familiar with the early IBM discussions that preceded ARIS and initiated much of the discussion as part of the NSFNET partnership. I also discussed ideas publicly, my own ideas, on the IETF int-serv mailing list prior to anything coming out of Cisco, IBM, or Ipsilon. If any patent related to forwarding comes of the IBM work I may still have email that precedes the public discussions that would very likely invalidate it. If they patent something related to their LDP work, that might be another story, depending on the nature of the patent. Early public discussion of signaling assumed a model more similar to LDP than RSVP/TE or CR-LDP, so even LDP is probably safe. Is there a specific patent number that you are concerned about or are you just asking what became of this discussion? Curtis From owner-mpls@UU.NET Thu Apr 25 04:14:07 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29044 for ; Thu, 25 Apr 2002 04:14:07 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmbw00247; Thu, 25 Apr 2002 08:12:49 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmbw26638 for mpls-outgoing; Thu, 25 Apr 2002 08:12:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmmbw26627 for ; Thu, 25 Apr 2002 08:12: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 QQmmbw00867 for ; Thu, 25 Apr 2002 08:11:23 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQmmbw04093 for ; Thu, 25 Apr 2002 08:11:16 GMT Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19) id <2YYVYZ94>; Thu, 25 Apr 2002 13:40:14 +0530 Message-ID: <9027F68B07E7D511AE9400B0D0787DC007048C@mailserver.netbrahma.com> From: Manoj Agiwal To: "Gmpls-Ops (E-mail)" , "'Ccamp (E-mail)" , "mpls@UU. NET (E-mail)" Subject: VT Switching Date: Thu, 25 Apr 2002 13:40:13 +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 , I want to estanlish a DS1 trail , using GMPLS signaling . The DS1 will get mapped to a single VT in a VTG , and will get transferred to other end using VT Switching . All the nodes particpating in the connection will do VT switching . Can I specify a VT by a single label , or I need to encode this information ( STS->VTG->VT) in some proprietary format which is understandable by neighbouring nodes . I would be interested in knowing how people do this . Regards , Manoj From owner-mpls@UU.NET Thu Apr 25 07:18:28 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01124 for ; Thu, 25 Apr 2002 07:18:27 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmcj12066; Thu, 25 Apr 2002 11:16:51 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmcj17818 for mpls-outgoing; Thu, 25 Apr 2002 11:16: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 QQmmcj17735 for ; Thu, 25 Apr 2002 11:16:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmmcj10328 for ; Thu, 25 Apr 2002 11:15:34 GMT From: neil.2.harrison@bt.com Received: from cbibipnt02.HC.BT.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: saturn.bt.com [193.113.57.20]) id QQmmcj16961 for ; Thu, 25 Apr 2002 11:15:33 GMT Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Thu, 25 Apr 2002 12:15:40 +0100 Message-ID: To: curtis@fictitious.org Cc: mpls@UU.NET Subject: RE: comments on nagarajan-ccamp-mpls-packet-protection-00.txt Date: Thu, 25 Apr 2002 12:15:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA01124 Hi Curtis.....nice to hear from you again. You make some important points....please see repsonses in-line. regards, Neil Curtis Villamizar wrote 24 April 2002 19:23 > In message > , nei > l.2.harrison@bt.com writes: > > > > 1 I noted a criticism in the mtg notes that it uses 2x > the BW of one > > LSP....well yes it is 1+1 so I'd say that's obvious. > However, I think we > > have to place any such criticism of BW efficiency in > context. For example, > > if I compare it with LDP as a server layer to (say) rfc2547 > VPNs, then > > because there is no relationship between a pkt's up-state > QoS forwarding > > treatment and a pkt's survivability requirements (vis-à-vis same or > > different DS-coded pkts of *any* VPN), operators are forced > to over-engineer > > such networks and *hope* (because there is no assurance) > that traffic > > survives under failures....a factor of 2x over-engineering > on some DS > > classes is not uncommon. > > > > Hence, the point I want to make here is that using BW wisely to > > reduce/remove a complexity/problem is one thing (which I > support), but > > asking an operator to throw BW at a problem that should not > really exist > > (because the application/problem in question has only been partially > > defined, eg just the connectivity bit of VPNs) is something > else. So any > > criticism of BW efficiency only makes sense against the > context of the > > application/problem it is addressing IMO. > > > > Point of failure protection schemes (local-protect and fast-reroute) > provide 50msec recovery. I'll just say FRR for short. NH=> Yes I am aware this is their claim/target. Totally uncessary, and IMO shows a lack of clear thinking/understanding of the total problem space here......no application needs these speeds and you are going to get prot-sw/restoration events for error bursts that would have self-cleared. You make a rod for your back (chasing L1 SDH/Sonet ring restoration times) by going too fast as one moves into the upper layer networks and closer to end applications. Lots of reasons why, many I have pointed out in previous mails when this topic has surfaced before. But if people are silly enough to do this then that's up to them I guess. > This technique > doesn't require sending double the bandwidth. Some implementations > might not make the 50msec but some do. > > Fully disjoint paths from the ingress yield from 1/4 to 1-2 seconds > recovery (depending again on who's implementation) and these require > less signaling than point of failure protection. In our > implementation these are called "standby" LSPs. NH=> Now that sounds like far more sensible port-sw/restoration times at these network layers....you can do a great deal with a topology database *before* a failure occurs ;-) You still need knowledge to the duct layer however to make it work....once you 'lease' the lower layers this info goes......and that's why the so-called peer-model in GMMPLS can never scale, ie commercial non-starter even if it was technically feasible. > > Reservations on the backups (using either FRR or standby) at a > numerically higher setup/hold priority can help avoid congestion (or > completely avoid it) during the failure without impacting the traffic > engineering of the primary path (on the numerically lower priority). NH=> I have said it before but I will do so again......please make sure any pre-emption/bumping scheme can be disabled. Its largely a waste of time: At low loads its a non-issue, and at high loads (which is strictly the only time you really need it) it rapidly becomes unpredicatable. Should not be a surprise, this is typical network behaviour (any type) at the 'loading knee'....same considerations apply to DS. I am also not saying this from some theoretical viewpoint but from bitter practical experience of such schemes. > > The ISPs that I've talked to about the topic of restoration indicate > that although fast restoration is highly desireable for some services, NH=> But I'll bet no one can *justify* 50ms! > a strong requirement is efficient use of available bandwidth. NH=> Yipee! We have been saying that those who think BW comes for free are nuts.....welcome to the real operator world. Those have not heeded this have already gone, or will go, bust. > The > goal is to allow the most cost effective delivery of service and keep > the financial bottom line in the black. This may have something to do > with a competative business environment but whatever the reason, the > "throw more bandwidth at it" approach does not seem to be in favor. NH=> Its not news to me this.....and its about time others grapsed this now the 'silly' margins on BW have all but gone. Anyone for GMPLS/SVC-like L1 BoD?....try getting a business case to fly on that one! > > So far signaling extensions to share the backup bandwidth have been > proposed but gone nowhere (perhaps implementation will help). This > would yield even better use of resources (or better avoidance of > congestion if overbooking backup bandwidth was eliminated). Of > course, if the payload is non-IP overbooking backups may not be an > option so this then would just yield better use of resources. > > Of course, FRR requires that the point of failure be able to detect > its own failure which may not be the case for optical devices. > Doubling the bandwidth is a steep price to pay to satisfy the > restoration needs. NH=> I agree Curtis. That is exactly why I said for *critical applications* (eg control/management channels) the proposals could be attractive.....and its also simple/elegant, which usually implies 'sensible'. > If the cost of WDM port plus optical switch port > is half that of a router port, that might be fine. It still might > make a lot more economic sense to use FRR to provide restoration at > the PSC capable boxes outside the optical domain which will generally > be plenty fast enough. > > IMHO - there is no need for this draft. In the end the ISPs/carriers > vote with their dollars and I haven't seen any "yes" votes of that > sort so I won't be coding this quite yet. > > As far as VPN is concerned, some providers are using (at least in > trial if not production) LDP over MPLS/TE and using the MPLS/TE > traffic engineering and fast recovery capabilites. NH=> This is sort-of what I have been thinking for some time too. The key problem is LDP as the bottom/server layer of LSPs *if* one aggregates over all VPNs as I pointed out; in particular, it does not allow one to differentiate a pkt's QoS and survivability attributes.....these are quite different. In the case of VPNs I would argue strongly that it is the trail object (ie the LSP) that has to carry the survivability semantics.....but its can't do this under like-DS-class aggregation in LDP......so we have to throw BW at the problem. I don't mind throwing BW at problems *wisely*, to get rid of the problem or reduce its complexity *if* there is no alternative technology solution......but I don't like throwing BW at the problem when the basis of the problem is not addressable in technology X, but there is technolgy Y that can sort it.....and perhaps gives other benefits too. > This scales well > if the network is divided into a core and regions keeping the number > of LSPs manageable and can work well if the nodes (routers) at the > borders of the core and regions are very reliable. NH=> Remember this.....its one thing targeting a smallish niche market and its a very different thing scaling to massive public network volumes.....the network solutions are usually not the same, and the NMS/OSS requitrements are radically different. 'Enterprise sourced' solutions usually can't cut-it for large operators when looking for the massive volumes...and we also need automatic defect detection/handling as you know I have been advocating for some time, as this too is a 'sign' of an ability/desire to address the large operator case. > > Curtis > From owner-mpls@UU.NET Thu Apr 25 09:54:51 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06228 for ; Thu, 25 Apr 2002 09:54:51 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmct09391; Thu, 25 Apr 2002 13:51:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmct14383 for mpls-outgoing; Thu, 25 Apr 2002 13:51: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 QQmmct14371 for ; Thu, 25 Apr 2002 13:51:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmmct06559 for ; Thu, 25 Apr 2002 13:50:40 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 QQmmct08214 for ; Thu, 25 Apr 2002 13:50:39 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA28601 for ; Thu, 25 Apr 2002 09:50:39 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA04869 for mpls@uu.net; Thu, 25 Apr 2002 09:50:39 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmmct13996 for ; Thu, 25 Apr 2002 13:45:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmmct12444 for ; Thu, 25 Apr 2002 13:45:11 GMT From: bjabbari@gmu.edu Received: from portal.gmu.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: portalknot.gmu.edu [129.174.0.8]) id QQmmct07661 for ; Thu, 25 Apr 2002 13:45:11 GMT Received: from gmu.edu (mail03.gmu.edu [129.174.0.11]) by portal.gmu.edu (8.8.8/8.8.8) with ESMTP id JAA06930; Thu, 25 Apr 2002 09:45:08 -0400 (EDT) To: "Per F Hansen" Cc: tli@juniper.net, mpls@UU.NET, Curtis Villamizar Message-ID: <1a6ad0f1a6ac35.1a6ac351a6ad0f@gmu.edu> Date: Thu, 25 Apr 2002 09:45:08 -0400 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: IBM MPLS patent X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA06228 And to add to Curtis’ comment, if the claims were to be broad, then an argument can be made based on the framework being merely an application and extension of techniques known in other areas (MTP- message transfer part of CCS7/SS7 protocol) to the IP-based networks. You can look at some publicly available documents (from ITU-T, then CCITT) in 1976 on SS7 protocol to find the similarities. For details you might want to read two papers I published in the Proceedings of the IEEE, Feb 1991 (on architecture) and Apr 1992 (on routing and congestion). On the other hand, if the claims were to be narrow and related to a specific implementation, then there could be a valid case. - Bijan --------------------------------------- Bijan Jabbari, PhD Professor of Electrical Engineering George Mason University Fairfax, VA 22030-4444 email: bjabbari@gmu.edu ----- Original Message ----- From: Curtis Villamizar Date: Wednesday, April 24, 2002 11:20 pm Subject: Re: IBM MPLS patent > > In message <20020417134506.17611.qmail@fe170.worldonline.dk>, "Per > F Hansen" wr > ites: > > Hello > > > > I saw an email from you 22/2-1999 related to the IBM > > mpls patent claim discussions. > > > > Can you or any other give an update about what has > > happened since. Do people pay IBM a fee, or have the > > MPLS stadards been changed to come around IBM, or > > were there practically a technical implementation way > > to come around IBM and still be MPLS compliant. > > > > Per > > > I don't think anyone pays IBM a fee for patents related to MPLS. I > don't even know if they have any. > > At the time I think we were speculating on what IBM might be claiming > to be patentable since they had made an intellectual property > statement but had no patent. One can only speculate when someone > claims to have something in the application stage. I am extremely > familiar with the early IBM discussions that preceded ARIS and > initiated much of the discussion as part of the NSFNET > partnership. I > also discussed ideas publicly, my own ideas, on the IETF int-serv > mailing list prior to anything coming out of Cisco, IBM, or Ipsilon. > If any patent related to forwarding comes of the IBM work I may still > have email that precedes the public discussions that would very likely > invalidate it. If they patent something related to their LDP work, > that might be another story, depending on the nature of the patent. > Early public discussion of signaling assumed a model more similar to > LDP than RSVP/TE or CR-LDP, so even LDP is probably safe. > > Is there a specific patent number that you are concerned about or are > you just asking what became of this discussion? > > Curtis > > From owner-mpls@UU.NET Thu Apr 25 12:19:27 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26018 for ; Thu, 25 Apr 2002 12:19:22 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmdd23818; Thu, 25 Apr 2002 16:16:34 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmdd02180 for mpls-outgoing; Thu, 25 Apr 2002 16:16: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 QQmmdd02145 for ; Thu, 25 Apr 2002 16:16:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmmdc25443 for ; Thu, 25 Apr 2002 16:14:14 GMT Received: from roam.psg.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-10-70.research.att.com [135.207.10.70]) id QQmmdc09207 for ; Thu, 25 Apr 2002 16:14:14 GMT Received: from randy by roam.psg.com with local (Exim 4.04) id 170lsi-000DqW-00; Thu, 25 Apr 2002 12:14:04 -0400 Approved: ops Message-ID: <9027F68B07E7D511AE9400B0D0787DC007048C@mailserver.netbrahma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Manoj Agiwal To: "Gmpls-Ops (E-mail)" , , "mpls@UU. NET (E-mail)" Subject: VT Switching Date: Thu, 25 Apr 2002 13:40:13 +0530 Sender: owner-mpls@UU.NET Precedence: bulk [ post by non-subscriber ] Hi , I want to estanlish a DS1 trail , using GMPLS signaling . The DS1 will get mapped to a single VT in a VTG , and will get transferred to other end using VT Switching . All the nodes particpating in the connection will do VT switching . Can I specify a VT by a single label , or I need to encode this information ( STS->VTG->VT) in some proprietary format which is understandable by neighbouring nodes . I would be interested in knowing how people do this . Regards , Manoj ------- end of forwarded message ------- From owner-mpls@UU.NET Thu Apr 25 16:35:06 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05133 for ; Thu, 25 Apr 2002 16:35:05 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmdu21394; Thu, 25 Apr 2002 20:32:14 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmdu21135 for mpls-outgoing; Thu, 25 Apr 2002 20:31:59 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 QQmmdu21129 for ; Thu, 25 Apr 2002 20:31:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmmdu12694 for ; Thu, 25 Apr 2002 20:31:04 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmmdu20255 for ; Thu, 25 Apr 2002 20:31:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA01313 for ; Thu, 25 Apr 2002 16:31:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA14478 for mpls@uu.net; Thu, 25 Apr 2002 16:31:02 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmmdu20945 for ; Thu, 25 Apr 2002 20:30:24 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 QQmmdt01543 for ; Thu, 25 Apr 2002 20:29:04 GMT Received: from hermes.fm.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmr01.intel.com [192.55.52.18]) id QQmmdt02680 for ; Thu, 25 Apr 2002 20:29:04 GMT Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.41 2002/04/22 23:29:17 root Exp $) with ESMTP id g3PKQmB27786 for ; Thu, 25 Apr 2002 20:26:54 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.16 2002/04/15 17:47:00 root Exp $) with SMTP id g3PKRw324541 for ; Thu, 25 Apr 2002 20:27:58 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002042513261019268 for ; Thu, 25 Apr 2002 13:26:10 -0700 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id <28FQCHNX>; Thu, 25 Apr 2002 13:25:48 -0700 Message-ID: From: "Sharma, Prem" To: "'Carlos Patriawan'" , "'CHAUDHARI SHASHIKANTH'", mpls-ops@mplsrc.com Subject: RE: [MPLS-OPS]: MPLS simulator Date: Thu, 25 Apr 2002 13:25:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Shashikant, Check out this link: http://www.deriveit.com./MPLS.htm Here they have GMPLS/MPLS Network Simulator. -Prem -----Original Message----- From: Carlos Patriawan [mailto:cpatriaw@pluris.com] Sent: Thursday, April 25, 2002 10:00 AM To: 'CHAUDHARI SHASHIKANTH'; mpls-ops@mplsrc.com Subject: RE: [MPLS-OPS]: MPLS simulator adtech has something like virtual grid topology where the router inside the grid can generate opaque LSA and establish RSVP-TE on top of it. Carlos -----Original Message----- From: CHAUDHARI SHASHIKANTH [mailto:shashi@crlbel.ernet.in] Sent: Thursday, April 25, 2002 2:23 AM To: mpls-ops@mplsrc.com Subject: [MPLS-OPS]: MPLS simulator Hi Can any one please tell me about the MPLS simulator which are available on the Internet which will support the simulting MPLS network with more than 100 nodes. Thanking you in advance. Shashikant Chaudhari ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- 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 Apr 26 06:06:33 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28612 for ; Fri, 26 Apr 2002 06:06:28 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmfw21263; Fri, 26 Apr 2002 10:05:20 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmfw25129 for mpls-outgoing; Fri, 26 Apr 2002 10:05:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmmfw24774 for ; Fri, 26 Apr 2002 10:04:58 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 QQmmfw19785 for ; Fri, 26 Apr 2002 10:04:47 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQmmfw26201 for ; Fri, 26 Apr 2002 10:04:39 GMT Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19) id <2YYVY6CN>; Fri, 26 Apr 2002 15:33:32 +0530 Message-ID: <9027F68B07E7D511AE9400B0D0787DC006801E@mailserver.netbrahma.com> From: Mohit Misra To: "'mpls@uu.net'" Subject: GMPLS LSP Enc Type Date: Fri, 26 Apr 2002 15:33: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 The distinction between the LSP Enc type and G-PID is not very clear. For example if we map DS3 into STS1, do we use LSP Enc type as SONET or ANSI PDH. Similarly if we are mapping Ethernet into SONET frames then LSP Enc type should be SONET or Ethernet. Second Question is if I map Ethernet frames into SPE using LAPS, What value should G-PID carry. There are two values defined there, one for Ethernet and other for LAPS. From owner-mpls@UU.NET Fri Apr 26 06:23:14 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28893 for ; Fri, 26 Apr 2002 06:23:13 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmfx06910; Fri, 26 Apr 2002 10:22:09 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmfx04812 for mpls-outgoing; Fri, 26 Apr 2002 10:21: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 QQmmfx04805 for ; Fri, 26 Apr 2002 10:21:46 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 QQmmfx01730 for ; Fri, 26 Apr 2002 10:20:52 GMT Received: from brahma01.netbrahma.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.70.67]) id QQmmfx12422 for ; Fri, 26 Apr 2002 10:20:45 GMT Received: by mailserver.netbrahma.com with Internet Mail Service (5.5.2653.19) id <2YYVY6D1>; Fri, 26 Apr 2002 15:49:42 +0530 Message-ID: <9027F68B07E7D511AE9400B0D0787DC007048E@mailserver.netbrahma.com> From: Manoj Agiwal To: "''Ccamp (E-mail)'" Cc: "'Gmpls-Ops (E-mail)'" , "'mpls@UU. NET (E-mail)'" Subject: GMPLS LSP Enc Type Date: Fri, 26 Apr 2002 15:49:36 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk The distinction between the LSP Enc type and G-PID is not very clear. For example if we map DS3 into STS1, do we use LSP Enc type as SONET or ANSI PDH. Similarly if we are mapping Ethernet into SONET frames then LSP Enc type should be SONET or Ethernet. Second Question is if I map Ethernet frames into SPE using LAPS, What value should G-PID carry. There are two values defined there, one for Ethernet and other for LAPS. From owner-mpls@UU.NET Fri Apr 26 08:46:29 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01695 for ; Fri, 26 Apr 2002 08:46:29 -0400 (EDT) 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 QQmmgg05127; Fri, 26 Apr 2002 12:44:24 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmgg29875 for mpls-outgoing; Fri, 26 Apr 2002 12:44:06 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 QQmmgg29870 for ; Fri, 26 Apr 2002 12:44:03 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 QQmmgg07688 for ; Fri, 26 Apr 2002 12:43:15 GMT Received: from roam.psg.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: H-135-207-10-70.research.att.com [135.207.10.70]) id QQmmgg03552 for ; Fri, 26 Apr 2002 12:43:15 GMT Received: from randy by roam.psg.com with local (Exim 4.04) id 17154A-0008Av-00; Fri, 26 Apr 2002 08:43:10 -0400 Approved: ops Message-ID: <9027F68B07E7D511AE9400B0D0787DC007048E@mailserver.netbrahma.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Manoj Agiwal To: "''Ccamp (E-mail)'" Cc: "'Gmpls-Ops (E-mail)'" , "'mpls@UU. NET (E-mail)'" Subject: GMPLS LSP Enc Type Date: Fri, 26 Apr 2002 15:49:36 +0530 Sender: owner-mpls@UU.NET Precedence: bulk The distinction between the LSP Enc type and G-PID is not very clear. For example if we map DS3 into STS1, do we use LSP Enc type as SONET or ANSI PDH. Similarly if we are mapping Ethernet into SONET frames then LSP Enc type should be SONET or Ethernet. Second Question is if I map Ethernet frames into SPE using LAPS, What value should G-PID carry. There are two values defined there, one for Ethernet and other for LAPS. From owner-mpls@UU.NET Fri Apr 26 09:45:58 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04117 for ; Fri, 26 Apr 2002 09:45:58 -0400 (EDT) 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 QQmmgk07004; Fri, 26 Apr 2002 13:44:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmgk26835 for mpls-outgoing; Fri, 26 Apr 2002 13:44:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmmgk26802 for ; Fri, 26 Apr 2002 13:44: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 QQmmgk00665 for ; Fri, 26 Apr 2002 13: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 QQmmgk26219 for ; Fri, 26 Apr 2002 13:44:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA10603 for ; Fri, 26 Apr 2002 09:44:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA24318 for mpls@uu.net; Fri, 26 Apr 2002 09:44:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmmgk26763 for ; Fri, 26 Apr 2002 13:43: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 QQmmgk13233 for ; Fri, 26 Apr 2002 13:42:50 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQmmgk05339 for ; Fri, 26 Apr 2002 13:42:50 GMT Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3QDgmU27653 for ; Fri, 26 Apr 2002 09:42:49 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA23922; Fri, 26 Apr 2002 15:42:48 +0200 (MET DST) Cc: "Gmpls-Ops (E-mail)" , ccamp@ops.ietf.org, "mpls@UU. NET (E-mail)" Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA23890; Fri, 26 Apr 2002 15:42:42 +0200 (MET DST) Message-ID: <3CC95952.335D8AAB@lucent.com> Date: Fri, 26 Apr 2002 15:42:42 +0200 From: Michiel van Everdingen Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Manoj Agiwal Original-CC: "Gmpls-Ops (E-mail)" , ccamp@ops.ietf.org, "mpls@UU. NET (E-mail)" Subject: Re: VT Switching References: <9027F68B07E7D511AE9400B0D0787DC007048C@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 Hello Manoj, What do you mean with 'neighbouring nodes' ? In my mind, VT switching matrices are neighbours if they are connected via some STS trail. This is just like STS switching matrices are neighbours if they are connected via some OC-n trail. See my proposal in http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00567.html to find out how VT switching matrices discover each other as neighbours. Hopefully the CCAMP WG will agree to add something like this in the LMP draft... Greetings, Michiel Manoj Agiwal wrote: > > [ post by non-subscriber ] > > Hi , > I want to estanlish a DS1 trail , using GMPLS signaling . > > The DS1 will get mapped to a single VT in a VTG , and will get > transferred to other end > using VT Switching . > > All the nodes particpating in the connection will do VT switching . > > Can I specify a VT by a single label , or I need to encode this > information ( STS->VTG->VT) in some > proprietary format which is understandable by neighbouring nodes . > > I would be interested in knowing how people do this . > > Regards , > Manoj > > > > > > > ------- end of forwarded message ------- -- +------------------------------------------------------------------+ | Michiel van Everdingen | | Systems Engineer | | Lucent Technologies - Optical Networking Group | | Botterstraat 45, 1271 XL Phone : +31 35 687 4883 | | P.O. Box 18, 1270 AA Fax : +31 35 687 5976 | | Huizen, The Netherlands mailto:MvanEverdingen@lucent.com | +------------------------------------------------------------------+ From owner-mpls@UU.NET Fri Apr 26 14:11:04 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19780 for ; Fri, 26 Apr 2002 14:11:04 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmhc03719; Fri, 26 Apr 2002 18:09:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmhc07701 for mpls-outgoing; Fri, 26 Apr 2002 18:09:37 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 QQmmhc07696 for ; Fri, 26 Apr 2002 18:09:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmmhc09328 for ; Fri, 26 Apr 2002 18:09:00 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f28.pav2.hotmail.com [64.4.37.28]) id QQmmhc00070 for ; Fri, 26 Apr 2002 18:08:59 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Apr 2002 11:08:58 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 26 Apr 2002 18:08:58 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Tunneling Date: Fri, 26 Apr 2002 18:08:58 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Apr 2002 18:08:58.0905 (UTC) FILETIME=[6FEB7090:01C1ED4D] Sender: owner-mpls@UU.NET Precedence: bulk Hi, Can I create a tunnel across OSPF areas? (Assuming that the ABR performs heavy routes aggregation) Thanx. -Tze Ven _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-mpls@UU.NET Sat Apr 27 05:25:39 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10072 for ; Sat, 27 Apr 2002 05:25:39 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmjl18826; Sat, 27 Apr 2002 09:24:33 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmjl11848 for mpls-outgoing; Sat, 27 Apr 2002 09:24: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 QQmmjl11843 for ; Sat, 27 Apr 2002 09:24: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 QQmmjl11049 for ; Sat, 27 Apr 2002 09:23:54 GMT From: weng.qing@zte.com.cn Received: from mail2.zte.com.cn by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [210.21.227.66]) id QQmmjl06179 for ; Sat, 27 Apr 2002 09:23:52 GMT To: mpls@UU.NET X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: Date: Sat, 27 Apr 2002 17:11:33 +0800 X-MIMETrack: Serialize by Router on notes_svr7_1/zte_ltd(Release 5.0.6a |January 17, 2001) at 2002-04-27 17:27:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk How to deal with MPLS VPN forwarding on ATM LSR ? in rfc3035,states "Except in certain circumstances specified below, when a labeled packet is transmitted on an LC-ATM interface, where the VPI/VCI (or VCID) is interpreted as the top label in the label stack, the packet MUST also contain a 'shim header' [3]. If the packet has a label stack with n entries, it MUST carry a shim with n entries. The actual value of the top label is encoded in the VPI/VCI field. The label value of the top entry in the shim (which is just a 'placeholder' entry) MUST be set to 0 upon transmission, and MUST be ignored upon reception. The packet's outgoing TTL, and its CoS, are carried in the TTL and CoS fields respectively of the top stack entry in the shim." So it means that if the packet has a label stack with n entries, the top entry in the shim is 0. When I send a VPN packet on an ATM ingress, I put VPN internal label in the shim label stack bottom entry,then out label is vpi/vci, I should put 0 in the shim label stack top entry; but this conflict with the following section: in RFC3032 states "A value of 0 represents the IPv4 Explicit NULL Label, This label value is only legal at the bottom of the label stack" What should I do on ATM LSR to support VPN ? From owner-mpls@UU.NET Sat Apr 27 05:57:11 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13290 for ; Sat, 27 Apr 2002 05:57:11 -0400 (EDT) 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 QQmmjn07419; Sat, 27 Apr 2002 09:55:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmjn13303 for mpls-outgoing; Sat, 27 Apr 2002 09:55:37 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 QQmmjn13298 for ; Sat, 27 Apr 2002 09:55:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmmjn24828 for ; Sat, 27 Apr 2002 09:55:11 GMT Received: from 21cn.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [61.140.60.248]) id QQmmjn06695 for ; Sat, 27 Apr 2002 09:55:10 GMT Received: from 21cn.com([10.2.1.6]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm43cca9dce; Sat, 27 Apr 2002 17:51:30 +0800 Received: from cmr1.ash.ops.us.uu.net([198.5.241.39]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm8a3cc59010; Tue, 23 Apr 2002 23:54:28 +0800 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 QQmlvr15032; Tue, 23 Apr 2002 15:49:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmlvr06533 for mpls-outgoing; Tue, 23 Apr 2002 15:48: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 QQmlvr06527 for ; Tue, 23 Apr 2002 15:48: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 QQmlvr23099 for ; Tue, 23 Apr 2002 15:48:09 GMT Received: from mailhost.avici.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host128.avici.com [208.246.215.128] (may be forged)) id QQmlvr09381 for ; Tue, 23 Apr 2002 15:48:09 GMT Received: from avici.com (swdev105.avici.com [10.2.21.105]) by mailhost.avici.com (8.11.0/8.11.0) with ESMTP id g3NFm0W04811; Tue, 23 Apr 2002 11:48:00 -0400 (EDT) Message-Id: <200204231548.g3NFm0W04811@mailhost.avici.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Markus Jork To: erosen@cisco.com cc: mpls@UU.NET Subject: Re: PHP In-reply-to: Your message of "Tue, 23 Apr 2002 11:17:25 EDT." <200204231517.LAA12825@erosen-u10.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Apr 2002 11:47:54 -0400 Sender: owner-mpls@UU.NET Precedence: bulk > Kireeti> One could use the 'check first nibble' hack :-( It would be neater > Kireeti> to use the L3PID. > > Eric> Well, I wouldn't want to have to set up a separate TE tunnel just to > Eric> handle the IPv6 traffic, so I'd recommend the "check first nibble" > Eric> hack. > > Actually, there is a real interoperability issue lurking here which we need > to get clear on. > > In conjunction with php, "check first nibble" could mean either of the > following: > > 1. The penultimate node pops the last label off the stack, creates a data > link layer frame with IPv4 as the protocol type, and transmits the frame. > The receiver of the frame checks the first nibble to see what the IP > version is and treats the packet as IPv4 or IPv6 depending on the IP > version. > > 2. The penultimate node pops the stack, checks the first nibble to see what > the IP version is, and creates a data link layer frame with either IPv4 > or IPv6 as the protocol type, depending on the value of the IP version > field. > > What I meant was 1; I'm not sure which Kireeti meant. > I certainly would have expected option 2! Markus From owner-mpls@UU.NET Sat Apr 27 16:32:09 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19724 for ; Sat, 27 Apr 2002 16:32:09 -0400 (EDT) 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 QQmmle08832; Sat, 27 Apr 2002 20:31:00 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmle16163 for mpls-outgoing; Sat, 27 Apr 2002 20:30: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 QQmmle16158 for ; Sat, 27 Apr 2002 20:30:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmmle11556 for ; Sat, 27 Apr 2002 20:30:33 GMT Received: from ihemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail1.lucent.com [192.11.222.161]) id QQmmle08191 for ; Sat, 27 Apr 2002 20:30:32 GMT Received: from bz0017exch001p.wins.lucent.com (h135-253-94-14.lucent.com [135.253.94.14]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g3RKUVI25282 for ; Sat, 27 Apr 2002 16:30:31 -0400 (EDT) Received: by BZ0017EXCH001P with Internet Mail Service (5.5.2650.21) id <26ZXGL73>; Sat, 27 Apr 2002 17:30:30 -0300 Message-ID: <49A5CB458910D411B73700508B676C5C05A8F40A@BZ0017EXCH002U> From: "Farias, Lavoisier Jose Leite (Lavoisier)" To: "'mpls@UU.net'" Subject: CAC Date: Sat, 27 Apr 2002 17:30:28 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Experts, I have a question regarding MPLS technology, and how an MPLS Network can allows QoS. Maybe my question is basic... The question is if MPLS LSR or LER has CAC (Call Admission Control) to guarantee QoS when LSPs when a CR-LDP or RSVP-TE RESV requested is received. I am familiar with ATM technology, so because that, I was thinking that there should be some kind of CAC to allows QoS at MPLS networks. Could you help me with this question ? Thank you in advance, Best Regards Lavoisier J.L.Farias From owner-mpls@UU.NET Sat Apr 27 18:15:02 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00420 for ; Sat, 27 Apr 2002 18:15:02 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmlk26221; Sat, 27 Apr 2002 22:13:47 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmlk04998 for mpls-outgoing; Sat, 27 Apr 2002 22:13:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmmlk04993 for ; Sat, 27 Apr 2002 22:13:21 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmmlk25531 for ; Sat, 27 Apr 2002 22:13:03 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmmlk01000 for ; Sat, 27 Apr 2002 22:13:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA29110 for ; Sat, 27 Apr 2002 18:13:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA02921 for mpls@uu.net; Sat, 27 Apr 2002 18:13:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmmlk04831 for ; Sat, 27 Apr 2002 22:11:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQmmlk15999 for ; Sat, 27 Apr 2002 22:11:34 GMT Received: from workhorse.fictitious.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQmmlk24206 for ; Sat, 27 Apr 2002 22:11:32 GMT Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id SAA90938; Sat, 27 Apr 2002 18:11:19 -0400 (EDT) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200204272211.SAA90938@workhorse.fictitious.org> To: "Farias, Lavoisier Jose Leite (Lavoisier)" cc: "'mpls@UU.net'" Reply-To: curtis@fictitious.org Subject: Re: CAC In-reply-to: Your message of "Sat, 27 Apr 2002 17:30:28 -0300." <49A5CB458910D411B73700508B676C5C05A8F40A@BZ0017EXCH002U> Date: Sat, 27 Apr 2002 18:11:19 -0400 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <49A5CB458910D411B73700508B676C5C05A8F40A@BZ0017EXCH002U>, "Farias, Lavoisier Jose Leite (Lavoisier)" writes: > Hi Experts, > > I have a question regarding MPLS technology, and how an MPLS Network can > allows QoS. Maybe my question is basic... > > The question is if MPLS LSR or LER has CAC (Call Admission Control) to > guarantee QoS when LSPs when a CR-LDP or RSVP-TE RESV requested is > received. CAC is supported but it may be the worst of the available ways to implement QoS. In the diffserv WG AF and EF services have been defined, though metering and priority queueing seems to do fine (and is very similar to EF). Preferred services are given preferential queueing treatment and the amount of preferred service is limited so as not to completely stomp on the less preferred services (worst effort service is not an acceptable service offering). The means to limit service can be "voluntary" on the part of the ingress. In that case some high limit is set (but usually not full bandwidth) and a lower voluntary limit is enforced by having the ingress avoid hot spots in the network, trying to spread its own load around. If all is configured well, except for occassional too fast attempts at recovery from a fault preemption or CAC limits should never take effect. The need to even attempt a very fast recovery is avoided using standby LSP at numerically higher setup/hold priorities, or doing the same with FRR. With standby or FRR, the initial recovery of primary LSPs after a fault can occur more slowly (since they are backed up) allowing better feedback to the set of ingress to acheive better initial layout. This avoids preemption of CAC. Backup LSP may not be an option if bandwidth is provisioned tightly, but overbooking of most traffic and temporary congestion is preferable to a mess where LSPs are rerouting too rapidly and CAC is causing failure of LSPs to come up until after numerous attempts. The circuit emulation LSPs have to be more strictly limited but LSPs carrying TCP would be better served being brought up quickly with some congestion followed by a period in which the layout is optimized and congestion is reduced or eliminated. Unlike in ATM the practical reality in MPLS networks is that in the face of catastrophy, congestion is something to be avoided but not bringing up some of the LSPs is not an option if one wants to stay in business. So CAC is to be avoided. A good example is the San Diego earthquake in the mid to late 1990s which affected the majority of fiber capacity to the area. Internet connections were congested but for all but emergency services and very high paying customers POTS and most swithced services was seen as "just plain broken" for a few days. (Somehow the phone carriers still claim 5 9s of reliability and the Chicago fire in the late 1980s didn't affect the 5 9s rating either). > I am familiar with ATM technology, so ... That's obvious and its half your problem. You can't just read a few MPLS documents and then assume that MPLS is just like ATM only the control plane and framing is different. > Thank you in advance, > > Best Regards > Lavoisier J.L.Farias Curtis ps - there is an FAQ at http://www.mplsrc.com/mplsfaq.shtml but it is brief and doesn't specifically address CAC. There could be an entire section on misconceptions about MPLS drawn from familiarity with ATM. From owner-mpls@UU.NET Mon Apr 29 07:58:25 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25949 for ; Mon, 29 Apr 2002 07:58:25 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmrf02474; Mon, 29 Apr 2002 11:55:54 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmrf27065 for mpls-outgoing; Mon, 29 Apr 2002 11:55: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 QQmmrf27046 for ; Mon, 29 Apr 2002 11:55: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 QQmmrf03427 for ; Mon, 29 Apr 2002 11:55: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 QQmmrf01053 for ; Mon, 29 Apr 2002 11:55:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA26793 for ; Mon, 29 Apr 2002 07:55:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA10887 for mpls@uu.net; Mon, 29 Apr 2002 07:55:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmmrf26979 for ; Mon, 29 Apr 2002 11:53:42 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 QQmmrf07283 for ; Mon, 29 Apr 2002 11:53:21 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 QQmmrf18731 for ; Mon, 29 Apr 2002 11:53:15 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25008; Mon, 29 Apr 2002 07:53:12 -0400 (EDT) Message-Id: <200204291153.HAA25008@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-08.txt Date: Mon, 29 Apr 2002 07:53:12 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Generalized MPLS - Signaling Functional Description Author(s) : L. Berger et al. Filename : draft-ietf-mpls-generalized-signaling-08.txt Pages : 32 Date : 26-Apr-02 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/SDH 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, and technology specific details are specified in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-08.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-08.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-08.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: <20020426141009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-signaling-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020426141009.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Apr 29 08:00:16 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26105 for ; Mon, 29 Apr 2002 08:00:14 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmrf02009; Mon, 29 Apr 2002 11:55:40 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmrf27056 for mpls-outgoing; Mon, 29 Apr 2002 11:55: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 QQmmrf27048 for ; Mon, 29 Apr 2002 11:55:17 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 QQmmrf01300 for ; Mon, 29 Apr 2002 11:55: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 QQmmrf01071 for ; Mon, 29 Apr 2002 11:55:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA26799 for ; Mon, 29 Apr 2002 07:55:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA10901 for mpls@uu.net; Mon, 29 Apr 2002 07:55:02 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmmrf26978 for ; Mon, 29 Apr 2002 11:53:42 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 QQmmrf07294 for ; Mon, 29 Apr 2002 11:53:21 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 QQmmrf18836 for ; Mon, 29 Apr 2002 11:53:20 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25024; Mon, 29 Apr 2002 07:53:17 -0400 (EDT) Message-Id: <200204291153.HAA25024@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-06.txt Date: Mon, 29 Apr 2002 07:53:17 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Generalized MPLS Signaling - CR-LDP Extensions Author(s) : P. Ashwood-Smith, L. Berger et al. Filename : draft-ietf-mpls-generalized-cr-ldp-06.txt Pages : 23 Date : 26-Apr-02 This document describes extensions to CR-LDP signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET/SDH 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. A generic functional description and an RSVP-TE specific description can be found in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-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-generalized-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-generalized-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: <20020426141019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-cr-ldp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020426141019.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Apr 29 09:00:00 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01914 for ; Mon, 29 Apr 2002 09:00:00 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmrf01312; Mon, 29 Apr 2002 11:55:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmrf27037 for mpls-outgoing; Mon, 29 Apr 2002 11:55:01 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQmmrf27026 for ; Mon, 29 Apr 2002 11:54:58 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmmrf09356 for ; Mon, 29 Apr 2002 11:54: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 QQmmrf00048 for ; Mon, 29 Apr 2002 11:54:03 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA26755 for ; Mon, 29 Apr 2002 07:54:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA10792 for mpls@uu.net; Mon, 29 Apr 2002 07:54:02 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmmrf26969 for ; Mon, 29 Apr 2002 11:53: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 QQmmrf21746 for ; Mon, 29 Apr 2002 11:53:25 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 QQmmrf18922 for ; Mon, 29 Apr 2002 11:53:25 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25049; Mon, 29 Apr 2002 07:53:23 -0400 (EDT) Message-Id: <200204291153.HAA25049@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-07.txt Date: Mon, 29 Apr 2002 07:53:22 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Generalized MPLS Signaling - RSVP-TE Extensions Author(s) : L. Berger et al. Filename : draft-ietf-mpls-generalized-rsvp-te-07.txt Pages : 40 Date : 26-Apr-02 This document describes extensions to RSVP-TE signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET/SDH 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 generic functional description and a CR-LDP specific description can be found in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-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-rsvp-te-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-rsvp-te-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: <20020426141028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-rsvp-te-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020426141028.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Apr 29 09:42:37 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07094 for ; Mon, 29 Apr 2002 09:42:37 -0400 (EDT) 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 QQmmrm15288; Mon, 29 Apr 2002 13:39:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmrm20397 for mpls-outgoing; Mon, 29 Apr 2002 13:39: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 QQmmrm20392 for ; Mon, 29 Apr 2002 13:39:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmmrm13882 for ; Mon, 29 Apr 2002 13:38: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 QQmmrm22742 for ; Mon, 29 Apr 2002 13:38:02 GMT Received: from erosen-u10.cisco.com (erosen-u10.cisco.com [161.44.134.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA01217 for ; Mon, 29 Apr 2002 09:38:02 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA21952 for mpls@uu.net; Mon, 29 Apr 2002 09:38:02 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmmrm20334 for ; Mon, 29 Apr 2002 13:37: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 QQmmrm28184 for ; Mon, 29 Apr 2002 13:36:33 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQmmrm21295 for ; Mon, 29 Apr 2002 13:36:32 GMT Received: (qmail 529 invoked by uid 104); 29 Apr 2002 13:36:32 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4199. . Clean. Processed in 0.454345 secs); 29 Apr 2002 13:36:32 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 29 Apr 2002 13:36:31 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g3TDaFp13959; Mon, 29 Apr 2002 06:36:24 -0700 (PDT) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Apr 2002 06:36:19 -0700 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A759@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'weng.qing@zte.com.cn'" , mpls@UU.NET Subject: RE: Date: Mon, 29 Apr 2002 06:36:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk The reason that a placeholder label entry is required is that the ATM header doesn't have any field to tell you whether there is any MPLS label underneath the ATM header. The S-bit of the placeholder label will do this job. As you said in normal MPLS forwarding label 0 is interpreted as explicit null label, but in ATM-LSRs, after the packet has been reassembled from the ATM cells, it is understood that for forwarding purpose the value of the top label is equal to VPI/VCI not 0. So for VPN purpose, you should encode your tunnel label in the VPI/VCI, then set the top shim entry to zero and set the bottom label to VC label. -Shahram > -----Original Message----- > From: weng.qing@zte.com.cn [mailto:weng.qing@zte.com.cn] > Sent: Saturday, April 27, 2002 5:12 AM > To: mpls@UU.NET > Subject: > > > > > How to deal with MPLS VPN forwarding on ATM LSR ? > > > in rfc3035,states "Except in certain circumstances specified below, > when a labeled packet is transmitted on an LC-ATM interface, > where the VPI/VCI (or VCID) is interpreted as the top label > in the label stack, the packet MUST also contain a 'shim > header' [3]. > If the packet has a label stack with n entries, it MUST > carry a shim > with n entries. The actual value of the top label is > encoded in the > VPI/VCI field. The label value of the top entry in the > shim (which > is just a 'placeholder' entry) MUST be set to 0 upon > transmission, > and MUST be ignored upon reception. The packet's > outgoing TTL, and > its CoS, are carried in the TTL and CoS fields > respectively of the > top stack entry in the shim." > > So it means that if the packet has a label stack with n > entries, the top > entry in the shim is 0. When I send a VPN packet on an ATM > ingress, I > put > VPN internal label in the shim label stack bottom > entry,then out label > is vpi/vci, > I should put 0 in the shim label stack top entry; > > but this conflict with the following section: > > in RFC3032 states "A value of 0 represents the IPv4 > Explicit NULL Label, > This label value is only legal at the bottom of the label stack" > > What should I do on ATM LSR to support VPN ? > From owner-mpls@UU.NET Mon Apr 29 14:57:27 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11267 for ; Mon, 29 Apr 2002 14:57:27 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmsh09861; Mon, 29 Apr 2002 18:53:35 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmsh09570 for mpls-outgoing; Mon, 29 Apr 2002 18:53:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQmmsh09565 for ; Mon, 29 Apr 2002 18:53:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQmmsh01373 for ; Mon, 29 Apr 2002 18:52:39 GMT Received: from newdev.harvard.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newdev.eecs.harvard.edu [140.247.60.212]) id QQmmsh15138 for ; Mon, 29 Apr 2002 18:52:39 GMT Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g3TIqLo08854; Mon, 29 Apr 2002 14:52:21 -0400 (EDT) Date: Mon, 29 Apr 2002 14:52:21 -0400 (EDT) From: Scott Bradner Message-Id: <200204291852.g3TIqLo08854@newdev.harvard.edu> To: mpls@UU.NET Subject: response to SG 13 Cc: bwijnen@lucent.com Sender: owner-mpls@UU.NET Precedence: bulk after reviewing the discussion on the draft response to SG 13 about draft-ohta-mpls-label-value-01.txt - I simplified the letter and just sent the following to Brian Moore (SG 13 chair) Scott ------------------ SOURCE: IETF Sub-IP Area - Scott Bradner, Area co-Director TITLE: Response to "Communication on the status of the request on the assignment of a reserved label value for MPLS OAM packet identification" The MPLS working group discussed SG 13's request for the assignment of a reserved label value for MPLS OAM packet identification (draft-ohta-mpls-label-value-01.txt) during the MPLS session during the recent IETF meeting in Minneapolis. There was some disagreement during the discussion about the long term implications of the IETF granting this request. During the discussion it was noted that there are a number of references to what might be modifications to IETF protocols in Y.1711. For example, Section 6.1 states, "Ideally this should be done automatically via LSP signaling at LSP set-up time (e.g. via a CR-LDP or RSVP control-plane mechanism), but it could also be configured manually." In order to understand the possible consequences of allocating an MPLS codepoint in response to the request in draft-ohta-mpls-label-value-01.txt the MPLS working group would like to understand the what modifications that SG13 may be assuming will be needed to other IETF protocols. (LDP, CR-LDP, RSVP, PIM and BGP have been suggested as IETF protocols that might be impacted.) A further concern is the potential impact on the MPLS forwarding plane as currently defined. In certain points in a MPLS network, based on an incoming label, the label is removed and the packet is forwarded with no further inspection of subsequent headers (be it another MPLS label or some other header). Y.1711 seems to imply that the above behavior would not satisfy Y.1711. Specifically, there are some cases where Y.1711 would expect a network element to intercept an OAM packet. Thus, the MPLS working group would like to understand if SG 13 thinks that Y.1711 assumes functionally that might raise issues of backward compatibility with existing MPLS systems and ASICs. From owner-mpls@UU.NET Mon Apr 29 15:08:12 2002 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11644 for ; Mon, 29 Apr 2002 15:08:12 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmsi28207; Mon, 29 Apr 2002 19:05:04 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmsi22388 for mpls-outgoing; Mon, 29 Apr 2002 19:04: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 QQmmsi22355 for ; Mon, 29 Apr 2002 19:04: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 QQmmsi05956 for ; Mon, 29 Apr 2002 19:04:09 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f59.law14.hotmail.com [64.4.21.59]) id QQmmsi07672 for ; Mon, 29 Apr 2002 19:04:09 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Apr 2002 12:04:08 -0700 Received: from 206.54.51.125 by lw14fd.law14.hotmail.msn.com with HTTP; Mon, 29 Apr 2002 19:04:08 GMT X-Originating-IP: [206.54.51.125] From: "Hitesh Kulkarni" To: mpls@UU.NET Subject: question about RESVTEAR processing Date: Mon, 29 Apr 2002 12:04:08 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 Apr 2002 19:04:08.0652 (UTC) FILETIME=[A3EC00C0:01C1EFB0] Sender: owner-mpls@UU.NET Precedence: bulk All, I have few doubts about resvtear processing.. From what i understand, on receiving a rtear msg, a node would delete the RSB and fwd the rtear msg if needed. I have the following doubts..Any help will be appreciated.. 1. In any given node, what is the impact of rtear processing on the corresponding PSB (if any..) 2. Does the ingress have to do anything special like tearing down the path or should it keep refreshing the path state inspite of receiving the rtear msg.. with regards, hitesh _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-mpls@UU.NET Mon Apr 29 23:41:39 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29049 for ; Mon, 29 Apr 2002 23:41:39 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmtq17619; Tue, 30 Apr 2002 03:36:52 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmtq07541 for mpls-outgoing; Tue, 30 Apr 2002 03:36: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 QQmmtq07536 for ; Tue, 30 Apr 2002 03:36:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmmtq05533 for ; Tue, 30 Apr 2002 03:35:23 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f38.law15.hotmail.com [64.4.23.38]) id QQmmtq21621 for ; Tue, 30 Apr 2002 03:35:23 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Apr 2002 20:35:22 -0700 Received: from 155.245.254.253 by lw15fd.law15.hotmail.msn.com with HTTP; Tue, 30 Apr 2002 03:35:22 GMT X-Originating-IP: [155.245.254.253] From: "Christopher Poh" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Hierarchical Routing Date: Tue, 30 Apr 2002 03:35:22 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Apr 2002 03:35:22.0794 (UTC) FILETIME=[0F22A0A0:01C1EFF8] Sender: owner-mpls@UU.NET Precedence: bulk Hi experts, I am currently pursuing my research study on traffic engineering with MPLS. I am interested in exploring into hierarchical routing that hides certain level of details about network topology when establishing a path. MPLS offers 2 solutions for this, namely, through explicit peering and implicit peering. My preference is towards implicit approach to avoid explosive number of remote peering. I consulted RFC 3031, but section 4.3 is quite brief about implicit peering and I am doubtful about its correct usage. I hope some experts out there can shed some light to my doubts. 1. Implicit peering is not possible for non-merging capable LSR domain. Is this true? 2. Given a border router, which is an egress LSR, originates a stack attribute for a label and distributes the information through implicit peering technique. i) How does the LSR manage the stack attribute? (my definition of 'manage' in this context is distributing the stack attribute when required and withdrawing it when not inuse). The RFC does not state this clearly. I find out that the originator of the stack attribute cannot easily determine whether the stack attribute is still being used by any LSR in the domain or not such that it may safely withdraw the attribute to conserve memory and/or label usage. Furthermore the originator cannot easily ensure that no LSR in the domain will ever continue to use the stack attribute after it has issued the withdrawal of the stack attribute unless there is a mechanism to guarantee this. In my opinion when the originator broadcast or multicast the withdrawal message, there may be some LSRs that may not receive it due to link failure or packet lost or etc. So this will create problems. ii) Section 3.27.5 of RFC3031 states that the intermediate LSRs need to store information about the label and its attribute even they do not require it. Is this a MUST? From my point of view an intermediate LSR may choose not to store the information provided that it does not use it because the stack attribute will never be visible when it relays any related tagged packets across. Am I missing important points here? 3. From label distibution protocol standpoint, how does a label be distributed with its stack attribute? I can't remember seeing this in LDP Specification. I would also appreciate if anyone could provide me some links to informative guidelines on implicit peering and its usage. Thank you in advance. -Chris _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-mpls@UU.NET Tue Apr 30 05:14:20 2002 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11227 for ; Tue, 30 Apr 2002 05:14:20 -0400 (EDT) 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 QQmmum02340; Tue, 30 Apr 2002 09:07:15 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmum13450 for mpls-outgoing; Tue, 30 Apr 2002 09:07: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 QQmmum13352 for ; Tue, 30 Apr 2002 09:06:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQmmum29775 for ; Tue, 30 Apr 2002 09:05:58 GMT Received: from tomp.smb.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQmmum01020 for ; Tue, 30 Apr 2002 09:05:57 GMT Received: from utfors.se ([172.20.0.78]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GVDITN00.DZC for ; Tue, 30 Apr 2002 11:10:35 +0200 Message-ID: <3CCE5E74.9070207@utfors.se> Date: Tue, 30 Apr 2002 11:05:56 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mpls wg Subject: WG Last call - draft-ietf-mpls-bundle-mib-01.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit This message initiates a two week WG last call on: Link Bundling Management Information Base With my liberal approach to weeks this last call ends May 15 at 2400 GMT. /Loa -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Tue Apr 30 08:06:47 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15198 for ; Tue, 30 Apr 2002 08:06:47 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmuy20691; Tue, 30 Apr 2002 12:04:28 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmuy23826 for mpls-outgoing; Tue, 30 Apr 2002 12:04: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 QQmmuy23819 for ; Tue, 30 Apr 2002 12:04: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 QQmmuy10102 for ; Tue, 30 Apr 2002 12:03:57 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f192.pav2.hotmail.com [64.4.37.192]) id QQmmuy00752 for ; Tue, 30 Apr 2002 12:03:57 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 Apr 2002 05:03:56 -0700 Received: from 155.245.254.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 30 Apr 2002 12:03:56 GMT X-Originating-IP: [155.245.254.253] From: "wu min" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: CSPF Date: Tue, 30 Apr 2002 12:03:56 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Apr 2002 12:03:56.0441 (UTC) FILETIME=[1AAFA890:01C1F03F] Sender: owner-mpls@UU.NET Precedence: bulk Hi, Is there any specific constraint shortest path first(CSPF) algorithm? I would be appreciated if someone could provide me some links. Thanx -Tze Ven _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-mpls@UU.NET Tue Apr 30 10:02:51 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20703 for ; Tue, 30 Apr 2002 10:02:50 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmvf29939; Tue, 30 Apr 2002 13:59:56 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmvf05188 for mpls-outgoing; Tue, 30 Apr 2002 13:59:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQmmvf05178 for ; Tue, 30 Apr 2002 13:59:36 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 QQmmvf11498 for ; Tue, 30 Apr 2002 13:59:10 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.168.79]) id QQmmvf08750 for ; Tue, 30 Apr 2002 13:59: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 JAA17237 for ; Tue, 30 Apr 2002 09:59:09 -0400 (EDT) Received: (erosen@localhost) by erosen-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA11649 for mpls@uu.net; Tue, 30 Apr 2002 09:59:09 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.ash.ops.us.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQmmtm10603 for ; Tue, 30 Apr 2002 02:32: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 QQmmtm03445 for ; Tue, 30 Apr 2002 02:31:34 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f172.law15.hotmail.com [64.4.23.172]) id QQmmtm13760 for ; Tue, 30 Apr 2002 02:31:33 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Apr 2002 19:31:33 -0700 Received: from 155.245.254.253 by lw15fd.law15.hotmail.msn.com with HTTP; Tue, 30 Apr 2002 02:31:32 GMT X-Originating-IP: [155.245.254.253] From: "Christopher Poh" To: mpls-ops@mplsrc.com, mpls@UU.NET Subject: Hierarchical Routing Date: Tue, 30 Apr 2002 02:31:32 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Apr 2002 02:31:33.0090 (UTC) FILETIME=[24742C20:01C1EFEF] Sender: owner-mpls@UU.NET Precedence: bulk Hi experts, I am currently pursuing my research study on traffic engineering with MPLS. I am interested in exploring into hierarchical routing that hides certain level of details about network topology when establishing a path. MPLS offers 2 solutions for this, namely, through explicit peering and implicit peering. My preference is towards implicit approach to avoid explosive number of remote peering. I consulted RFC 3031, but section 4.3 is quite brief about implicit peering and I am doubtful about its correct usage. I hope some experts out there can shed some light to my doubts. 1. Implicit peering is not possible for non-merging capable LSR domain. Is this true? 2. Given a border router, which is an egress LSR, originates a stack attribute for a label and distributes the information through implicit peering technique. i) How does the LSR manage the stack attribute? (my definition of 'manage' in this context is distributing the stack attribute when required and withdrawing it when not inuse). The RFC does not state this clearly. I find out that the originator of the stack attribute cannot easily determine whether the stack attribute is still being used by any LSR in the domain or not such that it may safely withdraw the attribute to conserve memory and/or label usage. Furthermore the originator cannot easily ensure that no LSR in the domain will ever continue to use the stack attribute after it has issued the withdrawal of the stack attribute unless there is a mechanism to guarantee this. In my opinion when the originator broadcast or multicast the withdrawal message, there may be some LSRs that may not receive it due to link failure or packet lost or etc. So this will create problems. ii) Section 3.27.5 of RFC3031 states that the intermediate LSRs need to store information about the label and its attribute even they do not require it. Is this a MUST? From my point of view an intermediate LSR may choose not to store the information provided that it does not use it because the stack attribute will never be visible when it relays any related tagged packets across. Am I missing important points here? 3. From label distibution protocol standpoint, how does a label be distributed with its stack attribute? I can't remember seeing this in LDP Specification. I would also appreciate if anyone could provide me some links to informative guidelines on implicit peering and its usage. Thank you in advance. -Chris _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-mpls@UU.NET Tue Apr 30 14:13:49 2002 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02231 for ; Tue, 30 Apr 2002 14:13:48 -0400 (EDT) Received: from mail-control.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.ash.ops.us.uu.net [153.39.10.50]) id QQmmvw14146; Tue, 30 Apr 2002 18:11:50 GMT Received: by mail-control.ash.ops.us.uu.net id QQmmvw06289 for mpls-outgoing; Tue, 30 Apr 2002 18:11: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 QQmmvw06282 for ; Tue, 30 Apr 2002 18:11:30 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 QQmmvw03703 for ; Tue, 30 Apr 2002 18:11:07 GMT Received: from hebe.or.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: jffdns02.or.intel.com [134.134.248.4]) id QQmmvw13338 for ; Tue, 30 Apr 2002 18:11:06 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by hebe.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.35 2002/04/27 00:24:14 root Exp $) with SMTP id g3UIB5B05043 for ; Tue, 30 Apr 2002 18:11:05 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002043011183124093 ; Tue, 30 Apr 2002 11:18:31 -0700 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 11:11:05 -0700 Message-ID: From: "Feng, Mark" To: "'Hitesh Kulkarni'" , mpls@UU.NET Subject: RE: question about RESVTEAR processing Date: Tue, 30 Apr 2002 11:10:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I think the answers are really implementation dependant. For the first question, I would say if the PSB is refering to the RSB, at minimum, the reference should be removed. As to the ingress node's behavior, it should do something:-). Leaving the Path refreshes indefinitely without receiving the Resv seems to be wasting resources, unless there are some reasons to do so. Hope this helps. - Mark > -----Original Message----- > From: Hitesh Kulkarni [mailto:hkulk@hotmail.com] > Sent: Monday, April 29, 2002 12:04 PM > To: mpls@UU.NET > Subject: question about RESVTEAR processing > > > All, > > I have few doubts about resvtear processing.. > > From what i understand, on receiving a rtear msg, a node > would delete the > RSB and fwd the rtear msg if needed. I have the following > doubts..Any help > will be appreciated.. > > 1. In any given node, what is the impact of rtear processing on the > corresponding PSB (if any..) > > 2. Does the ingress have to do anything special like tearing > down the path > or should it keep refreshing the path state inspite of > receiving the rtear > msg.. > > with regards, > hitesh > > > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com >