From owner-mpls@UU.NET Mon Jan 1 07:49:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26996 for ; Mon, 1 Jan 2001 07:49:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwbz26472; Mon, 1 Jan 2001 12:48:12 GMT Received: by mail-control.mail.uu.net id QQjwbz28825 for mpls-outgoing; Mon, 1 Jan 2001 12:47:48 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwbz28820 for ; Mon, 1 Jan 2001 12:47: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 QQjwbz10630 for ; Mon, 1 Jan 2001 12:46:44 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwbz10341 for ; Mon, 1 Jan 2001 12:46:43 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA08198 for mpls@uu.net; Mon, 1 Jan 2001 07:46:43 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwbz28717 for ; Mon, 1 Jan 2001 12:46:15 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjwbz07713 for ; Mon, 1 Jan 2001 12:45:51 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjwbz23222 for ; Mon, 1 Jan 2001 12:45:51 GMT Received: from cisco.com (war-jer-dhcp82.cisco.com [144.254.89.252]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id EAA04182; Mon, 1 Jan 2001 04:45:45 -0800 (PST) Message-ID: <3A507D9C.68CE6C29@cisco.com> Date: Mon, 01 Jan 2001 04:52:44 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rijsman, Bruno" CC: Yakov Rekhter , "'mpls@UU.NET'" , "BGP exploder (E-mail)" , "IDRP exploder (E-mail)" Subject: Re: Encoding of MPLS label in MP-REACH-NLRI question References: <49FF5C6DDBD8D311BBBD009027DE980CC11D8A@uniwest1.redstonecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit True Bruno, I think it would indeed benefit all current mpls-vpn customers the most (they should speak up here) not vendors if they prefer to mess with per neighbour knobs either on the cisco side or any other vendor's side or simply support adjusting the draft a bit. R. > "Rijsman, Bruno" wrote: > > I would not be opposed to changing both draft-rosen-rfc2547bis-02 and > draft-ietf-mpls-bgp4-mpls-04 to say that the label should be encoded as > "label.0001" instead of "1000.label". > > If we keep the drafts the way they are now, then any vendor who wants to > comply with the draft *and* interoperate with Cisco must have a knob to > select between the two encodings ("neighbor ... shifted-label-encoding"?), > and I don't see how that would benefit anyone. > > -- Bruno. > > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: Sunday, December 31, 2000 7:53 AM > To: Yakov Rekhter > Cc: Rijsman, Bruno; 'mpls@UU.NET'; BGP exploder (E-mail); IDRP exploder > (E-mail) > Subject: Re: Encoding of MPLS label in MP-REACH-NLRI question > > Yakov & Bruno, > > draft-ietf-mpls-bgp4-mpls-04.txt says: > > b) Label: > > The Label field carries one or more labels (that corresponds to > the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 > octets, where the high-order bit contains "Bottom of Stack" (as > defined in [MPLS-ENCAPS]). The following high-order three bits > must be zero. The remaining 20 bits contain the label value. > > while [MPLS-ENCAPS] draft-ietf-mpls-label-encaps-08.txt defines it as: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Label > | Label | Exp |S| TTL | > Stack > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Entry > > Label: Label Value, 20 bits > Exp: Experimental Use, 3 bits > S: Bottom of Stack, 1 bit > TTL: Time to Live, 8 bits > > So I think what happened was that Cisco followed the label encapsulation > draft rather then the encoding description in Carrying Label Information > in BGP-4 draft. The shipping encoding is as Bruno observed following: > > * +---------------------------+ > * | Length (1 octet) | > * +---------------------------+ > * | Label (3 octets) | > * +---------------------------+ > * ............................. > * +---------------------------+ > * | Prefix (variable) | > * +---------------------------+ > * > * That is: > * 1 octet for the length in bits of the NLRI > * A tag(label) stack where each stack item is represented by 3 > octets > * according to draft-ietf-mpls-lable_encaps-01.txt: > * 20 bits of tag, 3 bits of COS, 1 bit bottom of tag(label) > stack. > * The prefix. > > The reason being was that the code for this was written before the first > issue of the draft bgp4-mpls-00 which came out in April-1998. We may > call it a bug or not but the facts are that the only widely deployed > implementation of L3 mpls-vpns is cisco's at this point and changing the > current encoding will be quite hard. > > Yakov, > > > Looks like a bug to me, as without setting the bottom-of-stack to > > 1, there is no way to find out how many labels are carried in the > > As you see we set the S bit, but in the way Label.0001 rather then > 1000.Label > > R. > > > Yakov Rekhter wrote: > > > > Bruno, > > > > > A brief question about draft-rosen-rfc-2547bis-02: > > > > > > What is the proper encoding of an MPLS label in a labeled vpnv4 prefix > in an > > > MP-REACH-NLRI attribute? Draft-rosen-rfc2547bis-02 refers to > > > draft-ietf-mpls-bgp4-mpls-04 which says that the "label is encoded as 3 > > > octets, where the high-order bit contains bottom-of-stack. The following > > > high-order three bits must be zero. The remaining 20 buts contain the > label > > > value." > > > > > > Given this, I would expect label 1000 (decimal) to be encoded as > 80.03.e8 > > > (hex). However, one major vendor encodes it as 00.3e.81 (hex). > Similarly, I > > > would expect label 28 (decimal) to be encoded as 80.00.1c (hex) but the > > > major vendor encodes it as 00.01.c1 (hex). > > > > > > Am I missing something, or does the vendor have a bug? > > > > Looks like a bug to me, as without setting the bottom-of-stack to > > 1, there is no way to find out how many labels are carried in the > > MP_REACH_NLRI, and therefore no way to find out where the address > > prefix part of MPL_REACH_NLRI begins. > > > > Yakov. From owner-mpls@UU.NET Tue Jan 2 09:33:33 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18103 for ; Tue, 2 Jan 2001 09:33:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwfy28101; Tue, 2 Jan 2001 14:32:35 GMT Received: by mail-control.mail.uu.net id QQjwfy02814 for mpls-outgoing; Tue, 2 Jan 2001 14:32:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwfy02798 for ; Tue, 2 Jan 2001 14:31:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjwfx11725 for ; Tue, 2 Jan 2001 14:26:19 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 QQjwfx19170 for ; Tue, 2 Jan 2001 14:26:18 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA28629 for ; Tue, 2 Jan 2001 06:26:28 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA03113 for mpls@uu.net; Tue, 2 Jan 2001 09:26:17 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjvyt13959 for ; Sun, 31 Dec 2000 15:49: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 QQjvyt20183 for ; Sun, 31 Dec 2000 15:49:17 GMT Received: from uniwest1.redstonecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [199.105.223.130]) id QQjvyt18156 for ; Sun, 31 Dec 2000 15:49:17 GMT Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Sun, 31 Dec 2000 10:49:17 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980CC11D8A@uniwest1.redstonecom.com> From: "Rijsman, Bruno" To: "'Robert Raszuk'" , Yakov Rekhter Cc: "'mpls@UU.NET'" , "BGP exploder (E-mail)" , "IDRP exploder (E-mail)" Subject: RE: Encoding of MPLS label in MP-REACH-NLRI question Date: Sun, 31 Dec 2000 10:49:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I would not be opposed to changing both draft-rosen-rfc2547bis-02 and draft-ietf-mpls-bgp4-mpls-04 to say that the label should be encoded as "label.0001" instead of "1000.label". If we keep the drafts the way they are now, then any vendor who wants to comply with the draft *and* interoperate with Cisco must have a knob to select between the two encodings ("neighbor ... shifted-label-encoding"?), and I don't see how that would benefit anyone. -- Bruno. -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com] Sent: Sunday, December 31, 2000 7:53 AM To: Yakov Rekhter Cc: Rijsman, Bruno; 'mpls@UU.NET'; BGP exploder (E-mail); IDRP exploder (E-mail) Subject: Re: Encoding of MPLS label in MP-REACH-NLRI question Yakov & Bruno, draft-ietf-mpls-bgp4-mpls-04.txt says: b) Label: The Label field carries one or more labels (that corresponds to the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 octets, where the high-order bit contains "Bottom of Stack" (as defined in [MPLS-ENCAPS]). The following high-order three bits must be zero. The remaining 20 bits contain the label value. while [MPLS-ENCAPS] draft-ietf-mpls-label-encaps-08.txt defines it as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label | Label | Exp |S| TTL | Stack +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry Label: Label Value, 20 bits Exp: Experimental Use, 3 bits S: Bottom of Stack, 1 bit TTL: Time to Live, 8 bits So I think what happened was that Cisco followed the label encapsulation draft rather then the encoding description in Carrying Label Information in BGP-4 draft. The shipping encoding is as Bruno observed following: * +---------------------------+ * | Length (1 octet) | * +---------------------------+ * | Label (3 octets) | * +---------------------------+ * ............................. * +---------------------------+ * | Prefix (variable) | * +---------------------------+ * * That is: * 1 octet for the length in bits of the NLRI * A tag(label) stack where each stack item is represented by 3 octets * according to draft-ietf-mpls-lable_encaps-01.txt: * 20 bits of tag, 3 bits of COS, 1 bit bottom of tag(label) stack. * The prefix. The reason being was that the code for this was written before the first issue of the draft bgp4-mpls-00 which came out in April-1998. We may call it a bug or not but the facts are that the only widely deployed implementation of L3 mpls-vpns is cisco's at this point and changing the current encoding will be quite hard. Yakov, > Looks like a bug to me, as without setting the bottom-of-stack to > 1, there is no way to find out how many labels are carried in the As you see we set the S bit, but in the way Label.0001 rather then 1000.Label R. > Yakov Rekhter wrote: > > Bruno, > > > A brief question about draft-rosen-rfc-2547bis-02: > > > > What is the proper encoding of an MPLS label in a labeled vpnv4 prefix in an > > MP-REACH-NLRI attribute? Draft-rosen-rfc2547bis-02 refers to > > draft-ietf-mpls-bgp4-mpls-04 which says that the "label is encoded as 3 > > octets, where the high-order bit contains bottom-of-stack. The following > > high-order three bits must be zero. The remaining 20 buts contain the label > > value." > > > > Given this, I would expect label 1000 (decimal) to be encoded as 80.03.e8 > > (hex). However, one major vendor encodes it as 00.3e.81 (hex). Similarly, I > > would expect label 28 (decimal) to be encoded as 80.00.1c (hex) but the > > major vendor encodes it as 00.01.c1 (hex). > > > > Am I missing something, or does the vendor have a bug? > > Looks like a bug to me, as without setting the bottom-of-stack to > 1, there is no way to find out how many labels are carried in the > MP_REACH_NLRI, and therefore no way to find out where the address > prefix part of MPL_REACH_NLRI begins. > > Yakov. From owner-mpls@UU.NET Tue Jan 2 15:17:53 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22354 for ; Tue, 2 Jan 2001 15:17:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwgv04872; Tue, 2 Jan 2001 20:16:59 GMT Received: by mail-control.mail.uu.net id QQjwgv12084 for mpls-outgoing; Tue, 2 Jan 2001 20:16:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwgv12062 for ; Tue, 2 Jan 2001 20:16:00 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 QQjwgv24445 for ; Tue, 2 Jan 2001 20:15:49 GMT From: James_Huang@Mitel.COM Received: from Mitel.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newgate.mitel.com [198.53.180.100]) id QQjwgv26065 for ; Tue, 2 Jan 2001 20:15:48 GMT Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id PAA24517 for ; Tue, 2 Jan 2001 15:15:47 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 852569C8.006F4B46 ; Tue, 2 Jan 2001 15:15:37 -0500 X-Lotus-FromDomain: MITEL To: mpls@UU.NET Message-ID: <852569C8.006F4AC3.00@kanmta01.software.mitel.com> Date: Tue, 2 Jan 2001 12:15:36 -0800 Subject: Questions on multiprovider VPN operations in RFC2547bis Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hello, RFC2547bis supports multiprovider VPNs in which a VPN customer has two sites each served by a distinct VPN service provider. The VPN service providers serving the customer are themselves served by yet another VPN service provider. Suppose we have the following VPN deployment, CE1 --- (PE11 -- P1 -- PE12) == (PE21 -- P2 -- PE22) == (PE31 -- P3 -- PE32) -- CE2 PE11, P1, and PE12 are in AS1, PE21, P2, and PE22 are in AS2, and PE31, P3, and PE32 are in AS3. Assuming that P1 and P3 are route reflectors and are talking EBGP to each other. So when PE32 advertises a VPN-ipv4 route for CE2 to P3, P3 will in turn advertise the route to P1. When P1 receives the advertisement, it will then send the advertisement to PE11 and PE12. Here are my questions: (1) A VPN service provider can assign route distinguisher (RD) at its own discretion. So the VPN customer's RD in AS1 will likely be different from its RD in AS3. When P1 receives the VPN-ipv4 route advertisement from P3, does the RD in the advertisement need to be converted first before being sent to PE11 and PE12? (2) How about route target extended communities? Do they need to be converted too? (3) Can anyone show me a detailed diagram with both the control plane set-up and the data plane forwarding for the above VPN deployment scenario? Regards, -- James Huang From owner-mpls@UU.NET Tue Jan 2 15:38:31 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22509 for ; Tue, 2 Jan 2001 15:38:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwgw28306; Tue, 2 Jan 2001 20:37:32 GMT Received: by mail-control.mail.uu.net id QQjwgw13621 for mpls-outgoing; Tue, 2 Jan 2001 20:36:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwgw13616 for ; Tue, 2 Jan 2001 20:36:42 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 QQjwgw16072 for ; Tue, 2 Jan 2001 20:33:40 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjwgw02145 for ; Tue, 2 Jan 2001 20:33:39 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id MAA02597; Tue, 2 Jan 2001 12:33:39 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id MAA73191; Tue, 2 Jan 2001 12:33:39 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200101022033.MAA73191@garnet.juniper.net> To: James_Huang@Mitel.COM cc: mpls@UU.NET Subject: Re: Questions on multiprovider VPN operations in RFC2547bis In-Reply-To: Your message of "Tue, 02 Jan 2001 12:15:36 PST." <852569C8.006F4AC3.00@kanmta01.software.mitel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <73188.978467618.1@garnet.juniper.net> Date: Tue, 02 Jan 2001 12:33:39 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk James, > RFC2547bis supports multiprovider VPNs in which a VPN customer has two > sites each served by a distinct VPN service provider. The VPN service provid ers > serving the customer are themselves served by yet another VPN service provide r. > Suppose we have the following VPN deployment, > > CE1 --- (PE11 -- P1 -- PE12) == (PE21 -- P2 -- PE22) == (PE31 > -- P3 -- PE32) -- CE2 > > PE11, P1, and PE12 are in AS1, PE21, P2, and PE22 are in AS2, and PE31, P3, a nd > PE32 are in AS3. > Assuming that P1 and P3 are route reflectors and are talking EBGP to each > other. So when PE32 advertises a VPN-ipv4 route for CE2 to P3, P3 will in tu rn > advertise the route to P1. When P1 receives the advertisement, it will then > send the advertisement to PE11 and PE12. > > Here are my questions: > (1) A VPN service provider can assign route distinguisher (RD) at its own > discretion. Correct. > So the VPN customer's RD in AS1 will likely be different from its > RD in AS3. Correct too. > When P1 receives the VPN-ipv4 route advertisement from P3, does the > RD in the advertisement need to be converted first before being sent to PE11 > and PE12? No, it does not *need* to be converted. However, P1 *may* do the conversion. > (2) How about route target extended communities? Do they need to be > converted too? The same applies to route targets. They need not be converted by P1. But P1 *may* do the conversion. Yakov. From owner-mpls@UU.NET Tue Jan 2 15:46:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22566 for ; Tue, 2 Jan 2001 15:46:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwgw10661; Tue, 2 Jan 2001 20:44:42 GMT Received: by mail-control.mail.uu.net id QQjwgw14021 for mpls-outgoing; Tue, 2 Jan 2001 20:44:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwgw14015 for ; Tue, 2 Jan 2001 20:44:01 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 QQjwgw23638 for ; Tue, 2 Jan 2001 20:42:33 GMT Received: from web11406.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11406.mail.yahoo.com [216.136.131.236]) id QQjwgw07493 for ; Tue, 2 Jan 2001 20:42:33 GMT Message-ID: <20010102204233.1737.qmail@web11406.mail.yahoo.com> Received: from [132.177.121.21] by web11406.mail.yahoo.com; Tue, 02 Jan 2001 12:42:33 PST Date: Tue, 2 Jan 2001 12:42:33 -0800 (PST) From: John Sparr Subject: ERO and strict/loose subobject To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi all, One question about the ERO object in RSVP: Assuming there is a sender node and it creates an ERO. Should the ERO include the ip address of sender itself? If yes, why? Another question is about strict/loose object: The draft of RSVP-TE says "The path between a strict node and its preceding node MUST include only network nodes from the strict node and its preceding abstract node." Does it mean if there is strict subobject in ERO, then ther is no loose subobject and if there is loose subobject, then there is no strict subobject? Thanks a lot John __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From owner-mpls@UU.NET Tue Jan 2 16:00:11 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22609 for ; Tue, 2 Jan 2001 16:00:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwgx00537; Tue, 2 Jan 2001 20:58:39 GMT Received: by mail-control.mail.uu.net id QQjwgx15051 for mpls-outgoing; Tue, 2 Jan 2001 20:58:03 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwgx15043 for ; Tue, 2 Jan 2001 20:57:58 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 QQjwgx01532 for ; Tue, 2 Jan 2001 20:55:50 GMT Received: from scallop.baynetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns5.baynetworks.com [194.133.90.101]) id QQjwgx07086 for ; Tue, 2 Jan 2001 20:55:49 GMT Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by scallop.baynetworks.com (8.9.1/8.9.1) with ESMTP id WAA04436 for ; Tue, 2 Jan 2001 22:02:40 +0100 (MET) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id PAA05923; Tue, 2 Jan 2001 15:55:15 -0500 (EST) Received: from dfedyk-new.ca.nortel.com (dhcp225-54 [192.32.225.54]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id PAA17737; Tue, 2 Jan 2001 15:55:14 -0500 for Message-Id: <3.0.1.32.20010102155810.0072c11c@pobox.engeast.baynetworks.com> X-Sender: dwfedyk@pobox.engeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 02 Jan 2001 15:58:10 -0500 To: jboyle@Level3.net From: Don Fedyk Subject: RE: drat-martini-l2circuit-enacap/trans-mpls Cc: mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Jim Please see response below: > > On Tue, 19 Dec 2000, Don Fedyk wrote: > > > Shahram and Luca > > > > draft-stdenis-ms-over-mpls-00.txt details how OAM cells can > be handled. > > Please have a look. There is also an extensive requirements > section that > > outlines what requirements we wanted to satisfy. Among the > requiremnets > > was: no compromise to the ATM capabilities. This is one of > the reasons > > Don - I don't see that requirement int your document, are you > intending to > add verbiage in the draft to show how one performs the > necessary service > interworking for this MPLS cloud to interwork with the ATM cloud and > maintain conformance to, for instance, TM4.0? And what is the proper > forum for such activity? The point I was making was that we chose _data_plane_ encapsulations that allow network interworking and include the transmission of OAM cells. Then if we chose in the future to build systems have signaling interworking we could do that. Our draft takes the stance that initially this will be configured. As to the forum where this would be carried out I was hoping it would be the IETF for the MPLS portions due to the initial the scope. Don > > Jim > > > it was over MPLS not just any transport. > > > > Don > > > http://www.ietf.org/internet-drafts/draft-stdenis-ms-over-mpls-00.txt > > > > > > > -----Original Message----- > > > From: Luca Martini [mailto:luca@level3.net] > > > Sent: Monday, December 18, 2000 7:24 PM > > > To: Shahram Davari > > > Cc: 'mpls@uu.net' > > > Subject: Re: drat-martini-l2circuit-enacap/trans-mpls > > > > > > > > > Shahram Davari wrote: > > > > > > > > Hi, > > > > > > > > I have some questions from the authors of these drafts. > > > > > > > > 1) Section 5.2.1 of the Encap draft says: > > > > > > > > "A router that does not support transport of OAM cells > > > MUST discard incoming MPLS frames on an ATM VC LSP that > > > contain an ATM cell with the high-order bit of the PTI set to 1". > > > > > > > > Since in the MPLS network, only the ingress LSR and egress > > > LSR are ware of the existence of OAM cells, and since the > > > egress LSR does not need to do any thing special for the > > > received OAM cells from the user data cells, I assume by > > > "router" the authors mean ingress LSR. If so then why does it > > > says "incoming MPLS frames"? > > > > > > > yes, this slipped in. It's wrong . I'll fix it. > > > > > > > 2) Section 4.2.1 of the Trans draft says: > > > > > > > > "A router that does not support transport of ATM cells MUST > > > discard incoming MPLS frames on an ATM VC LSP that contain a > > > control word with the T bit set. > > > > > > > > This section looks very similar to section 5.2.1 of the > > > Encap draft, while this specific sentence is completely > > > different. Is there a mistake or it is correct? If it is > > > correct then why is this subject in the OAM section? Sine the > > > sentence is talking about received MPLS frames, it seems that > > > it is talking about an egress LSR, but why should an egress > > > LSR that can't support ATM distribute the VC label in the > first place? > > > > > > > it a mistake in the text of the draft. > > > > > > > > > > 3) Section 5.2.1 of Encap draft and section 4.2.1 of Trans > > > draft say: > > > > "The LSR MAY optionally be configured to periodically > > > generate F5 end-to-end loop back OAM cells on a VC. ... If > > > the LSR fails to receive a response to an F5 end-to-end loop > > > back OAM cell for a pre-defined period of time it MUST > > > withdraw the label mapping for the VC." > > > > Is this talking about ingress LSR or egress LSR? > > > Both. > > > As both ends can be configured to do end to end loopback > oam cells. In > > > this model you must consider the ATM network as to separate > > > ATM network > > > with a "strange" link in the middle ( the MPSL network ). So > > > end to end > > > means LSR to ATM device. > > > > > > > > > > > > > 4) Section 5.2.1 of Encap draft and section 4.2.1 of Trans > > > draft say: > > > > "If an ingress LSR receives an AIS F5 OAM cell, fails to > > > receive a pre-defined number of the End-to-End loop OAM > > > cells, or a physical interface goes down, it MUST withdraw > > > the label mappings for all VCs associated with the failure. > > > When a VC label mapping is withdrawn, the egress LSR SHOULD > > > generate AIS F5 OAM cells on the VC associated with the > > > withdrawn label mapping. " > > > > I always thought that LDP label withdrawal is initiated > > > from downstream (egress). Could you please explain how the > > > ingress LSR can withdraw a label that doesn't belong to it? > > > > > > > In order to make the LSP bi-directional , and LSR must have a > > > label for > > > VC/GR id in both directions. If one direction is > withdrawn the circuit > > > goes down. So the LSr withdraw a label that he has advertised , > > > resulting in the upstream router generating AIS F5 OAM cells. > > > > > > > 5) Section 5.2.1 of Encap draft says: > > > > > > > > "A router that supports transport of OAM cells MUST follow > > > the procedures outlined in [7] section 8 for mode 0 only" > > > > I think it needs to be mentioned that performance OAM cells > > > can't be used with the AAL5 based transmission (due to > > > possible displacement). > > > Yes, this has been changed in the future version of the draft. > > > > > > Thanks. > > > Luca > > > > > > > > > > Regards, > > > > Shahram Davari > > > > Systems Engineer > > > > Product Research Group > > > > PMC-Sierra, Inc. (Ottawa) > > > > Phone: (613) 271-4018 > > > > Fax: (613) 271-7007 > > > > > > -- > > > Just say no to summer. Ski all year ! > > > Luca Martini Senior Network Architect, Level 3 Communications - > > > Broomfield, CO > > > luca@level3.net | VE2WKR/W0 | Phone 720-888-1225 | pager > > > page-luca@level3.net > > > > > > > From owner-mpls@UU.NET Tue Jan 2 16:27:18 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22863 for ; Tue, 2 Jan 2001 16:27:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwgz23788; Tue, 2 Jan 2001 21:26:03 GMT Received: by mail-control.mail.uu.net id QQjwgz28939 for mpls-outgoing; Tue, 2 Jan 2001 21:25:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwgz28934 for ; Tue, 2 Jan 2001 21:25: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 QQjwgz08886 for ; Tue, 2 Jan 2001 21:23:57 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwgz20619 for ; Tue, 2 Jan 2001 21:23:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA19825 for mpls@uu.net; Tue, 2 Jan 2001 16:23:55 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwgz28817 for ; Tue, 2 Jan 2001 21:23: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 QQjwgz08556 for ; Tue, 2 Jan 2001 21:18:56 GMT Received: from xover.hjinc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjwgz12755 for ; Tue, 2 Jan 2001 21:18:56 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 16:16:58 -0500 Message-ID: <87009604743AD411B1F600508BA0F959040D1C@xover.hjinc.com> From: "Sanford, Bill" To: "'John Sparr'" , mpls@UU.NET Subject: RE: ERO and strict/loose subobject Date: Tue, 2 Jan 2001 16:16:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk John, see the comments below: > -----Original Message----- > From: John Sparr [mailto:johnll44@yahoo.com] > Sent: Tuesday, January 02, 2001 3:43 PM > To: mpls@UU.NET > Subject: ERO and strict/loose subobject > > > Hi all, > > One question about the ERO object in RSVP: > > Assuming there is a sender node and it creates an ERO. > Should the ERO include the ip address of sender > itself? If yes, why? Lets say the ERO is not set with the sender node and is started on the next hop. How does the LSP you want to set up know that there are no other hops in between the sender and next hop? If you don't have the senders ip address as the first subobject, there isn't any way to set the properties of the link to the next hop to loose or strict. In the implementation in draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you didn't have the sender address in the ERO, it would immediately error with "Bad EXPLICIT_ROUTE object" error. In 4.3.4.1. Selection of the Next Hop, it explains: 1) The node receiving the RSVP message MUST first evaluate the first subobject. If the node is not part of the abstract node described by the first subobject, it has received the message in error and SHOULD return a "Bad initial subobject" error. If there is no first subobject, the message is also in error and the system SHOULD return a "Bad EXPLICIT_ROUTE object" error. > > Another question is about strict/loose object: > > The draft of RSVP-TE says "The path between a strict > node and its preceding node MUST include only network > nodes from the strict node and its preceding abstract > node." > > Does it mean if there is strict subobject in ERO, then > ther is no loose subobject and if there is loose > subobject, then there is no strict subobject? Not at all. You can have both strict hops and loose hops as part of the same ERO. On a "strict" hop link, there isn't any other route it can take except for the next hop in the ERO list. On a "loose" hop link, there can be additional hops between the nodes provided that it ends up on the next hop. Bill From owner-mpls@UU.NET Tue Jan 2 16:46:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23032 for ; Tue, 2 Jan 2001 16:46:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwha11461; Tue, 2 Jan 2001 21:44:48 GMT Received: by mail-control.mail.uu.net id QQjwha00452 for mpls-outgoing; Tue, 2 Jan 2001 21:44:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwha00445 for ; Tue, 2 Jan 2001 21:44:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjwha05114 for ; Tue, 2 Jan 2001 21:43:33 GMT From: James_Huang@Mitel.COM Received: from Mitel.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newgate.mitel.com [198.53.180.100]) id QQjwha08513 for ; Tue, 2 Jan 2001 21:43:33 GMT Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id QAA03065; Tue, 2 Jan 2001 16:43:32 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 852569C8.007754EA ; Tue, 2 Jan 2001 16:43:25 -0500 X-Lotus-FromDomain: MITEL To: Yakov Rekhter cc: mpls@UU.NET Message-ID: <852569C8.0077535C.00@kanmta01.software.mitel.com> Date: Tue, 2 Jan 2001 13:43:21 -0800 Subject: Re: Questions on multiprovider VPN operations in RFC2547bis Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk From: James Huang@MITEL on 01/02/2001 01:43 PM PST Yakov, Should P1 always convert the RD if the RD for the customer in AS1 and AS3 are different? Or is it P3's responsibility to do the conversion? One of them should do it, right? -- James Huang Yakov Rekhter on 01/02/2001 12:33:39 PM To: James Huang/USA/Mitel@Mitel cc: mpls@UU.NET Subject: Re: Questions on multiprovider VPN operations in RFC2547bis James, > RFC2547bis supports multiprovider VPNs in which a VPN customer has two > sites each served by a distinct VPN service provider. The VPN service provid ers > serving the customer are themselves served by yet another VPN service provide r. > Suppose we have the following VPN deployment, > > CE1 --- (PE11 -- P1 -- PE12) == (PE21 -- P2 -- PE22) == (PE31 > -- P3 -- PE32) -- CE2 > > PE11, P1, and PE12 are in AS1, PE21, P2, and PE22 are in AS2, and PE31, P3, a nd > PE32 are in AS3. > Assuming that P1 and P3 are route reflectors and are talking EBGP to each > other. So when PE32 advertises a VPN-ipv4 route for CE2 to P3, P3 will in tu rn > advertise the route to P1. When P1 receives the advertisement, it will then > send the advertisement to PE11 and PE12. > > Here are my questions: > (1) A VPN service provider can assign route distinguisher (RD) at its own > discretion. Correct. > So the VPN customer's RD in AS1 will likely be different from its > RD in AS3. Correct too. > When P1 receives the VPN-ipv4 route advertisement from P3, does the > RD in the advertisement need to be converted first before being sent to PE11 > and PE12? No, it does not *need* to be converted. However, P1 *may* do the conversion. > (2) How about route target extended communities? Do they need to be > converted too? The same applies to route targets. They need not be converted by P1. But P1 *may* do the conversion. Yakov. From owner-mpls@UU.NET Tue Jan 2 16:59:20 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23152 for ; Tue, 2 Jan 2001 16:59:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwhb00183; Tue, 2 Jan 2001 21:58:24 GMT Received: by mail-control.mail.uu.net id QQjwhb01626 for mpls-outgoing; Tue, 2 Jan 2001 21:58:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwhb01621 for ; Tue, 2 Jan 2001 21:58: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 QQjwhb13145 for ; Tue, 2 Jan 2001 21:56:57 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwhb10151 for ; Tue, 2 Jan 2001 21:56:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA22576 for mpls@uu.net; Tue, 2 Jan 2001 16:56:56 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwhb01431 for ; Tue, 2 Jan 2001 21:55:54 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 QQjwhb02936 for ; Tue, 2 Jan 2001 21:53:20 GMT Received: from ogma.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjwhb22710 for ; Tue, 2 Jan 2001 21:53:20 GMT Received: from london.cisco.com (london.cisco.com [144.254.32.10]) by ogma.cisco.com (Postfix) with ESMTP id 5E33AB4; Tue, 2 Jan 2001 22:53:19 +0100 (MET) Received: from jguichar-8kcdt.cisco.com (jguichar-isdn-home.cisco.com [10.49.131.222]) by london.cisco.com (8.8.8+Sun/8.8.8) with SMTP id WAA02894; Tue, 2 Jan 2001 22:53:18 +0100 (MET) Message-Id: <200101022153.WAA02894@london.cisco.com> X-Sender: jguichar@london.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 02 Jan 2001 21:50:33 +0000 To: James_Huang@Mitel.COM, Yakov Rekhter From: Jim Guichard Subject: Re: Questions on multiprovider VPN operations in RFC2547bis Cc: mpls@UU.NET In-Reply-To: <852569C8.0077535C.00@kanmta01.software.mitel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk neither of them has to convert the RD if they do not wish too - import into VPNs is controlled by the RT, not the RD. This means that as long as each provider knows what RT values to import (as advertised by an adjacent provider) then the VPN routing information can be propagated .. Jim At 13:43 02/01/2001 -0800, James_Huang@Mitel.COM wrote: > > >From: James Huang@MITEL on 01/02/2001 01:43 PM PST >Yakov, > Should P1 always convert the RD if the RD for the customer in AS1 and AS3 >are different? Or is it P3's responsibility to do the conversion? One of them >should do it, right? > >-- James Huang > > > > > >Yakov Rekhter on 01/02/2001 12:33:39 PM > >To: James Huang/USA/Mitel@Mitel >cc: mpls@UU.NET > >Subject: Re: Questions on multiprovider VPN operations in RFC2547bis > > > >James, > >> RFC2547bis supports multiprovider VPNs in which a VPN customer has two >> sites each served by a distinct VPN service provider. The VPN service provid >ers >> serving the customer are themselves served by yet another VPN service provide >r. >> Suppose we have the following VPN deployment, >> >> CE1 --- (PE11 -- P1 -- PE12) == (PE21 -- P2 -- PE22) == (PE31 >> -- P3 -- PE32) -- CE2 >> >> PE11, P1, and PE12 are in AS1, PE21, P2, and PE22 are in AS2, and PE31, P3, a >nd >> PE32 are in AS3. >> Assuming that P1 and P3 are route reflectors and are talking EBGP to each >> other. So when PE32 advertises a VPN-ipv4 route for CE2 to P3, P3 will in tu >rn >> advertise the route to P1. When P1 receives the advertisement, it will then >> send the advertisement to PE11 and PE12. >> >> Here are my questions: >> (1) A VPN service provider can assign route distinguisher (RD) at its own >> discretion. > >Correct. > >> So the VPN customer's RD in AS1 will likely be different from its >> RD in AS3. > >Correct too. > >> When P1 receives the VPN-ipv4 route advertisement from P3, does the >> RD in the advertisement need to be converted first before being sent to PE11 >> and PE12? > >No, it does not *need* to be converted. However, P1 *may* do the >conversion. > >> (2) How about route target extended communities? Do they need to be >> converted too? > >The same applies to route targets. They need not be converted by P1. >But P1 *may* do the conversion. > >Yakov. > Jim Guichard CCIE #2069 Technical Advisory Consultant EMEA Global Solutions Engineering +44 208 756 8806 Mobile: +44 7802 809763 From owner-mpls@UU.NET Tue Jan 2 17:04:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23199 for ; Tue, 2 Jan 2001 17:04:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwhc07946; Tue, 2 Jan 2001 22:03:27 GMT Received: by mail-control.mail.uu.net id QQjwhc08428 for mpls-outgoing; Tue, 2 Jan 2001 22:03:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwhc08328 for ; Tue, 2 Jan 2001 22:02: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 QQjwhc16831 for ; Tue, 2 Jan 2001 22:02:17 GMT Received: from uniwest1.redstonecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [199.105.223.130]) id QQjwhc18328 for ; Tue, 2 Jan 2001 22:02:17 GMT Received: by uniwest1.redstonecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 17:02:17 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C0FF9FA@uniwest1.redstonecom.com> From: "Shekhar, Ravi" To: "'James_Huang@Mitel.COM'" Cc: "'mpls@uu.net'" Subject: RE: Questions on multiprovider VPN operations in RFC2547bis Date: Tue, 2 Jan 2001 17:02:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I am not sure why would you want RD to be changed, but my guess is that you are wondering how routes will be imported if the route-descriptors are different. From my limited understanding, it seems it is not necessary to change RD for this purpose. RDs help in distinguishing same route prefixes from different VPNs. Its the route-target which determines which routes should be imported and one can configure multiple (appropriate) route-targets to be imported on the router on each site of the VPN. - Ravi Shekhar. > -----Original Message----- > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > Sent: Tuesday, January 02, 2001 4:43 PM > To: Yakov Rekhter > Cc: mpls@UU.NET > Subject: Re: Questions on multiprovider VPN operations in RFC2547bis > > > > > From: James Huang@MITEL on 01/02/2001 01:43 PM PST > Yakov, > Should P1 always convert the RD if the RD for the > customer in AS1 and AS3 > are different? Or is it P3's responsibility to do the > conversion? One of them > should do it, right? > > -- James Huang > > > > > > Yakov Rekhter on 01/02/2001 12:33:39 PM > > To: James Huang/USA/Mitel@Mitel > cc: mpls@UU.NET > > Subject: Re: Questions on multiprovider VPN operations in RFC2547bis > > > > James, > > > RFC2547bis supports multiprovider VPNs in which a VPN > customer has two > > sites each served by a distinct VPN service provider. The > VPN service provid > ers > > serving the customer are themselves served by yet another > VPN service provide > r. > > Suppose we have the following VPN deployment, > > > > CE1 --- (PE11 -- P1 -- PE12) == (PE21 -- P2 > -- PE22) == (PE31 > > -- P3 -- PE32) -- CE2 > > > > PE11, P1, and PE12 are in AS1, PE21, P2, and PE22 are in > AS2, and PE31, P3, a > nd > > PE32 are in AS3. > > Assuming that P1 and P3 are route reflectors and are > talking EBGP to each > > other. So when PE32 advertises a VPN-ipv4 route for CE2 to > P3, P3 will in tu > rn > > advertise the route to P1. When P1 receives the > advertisement, it will then > > send the advertisement to PE11 and PE12. > > > > Here are my questions: > > (1) A VPN service provider can assign route > distinguisher (RD) at its own > > discretion. > > Correct. > > > So the VPN customer's RD in AS1 will likely be > different from its > > RD in AS3. > > Correct too. > > > When P1 receives the VPN-ipv4 route advertisement from P3, does the > > RD in the advertisement need to be converted first before > being sent to PE11 > > and PE12? > > No, it does not *need* to be converted. However, P1 *may* do the > conversion. > > > (2) How about route target extended communities? Do > they need to be > > converted too? > > The same applies to route targets. They need not be converted by P1. > But P1 *may* do the conversion. > > Yakov. > > > > From owner-mpls@UU.NET Tue Jan 2 19:20:03 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24349 for ; Tue, 2 Jan 2001 19:20:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwhl04348; Wed, 3 Jan 2001 00:19:03 GMT Received: by mail-control.mail.uu.net id QQjwhl15864 for mpls-outgoing; Wed, 3 Jan 2001 00:18:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwhl15852 for ; Wed, 3 Jan 2001 00:18: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 QQjwhk07724 for ; Wed, 3 Jan 2001 00:14:44 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwhk28126 for ; Wed, 3 Jan 2001 00:14:44 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA00478 for mpls@uu.net; Tue, 2 Jan 2001 19:14:43 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwhk15451 for ; Wed, 3 Jan 2001 00:14: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 QQjwhk20181 for ; Wed, 3 Jan 2001 00:13:00 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjwhk14533 for ; Wed, 3 Jan 2001 00:12:59 GMT Received: from cisco.com (war-jer-dhcp83.cisco.com [144.254.89.253]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA09744; Tue, 2 Jan 2001 16:12:20 -0800 (PST) Message-ID: <3A527009.EDE39768@cisco.com> Date: Tue, 02 Jan 2001 16:19:21 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Shekhar, Ravi" CC: "'James_Huang@Mitel.COM'" , "'mpls@uu.net'" Subject: Re: Questions on multiprovider VPN operations in RFC2547bis References: <49FF5C6DDBD8D311BBBD009027DE980C0FF9FA@uniwest1.redstonecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > I am not sure why would you want RD to be changed, but my I responded on this email in the NBVPN list but here let me just comment on the above. The RD will need to be changed when there is any possibility that the duplication of RD value is possible. This has nothing to do with importing to vrfs or not but with maintaining the correct and not confused data structures (for example vpnv4 route reflector tries) in the provider's network. To summarise if one uses part of his registered AS# in the RD string no change of RD is needed in the incomming updates and this is the simples way to avoid the confusion. The incomming RD check still would need to be done of course to prevent attacks from not trusted peers :). R. > "Shekhar, Ravi" wrote: > > I am not sure why would you want RD to be changed, but my > guess is that you are wondering how routes will be imported > if the route-descriptors are different. > > From my limited understanding, it seems it is not necessary to > change RD for this purpose. RDs help in distinguishing > same route prefixes from different VPNs. > Its the route-target which determines which routes should be > imported and one can configure multiple (appropriate) route-targets > to be imported on the router on each site of the VPN. > > - Ravi Shekhar. > > > -----Original Message----- > > From: James_Huang@Mitel.COM [mailto:James_Huang@Mitel.COM] > > Sent: Tuesday, January 02, 2001 4:43 PM > > To: Yakov Rekhter > > Cc: mpls@UU.NET > > Subject: Re: Questions on multiprovider VPN operations in RFC2547bis > > > > > > > > > > From: James Huang@MITEL on 01/02/2001 01:43 PM PST > > Yakov, > > Should P1 always convert the RD if the RD for the > > customer in AS1 and AS3 > > are different? Or is it P3's responsibility to do the > > conversion? One of them > > should do it, right? > > > > -- James Huang > > > > > > > > > > > > Yakov Rekhter on 01/02/2001 12:33:39 PM > > > > To: James Huang/USA/Mitel@Mitel > > cc: mpls@UU.NET > > > > Subject: Re: Questions on multiprovider VPN operations in RFC2547bis > > > > > > > > James, > > > > > RFC2547bis supports multiprovider VPNs in which a VPN > > customer has two > > > sites each served by a distinct VPN service provider. The > > VPN service provid > > ers > > > serving the customer are themselves served by yet another > > VPN service provide > > r. > > > Suppose we have the following VPN deployment, > > > > > > CE1 --- (PE11 -- P1 -- PE12) == (PE21 -- P2 > > -- PE22) == (PE31 > > > -- P3 -- PE32) -- CE2 > > > > > > PE11, P1, and PE12 are in AS1, PE21, P2, and PE22 are in > > AS2, and PE31, P3, a > > nd > > > PE32 are in AS3. > > > Assuming that P1 and P3 are route reflectors and are > > talking EBGP to each > > > other. So when PE32 advertises a VPN-ipv4 route for CE2 to > > P3, P3 will in tu > > rn > > > advertise the route to P1. When P1 receives the > > advertisement, it will then > > > send the advertisement to PE11 and PE12. > > > > > > Here are my questions: > > > (1) A VPN service provider can assign route > > distinguisher (RD) at its own > > > discretion. > > > > Correct. > > > > > So the VPN customer's RD in AS1 will likely be > > different from its > > > RD in AS3. > > > > Correct too. > > > > > When P1 receives the VPN-ipv4 route advertisement from P3, does the > > > RD in the advertisement need to be converted first before > > being sent to PE11 > > > and PE12? > > > > No, it does not *need* to be converted. However, P1 *may* do the > > conversion. > > > > > (2) How about route target extended communities? Do > > they need to be > > > converted too? > > > > The same applies to route targets. They need not be converted by P1. > > But P1 *may* do the conversion. > > > > Yakov. > > > > > > > > From owner-mpls@UU.NET Wed Jan 3 09:29:41 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23086 for ; Wed, 3 Jan 2001 09:29:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwjp21725; Wed, 3 Jan 2001 14:29:37 GMT Received: by mail-control.mail.uu.net id QQjwjp20314 for mpls-outgoing; Wed, 3 Jan 2001 14:29:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwjp20309 for ; Wed, 3 Jan 2001 14:29:11 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 QQjwjp16740 for ; Wed, 3 Jan 2001 14:28:17 GMT Received: from web11406.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11406.mail.yahoo.com [216.136.131.236]) id QQjwjp10347 for ; Wed, 3 Jan 2001 14:28:16 GMT Message-ID: <20010103142816.12307.qmail@web11406.mail.yahoo.com> Received: from [132.177.121.21] by web11406.mail.yahoo.com; Wed, 03 Jan 2001 06:28:16 PST Date: Wed, 3 Jan 2001 06:28:16 -0800 (PST) From: John Sparr Subject: RE: ERO and strict/loose subobject To: "Sanford, Bill" , mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Bill, Thanks for the comments. I was still a little bit confused about the first subobject in the ERO. Lets say the example like below: --- "Sanford, Bill" wrote: > John, see the comments below: > > > -----Original Message----- > > From: John Sparr [mailto:johnll44@yahoo.com] > > Sent: Tuesday, January 02, 2001 3:43 PM > > To: mpls@UU.NET > > Subject: ERO and strict/loose subobject > > > > > > Hi all, > > > > One question about the ERO object in RSVP: > > > > Assuming there is a sender node and it creates an > ERO. > > Should the ERO include the ip address of sender > > itself? If yes, why? > > Lets say the ERO is not set with the sender node and > is started on the next > hop. How does the LSP you want to set up know that > there are no other hops > in between the sender and next hop? If you don't > have the senders ip > address as the first subobject, there isn't any way > to set the properties of > the link to the next hop to loose or strict. > > In the implementation in > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you > didn't have the sender address in the ERO, it would > immediately error with > "Bad EXPLICIT_ROUTE object" error. > > In 4.3.4.1. Selection of the Next Hop, it explains: > > 1) The node receiving the RSVP message MUST first > evaluate the first > subobject. If the node is not part of the > abstract node described by > the first subobject, it has received the message > in error and SHOULD > return a "Bad initial subobject" error. If there > is no first > subobject, the message is also in error and the > system SHOULD return > a "Bad EXPLICIT_ROUTE object" error. > > > > > Another question is about strict/loose object: > > > > The draft of RSVP-TE says "The path between a > strict > > node and its preceding node MUST include only > network > > nodes from the strict node and its preceding > abstract > > node." > > > > Does it mean if there is strict subobject in ERO, > then > > ther is no loose subobject and if there is loose > > subobject, then there is no strict subobject? > > Not at all. You can have both strict hops and loose > hops as part of the > same ERO. On a "strict" hop link, there isn't any > other route it can take > except for the next hop in the ERO list. On a > "loose" hop link, there can > be additional hops between the nodes provided that > it ends up on the next > hop. > > Bill __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From owner-mpls@UU.NET Wed Jan 3 09:51:16 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23854 for ; Wed, 3 Jan 2001 09:51:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwjr25002; Wed, 3 Jan 2001 14:51:16 GMT Received: by mail-control.mail.uu.net id QQjwjr21808 for mpls-outgoing; Wed, 3 Jan 2001 14:50:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwjr21803 for ; Wed, 3 Jan 2001 14:50:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjwjr00373 for ; Wed, 3 Jan 2001 14:47:54 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 QQjwjr19925 for ; Wed, 3 Jan 2001 14:47:54 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id GAA10783 for ; Wed, 3 Jan 2001 06:48:04 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA04919 for mpls@uu.net; Wed, 3 Jan 2001 09:47:51 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwgb19172 for ; Tue, 2 Jan 2001 15:29:34 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjwgb12202 for ; Tue, 2 Jan 2001 15:28:32 GMT Received: from ms.info.sh.cn. by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.95.7.153]) id QQjwgb11436 for ; Tue, 2 Jan 2001 15:28:29 GMT Received: from romer ([172.16.12.4]) by ms.info.sh.cn. (8.10.1/8.10.1) with SMTP id f02FDnr04369 for ; Tue, 2 Jan 2001 23:13:49 +0800 (GMT+0800) Message-ID: <002101c074d0$7ab86ba0$040c10ac@info.sh.cn> From: "Tong Wu" To: Subject: questions on LDP session initialization Date: Tue, 2 Jan 2001 23:27:12 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA23854 Hi, In 3.5.3. of draft-ietf-mpls-ldp-11.txt, it is said that " If one LSR proposes Downstream Unsolicited and the other proposes Downstream on Demand, the rules for resolving this difference is: - If the session is for a label-controlled ATM link or a label-controlled Frame Relay link, then Downstream on Demand must be used. - Otherwise, Downstream Unsolicited must be used " Are there any deep reasons to distingish the case of ATM/FR from others'? Is it just becaue of the considerations of label-merging difficulties in ATM or FR networks? Thanks a lot in advance. Best Regards, Wu, Tong From owner-mpls@UU.NET Wed Jan 3 10:37:44 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25764 for ; Wed, 3 Jan 2001 10:37:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwju03234; Wed, 3 Jan 2001 15:37:45 GMT Received: by mail-control.mail.uu.net id QQjwju07013 for mpls-outgoing; Wed, 3 Jan 2001 15:37:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwju07008 for ; Wed, 3 Jan 2001 15:37:11 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 QQjwju10774 for ; Wed, 3 Jan 2001 15:34:40 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwju22930 for ; Wed, 3 Jan 2001 15:34:40 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA10385 for mpls@uu.net; Wed, 3 Jan 2001 10:34:39 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwju06773 for ; Wed, 3 Jan 2001 15:34:27 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 QQjwju08333 for ; Wed, 3 Jan 2001 15:33:20 GMT Received: from xover.hjinc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjwju21071 for ; Wed, 3 Jan 2001 15:33:20 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 10:31:08 -0500 Message-ID: <87009604743AD411B1F600508BA0F959040D1D@xover.hjinc.com> From: "Sanford, Bill" To: "'Yangguang Xu'" Cc: "'mpls@uu.net'" Subject: RE: ERO and strict/loose subobject Date: Wed, 3 Jan 2001 10:31:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: Yangguang Xu [mailto:xuyg@lucent.com] > Sent: Tuesday, January 02, 2001 4:56 PM > To: Sanford, Bill > Subject: Re: ERO and strict/loose subobject > > Bill, > > The "L" bit for a node doesn't mean the node is loose. That is exactly what it means. > Indeed, the node is > strict but the path from preceding node to this node is > loose. Am I right? > > Thanks, > > Yangguang > Yangguang, in draft-ietf-mpls-rsvp-lsp-tunnel-07.txt: 4.3.3.1. Strict and Loose Subobjects The L bit in the subobject is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.' For brevity, we say that if the value of the subobject attribute is 'loose' then it is a 'loose subobject.' Otherwise, it's a 'strict subobject.' Further, we say that the abstract node of a strict or loose subobject is a strict or a loose node, respectively. Loose and strict nodes are always interpreted relative to their prior abstract nodes. If you have a "loose prior abstract node," the address *may* be the previous hop in the ERO list. If you have a "strict prior abstract node," the address *must* be the previous hop in the ERO list. Bill From owner-mpls@UU.NET Wed Jan 3 10:54:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26353 for ; Wed, 3 Jan 2001 10:54:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwjv21683; Wed, 3 Jan 2001 15:54:08 GMT Received: by mail-control.mail.uu.net id QQjwjv09172 for mpls-outgoing; Wed, 3 Jan 2001 15:53:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwjv09162 for ; Wed, 3 Jan 2001 15:53: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 QQjwjv18678 for ; Wed, 3 Jan 2001 15:52:32 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 QQjwjv15262 for ; Wed, 3 Jan 2001 15:52:32 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA28978 for ; Wed, 3 Jan 2001 10:52:32 -0500 (EST) Received: from mvmail.mv.lucent.com (h135-13-96-58.lucent.com [135.13.96.58]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA28969; Wed, 3 Jan 2001 10:52:31 -0500 (EST) Received: from lucent.com (ma0940xuyg.mv.lucent.com [135.13.36.111]) by mvmail.mv.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA06140; Wed, 3 Jan 2001 10:52:30 -0500 (EST) Message-ID: <3A534ABE.CEDB5887@lucent.com> Date: Wed, 03 Jan 2001 10:52:30 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Sanford, Bill" CC: "'mpls@uu.net'" Subject: Re: ERO and strict/loose subobject References: <87009604743AD411B1F600508BA0F959040D1D@xover.hjinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > > The "L" bit for a node doesn't mean the node is loose. > > That is exactly what it means. > > > Indeed, the node is > > strict but the path from preceding node to this node is > > loose. Am I right? > > > If you have a "loose prior abstract node," the address *may* be the previous > hop in the ERO list. If you have a "strict prior abstract node," the > address *must* be the previous hop in the ERO list. > > Bill Bill, Because node marked as "loose" can also be interpreted as that the node itself is not necessary in the ERO. What I am saying is that no matter the abstract node is marked as loose or strict, it has to be in the ERO, however somewhere depending on its being loose or strict. Thanks, Yangguang From owner-mpls@UU.NET Wed Jan 3 11:20:19 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27186 for ; Wed, 3 Jan 2001 11:20:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwjx00131; Wed, 3 Jan 2001 16:20:15 GMT Received: by mail-control.mail.uu.net id QQjwjx23928 for mpls-outgoing; Wed, 3 Jan 2001 16:19:53 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwjx23918 for ; Wed, 3 Jan 2001 16:19:49 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 QQjwjx12699 for ; Wed, 3 Jan 2001 16:19:23 GMT Received: from mclean.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mclean.mail.mindspring.net [207.69.200.57]) id QQjwjx06402 for ; Wed, 3 Jan 2001 16:19:22 GMT Received: from mindspring.com (user-2ive38r.dialup.mindspring.com [165.247.13.27]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA05045; Wed, 3 Jan 2001 11:19:15 -0500 (EST) Message-ID: <3A535161.B4A77BEB@mindspring.com> Date: Wed, 03 Jan 2001 11:20:49 -0500 From: Eric Gray Reply-To: ewgray@mindspring.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Sanford CC: Yangguang Xu , MPLS Mailing List Subject: Re: ERO and strict/loose subobject References: <87009604743AD411B1F600508BA0F959040D1D@xover.hjinc.com> <3A534ABE.CEDB5887@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bill, Yangguang is exactly correct. What the L bit means is that the next listed hop in the ER does not have to be an adjacent peer. It still must be in the eventual ER. Some people have been known to refer to an "abstract node" as a "loose node", and - in that sense - the L bit indicates a "loose hop" rather than a "loose node". -- Eric Gray Yangguang Xu wrote: > > > The "L" bit for a node doesn't mean the node is loose. > > > > That is exactly what it means. > > > > > Indeed, the node is > > > strict but the path from preceding node to this node is > > > loose. Am I right? > > > > > > If you have a "loose prior abstract node," the address *may* be the previous > > hop in the ERO list. If you have a "strict prior abstract node," the > > address *must* be the previous hop in the ERO list. > > > > Bill > > Bill, > > Because node marked as "loose" can also be interpreted as that the node itself > is not necessary in the ERO. What I am saying is that no matter the abstract > node is marked as loose or strict, it has to be in the ERO, however somewhere > depending on its being loose or strict. > > Thanks, > > Yangguang From owner-mpls@UU.NET Wed Jan 3 11:31:10 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27471 for ; Wed, 3 Jan 2001 11:31:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwjy24838; Wed, 3 Jan 2001 16:31:07 GMT Received: by mail-control.mail.uu.net id QQjwjy25099 for mpls-outgoing; Wed, 3 Jan 2001 16:30:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwjy25088 for ; Wed, 3 Jan 2001 16:30:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjwjx00482 for ; Wed, 3 Jan 2001 16:28:24 GMT Received: from web11406.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11406.mail.yahoo.com [216.136.131.236]) id QQjwjx08146 for ; Wed, 3 Jan 2001 16:28:23 GMT Message-ID: <20010103162823.90356.qmail@web11406.mail.yahoo.com> Received: from [132.177.121.21] by web11406.mail.yahoo.com; Wed, 03 Jan 2001 08:28:23 PST Date: Wed, 3 Jan 2001 08:28:23 -0800 (PST) From: John Sparr Subject: RE: ERO and strict/loose subobject To: "Sanford, Bill" , mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Bill, Thanks for the comments. I was still a little bit confused about the first subobject in the ERO. Lets say the following example. A--A1--A2--A3--B--C Assuming A is the sender node and B is the receiver node, A1-A3 are the intermediate nodes. A creates an ERO with the first subobj A's addr (loose) and second subobj B's addr. When A sends Path msg with the ERO towards B, what should A do to the ERO, it should delete the first subobj (itself addr)? or send both subobjs to B? I think A should delet the first subobj, but if it is, it's no use to add the first subobj( itself addr) at the beginning of creating ERO. Please correct me. Thanks in advance Regards, John --- "Sanford, Bill" wrote: > John, see the comments below: > > > -----Original Message----- > > From: John Sparr [mailto:johnll44@yahoo.com] > > Sent: Tuesday, January 02, 2001 3:43 PM > > To: mpls@UU.NET > > Subject: ERO and strict/loose subobject > > > > > > Hi all, > > > > One question about the ERO object in RSVP: > > > > Assuming there is a sender node and it creates an > ERO. > > Should the ERO include the ip address of sender > > itself? If yes, why? > > Lets say the ERO is not set with the sender node and > is started on the next > hop. How does the LSP you want to set up know that > there are no other hops > in between the sender and next hop? If you don't > have the senders ip > address as the first subobject, there isn't any way > to set the properties of > the link to the next hop to loose or strict. > > In the implementation in > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you > didn't have the sender address in the ERO, it would > immediately error with > "Bad EXPLICIT_ROUTE object" error. > > In 4.3.4.1. Selection of the Next Hop, it explains: > > 1) The node receiving the RSVP message MUST first > evaluate the first > subobject. If the node is not part of the > abstract node described by > the first subobject, it has received the message > in error and SHOULD > return a "Bad initial subobject" error. If there > is no first > subobject, the message is also in error and the > system SHOULD return > a "Bad EXPLICIT_ROUTE object" error. > > > > > Another question is about strict/loose object: > > > > The draft of RSVP-TE says "The path between a > strict > > node and its preceding node MUST include only > network > > nodes from the strict node and its preceding > abstract > > node." > > > > Does it mean if there is strict subobject in ERO, > then > > ther is no loose subobject and if there is loose > > subobject, then there is no strict subobject? > > Not at all. You can have both strict hops and loose > hops as part of the > same ERO. On a "strict" hop link, there isn't any > other route it can take > except for the next hop in the ERO list. On a > "loose" hop link, there can > be additional hops between the nodes provided that > it ends up on the next > hop. > > Bill __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From owner-mpls@UU.NET Wed Jan 3 11:42:56 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27856 for ; Wed, 3 Jan 2001 11:42:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwjy12697; Wed, 3 Jan 2001 16:42:57 GMT Received: by mail-control.mail.uu.net id QQjwjy26384 for mpls-outgoing; Wed, 3 Jan 2001 16:42:32 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwjy26355 for ; Wed, 3 Jan 2001 16:42: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 QQjwjy27072 for ; Wed, 3 Jan 2001 16:41:38 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwjy02251 for ; Wed, 3 Jan 2001 16:41:38 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA17488 for mpls@uu.net; Wed, 3 Jan 2001 11:41:37 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwjy26083 for ; Wed, 3 Jan 2001 16:41: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 QQjwjy24591 for ; Wed, 3 Jan 2001 16:40:02 GMT Received: from xover.hjinc.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjwjy25185 for ; Wed, 3 Jan 2001 16:40:02 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 11:37:50 -0500 Message-ID: <87009604743AD411B1F600508BA0F959040D1E@xover.hjinc.com> From: "Sanford, Bill" To: "'John Sparr'" , mpls@UU.NET Subject: RE: ERO and strict/loose subobject Date: Wed, 3 Jan 2001 11:37:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk In draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, There are decisions to be made and "4.3.4. Processing of the Explicit Route Object" explains how to handle them. > -----Original Message----- > From: John Sparr [mailto:johnll44@yahoo.com] > Sent: Wednesday, January 03, 2001 11:28 AM > To: Sanford, Bill; mpls@UU.NET > Subject: RE: ERO and strict/loose subobject > > > > Hi Bill, > > Thanks for the comments. > > I was still a little bit confused about the first > subobject in the ERO. Lets say the following example. > > A--A1--A2--A3--B--C > > Assuming A is the sender node and B is the receiver > node, A1-A3 are the intermediate nodes. A creates an > ERO with the first subobj A's addr (loose) and second > subobj B's addr. When A sends Path msg with the ERO > towards B, what should A do to the ERO, it should > delete the first subobj (itself addr)? or send both > subobjs to B? I think A should delet the first subobj, > but if it is, it's no use to add the first subobj( > itself addr) at the beginning of creating ERO. > > Please correct me. > > Thanks in advance > > Regards, > > John > > > > > --- "Sanford, Bill" wrote: > > John, see the comments below: > > > > > -----Original Message----- > > > From: John Sparr [mailto:johnll44@yahoo.com] > > > Sent: Tuesday, January 02, 2001 3:43 PM > > > To: mpls@UU.NET > > > Subject: ERO and strict/loose subobject > > > > > > > > > Hi all, > > > > > > One question about the ERO object in RSVP: > > > > > > Assuming there is a sender node and it creates an > > ERO. > > > Should the ERO include the ip address of sender > > > itself? If yes, why? > > > > Lets say the ERO is not set with the sender node and > > is started on the next > > hop. How does the LSP you want to set up know that > > there are no other hops > > in between the sender and next hop? If you don't > > have the senders ip > > address as the first subobject, there isn't any way > > to set the properties of > > the link to the next hop to loose or strict. > > > > In the implementation in > > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you > > didn't have the sender address in the ERO, it would > > immediately error with > > "Bad EXPLICIT_ROUTE object" error. > > > > In 4.3.4.1. Selection of the Next Hop, it explains: > > > > 1) The node receiving the RSVP message MUST first > > evaluate the first > > subobject. If the node is not part of the > > abstract node described by > > the first subobject, it has received the message > > in error and SHOULD > > return a "Bad initial subobject" error. If there > > is no first > > subobject, the message is also in error and the > > system SHOULD return > > a "Bad EXPLICIT_ROUTE object" error. > > > > > > > > Another question is about strict/loose object: > > > > > > The draft of RSVP-TE says "The path between a > > strict > > > node and its preceding node MUST include only > > network > > > nodes from the strict node and its preceding > > abstract > > > node." > > > > > > Does it mean if there is strict subobject in ERO, > > then > > > ther is no loose subobject and if there is loose > > > subobject, then there is no strict subobject? > > > > Not at all. You can have both strict hops and loose > > hops as part of the > > same ERO. On a "strict" hop link, there isn't any > > other route it can take > > except for the next hop in the ERO list. On a > > "loose" hop link, there can > > be additional hops between the nodes provided that > > it ends up on the next > > hop. > > > > Bill > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Photos - Share your holiday photos online! > http://photos.yahoo.com/ > From owner-mpls@UU.NET Wed Jan 3 11:54:23 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28107 for ; Wed, 3 Jan 2001 11:54:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwjz16474; Wed, 3 Jan 2001 16:54:24 GMT Received: by mail-control.mail.uu.net id QQjwjz27624 for mpls-outgoing; Wed, 3 Jan 2001 16:53:52 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwjz27591 for ; Wed, 3 Jan 2001 16:53: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 QQjwjz20457 for ; Wed, 3 Jan 2001 16:52:31 GMT Received: from tisch.mail.mindspring.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tisch.mail.mindspring.net [207.69.200.157]) id QQjwjz27090 for ; Wed, 3 Jan 2001 16:52:30 GMT Received: from mindspring.com (user-2ive38r.dialup.mindspring.com [165.247.13.27]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id LAA21073; Wed, 3 Jan 2001 11:52:24 -0500 (EST) Message-ID: <3A535926.ACF908CB@mindspring.com> Date: Wed, 03 Jan 2001 11:53:58 -0500 From: Eric Gray Reply-To: ewgray@mindspring.com X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: John Sparr CC: Bill Sanford , MPLS Mailing List Subject: Re: ERO and strict/loose subobject References: <20010103162823.90356.qmail@web11406.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 John, I believe part of the issue is your use of terms. In the example you give, I believe that either the "address" A must be that of an abstract node that includes addresses A1, A2 and A3 OR B needs to have the L bit set to indicate that it does not have to be the very next (adjacent) peer. I am sure that A cannot forward the Path message to A1, let alone to B, otherwise. I think if you recast your question in terms of "loose hops" and "abstract nodes" and re-read the applicable sections of the specification, your answer will emerge. -- Eric Gray John Sparr wrote: > Hi Bill, > > Thanks for the comments. > > I was still a little bit confused about the first > subobject in the ERO. Lets say the following example. > > A--A1--A2--A3--B--C > > Assuming A is the sender node and B is the receiver > node, A1-A3 are the intermediate nodes. A creates an > ERO with the first subobj A's addr (loose) and second > subobj B's addr. When A sends Path msg with the ERO > towards B, what should A do to the ERO, it should > delete the first subobj (itself addr)? or send both > subobjs to B? I think A should delet the first subobj, > but if it is, it's no use to add the first subobj( > itself addr) at the beginning of creating ERO. > > Please correct me. > > Thanks in advance > > Regards, > > John > > --- "Sanford, Bill" wrote: > > John, see the comments below: > > > > > -----Original Message----- > > > From: John Sparr [mailto:johnll44@yahoo.com] > > > Sent: Tuesday, January 02, 2001 3:43 PM > > > To: mpls@UU.NET > > > Subject: ERO and strict/loose subobject > > > > > > > > > Hi all, > > > > > > One question about the ERO object in RSVP: > > > > > > Assuming there is a sender node and it creates an > > ERO. > > > Should the ERO include the ip address of sender > > > itself? If yes, why? > > > > Lets say the ERO is not set with the sender node and > > is started on the next > > hop. How does the LSP you want to set up know that > > there are no other hops > > in between the sender and next hop? If you don't > > have the senders ip > > address as the first subobject, there isn't any way > > to set the properties of > > the link to the next hop to loose or strict. > > > > In the implementation in > > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you > > didn't have the sender address in the ERO, it would > > immediately error with > > "Bad EXPLICIT_ROUTE object" error. > > > > In 4.3.4.1. Selection of the Next Hop, it explains: > > > > 1) The node receiving the RSVP message MUST first > > evaluate the first > > subobject. If the node is not part of the > > abstract node described by > > the first subobject, it has received the message > > in error and SHOULD > > return a "Bad initial subobject" error. If there > > is no first > > subobject, the message is also in error and the > > system SHOULD return > > a "Bad EXPLICIT_ROUTE object" error. > > > > > > > > Another question is about strict/loose object: > > > > > > The draft of RSVP-TE says "The path between a > > strict > > > node and its preceding node MUST include only > > network > > > nodes from the strict node and its preceding > > abstract > > > node." > > > > > > Does it mean if there is strict subobject in ERO, > > then > > > ther is no loose subobject and if there is loose > > > subobject, then there is no strict subobject? > > > > Not at all. You can have both strict hops and loose > > hops as part of the > > same ERO. On a "strict" hop link, there isn't any > > other route it can take > > except for the next hop in the ERO list. On a > > "loose" hop link, there can > > be additional hops between the nodes provided that > > it ends up on the next > > hop. > > > > Bill > > __________________________________________________ > Do You Yahoo!? > Yahoo! Photos - Share your holiday photos online! > http://photos.yahoo.com/ From owner-mpls@UU.NET Wed Jan 3 14:05:41 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02159 for ; Wed, 3 Jan 2001 14:05:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwki02407; Wed, 3 Jan 2001 19:05:40 GMT Received: by mail-control.mail.uu.net id QQjwki13148 for mpls-outgoing; Wed, 3 Jan 2001 19:05:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwki13138 for ; Wed, 3 Jan 2001 19:05:07 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 QQjwki29816 for ; Wed, 3 Jan 2001 19:04: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 QQjwki00178 for ; Wed, 3 Jan 2001 19:04:11 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA29594 for ; Wed, 3 Jan 2001 14:04:05 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA13846 for ; Wed, 3 Jan 2001 14:04:07 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 14:04:06 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF446BD6@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: mpls@UU.NET Subject: Questions on creation of p2mp connection using LSR-MIB Date: Wed, 3 Jan 2001 14:04:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi! I have few questions related to establishment of point-to-multipoint connections using LSR-MIB. Your comments / suggestions will be appreciated. Thanks, sanjay Consider the following example: ------------------------------------- In mplsInSegmentTable : { mplsInSegmentIfIndex = 10 mplsInSegmentLabel = 100 ... } In mplsOutSegmentTable: { mplsOutSegmentIndex = 1 mplsOutSegmentIfIndex = 11 ... ---------------------------------- mplsOutSegmentIndex = 2 mplsOutSegmentIfIndex = 12 ... } As per the current indexing scheme, I have to create the following two rows in the mplsXCTable: { (create a row in this table using the index: 1.10.100.1) mplsXCIndex = 1 mplsXCLSPId = 999 .... (create a row in this table using the index: 1.10.100.2) mplsXCIndex = 2 mplsXCLSPId = 999 .... } Creation of the above mentioned row in the XC table will automatically populate the mplsInSegmentXCIndex and mplsOutSegmentXCIndex. Now the questions: ----------------------- (a) mplsXCTable.1.10.100.2.mplsXCAdminStatus == down(2) =>The desired operational status of this segment (outgoing) is down and no packets should be forwarded on this segment. Is my assumption correct ? (b) Assume that mplsXCTable.1.10.100.1.mplsXCAdminStatus == down(2) What does this mean ? Is this the adminStatus of the incoming segment or the outgoing segment ? or Does it represent the overall admin Status of the point-to-multipoint connection ? (c) Do you think, the XC model will be simpler, if we create only ONE XC entry for each connection and make the mplsInSegmentXCIndex & mplsOutSegmentXCIndex read-write (for SNMP initiated p2mp & mp2p connections) ? The mplsInSegmentXCIndex & mplsOutSegmentXCIndex can still be automatically created for control protocol initiated connections. [May also need to move the mplsXCLabelStackIndex to outSegmentTable.] From owner-mpls@UU.NET Wed Jan 3 14:30:53 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02738 for ; Wed, 3 Jan 2001 14:30:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwkf26225; Wed, 3 Jan 2001 18:23:30 GMT Received: by mail-control.mail.uu.net id QQjwkf27662 for mpls-outgoing; Wed, 3 Jan 2001 18:23:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwkf27652 for ; Wed, 3 Jan 2001 18:23:02 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 QQjwkf29025 for ; Wed, 3 Jan 2001 18:20:15 GMT Received: from web11404.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11404.mail.yahoo.com [216.136.131.234]) id QQjwkf21462 for ; Wed, 3 Jan 2001 18:20:15 GMT Message-ID: <20010103182014.34779.qmail@web11404.mail.yahoo.com> Received: from [132.177.121.21] by web11404.mail.yahoo.com; Wed, 03 Jan 2001 10:20:14 PST Date: Wed, 3 Jan 2001 10:20:14 -0800 (PST) From: John Sparr Subject: Re: ERO and strict/loose subobject To: ewgray@mindspring.com Cc: Bill Sanford , MPLS Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, You are right. I made a mistake. In the example, A is not the abstract node and B should set the L bit. My question is how node A handle the ERO. Does the ERO created by A contains only B's addr or both A's addr and B's addr, when A sent out path msg with ERO? Assuming A want to send ERO to B and regardless the intermediate nodes. Thanks. Regards, John --- Eric Gray wrote: > John, > > I believe part of the issue is your use of > terms. > In the example you give, I believe that either the > "address" A must be that of an abstract node that > includes addresses A1, A2 and A3 OR B needs > to have the L bit set to indicate that it does not > have to be the very next (adjacent) peer. I am > sure that A cannot forward the Path message > to A1, let alone to B, otherwise. > > I think if you recast your question in terms of > "loose hops" and "abstract nodes" and re-read > the applicable sections of the specification, your > answer will emerge. > > -- > Eric Gray > > John Sparr wrote: > > > Hi Bill, > > > > Thanks for the comments. > > > > I was still a little bit confused about the first > > subobject in the ERO. Lets say the following > example. > > > > A--A1--A2--A3--B--C > > > > Assuming A is the sender node and B is the > receiver > > node, A1-A3 are the intermediate nodes. A creates > an > > ERO with the first subobj A's addr (loose) and > second > > subobj B's addr. When A sends Path msg with the > ERO > > towards B, what should A do to the ERO, it should > > delete the first subobj (itself addr)? or send > both > > subobjs to B? I think A should delet the first > subobj, > > but if it is, it's no use to add the first subobj( > > itself addr) at the beginning of creating ERO. > > > > Please correct me. > > > > Thanks in advance > > > > Regards, > > > > John > > > > --- "Sanford, Bill" wrote: > > > John, see the comments below: > > > > > > > -----Original Message----- > > > > From: John Sparr [mailto:johnll44@yahoo.com] > > > > Sent: Tuesday, January 02, 2001 3:43 PM > > > > To: mpls@UU.NET > > > > Subject: ERO and strict/loose subobject > > > > > > > > > > > > Hi all, > > > > > > > > One question about the ERO object in RSVP: > > > > > > > > Assuming there is a sender node and it creates > an > > > ERO. > > > > Should the ERO include the ip address of > sender > > > > itself? If yes, why? > > > > > > Lets say the ERO is not set with the sender node > and > > > is started on the next > > > hop. How does the LSP you want to set up know > that > > > there are no other hops > > > in between the sender and next hop? If you > don't > > > have the senders ip > > > address as the first subobject, there isn't any > way > > > to set the properties of > > > the link to the next hop to loose or strict. > > > > > > In the implementation in > > > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you > > > didn't have the sender address in the ERO, it > would > > > immediately error with > > > "Bad EXPLICIT_ROUTE object" error. > > > > > > In 4.3.4.1. Selection of the Next Hop, it > explains: > > > > > > 1) The node receiving the RSVP message MUST > first > > > evaluate the first > > > subobject. If the node is not part of the > > > abstract node described by > > > the first subobject, it has received the > message > > > in error and SHOULD > > > return a "Bad initial subobject" error. If > there > > > is no first > > > subobject, the message is also in error and > the > > > system SHOULD return > > > a "Bad EXPLICIT_ROUTE object" error. > > > > > > > > > > > Another question is about strict/loose object: > > > > > > > > The draft of RSVP-TE says "The path between a > > > strict > > > > node and its preceding node MUST include only > > > network > > > > nodes from the strict node and its preceding > > > abstract > > > > node." > > > > > > > > Does it mean if there is strict subobject in > ERO, > > > then > > > > ther is no loose subobject and if there is > loose > > > > subobject, then there is no strict subobject? > > > > > > Not at all. You can have both strict hops and > loose > > > hops as part of the > > > same ERO. On a "strict" hop link, there isn't > any > > > other route it can take > > > except for the next hop in the ERO list. On a > > > "loose" hop link, there can > > > be additional hops between the nodes provided > that > > > it ends up on the next > > > hop. > > > > > > Bill > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Photos - Share your holiday photos online! > > http://photos.yahoo.com/ > __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From owner-mpls@UU.NET Wed Jan 3 14:31:40 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02763 for ; Wed, 3 Jan 2001 14:31:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwkk07963; Wed, 3 Jan 2001 19:31:39 GMT Received: by mail-control.mail.uu.net id QQjwkk16396 for mpls-outgoing; Wed, 3 Jan 2001 19:31:09 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwkk16377 for ; Wed, 3 Jan 2001 19:31: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 QQjwkk04507 for ; Wed, 3 Jan 2001 19:30:14 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwkk05628 for ; Wed, 3 Jan 2001 19:30:14 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA01444 for mpls@uu.net; Wed, 3 Jan 2001 14:30:14 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwkj16146 for ; Wed, 3 Jan 2001 19:29:52 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 QQjwkj20504 for ; Wed, 3 Jan 2001 19:29:23 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 QQjwkj04278 for ; Wed, 3 Jan 2001 19:29:22 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA17598; Wed, 3 Jan 2001 14:29:01 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAE00927; Wed, 3 Jan 2001 14:29:09 -0500 (EST) Message-Id: <4.3.2.7.2.20010103141840.02132410@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 03 Jan 2001 14:31:45 -0500 To: "Choudhury, Sanjaya" , mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: Questions on creation of p2mp connection using LSR-MIB Cc: cheenu Srinivasan , Arun Viswanathan In-Reply-To: <4FBEA8857476D311A03300204840E1CF446BD6@whq-msgusr-02.pit.c omms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Sanjaya, Answers are in-line. > Hi! I have few questions related to establishment of >point-to-multipoint > connections using LSR-MIB. Your comments / suggestions will be > appreciated. > > Thanks, > sanjay > > Consider the following example: > ------------------------------------- > In mplsInSegmentTable : > { > mplsInSegmentIfIndex = 10 > mplsInSegmentLabel = 100 > ... > } > In mplsOutSegmentTable: > { > mplsOutSegmentIndex = 1 > mplsOutSegmentIfIndex = 11 > ... > ---------------------------------- > mplsOutSegmentIndex = 2 > mplsOutSegmentIfIndex = 12 > ... > } > > As per the current indexing scheme, I have to create the following > two rows in the mplsXCTable: > { > (create a row in this table using the index: 1.10.100.1) > mplsXCIndex = 1 > mplsXCLSPId = 999 > .... > > (create a row in this table using the index: 1.10.100.2) > mplsXCIndex = 2 > mplsXCLSPId = 999 > .... > } > > Creation of the above mentioned row in the XC table will >automatically > populate the mplsInSegmentXCIndex and mplsOutSegmentXCIndex. > > Now the questions: > ----------------------- > (a) mplsXCTable.1.10.100.2.mplsXCAdminStatus == down(2) > =>The desired operational status of this segment (outgoing) is > down and no packets should be forwarded on this segment. > > Is my assumption correct ? If you are referring to the operational status of the in/OutSegments, remember that we no longer have operational status in the MPLS-LSR-MIB for in/out segments as they do not make sense. Your assumption is correct if you are assuming that the XCoperStatus = down(2) if the connection will not forward traffic. The details of why it is not forwarding traffic are not important in this context. > (b) Assume that mplsXCTable.1.10.100.1.mplsXCAdminStatus == down(2) > > What does this mean ? Is this the adminStatus of the incoming >segment > or the outgoing segment ? or Does it represent the overall admin >Status of the point-to-multipoint connection ? It is meant to denote the overall status of the connection. The specifics of whether or not the actual in/out label is "enabled" are up to your implementation. --Tom From owner-mpls@UU.NET Wed Jan 3 19:42:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10731 for ; Wed, 3 Jan 2001 19:42:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwle07442; Thu, 4 Jan 2001 00:42:07 GMT Received: by mail-control.mail.uu.net id QQjwle10378 for mpls-outgoing; Thu, 4 Jan 2001 00:41:49 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwle10367 for ; Thu, 4 Jan 2001 00:41: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 QQjwle16826 for ; Thu, 4 Jan 2001 00:40:49 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 QQjwle05149 for ; Thu, 4 Jan 2001 00:40:48 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 TAA24927; Wed, 3 Jan 2001 19:40:35 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA23414; Wed, 3 Jan 2001 19:40:38 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 19:40:37 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF446BD7@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: "'Thomas D. Nadeau'" , mpls@UU.NET Cc: cheenu Srinivasan , Arun Viswanathan Subject: RE: Questions on creation of p2mp connection using LSR-MIB Date: Wed, 3 Jan 2001 19:40:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom! Thanks for your reply. I am still a little confused. I will appreciate, if you can clarify my understanding of your response. (A) Meaning of the mplsXCAdminStatus field Based on your response, When a user sets (i)mplsXCTable.1.10.100.2.mplsXCAdminStatus to down(2), =>user wants the switch to stop forwarding on the out segment with mplsOutSegmentIndex =2 where as, if the user sets (ii) mplsXCTable.1.10.100.1.mplsXCAdminStatus to down(2) => "overall" connection has been administrated to down and switch should not forward on ANY of the out segments How do you know which of the two mplsXCAdminStatus fields represents the "overall" connection's admin status?? [Similar questions arises for mp2p connections because of multiple AdminStatus fields in XC table] (B) This is a follow up question: Why didn't we use a single XC entry in the mplsXCTable for each connection (p2p/p2mp/mp2p)? Thanks, sanjay -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, January 03, 2001 2:32 PM To: Choudhury, Sanjaya; mpls@UU.NET Cc: cheenu Srinivasan; Arun Viswanathan Subject: Re: Questions on creation of p2mp connection using LSR-MIB Sanjaya, Answers are in-line. > Hi! I have few questions related to establishment of >point-to-multipoint > connections using LSR-MIB. Your comments / suggestions will be > appreciated. > > Thanks, > sanjay > > Consider the following example: > ------------------------------------- > In mplsInSegmentTable : > { > mplsInSegmentIfIndex = 10 > mplsInSegmentLabel = 100 > ... > } > In mplsOutSegmentTable: > { > mplsOutSegmentIndex = 1 > mplsOutSegmentIfIndex = 11 > ... > ---------------------------------- > mplsOutSegmentIndex = 2 > mplsOutSegmentIfIndex = 12 > ... > } > > As per the current indexing scheme, I have to create the following > two rows in the mplsXCTable: > { > (create a row in this table using the index: 1.10.100.1) > mplsXCIndex = 1 > mplsXCLSPId = 999 > .... > > (create a row in this table using the index: 1.10.100.2) > mplsXCIndex = 1 (corrected a typo) > mplsXCLSPId = 999 > .... > } > > Creation of the above mentioned row in the XC table will >automatically > populate the mplsInSegmentXCIndex and mplsOutSegmentXCIndex. > > Now the questions: > ----------------------- > (a) mplsXCTable.1.10.100.2.mplsXCAdminStatus == down(2) > =>The desired operational status of this segment (outgoing) is > down and no packets should be forwarded on this segment. > > Is my assumption correct ? If you are referring to the operational status of the in/OutSegments, remember that we no longer have operational status in the MPLS-LSR-MIB for in/out segments as they do not make sense. Your assumption is correct if you are assuming that the XCoperStatus = down(2) if the connection will not forward traffic. The details of why it is not forwarding traffic are not important in this context. > (b) Assume that mplsXCTable.1.10.100.1.mplsXCAdminStatus == down(2) > > What does this mean ? Is this the adminStatus of the incoming >segment > or the outgoing segment ? or Does it represent the overall admin >Status of the point-to-multipoint connection ? It is meant to denote the overall status of the connection. The specifics of whether or not the actual in/out label is "enabled" are up to your implementation. --Tom From owner-mpls@UU.NET Wed Jan 3 20:00:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11006 for ; Wed, 3 Jan 2001 20:00:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwlg10709; Thu, 4 Jan 2001 01:00:07 GMT Received: by mail-control.mail.uu.net id QQjwlf11538 for mpls-outgoing; Thu, 4 Jan 2001 00:59:48 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwlf11533 for ; Thu, 4 Jan 2001 00:59:36 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 QQjwlf27478 for ; Thu, 4 Jan 2001 00:58:32 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwlf02397 for ; Thu, 4 Jan 2001 00:58:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA22037 for mpls@uu.net; Wed, 3 Jan 2001 19:58:31 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwlf11498 for ; Thu, 4 Jan 2001 00:58: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 QQjwlf06767 for ; Thu, 4 Jan 2001 00:57:50 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 QQjwlf01691 for ; Thu, 4 Jan 2001 00:57:50 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id TAA00202; Wed, 3 Jan 2001 19:57:31 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id AAE05321; Wed, 3 Jan 2001 19:57:40 -0500 (EST) Message-Id: <4.3.2.7.2.20010103195125.021a5228@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 03 Jan 2001 20:00:17 -0500 To: "Choudhury, Sanjaya" , mpls@UU.NET From: "Thomas D. Nadeau" Subject: RE: Questions on creation of p2mp connection using LSR-MIB Cc: cheenu Srinivasan , Arun Viswanathan In-Reply-To: <4FBEA8857476D311A03300204840E1CF446BD7@whq-msgusr-02.pit.c omms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Sanjay, > How do you know which of the two mplsXCAdminStatus fields > represents the "overall" connection's admin status?? It depends on how you have implemented this. You can implement this in two different ways: a) you can use a single XC entry and have a single inSegment map to multiple outSegments using the same XC or b) you can have two different XC entries, one for each outSegment and the same inSegment. In the first case, a single XC would have to be disabled. In the second case, you would have two XC entries which would have to both be disabled. > [Similar questions arises for mp2p connections because > of multiple AdminStatus fields in XC table] > > (B) This is a follow up question: Why didn't we use a > single XC entry in the mplsXCTable for each connection > (p2p/p2mp/mp2p)? This is certainly a valid way of implementing this, as I pointed out above. --Tom From owner-mpls@UU.NET Wed Jan 3 20:42:48 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11776 for ; Wed, 3 Jan 2001 20:42:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwli11777; Thu, 4 Jan 2001 01:42:48 GMT Received: by mail-control.mail.uu.net id QQjwli26433 for mpls-outgoing; Thu, 4 Jan 2001 01:42:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwli26421 for ; Thu, 4 Jan 2001 01:42: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 QQjwli07067 for ; Thu, 4 Jan 2001 01:41:06 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjwli03603 for ; Thu, 4 Jan 2001 01:41:03 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 UAA08416; Wed, 3 Jan 2001 20:40:40 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200101040140.UAA08416@workhorse.fictitious.org> To: Keith.Schuettpelz@go.ecitele.com cc: ewgray@mindspring.com, Ben Black , Dan Tappan , mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: MPLS and fragmentation... In-reply-to: Your message of "Thu, 14 Dec 2000 15:46:25 EST." <852569B5.00722D9D.00@ussmtp01.ftl.telematics.com> Date: Wed, 03 Jan 2001 20:40:40 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <852569B5.00722D9D.00@ussmtp01.ftl.telematics.com>, Keith.Schuettpel z@go.ecitele.com writes: > > > > Eric Gray wrote: > > > Consider this. You are about to discard a packet > > because it is to large. Who cares if you do this on the > > slow path? > > I see at least 2 issues... > > 1) If you need to fragment the packet rather than discard it > Doing this in the slow path can result in packet re-ordering w.r.t. > subsequent smaller packets processed in the fast path. > Is this acceptable? Generate ICMP if DF is set or silently discard if DF is clear might be the best thing to do. Attempting to fragment the DF-clear traffic and dropping if the rate was too high would be fine as long as it couldn't result in any sort of denial of service or instability due to processor loading. PMTU (rfc1191) will still work if packets without DF are discarded. TCP implementations that don't use PMTU will break if they use the local interface MTU and packets without DF are discarded. > 2) If you need to send an ICMP message back to the source. > How fast must the slow path be in order to handle all of the > concurrent PMTUD's being performed by the many TCP flows > passing through a core link? I.e. What percentage of the packets will > be performing PMTUD and have the DF bit set, requiring the generation > of an ICMP message? When PMTU is used, the TCP flows only very rarely send a larger packet to probe the MTU size. An abnormal case would be a reroute that results in a smaller MTU. This is where the LSR must be able to survive a transient period where it is called upon to generate ICMP and fragment at a very high rate. RSVP-TE has it right. If tunnel reroutes using make-before-break, the MTU changes at the ingress and any ICMP or fragmenting happens there. Curtis From owner-mpls@UU.NET Thu Jan 4 03:29:50 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00294 for ; Thu, 4 Jan 2001 03:29:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwmj19031; Thu, 4 Jan 2001 08:29:50 GMT Received: by mail-control.mail.uu.net id QQjwmj20710 for mpls-outgoing; Thu, 4 Jan 2001 08:29:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwmj20699 for ; Thu, 4 Jan 2001 08:29: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 QQjwmj03456 for ; Thu, 4 Jan 2001 08:28:29 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 QQjwmj17005 for ; Thu, 4 Jan 2001 08:28:26 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id OAA29756 for ; Thu, 4 Jan 2001 14:05:32 GMT Received: from wipro.com ([192.168.220.54]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA4530 for ; Thu, 4 Jan 2001 13:55:47 +0530 Message-ID: <3A5434BB.83154511@wipro.com> Date: Thu, 04 Jan 2001 14:00:52 +0530 From: "Amarnath Honnavalli Anantharamaiah" X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Regarding Address Message and Address Withdraw message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi *, Sorry if my questiong is very prelimnary.. But there isnt much explanation of Address message and address withdraw message in the draft or any other state m/c explanation. As per the MPLS architecture document this message will be sent by every LSR before sending or receiving any Label Request or Label mapping message OR when a new interface is created or removed.... I have several questions regarding this... [1] Does an LSR advertive this mapping for all the interfaces/label space it has OR does it only advertise only the interface address on which session is establised. For eg. in a scenario as under. Does R2 advertise interface address label space mapping for all the label space a,b,c to R1 or only the interface address of only R2:b to R1. --- session s1 --- session s2 --- | R1|---------------a | R2| b ----------------| R3| --- --- --- c \ \sesssion s3 \ --- | R3| --- [2] If it is advertising interface address of all the label space R2:a, R2:b, R2:c to R1 for eg., R1 will have a mapping of LDPID and interface address as under LDPId interface R2:a i1 R2:b i2 R2:c i3 What does LSR R1 do with the other mappings R2:b and R2:c [3] If it is only advertising interface address of the label space on the established, then this is not required because we know the interface address at the session establishment. Am I right !!! Thanks in Advance Amar From owner-mpls@UU.NET Thu Jan 4 06:29:54 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01669 for ; Thu, 4 Jan 2001 06:29:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwmv22594; Thu, 4 Jan 2001 11:29:53 GMT Received: by mail-control.mail.uu.net id QQjwmv10104 for mpls-outgoing; Thu, 4 Jan 2001 11:29:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwmv10092 for ; Thu, 4 Jan 2001 11:29: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 QQjwmv28928 for ; Thu, 4 Jan 2001 11:27:43 GMT From: mike.sexton@alcatel.co.uk Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQjwmv28878 for ; Thu, 4 Jan 2001 11:27:42 GMT Received: from bemail01.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f04BQrL18567; Thu, 4 Jan 2001 12:26:53 +0100 (MET) Received: by bemail01.net.alcatel.be(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C12569CA.003EDF92 ; Thu, 4 Jan 2001 12:26:44 +0100 X-Lotus-FromDomain: ALCATEL To: James_Huang@Mitel.COM cc: mpls@UU.NET Message-ID: Date: Wed, 3 Jan 2001 12:07:03 +0000 Subject: Re: Questions on multiprovider VPN operations in RFC2547bis Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk James and Yakov, According to my understanding, RFC2547bis specifies a RD structure which is globally unique to allow for uncoordinated administration of this resource amongst service providers. Therefore surely the simple answer is: "No. There is no need to change the RD at the boundary indeed such an uneccesary VPN-IP4 address translation should be deprecated." Administratively the service provider receiving the request to add a site will determine the RD to be used and should be able to expect other participating SPs to work with that. What is more difficult to understand is Yakov's reply "...However, P1 *may* do the conversion.....". Under what circumstances is it envisaged that a conversion may be required? I suppose a SP is free to operate his service in a way which does not conform with global addressing conventions with regard to RDs and in this case the nonconforming SP would have to assume the burden of VPN-IP4 address translation. Do you have any more realistic scenarios in mind? To complete the simple story however there should be some explicit support for advertising RDs between the EBGP-talking route reflectors (if indeed this does not exist already). I suppose that, except for taking the precaution of defining an RD structure which can support global uniqueness while remaining free of implied semantics (itself something of a contradiction) the wider issues surrounding interconnection at MPLS boundaries are all out of scope for the moment and "for further study". The question does lead on to some more fundamental issues which arise at MPLS administrative domain boundaries. In addition to reachability advertisements there is the probable need for some sort of Bandwidth Broker or policy manager to deal with extending SLAs accross the boundary. This may force an architecture that requires LSPs to terminate at the bounday to be reinitiated in the connected domain just so that IP layer header information may be re-examined to support policing etc. potentially frustrating much of the MPLS scalability gains at core gateways. Alternatively it will be necessary to elaborate on SLAs based on (or easily mappable to) LSPs carrying aggregated (eg similar service level) flows implying per LSP OAM flows. Irrespective of such service level issues, basic problem resolution in a multi-provider service environment will likely demand per LSP OAM flows which can be observed and acted upon at such boundaries. Regards, Mike Sexton James_Huang@Mitel.COM on 02/01/2001 20:12:46 To: mpls@UU.NET cc: (bcc: Michael J SEXTON/GB/ALCATEL) Subject: Questions on multiprovider VPN operations in RFC2547bis Hello, RFC2547bis supports multiprovider VPNs in which a VPN customer has two sites each served by a distinct VPN service provider. The VPN service providers serving the customer are themselves served by yet another VPN service provider. Suppose we have the following VPN deployment, CE1 --- (PE11 -- P1 -- PE12) == (PE21 -- P2 -- PE22) == (PE31 -- P3 -- PE32) -- CE2 PE11, P1, and PE12 are in AS1, PE21, P2, and PE22 are in AS2, and PE31, P3, and PE32 are in AS3. Assuming that P1 and P3 are route reflectors and are talking EBGP to each other. So when PE32 advertises a VPN-ipv4 route for CE2 to P3, P3 will in turn advertise the route to P1. When P1 receives the advertisement, it will then send the advertisement to PE11 and PE12. Here are my questions: (1) A VPN service provider can assign route distinguisher (RD) at its own discretion. So the VPN customer's RD in AS1 will likely be different from its RD in AS3. When P1 receives the VPN-ipv4 route advertisement from P3, does the RD in the advertisement need to be converted first before being sent to PE11 and PE12? (2) How about route target extended communities? Do they need to be converted too? (3) Can anyone show me a detailed diagram with both the control plane set-up and the data plane forwarding for the above VPN deployment scenario? Regards, -- James Huang From owner-mpls@UU.NET Thu Jan 4 10:26:36 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07000 for ; Thu, 4 Jan 2001 10:26:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwnl11547; Thu, 4 Jan 2001 15:26:36 GMT Received: by mail-control.mail.uu.net id QQjwnl13164 for mpls-outgoing; Thu, 4 Jan 2001 15:26:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwnl13141 for ; Thu, 4 Jan 2001 15:26:04 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 QQjwnl16068 for ; Thu, 4 Jan 2001 15:24:16 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjwnl08054 for ; Thu, 4 Jan 2001 15:24:16 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id HAA18924; Thu, 4 Jan 2001 07:24:15 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id HAA86015; Thu, 4 Jan 2001 07:24:14 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200101041524.HAA86015@garnet.juniper.net> To: mike.sexton@alcatel.co.uk cc: James_Huang@Mitel.COM, mpls@UU.NET Subject: Re: Questions on multiprovider VPN operations in RFC2547bis In-Reply-To: Your message of "Wed, 03 Jan 2001 12:07:03 GMT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86012.978621854.1@garnet.juniper.net> Date: Thu, 04 Jan 2001 07:24:14 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Mike, > According to my understanding, RFC2547bis specifies a RD structure > which is globally unique to allow for uncoordinated administration > of this resource among st service providers. Therefore surely the > simple answer is: "No. There is no need to change the RD at the > boundary indeed such an uneccesary VPN-IP4 address translation > should be deprecated." Administratively the service provider > receiving the request to add a site will determine the RD to be > used and should be able to expect other participating SPs to work > with that. What is more difficult to understand is Yakov's reply > "...How ever, P1 *may* do the conversion.....". Under what > circumstances is it envisaged that a conversion may be required? I can't think of any *practical* circumstances when such a conversion may be required. But from this it doesn't follow that there are no such practical circumstances - it is just that I am not aware of them. The point I'd like to make is that if such circumstances will arise, one may convert RDs. Yakov. From owner-mpls@UU.NET Thu Jan 4 10:35:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07337 for ; Thu, 4 Jan 2001 10:35:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwnm23021; Thu, 4 Jan 2001 15:35:51 GMT Received: by mail-control.mail.uu.net id QQjwnm14204 for mpls-outgoing; Thu, 4 Jan 2001 15:35:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwnm14196 for ; Thu, 4 Jan 2001 15:35: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 QQjwnm12904 for ; Thu, 4 Jan 2001 15:34:03 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQjwnm20474 for ; Thu, 4 Jan 2001 15:34:02 GMT Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 4 Jan 2001 10:33:52 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id C25QCWLA; Thu, 4 Jan 2001 10:33:45 -0500 Received: from nortelnetworks.com (starmie.engeast.baynetworks.com [192.32.148.132]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CGS4G8WB; Thu, 4 Jan 2001 10:33:48 -0500 Message-ID: <3A5497E0.C806C697@nortelnetworks.com> Date: Thu, 04 Jan 2001 10:33:52 -0500 From: "Antonela Paraschiv" X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: John Sparr CC: ewgray@mindspring.com, Bill Sanford , MPLS Mailing List Subject: Re: ERO and strict/loose subobject References: <20010103182014.34779.qmail@web11404.mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------16ECCF2E8325A702E8D51C80" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk --------------16ECCF2E8325A702E8D51C80 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi John, According to the draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, when the path message leaves node A (in your example with A, A1, A2, B nodes), the ERO should have ERO = {A1, B}. The following paragraphs from the spec (from 4.3.4.1. Selection of the Next Hop) state that if a node receives a path message in which the first ERO subobject does not belong to it, it has to reply with Bad initial object. "1) The node receiving the RSVP message MUST first evaluate the first subobject. If the node is not part of the abstract node described by the first subobject, it has received the message in error and SHOULD return a "Bad initial subobject" error. If there is no first subobject, the message is also in error and the system SHOULD return a "Bad EXPLICIT_ROUTE object" error." and "6) Finally, the node replaces the first subobject with any subobject that denotes an abstract node containing the next hop. This is necessary so that when the explicit route is received by the next hop, it will be accepted." Note please that step 1) above does not mention ANYTHING about first ERO subobject being strict or loose. Can any of the authors please confirm/infirm the above? Best regards, Antonela John Sparr wrote: > Hi Eric, > > You are right. I made a mistake. In the example, A is > not the abstract node and B should set the L bit. > > My question is how node A handle the ERO. Does the ERO > created by A contains only B's addr or both A's addr > and B's addr, when A sent out path msg with ERO? > Assuming A want to send ERO to B and regardless the > intermediate nodes. > > Thanks. > > Regards, > > John > > --- Eric Gray wrote: > > John, > > > > I believe part of the issue is your use of > > terms. > > In the example you give, I believe that either the > > "address" A must be that of an abstract node that > > includes addresses A1, A2 and A3 OR B needs > > to have the L bit set to indicate that it does not > > have to be the very next (adjacent) peer. I am > > sure that A cannot forward the Path message > > to A1, let alone to B, otherwise. > > > > I think if you recast your question in terms of > > "loose hops" and "abstract nodes" and re-read > > the applicable sections of the specification, your > > answer will emerge. > > > > -- > > Eric Gray > > > > John Sparr wrote: > > > > > Hi Bill, > > > > > > Thanks for the comments. > > > > > > I was still a little bit confused about the first > > > subobject in the ERO. Lets say the following > > example. > > > > > > A--A1--A2--A3--B--C > > > > > > Assuming A is the sender node and B is the > > receiver > > > node, A1-A3 are the intermediate nodes. A creates > > an > > > ERO with the first subobj A's addr (loose) and > > second > > > subobj B's addr. When A sends Path msg with the > > ERO > > > towards B, what should A do to the ERO, it should > > > delete the first subobj (itself addr)? or send > > both > > > subobjs to B? I think A should delet the first > > subobj, > > > but if it is, it's no use to add the first subobj( > > > itself addr) at the beginning of creating ERO. > > > > > > Please correct me. > > > > > > Thanks in advance > > > > > > Regards, > > > > > > John > > > > > > --- "Sanford, Bill" wrote: > > > > John, see the comments below: > > > > > > > > > -----Original Message----- > > > > > From: John Sparr [mailto:johnll44@yahoo.com] > > > > > Sent: Tuesday, January 02, 2001 3:43 PM > > > > > To: mpls@UU.NET > > > > > Subject: ERO and strict/loose subobject > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > One question about the ERO object in RSVP: > > > > > > > > > > Assuming there is a sender node and it creates > > an > > > > ERO. > > > > > Should the ERO include the ip address of > > sender > > > > > itself? If yes, why? > > > > > > > > Lets say the ERO is not set with the sender node > > and > > > > is started on the next > > > > hop. How does the LSP you want to set up know > > that > > > > there are no other hops > > > > in between the sender and next hop? If you > > don't > > > > have the senders ip > > > > address as the first subobject, there isn't any > > way > > > > to set the properties of > > > > the link to the next hop to loose or strict. > > > > > > > > In the implementation in > > > > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you > > > > didn't have the sender address in the ERO, it > > would > > > > immediately error with > > > > "Bad EXPLICIT_ROUTE object" error. > > > > > > > > In 4.3.4.1. Selection of the Next Hop, it > > explains: > > > > > > > > 1) The node receiving the RSVP message MUST > > first > > > > evaluate the first > > > > subobject. If the node is not part of the > > > > abstract node described by > > > > the first subobject, it has received the > > message > > > > in error and SHOULD > > > > return a "Bad initial subobject" error. If > > there > > > > is no first > > > > subobject, the message is also in error and > > the > > > > system SHOULD return > > > > a "Bad EXPLICIT_ROUTE object" error. > > > > > > > > > > > > > > Another question is about strict/loose object: > > > > > > > > > > The draft of RSVP-TE says "The path between a > > > > strict > > > > > node and its preceding node MUST include only > > > > network > > > > > nodes from the strict node and its preceding > > > > abstract > > > > > node." > > > > > > > > > > Does it mean if there is strict subobject in > > ERO, > > > > then > > > > > ther is no loose subobject and if there is > > loose > > > > > subobject, then there is no strict subobject? > > > > > > > > Not at all. You can have both strict hops and > > loose > > > > hops as part of the > > > > same ERO. On a "strict" hop link, there isn't > > any > > > > other route it can take > > > > except for the next hop in the ERO list. On a > > > > "loose" hop link, there can > > > > be additional hops between the nodes provided > > that > > > > it ends up on the next > > > > hop. > > > > > > > > Bill > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Yahoo! Photos - Share your holiday photos online! > > > http://photos.yahoo.com/ > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Photos - Share your holiday photos online! > http://photos.yahoo.com/ -- Antonela Paraschiv Passport MPLS, Carrier Data Networks, Nortel Networks Tel: (978)288-6136 (Esn : 248-6136) E-mail: antonela@nortelnetworks.com --------------16ECCF2E8325A702E8D51C80 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi John,

According to the draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, when the path message leaves node A (in your example with A, A1, A2, B nodes), the ERO should have

   ERO = {A1, B}.

The following paragraphs from the spec (from 4.3.4.1. Selection of the Next Hop) state that if a node receives a path message in which the first ERO subobject does not belong to it, it has to reply with Bad initial object.

   "1) The node receiving the RSVP message MUST first evaluate the first
   subobject.  If the node is not part of the abstract node described by
   the first subobject, it has received the message in error and SHOULD
   return a "Bad initial subobject" error.  If there is no first
   subobject, the message is also in error and the system SHOULD return
    a "Bad EXPLICIT_ROUTE object" error."
and
   "6) Finally, the node replaces the first subobject with any subobject
   that denotes an abstract node containing the next hop.  This is
   necessary so that when the explicit route is received by the next
   hop, it will be accepted."

Note please that step 1) above does not mention ANYTHING about first ERO subobject being strict or loose.

Can any of the authors please confirm/infirm the above?

Best regards,
Antonela
 
 
 

John Sparr wrote:

Hi Eric,

You are right. I made a mistake. In the example, A is
not the abstract node and B should set the L bit.

My question is how node A handle the ERO. Does the ERO
created by A contains only B's addr or both A's addr
and B's addr, when A sent out path msg with ERO?
Assuming A want to send ERO to B and regardless the
intermediate nodes.

Thanks.

Regards,

John

--- Eric Gray <ewgray@mindspring.com> wrote:
> John,
>
>     I believe part of the issue is your use of
> terms.
> In the example you give, I believe that either the
> "address" A must be that of an abstract node that
> includes addresses A1, A2 and A3 OR B needs
> to have the L bit set to indicate that it does not
> have to be the very next (adjacent) peer. I am
> sure that A cannot forward the Path message
> to A1, let alone to B, otherwise.
>
>     I think if you recast your question in terms of
> "loose hops" and "abstract nodes" and re-read
> the applicable sections of the specification, your
> answer will emerge.
>
> --
> Eric Gray
>
> John Sparr wrote:
>
> > Hi Bill,
> >
> > Thanks for the comments.
> >
> > I was still a little bit confused about the first
> > subobject in the ERO. Lets say the following
> example.
> >
> >     A--A1--A2--A3--B--C
> >
> > Assuming A is the sender node and B is the
> receiver
> > node, A1-A3 are the intermediate nodes. A creates
> an
> > ERO with the first subobj A's addr (loose) and
> second
> > subobj B's addr. When A sends Path msg with the
> ERO
> > towards B, what should A do to the ERO, it should
> > delete the first subobj (itself addr)? or send
> both
> > subobjs to B? I think A should delet the first
> subobj,
> > but if it is, it's no use to add the first subobj(
> > itself addr) at the beginning of creating ERO.
> >
> > Please correct me.
> >
> > Thanks in advance
> >
> > Regards,
> >
> > John
> >
> > --- "Sanford, Bill" <bills@netplane.com> wrote:
> > > John, see the comments below:
> > >
> > > > -----Original Message-----
> > > > From: John Sparr [mailto:johnll44@yahoo.com]
> > > > Sent: Tuesday, January 02, 2001 3:43 PM
> > > > To: mpls@UU.NET
> > > > Subject: ERO and strict/loose subobject
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > One question about the ERO object in RSVP:
> > > >
> > > > Assuming there is a sender node and it creates
> an
> > > ERO.
> > > > Should the ERO include the ip address of
> sender
> > > > itself? If yes, why?
> > >
> > > Lets say the ERO is not set with the sender node
> and
> > > is started on the next
> > > hop.  How does the LSP you want to set up know
> that
> > > there are no other hops
> > > in between the sender and next hop?  If you
> don't
> > > have the senders ip
> > > address as the first subobject, there isn't any
> way
> > > to set the properties of
> > > the link to the next hop to loose or strict.
> > >
> > > In the implementation in
> > > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you
> > > didn't have the sender address in the ERO, it
> would
> > > immediately error with
> > > "Bad EXPLICIT_ROUTE object" error.
> > >
> > > In 4.3.4.1. Selection of the Next Hop, it
> explains:
> > >
> > > 1) The node receiving the RSVP message MUST
> first
> > > evaluate the first
> > >    subobject.  If the node is not part of the
> > > abstract node described by
> > >    the first subobject, it has received the
> message
> > > in error and SHOULD
> > >    return a "Bad initial subobject" error.  If
> there
> > > is no first
> > >    subobject, the message is also in error and
> the
> > > system SHOULD return
> > >    a "Bad EXPLICIT_ROUTE object" error.
> > >
> > > >
> > > > Another question is about strict/loose object:
> > > >
> > > > The draft of RSVP-TE says "The path between a
> > > strict
> > > > node and its preceding node MUST include only
> > > network
> > > > nodes from the strict node and its preceding
> > > abstract
> > > > node."
> > > >
> > > > Does it mean if there is strict subobject in
> ERO,
> > > then
> > > > ther is no loose subobject and if there is
> loose
> > > > subobject, then there is no strict subobject?
> > >
> > > Not at all.  You can have both strict hops and
> loose
> > > hops as part of the
> > > same ERO.  On a "strict" hop link, there isn't
> any
> > > other route it can take
> > > except for the next hop in the ERO list.  On a
> > > "loose" hop link, there can
> > > be additional hops between the nodes provided
> that
> > > it ends up on the next
> > > hop.
> > >
> > > Bill
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Photos - Share your holiday photos online!
> > http://photos.yahoo.com/
>

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

-- 
Antonela Paraschiv 
Passport MPLS, Carrier Data Networks, Nortel Networks
Tel: (978)288-6136 (Esn : 248-6136)
E-mail: antonela@nortelnetworks.com
  --------------16ECCF2E8325A702E8D51C80-- From owner-mpls@UU.NET Thu Jan 4 11:29:17 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09301 for ; Thu, 4 Jan 2001 11:29:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwnp26798; Thu, 4 Jan 2001 16:29:16 GMT Received: by mail-control.mail.uu.net id QQjwnp00489 for mpls-outgoing; Thu, 4 Jan 2001 16:28:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwnp00484 for ; Thu, 4 Jan 2001 16:28:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjwnp11985 for ; Thu, 4 Jan 2001 16:25:16 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 QQjwnp06975 for ; Thu, 4 Jan 2001 16:25:16 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA11678; Thu, 4 Jan 2001 08:24:53 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA09012; Thu, 4 Jan 2001 11:24:42 -0500 (EST) Message-Id: <200101041624.LAA09012@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: "Rijsman, Bruno" cc: "'Robert Raszuk'" , Yakov Rekhter , "'mpls@UU.NET'" , "BGP exploder (E-mail)" , "IDRP exploder (E-mail)" Subject: Re: Encoding of MPLS label in MP-REACH-NLRI question In-reply-to: Your message of Sun, 31 Dec 2000 10:49:15 -0500. <49FF5C6DDBD8D311BBBD009027DE980CC11D8A@uniwest1.redstonecom.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Thu, 04 Jan 2001 11:24:42 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Right now the draft says: The Label field carries one or more labels (that corresponds to the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 octets, where the high-order bit contains "Bottom of Stack" (as defined in [MPLS-ENCAPS]). The following high-order three bits must be zero. The remaining 20 bits contain the label value. Barring objection, I will change this to: The Label field carries one or more labels (that corresponds to the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 octets, where the high-order 20 bits contain the label value, the following three bits must be zero, and the low order bit contains "Bottom of Stack" (as defined in [MPLS-ENCAPS]). and reissue the draft. From owner-mpls@UU.NET Thu Jan 4 11:39:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09571 for ; Thu, 4 Jan 2001 11:39:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwnq11242; Thu, 4 Jan 2001 16:39:09 GMT Received: by mail-control.mail.uu.net id QQjwnq01514 for mpls-outgoing; Thu, 4 Jan 2001 16:38:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwnq01503 for ; Thu, 4 Jan 2001 16:38:44 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 QQjwnq07855 for ; Thu, 4 Jan 2001 16:37:19 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 QQjwnq27073 for ; Thu, 4 Jan 2001 16:37:18 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 LAA10000; Thu, 4 Jan 2001 11:36:57 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200101041636.LAA10000@workhorse.fictitious.org> To: jie yang ee stnt cc: mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Routing In-reply-to: Your message of "Wed, 13 Dec 2000 12:30:33 EST." <200012131730.MAA07196@lycia.njit.edu> Date: Thu, 04 Jan 2001 11:36:57 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <200012131730.MAA07196@lycia.njit.edu>, jie yang ee stnt writes: > > } From owner-mpls@UU.NET Wed Dec 13 12:07 EST 2000 > } To: "Faisal S. Naik" > } cc: mpls uunet > } Subject: Re: Routing > } MIME-Version: 1.0 > } > } > } > Hello friends, > } > Forgive me if i am off topic, but i wanted to confirm one thing, > } > are todays IGPs dynamic in nature? Also are they capable of selecting an > alternate route (if available) on their own? and how far do traffic engineeri > ng technologies help IGPs in this scenario. > } > Regards, > } > } Yes they are, and yes they can. However with a more complex network > } loadbalancing and TE becomes incresingly complex. > } > } - kurtis - > we believe that multipath routing and traffic dispersion have some benefit > in network security, reliability and, perhaps, performance. But I am not > quite sure whether today's IGPs are able to find several possilble > paths at a time and how difficult it is to be implemented, including > balance loading algorithms. would someone > draw a light on the trade-offs of such a scenario? > thank you. > Jie [ I'm not sure who "we" is. In the IETF "we" speak as individuals unless there has been consensus established in a WG or among some set of people, such as a set of coauthors. ] ECMP is defined for OSPF. It is implemented for ISIS and BGP as well. You can create two or more LSP to the same egress and load split and if one goes down get a fast partial restoration with full restoration when the one that went down reroutes. There is also something called OMP (http://www.fictitious.org/omp) that has yet to be implemented in a core router. Curtis From owner-mpls@UU.NET Thu Jan 4 12:04:21 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10226 for ; Thu, 4 Jan 2001 12:04:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwns02614; Thu, 4 Jan 2001 17:04:22 GMT Received: by mail-control.mail.uu.net id QQjwns10145 for mpls-outgoing; Thu, 4 Jan 2001 17:03:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwns09589 for ; Thu, 4 Jan 2001 17:03:36 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 QQjwns14537 for ; Thu, 4 Jan 2001 17:03:02 GMT Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQjwns10167 for ; Thu, 4 Jan 2001 17:03:01 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA12069 for ; Thu, 4 Jan 2001 12:03:01 -0500 (EST) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id MAA12065; Thu, 4 Jan 2001 12:03:00 -0500 (EST) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA01777; Thu, 4 Jan 2001 12:03:00 -0500 Message-ID: <3A54AD56.48A6F5C4@hotair.hobl.lucent.com> Date: Thu, 04 Jan 2001 12:05:26 -0500 From: Ramesh Bhandari X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: jie yang ee stnt , mpls@UU.NET Subject: Re: Routing References: <200101041636.LAA10000@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit You can also look up my book "Survivable Networks:Algorithms for Diverse Routing", Kluwer (1999) for concepts on traffic splitting over a number of disjoint paths (inclduing algorithms for their determinations within a given network)), and full restoration, when a link or node fails. Ramesh Bhandari Curtis Villamizar wrote: > In message <200012131730.MAA07196@lycia.njit.edu>, jie yang ee stnt writes: > > > > } From owner-mpls@UU.NET Wed Dec 13 12:07 EST 2000 > > } To: "Faisal S. Naik" > > } cc: mpls uunet > > } Subject: Re: Routing > > } MIME-Version: 1.0 > > } > > } > > } > Hello friends, > > } > Forgive me if i am off topic, but i wanted to confirm one thing, > > } > are todays IGPs dynamic in nature? Also are they capable of selecting an > > alternate route (if available) on their own? and how far do traffic engineeri > > ng technologies help IGPs in this scenario. > > } > Regards, > > } > > } Yes they are, and yes they can. However with a more complex network > > } loadbalancing and TE becomes incresingly complex. > > } > > } - kurtis - > > > we believe that multipath routing and traffic dispersion have some benefit > > in network security, reliability and, perhaps, performance. But I am not > > quite sure whether today's IGPs are able to find several possilble > > paths at a time and how difficult it is to be implemented, including > > balance loading algorithms. would someone > > draw a light on the trade-offs of such a scenario? > > thank you. > > Jie > > > [ I'm not sure who "we" is. In the IETF "we" speak as individuals > unless there has been consensus established in a WG or among some set > of people, such as a set of coauthors. ] > > ECMP is defined for OSPF. It is implemented for ISIS and BGP as well. > > You can create two or more LSP to the same egress and load split and > if one goes down get a fast partial restoration with full restoration > when the one that went down reroutes. > > There is also something called OMP (http://www.fictitious.org/omp) > that has yet to be implemented in a core router. > > Curtis From owner-mpls@UU.NET Thu Jan 4 13:11:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11789 for ; Thu, 4 Jan 2001 13:11:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwnw22593; Thu, 4 Jan 2001 18:10:58 GMT Received: by mail-control.mail.uu.net id QQjwnw04724 for mpls-outgoing; Thu, 4 Jan 2001 18:10:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwnw04698 for ; Thu, 4 Jan 2001 18:10: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 QQjwnw21132 for ; Thu, 4 Jan 2001 18:09:15 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjwnw20217 for ; Thu, 4 Jan 2001 18:09:14 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 NAA11623; Thu, 4 Jan 2001 13:08:23 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200101041808.NAA11623@workhorse.fictitious.org> To: "Faisal S. Naik" cc: "mpls uunet" , zaziz@cisco.com, prasanna@csa.iisc.ernet.in Reply-To: curtis@avici.com Subject: Re: Some queries In-reply-to: Your message of "Sat, 16 Dec 2000 07:04:27 +0500." <009401c06704$892669a0$f23987cb@faisal-s> Date: Thu, 04 Jan 2001 13:08:23 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <009401c06704$892669a0$f23987cb@faisal-s>, "Faisal S. Naik" writes: > > Hello friends,=20 > At a recent discussion with my MS class students, i was discussing MPLS = > and related issues. The discussion went into a complete confusion when = > we got stuck at the very question=20 > WHY use MPLS? > Is it only because of the fact that the efficient swapping mechanism, = > that MPLS is considered good. What about already accepted switching = > techs like ATMs, incase they are integrated with IPv6 networks for = > better services like QoS through flow labels? > would anyone be kind enough to clarify? > Regards, > Faisal Hi, I just read the answers on this an you guys all got it wrong. :-) The scaling argument was close, but hierarchy was needed in some way that could make the overall solution scale, not just allow the PNNI routing to scale but prevent scalability in the upper layers. There were a number of motivations for getting rid of ATM in IP networks. One was the cell tax which at a typical 20% would not alone kill ATM. Another was SAR. You can't get fast ATM router interfaces because SAR speed and SAR buffering becomes a problem. This alone was enough to kill ATM. Perhaps even larger was the problems of independent control planes and the effect on IGP scaling. Flooding is needed for reliability in the IGP and flooding in a full mesh of N routers has some N^3 properties with regard to messages sent when a router in the mesh fails and N^2 when a VC fails. Attempts to constrain the flooding tended to slow convergence and sometimes cause long lived IGP inconsistency when change occurred. This is not a problem is the flooding follows the physical interconnections as it does with MPLS since the number of adjacencies per node drops dramatically. The IGP scaling problem was address by ISPs by partitioning their network into core and regions but this reduced the effectivenes of TE. There was also no way to change a BW reservation amount and no make-before-break rerouting. If a better path was available, ATM implementations would not use it (or would not do so for very long periods of time). There was more attention to adaptivity in MPLS. Lack of local-protect was at one point seen as a limitation. There were also implementation issues. ATM vendors were slow to add buffering to the switches and never added enough. They were slow to do EPD/PPD and never did RED, pushing ABR way too long (which never worked well in practice). There was reluctance to give up on the CAC religion and allow overbooking. Layout algorithms were not very good for what the ISPs wanted to do and results were poor. Curtis From owner-mpls@UU.NET Thu Jan 4 13:12:59 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11824 for ; Thu, 4 Jan 2001 13:12:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwnw22493; Thu, 4 Jan 2001 18:12:58 GMT Received: by mail-control.mail.uu.net id QQjwnw05013 for mpls-outgoing; Thu, 4 Jan 2001 18:12:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwnw04996 for ; Thu, 4 Jan 2001 18:12:32 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 QQjwnw17829 for ; Thu, 4 Jan 2001 18:11:54 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwnw24435 for ; Thu, 4 Jan 2001 18:11:53 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA11387 for mpls@uu.net; Thu, 4 Jan 2001 13:11:53 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwnw04872 for ; Thu, 4 Jan 2001 18:11:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjwnw14904 for ; Thu, 4 Jan 2001 18:10:56 GMT Received: from xover.hjinc.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjwnw22486 for ; Thu, 4 Jan 2001 18:10:55 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Jan 2001 13:08:41 -0500 Message-ID: <87009604743AD411B1F600508BA0F959040D1F@xover.hjinc.com> From: "Sanford, Bill" To: "'Antonela Paraschiv'" , John Sparr Cc: ewgray@mindspring.com, "Sanford, Bill" , MPLS Mailing List Subject: RE: ERO and strict/loose subobject Date: Thu, 4 Jan 2001 13:08:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07679.5DE0AE20" 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_01C07679.5DE0AE20 Content-Type: text/plain So if we go back to John's original question: -----Original Message----- From: Antonela Paraschiv [mailto:antonela@nortelnetworks.com] Sent: Thursday, January 04, 2001 10:34 AM To: John Sparr Cc: ewgray@mindspring.com; Bill Sanford; MPLS Mailing List Subject: Re: ERO and strict/loose subobject Hi John, According to the draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, when the path message leaves node A (in your example with A, A1, A2, B nodes), the ERO should have ERO = {A1, B}. The following paragraphs from the spec (from 4.3.4.1. Selection of the Next Hop) state that if a node receives a path message in which the first ERO subobject does not belong to it, it has to reply with Bad initial object. "1) The node receiving the RSVP message MUST first evaluate the first subobject. If the node is not part of the abstract node described by the first subobject, it has received the message in error and SHOULD return a "Bad initial subobject" error. If there is no first subobject, the message is also in error and the system SHOULD return a "Bad EXPLICIT_ROUTE object" error." and "6) Finally, the node replaces the first subobject with any subobject that denotes an abstract node containing the next hop. This is necessary so that when the explicit route is received by the next hop, it will be accepted." Note please that step 1) above does not mention ANYTHING about first ERO subobject being strict or loose. Can any of the authors please confirm/infirm the above? Best regards, Antonela John Sparr wrote: Hi Eric, You are right. I made a mistake. In the example, A is not the abstract node and B should set the L bit. My question is how node A handle the ERO. Does the ERO created by A contains only B's addr or both A's addr and B's addr, when A sent out path msg with ERO? Assuming A want to send ERO to B and regardless the intermediate nodes. Thanks. Regards, John --- Eric Gray wrote: > John, > > I believe part of the issue is your use of > terms. > In the example you give, I believe that either the > "address" A must be that of an abstract node that > includes addresses A1, A2 and A3 OR B needs > to have the L bit set to indicate that it does not > have to be the very next (adjacent) peer. I am > sure that A cannot forward the Path message > to A1, let alone to B, otherwise. > > I think if you recast your question in terms of > "loose hops" and "abstract nodes" and re-read > the applicable sections of the specification, your > answer will emerge. > > -- > Eric Gray > > John Sparr wrote: > > > Hi Bill, > > > > Thanks for the comments. > > > > I was still a little bit confused about the first > > subobject in the ERO. Lets say the following > example. > > > > A--A1--A2--A3--B--C > > > > Assuming A is the sender node and B is the > receiver > > node, A1-A3 are the intermediate nodes. A creates > an > > ERO with the first subobj A's addr (loose) and > second > > subobj B's addr. When A sends Path msg with the > ERO > > towards B, what should A do to the ERO, it should > > delete the first subobj (itself addr)? or send > both > > subobjs to B? I think A should delet the first > subobj, > > but if it is, it's no use to add the first subobj( > > itself addr) at the beginning of creating ERO. > > > > Please correct me. > > > > Thanks in advance > > > > Regards, > > > > John > > > > --- "Sanford, Bill" wrote: > > > John, see the comments below: > > > > > > > -----Original Message----- > > > > From: John Sparr [ mailto:johnll44@yahoo.com ] > > > > Sent: Tuesday, January 02, 2001 3:43 PM > > > > To: mpls@UU.NET > > > > Subject: ERO and strict/loose subobject > > > > > > > > > > > > Hi all, > > > > > > > > One question about the ERO object in RSVP: > > > > > > > > Assuming there is a sender node and it creates > an > > > ERO. > > > > Should the ERO include the ip address of > sender > > > > itself? If yes, why? > > > > > > Lets say the ERO is not set with the sender node > and > > > is started on the next > > > hop. How does the LSP you want to set up know > that > > > there are no other hops > > > in between the sender and next hop? If you > don't > > > have the senders ip > > > address as the first subobject, there isn't any > way > > > to set the properties of > > > the link to the next hop to loose or strict. > > > > > > In the implementation in > > > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you > > > didn't have the sender address in the ERO, it > would > > > immediately error with > > > "Bad EXPLICIT_ROUTE object" error. > > > > > > In 4.3.4.1. Selection of the Next Hop, it > explains: > > > > > > 1) The node receiving the RSVP message MUST > first > > > evaluate the first > > > subobject. If the node is not part of the > > > abstract node described by > > > the first subobject, it has received the > message > > > in error and SHOULD > > > return a "Bad initial subobject" error. If > there > > > is no first > > > subobject, the message is also in error and > the > > > system SHOULD return > > > a "Bad EXPLICIT_ROUTE object" error. > > > > > > > > > > > Another question is about strict/loose object: > > > > > > > > The draft of RSVP-TE says "The path between a > > > strict > > > > node and its preceding node MUST include only > > > network > > > > nodes from the strict node and its preceding > > > abstract > > > > node." > > > > > > > > Does it mean if there is strict subobject in > ERO, > > > then > > > > ther is no loose subobject and if there is > loose > > > > subobject, then there is no strict subobject? > > > > > > Not at all. You can have both strict hops and > loose > > > hops as part of the > > > same ERO. On a "strict" hop link, there isn't > any > > > other route it can take > > > except for the next hop in the ERO list. On a > > > "loose" hop link, there can > > > be additional hops between the nodes provided > that > > > it ends up on the next > > > hop. > > > > > > Bill > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Photos - Share your holiday photos online! > > http://photos.yahoo.com/ > __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ -- Antonela Paraschiv Passport MPLS, Carrier Data Networks, Nortel Networks Tel: (978)288-6136 (Esn : 248-6136) E-mail: antonela@nortelnetworks.com ------_=_NextPart_001_01C07679.5DE0AE20 Content-Type: text/html
So if we go back to John's original question:
 
-----Original Message-----
From: Antonela Paraschiv [mailto:antonela@nortelnetworks.com]
Sent: Thursday, January 04, 2001 10:34 AM
To: John Sparr
Cc: ewgray@mindspring.com; Bill Sanford; MPLS Mailing List
Subject: Re: ERO and strict/loose subobject

Hi John,

According to the draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, when the path message leaves node A (in your example with A, A1, A2, B nodes), the ERO should have

   ERO = {A1, B}.

The following paragraphs from the spec (from 4.3.4.1. Selection of the Next Hop) state that if a node receives a path message in which the first ERO subobject does not belong to it, it has to reply with Bad initial object.

   "1) The node receiving the RSVP message MUST first evaluate the first
   subobject.  If the node is not part of the abstract node described by
   the first subobject, it has received the message in error and SHOULD
   return a "Bad initial subobject" error.  If there is no first
   subobject, the message is also in error and the system SHOULD return
    a "Bad EXPLICIT_ROUTE object" error."
and
   "6) Finally, the node replaces the first subobject with any subobject
   that denotes an abstract node containing the next hop.  This is
   necessary so that when the explicit route is received by the next
   hop, it will be accepted."

Note please that step 1) above does not mention ANYTHING about first ERO subobject being strict or loose.

Can any of the authors please confirm/infirm the above?

Best regards,
Antonela
 
 
 

John Sparr wrote:

Hi Eric,

You are right. I made a mistake. In the example, A is
not the abstract node and B should set the L bit.

My question is how node A handle the ERO. Does the ERO
created by A contains only B's addr or both A's addr
and B's addr, when A sent out path msg with ERO?
Assuming A want to send ERO to B and regardless the
intermediate nodes.

Thanks.

Regards,

John

--- Eric Gray <ewgray@mindspring.com> wrote:
> John,
>
>     I believe part of the issue is your use of
> terms.
> In the example you give, I believe that either the
> "address" A must be that of an abstract node that
> includes addresses A1, A2 and A3 OR B needs
> to have the L bit set to indicate that it does not
> have to be the very next (adjacent) peer. I am
> sure that A cannot forward the Path message
> to A1, let alone to B, otherwise.
>
>     I think if you recast your question in terms of
> "loose hops" and "abstract nodes" and re-read
> the applicable sections of the specification, your
> answer will emerge.
>
> --
> Eric Gray
>
> John Sparr wrote:
>
> > Hi Bill,
> >
> > Thanks for the comments.
> >
> > I was still a little bit confused about the first
> > subobject in the ERO. Lets say the following
> example.
> >
> >     A--A1--A2--A3--B--C
> >
> > Assuming A is the sender node and B is the
> receiver
> > node, A1-A3 are the intermediate nodes. A creates
> an
> > ERO with the first subobj A's addr (loose) and
> second
> > subobj B's addr. When A sends Path msg with the
> ERO
> > towards B, what should A do to the ERO, it should
> > delete the first subobj (itself addr)? or send
> both
> > subobjs to B? I think A should delet the first
> subobj,
> > but if it is, it's no use to add the first subobj(
> > itself addr) at the beginning of creating ERO.
> >
> > Please correct me.
> >
> > Thanks in advance
> >
> > Regards,
> >
> > John
> >
> > --- "Sanford, Bill" <bills@netplane.com> wrote:
> > > John, see the comments below:
> > >
> > > > -----Original Message-----
> > > > From: John Sparr [mailto:johnll44@yahoo.com]
> > > > Sent: Tuesday, January 02, 2001 3:43 PM
> > > > To: mpls@UU.NET
> > > > Subject: ERO and strict/loose subobject
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > One question about the ERO object in RSVP:
> > > >
> > > > Assuming there is a sender node and it creates
> an
> > > ERO.
> > > > Should the ERO include the ip address of
> sender
> > > > itself? If yes, why?
> > >
> > > Lets say the ERO is not set with the sender node
> and
> > > is started on the next
> > > hop.  How does the LSP you want to set up know
> that
> > > there are no other hops
> > > in between the sender and next hop?  If you
> don't
> > > have the senders ip
> > > address as the first subobject, there isn't any
> way
> > > to set the properties of
> > > the link to the next hop to loose or strict.
> > >
> > > In the implementation in
> > > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you
> > > didn't have the sender address in the ERO, it
> would
> > > immediately error with
> > > "Bad EXPLICIT_ROUTE object" error.
> > >
> > > In 4.3.4.1. Selection of the Next Hop, it
> explains:
> > >
> > > 1) The node receiving the RSVP message MUST
> first
> > > evaluate the first
> > >    subobject.  If the node is not part of the
> > > abstract node described by
> > >    the first subobject, it has received the
> message
> > > in error and SHOULD
> > >    return a "Bad initial subobject" error.  If
> there
> > > is no first
> > >    subobject, the message is also in error and
> the
> > > system SHOULD return
> > >    a "Bad EXPLICIT_ROUTE object" error.
> > >
> > > >
> > > > Another question is about strict/loose object:
> > > >
> > > > The draft of RSVP-TE says "The path between a
> > > strict
> > > > node and its preceding node MUST include only
> > > network
> > > > nodes from the strict node and its preceding
> > > abstract
> > > > node."
> > > >
> > > > Does it mean if there is strict subobject in
> ERO,
> > > then
> > > > ther is no loose subobject and if there is
> loose
> > > > subobject, then there is no strict subobject?
> > >
> > > Not at all.  You can have both strict hops and
> loose
> > > hops as part of the
> > > same ERO.  On a "strict" hop link, there isn't
> any
> > > other route it can take
> > > except for the next hop in the ERO list.  On a
> > > "loose" hop link, there can
> > > be additional hops between the nodes provided
> that
> > > it ends up on the next
> > > hop.
> > >
> > > Bill
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Photos - Share your holiday photos online!
> > http://photos.yahoo.com/
>

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

-- 
Antonela Paraschiv 
Passport MPLS, Carrier Data Networks, Nortel Networks
Tel: (978)288-6136 (Esn : 248-6136)
E-mail: antonela@nortelnetworks.com
 
------_=_NextPart_001_01C07679.5DE0AE20-- From owner-mpls@UU.NET Thu Jan 4 13:20:17 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12113 for ; Thu, 4 Jan 2001 13:20:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwnx03027; Thu, 4 Jan 2001 18:20:10 GMT Received: by mail-control.mail.uu.net id QQjwnx06273 for mpls-outgoing; Thu, 4 Jan 2001 18:19:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwnx06260 for ; Thu, 4 Jan 2001 18:19: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 QQjwnx26237 for ; Thu, 4 Jan 2001 18:15:24 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwnx03557 for ; Thu, 4 Jan 2001 18:15:24 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA11990 for mpls@uu.net; Thu, 4 Jan 2001 13:15:23 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwnw05375 for ; Thu, 4 Jan 2001 18:14: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 QQjwnw23548 for ; Thu, 4 Jan 2001 18:13:49 GMT Received: from xover.hjinc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQjwnw26655 for ; Thu, 4 Jan 2001 18:13:49 GMT Received: by xover.hjinc.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Jan 2001 13:11:35 -0500 Message-ID: <87009604743AD411B1F600508BA0F959040D20@xover.hjinc.com> From: "Sanford, Bill" To: "'Antonela Paraschiv'" , John Sparr Cc: ewgray@mindspring.com, MPLS Mailing List Subject: RE: ERO and strict/loose subobject Date: Thu, 4 Jan 2001 13:11:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07679.C59BB410" 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_01C07679.C59BB410 Content-Type: text/plain So if we go back to John's original question, John> One question about the ERO object in RSVP: John> Assuming there is a sender node and it creates an ERO. Should the ERO include the ip address of sender itself? If yes, why? Doesn't the ERO list have to include the sender as the first hop so it can evaluate the next hop it has to go to? -----Original Message----- From: Antonela Paraschiv [mailto:antonela@nortelnetworks.com] Sent: Thursday, January 04, 2001 10:34 AM To: John Sparr Cc: ewgray@mindspring.com; Bill Sanford; MPLS Mailing List Subject: Re: ERO and strict/loose subobject Hi John, According to the draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, when the path message leaves node A (in your example with A, A1, A2, B nodes), the ERO should have ERO = {A1, B}. The following paragraphs from the spec (from 4.3.4.1. Selection of the Next Hop) state that if a node receives a path message in which the first ERO subobject does not belong to it, it has to reply with Bad initial object. "1) The node receiving the RSVP message MUST first evaluate the first subobject. If the node is not part of the abstract node described by the first subobject, it has received the message in error and SHOULD return a "Bad initial subobject" error. If there is no first subobject, the message is also in error and the system SHOULD return a "Bad EXPLICIT_ROUTE object" error." and "6) Finally, the node replaces the first subobject with any subobject that denotes an abstract node containing the next hop. This is necessary so that when the explicit route is received by the next hop, it will be accepted." Note please that step 1) above does not mention ANYTHING about first ERO subobject being strict or loose. Can any of the authors please confirm/infirm the above? Best regards, Antonela John Sparr wrote: Hi Eric, You are right. I made a mistake. In the example, A is not the abstract node and B should set the L bit. My question is how node A handle the ERO. Does the ERO created by A contains only B's addr or both A's addr and B's addr, when A sent out path msg with ERO? Assuming A want to send ERO to B and regardless the intermediate nodes. Thanks. Regards, John --- Eric Gray wrote: > John, > > I believe part of the issue is your use of > terms. > In the example you give, I believe that either the > "address" A must be that of an abstract node that > includes addresses A1, A2 and A3 OR B needs > to have the L bit set to indicate that it does not > have to be the very next (adjacent) peer. I am > sure that A cannot forward the Path message > to A1, let alone to B, otherwise. > > I think if you recast your question in terms of > "loose hops" and "abstract nodes" and re-read > the applicable sections of the specification, your > answer will emerge. > > -- > Eric Gray > > John Sparr wrote: > > > Hi Bill, > > > > Thanks for the comments. > > > > I was still a little bit confused about the first > > subobject in the ERO. Lets say the following > example. > > > > A--A1--A2--A3--B--C > > > > Assuming A is the sender node and B is the > receiver > > node, A1-A3 are the intermediate nodes. A creates > an > > ERO with the first subobj A's addr (loose) and > second > > subobj B's addr. When A sends Path msg with the > ERO > > towards B, what should A do to the ERO, it should > > delete the first subobj (itself addr)? or send > both > > subobjs to B? I think A should delet the first > subobj, > > but if it is, it's no use to add the first subobj( > > itself addr) at the beginning of creating ERO. > > > > Please correct me. > > > > Thanks in advance > > > > Regards, > > > > John > > > > --- "Sanford, Bill" wrote: > > > John, see the comments below: > > > > > > > -----Original Message----- > > > > From: John Sparr [ mailto:johnll44@yahoo.com ] > > > > Sent: Tuesday, January 02, 2001 3:43 PM > > > > To: mpls@UU.NET > > > > Subject: ERO and strict/loose subobject > > > > > > > > > > > > Hi all, > > > > > > > > One question about the ERO object in RSVP: > > > > > > > > Assuming there is a sender node and it creates > an > > > ERO. > > > > Should the ERO include the ip address of > sender > > > > itself? If yes, why? > > > > > > Lets say the ERO is not set with the sender node > and > > > is started on the next > > > hop. How does the LSP you want to set up know > that > > > there are no other hops > > > in between the sender and next hop? If you > don't > > > have the senders ip > > > address as the first subobject, there isn't any > way > > > to set the properties of > > > the link to the next hop to loose or strict. > > > > > > In the implementation in > > > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you > > > didn't have the sender address in the ERO, it > would > > > immediately error with > > > "Bad EXPLICIT_ROUTE object" error. > > > > > > In 4.3.4.1. Selection of the Next Hop, it > explains: > > > > > > 1) The node receiving the RSVP message MUST > first > > > evaluate the first > > > subobject. If the node is not part of the > > > abstract node described by > > > the first subobject, it has received the > message > > > in error and SHOULD > > > return a "Bad initial subobject" error. If > there > > > is no first > > > subobject, the message is also in error and > the > > > system SHOULD return > > > a "Bad EXPLICIT_ROUTE object" error. > > > > > > > > > > > Another question is about strict/loose object: > > > > > > > > The draft of RSVP-TE says "The path between a > > > strict > > > > node and its preceding node MUST include only > > > network > > > > nodes from the strict node and its preceding > > > abstract > > > > node." > > > > > > > > Does it mean if there is strict subobject in > ERO, > > > then > > > > ther is no loose subobject and if there is > loose > > > > subobject, then there is no strict subobject? > > > > > > Not at all. You can have both strict hops and > loose > > > hops as part of the > > > same ERO. On a "strict" hop link, there isn't > any > > > other route it can take > > > except for the next hop in the ERO list. On a > > > "loose" hop link, there can > > > be additional hops between the nodes provided > that > > > it ends up on the next > > > hop. > > > > > > Bill > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Photos - Share your holiday photos online! > > http://photos.yahoo.com/ > __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ -- Antonela Paraschiv Passport MPLS, Carrier Data Networks, Nortel Networks Tel: (978)288-6136 (Esn : 248-6136) E-mail: antonela@nortelnetworks.com ------_=_NextPart_001_01C07679.C59BB410 Content-Type: text/html
 
So if we go back to John's original question,

John> One question about the ERO object in RSVP:

John> Assuming there is a sender node and it creates an ERO. Should the ERO include the ip address of sender itself? If yes, why?

Doesn't the ERO list have to include the sender as the first hop so it can evaluate the next hop it has to go to?

-----Original Message-----
From: Antonela Paraschiv [mailto:antonela@nortelnetworks.com]
Sent: Thursday, January 04, 2001 10:34 AM
To: John Sparr
Cc: ewgray@mindspring.com; Bill Sanford; MPLS Mailing List
Subject: Re: ERO and strict/loose subobject

Hi John,

According to the draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, when the path message leaves node A (in your example with A, A1, A2, B nodes), the ERO should have

   ERO = {A1, B}.

The following paragraphs from the spec (from 4.3.4.1. Selection of the Next Hop) state that if a node receives a path message in which the first ERO subobject does not belong to it, it has to reply with Bad initial object.

   "1) The node receiving the RSVP message MUST first evaluate the first
   subobject.  If the node is not part of the abstract node described by
   the first subobject, it has received the message in error and SHOULD
   return a "Bad initial subobject" error.  If there is no first
   subobject, the message is also in error and the system SHOULD return
    a "Bad EXPLICIT_ROUTE object" error."
and
   "6) Finally, the node replaces the first subobject with any subobject
   that denotes an abstract node containing the next hop.  This is
   necessary so that when the explicit route is received by the next
   hop, it will be accepted."

Note please that step 1) above does not mention ANYTHING about first ERO subobject being strict or loose.

Can any of the authors please confirm/infirm the above?

Best regards,
Antonela
 
 
 

John Sparr wrote:

Hi Eric,

You are right. I made a mistake. In the example, A is
not the abstract node and B should set the L bit.

My question is how node A handle the ERO. Does the ERO
created by A contains only B's addr or both A's addr
and B's addr, when A sent out path msg with ERO?
Assuming A want to send ERO to B and regardless the
intermediate nodes.

Thanks.

Regards,

John

--- Eric Gray <ewgray@mindspring.com> wrote:
> John,
>
>     I believe part of the issue is your use of
> terms.
> In the example you give, I believe that either the
> "address" A must be that of an abstract node that
> includes addresses A1, A2 and A3 OR B needs
> to have the L bit set to indicate that it does not
> have to be the very next (adjacent) peer. I am
> sure that A cannot forward the Path message
> to A1, let alone to B, otherwise.
>
>     I think if you recast your question in terms of
> "loose hops" and "abstract nodes" and re-read
> the applicable sections of the specification, your
> answer will emerge.
>
> --
> Eric Gray
>
> John Sparr wrote:
>
> > Hi Bill,
> >
> > Thanks for the comments.
> >
> > I was still a little bit confused about the first
> > subobject in the ERO. Lets say the following
> example.
> >
> >     A--A1--A2--A3--B--C
> >
> > Assuming A is the sender node and B is the
> receiver
> > node, A1-A3 are the intermediate nodes. A creates
> an
> > ERO with the first subobj A's addr (loose) and
> second
> > subobj B's addr. When A sends Path msg with the
> ERO
> > towards B, what should A do to the ERO, it should
> > delete the first subobj (itself addr)? or send
> both
> > subobjs to B? I think A should delet the first
> subobj,
> > but if it is, it's no use to add the first subobj(
> > itself addr) at the beginning of creating ERO.
> >
> > Please correct me.
> >
> > Thanks in advance
> >
> > Regards,
> >
> > John
> >
> > --- "Sanford, Bill" <bills@netplane.com> wrote:
> > > John, see the comments below:
> > >
> > > > -----Original Message-----
> > > > From: John Sparr [mailto:johnll44@yahoo.com]
> > > > Sent: Tuesday, January 02, 2001 3:43 PM
> > > > To: mpls@UU.NET
> > > > Subject: ERO and strict/loose subobject
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > One question about the ERO object in RSVP:
> > > >
> > > > Assuming there is a sender node and it creates
> an
> > > ERO.
> > > > Should the ERO include the ip address of
> sender
> > > > itself? If yes, why?
> > >
> > > Lets say the ERO is not set with the sender node
> and
> > > is started on the next
> > > hop.  How does the LSP you want to set up know
> that
> > > there are no other hops
> > > in between the sender and next hop?  If you
> don't
> > > have the senders ip
> > > address as the first subobject, there isn't any
> way
> > > to set the properties of
> > > the link to the next hop to loose or strict.
> > >
> > > In the implementation in
> > > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you
> > > didn't have the sender address in the ERO, it
> would
> > > immediately error with
> > > "Bad EXPLICIT_ROUTE object" error.
> > >
> > > In 4.3.4.1. Selection of the Next Hop, it
> explains:
> > >
> > > 1) The node receiving the RSVP message MUST
> first
> > > evaluate the first
> > >    subobject.  If the node is not part of the
> > > abstract node described by
> > >    the first subobject, it has received the
> message
> > > in error and SHOULD
> > >    return a "Bad initial subobject" error.  If
> there
> > > is no first
> > >    subobject, the message is also in error and
> the
> > > system SHOULD return
> > >    a "Bad EXPLICIT_ROUTE object" error.
> > >
> > > >
> > > > Another question is about strict/loose object:
> > > >
> > > > The draft of RSVP-TE says "The path between a
> > > strict
> > > > node and its preceding node MUST include only
> > > network
> > > > nodes from the strict node and its preceding
> > > abstract
> > > > node."
> > > >
> > > > Does it mean if there is strict subobject in
> ERO,
> > > then
> > > > ther is no loose subobject and if there is
> loose
> > > > subobject, then there is no strict subobject?
> > >
> > > Not at all.  You can have both strict hops and
> loose
> > > hops as part of the
> > > same ERO.  On a "strict" hop link, there isn't
> any
> > > other route it can take
> > > except for the next hop in the ERO list.  On a
> > > "loose" hop link, there can
> > > be additional hops between the nodes provided
> that
> > > it ends up on the next
> > > hop.
> > >
> > > Bill
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Photos - Share your holiday photos online!
> > http://photos.yahoo.com/
>

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

-- 
Antonela Paraschiv 
Passport MPLS, Carrier Data Networks, Nortel Networks
Tel: (978)288-6136 (Esn : 248-6136)
E-mail: antonela@nortelnetworks.com
 
------_=_NextPart_001_01C07679.C59BB410-- From owner-mpls@UU.NET Thu Jan 4 14:32:11 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13878 for ; Thu, 4 Jan 2001 14:32:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwoc14346; Thu, 4 Jan 2001 19:32:10 GMT Received: by mail-control.mail.uu.net id QQjwoc25306 for mpls-outgoing; Thu, 4 Jan 2001 19:31:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwoc25280 for ; Thu, 4 Jan 2001 19:31: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 QQjwoc14315 for ; Thu, 4 Jan 2001 19:30:05 GMT Received: from tcb.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQjwoc12799 for ; Thu, 4 Jan 2001 19:30:05 GMT Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id MAA20297; Thu, 4 Jan 2001 12:28:54 -0700 Message-Id: <200101041928.MAA20297@tcb.net> To: erosen@cisco.com cc: "'mpls@UU.NET'" , "BGP exploder (E-mail)" From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: Encoding of MPLS label in MP-REACH-NLRI question Date: Thu, 04 Jan 2001 12:28:54 -0700 Sender: owner-mpls@UU.NET Precedence: bulk > Barring objection, I will change this to: > > The Label field carries one or more labels (that corresponds > to the stack of labels [MPLS-ENCAPS]). Each label is encoded > as 3 octets, where the high-order 20 bits contain the label > value, the following three bits must be zero, and the low > order bit contains "Bottom of Stack" (as defined in > [MPLS-ENCAPS]). > > and reissue the draft. Eric, I can only assume you knew this was coming, so I'll get right to the point. First, let's briefly review some recent posts: -------- Date: Mon, 18 Dec 2000 14:17:46 EST From: Eric Rosen Subject: Re: Concerns regarding the numerous layer violations... ... The goal was just to make the stuff useful, not to achieve a political goal or to maintain a level of architectural purity. ... -------- Date: Mon, 18 Dec 2000 14:47:45 EST From: Eric Rosen Subject: Re: Concerns regarding the numerous layer violations... ... No one wanted to make a career of re-editing and re-organizing the documents, and then having to obtain a new WG consensus around the new organization. ... -------- Why is it now ok to edit and reissue the draft? I won't even speculate, I believe it's clearly obvious. Though I don't have strong feelings either way about this change, I believe the inconsistency in your willingness to cooperate should be observed. -danny From owner-mpls@UU.NET Thu Jan 4 14:40:17 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14115 for ; Thu, 4 Jan 2001 14:40:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwoc26229; Thu, 4 Jan 2001 19:40:16 GMT Received: by mail-control.mail.uu.net id QQjwoc26099 for mpls-outgoing; Thu, 4 Jan 2001 19:39:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwoc26094 for ; Thu, 4 Jan 2001 19:39:45 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 QQjwoc29422 for ; Thu, 4 Jan 2001 19:38:08 GMT Received: from zcars04e.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) id QQjwoc29390 for ; Thu, 4 Jan 2001 19:38:07 GMT Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Thu, 4 Jan 2001 14:35:08 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZLK0A7LC; Thu, 4 Jan 2001 14:35:09 -0500 Received: from nortelnetworks.com (starmie.engeast.baynetworks.com [192.32.148.132]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CGS4G9LY; Thu, 4 Jan 2001 14:35:08 -0500 Message-ID: <3A54D06C.ECD02976@nortelnetworks.com> Date: Thu, 04 Jan 2001 14:35:09 -0500 From: "Antonela Paraschiv" X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Sanford, Bill" CC: "Antonela Paraschiv" , John Sparr , ewgray@mindspring.com, MPLS Mailing List Subject: Re: ERO and strict/loose subobject References: <87009604743AD411B1F600508BA0F959040D20@xover.hjinc.com> Content-Type: multipart/alternative; boundary="------------CD78E04EE0887674CE6A6D6F" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk --------------CD78E04EE0887674CE6A6D6F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks a lot Bill for taking the time to reply. I hoped you could stress the answer and not the question. I had the feeling that John needed a confirmation or maybe a clearer answer. Best regards, Antonela "Sanford, Bill" wrote: > So if we go back to John's original question,John> One question about > the ERO object in RSVP: > > John> Assuming there is a sender node and it creates an ERO.Should the > ERO include the ip address of senderitself? If yes, why? > > Doesn't the ERO list have to include the sender as the first hop so it > can evaluate the next hop it has to go to? > > -----Original Message----- > From: Antonela Paraschiv > [mailto:antonela@nortelnetworks.com] > Sent: Thursday, January 04, 2001 10:34 AM > To: John Sparr > Cc: ewgray@mindspring.com; Bill Sanford; MPLS Mailing List > Subject: Re: ERO and strict/loose subobject > Hi John, > > According to the draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, > when the path message leaves node A (in your example with A, > A1, A2, B nodes), the ERO should have > > ERO = {A1, B}. > > The following paragraphs from the spec (from 4.3.4.1. > Selection of the Next Hop) state that if a node receives a > path message in which the first ERO subobject does not > belong to it, it has to reply with Bad initial object. > > "1) The node receiving the RSVP message MUST first > evaluate the first > subobject. If the node is not part of the abstract node > described by > the first subobject, it has received the message in error > and SHOULD > return a "Bad initial subobject" error. If there is no > first > subobject, the message is also in error and the system > SHOULD return > a "Bad EXPLICIT_ROUTE object" error." > and > "6) Finally, the node replaces the first subobject with > any subobject > that denotes an abstract node containing the next hop. > This is > necessary so that when the explicit route is received by > the next > hop, it will be accepted." > > Note please that step 1) above does not mention ANYTHING > about first ERO subobject being strict or loose. > > Can any of the authors please confirm/infirm the above? > > Best regards, > Antonela > > > > > John Sparr wrote: > > > Hi Eric, > > > > You are right. I made a mistake. In the example, A is > > not the abstract node and B should set the L bit. > > > > My question is how node A handle the ERO. Does the ERO > > created by A contains only B's addr or both A's addr > > and B's addr, when A sent out path msg with ERO? > > Assuming A want to send ERO to B and regardless the > > intermediate nodes. > > > > Thanks. > > > > Regards, > > > > John > > > > --- Eric Gray wrote: > > > John, > > > > > > I believe part of the issue is your use of > > > terms. > > > In the example you give, I believe that either the > > > "address" A must be that of an abstract node that > > > includes addresses A1, A2 and A3 OR B needs > > > to have the L bit set to indicate that it does not > > > have to be the very next (adjacent) peer. I am > > > sure that A cannot forward the Path message > > > to A1, let alone to B, otherwise. > > > > > > I think if you recast your question in terms of > > > "loose hops" and "abstract nodes" and re-read > > > the applicable sections of the specification, your > > > answer will emerge. > > > > > > -- > > > Eric Gray > > > > > > John Sparr wrote: > > > > > > > Hi Bill, > > > > > > > > Thanks for the comments. > > > > > > > > I was still a little bit confused about the first > > > > subobject in the ERO. Lets say the following > > > example. > > > > > > > > A--A1--A2--A3--B--C > > > > > > > > Assuming A is the sender node and B is the > > > receiver > > > > node, A1-A3 are the intermediate nodes. A creates > > > an > > > > ERO with the first subobj A's addr (loose) and > > > second > > > > subobj B's addr. When A sends Path msg with the > > > ERO > > > > towards B, what should A do to the ERO, it should > > > > delete the first subobj (itself addr)? or send > > > both > > > > subobjs to B? I think A should delet the first > > > subobj, > > > > but if it is, it's no use to add the first subobj( > > > > itself addr) at the beginning of creating ERO. > > > > > > > > Please correct me. > > > > > > > > Thanks in advance > > > > > > > > Regards, > > > > > > > > John > > > > > > > > --- "Sanford, Bill" wrote: > > > > > John, see the comments below: > > > > > > > > > > > -----Original Message----- > > > > > > From: John Sparr [mailto:johnll44@yahoo.com] > > > > > > Sent: Tuesday, January 02, 2001 3:43 PM > > > > > > To: mpls@UU.NET > > > > > > Subject: ERO and strict/loose subobject > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > One question about the ERO object in RSVP: > > > > > > > > > > > > Assuming there is a sender node and it creates > > > an > > > > > ERO. > > > > > > Should the ERO include the ip address of > > > sender > > > > > > itself? If yes, why? > > > > > > > > > > Lets say the ERO is not set with the sender node > > > and > > > > > is started on the next > > > > > hop. How does the LSP you want to set up know > > > that > > > > > there are no other hops > > > > > in between the sender and next hop? If you > > > don't > > > > > have the senders ip > > > > > address as the first subobject, there isn't any > > > way > > > > > to set the properties of > > > > > the link to the next hop to loose or strict. > > > > > > > > > > In the implementation in > > > > > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you > > > > > didn't have the sender address in the ERO, it > > > would > > > > > immediately error with > > > > > "Bad EXPLICIT_ROUTE object" error. > > > > > > > > > > In 4.3.4.1. Selection of the Next Hop, it > > > explains: > > > > > > > > > > 1) The node receiving the RSVP message MUST > > > first > > > > > evaluate the first > > > > > subobject. If the node is not part of the > > > > > abstract node described by > > > > > the first subobject, it has received the > > > message > > > > > in error and SHOULD > > > > > return a "Bad initial subobject" error. If > > > there > > > > > is no first > > > > > subobject, the message is also in error and > > > the > > > > > system SHOULD return > > > > > a "Bad EXPLICIT_ROUTE object" error. > > > > > > > > > > > > > > > > > Another question is about strict/loose object: > > > > > > > > > > > > The draft of RSVP-TE says "The path between a > > > > > strict > > > > > > node and its preceding node MUST include only > > > > > network > > > > > > nodes from the strict node and its preceding > > > > > abstract > > > > > > node." > > > > > > > > > > > > Does it mean if there is strict subobject in > > > ERO, > > > > > then > > > > > > ther is no loose subobject and if there is > > > loose > > > > > > subobject, then there is no strict subobject? > > > > > > > > > > Not at all. You can have both strict hops and > > > loose > > > > > hops as part of the > > > > > same ERO. On a "strict" hop link, there isn't > > > any > > > > > other route it can take > > > > > except for the next hop in the ERO list. On a > > > > > "loose" hop link, there can > > > > > be additional hops between the nodes provided > > > that > > > > > it ends up on the next > > > > > hop. > > > > > > > > > > Bill > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Yahoo! Photos - Share your holiday photos online! > > > > http://photos.yahoo.com/ > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Photos - Share your holiday photos online! > > http://photos.yahoo.com/ > > -- > Antonela Paraschiv > Passport MPLS, Carrier Data Networks, Nortel Networks > Tel: (978)288-6136 (Esn : 248-6136) > E-mail: antonela@nortelnetworks.com > > > -- Antonela Paraschiv Passport MPLS, Carrier Data Networks, Nortel Networks Tel: (978)288-6136 (Esn : 248-6136) E-mail: antonela@nortelnetworks.com --------------CD78E04EE0887674CE6A6D6F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks a lot Bill for taking the time to reply.
I hoped you could stress the answer and not the question. I had the feeling that John needed a confirmation or maybe a clearer answer.

Best regards,
Antonela
 

"Sanford, Bill" wrote:

So if we go back to John's original question,John> One question about the ERO object in RSVP:

John> Assuming there is a sender node and it creates an ERO.Should the ERO include the ip address of senderitself? If yes, why?

Doesn't the ERO list have to include the sender as the first hop so it can evaluate the next hop it has to go to?

-----Original Message-----
From: Antonela Paraschiv [mailto:antonela@nortelnetworks.com]
Sent: Thursday, January 04, 2001 10:34 AM
To: John Sparr
Cc: ewgray@mindspring.com; Bill Sanford; MPLS Mailing List
Subject: Re: ERO and strict/loose subobject
Hi John,

According to the draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, when the path message leaves node A (in your example with A, A1, A2, B nodes), the ERO should have

   ERO = {A1, B}.

The following paragraphs from the spec (from 4.3.4.1. Selection of the Next Hop) state that if a node receives a path message in which the first ERO subobject does not belong to it, it has to reply with Bad initial object.

   "1) The node receiving the RSVP message MUST first evaluate the first
   subobject.  If the node is not part of the abstract node described by
   the first subobject, it has received the message in error and SHOULD
   return a "Bad initial subobject" error.  If there is no first
   subobject, the message is also in error and the system SHOULD return
    a "Bad EXPLICIT_ROUTE object" error."
and
   "6) Finally, the node replaces the first subobject with any subobject
   that denotes an abstract node containing the next hop.  This is
   necessary so that when the explicit route is received by the next
   hop, it will be accepted."

Note please that step 1) above does not mention ANYTHING about first ERO subobject being strict or loose.

Can any of the authors please confirm/infirm the above?

Best regards,
Antonela
 
 
 

John Sparr wrote:

Hi Eric,

You are right. I made a mistake. In the example, A is
not the abstract node and B should set the L bit.

My question is how node A handle the ERO. Does the ERO
created by A contains only B's addr or both A's addr
and B's addr, when A sent out path msg with ERO?
Assuming A want to send ERO to B and regardless the
intermediate nodes.

Thanks.

Regards,

John

--- Eric Gray <ewgray@mindspring.com> wrote:
> John,
>
>     I believe part of the issue is your use of
> terms.
> In the example you give, I believe that either the
> "address" A must be that of an abstract node that
> includes addresses A1, A2 and A3 OR B needs
> to have the L bit set to indicate that it does not
> have to be the very next (adjacent) peer. I am
> sure that A cannot forward the Path message
> to A1, let alone to B, otherwise.
>
>     I think if you recast your question in terms of
> "loose hops" and "abstract nodes" and re-read
> the applicable sections of the specification, your
> answer will emerge.
>
> --
> Eric Gray
>
> John Sparr wrote:
>
> > Hi Bill,
> >
> > Thanks for the comments.
> >
> > I was still a little bit confused about the first
> > subobject in the ERO. Lets say the following
> example.
> >
> >     A--A1--A2--A3--B--C
> >
> > Assuming A is the sender node and B is the
> receiver
> > node, A1-A3 are the intermediate nodes. A creates
> an
> > ERO with the first subobj A's addr (loose) and
> second
> > subobj B's addr. When A sends Path msg with the
> ERO
> > towards B, what should A do to the ERO, it should
> > delete the first subobj (itself addr)? or send
> both
> > subobjs to B? I think A should delet the first
> subobj,
> > but if it is, it's no use to add the first subobj(
> > itself addr) at the beginning of creating ERO.
> >
> > Please correct me.
> >
> > Thanks in advance
> >
> > Regards,
> >
> > John
> >
> > --- "Sanford, Bill" <bills@netplane.com> wrote:
> > > John, see the comments below:
> > >
> > > > -----Original Message-----
> > > > From: John Sparr [mailto:johnll44@yahoo.com]
> > > > Sent: Tuesday, January 02, 2001 3:43 PM
> > > > To: mpls@UU.NET
> > > > Subject: ERO and strict/loose subobject
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > One question about the ERO object in RSVP:
> > > >
> > > > Assuming there is a sender node and it creates
> an
> > > ERO.
> > > > Should the ERO include the ip address of
> sender
> > > > itself? If yes, why?
> > >
> > > Lets say the ERO is not set with the sender node
> and
> > > is started on the next
> > > hop.  How does the LSP you want to set up know
> that
> > > there are no other hops
> > > in between the sender and next hop?  If you
> don't
> > > have the senders ip
> > > address as the first subobject, there isn't any
> way
> > > to set the properties of
> > > the link to the next hop to loose or strict.
> > >
> > > In the implementation in
> > > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if you
> > > didn't have the sender address in the ERO, it
> would
> > > immediately error with
> > > "Bad EXPLICIT_ROUTE object" error.
> > >
> > > In 4.3.4.1. Selection of the Next Hop, it
> explains:
> > >
> > > 1) The node receiving the RSVP message MUST
> first
> > > evaluate the first
> > >    subobject.  If the node is not part of the
> > > abstract node described by
> > >    the first subobject, it has received the
> message
> > > in error and SHOULD
> > >    return a "Bad initial subobject" error.  If
> there
> > > is no first
> > >    subobject, the message is also in error and
> the
> > > system SHOULD return
> > >    a "Bad EXPLICIT_ROUTE object" error.
> > >
> > > >
> > > > Another question is about strict/loose object:
> > > >
> > > > The draft of RSVP-TE says "The path between a
> > > strict
> > > > node and its preceding node MUST include only
> > > network
> > > > nodes from the strict node and its preceding
> > > abstract
> > > > node."
> > > >
> > > > Does it mean if there is strict subobject in
> ERO,
> > > then
> > > > ther is no loose subobject and if there is
> loose
> > > > subobject, then there is no strict subobject?
> > >
> > > Not at all.  You can have both strict hops and
> loose
> > > hops as part of the
> > > same ERO.  On a "strict" hop link, there isn't
> any
> > > other route it can take
> > > except for the next hop in the ERO list.  On a
> > > "loose" hop link, there can
> > > be additional hops between the nodes provided
> that
> > > it ends up on the next
> > > hop.
> > >
> > > Bill
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Photos - Share your holiday photos online!
> > http://photos.yahoo.com/
>

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

-- 
Antonela Paraschiv 
Passport MPLS, Carrier Data Networks, Nortel Networks
Tel: (978)288-6136 (Esn : 248-6136)
E-mail: antonela@nortelnetworks.com
 
-- 
Antonela Paraschiv 
Passport MPLS, Carrier Data Networks, Nortel Networks
Tel: (978)288-6136 (Esn : 248-6136)
E-mail: antonela@nortelnetworks.com
  --------------CD78E04EE0887674CE6A6D6F-- From owner-mpls@UU.NET Thu Jan 4 14:44:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14222 for ; Thu, 4 Jan 2001 14:44:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwoc06305; Thu, 4 Jan 2001 19:44:02 GMT Received: by mail-control.mail.uu.net id QQjwoc26433 for mpls-outgoing; Thu, 4 Jan 2001 19:43:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwoc26411 for ; Thu, 4 Jan 2001 19:43:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjwoc09642 for ; Thu, 4 Jan 2001 19:40:36 GMT Received: from web11407.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11407.mail.yahoo.com [216.136.131.237]) id QQjwoc26726 for ; Thu, 4 Jan 2001 19:40:35 GMT Message-ID: <20010104194035.27652.qmail@web11407.mail.yahoo.com> Received: from [132.177.121.29] by web11407.mail.yahoo.com; Thu, 04 Jan 2001 11:40:35 PST Date: Thu, 4 Jan 2001 11:40:35 -0800 (PST) From: John Sparr Subject: Re: ERO and strict/loose subobject To: Antonela Paraschiv Cc: ewgray@mindspring.com, Bill Sanford , MPLS Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Antonela, I think it doesn't matter for the strict or loose attribute set for the sender's first subobject in the ERO. The sender node just use it (itself addr) as an evaluating for the first subobj and then delet it. The L bit is meaningful fot the next hop. If the L bit is set, phop can reach nhop freely, the very adjcance is not nessary. For example: A--B--C--D A is a sender and D is a receiver. For the ERO A created should be in order: A,B,C,D. When A send out path msg with ERO, the first subobj (A's addr) is deleted. When B received path msg with the ERO, it see itself addr first. Is that clear? If wrong, please correct me. Regards, John --- Antonela Paraschiv wrote: > Hi John, > > According to the > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, when the > path > message leaves node A (in your example with A, A1, > A2, B nodes), the ERO > should have > > ERO = {A1, B}. > > The following paragraphs from the spec (from > 4.3.4.1. Selection of the > Next Hop) state that if a node receives a path > message in which the > first ERO subobject does not belong to it, it has to > reply with Bad > initial object. > > "1) The node receiving the RSVP message MUST > first evaluate the first > > subobject. If the node is not part of the > abstract node described by > > the first subobject, it has received the message > in error and SHOULD > return a "Bad initial subobject" error. If there > is no first > subobject, the message is also in error and the > system SHOULD return > a "Bad EXPLICIT_ROUTE object" error." > and > "6) Finally, the node replaces the first > subobject with any subobject > > that denotes an abstract node containing the next > hop. This is > necessary so that when the explicit route is > received by the next > hop, it will be accepted." > > Note please that step 1) above does not mention > ANYTHING about first ERO > subobject being strict or loose. > > Can any of the authors please confirm/infirm the > above? > > Best regards, > Antonela > > > > > John Sparr wrote: > > > Hi Eric, > > > > You are right. I made a mistake. In the example, A > is > > not the abstract node and B should set the L bit. > > > > My question is how node A handle the ERO. Does the > ERO > > created by A contains only B's addr or both A's > addr > > and B's addr, when A sent out path msg with ERO? > > Assuming A want to send ERO to B and regardless > the > > intermediate nodes. > > > > Thanks. > > > > Regards, > > > > John > > > > --- Eric Gray wrote: > > > John, > > > > > > I believe part of the issue is your use of > > > terms. > > > In the example you give, I believe that either > the > > > "address" A must be that of an abstract node > that > > > includes addresses A1, A2 and A3 OR B needs > > > to have the L bit set to indicate that it does > not > > > have to be the very next (adjacent) peer. I am > > > sure that A cannot forward the Path message > > > to A1, let alone to B, otherwise. > > > > > > I think if you recast your question in terms > of > > > "loose hops" and "abstract nodes" and re-read > > > the applicable sections of the specification, > your > > > answer will emerge. > > > > > > -- > > > Eric Gray > > > > > > John Sparr wrote: > > > > > > > Hi Bill, > > > > > > > > Thanks for the comments. > > > > > > > > I was still a little bit confused about the > first > > > > subobject in the ERO. Lets say the following > > > example. > > > > > > > > A--A1--A2--A3--B--C > > > > > > > > Assuming A is the sender node and B is the > > > receiver > > > > node, A1-A3 are the intermediate nodes. A > creates > > > an > > > > ERO with the first subobj A's addr (loose) and > > > second > > > > subobj B's addr. When A sends Path msg with > the > > > ERO > > > > towards B, what should A do to the ERO, it > should > > > > delete the first subobj (itself addr)? or send > > > both > > > > subobjs to B? I think A should delet the first > > > subobj, > > > > but if it is, it's no use to add the first > subobj( > > > > itself addr) at the beginning of creating ERO. > > > > > > > > Please correct me. > > > > > > > > Thanks in advance > > > > > > > > Regards, > > > > > > > > John > > > > > > > > --- "Sanford, Bill" > wrote: > > > > > John, see the comments below: > > > > > > > > > > > -----Original Message----- > > > > > > From: John Sparr > [mailto:johnll44@yahoo.com] > > > > > > Sent: Tuesday, January 02, 2001 3:43 PM > > > > > > To: mpls@UU.NET > > > > > > Subject: ERO and strict/loose subobject > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > One question about the ERO object in RSVP: > > > > > > > > > > > > Assuming there is a sender node and it > creates > > > an > > > > > ERO. > > > > > > Should the ERO include the ip address of > > > sender > > > > > > itself? If yes, why? > > > > > > > > > > Lets say the ERO is not set with the sender > node > > > and > > > > > is started on the next > > > > > hop. How does the LSP you want to set up > know > > > that > > > > > there are no other hops > > > > > in between the sender and next hop? If you > > > don't > > > > > have the senders ip > > > > > address as the first subobject, there isn't > any > > > way > > > > > to set the properties of > > > > > the link to the next hop to loose or strict. > > > > > > > > > > In the implementation in > > > > > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, if > you > > > > > didn't have the sender address in the ERO, > it > > > would > > > > > immediately error with > > > > > "Bad EXPLICIT_ROUTE object" error. > > > > > > > > > > In 4.3.4.1. Selection of the Next Hop, it > > > explains: > > > > > > > > > > 1) The node receiving the RSVP message MUST > > > first > > > > > evaluate the first > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From owner-mpls@UU.NET Thu Jan 4 16:36:46 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16662 for ; Thu, 4 Jan 2001 16:36:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwok14797; Thu, 4 Jan 2001 21:36:44 GMT Received: by mail-control.mail.uu.net id QQjwok02184 for mpls-outgoing; Thu, 4 Jan 2001 21:36:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwok02154 for ; Thu, 4 Jan 2001 21: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 QQjwok15573 for ; Thu, 4 Jan 2001 21:34:58 GMT Received: from iol.unh.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mars.iol.unh.edu [132.177.121.222]) id QQjwok14824 for ; Thu, 4 Jan 2001 21:34:57 GMT Received: from localhost (mmeara@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id QAA05979; Thu, 4 Jan 2001 16:38:13 -0500 (EST) Date: Thu, 4 Jan 2001 16:38:13 -0500 From: "Michael H. O'Meara" To: Eric Gray cc: John Sparr , Bill Sanford , MPLS Mailing List Subject: Re: ERO and strict/loose subobject In-Reply-To: <3A535926.ACF908CB@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hello all, While there's a thread on the subject, I was hoping that someone might help clarify some of my confusion in regards to the processing of an ERO. In particular, I'm having some difficulty understanding the selection of a next hop for a node in the interior of an abstract node. According to draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, section 4.3.4.1: 5) Interior of the Abstract Node Case: Otherwise, the node selects a next hop within the abstract node of the first subobject (which the node belongs to) that is along the path to the abstract node of the second subobject (which is the next abstract node). ... 6) Finally, the node replaces the first subobject with any subobject that denotes an abstract node containing the next hop. This is necessary so that when the explicit route is received by the next hop, it will be accepted. What, exactly, is meant by "any subobject that denotes an abstract node containing the next hop?" For example, given the following topology: A--B1--B2--B3--C Say that A sends an ERO={B,C}, where B describes an abstract node that contains B1, B2, and B3, and B and C are strict hops. According to the steps for making the selection of a next hop, B1 could send an ERO={B2,C} to B2. Since C is listed as a strict hop, B2 would return a "Bad strict node error." I may be missing something, but it would seem that nothing in the steps for the selection of a next hop, nor in section 4.3.4.2 on the addition of subobjects to the ERO, would preclude this from happening. I would certainly appreciate any help in clarifying this matter. Thanks in advance, Mike *************************** Michael O'Meara Technician MPLS Consortium InterOperability Lab University of New Hampshire *************************** From owner-mpls@UU.NET Thu Jan 4 17:04:05 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17249 for ; Thu, 4 Jan 2001 17:04:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwom12295; Thu, 4 Jan 2001 22:04:05 GMT Received: by mail-control.mail.uu.net id QQjwom11245 for mpls-outgoing; Thu, 4 Jan 2001 22:03:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwom11218 for ; Thu, 4 Jan 2001 22:03:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjwom07007 for ; Thu, 4 Jan 2001 22:02:29 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 QQjwom08844 for ; Thu, 4 Jan 2001 22:02:28 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 RAA02707 for ; Thu, 4 Jan 2001 17:02:25 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA10378 for ; Thu, 4 Jan 2001 17:02:28 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Jan 2001 17:02:21 -0500 Message-ID: <39469E08BD83D411A3D900204840EC5520DDA2@vie-msgusr-01.dc.fore.com> From: "Brennen, Jack" To: MPLS Mailing List Subject: RE: ERO and strict/loose subobject Date: Thu, 4 Jan 2001 17:02:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Your reading of the draft appears to be correct -- the draft seems to allow that although it is not really a useful behavior. It seems that any of the following EROs could be sent from B1 to B2 and still maintain correct end-to-end operation: A--B1--B2--B3--C {B,C} {B2,B,C} {B2,B3,B,C} {B2,B3,C} {Bx,C} -- where Bx is any subset of node B containing both B2 and B3. This is not a complete list -- the draft leaves a great deal of room for variations on these themes. All of these EROs seem to be permitted by the draft, primarily by the third paragraph of 4.3.4.2: Otherwise, if the node is a member of the abstract node for the first subobject, a series of subobjects MAY be inserted before the first subobject or MAY replace the first subobject. Each subobject in this series MUST denote an abstract node that is a subset of the current abstract node. My personal preference as an implementor would be to forward the incoming ERO unmodified -- send the ERO {B,C} to node B2. But certainly nothing useful can come from sending the ERO {B2,C} to node B2. > -----Original Message----- > From: Michael H. O'Meara [mailto:mmeara@mars.iol.unh.edu] > Sent: Thursday, January 04, 2001 4:38 PM > To: Eric Gray > Cc: John Sparr; Bill Sanford; MPLS Mailing List > Subject: Re: ERO and strict/loose subobject > > > Hello all, > While there's a thread on the subject, I was hoping that someone > might help clarify some of my confusion in regards to the > processing of an > ERO. In particular, I'm having some difficulty understanding > the selection > of a next hop for a node in the interior of an abstract node. > According to > draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, section 4.3.4.1: > > 5) Interior of the Abstract Node Case: Otherwise, the node selects a > next hop within the abstract node of the first subobject (which the > node belongs to) that is along the path to the abstract node of the > second subobject (which is the next abstract node). > ... > 6) Finally, the node replaces the first subobject with any subobject > that denotes an abstract node containing the next hop. This is > necessary so that when the explicit route is received by the next > hop, it will be accepted. > > What, exactly, is meant by "any subobject that denotes an abstract > node containing the next hop?" For example, given the > following topology: > > A--B1--B2--B3--C > > Say that A sends an ERO={B,C}, where B describes an > abstract node that > contains B1, B2, and B3, and B and C are strict hops. According to the > steps for making the selection of a next hop, B1 could send > an ERO={B2,C} > to B2. > Since C is listed as a strict hop, B2 would return a > "Bad strict > node error." I may be missing something, but it would seem > that nothing in > the steps for the selection of a next hop, nor in section > 4.3.4.2 on the > addition of subobjects to the ERO, would preclude this from > happening. I > would certainly appreciate any help in clarifying this matter. > Thanks in advance, > Mike > > *************************** > Michael O'Meara > Technician > MPLS Consortium > InterOperability Lab > University of New Hampshire > *************************** > > > From owner-mpls@UU.NET Thu Jan 4 18:33:55 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18261 for ; Thu, 4 Jan 2001 18:33:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwoj26331; Thu, 4 Jan 2001 21:26:04 GMT Received: by mail-control.mail.uu.net id QQjwoj00850 for mpls-outgoing; Thu, 4 Jan 2001 21:25:39 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwoj00842 for ; Thu, 4 Jan 2001 21:25:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjwoj09109 for ; Thu, 4 Jan 2001 21:22:15 GMT Received: from zcars04f.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQjwoj22530 for ; Thu, 4 Jan 2001 21:22:15 GMT Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 4 Jan 2001 16:21:54 -0500 Received: from zcard00p.ca.nortel.com ([47.129.25.61]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CJNWTS48; Thu, 4 Jan 2001 16:21:55 -0500 Received: from nortelnetworks.com (zcars02x.ca.nortel.com [47.23.81.10]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y9V14AW8; Thu, 4 Jan 2001 16:21:55 -0500 Message-ID: <3A54E972.9C7746D6@nortelnetworks.com> Date: Thu, 04 Jan 2001 16:21:54 -0500 From: "Cheng-Yin Lee" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: "Faisal S. Naik" , mpls uunet , zaziz@cisco.com, prasanna@csa.iisc.ernet.in Subject: Re: Some queries References: <200101041808.NAA11623@workhorse.fictitious.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, Curtis Villamizar wrote: > There were a number of motivations for getting rid of ATM in IP > networks. One was the cell tax which at a typical 20% would not alone > kill ATM. Another was SAR. You can't get fast ATM router interfaces > because SAR speed and SAR buffering becomes a problem. This alone was > enough to kill ATM. > > Perhaps even larger was the problems of independent control planes and > the effect on IGP scaling. Flooding is needed for reliability in the > IGP and flooding in a full mesh of N routers has some N^3 properties > with regard to messages sent when a router in the mesh fails and N^2 > when a VC fails. Attempts to constrain the flooding tended to slow > convergence and sometimes cause long lived IGP inconsistency when > change occurred. This is not a problem is the flooding follows the > physical interconnections as it does with MPLS since the number of > adjacencies per node drops dramatically. Over time , would there be any inclinations to add direct connectivity between B and H, and then over F and D, and so on, leading to perhaps densely meshed networks in the long run ? What is your opinion on this? B-------C-------D / \ / \ A E \ / \ / F--------G--------H One could use a common control plane and may still run into IGP scaling issues because the network is densely meshed, right? > The IGP scaling problem was address by ISPs by partitioning their > network into core and regions but this reduced the effectivenes of TE. Could you kindly elaborate your thoughts on this? thanks, cyl From owner-mpls@UU.NET Thu Jan 4 19:48:11 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18921 for ; Thu, 4 Jan 2001 19:48:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwox15443; Fri, 5 Jan 2001 00:48:07 GMT Received: by mail-control.mail.uu.net id QQjwox21101 for mpls-outgoing; Fri, 5 Jan 2001 00:47:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwox21096 for ; Fri, 5 Jan 2001 00:47:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjwox19039 for ; Fri, 5 Jan 2001 00:47:07 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwox25939 for ; Fri, 5 Jan 2001 00:47:06 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA08770 for mpls@uu.net; Thu, 4 Jan 2001 19:47:06 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwox21029 for ; Fri, 5 Jan 2001 00:46: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 QQjwow11761 for ; Fri, 5 Jan 2001 00:44:41 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjwow07712 for ; Fri, 5 Jan 2001 00:44:41 GMT Received: from cisco.com (war-jer-dhcp84.cisco.com [144.254.89.254]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA01208; Thu, 4 Jan 2001 16:44:35 -0800 (PST) Message-ID: <3A551A9A.4345905D@cisco.com> Date: Thu, 04 Jan 2001 16:51:38 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: danny@ambernetworks.com CC: erosen@cisco.com, "'mpls@UU.NET'" , "BGP exploder (E-mail)" Subject: Re: Encoding of MPLS label in MP-REACH-NLRI question References: <200101041928.MAA20297@tcb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Danny, First I think the little change below can not be compared to the serious of proposals made in the "... numerous layer violations... " thread a while back. You are just not comparing the same orders of magnitudes here at all. Second I always thought that the nature of a draft is to be able to adjust it to fit it to the most of the operational community or proven solutions. That is not to say that the nature of the draft allows to turn it upside down while it is in the rfc editor queue and deployed widely :). R. > Danny McPherson wrote: > > > Barring objection, I will change this to: > > > > The Label field carries one or more labels (that corresponds > > to the stack of labels [MPLS-ENCAPS]). Each label is encoded > > as 3 octets, where the high-order 20 bits contain the label > > value, the following three bits must be zero, and the low > > order bit contains "Bottom of Stack" (as defined in > > [MPLS-ENCAPS]). > > > > and reissue the draft. > > Eric, > I can only assume you knew this was coming, so I'll get > right to the point. First, let's briefly review some > recent posts: > > -------- > Date: Mon, 18 Dec 2000 14:17:46 EST > From: Eric Rosen > Subject: Re: Concerns regarding the numerous layer violations... > > ... > > The goal was just to make the stuff useful, not to achieve a political goal > or to maintain a level of architectural purity. > ... > > -------- > Date: Mon, 18 Dec 2000 14:47:45 EST > From: Eric Rosen > Subject: Re: Concerns regarding the numerous layer violations... > > ... > No one wanted to make a career of re-editing and re-organizing the documents, > and then having to obtain a new WG consensus around the new organization. > ... > > -------- > > Why is it now ok to edit and reissue the draft? I won't > even speculate, I believe it's clearly obvious. Though I > don't have strong feelings either way about this change, > I believe the inconsistency in your willingness to > cooperate should be observed. > > -danny From owner-mpls@UU.NET Thu Jan 4 20:42:51 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19371 for ; Thu, 4 Jan 2001 20:42:51 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwpa18821; Fri, 5 Jan 2001 01:42:50 GMT Received: by mail-control.mail.uu.net id QQjwpa05734 for mpls-outgoing; Fri, 5 Jan 2001 01:42:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwpa05725 for ; Fri, 5 Jan 2001 01:41:59 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 QQjwpa16366 for ; Fri, 5 Jan 2001 01:41:16 GMT Received: from bgslc02.TBG.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQjwpa15580 for ; Fri, 5 Jan 2001 01:41:16 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Jan 2001 18:36:16 -0700 Message-ID: <0C875DC28791D21192CD00104B95BFE70146D1C2@BGSLC02> From: Irwin Lazar To: "'mpls@uu.net'" Subject: MPLScon 2001 Date: Thu, 4 Jan 2001 18:36:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C076B7.E4D8B8F8" 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_01C076B7.E4D8B8F8 Content-Type: text/plain; charset="iso-8859-1" I'm happy to announce that the web site for MPLScon 2001 is now available at www.mplscon.com . The event is going to be held on March 26-29 at the Wyndham Hotel in San Jose, California. Our complete conference agenda will be available sometime next week. Registration to attend the event is now open. I hope to see many of you there! Irwin -------------- Irwin Lazar Conference Director, MPLScon 2001 March 26-29, San Jose, CA e-mail: ilazar@tbg.com phone: 703-742-9659 cell: 703-402-4119 http://www.mplscon.com ------_=_NextPart_001_01C076B7.E4D8B8F8 Content-Type: text/html; charset="iso-8859-1"
I'm happy to announce that the web site for MPLScon 2001 is now available at www.mplscon.com.
 
The event is going to be held on March 26-29 at the Wyndham Hotel in San Jose, California.  Our complete conference agenda will be available sometime next week.
 
Registration to attend the event is now open.  I hope to see many of you there!
 
Irwin
 
--------------
Irwin Lazar
Conference Director, MPLScon 2001
March 26-29, San Jose, CA
phone: 703-742-9659
cell: 703-402-4119
 
 
------_=_NextPart_001_01C076B7.E4D8B8F8-- From owner-mpls@UU.NET Thu Jan 4 22:29:10 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21016 for ; Thu, 4 Jan 2001 22:29:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwph05491; Fri, 5 Jan 2001 03:29:09 GMT Received: by mail-control.mail.uu.net id QQjwph05468 for mpls-outgoing; Fri, 5 Jan 2001 03:28:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwph05463 for ; Fri, 5 Jan 2001 03:28: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 QQjwph03430 for ; Fri, 5 Jan 2001 03:27:01 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjwph09765 for ; Fri, 5 Jan 2001 03:26:59 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 WAA14553; Thu, 4 Jan 2001 22:26:39 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200101050326.WAA14553@workhorse.fictitious.org> To: "Cheng-Yin Lee" cc: curtis@avici.com, "Faisal S. Naik" , mpls uunet , zaziz@cisco.com, prasanna@csa.iisc.ernet.in Reply-To: curtis@avici.com Subject: Re: Some queries In-reply-to: Your message of "Thu, 04 Jan 2001 16:21:54 EST." <3A54E972.9C7746D6@nortelnetworks.com> Date: Thu, 04 Jan 2001 22:26:39 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3A54E972.9C7746D6@nortelnetworks.com>, "Cheng-Yin Lee" writes: > Curtis, > > Curtis Villamizar wrote: > > > There were a number of motivations for getting rid of ATM in IP > > networks. One was the cell tax which at a typical 20% would not alone > > kill ATM. Another was SAR. You can't get fast ATM router interfaces > > because SAR speed and SAR buffering becomes a problem. This alone was > > enough to kill ATM. > > > > Perhaps even larger was the problems of independent control planes and > > the effect on IGP scaling. Flooding is needed for reliability in the > > IGP and flooding in a full mesh of N routers has some N^3 properties > > with regard to messages sent when a router in the mesh fails and N^2 > > when a VC fails. Attempts to constrain the flooding tended to slow > > convergence and sometimes cause long lived IGP inconsistency when > > change occurred. This is not a problem is the flooding follows the > > physical interconnections as it does with MPLS since the number of > > adjacencies per node drops dramatically. > > Over time , would there be any inclinations to add direct connectivity betwee > n B > and H, and then over F and D, and so on, leading to perhaps densely meshed > networks in the long run ? What is your opinion on this? > > B-------C-------D > / \ > / \ > A E > \ / > \ / > F--------G--------H > > One could use a common control plane and may still run into IGP scaling issue > s > because the network is densely meshed, right? Densely meshed in a 1,000 node network might mean 10-15 adjacencies per node. That is still a lot less than full mesh of 999 adjacencies per node if IP over ATM were used. > > The IGP scaling problem was address by ISPs by partitioning their > > network into core and regions but this reduced the effectivenes of TE. > > Could you kindly elaborate your thoughts on this? Typically a provider would partition the topology into N regions where N is 10s, then run VCs within an ATM core that interconnected the regions and VCs within each region. The routers had no visibility into TE state so if there was mutliple routers bordering the core and a given region and one of those core routers had a much less congested path to a destination (recognizing that congestion was more likely within specific regions than with the core) then the core routers had no good way to pick the right edge router and get on the VC with a cleaner shot at the destination. [Its late. I hope this is clear.] > thanks, > cyl Curtis From owner-mpls@UU.NET Fri Jan 5 01:14:14 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24579 for ; Fri, 5 Jan 2001 01:14:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwps29228; Fri, 5 Jan 2001 06:14:12 GMT Received: by mail-control.mail.uu.net id QQjwps19910 for mpls-outgoing; Fri, 5 Jan 2001 06:13:42 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwps19903 for ; Fri, 5 Jan 2001 06:13: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 QQjwps23723 for ; Fri, 5 Jan 2001 06:13:08 GMT Received: from web1101.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web1101.mail.yahoo.com [128.11.23.121]) id QQjwps13984 for ; Fri, 5 Jan 2001 06:13:07 GMT Received: (qmail 11026 invoked by uid 60001); 5 Jan 2001 06:13:07 -0000 Message-ID: <20010105061307.11025.qmail@web1101.mail.yahoo.com> Received: from [198.11.21.27] by web1101.mail.yahoo.com; Thu, 04 Jan 2001 22:13:07 PST Date: Thu, 4 Jan 2001 22:13:07 -0800 (PST) From: Shahid Muhammad Shafi Subject: Kindly Help!!! To: cisco@groupstudy.com Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Dear all members Which IOS versioin supports MPLS? Does 11.2 supports MPLS or it has to be upgraded?? Secondly which cisco platforms can act as LSR and Edge LSR. Will 3640 and LS 1010 will be enough??? Also what routers from Juniper can rpovide the same functionality. I want to develop a prototype for VPN over MPLS. Any input will be appreciated. Regards Shahid ===== Shahid Muhammad Shafi MSc Telecommunications Candidate University of Colorado Boulder BSEE(GIKI),MCSE+I,CNA,CCNA,CCNP Please help feed hungry people worldwide http://www.hungersite.com/ A small thing each of us can do to help others less fortunate than ourselves __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From owner-mpls@UU.NET Fri Jan 5 02:55:39 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07356 for ; Fri, 5 Jan 2001 02:55:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwpz05343; Fri, 5 Jan 2001 07:55:33 GMT Received: by mail-control.mail.uu.net id QQjwpz07507 for mpls-outgoing; Fri, 5 Jan 2001 07:55:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwpz07498 for ; Fri, 5 Jan 2001 07:54:58 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjwpz07516 for ; Fri, 5 Jan 2001 07:54:47 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwpz04337 for ; Fri, 5 Jan 2001 07:54:46 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id CAA26726 for mpls@uu.net; Fri, 5 Jan 2001 02:54:46 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwpz07483 for ; Fri, 5 Jan 2001 07:54:05 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 QQjwpz15451 for ; Fri, 5 Jan 2001 07:54:02 GMT Received: from cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjwpz03459 for ; Fri, 5 Jan 2001 07:54:02 GMT Received: from cisco.com (war-jer-dhcp84.cisco.com [144.254.89.254]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA24963; Thu, 4 Jan 2001 23:53:28 -0800 (PST) Message-ID: <3A557F20.759B8CA1@cisco.com> Date: Fri, 05 Jan 2001 00:00:32 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Shahid Muhammad Shafi CC: cisco@groupstudy.com, mpls@UU.NET Subject: Re: Kindly Help!!! References: <20010105061307.11025.qmail@web1101.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 I will reply to you offline reg vendor specific questions. R. > Shahid Muhammad Shafi wrote: > > Dear all members > > Which IOS versioin supports MPLS? Does 11.2 supports > MPLS or it has to be upgraded?? > > Secondly which cisco platforms can act as LSR and Edge > LSR. Will 3640 and LS 1010 will be enough??? > > Also what routers from Juniper can rpovide the same > functionality. I want to develop a prototype for VPN > over MPLS. Any input will be appreciated. > > Regards > Shahid > > ===== > Shahid Muhammad Shafi > MSc Telecommunications Candidate > University of Colorado Boulder > BSEE(GIKI),MCSE+I,CNA,CCNA,CCNP > > Please help feed hungry people worldwide http://www.hungersite.com/ > A small thing each of us can do to help others less fortunate than ourselves > > __________________________________________________ > Do You Yahoo!? > Yahoo! Photos - Share your holiday photos online! > http://photos.yahoo.com/ From owner-mpls@UU.NET Fri Jan 5 03:58:15 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07767 for ; Fri, 5 Jan 2001 03:58:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwqd14295; Fri, 5 Jan 2001 08:58:11 GMT Received: by mail-control.mail.uu.net id QQjwqd22590 for mpls-outgoing; Fri, 5 Jan 2001 08:57:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwqd22585 for ; Fri, 5 Jan 2001 08:57: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 QQjwqd22484 for ; Fri, 5 Jan 2001 08:57:37 GMT Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQjwqd24011 for ; Fri, 5 Jan 2001 08:57:37 GMT Received: from bemail01.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f058vXn24995; Fri, 5 Jan 2001 09:57:34 +0100 (MET) Received: from alcatel.be ([138.203.171.174]) by bemail01.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569CB.0031329A; Fri, 5 Jan 2001 09:57:22 +0100 Message-ID: <3A5598F0.AFFDDD69@alcatel.be> Date: Fri, 05 Jan 2001 10:50:40 +0100 From: Tony VAN KERCKHOVE Organization: Alcatel X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14-15mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Shahid Muhammad Shafi CC: mpls@UU.NET Subject: Re: Kindly Help!!! References: <20010105061307.11025.qmail@web1101.mail.yahoo.com> Content-Type: multipart/mixed; boundary="------------277394D12B19B282C8C53896" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------277394D12B19B282C8C53896 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Shahid, You didn't specify what label distribution protocol you would like to use: RSVP or LDP. Since you are developing a VPN prototype, I assume that you need LDP (according to RFC2547). I am doing exactly the same and I couldn't get my hands on any *properly working* LDP implementation from either Cisco or Juniper. Juniper claims to have LDP in their Junos 4.2R1.3, but that implementation is not yet conforming to the LDP specifications (e.g. it sends malformed Status TLV). Maybe you can use Cisco Tag Switching or Juniper's LDP variant for the sake of your prototype, but you won't get an interoperable solution. If you do find what you're looking for, please let me know. I'll do the same. Kind Regards, Tony Shahid Muhammad Shafi wrote: > > Dear all members > > Which IOS versioin supports MPLS? Does 11.2 supports > MPLS or it has to be upgraded?? > > Secondly which cisco platforms can act as LSR and Edge > LSR. Will 3640 and LS 1010 will be enough??? > > Also what routers from Juniper can rpovide the same > functionality. I want to develop a prototype for VPN > over MPLS. Any input will be appreciated. > > Regards > Shahid > > ===== > Shahid Muhammad Shafi > MSc Telecommunications Candidate > University of Colorado Boulder > BSEE(GIKI),MCSE+I,CNA,CCNA,CCNP > > Please help feed hungry people worldwide http://www.hungersite.com/ > A small thing each of us can do to help others less fortunate than ourselves > > __________________________________________________ > Do You Yahoo!? > Yahoo! Photos - Share your holiday photos online! > http://photos.yahoo.com/ --------------277394D12B19B282C8C53896 Content-Type: text/x-vcard; charset=us-ascii; name="Tony.Van_Kerckhove.vcf" Content-Description: Card for Tony VAN KERCKHOVE Content-Disposition: attachment; filename="Tony.Van_Kerckhove.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Van Kerckhove;Tony tel;work:32-3-450.32.22 x-mozilla-html:FALSE org:Alcatel;Carrier Internetworking Division - Managed IP Solutions - Universal IP Gateway Business Group version:2.1 email;internet:tony.van_kerckhove@alcatel.be title:Software Development Engineer adr;quoted-printable:;;Alcatel=0D=0ADe Villermontstraat 38=0D=0AB-2550 Kontich=0D=0ABelgium;;;; x-mozilla-cpt:;25632 fn:Tony Van Kerckhove end:vcard --------------277394D12B19B282C8C53896-- From owner-mpls@UU.NET Fri Jan 5 09:28:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13418 for ; Fri, 5 Jan 2001 09:28:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwqz15944; Fri, 5 Jan 2001 14:27:59 GMT Received: by mail-control.mail.uu.net id QQjwqz23526 for mpls-outgoing; Fri, 5 Jan 2001 14:27:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwqz23512 for ; Fri, 5 Jan 2001 14:27:12 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 QQjwqz15220 for ; Fri, 5 Jan 2001 14:26:42 GMT Received: from winstar.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fw-1.winstar.com [207.86.108.130]) id QQjwqz01464 for ; Fri, 5 Jan 2001 14:26:41 GMT Received: from vaawsh032382 (dhcp-vaa-1-183-160.winstar.com [10.1.183.160]) by winstar.com (8.9.3/8.9.1) with SMTP id JAA22899; Fri, 5 Jan 2001 09:25:30 -0500 (EST) From: "Yi Chu" To: , "Cheng-Yin Lee" Cc: "Faisal S. Naik" , "mpls uunet" , , Subject: RE: Some queries Date: Fri, 5 Jan 2001 09:22:29 -0500 Message-ID: <000501c07722$ef469e70$a0b7010a@winstar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <200101050326.WAA14553@workhorse.fictitious.org> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Please forgive me if my question is so obvious and maybe stupid, since I am new to this discussion. Why 1000 nodes can have 10-15 adjacencies while IP over ATM needs 999 adjacencies per node? I think IP over ATM uses ATM VC just as a physical link, so there is no difference in adjacencies per node whether the routers are connected through Sonet links or ATM VCs. So what is the reason that IP over ATM requires full VC mesh of all nodes? Yi Chu -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Curtis Villamizar Sent: Thursday, January 04, 2001 10:27 PM To: Cheng-Yin Lee Cc: curtis@avici.com; Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: Re: Some queries In message <3A54E972.9C7746D6@nortelnetworks.com>, "Cheng-Yin Lee" writes: > Curtis, > > Curtis Villamizar wrote: > > > There were a number of motivations for getting rid of ATM in IP > > networks. One was the cell tax which at a typical 20% would not alone > > kill ATM. Another was SAR. You can't get fast ATM router interfaces > > because SAR speed and SAR buffering becomes a problem. This alone was > > enough to kill ATM. > > > > Perhaps even larger was the problems of independent control planes and > > the effect on IGP scaling. Flooding is needed for reliability in the > > IGP and flooding in a full mesh of N routers has some N^3 properties > > with regard to messages sent when a router in the mesh fails and N^2 > > when a VC fails. Attempts to constrain the flooding tended to slow > > convergence and sometimes cause long lived IGP inconsistency when > > change occurred. This is not a problem is the flooding follows the > > physical interconnections as it does with MPLS since the number of > > adjacencies per node drops dramatically. > > Over time , would there be any inclinations to add direct connectivity betwee > n B > and H, and then over F and D, and so on, leading to perhaps densely meshed > networks in the long run ? What is your opinion on this? > > B-------C-------D > / \ > / \ > A E > \ / > \ / > F--------G--------H > > One could use a common control plane and may still run into IGP scaling issue > s > because the network is densely meshed, right? Densely meshed in a 1,000 node network might mean 10-15 adjacencies per node. That is still a lot less than full mesh of 999 adjacencies per node if IP over ATM were used. > > The IGP scaling problem was address by ISPs by partitioning their > > network into core and regions but this reduced the effectivenes of TE. > > Could you kindly elaborate your thoughts on this? Typically a provider would partition the topology into N regions where N is 10s, then run VCs within an ATM core that interconnected the regions and VCs within each region. The routers had no visibility into TE state so if there was mutliple routers bordering the core and a given region and one of those core routers had a much less congested path to a destination (recognizing that congestion was more likely within specific regions than with the core) then the core routers had no good way to pick the right edge router and get on the VC with a cleaner shot at the destination. [Its late. I hope this is clear.] > thanks, > cyl Curtis From owner-mpls@UU.NET Fri Jan 5 09:38:18 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13692 for ; Fri, 5 Jan 2001 09:38:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwra04216; Fri, 5 Jan 2001 14:38:17 GMT Received: by mail-control.mail.uu.net id QQjwra24319 for mpls-outgoing; Fri, 5 Jan 2001 14:37:47 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwra24263 for ; Fri, 5 Jan 2001 14:37: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 QQjwra17499 for ; Fri, 5 Jan 2001 14:36:54 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjwra02251 for ; Fri, 5 Jan 2001 14:36:54 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA17237 for ; Fri, 5 Jan 2001 06:36:59 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA12651 for mpls@uu.net; Fri, 5 Jan 2001 09:36:52 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwqe04786 for ; Fri, 5 Jan 2001 09:11:02 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 QQjwqe02681 for ; Fri, 5 Jan 2001 09:10:31 GMT Received: from prithvi.siliconsystems.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.85.131]) id QQjwqe10606 for ; Fri, 5 Jan 2001 09:10:28 GMT Received: from mail.siliconsystems.co.in (mail.siliconsystems.co.in [172.19.32.5]) by prithvi.siliconsystems.co.in (8.9.1a+p1/8.9.1/d: thinkit.m4,v 1.5 2000/06/09 23:40:41 dmccart Exp $) with ESMTP id JAA14993 for ; Fri, 5 Jan 2001 09:10:07 GMT Received: from siliconsystems.co.in (opal.siliconsystems.co.in [172.19.32.37]) by mail.siliconsystems.co.in (8.9.3/8.9.3) with ESMTP id OAA16888 for ; Fri, 5 Jan 2001 14:53:54 +0530 (IST) Message-ID: <3A5591B4.5F86EDDC@siliconsystems.co.in> Date: Fri, 05 Jan 2001 14:49:48 +0530 From: Sachin Doshi X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Query Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Could anyone clarify me on these 1. When is MPLS label of 0 (implicit IP is used)? 2. How is the TTL field update in MPLS packets. Suppose there is a egress router which can pop the MPLS label and then can switch/route the packet on IP address. By how much should it decrement the TTL (1 or 2). regards, sachin doshi From owner-mpls@UU.NET Fri Jan 5 09:45:08 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14082 for ; Fri, 5 Jan 2001 09:45:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwrb26681; Fri, 5 Jan 2001 14:45:02 GMT Received: by mail-control.mail.uu.net id QQjwra24735 for mpls-outgoing; Fri, 5 Jan 2001 14:44:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwra24725 for ; Fri, 5 Jan 2001 14:44:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjwra08287 for ; Fri, 5 Jan 2001 14:43:49 GMT Received: from stn.springtidenet.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: stn.springtidenet.com [63.88.111.246]) id QQjwra11948 for ; Fri, 5 Jan 2001 14:43:49 GMT Received: from stn15.springtidenet.com by stn.springtidenet.com via smtpd (for cmr0.ash.ops.us.uu.net [198.5.241.38]) with SMTP; 5 Jan 2001 14:43:49 UT Received: from 172.16.6.11 by stn15.springtidenet.com (InterScan E-Mail VirusWall NT); Fri, 05 Jan 2001 09:36:38 -0500 (Eastern Standard Time) Received: from sol.springtidenet.com (sol.springtidenet.com [172.20.20.4]) by stn11.springtidenet.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id JAA05023; Fri, 05 Jan 2001 09:36:45 -0500 Received: by h135-119-200-11.outland.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 09:36:38 -0500 Message-ID: From: "Bagasrawala, Abbas" To: "'Yi Chu'" , curtis@avici.com, Cheng-Yin Lee Cc: "Faisal S. Naik" , mpls uunet , zaziz@cisco.com, prasanna@csa.iisc.ernet.in Subject: RE: Some queries Date: Fri, 5 Jan 2001 09:36:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Yi, I will attempt to answer this question and the experts can correct me if I am wrong. For IP over ATM (overlay networks) the ATM VC's are just a physical link (as you noted) and thus each router at the end of the VC's need to be aware of the adjacent router. In effect the ATM core is transparent and thus you have 1000 routers connected to each other. This requires that adjacencies at each node is 999 (N-1). With densely meshed networks the number of adjacencies are less than of fully meshed network. Abbas Bagasra -----Original Message----- From: Yi Chu [mailto:ychu@winstar.com] Sent: Friday, January 05, 2001 9:22 AM To: curtis@avici.com; Cheng-Yin Lee Cc: Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: RE: Some queries Please forgive me if my question is so obvious and maybe stupid, since I am new to this discussion. Why 1000 nodes can have 10-15 adjacencies while IP over ATM needs 999 adjacencies per node? I think IP over ATM uses ATM VC just as a physical link, so there is no difference in adjacencies per node whether the routers are connected through Sonet links or ATM VCs. So what is the reason that IP over ATM requires full VC mesh of all nodes? Yi Chu -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Curtis Villamizar Sent: Thursday, January 04, 2001 10:27 PM To: Cheng-Yin Lee Cc: curtis@avici.com; Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: Re: Some queries In message <3A54E972.9C7746D6@nortelnetworks.com>, "Cheng-Yin Lee" writes: > Curtis, > > Curtis Villamizar wrote: > > > There were a number of motivations for getting rid of ATM in IP > > networks. One was the cell tax which at a typical 20% would not alone > > kill ATM. Another was SAR. You can't get fast ATM router interfaces > > because SAR speed and SAR buffering becomes a problem. This alone was > > enough to kill ATM. > > > > Perhaps even larger was the problems of independent control planes and > > the effect on IGP scaling. Flooding is needed for reliability in the > > IGP and flooding in a full mesh of N routers has some N^3 properties > > with regard to messages sent when a router in the mesh fails and N^2 > > when a VC fails. Attempts to constrain the flooding tended to slow > > convergence and sometimes cause long lived IGP inconsistency when > > change occurred. This is not a problem is the flooding follows the > > physical interconnections as it does with MPLS since the number of > > adjacencies per node drops dramatically. > > Over time , would there be any inclinations to add direct connectivity betwee > n B > and H, and then over F and D, and so on, leading to perhaps densely meshed > networks in the long run ? What is your opinion on this? > > B-------C-------D > / \ > / \ > A E > \ / > \ / > F--------G--------H > > One could use a common control plane and may still run into IGP scaling issue > s > because the network is densely meshed, right? Densely meshed in a 1,000 node network might mean 10-15 adjacencies per node. That is still a lot less than full mesh of 999 adjacencies per node if IP over ATM were used. > > The IGP scaling problem was address by ISPs by partitioning their > > network into core and regions but this reduced the effectivenes of TE. > > Could you kindly elaborate your thoughts on this? Typically a provider would partition the topology into N regions where N is 10s, then run VCs within an ATM core that interconnected the regions and VCs within each region. The routers had no visibility into TE state so if there was mutliple routers bordering the core and a given region and one of those core routers had a much less congested path to a destination (recognizing that congestion was more likely within specific regions than with the core) then the core routers had no good way to pick the right edge router and get on the VC with a cleaner shot at the destination. [Its late. I hope this is clear.] > thanks, > cyl Curtis From owner-mpls@UU.NET Fri Jan 5 09:59:47 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14289 for ; Fri, 5 Jan 2001 09:59:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwrb05877; Fri, 5 Jan 2001 14:59:46 GMT Received: by mail-control.mail.uu.net id QQjwrb26400 for mpls-outgoing; Fri, 5 Jan 2001 14:59:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwrb26392 for ; Fri, 5 Jan 2001 14:59:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjwrb22096 for ; Fri, 5 Jan 2001 14:58:23 GMT Received: from winstar.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fw-1.winstar.com [207.86.108.130]) id QQjwrb01382 for ; Fri, 5 Jan 2001 14:58:22 GMT Received: from vaawsh032382 (dhcp-vaa-1-183-160.winstar.com [10.1.183.160]) by winstar.com (8.9.3/8.9.1) with SMTP id JAA00224; Fri, 5 Jan 2001 09:57:18 -0500 (EST) From: "Yi Chu" To: "Bagasrawala, Abbas" , , "Cheng-Yin Lee" Cc: "Faisal S. Naik" , "mpls uunet" , , Subject: RE: Some queries Date: Fri, 5 Jan 2001 09:54:16 -0500 Message-ID: <000c01c07727$601ac190$a0b7010a@winstar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Abbas Bagasra: Thanks for explaining. But sorry I still do not get the point. If I have routers A,B and C, connected through an ATM core. If I set up VCs to connect A and B, B and C only. Is it a legitimate configuration? I mean it is not necessary to have A adjacent to C. Packet from A to C can still be routed through B. Admitted that those packets would traverse in and out the ATM interface on B. But is there any architectural reason why the above configuration is prohibited? yi -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Bagasrawala, Abbas Sent: Friday, January 05, 2001 9:36 AM To: 'Yi Chu'; curtis@avici.com; Cheng-Yin Lee Cc: Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: RE: Some queries Yi, I will attempt to answer this question and the experts can correct me if I am wrong. For IP over ATM (overlay networks) the ATM VC's are just a physical link (as you noted) and thus each router at the end of the VC's need to be aware of the adjacent router. In effect the ATM core is transparent and thus you have 1000 routers connected to each other. This requires that adjacencies at each node is 999 (N-1). With densely meshed networks the number of adjacencies are less than of fully meshed network. Abbas Bagasra -----Original Message----- From: Yi Chu [mailto:ychu@winstar.com] Sent: Friday, January 05, 2001 9:22 AM To: curtis@avici.com; Cheng-Yin Lee Cc: Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: RE: Some queries Please forgive me if my question is so obvious and maybe stupid, since I am new to this discussion. Why 1000 nodes can have 10-15 adjacencies while IP over ATM needs 999 adjacencies per node? I think IP over ATM uses ATM VC just as a physical link, so there is no difference in adjacencies per node whether the routers are connected through Sonet links or ATM VCs. So what is the reason that IP over ATM requires full VC mesh of all nodes? Yi Chu -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Curtis Villamizar Sent: Thursday, January 04, 2001 10:27 PM To: Cheng-Yin Lee Cc: curtis@avici.com; Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: Re: Some queries In message <3A54E972.9C7746D6@nortelnetworks.com>, "Cheng-Yin Lee" writes: > Curtis, > > Curtis Villamizar wrote: > > > There were a number of motivations for getting rid of ATM in IP > > networks. One was the cell tax which at a typical 20% would not alone > > kill ATM. Another was SAR. You can't get fast ATM router interfaces > > because SAR speed and SAR buffering becomes a problem. This alone was > > enough to kill ATM. > > > > Perhaps even larger was the problems of independent control planes and > > the effect on IGP scaling. Flooding is needed for reliability in the > > IGP and flooding in a full mesh of N routers has some N^3 properties > > with regard to messages sent when a router in the mesh fails and N^2 > > when a VC fails. Attempts to constrain the flooding tended to slow > > convergence and sometimes cause long lived IGP inconsistency when > > change occurred. This is not a problem is the flooding follows the > > physical interconnections as it does with MPLS since the number of > > adjacencies per node drops dramatically. > > Over time , would there be any inclinations to add direct connectivity betwee > n B > and H, and then over F and D, and so on, leading to perhaps densely meshed > networks in the long run ? What is your opinion on this? > > B-------C-------D > / \ > / \ > A E > \ / > \ / > F--------G--------H > > One could use a common control plane and may still run into IGP scaling issue > s > because the network is densely meshed, right? Densely meshed in a 1,000 node network might mean 10-15 adjacencies per node. That is still a lot less than full mesh of 999 adjacencies per node if IP over ATM were used. > > The IGP scaling problem was address by ISPs by partitioning their > > network into core and regions but this reduced the effectivenes of TE. > > Could you kindly elaborate your thoughts on this? Typically a provider would partition the topology into N regions where N is 10s, then run VCs within an ATM core that interconnected the regions and VCs within each region. The routers had no visibility into TE state so if there was mutliple routers bordering the core and a given region and one of those core routers had a much less congested path to a destination (recognizing that congestion was more likely within specific regions than with the core) then the core routers had no good way to pick the right edge router and get on the VC with a cleaner shot at the destination. [Its late. I hope this is clear.] > thanks, > cyl Curtis From owner-mpls@UU.NET Fri Jan 5 10:11:12 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14443 for ; Fri, 5 Jan 2001 10:11:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwrc23740; Fri, 5 Jan 2001 15:11:11 GMT Received: by mail-control.mail.uu.net id QQjwrc08952 for mpls-outgoing; Fri, 5 Jan 2001 15:10:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwrc08947 for ; Fri, 5 Jan 2001 15:10:36 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 QQjwrc20806 for ; Fri, 5 Jan 2001 15:08:39 GMT Received: from stn.springtidenet.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: stn.springtidenet.com [63.88.111.246]) id QQjwrc15651 for ; Fri, 5 Jan 2001 15:08:38 GMT Received: from stn15.springtidenet.com by stn.springtidenet.com via smtpd (for cmr0.ash.ops.us.uu.net [198.5.241.38]) with SMTP; 5 Jan 2001 15:08:38 UT Received: from 172.16.6.11 by stn15.springtidenet.com (InterScan E-Mail VirusWall NT); Fri, 05 Jan 2001 10:09:21 -0500 (Eastern Standard Time) Received: from sol.springtidenet.com (sol.springtidenet.com [172.20.20.4]) by stn11.springtidenet.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id KAA05116; Fri, 05 Jan 2001 10:09:28 -0500 Received: by h135-119-200-11.outland.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 10:09:21 -0500 Message-ID: From: "Bagasrawala, Abbas" To: "'Yi Chu'" Cc: mpls uunet Subject: RE: Some queries Date: Fri, 5 Jan 2001 10:09:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Yi, There's no reason why you cannot configure as you suggested but then B becomes the bottleneck. The use of mpls in atm core helps in scaling the network by avoiding the full meshed vcc's to each of the nodes (routers). Abbas -----Original Message----- From: Yi Chu [mailto:ychu@winstar.com] Sent: Friday, January 05, 2001 9:54 AM To: Bagasrawala, Abbas; curtis@avici.com; Cheng-Yin Lee Cc: Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: RE: Some queries Abbas Bagasra: Thanks for explaining. But sorry I still do not get the point. If I have routers A,B and C, connected through an ATM core. If I set up VCs to connect A and B, B and C only. Is it a legitimate configuration? I mean it is not necessary to have A adjacent to C. Packet from A to C can still be routed through B. Admitted that those packets would traverse in and out the ATM interface on B. But is there any architectural reason why the above configuration is prohibited? yi -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Bagasrawala, Abbas Sent: Friday, January 05, 2001 9:36 AM To: 'Yi Chu'; curtis@avici.com; Cheng-Yin Lee Cc: Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: RE: Some queries Yi, I will attempt to answer this question and the experts can correct me if I am wrong. For IP over ATM (overlay networks) the ATM VC's are just a physical link (as you noted) and thus each router at the end of the VC's need to be aware of the adjacent router. In effect the ATM core is transparent and thus you have 1000 routers connected to each other. This requires that adjacencies at each node is 999 (N-1). With densely meshed networks the number of adjacencies are less than of fully meshed network. Abbas Bagasra -----Original Message----- From: Yi Chu [mailto:ychu@winstar.com] Sent: Friday, January 05, 2001 9:22 AM To: curtis@avici.com; Cheng-Yin Lee Cc: Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: RE: Some queries Please forgive me if my question is so obvious and maybe stupid, since I am new to this discussion. Why 1000 nodes can have 10-15 adjacencies while IP over ATM needs 999 adjacencies per node? I think IP over ATM uses ATM VC just as a physical link, so there is no difference in adjacencies per node whether the routers are connected through Sonet links or ATM VCs. So what is the reason that IP over ATM requires full VC mesh of all nodes? Yi Chu -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Curtis Villamizar Sent: Thursday, January 04, 2001 10:27 PM To: Cheng-Yin Lee Cc: curtis@avici.com; Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: Re: Some queries In message <3A54E972.9C7746D6@nortelnetworks.com>, "Cheng-Yin Lee" writes: > Curtis, > > Curtis Villamizar wrote: > > > There were a number of motivations for getting rid of ATM in IP > > networks. One was the cell tax which at a typical 20% would not alone > > kill ATM. Another was SAR. You can't get fast ATM router interfaces > > because SAR speed and SAR buffering becomes a problem. This alone was > > enough to kill ATM. > > > > Perhaps even larger was the problems of independent control planes and > > the effect on IGP scaling. Flooding is needed for reliability in the > > IGP and flooding in a full mesh of N routers has some N^3 properties > > with regard to messages sent when a router in the mesh fails and N^2 > > when a VC fails. Attempts to constrain the flooding tended to slow > > convergence and sometimes cause long lived IGP inconsistency when > > change occurred. This is not a problem is the flooding follows the > > physical interconnections as it does with MPLS since the number of > > adjacencies per node drops dramatically. > > Over time , would there be any inclinations to add direct connectivity betwee > n B > and H, and then over F and D, and so on, leading to perhaps densely meshed > networks in the long run ? What is your opinion on this? > > B-------C-------D > / \ > / \ > A E > \ / > \ / > F--------G--------H > > One could use a common control plane and may still run into IGP scaling issue > s > because the network is densely meshed, right? Densely meshed in a 1,000 node network might mean 10-15 adjacencies per node. That is still a lot less than full mesh of 999 adjacencies per node if IP over ATM were used. > > The IGP scaling problem was address by ISPs by partitioning their > > network into core and regions but this reduced the effectivenes of TE. > > Could you kindly elaborate your thoughts on this? Typically a provider would partition the topology into N regions where N is 10s, then run VCs within an ATM core that interconnected the regions and VCs within each region. The routers had no visibility into TE state so if there was mutliple routers bordering the core and a given region and one of those core routers had a much less congested path to a destination (recognizing that congestion was more likely within specific regions than with the core) then the core routers had no good way to pick the right edge router and get on the VC with a cleaner shot at the destination. [Its late. I hope this is clear.] > thanks, > cyl Curtis From owner-mpls@UU.NET Fri Jan 5 10:53:18 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15398 for ; Fri, 5 Jan 2001 10:53:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwrf02181; Fri, 5 Jan 2001 15:53:17 GMT Received: by mail-control.mail.uu.net id QQjwrf13009 for mpls-outgoing; Fri, 5 Jan 2001 15:52:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwrf13004 for ; Fri, 5 Jan 2001 15:52: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 QQjwrf15091 for ; Fri, 5 Jan 2001 15:50:43 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwrf20453 for ; Fri, 5 Jan 2001 15:50:41 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA21335 for mpls@uu.net; Fri, 5 Jan 2001 10:50:41 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwrf12840 for ; Fri, 5 Jan 2001 15:50: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 QQjwrf12081 for ; Fri, 5 Jan 2001 15:49:45 GMT Received: from lohi.eng.telia.fi by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQjwrf19005 for ; Fri, 5 Jan 2001 15:49:44 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f05FAwM15948; Fri, 5 Jan 2001 17:10:58 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14933.58370.167716.829114@lohi.eng.telia.fi> Date: Fri, 5 Jan 2001 17:10:58 +0200 (EET) To: "Yi Chu" Cc: "Bagasrawala, Abbas" , , "Cheng-Yin Lee" , "Faisal S. Naik" , "mpls uunet" , , Subject: RE: Some queries In-Reply-To: <000c01c07727$601ac190$a0b7010a@winstar.com> References: <000c01c07727$601ac190$a0b7010a@winstar.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Yi Chu writes: > Thanks for explaining. But sorry I still do not get the point. If I have > routers A,B and C, connected through an ATM core. If I set up VCs to > connect A and B, B and C only. Is it a legitimate configuration? I mean it > is not necessary to have A adjacent to C. Packet from A to C can still be > routed through B. Admitted that those packets would traverse in and out > the ATM interface on B. But is there any architectural reason why the above > configuration is prohibited? no, the configuration is not prohibited and in fact some routers allow all three interface still to use an ip address from the same ip subnet. so you could start with default connectivity between your routers and then start adding more connections dynamically if there is enough traffic between a pair. i documented this once in an internet draft that has now expired. -- juha From owner-mpls@UU.NET Fri Jan 5 11:46:33 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16414 for ; Fri, 5 Jan 2001 11:46:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwrj16886; Fri, 5 Jan 2001 16:46:32 GMT Received: by mail-control.mail.uu.net id QQjwrj29473 for mpls-outgoing; Fri, 5 Jan 2001 16:46:06 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwrj29425 for ; Fri, 5 Jan 2001 16:45:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjwri14414 for ; Fri, 5 Jan 2001 16:44:04 GMT Received: from winstar.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fw-1.winstar.com [207.86.108.130]) id QQjwri07201 for ; Fri, 5 Jan 2001 16:44:03 GMT Received: from vaawsh032382 (dhcp-vaa-1-183-160.winstar.com [10.1.183.160]) by winstar.com (8.9.3/8.9.1) with SMTP id LAA20151; Fri, 5 Jan 2001 11:40:33 -0500 (EST) From: "Yi Chu" To: "Juha Heinanen" Cc: "Bagasrawala, Abbas" , , "Cheng-Yin Lee" , "Faisal S. Naik" , "mpls uunet" , , Subject: RE: Some queries Date: Fri, 5 Jan 2001 11:37:31 -0500 Message-ID: <001001c07735$ccf9aa20$a0b7010a@winstar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_01C0770B.E423A220" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <14933.58370.167716.829114@lohi.eng.telia.fi> Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C0770B.E423A220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit So based on the reply from Juha and Abbas, there is no need to have 999 adjacencies for IP over ATM either. A densely meshed network would work for ATM solution as well (10 to 15 adjacencies per router for a 1000 router network). I understand the need to improve the overlay model, and thus the need for MPLS. But I just can not stand false statements. Yi -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Juha Heinanen Sent: Friday, January 05, 2001 10:11 AM To: Yi Chu Cc: Bagasrawala, Abbas; curtis@avici.com; Cheng-Yin Lee; Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: RE: Some queries Yi Chu writes: > Thanks for explaining. But sorry I still do not get the point. If I have > routers A,B and C, connected through an ATM core. If I set up VCs to > connect A and B, B and C only. Is it a legitimate configuration? I mean it > is not necessary to have A adjacent to C. Packet from A to C can still be > routed through B. Admitted that those packets would traverse in and out > the ATM interface on B. But is there any architectural reason why the above > configuration is prohibited? no, the configuration is not prohibited and in fact some routers allow all three interface still to use an ip address from the same ip subnet. so you could start with default connectivity between your routers and then start adding more connections dynamically if there is enough traffic between a pair. i documented this once in an internet draft that has now expired. * juha ------=_NextPart_000_0011_01C0770B.E423A220 Content-Type: message/rfc822 Content-Disposition: attachment From: "Bagasrawala, Abbas" To: "'Yi Chu'" Cc: "mpls uunet" Subject: RE: Some queries Date: Fri, 5 Jan 2001 10:09:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Internet Mail Service (5.5.2650.21) X-UIDL: 978707652.15289.sun3mail X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Transfer-Encoding: 7bit Yi, There's no reason why you cannot configure as you suggested but then B becomes the bottleneck. The use of mpls in atm core helps in scaling the network by avoiding the full meshed vcc's to each of the nodes (routers). Abbas -----Original Message----- From: Yi Chu [mailto:ychu@winstar.com] Sent: Friday, January 05, 2001 9:54 AM To: Bagasrawala, Abbas; curtis@avici.com; Cheng-Yin Lee Cc: Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: RE: Some queries Abbas Bagasra: Thanks for explaining. But sorry I still do not get the point. If I have routers A,B and C, connected through an ATM core. If I set up VCs to connect A and B, B and C only. Is it a legitimate configuration? I mean it is not necessary to have A adjacent to C. Packet from A to C can still be routed through B. Admitted that those packets would traverse in and out the ATM interface on B. But is there any architectural reason why the above configuration is prohibited? yi -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Bagasrawala, Abbas Sent: Friday, January 05, 2001 9:36 AM To: 'Yi Chu'; curtis@avici.com; Cheng-Yin Lee Cc: Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: RE: Some queries Yi, I will attempt to answer this question and the experts can correct me if I am wrong. For IP over ATM (overlay networks) the ATM VC's are just a physical link (as you noted) and thus each router at the end of the VC's need to be aware of the adjacent router. In effect the ATM core is transparent and thus you have 1000 routers connected to each other. This requires that adjacencies at each node is 999 (N-1). With densely meshed networks the number of adjacencies are less than of fully meshed network. Abbas Bagasra -----Original Message----- From: Yi Chu [mailto:ychu@winstar.com] Sent: Friday, January 05, 2001 9:22 AM To: curtis@avici.com; Cheng-Yin Lee Cc: Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: RE: Some queries Please forgive me if my question is so obvious and maybe stupid, since I am new to this discussion. Why 1000 nodes can have 10-15 adjacencies while IP over ATM needs 999 adjacencies per node? I think IP over ATM uses ATM VC just as a physical link, so there is no difference in adjacencies per node whether the routers are connected through Sonet links or ATM VCs. So what is the reason that IP over ATM requires full VC mesh of all nodes? Yi Chu -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Curtis Villamizar Sent: Thursday, January 04, 2001 10:27 PM To: Cheng-Yin Lee Cc: curtis@avici.com; Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: Re: Some queries In message <3A54E972.9C7746D6@nortelnetworks.com>, "Cheng-Yin Lee" writes: > Curtis, > > Curtis Villamizar wrote: > > > There were a number of motivations for getting rid of ATM in IP > > networks. One was the cell tax which at a typical 20% would not alone > > kill ATM. Another was SAR. You can't get fast ATM router interfaces > > because SAR speed and SAR buffering becomes a problem. This alone was > > enough to kill ATM. > > > > Perhaps even larger was the problems of independent control planes and > > the effect on IGP scaling. Flooding is needed for reliability in the > > IGP and flooding in a full mesh of N routers has some N^3 properties > > with regard to messages sent when a router in the mesh fails and N^2 > > when a VC fails. Attempts to constrain the flooding tended to slow > > convergence and sometimes cause long lived IGP inconsistency when > > change occurred. This is not a problem is the flooding follows the > > physical interconnections as it does with MPLS since the number of > > adjacencies per node drops dramatically. > > Over time , would there be any inclinations to add direct connectivity betwee > n B > and H, and then over F and D, and so on, leading to perhaps densely meshed > networks in the long run ? What is your opinion on this? > > B-------C-------D > / \ > / \ > A E > \ / > \ / > F--------G--------H > > One could use a common control plane and may still run into IGP scaling issue > s > because the network is densely meshed, right? Densely meshed in a 1,000 node network might mean 10-15 adjacencies per node. That is still a lot less than full mesh of 999 adjacencies per node if IP over ATM were used. > > The IGP scaling problem was address by ISPs by partitioning their > > network into core and regions but this reduced the effectivenes of TE. > > Could you kindly elaborate your thoughts on this? Typically a provider would partition the topology into N regions where N is 10s, then run VCs within an ATM core that interconnected the regions and VCs within each region. The routers had no visibility into TE state so if there was mutliple routers bordering the core and a given region and one of those core routers had a much less congested path to a destination (recognizing that congestion was more likely within specific regions than with the core) then the core routers had no good way to pick the right edge router and get on the VC with a cleaner shot at the destination. [Its late. I hope this is clear.] > thanks, > cyl Curtis ------=_NextPart_000_0011_01C0770B.E423A220-- From owner-mpls@UU.NET Fri Jan 5 12:09:00 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16941 for ; Fri, 5 Jan 2001 12:09:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwrk18431; Fri, 5 Jan 2001 17:08:59 GMT Received: by mail-control.mail.uu.net id QQjwrk12690 for mpls-outgoing; Fri, 5 Jan 2001 17:08:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwrk12676 for ; Fri, 5 Jan 2001 17:08: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 QQjwrk09572 for ; Fri, 5 Jan 2001 17:07:42 GMT Received: from zcars04e.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) id QQjwrk10509 for ; Fri, 5 Jan 2001 17:07:41 GMT Received: from zcard00n.ca.nortel.com by zcars04e.ca.nortel.com; Fri, 5 Jan 2001 12:05:37 -0500 Received: from zcard00p.ca.nortel.com ([47.129.25.61]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CJNWWRAJ; Fri, 5 Jan 2001 12:05:38 -0500 Received: from nortelnetworks.com (zcars02x.ca.nortel.com [47.23.81.10]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y9V14B5P; Fri, 5 Jan 2001 12:05:33 -0500 Message-ID: <3A55FEDC.75C84C0@nortelnetworks.com> Date: Fri, 05 Jan 2001 12:05:33 -0500 From: "Cheng-Yin Lee" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Yi Chu CC: Juha Heinanen , "Bagasrawala, Abbas" , curtis , "Faisal S. Naik" , mpls uunet , zaziz , prasanna Subject: Re: Some queries References: <001001c07735$ccf9aa20$a0b7010a@winstar.com> Content-Type: multipart/alternative; boundary="------------5C7C21B216BB399BD830E0FE" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk --------------5C7C21B216BB399BD830E0FE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yi, The related point that I was trying to get clarification from Curtis was that it is not so much independent control planes that result in IGP scaling issues (wrt the quote below from Curtis), but rather how fully-meshed one's network is. But I think this point is clearer now. thanks, cyl > Curtis Villamizar wrote: > > There were a number of motivations for getting rid of ATM in IP > networks. One was the cell tax which at a typical 20% would not alone > kill ATM. Another was SAR. You can't get fast ATM router interfaces > because SAR speed and SAR buffering becomes a problem. This alone was > enough to kill ATM. > > Perhaps even larger was the problems of independent control planes and > the effect on IGP scaling. .... > Yi Chu wrote: > So based on the reply from Juha and Abbas, there is no need to have 999 > adjacencies for IP over ATM either. A densely meshed network would work for > ATM solution as well (10 to 15 adjacencies per router for a 1000 router > network). > > I understand the need to improve the overlay model, and thus the need for > MPLS. But I just can not stand false statements. > > Yi > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Juha > Heinanen > Sent: Friday, January 05, 2001 10:11 AM > To: Yi Chu > Cc: Bagasrawala, Abbas; curtis@avici.com; Cheng-Yin Lee; Faisal S. Naik; > mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in > Subject: RE: Some queries > > Yi Chu writes: > > > Thanks for explaining. But sorry I still do not get the point. If I have > > routers A,B and C, connected through an ATM core. If I set up VCs to > > connect A and B, B and C only. Is it a legitimate configuration? I mean > it > > is not necessary to have A adjacent to C. Packet from A to C can still > be > > routed through B. Admitted that those packets would traverse in and out > > the ATM interface on B. But is there any architectural reason why the > above > > configuration is prohibited? > > no, the configuration is not prohibited and in fact some routers allow > all three interface still to use an ip address from the same ip subnet. > > so you could start with default connectivity between your routers and > then start adding more connections dynamically if there is enough > traffic between a pair. i documented this once in an internet draft that > has now expired. > > * juha > > ------------------------------------------------------------------------ > > Part 1.2 Type: message/rfc822 > Encoding: 7bit --------------5C7C21B216BB399BD830E0FE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Yi,
The related point that I was trying to get clarification from Curtis was that it is not so much independent control planes that result in IGP scaling issues (wrt the quote below from Curtis), but rather how fully-meshed one's network is.  But I think this point is clearer now.

thanks,
cyl 

Curtis Villamizar wrote:
There were a number of motivations for getting rid of ATM in IP
networks.  One was the cell tax which at a typical 20% would not alone
kill ATM.  Another was SAR.  You can't get fast ATM router interfaces
because SAR speed and SAR buffering becomes a problem.  This alone was
enough to kill ATM.
Perhaps even larger was the problems of independent control planes and
the effect on IGP scaling. ....

Yi Chu wrote:

So based on the reply from Juha and Abbas, there is no need to have 999
adjacencies for IP over ATM either.  A densely meshed network would work for
ATM solution as well (10 to 15 adjacencies per router for a 1000 router
network).

I understand the need to improve the overlay model, and thus the need for
MPLS.  But I just can not stand false statements.

Yi

-----Original Message-----
From:   owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Juha
Heinanen
Sent:   Friday, January 05, 2001 10:11 AM
To:     Yi Chu
Cc:     Bagasrawala, Abbas; curtis@avici.com; Cheng-Yin Lee; Faisal S. Naik;
mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in
Subject:        RE: Some queries

Yi Chu writes:

 > Thanks for explaining. But sorry I still do not get the point.  If I have
 > routers A,B and C, connected through an ATM core.  If I set up VCs to
 > connect A and B, B and C only.  Is it a legitimate configuration?  I mean
it
 > is not necessary to have A adjacent to C.  Packet from A to C can still
be
 > routed through B.  Admitted that those packets would traverse in and out
 > the ATM interface on B.  But is there any architectural reason why the
above
 > configuration is prohibited?

no, the configuration is not prohibited and in fact some routers allow
all three interface still to use an ip address from the same ip subnet.

so you could start with default connectivity between your routers and
then start adding more connections dynamically if there is enough
traffic between a pair. i documented this once in an internet draft that
has now expired.

* juha

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

   Part 1.2    Type: message/rfc822
           Encoding: 7bit

--------------5C7C21B216BB399BD830E0FE-- From owner-mpls@UU.NET Fri Jan 5 12:25:37 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17300 for ; Fri, 5 Jan 2001 12:25:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwrl18470; Fri, 5 Jan 2001 17:25:30 GMT Received: by mail-control.mail.uu.net id QQjwrl14683 for mpls-outgoing; Fri, 5 Jan 2001 17:25:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwrl14666 for ; Fri, 5 Jan 2001 17:24:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjwrl17667 for ; Fri, 5 Jan 2001 17:23:58 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwrl11077 for ; Fri, 5 Jan 2001 17:23:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA29754 for mpls@uu.net; Fri, 5 Jan 2001 12:23:55 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwrl14600 for ; Fri, 5 Jan 2001 17:23: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 QQjwrl13891 for ; Fri, 5 Jan 2001 17:22:34 GMT Received: from ogma.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ogma.cisco.com [144.254.74.39]) id QQjwrl04416 for ; Fri, 5 Jan 2001 17:22:32 GMT Received: from amsterdam.cisco.com (amsterdam.cisco.com [144.254.74.36]) by ogma.cisco.com (Postfix) with ESMTP id DD97513B; Fri, 5 Jan 2001 18:22:31 +0100 (MET) Received: from wdec.cisco.com (amsterdam3-dhcp30.cisco.com [144.254.51.79]) by amsterdam.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA21795; Fri, 5 Jan 2001 18:22:30 +0100 (MET) Message-Id: <4.3.2.7.2.20010105181619.00b5ba80@amsterdam.cisco.com> X-Sender: wdec@amsterdam.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 05 Jan 2001 18:22:20 +0100 To: Sachin Doshi , mpls@UU.NET From: Wojciech Dec Subject: Re: Query In-Reply-To: <3A5591B4.5F86EDDC@siliconsystems.co.in> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 14:49 05/01/01 +0530, Sachin Doshi wrote: >Hi, > Could anyone clarify me on these > >1. When is MPLS label of 0 (implicit IP is used)? It's typically used in penultimate-hop popping scenarios, however the use of explicit null or implicit null in such scenarios is something that would be typically preconfigured. >2. How is the TTL field update in MPLS packets. Suppose there is a >egress router which can pop the MPLS label and then can switch/route the >packet on IP address. By how much should it decrement the TTL (1 or 2). If TTL is to retain the meaning and use of TTL, then the decrement must be 1. Regards, Woj. >regards, > sachin doshi _________________________________________________________ Wojciech Dec CCIE# 5563 Phone: +31 (0)20 342 3034 Network Consulting Engineer Mobile: +31 (0)622 466 802 Cisco Systems, E-Mail: wdec@cisco.com PO Box 22514, 1100 DA Amsterdam The Netherlands From owner-mpls@UU.NET Fri Jan 5 14:06:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19906 for ; Fri, 5 Jan 2001 14:06:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwrs17798; Fri, 5 Jan 2001 19:06:17 GMT Received: by mail-control.mail.uu.net id QQjwrs13911 for mpls-outgoing; Fri, 5 Jan 2001 19:05:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjwrs13886 for ; Fri, 5 Jan 2001 19:05:29 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjwrs18003 for ; Fri, 5 Jan 2001 19:04:50 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwrs28778 for ; Fri, 5 Jan 2001 19:04:49 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA07659 for mpls@uu.net; Fri, 5 Jan 2001 14:04:49 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwrs10579 for ; Fri, 5 Jan 2001 19:04:04 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 QQjwrs19574 for ; Fri, 5 Jan 2001 19:04:00 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 QQjwrs03704 for ; Fri, 5 Jan 2001 19:04:00 GMT Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA22533 for ; Fri, 5 Jan 2001 11:04:10 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f05J41m11983 for ; Fri, 5 Jan 2001 11:04:01 -0800 (PST) Received: from jugland-pc (sj-dial-4-67.cisco.com [171.68.181.196]) by mailman.cisco.com (8.9.3/8.9.1) with SMTP id LAA15991 for ; Fri, 5 Jan 2001 11:03:57 -0800 (PST) Message-Id: <200101051903.LAA15991@mailman.cisco.com> X-Sender: jugland@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Fri, 05 Jan 2001 11:11:46 -0800 To: mpls@UU.NET From: Jason Ugland Subject: mpls-request@uu.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk mpls-request@uu.net From owner-mpls@UU.NET Fri Jan 5 15:44:47 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21995 for ; Fri, 5 Jan 2001 15:44:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwry27692; Fri, 5 Jan 2001 20:44:38 GMT Received: by mail-control.mail.uu.net id QQjwry05318 for mpls-outgoing; Fri, 5 Jan 2001 20:44:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwry05307 for ; Fri, 5 Jan 2001 20:44: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 QQjwry03546 for ; Fri, 5 Jan 2001 20:43:21 GMT Received: from mx1out.umbc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx1out.umbc.edu [130.85.253.51]) id QQjwry07708 for ; Fri, 5 Jan 2001 20:43:20 GMT Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx1out.umbc.edu (8.9.3/8.9.3) with ESMTP id PAA22733; Fri, 5 Jan 2001 15:43:18 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id PAA345560; Fri, 5 Jan 2001 15:43:18 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Fri, 5 Jan 2001 15:43:18 -0500 From: Vijay Gill X-Sender: vijay@irix2.gl.umbc.edu To: Yi Chu cc: mpls uunet Subject: RE: Some queries In-Reply-To: <001001c07735$ccf9aa20$a0b7010a@winstar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Fri, 5 Jan 2001, Yi Chu wrote: > So based on the reply from Juha and Abbas, there is no need to have 999 > adjacencies for IP over ATM either. A densely meshed network would work for > ATM solution as well (10 to 15 adjacencies per router for a 1000 router > network). > > I understand the need to improve the overlay model, and thus the need for > MPLS. But I just can not stand false statements. People, it doesn't hurt to trim headers. There is nothing that precludes running ATM over a point to point links like SONET, so that your adjacency count grows linearly as the number of links in your network. That approach adds no major benefit over PoS and increases your cost/bit of ip traffic transported over your network (cell tax). This is a reasonable approach if you are buying ATM pvc's across some other providers cloud to get cheaper pipes. This approach is perfectly analogous to just buying point to point circuits and gives up a very important feature that some ISPs currently use ATM for - the ability to get constrained based routing, so as to do effective automatic traffic engineering. To allow for automatic traffic engineering, some organizations terminate their SONET handoffs into ATM switches and terminate routers into the ATM switches as well. The ATM switches then talk amongst each other (various levels of hierarchy go in here), and export a virtualized transport fabric to the routers. The routers are then fully meshed with subinterfaces and sPVCs to all the other routers in that particular area, such that no router _transits_ another router. All routers appear to be directly connected to each other, so that the IP traffic always takes what appears to be the shortest path to any other router (a direct connection). In general, hop by hop traffic forwarding can only super-aggregate traffic, thus hiding edge-edge traffic flow information. Using a full mesh of ATM pvcs such that there is no edge-router----intermediate-router-----edge-router transit allows operators to disambiguate the traffic flow on an edge-edge basis. This, along with some hierarchy, allows for precise traffic measurement between router-router flows and at the city-pair level, and results in fairly tractable flow data that can be used to predict traffic levels, allowing for proper sizing of sPVC contracts, etc. These contracts are then used by the ATM switch software to do constrained based routing of sPVCs, allowing the network operators to do a good job of traffic engineering and circuit layout/capacity planning. This might explain why people have gone with the extra expense (both in capex and SGnA) and complexity to implement a fully meshed ATM solution. /vijay From owner-mpls@UU.NET Fri Jan 5 16:06:21 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22542 for ; Fri, 5 Jan 2001 16:06:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwsa29103; Fri, 5 Jan 2001 21:06:08 GMT Received: by mail-control.mail.uu.net id QQjwsa14590 for mpls-outgoing; Fri, 5 Jan 2001 21:05:36 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwsa14399 for ; Fri, 5 Jan 2001 21:05:31 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 QQjwsa07498 for ; Fri, 5 Jan 2001 21:05:27 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjwsa18501 for ; Fri, 5 Jan 2001 21:05:27 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA21745 for ; Fri, 5 Jan 2001 13:05:33 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA14041 for mpls@uu.net; Fri, 5 Jan 2001 16:05:25 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwry05206 for ; Fri, 5 Jan 2001 20:42: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 QQjwry15722 for ; Fri, 5 Jan 2001 20:42:14 GMT Received: from po4.glue.umd.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: po4.glue.umd.edu [128.8.10.124]) id QQjwry06192 for ; Fri, 5 Jan 2001 20:42:14 GMT Received: from riccati.eng.umd.edu (root@riccati.eng.umd.edu [129.2.94.101]) by po4.glue.umd.edu (8.10.1/8.10.1) with ESMTP id f05KgDR23214; Fri, 5 Jan 2001 15:42:13 -0500 (EST) Received: from riccati.eng.umd.edu (sendmail@localhost [127.0.0.1]) by riccati.eng.umd.edu (8.9.3/8.9.3) with SMTP id PAA05429; Fri, 5 Jan 2001 15:42:13 -0500 (EST) Received: from localhost (shayman@localhost) by riccati.eng.umd.edu (8.9.3/8.9.3) with ESMTP id PAA05425; Fri, 5 Jan 2001 15:42:13 -0500 (EST) X-Authentication-Warning: riccati.eng.umd.edu: shayman owned process doing -bs Date: Fri, 5 Jan 2001 15:42:13 -0500 (EST) From: Mark Shayman X-Sender: shayman@riccati.eng.umd.edu To: mpls@UU.NET, tsvwg@ietf.org cc: Mark Shayman , rfj@cs.umd.edu Subject: I-D:Using ECN to Signal Congestion Within an MPLS Domain Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, We have submitted an I-D: "Using ECN to Signal Congestion Within an MPLS Domain. It can be found at http://www.ietf.org/internet-drafts/draft-shayman-mpls-ecn-00.txt The abstract is given below. We would welcome feedback. --Mark Shayman and Rob Jaeger =========================================================================== Abstract: We propose the addition of Explicit Congestion Notification (ECN) together with congestion signaling back to the ingress in order to provide notification to the ingress label switching router (LSR) if congestion is experienced along a label switched path (LSP). This information could be used by the ingress LSR to mitigate congestion by employing dynamic traffic engineering techniques such as shifting flows to alternate paths. While extending ECN to enable its use for congestion control by the ingress LSR, the proposal retains (with modification) the capability to signal ECN end-to-end as proposed in an earlier IETF draft authored by others. The current proposal incorporates ECN into MPLS in a manner that is coordinated with the use of ECN in IP, is backwards compatible, and provides MPLS with a means of alleviating congestion of flows traversing MPLS tunnels. **************************************************************************** Prof. Mark Shayman email: shayman@eng.umd.edu Dept. Electrical & Computer Eng. phone: 301-405-3667 University of Maryland fax: 301-314-9281 College Park, MD 20742 From owner-mpls@UU.NET Fri Jan 5 16:15:00 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22743 for ; Fri, 5 Jan 2001 16:15:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwsa20587; Fri, 5 Jan 2001 21:14:42 GMT Received: by mail-control.mail.uu.net id QQjwsa19665 for mpls-outgoing; Fri, 5 Jan 2001 21:14:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjwsa19656 for ; Fri, 5 Jan 2001 21:14:12 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 QQjwsa23770 for ; Fri, 5 Jan 2001 21:12:38 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjwsa28494 for ; Fri, 5 Jan 2001 21:12:38 GMT Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA14986; Fri, 5 Jan 2001 13:12:06 -0800 (PST) Received: from garnet.juniper.net (localhost [127.0.0.1]) by garnet.juniper.net (8.9.3/8.9.3) with ESMTP id NAA47507; Fri, 5 Jan 2001 13:12:05 -0800 (PST) (envelope-from yakov@garnet.juniper.net) Message-Id: <200101052112.NAA47507@garnet.juniper.net> To: erosen@cisco.com cc: "Rijsman, Bruno" , "'mpls@UU.NET'" , "BGP exploder (E-mail)" Subject: Re: Encoding of MPLS label in MP-REACH-NLRI question In-Reply-To: Your message of "Thu, 04 Jan 2001 11:24:42 EST." <200101041624.LAA09012@erosen-sun.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <47504.978729125.1@garnet.juniper.net> Date: Fri, 05 Jan 2001 13:12:05 -0800 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Eric, > Right now the draft says: > > The Label field carries one or more labels (that corresponds > to the stack of labels [MPLS-ENCAPS]). Each label is encoded > as 3 octets, where the high-order bit contains "Bottom of > Stack" (as defined in [MPLS-ENCAPS]). The following high-order > three bits must be zero. The remaining 20 bits contain the > label value. > > Barring objection, I will change this to: > > The Label field carries one or more labels (that corresponds > to the stack of labels [MPLS-ENCAPS]). Each label is encoded > as 3 octets, where the high-order 20 bits contain the label > value, the following three bits must be zero, and the low > order bit contains "Bottom of Stack" (as defined in > [MPLS-ENCAPS]). > > and reissue the draft. I also wonder whether we need "the following three bits must be zero"... Yakov. > From owner-mpls@UU.NET Fri Jan 5 17:20:51 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24393 for ; Fri, 5 Jan 2001 17:20:51 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwsf26244; Fri, 5 Jan 2001 22:20:44 GMT Received: by mail-control.mail.uu.net id QQjwsf07810 for mpls-outgoing; Fri, 5 Jan 2001 22:20:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwsf07798 for ; Fri, 5 Jan 2001 22:20: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 QQjwsf04221 for ; Fri, 5 Jan 2001 22:19:57 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwsf27604 for ; Fri, 5 Jan 2001 22:19:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA23838 for mpls@uu.net; Fri, 5 Jan 2001 17:19:56 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwsf07741 for ; Fri, 5 Jan 2001 22:19:42 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjwsf00897 for ; Fri, 5 Jan 2001 22:17:59 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjwsf06817 for ; Fri, 5 Jan 2001 22:17:59 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA01110 for ; Fri, 5 Jan 2001 17:17:58 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA25562 for ; Fri, 5 Jan 2001 17:17:58 -0500 (EST) Message-Id: <200101052217.RAA25562@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Last call on MPLS TE MIB Date: Fri, 05 Jan 2001 17:17:58 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk This message begins a workgroup last call on draft-ietf-mpls-te-mib-05.txt, "MPLS Traffic Engineering Management Information Base Using SMIv2". The last call ends Jan 19, 5pm est. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Fri Jan 5 17:34:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24628 for ; Fri, 5 Jan 2001 17:34:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwsg13967; Fri, 5 Jan 2001 22:33:55 GMT Received: by mail-control.mail.uu.net id QQjwsg09151 for mpls-outgoing; Fri, 5 Jan 2001 22:33:24 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwsg09137 for ; Fri, 5 Jan 2001 22:33: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 QQjwsg14336 for ; Fri, 5 Jan 2001 22:32:37 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjwsg14542 for ; Fri, 5 Jan 2001 22:32:36 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA24943 for mpls@uu.net; Fri, 5 Jan 2001 17:32:36 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwsg09041 for ; Fri, 5 Jan 2001 22:32:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjwsg29170 for ; Fri, 5 Jan 2001 22:31:09 GMT Received: from funnel.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjwsg25510 for ; Fri, 5 Jan 2001 22:31:09 GMT Received: from lir.cisco.com (lir-hme1.cisco.com [171.69.209.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA02566 for ; Fri, 5 Jan 2001 17:31:08 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA04518 for ; Fri, 5 Jan 2001 17:31:08 -0500 (EST) Message-Id: <200101052231.RAA04518@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: mpls@UU.NET Subject: Last call on MPLS multicast framework Date: Fri, 05 Jan 2001 17:31:08 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk This message begins a workgroup last call on draft-ietf-mpls-multicast-04.txt, "Framework for IP Multicast in MPLS" The last call ends Jan 19, 5pm est. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Sat Jan 6 12:35:10 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16531 for ; Sat, 6 Jan 2001 12:35:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwve13701; Sat, 6 Jan 2001 17:34:55 GMT Received: by mail-control.mail.uu.net id QQjwve28096 for mpls-outgoing; Sat, 6 Jan 2001 17:34:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwve28089 for ; Sat, 6 Jan 2001 17:34:17 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 QQjwve24489 for ; Sat, 6 Jan 2001 17:33:45 GMT Received: from femail5.sdc1.sfba.home.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail5.sdc1.sfba.home.com [24.0.95.85]) id QQjwve12222 for ; Sat, 6 Jan 2001 17:33:44 GMT Received: from c1052242a.frmt1.sfba.home.com ([24.19.208.28]) by femail5.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010106173344.NQVE29808.femail5.sdc1.sfba.home.com@c1052242a.frmt1.sfba.home.com>; Sat, 6 Jan 2001 09:33:44 -0800 Message-ID: <009f01c0786b$5f4a1be0$1cd01318@frmt1.sfba.home.com> Reply-To: "Manohar Ellanti" From: "Manohar Ellanti" To: "mpls uunet" Cc: "Vijay Gill" , "Yi Chu" References: Subject: Re: Some queries Date: Sat, 6 Jan 2001 21:33:31 -0800 Organization: @home MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Vijay Gill" > This approach is perfectly analogous to just buying point to point > circuits and gives up a very important feature that some ISPs currently > use ATM for - the ability to get constrained based routing, so as to do > effective automatic traffic engineering. > > To allow for automatic traffic engineering, some organizations terminate > their SONET handoffs into ATM switches and terminate routers into the ATM > switches as well. The ATM switches then talk amongst each other (various > levels of hierarchy go in here), and export a virtualized transport fabric > to the routers. The routers are then fully meshed with subinterfaces and > sPVCs to all the other routers in that particular area, such that no > router _transits_ another router. All routers appear to be directly > connected to each other, so that the IP traffic always takes what appears > to be the shortest path to any other router (a direct connection). > > Do you mean to say SPs such as large/national ISPs use ATMs on the backbone and have complete mesh with DS3/OC-3/OC-12 links and then allow routers etc connected to these ATMs switches to have mesh connectivity as well between all POPs using sub-interfaces or different physical interfaces. I would think they use core routers to build the backbone rather than ATM switches. Consider this; POP1---------------------------DS3/OC-3/OC-12/OC-48-------------POP2 R[1..m]--Interface[1..n]--ATM----------------------------------ATM---Interfa ce[1..j]--Router[1..k] \ / \ / \ / \ / \ / \ / POP 3 ATM R[1..M]---Interface[1..N] In this case R-to-R logical mesh can be accomplished using PVCs (on per router or per interface basis) with traffic engineering occurring in the overlay IP network as well as in the ATM network. -Manohar N Ellanti From owner-mpls@UU.NET Sat Jan 6 13:38:43 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16804 for ; Sat, 6 Jan 2001 13:38:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwvi06882; Sat, 6 Jan 2001 18:38:17 GMT Received: by mail-control.mail.uu.net id QQjwvi13462 for mpls-outgoing; Sat, 6 Jan 2001 18:37:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwvi13457 for ; Sat, 6 Jan 2001 18:37:47 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 QQjwvi24101 for ; Sat, 6 Jan 2001 18:37:27 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjwvi05474 for ; Sat, 6 Jan 2001 18:37:27 GMT Received: from oleary-lt (mccarthy-lt.jnpr.net [172.24.249.44] (may be forged)) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA18295; Sat, 6 Jan 2001 10:37:23 -0800 (PST) Message-Id: <4.2.0.58.20010106103016.01572c30@garnet.juniper.net> X-Sender: doleary@garnet.juniper.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 06 Jan 2001 10:34:06 -0800 To: "Manohar Ellanti" , "mpls uunet" From: "dave o'leary" Subject: Re: Some queries In-Reply-To: <009f01c0786b$5f4a1be0$1cd01318@frmt1.sfba.home.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 09:33 PM 1/6/01 -0800, Manohar Ellanti wrote: >Do you mean to say SPs such as large/national ISPs use ATMs on the backbone >and have complete mesh with DS3/OC-3/OC-12 links and then allow routers etc >connected to these ATMs switches to have mesh connectivity as well between >all POPs using sub-interfaces or different physical interfaces. I would >think they use core routers to build the backbone rather than ATM switches. ATM in the some of the larger backbones was common throughout the mid-late 90's, and still remains in some of the networks - but due to some of the reasons discussed on this thread, many are planning to migrate to routers/LSRs interconnected with SONET/SDH links and no ATM switches (or encapsulation), using MPLS to more or less replicate the traffic engineering capabilities of ATM between routers - I believe this is where this thread started, right? dave From owner-mpls@UU.NET Sat Jan 6 14:31:56 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17155 for ; Sat, 6 Jan 2001 14:31:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwvm17596; Sat, 6 Jan 2001 19:31:46 GMT Received: by mail-control.mail.uu.net id QQjwvm28186 for mpls-outgoing; Sat, 6 Jan 2001 19:31:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwvm28141 for ; Sat, 6 Jan 2001 19:31: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 QQjwvl17122 for ; Sat, 6 Jan 2001 19:28:54 GMT Received: from web11908.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11908.mail.yahoo.com [216.136.172.192]) id QQjwvl18366 for ; Sat, 6 Jan 2001 19:28:53 GMT Message-ID: <20010106192853.11365.qmail@web11908.mail.yahoo.com> Received: from [63.113.148.3] by web11908.mail.yahoo.com; Sat, 06 Jan 2001 11:28:53 PST Date: Sat, 6 Jan 2001 11:28:53 -0800 (PST) From: Mahesh S Subject: Forwarding Adjacency LSPs 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 question about LSP heirarchy with MPLS TE draft draft-kompella-lsp-hierarchy-00.txt This draft says in section 4.2 That OSPF/ISIS peering is not expected to happen across an FA-LSP. It also the link should be announced as a point to point link. But section 12.4.1.1 of RFC2328 (OSPF ver 2) says the link should be announced as a point to point link (type 1) only if adjacency is established otherwise it should be only announced as a stub link(type 3). The question is do we announce it as a stub link (type 3)? in that case this link will not be used to reach the routers that are further down the tail end of the FA LSP? If we announce it as a point2point link (type 1) does it confirm to RFC2328? thanks, mahesh __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From owner-mpls@UU.NET Sat Jan 6 15:08:01 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17344 for ; Sat, 6 Jan 2001 15:08:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwvo06000; Sat, 6 Jan 2001 20:07:55 GMT Received: by mail-control.mail.uu.net id QQjwvo11746 for mpls-outgoing; Sat, 6 Jan 2001 20:07:23 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwvo11738 for ; Sat, 6 Jan 2001 20:07:21 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 QQjwvo13111 for ; Sat, 6 Jan 2001 20:06:44 GMT Received: from rip.psg.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQjwvo15524 for ; Sat, 6 Jan 2001 20:06:43 GMT Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14Ezbn-000DpN-00; Sat, 06 Jan 2001 12:06:35 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Manohar Ellanti" Cc: "mpls uunet" , "Vijay Gill" , "Yi Chu" Subject: Re: Some queries References: <009f01c0786b$5f4a1be0$1cd01318@frmt1.sfba.home.com> Message-Id: Date: Sat, 06 Jan 2001 12:06:35 -0800 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Do you mean to say SPs such as large/national ISPs use ATMs on the backbone > and have complete mesh with DS3/OC-3/OC-12 links no, complete mesh of vcs over semi-meshed physical circuits randy From owner-mpls@UU.NET Sat Jan 6 16:03:22 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17706 for ; Sat, 6 Jan 2001 16:03:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwvs16888; Sat, 6 Jan 2001 21:03:14 GMT Received: by mail-control.mail.uu.net id QQjwvs24703 for mpls-outgoing; Sat, 6 Jan 2001 21:02:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjwvs23703 for ; Sat, 6 Jan 2001 21:02:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjwvs02650 for ; Sat, 6 Jan 2001 21:02:15 GMT Received: from ulysses.routingloop.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dsl-64-195-149-73.telocity.com [64.195.149.73]) id QQjwvs22819 for ; Sat, 6 Jan 2001 21:02:15 GMT Received: (from alan@localhost) by ulysses.routingloop.com (8.10.0/8.10.0) id f06L2Bv11477 for mpls@UU.NET; Sat, 6 Jan 2001 13:02:11 -0800 (PST) Date: Sat, 6 Jan 2001 13:02:10 -0800 From: Alan Hannan To: mpls Subject: Re: Some queries Message-ID: <20010106130210.A11443@routingloop.com> References: <009f01c0786b$5f4a1be0$1cd01318@frmt1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from randy@psg.com on Sat, Jan 06, 2001 at 12:06:35PM -0800 Sender: owner-mpls@UU.NET Precedence: bulk It is useful to point out that within a domain such as the backbone, it is very common to have a partial mesh at L1 (circuit), and a full mesh at L2 (ATM PVC/sPVC or MPLS LSP) and L3 (IP Routing and/or forwarding adjacency).. Note however that all routers in the network/AS may not participate in a full mesh at L2/L3 (much les L1) due to hierarchy. For example, Customer aggregations routers, even if they perform MPLS, are unlikely to have a full mesh w/ all other routers in the AS. Additionally, it is not uncommon to find large/national/global networks will have hierarchical domains, say, of Global Level, National Level, Regional Level, and Metro Levels. Within each of these domains one can expect partial mesh at L1 and full mesh at L2/L3. In such a network, you might find 40 routers in 20 pops on the top-most backbone level, w/ each router having an average degree of freedom of say 2.0 and each POP of 4.0. Therefore you would expect and observe about 80 physical backbone links (DOF*N/2) and about 39 L2/L3 adjacencies (M-1). Note that there should be (M*(M-1)) or about 1560 total forwarding paths in the backbone domain alone. -alan Thus spake Randy Bush (randy@psg.com) on or about Sat, Jan 06, 2001 at 12:06:35PM -0800: > > Do you mean to say SPs such as large/national ISPs use ATMs on the backbone > > and have complete mesh with DS3/OC-3/OC-12 links > > no, complete mesh of vcs over semi-meshed physical circuits > > randy From owner-mpls@UU.NET Sat Jan 6 19:26:00 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18741 for ; Sat, 6 Jan 2001 19:26:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwwf01799; Sun, 7 Jan 2001 00:25:47 GMT Received: by mail-control.mail.uu.net id QQjwwf13263 for mpls-outgoing; Sun, 7 Jan 2001 00:25:12 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwwf13255 for ; Sun, 7 Jan 2001 00:25: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 QQjwwf11034 for ; Sun, 7 Jan 2001 00:25:07 GMT Received: from femail8.sdc1.sfba.home.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail8.sdc1.sfba.home.com [24.0.95.88]) id QQjwwf07849 for ; Sun, 7 Jan 2001 00:25:07 GMT Received: from c1052242a.frmt1.sfba.home.com ([24.19.208.28]) by femail8.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010107002506.DBSJ17073.femail8.sdc1.sfba.home.com@c1052242a.frmt1.sfba.home.com>; Sat, 6 Jan 2001 16:25:06 -0800 Message-ID: <018f01c078a4$d751b600$1cd01318@frmt1.sfba.home.com> Reply-To: "Manohar Ellanti" From: "Manohar Ellanti" To: "mpls uunet" , "dave o'leary" References: <4.2.0.58.20010106103016.01572c30@garnet.juniper.net> Subject: Re: Some queries Date: Sun, 7 Jan 2001 04:24:54 -0800 Organization: @home MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "dave o'leary" > > ATM in the some of the larger backbones was common throughout the mid-late > 90's, > and still remains in some of the networks - but due to some of the reasons > discussed > on this thread, many are planning to migrate to routers/LSRs interconnected > with > SONET/SDH links and no ATM switches (or encapsulation), using MPLS to > more or less replicate the traffic engineering capabilities of ATM between > routers - > I believe this is where this thread started, right? > Agreed. It is also possible to have much simpler and transparent solution to provide point-to-point Service Provider (SP) router connectivity while not mandating that MPLS be used at the edge. We could use the transport/emulation services such DS3/MPLS being proposed or some optimized and data format aware payload point-to-point transport over MPLS. Network Provider (NP) traffic engineering and SP traffic engineering may use same tools such as MPLS or some proprietary but by keeping overlay model there is a natural separation which is simple and easy to operate , especially for NP. Considering that generally POP to POP physical topology is fairly static with lead-planning times of anywhere from few months to an year or longer before a topological change is effected, there is not so much of dynamic nature to the underlying topology. It should therefore be possible to keep provisioning and operational complexity as simple as possible , even that means provisioning point-to-point circuits (LSP) using off-line TE tools and installing the path in the NP network while SP could use dynamic TE mechanisms. I am beginning to think that overlay may be in place despite all the nice things being said of peer model. It is not only avoidance of overhead with ATM cell header ( with NP TE and SP TE there may be stack of 32-bit headers as well) but also avoidance of two control plane technologies:one at the ATM level and one at the IP level. With MPLS, if used by NP we have single technology for control plane however one should not forget that these are still two instance: one instance by NP another instance by SP. As I see it , we do get benefits 1) substantial reduction in overhead (with MPLS we do have overhead) 2) continued existence of two instance of control plane. -Manohar N Ellanti From owner-mpls@UU.NET Sun Jan 7 01:31:43 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25796 for ; Sun, 7 Jan 2001 01:31:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjwxe29416; Sun, 7 Jan 2001 06:31:31 GMT Received: by mail-control.mail.uu.net id QQjwxe14026 for mpls-outgoing; Sun, 7 Jan 2001 06:31:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwxe14007 for ; Sun, 7 Jan 2001 06:31: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 QQjwxe10131 for ; Sun, 7 Jan 2001 06:30:56 GMT Received: from hercules.nj.broadi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.102.22.123]) id QQjwxe03797 for ; Sun, 7 Jan 2001 06:30:52 GMT Received: from 5 ([202.102.22.124]) by hercules.nj.broadi.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 7 Jan 2000 14:36:57 +0800 Date: Sun, 7 Jan 2001 14:33:13 +0800 From: Eric Miao To: "mpls@uu.net" Subject: Some questions(label space, NHLFE, ldp peers for an address prefix) X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 07 Jan 2000 06:36:57.0755 (UTC) FILETIME=[9864BEB0:01BF58D9] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, everybody, Here are some questions about MPLS-ARCH. Can someone give me explanation? Thanks in advance. 1. Label Space ============== 3.14. Scope and Uniqueness of Labels says In general, Rd can only tell whether it was Ru1 or Ru2 that put the particular label value L at the top of the label stack if the following conditions hold: - Ru1 and Ru2 are the only label distribution peers to which Rd ~~~~ distributed a binding of label value L, and - Ru1 and Ru2 are each directly connected to Rd via a point-to- ~~~~~~~~~ point interface. ~~~~~ When these conditions hold, an LSR may use labels that have "per interface" scope, i.e., which are only unique per interface. We may say that the LSR is using a "per-interface label space". When these conditions do not hold, the labels must be unique over the LSR which has assigned them, and we may say that the LSR is using a "per- platform label space." Why must Ru1 and Ru2 be only label distribution peers to which Rd distributed a binding of label value L, and be each directly connected to Rd via a p2p interface? 2. NHLFE ======== 3.10. The Next Hop Label Forwarding Entry (NHLFE) says the operation to perform on the packet's label stack; this is one of the following operations: a) replace the label at the top of the label stack with a specified new label b) pop the label stack c) replace the label at the top of the label stack with a specified new label, and then push one or more specified new labels onto the label stack. Since there is FEC to NHLFE map (FTN) which determines what label an unlabeled packet should be labeled with, why no PUSH operation in NHLFE. 3. Label distribution peers for an address fix ============================================== 4.1.2.1. Label Distribution Peers for an Address Prefix says LSRs R1 and R2 are considered to be label distribution peers for address prefix X if and only if one of the following conditions holds: 1. R1's route to X is a route which it learned about via a particular instance of a particular IGP, and R2 is a neighbor ~~~~~~~~ of R1 in that instance of that IGP 2. R1's route to X is a route which it learned about by some instance of routing algorithm A1, and that route is ~~~~~~~~~~~~ redistributed into an instance of routing algorithm A2, and R2 ~~~~~~~~~~~~~ is a neighbor of R1 in that instance of A2 3. R1 is the receive endpoint of an LSP Tunnel that is within another LSP, and R2 is a transmit endpoint of that tunnel, and R1 and R2 are participants in a common instance of an IGP, and ~~~~~~~~~~~~~~~ are in the same IGP area (if the IGP in question has areas), ~~~~~~~~~~~~~ and R1's route to X was learned via that IGP instance, or is redistributed by R1 into that IGP instance ~~~~~~~~~~~~~ 4. R1's route to X is a route which it learned about via BGP, and R2 is a BGP peer of R1 Above sentences are not easy to understand. Can someone make detailed and clear description?(examples using RIP, OSPF, BGP) Eric Miao ericmiao@nj.broadi.com From owner-mpls@UU.NET Mon Jan 8 05:12:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29010 for ; Mon, 8 Jan 2001 05:12:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxbk23517; Mon, 8 Jan 2001 10:11:50 GMT Received: by mail-control.mail.uu.net id QQjxbk13116 for mpls-outgoing; Mon, 8 Jan 2001 10:11:20 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxbk13045 for ; Mon, 8 Jan 2001 10:11:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjxbk14523 for ; Mon, 8 Jan 2001 10:10:31 GMT Received: from infres.enst.fr by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: infres.enst.fr [137.194.160.3]) id QQjxbk21814 for ; Mon, 8 Jan 2001 10:10:31 GMT Received: from cinna.enst.fr (cinna.enst.fr [137.194.192.5]) by infres.enst.fr (Postfix) with ESMTP id BE40A45407; Mon, 8 Jan 2001 11:10:24 +0100 (MET) Received: from localhost (kuri@localhost) by cinna.enst.fr (8.9.3+Sun/8.9.1) with SMTP id JAA02094; Mon, 8 Jan 2001 09:41:37 +0100 (MET) Date: Mon, 8 Jan 2001 09:41:37 +0100 (MET) From: Josue Kuri To: Eric Miao , @cinna.enst.fr@cinna.enst.fr@cinna.enst.fr@cinna.enst.fr@cinna.enst.fr@cinna.enst.fr Cc: "mpls@uu.net" , @cinna.enst.fr@cinna.enst.fr@cinna.enst.fr@cinna.enst.fr@cinna.enst.fr@cinna.enst.fr Subject: Re: Some questions(label space, NHLFE, ldp peers for an address prefix) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Eric, > 1. Label Space > ============== > > 3.14. Scope and Uniqueness of Labels says > > In general, Rd can only tell whether it was Ru1 or Ru2 that put the > particular label value L at the top of the label stack if the > following conditions hold: > > - Ru1 and Ru2 are the only label distribution peers to which Rd > ~~~~ > distributed a binding of label value L, and > - Ru1 and Ru2 are each directly connected to Rd via a point-to- > ~~~~~~~~~ > point interface. > ~~~~~ > > When these conditions hold, an LSR may use labels that have "per > interface" scope, i.e., which are only unique per interface. We may > say that the LSR is using a "per-interface label space". When these > conditions do not hold, the labels must be unique over the LSR which > has assigned them, and we may say that the LSR is using a "per- > platform label space." > > Why must Ru1 and Ru2 be only label distribution peers to which Rd distributed a > binding of label value L, and be each directly connected to Rd via a p2p interface? > You can think about this otherwise: Rd distributes label "L". {Ru1, Ru2, Ru3...RuN} is a set of upstream LSRs (peers of Rd). If Rd has distributed the SAME label value "L" to all the LSRs in the set, when a packet with label "L" arrives to Rd, Rd can determine which LSR in the set sent the packet based on the interface the packet came through. Note that this is possible only if each LSR in the set is connected to Rd by a DIFFERENT interface. > 2. NHLFE > ======== > > 3.10. The Next Hop Label Forwarding Entry (NHLFE) says > > the operation to perform on the packet's label stack; this is > one of the following operations: > a) replace the label at the top of the label stack with a > specified new label > b) pop the label stack > c) replace the label at the top of the label stack with a > specified new label, and then push one or more specified ^^^^ > new labels onto the label stack. > > Since there is FEC to NHLFE map (FTN) which determines what label an unlabeled packet > should be labeled with, why no PUSH operation in NHLFE. > There is a push operation in (c). Regards, Josue From owner-mpls@UU.NET Mon Jan 8 05:53:47 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29250 for ; Mon, 8 Jan 2001 05:53:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxbn09334; Mon, 8 Jan 2001 10:53:35 GMT Received: by mail-control.mail.uu.net id QQjxbn15711 for mpls-outgoing; Mon, 8 Jan 2001 10:53:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxbn15706 for ; Mon, 8 Jan 2001 10:53:09 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 QQjxbn19073 for ; Mon, 8 Jan 2001 10:51:19 GMT Received: from hercules.nj.broadi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.102.22.123]) id QQjxbn15976 for ; Mon, 8 Jan 2001 10:51:16 GMT Received: from 5 ([202.102.22.124]) by hercules.nj.broadi.com with Microsoft SMTPSVC(5.0.2195.1600); Sat, 8 Jan 2000 18:57:25 +0800 Date: Mon, 8 Jan 2001 18:54:20 +0800 From: Eric Miao To: "mpls@uu.net" Subject: Re: Re: Some questions(label space, NHLFE, ldp peers for an address prefix) X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 08 Jan 2000 10:57:25.0284 (UTC) FILETIME=[258A2E40:01BF59C7] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >Hi Eric, > >> 1. Label Space >> ============== >> >> 3.14. Scope and Uniqueness of Labels says >> >> In general, Rd can only tell whether it was Ru1 or Ru2 that put the >> particular label value L at the top of the label stack if the >> following conditions hold: >> >> - Ru1 and Ru2 are the only label distribution peers to which Rd >> ~~~~ >> distributed a binding of label value L, and >> - Ru1 and Ru2 are each directly connected to Rd via a point-to- >> ~~~~~~~~~ >> point interface. >> ~~~~~ >> >> When these conditions hold, an LSR may use labels that have "per >> interface" scope, i.e., which are only unique per interface. We may >> say that the LSR is using a "per-interface label space". When these >> conditions do not hold, the labels must be unique over the LSR which >> has assigned them, and we may say that the LSR is using a "per- >> platform label space." >> >> Why must Ru1 and Ru2 be only label distribution peers to which Rd distributed a >> binding of label value L, and be each directly connected to Rd via a p2p interface? >> > >You can think about this otherwise: >Rd distributes label "L". >{Ru1, Ru2, Ru3...RuN} is a set of upstream LSRs (peers of Rd). If Rd >has distributed the SAME label value "L" to all the LSRs in the set, when >a packet with label "L" arrives to Rd, Rd can determine which LSR in the >set sent the packet based on the interface the packet came through. Note >that this is possible only if each LSR in the set is connected to Rd by a >DIFFERENT interface. > > >> 2. NHLFE >> ======== >> >> 3.10. The Next Hop Label Forwarding Entry (NHLFE) says >> >> the operation to perform on the packet's label stack; this is >> one of the following operations: >> a) replace the label at the top of the label stack with a >> specified new label >> b) pop the label stack >> c) replace the label at the top of the label stack with a >> specified new label, and then push one or more specified > ^^^^ >> new labels onto the label stack. >> >> Since there is FEC to NHLFE map (FTN) which determines what label an unlabeled packet >> should be labeled with, why no PUSH operation in NHLFE. >> > >There is a push operation in (c). a) SWAP b) POP c) SWAP and PUSHes, not PUSHes > > > >Regards, > > Josue Eric Miao ericmiao@nj.broadi.com From owner-mpls@UU.NET Mon Jan 8 06:50:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29546 for ; Mon, 8 Jan 2001 06:50:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxbr04969; Mon, 8 Jan 2001 11:50:21 GMT Received: by mail-control.mail.uu.net id QQjxbr00905 for mpls-outgoing; Mon, 8 Jan 2001 11:49:50 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxbr00900 for ; Mon, 8 Jan 2001 11:49: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 QQjxbr25786 for ; Mon, 8 Jan 2001 11:49:35 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxbr10641 for ; Mon, 8 Jan 2001 11:49:34 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA19240 for mpls@uu.net; Mon, 8 Jan 2001 06:49:33 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxbr00880 for ; Mon, 8 Jan 2001 11:49: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 QQjxbr22820 for ; Mon, 8 Jan 2001 11:48:48 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjxbr16854 for ; Mon, 8 Jan 2001 11:48:48 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29533; Mon, 8 Jan 2001 06:48:44 -0500 (EST) Message-Id: <200101081148.GAA29533@ietf.org> To: IETF-Announce:; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: mpls@UU.NET From: The IESG Subject: Protocol Action: Carrying Label Information in BGP-4 to Proposed Standard Date: Mon, 08 Jan 2001 06:48:44 -0500 Sender: owner-mpls@UU.NET Precedence: bulk The IESG has approved the Internet-Draft 'Carrying Label Information in BGP-4' as a Proposed Standard. This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are David Oran and Rob Coltun. Technical Summary When BGP is used to distribute a particular route, it can be also be used to distribute an MPLS label which is mapped to that route This document specifies the way in which this is done. The label mapping information for a particular route is piggybacked in the same BGP Update message that is used to distribute the route itself. Working Group Summary The working group supported this document and no issues were raised during IETF Last-Call. Protocol Quality Rob Coltun has reviewed the spec for the IESG. There are multiple implementations of this technology. Note to RFC Editor: Yakpv Rekhter's contact information is not current. From owner-mpls@UU.NET Mon Jan 8 07:29:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00780 for ; Mon, 8 Jan 2001 07:29:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxbt07296; Mon, 8 Jan 2001 12:29:29 GMT Received: by mail-control.mail.uu.net id QQjxbt14886 for mpls-outgoing; Mon, 8 Jan 2001 12:29:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxbt14881 for ; Mon, 8 Jan 2001 12:29: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 QQjxbt21747 for ; Mon, 8 Jan 2001 12:29:02 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxbt06575 for ; Mon, 8 Jan 2001 12:29:02 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA20980 for mpls@uu.net; Mon, 8 Jan 2001 07:29:01 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxbt14847 for ; Mon, 8 Jan 2001 12:28:46 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 QQjxbt21553 for ; Mon, 8 Jan 2001 12:28:18 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjxbt11208 for ; Mon, 8 Jan 2001 12:28:18 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00511; Mon, 8 Jan 2001 07:28:16 -0500 (EST) Message-Id: <200101081228.HAA00511@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-lsr-mib-07.txt Date: Mon, 08 Jan 2001 07:28:16 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS Label Switch Router Management Information Base Using SMIv2 Author(s) : C. Srinivasan, A. Viswanathan, T. Nadeau Filename : draft-ietf-mpls-lsr-mib-07.txt Pages : 54 Date : 05-Jan-01 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling a Multi-Protocol Label Switching (MPLS) [MPLSArch, MPLSFW] Label Switch Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-lsr-mib-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-lsr-mib-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: <20010105145823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-lsr-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-lsr-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010105145823.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Mon Jan 8 11:18:26 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09218 for ; Mon, 8 Jan 2001 11:18:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxcj01466; Mon, 8 Jan 2001 16:16:22 GMT Received: by mail-control.mail.uu.net id QQjxcj22876 for mpls-outgoing; Mon, 8 Jan 2001 16:15:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxcj22870 for ; Mon, 8 Jan 2001 16:15:41 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 QQjxcj19717 for ; Mon, 8 Jan 2001 16:15:03 GMT Received: from mail.chiaro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: us.chiaro.com [63.88.196.33]) id QQjxcj00761 for ; Mon, 8 Jan 2001 16:15:02 GMT Received: by 128-101-236-84.chiaro.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Jan 2001 10:15:01 -0600 Message-ID: <2383E22BDFF6D311BB8400B0D021A5077AAD1A@128-101-236-84.chiaro.com> From: Steve Yao To: "'Josue Kuri'" , Eric Miao Cc: "mpls@uu.net" Subject: RE: Some questions(label space, NHLFE, ldp peers for an address p refix) Date: Mon, 8 Jan 2001 10:14:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Josue, I think your description is probably better and the first condition in the draft can be removed. - Steve > -----Original Message----- > From: Josue Kuri [mailto:kuri@infres.enst.fr] > Sent: Monday, January 08, 2001 2:42 AM > To: Eric Miao; > @cinna.enst.fr@cinna.enst.fr@cinna.enst.fr@cinna.enst.fr@cinna > .enst.fr@c > inna.enst.fr > Cc: mpls@uu.net; > @cinna.enst.fr@cinna.enst.fr@cinna.enst.fr@cinna.enst.fr@cinna > .enst.fr@c > inna.enst.fr > Subject: Re: Some questions(label space, NHLFE, ldp peers for > an address > prefix) > > > > Hi Eric, > > > 1. Label Space > > ============== > > > > 3.14. Scope and Uniqueness of Labels says > > > > In general, Rd can only tell whether it was Ru1 or Ru2 > that put the > > particular label value L at the top of the label stack if the > > following conditions hold: > > > > - Ru1 and Ru2 are the only label distribution peers > to which Rd > > ~~~~ > > distributed a binding of label value L, and > > - Ru1 and Ru2 are each directly connected to Rd via > a point-to- > > > ~~~~~~~~~ > > point interface. > > ~~~~~ > > > > When these conditions hold, an LSR may use labels that > have "per > > interface" scope, i.e., which are only unique per > interface. We may > > say that the LSR is using a "per-interface label > space". When these > > conditions do not hold, the labels must be unique over > the LSR which > > has assigned them, and we may say that the LSR is using a "per- > > platform label space." > > > > Why must Ru1 and Ru2 be only label distribution peers to > which Rd distributed a > > binding of label value L, and be each directly connected to > Rd via a p2p interface? > > > > You can think about this otherwise: > Rd distributes label "L". > {Ru1, Ru2, Ru3...RuN} is a set of upstream LSRs (peers of Rd). If Rd > has distributed the SAME label value "L" to all the LSRs in > the set, when > a packet with label "L" arrives to Rd, Rd can determine which > LSR in the > set sent the packet based on the interface the packet came > through. Note > that this is possible only if each LSR in the set is > connected to Rd by a > DIFFERENT interface. > > > > 2. NHLFE > > ======== > > > > 3.10. The Next Hop Label > Forwarding Entry (NHLFE) says > > > > the operation to perform on the packet's label stack; this is > > one of the following operations: > > a) replace the label at the top of the label stack with a > > specified new label > > b) pop the label stack > > c) replace the label at the top of the label stack with a > > specified new label, and then push one or more > specified > ^^^^ > > new labels onto the label stack. > > > > Since there is FEC to NHLFE map (FTN) which determines what > label an unlabeled packet > > should be labeled with, why no PUSH operation in NHLFE. > > > > There is a push operation in (c). > > > > Regards, > > Josue > ****************************************************************** This e-mail and any files transmitted with it are the property of Chiaro Networks, Ltd., and may contain confidential and privileged material for the sole use of the intended recipient(s) to whom this e-mail is addressed. If you are not one of the named recipient(s), or otherwise have reason to believe that you have received this message in error, please notify the sender and delete all copies from your system. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. ****************************************************************** From owner-mpls@UU.NET Mon Jan 8 11:34:01 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09828 for ; Mon, 8 Jan 2001 11:34:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxck27074; Mon, 8 Jan 2001 16:31:38 GMT Received: by mail-control.mail.uu.net id QQjxck24931 for mpls-outgoing; Mon, 8 Jan 2001 16:31:08 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxck24836 for ; Mon, 8 Jan 2001 16:30:52 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 QQjxck22569 for ; Mon, 8 Jan 2001 16:30:06 GMT Received: from workhorse.fictitious.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: workhorse.fictitious.org [209.66.129.230]) id QQjxck06103 for ; Mon, 8 Jan 2001 16:30:01 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 LAA24767; Mon, 8 Jan 2001 11:15:11 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200101081615.LAA24767@workhorse.fictitious.org> To: "Yi Chu" cc: curtis@avici.com, "Cheng-Yin Lee" , "Faisal S. Naik" , "mpls uunet" , zaziz@cisco.com, prasanna@csa.iisc.ernet.in Reply-To: curtis@avici.com Subject: Re: Some queries In-reply-to: Your message of "Fri, 05 Jan 2001 09:22:29 EST." <000501c07722$ef469e70$a0b7010a@winstar.com> Date: Mon, 08 Jan 2001 11:15:11 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <000501c07722$ef469e70$a0b7010a@winstar.com>, "Yi Chu" writes: > Please forgive me if my question is so obvious and maybe stupid, since I am > new to this discussion. > > Why 1000 nodes can have 10-15 adjacencies while IP over ATM needs 999 > adjacencies per node? I think IP over ATM uses ATM VC just as a physical > link, so there is no difference in adjacencies per node whether the routers > are connected through Sonet links or ATM VCs. > > So what is the reason that IP over ATM requires full VC mesh of all nodes? > > Yi Chu If you use ATM as a means of traffic engineering, you must apply a full mesh of VCs and allow ATM to route the VCs. If you use ATM solely as a link layer protocol, you can set up a much more limited set of VCs that correspond more closely to the physical topology, but ATM is no longer able to route the traffic. The traffic follows the set of hops dictated at layer 3. If you use MPLS, you get a control plane that maps directly onto the physical topology and therefore has less adjacecencies but you retrain the ability to traffic engineer from edge to edge. Curtis From owner-mpls@UU.NET Mon Jan 8 12:01:53 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10896 for ; Mon, 8 Jan 2001 12:01:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxcm04316; Mon, 8 Jan 2001 17:00:14 GMT Received: by mail-control.mail.uu.net id QQjxcl27742 for mpls-outgoing; Mon, 8 Jan 2001 16:59:51 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxcl27724 for ; Mon, 8 Jan 2001 16:59: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 QQjxcl28244 for ; Mon, 8 Jan 2001 16:58:55 GMT Received: from winstar.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fw-1.winstar.com [207.86.108.130]) id QQjxcl19727 for ; Mon, 8 Jan 2001 16:58:54 GMT Received: from vaawsh032382 (dhcp-vaa-1-183-160.winstar.com [10.1.183.160]) by winstar.com (8.9.3/8.9.1) with SMTP id LAA12880; Mon, 8 Jan 2001 11:43:32 -0500 (EST) From: "Yi Chu" To: Cc: "Cheng-Yin Lee" , "Faisal S. Naik" , "mpls uunet" , , Subject: RE: Some queries Date: Mon, 8 Jan 2001 11:40:33 -0500 Message-ID: <002c01c07991$b85bb2d0$a0b7010a@winstar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <200101081615.LAA24767@workhorse.fictitious.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ATM is a link layer protocol and should be treated as such. It can be stretched to support TE, to a limited fashion (region to region, e.g.). Full mesh of 1000 nodes is not the fault of ATM as a protocol, it is the failure of not doing proper capacity engineering, IMHO. yi -----Original Message----- From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] Sent: Monday, January 08, 2001 11:15 AM To: Yi Chu Cc: curtis@avici.com; Cheng-Yin Lee; Faisal S. Naik; mpls uunet; zaziz@cisco.com; prasanna@csa.iisc.ernet.in Subject: Re: Some queries In message <000501c07722$ef469e70$a0b7010a@winstar.com>, "Yi Chu" writes: > Please forgive me if my question is so obvious and maybe stupid, since I am > new to this discussion. > > Why 1000 nodes can have 10-15 adjacencies while IP over ATM needs 999 > adjacencies per node? I think IP over ATM uses ATM VC just as a physical > link, so there is no difference in adjacencies per node whether the routers > are connected through Sonet links or ATM VCs. > > So what is the reason that IP over ATM requires full VC mesh of all nodes? > > Yi Chu If you use ATM as a means of traffic engineering, you must apply a full mesh of VCs and allow ATM to route the VCs. If you use ATM solely as a link layer protocol, you can set up a much more limited set of VCs that correspond more closely to the physical topology, but ATM is no longer able to route the traffic. The traffic follows the set of hops dictated at layer 3. If you use MPLS, you get a control plane that maps directly onto the physical topology and therefore has less adjacecencies but you retrain the ability to traffic engineer from edge to edge. Curtis From owner-mpls@UU.NET Mon Jan 8 13:22:40 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12976 for ; Mon, 8 Jan 2001 13:22:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxcq20235; Mon, 8 Jan 2001 18:10:01 GMT Received: by mail-control.mail.uu.net id QQjxcq27484 for mpls-outgoing; Mon, 8 Jan 2001 18:09:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxcq27469 for ; Mon, 8 Jan 2001 18:09:22 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 QQjxcq07148 for ; Mon, 8 Jan 2001 18:09:06 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 QQjxcq18656 for ; Mon, 8 Jan 2001 18:09:04 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 NAA25298; Mon, 8 Jan 2001 13:01:39 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200101081801.NAA25298@workhorse.fictitious.org> To: "Yi Chu" cc: curtis@avici.com, "Cheng-Yin Lee" , "Faisal S. Naik" , "mpls uunet" , zaziz@cisco.com, prasanna@csa.iisc.ernet.in Reply-To: curtis@avici.com Subject: Re: Some queries In-reply-to: Your message of "Mon, 08 Jan 2001 11:40:33 EST." <002c01c07991$b85bb2d0$a0b7010a@winstar.com> Date: Mon, 08 Jan 2001 13:01:39 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <002c01c07991$b85bb2d0$a0b7010a@winstar.com>, "Yi Chu" writes: > ATM is a link layer protocol and should be treated as such. It can be > stretched to support TE, to a limited fashion (region to region, e.g.). > Full mesh of 1000 nodes is not the fault of ATM as a protocol, it is the > failure of not doing proper capacity engineering, IMHO. > > yi It is a reality for ISPs with 500-1,000 access routers. Since the 1,000 node full mesh would work really badly, ISPs break networks into 10s of regions, then they have on the order of a 100 node full mesh withing the region though flooding within the core becomes manageable. They also lose edge-to-edge TE capability that with hierarchical MPLS-TE they will get back (when hierarchical MPLS-TE is ready). As Vijay and Jim pointed out earlier, the limit of OC12c on router ATM interfaces caused this hierarchical plan to start to break down around 1997 or 1998, fueling a sense of urgency to replace ATM in the core. Curtis From owner-mpls@UU.NET Mon Jan 8 14:28:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14413 for ; Mon, 8 Jan 2001 14:28:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxcv19675; Mon, 8 Jan 2001 19:27:13 GMT Received: by mail-control.mail.uu.net id QQjxcv17621 for mpls-outgoing; Mon, 8 Jan 2001 19:26:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxcv17605 for ; Mon, 8 Jan 2001 19:26: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 QQjxcv29305 for ; Mon, 8 Jan 2001 19:26:27 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 QQjxcv14487 for ; Mon, 8 Jan 2001 19:26:27 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA09884 for ; Mon, 8 Jan 2001 11:26:37 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA20177 for mpls@uu.net; Mon, 8 Jan 2001 14:26:25 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxcr29002 for ; Mon, 8 Jan 2001 18:21: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 QQjxcr02762 for ; Mon, 8 Jan 2001 18:21:09 GMT Received: from 2KSRVR.POINTR.NET by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 97-34.pointreyesnet.com [209.133.97.34] (may be forged)) id QQjxcr07313 for ; Mon, 8 Jan 2001 18:21:09 GMT Received: by 2KSRVR.POINTR.NET with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Jan 2001 10:19:07 -0800 Message-ID: From: Lyndon Ong To: "'mpls@uu.net'" Subject: Re: Some Queries Date: Mon, 8 Jan 2001 10:19:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk ----- Original Message ----- From "Vijay Gill" > This approach is perfectly analogous to just buying point to point > circuits and gives up a very important feature that some ISPs currently > use ATM for - the ability to get constrained based routing, so as to do > effective automatic traffic engineering. > > To allow for automatic traffic engineering, some organizations terminate > their SONET handoffs into ATM switches and terminate routers into the ATM > switches as well. The ATM switches then talk amongst each other (various > levels of hierarchy go in here), and export a virtualized transport fabric > to the routers. The routers are then fully meshed with subinterfaces and > sPVCs to all the other routers in that particular area, such that no > router _transits_ another router. All routers appear to be directly > connected to each other, so that the IP traffic always takes what appears > to be the shortest path to any other router (a direct connection). > MPLS will also allow you to do this, essentially make a physical topology of multiple links look like a logical topology of a single link between router pairs so that IP always picks this as the shortest path. The IP part is "automatic", but how is the logical topology (ATM or MPLS) created? Is this through some offline tools and configuration, or done directly by switches? Cheers, L. Ong From owner-mpls@UU.NET Mon Jan 8 14:28:51 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14426 for ; Mon, 8 Jan 2001 14:28:51 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxcv15780; Mon, 8 Jan 2001 19:27:13 GMT Received: by mail-control.mail.uu.net id QQjxcv17618 for mpls-outgoing; Mon, 8 Jan 2001 19:26:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxcv17602 for ; Mon, 8 Jan 2001 19:26:30 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 QQjxcv27149 for ; Mon, 8 Jan 2001 19:25:32 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjxcv17296 for ; Mon, 8 Jan 2001 19:25:31 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA06728 for ; Mon, 8 Jan 2001 11:25:38 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA20168 for mpls@uu.net; Mon, 8 Jan 2001 14:25:30 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjwsx14192 for ; Sat, 6 Jan 2001 02:54: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 QQjwsx20178 for ; Sat, 6 Jan 2001 02:53:43 GMT Received: from web11901.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11901.mail.yahoo.com [216.136.172.185]) id QQjwsx05367 for ; Sat, 6 Jan 2001 02:53:42 GMT Message-ID: <20010106025342.23448.qmail@web11901.mail.yahoo.com> Received: from [63.113.148.3] by web11901.mail.yahoo.com; Fri, 05 Jan 2001 18:53:42 PST Date: Fri, 5 Jan 2001 18:53:42 -0800 (PST) From: Mahesh S Subject: Peer adjacenices over FA LSP To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk The LSP Heiearcht with MPLS TE draft (draft-kompella-lsp-heirarchy-00.txt) says that the FA lsp can be represented as a unnumbered or numbered point2point link It also says in section 4.2 that "It is expected that forwarding adjacencies will not be used for establishing ISIS/OSPF peering relation between the routers at the ends of the adjacency." RFC2328 section 12.4.1.1 says "If a point2point link is fully adjacent then advertise it as a type 1 link. in additon if the state is point2point advertise a stub link (type 3) to the neighboring router." If we are advertise the FA LSP as a stub link then this link will not be used to reach the routers connected to the tail end of the Forwarding LSP. But if we advertise it as a type 1 link,is it a violation of OSPF protocol, because of section 12.4.1.1? __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From owner-mpls@UU.NET Mon Jan 8 14:37:08 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14776 for ; Mon, 8 Jan 2001 14:37:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxcw28756; Mon, 8 Jan 2001 19:35:28 GMT Received: by mail-control.mail.uu.net id QQjxcw18490 for mpls-outgoing; Mon, 8 Jan 2001 19:35:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxcw18465 for ; Mon, 8 Jan 2001 19:34:53 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 QQjxcw14709 for ; Mon, 8 Jan 2001 19:34:47 GMT Received: from EX-IMC3-CORP.efi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns3.efi.com [192.68.228.82]) id QQjxcw06391 for ; Mon, 8 Jan 2001 19:34:47 GMT Received: from efi.com (lomme.efi.com [10.10.69.7]) by EX-IMC3-CORP.efi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Z5AXXV9W; Mon, 8 Jan 2001 11:34:46 -0800 Message-ID: <3A5A1619.D82ED099@efi.com> Date: Mon, 08 Jan 2001 11:33:45 -0800 From: Saurabh Shrivastava Organization: Electronics For Imaging Inc. X-Mailer: Mozilla 4.61 [en] (X11; U; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 CC: "mpls@uu.net" Subject: Re: Some questions(label space, NHLFE, ldp peers for an addressprefix) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I think, it should be stated like this - the LSR should make sure that when it recieves a packet, it can look at the label and the interface it was received from and know what to do with packet unambiguously. That is all. The standards should not enforce more rules. Now it is upto the LSR to decide how it can make this unambiguous decision - maybe with different labels/or with same labels on different interfaces/or LSR maynot wish to distinguish packets coming from different Ru's (so that the LSR in question has its job simplified)... Josue Kuri wrote: > > Hi Eric, > > > 1. Label Space > > ============== > > > > 3.14. Scope and Uniqueness of Labels says > > > > In general, Rd can only tell whether it was Ru1 or Ru2 that put the > > particular label value L at the top of the label stack if the > > following conditions hold: > > > > - Ru1 and Ru2 are the only label distribution peers to which Rd > > ~~~~ > > distributed a binding of label value L, and > > - Ru1 and Ru2 are each directly connected to Rd via a point-to- > > ~~~~~~~~~ > > point interface. > > ~~~~~ > > > > When these conditions hold, an LSR may use labels that have "per > > interface" scope, i.e., which are only unique per interface. We may > > say that the LSR is using a "per-interface label space". When these > > conditions do not hold, the labels must be unique over the LSR which > > has assigned them, and we may say that the LSR is using a "per- > > platform label space." > > > > Why must Ru1 and Ru2 be only label distribution peers to which Rd distributed a > > binding of label value L, and be each directly connected to Rd via a p2p interface? > > > > You can think about this otherwise: > Rd distributes label "L". > {Ru1, Ru2, Ru3...RuN} is a set of upstream LSRs (peers of Rd). If Rd > has distributed the SAME label value "L" to all the LSRs in the set, when > a packet with label "L" arrives to Rd, Rd can determine which LSR in the > set sent the packet based on the interface the packet came through. Note > that this is possible only if each LSR in the set is connected to Rd by a > DIFFERENT interface. > > > 2. NHLFE > > ======== > > > > 3.10. The Next Hop Label Forwarding Entry (NHLFE) says > > > > the operation to perform on the packet's label stack; this is > > one of the following operations: > > a) replace the label at the top of the label stack with a > > specified new label > > b) pop the label stack > > c) replace the label at the top of the label stack with a > > specified new label, and then push one or more specified > ^^^^ > > new labels onto the label stack. > > > > Since there is FEC to NHLFE map (FTN) which determines what label an unlabeled packet > > should be labeled with, why no PUSH operation in NHLFE. > > > > There is a push operation in (c). > > Regards, > > Josue -- -------------------------------------------------------------------- Wisdom has 2 parts: Having a lot to say, Not Saying Anything Saurabh Shrivastava Saurabh.Shrivastava@efi.com Electronics for Imaging 650.357.3820 (office-direct) http://www.efi.com/ 650.592.2634 (residence) -------------------------------------------------------------------- From owner-mpls@UU.NET Mon Jan 8 14:48:12 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15016 for ; Mon, 8 Jan 2001 14:48:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxcx17467; Mon, 8 Jan 2001 19:46:28 GMT Received: by mail-control.mail.uu.net id QQjxcx19707 for mpls-outgoing; Mon, 8 Jan 2001 19:45:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxcx19701 for ; Mon, 8 Jan 2001 19:45: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 QQjxcw13604 for ; Mon, 8 Jan 2001 19:44:05 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjxcw13970 for ; Mon, 8 Jan 2001 19:44:04 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA08952; Mon, 8 Jan 2001 11:44:04 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id LAA11326; Mon, 8 Jan 2001 11:43:37 -0800 (PST) Date: Mon, 8 Jan 2001 11:43:37 -0800 (PST) From: Kireeti Kompella Message-Id: <200101081943.LAA11326@kummer.juniper.net> To: mpls@UU.NET, smaheshus@yahoo.com Subject: Re: Peer adjacenices over FA LSP In-Reply-To: <20010106025342.23448.qmail@web11901.mail.yahoo.com> Sender: owner-mpls@UU.NET Precedence: bulk > RFC2328 section 12.4.1.1 says > "If a point2point link is fully adjacent then > advertise it as a type 1 link. in additon if the > state is point2point advertise a stub link (type 3) to > the neighboring router." > > If we are advertise the FA LSP as a stub link then > this link will not be used to reach the routers > connected to the tail end of the Forwarding LSP. > > But if we advertise it as a type 1 link,is it a > violation of OSPF protocol, because of section > 12.4.1.1? The draft says to advertise the FA as a *TE* link, not as a regular link. RFC2328 does not apply. However, one could very well advertise an LSP as a regular link, as a generalization of Henk's TE shortcuts (will be mentioned in the next version of the draft). In that case, I would advertise it as a type 1 link. I am not sure that this is indeed a violation of the spec, but if it is, so be it. Kireeti. From owner-mpls@UU.NET Mon Jan 8 15:55:55 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16567 for ; Mon, 8 Jan 2001 15:55:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxdb23137; Mon, 8 Jan 2001 20:54:30 GMT Received: by mail-control.mail.uu.net id QQjxdb07499 for mpls-outgoing; Mon, 8 Jan 2001 20:53:55 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxdb07483 for ; Mon, 8 Jan 2001 20:53:45 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 QQjxdb07670 for ; Mon, 8 Jan 2001 20:53:35 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjxdb26203 for ; Mon, 8 Jan 2001 20:53:34 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 PAA20582 for ; Mon, 8 Jan 2001 15:06:18 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA27214 for ; Mon, 8 Jan 2001 15:06:19 -0500 (EST) Message-ID: <3A5A1DE4.8CC860@marconi.com> Date: Mon, 08 Jan 2001 15:07:00 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: Some Queries References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lyndon Ong wrote: > > ... how is the logical topology (ATM or MPLS) created? Is this > through some offline tools and configuration, or done directly > by switches? There are two common ways: 1: Each switch can have its forwarding tables hand-configured (or via an external network management package). In the ATM world, this is how PVC's (permenant virtual circuits) are created. 2: The network can be given a list of endpoints for the virtual circuits and let the switches set up the actual circuits via a routing and signalling protocol. In the ATM world, this is the SPVC (signalled PVC), using PNNI for a routing protocol and UNI/NNI as a signalling protocol. In the MPLS world, it would use an IGP (like OSPF or ISIS) as the routing protocol and an IP signalling protocol (like RSVP or LDP.) There are other ways as well. For instance, ATM supports SVCs (signalled VC) which are created on-demand by edge hosts/routers and are torn down by those hosts/routers when no longer needed. This would not be a good idea in an ISP's core, but is often used in enterprise networks. -- David From owner-mpls@UU.NET Mon Jan 8 16:45:41 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17230 for ; Mon, 8 Jan 2001 16:45:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxde02030; Mon, 8 Jan 2001 21:44:02 GMT Received: by mail-control.mail.uu.net id QQjxde24352 for mpls-outgoing; Mon, 8 Jan 2001 21:43:29 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxde24340 for ; Mon, 8 Jan 2001 21:43: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 QQjxde25310 for ; Mon, 8 Jan 2001 21:43:04 GMT Received: from mx3out.umbc.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx3out.umbc.edu [130.85.253.53]) id QQjxde00668 for ; Mon, 8 Jan 2001 21:43:04 GMT Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx3out.umbc.edu (8.9.3/8.9.3) with ESMTP id QAA05909; Mon, 8 Jan 2001 16:43:03 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id QAA495948; Mon, 8 Jan 2001 16:43:02 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Mon, 8 Jan 2001 16:43:02 -0500 From: Vijay Gill X-Sender: vijay@irix2.gl.umbc.edu To: Lyndon Ong cc: "'mpls@uu.net'" Subject: Re: Some Queries In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 8 Jan 2001, Lyndon Ong wrote: > MPLS will also allow you to do this, essentially make a physical > topology of multiple links look like a logical topology of a single > link between router pairs so that IP always picks this as the shortest > path. Whilst I would be the first to say that MPLS has its place, it is far from being a protocol that can solve all problems for all people, unlike the perception that is being foisted upon the world by the marketing departments (hardware vendors AND service providers are both guilty of this). Here is a small illustration of why MPLS will also NOT allow us to do this with the same cleanliness (in the ip portion of things) as Frame or ATM. One of the problems with MPLS is the fact that most documents and "high level" overviews show something like an edge-to-edge mpls LSP setup. Like so: ---[rtr1]--- -------[rtr4] / \ / | [rtr2]-----lsp------[rtr3]---lsp-+ Which makes for all sorts of easy to design networks. Reality unfortunately, tends not to care too much about fitting into neat marketing diagrams and looks something much like this: /---[rtr]--[edge] * 200-300 more of these. {huge glob of networking}---[rtr]---/ | | | | [rtr]----[rtr] [rtr] [rtr] \ / \ / \ / \ / [edge] [edge] Now, how do you run an LSP from the edge to the upper level clouds? Where do you terminate them? Do you go edge-to-edge (causing a full mesh explosion of state in your network?) 700 edge device networks are common, and they all have multiple uplinks. Do we go with two LSPs from every edge device to every OTHER edge device so we can use both uplinks effectively? Then we start to add hierarchy here. One design being the lets mesh the aggregation routers instead of the edge routers. Problem with that design is that now the MPLS domain does not go all the way to the edge, causing the edge to slosh ip traffic flows based on topology changes inside your network, causing your bandwidth settings on LSPS to fail miserably, as traffic may now start traversing LSPs which were previously (thanks to the wonders of SPF) never loaded, thus the automatic TE scripts set their reserved bandwidth to 0. The same issue arises when you have regionalized meshing. As soon as you break away from the edge-edge full mesh model, you introduce a discontinuity into the mpls/igp domain, causing traffic flows to slosh around unexpectedly in responses to topology changes, invalidating your schemas, and your neat bandwidth reservations. Not all is lost here, given sufficient planning and small enough flows, most of these can be worked around. The key thing to take away is that automatically saying technology XXX will do what technology YYY did is not necessarily a valid statement. > The IP part is "automatic", but how is the logical topology (ATM or > MPLS) created? Is this through some offline tools and configuration, > or done directly by switches? There are multiple ways to do this. /vijay From owner-mpls@UU.NET Mon Jan 8 17:39:28 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17982 for ; Mon, 8 Jan 2001 17:39:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxdi03837; Mon, 8 Jan 2001 22:35:19 GMT Received: by mail-control.mail.uu.net id QQjxdi10218 for mpls-outgoing; Mon, 8 Jan 2001 22:34:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxdi10213 for ; Mon, 8 Jan 2001 22:34: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 QQjxdi10590 for ; Mon, 8 Jan 2001 22:33:46 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjxdi01796 for ; Mon, 8 Jan 2001 22:33:46 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id OAA19893; Mon, 8 Jan 2001 14:33:28 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id OAA12544; Mon, 8 Jan 2001 14:33:27 -0800 (PST) Date: Mon, 8 Jan 2001 14:33:27 -0800 (PST) From: Kireeti Kompella Message-Id: <200101082233.OAA12544@kummer.juniper.net> To: long@pointreyesnet.com, vijay@umbc.edu Subject: Re: Some Queries Cc: mpls@UU.NET In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Hi Vijay, > Then we start to add hierarchy here. One design being the lets mesh the > aggregation routers instead of the edge routers. Problem with that design > is that now the MPLS domain does not go all the way to the edge, causing > the edge to slosh ip traffic flows based on topology changes inside your > network, causing your bandwidth settings on LSPS to fail miserably, as > traffic may now start traversing LSPs which were previously (thanks to the > wonders of SPF) never loaded, thus the automatic TE scripts set their > reserved bandwidth to 0. So you advertise the LSPs into your SPF, and give them a fixed metric. Now your SPFs behave: end of slosh. (Confess!) > The key thing to take away is that > automatically saying technology XXX will do what technology YYY did is not > necessarily a valid statement. Excellent point. Explicitly: ATM is not MPLS; MPLS is not ATM. They are close in many respects, but not identical. Kireeti. From owner-mpls@UU.NET Mon Jan 8 18:05:11 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18309 for ; Mon, 8 Jan 2001 18:05:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxdk21125; Mon, 8 Jan 2001 23:04:09 GMT Received: by mail-control.mail.uu.net id QQjxdk00061 for mpls-outgoing; Mon, 8 Jan 2001 23:03:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxdk29944 for ; Mon, 8 Jan 2001 23:03:22 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 QQjxdk17275 for ; Mon, 8 Jan 2001 23:00:08 GMT Received: from mx1out.umbc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx1out.umbc.edu [130.85.253.51]) id QQjxdk06498 for ; Mon, 8 Jan 2001 23:00:08 GMT Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx1out.umbc.edu (8.9.3/8.9.3) with ESMTP id SAA24750; Mon, 8 Jan 2001 18:00:07 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id SAA557802; Mon, 8 Jan 2001 18:00:06 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Mon, 8 Jan 2001 18:00:06 -0500 From: Vijay Gill X-Sender: vijay@irix2.gl.umbc.edu To: Kireeti Kompella cc: long@pointreyesnet.com, mpls@UU.NET Subject: Re: Some Queries In-Reply-To: <200101082233.OAA12544@kummer.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 8 Jan 2001, Kireeti Kompella wrote: > Hi Vijay, > > > traffic may now start traversing LSPs which were previously (thanks to the > > wonders of SPF) never loaded, thus the automatic TE scripts set their > > reserved bandwidth to 0. > > So you advertise the LSPs into your SPF, and give them a fixed metric. > Now your SPFs behave: end of slosh. (Confess!) I do not have any idea what you are talking about it. No one saw me do it, I deny _all_ knowledge of such heinous hacks. > > The key thing to take away is that > > automatically saying technology XXX will do what technology YYY did is not > > necessarily a valid statement. > > Excellent point. Explicitly: ATM is not MPLS; MPLS is not ATM. > They are close in many respects, but not identical. vijay "plausible deniability" gill From owner-mpls@UU.NET Mon Jan 8 20:32:38 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19466 for ; Mon, 8 Jan 2001 20:32:37 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxdt26488; Tue, 9 Jan 2001 01:29:35 GMT Received: by mail-control.mail.uu.net id QQjxdt21520 for mpls-outgoing; Tue, 9 Jan 2001 01:29:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxdt21511 for ; Tue, 9 Jan 2001 01:28:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjxdt13118 for ; Tue, 9 Jan 2001 01:28:25 GMT Received: from roam.psg.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mg-206253202-57.ricochet.net [206.253.202.57]) id QQjxdt19700 for ; Tue, 9 Jan 2001 01:28:23 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14FlwM-000MdV-00; Mon, 08 Jan 2001 15:43:02 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Lee, Cheng-Yin [CAR:0C40:EXCH]" Cc: mpls@UU.NET Subject: Re: Some queries References: <3A59FCC9.2C5ECE2A@nortelnetworks.com> Message-Id: Date: Mon, 08 Jan 2001 15:43:02 -0800 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >>> Do you mean to say SPs such as large/national ISPs use ATMs on the backbone >>> and have complete mesh with DS3/OC-3/OC-12 links >> no, complete mesh of vcs over semi-meshed physical circuits > What is the main reason for using a complete mesh of VCs? personally, i think of it as diseased. but some folk do engineering in a city-pair matrix, and like to pseud-provision analogously. sorry, i was unable to read the rest of your message. randy > > > Randy, >

Randy Bush wrote: >

> 
> Do you mean to say SPs such as large/national ISPs use ATMs on the backbone
>> and have complete mesh with DS3/OC-3/OC-12 links 
> 
> no, complete mesh of vcs over semi-meshed physical circuits
>
> >


What is the main reason for using a complete mesh of VCs? >

thanks, >
cyl From owner-mpls@UU.NET Tue Jan 9 03:34:49 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07765 for ; Tue, 9 Jan 2001 03:34:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxew20063; Tue, 9 Jan 2001 08:33:42 GMT Received: by mail-control.mail.uu.net id QQjxew19248 for mpls-outgoing; Tue, 9 Jan 2001 08:33:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxew19240 for ; Tue, 9 Jan 2001 08:33: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 QQjxew19000 for ; Tue, 9 Jan 2001 08:32:02 GMT Received: from infres.enst.fr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: infres.enst.fr [137.194.160.3]) id QQjxew17992 for ; Tue, 9 Jan 2001 08:32:01 GMT Received: from cinna.enst.fr (cinna.enst.fr [137.194.192.5]) by infres.enst.fr (Postfix) with ESMTP id 9085545409; Tue, 9 Jan 2001 09:31:54 +0100 (MET) Received: from localhost (kuri@localhost) by cinna.enst.fr (8.9.3+Sun/8.9.1) with SMTP id JAA05544; Tue, 9 Jan 2001 09:31:53 +0100 (MET) Date: Tue, 9 Jan 2001 09:31:53 +0100 (MET) From: Josue Kuri To: Saurabh Shrivastava Cc: "mpls@uu.net" Subject: Re: Some questions(label space, NHLFE, ldp peers for an addressprefix) In-Reply-To: <3A5A1619.D82ED099@efi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi Saurabh, > I think, it should be stated like this - the LSR should make sure that > when it recieves a packet, it can look at the label and the interface it > was received from and know what to do with packet unambiguously. That is > all. The standards should not enforce more rules. > > Now it is upto the LSR to decide how it can make this unambiguous decision > - maybe with different labels/or with same labels on different interfaces/or LSR > maynot wish to distinguish packets coming from different Ru's (so that > the LSR in question has its job simplified)... > > The statement in the draft just points out the _necessary_ conditions for the label to be correctly interpreted (i.e., it is not enforcing superfluous conditions). Stating the conditions differently to better understand them doesn't change the content. Regards, Josue > > 3.14. Scope and Uniqueness of Labels says > > In general, Rd can only tell whether it was Ru1 or Ru2 that put the > particular label value L at the top of the label stack if the > following conditions hold: > > - Ru1 and Ru2 are the only label distribution peers to which Rd > ~~~~ > distributed a binding of label value L, and > - Ru1 and Ru2 are each directly connected to Rd via a point-to- > ~~~~~~~~~ > point interface. > ~~~~~ > > When these conditions hold, an LSR may use labels that have "per > interface" scope, i.e., which are only unique per interface. We may > say that the LSR is using a "per-interface label space". When these > conditions do not hold, the labels must be unique over the LSR which > has assigned them, and we may say that the LSR is using a "per- > platform label space." > > Why must Ru1 and Ru2 be only label distribution peers to which Rd distributed a > binding of label value L, and be each directly connected to Rd via a p2p interface? > > > You can think about this otherwise: > Rd distributes label "L". > {Ru1, Ru2, Ru3...RuN} is a set of upstream LSRs (peers of Rd). If Rd > has distributed the SAME label value "L" to all the LSRs in the set, when > a packet with label "L" arrives to Rd, Rd can determine which LSR in the > set sent the packet based on the interface the packet came through. Note > that this is possible only if each LSR in the set is connected to Rd by a > DIFFERENT interface. > From owner-mpls@UU.NET Tue Jan 9 04:30:59 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08038 for ; Tue, 9 Jan 2001 04:30:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxez14250; Tue, 9 Jan 2001 09:17:50 GMT Received: by mail-control.mail.uu.net id QQjxez04674 for mpls-outgoing; Tue, 9 Jan 2001 09:17:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxez04663 for ; Tue, 9 Jan 2001 09:17:09 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 QQjxez17191 for ; Tue, 9 Jan 2001 09:15:12 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxez27688 for ; Tue, 9 Jan 2001 09:15:08 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id EAA06192 for mpls@uu.net; Tue, 9 Jan 2001 04:15:07 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxey04194 for ; Tue, 9 Jan 2001 09:14: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 QQjxey00126 for ; Tue, 9 Jan 2001 09:14:43 GMT Received: from shell-beach.layer8.net by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: black-3.dsl.speakeasy.net [216.231.56.189]) id QQjxey27162 for ; Tue, 9 Jan 2001 09:14:42 GMT Received: (qmail 26696 invoked by uid 1000); 9 Jan 2001 09:09:43 -0000 Date: Tue, 9 Jan 2001 01:09:43 -0800 From: Ben Black To: Josue Kuri Cc: Saurabh Shrivastava , "mpls@uu.net" Subject: Re: Some questions(label space, NHLFE, ldp peers for an addressprefix) Message-ID: <20010109010943.B18350@layer8.net> References: <3A5A1619.D82ED099@efi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kuri@infres.enst.fr on Tue, Jan 09, 2001 at 09:31:53AM +0100 Sender: owner-mpls@UU.NET Precedence: bulk On Tue, Jan 09, 2001 at 09:31:53AM +0100, Josue Kuri wrote: > > The statement in the draft just points out the _necessary_ conditions for > the label to be correctly interpreted (i.e., it is not enforcing > superfluous conditions). Stating the conditions differently to better > understand them doesn't change the content. > Actually, the draft says that the labels MUST be unique, it doesn't merely state conditions. I agree that the draft is overly restrictive in this regard, but it seems rather likely that, once again, the draft process will be railroaded and no improvements will be made. Ben From owner-mpls@UU.NET Tue Jan 9 11:35:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15704 for ; Tue, 9 Jan 2001 11:35:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgc03698; Tue, 9 Jan 2001 16:33:56 GMT Received: by mail-control.mail.uu.net id QQjxgc05881 for mpls-outgoing; Tue, 9 Jan 2001 16:33:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxgc05873 for ; Tue, 9 Jan 2001 16:33:18 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 QQjxgc06601 for ; Tue, 9 Jan 2001 16:33:04 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 QQjxgc24188 for ; Tue, 9 Jan 2001 16:33:03 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA11992 for ; Tue, 9 Jan 2001 08:33:14 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA23090 for mpls@uu.net; Tue, 9 Jan 2001 11:33:02 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxev18703 for ; Tue, 9 Jan 2001 08:27:01 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 QQjxev12626 for ; Tue, 9 Jan 2001 08:26:19 GMT Received: from zcars04f.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQjxev10411 for ; Tue, 9 Jan 2001 08:26:18 GMT Received: from zmers013 (actually zmers013.ca.nortel.com) by zcars04f.ca.nortel.com; Mon, 8 Jan 2001 12:42:54 -0500 Received: from nortelnetworks.com (actually pcarh00f.ca.nortel.com) by zmers013; Mon, 8 Jan 2001 12:42:40 -0500 Message-ID: <3A59FCC9.2C5ECE2A@nortelnetworks.com> Date: Mon, 08 Jan 2001 12:45:45 -0500 From: "Lee, Cheng-Yin [CAR:0C40:EXCH]" X-Mailer: Mozilla 4.72 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: randy@psg.com CC: mpls@UU.NET Subject: Re: Some queries Content-Type: multipart/alternative; boundary="------------5C2B36F002870E8D0FD698E1" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk --------------5C2B36F002870E8D0FD698E1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy, Randy Bush wrote: > > Do you mean to say SPs such as large/national ISPs use ATMs on the backbone > > and have complete mesh with DS3/OC-3/OC-12 links > > no, complete mesh of vcs over semi-meshed physical circuits > What is the main reason for using a complete mesh of VCs? thanks, cyl --------------5C2B36F002870E8D0FD698E1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Randy,

Randy Bush wrote: 

> Do you mean to say SPs such as large/national ISPs use ATMs on the backbone
> and have complete mesh with DS3/OC-3/OC-12 links 

no, complete mesh of vcs over semi-meshed physical circuits


What is the main reason for using a complete mesh of VCs?

thanks,
cyl --------------5C2B36F002870E8D0FD698E1-- From owner-mpls@UU.NET Tue Jan 9 11:36:38 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15744 for ; Tue, 9 Jan 2001 11:36:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgc26798; Tue, 9 Jan 2001 16:34:57 GMT Received: by mail-control.mail.uu.net id QQjxgc05951 for mpls-outgoing; Tue, 9 Jan 2001 16:34:36 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxgc05934 for ; Tue, 9 Jan 2001 16:34: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 QQjxgc06961 for ; Tue, 9 Jan 2001 16:33:14 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 QQjxgc24394 for ; Tue, 9 Jan 2001 16:33:13 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA12112 for ; Tue, 9 Jan 2001 08:33:23 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA23094 for mpls@uu.net; Tue, 9 Jan 2001 11:33:12 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxez05582 for ; Tue, 9 Jan 2001 09:27:49 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 QQjxez21936 for ; Tue, 9 Jan 2001 09:27:45 GMT Received: from siso_server.samsung.co.kr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.244.212.254]) id QQjxez13056 for ; Tue, 9 Jan 2001 09:27:43 GMT Received: by SISO_SERVER with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 14:58:36 +0530 Message-ID: From: Murahari To: "'mpls@uu.net'" Cc: "'cisco-nsp@puck.nether.net'" Subject: Label stacking Date: Tue, 9 Jan 2001 14:58:29 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk > Hi, In normal ATM network(with MPLS support), how are push and pop operations performed on third label(assuming that the stack depth is 3)? Will this label be part of 48byte data field of ATM cell? If so, how to apply switching operations on that label?(as per my understanding, there is no copying of labels from shim header to VPI/VCI fields) > Murahari > From owner-mpls@UU.NET Tue Jan 9 11:37:45 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15774 for ; Tue, 9 Jan 2001 11:37:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgc06892; Tue, 9 Jan 2001 16:36:07 GMT Received: by mail-control.mail.uu.net id QQjxgc06004 for mpls-outgoing; Tue, 9 Jan 2001 16:35:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxgc05986 for ; Tue, 9 Jan 2001 16:35:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjxgc04256 for ; Tue, 9 Jan 2001 16:33:38 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 QQjxgc24962 for ; Tue, 9 Jan 2001 16:33:37 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA12301 for ; Tue, 9 Jan 2001 08:33:42 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA23098 for mpls@uu.net; Tue, 9 Jan 2001 11:33:31 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxfb08311 for ; Tue, 9 Jan 2001 09:58: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 QQjxfb27291 for ; Tue, 9 Jan 2001 09:57:38 GMT Received: from gorilla.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQjxfb22082 for ; Tue, 9 Jan 2001 09:57:37 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA25353; Tue, 9 Jan 2001 10:57:19 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA17997; Tue, 9 Jan 2001 10:57:20 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 10:57:18 +0100 Message-ID: From: Hummel Heinrich To: "'George Swallow'" , mpls@UU.NET Subject: RE: Last call on MPLS multicast framework Date: Tue, 9 Jan 2001 10:57:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk TTL, see Section 2 and 10.1 in draft-ietf-mpls-multicast-04.txt: There cannot be an endless looping LSP as the IP-Header of LSP-setup messages have a TTL. So why is the TTL field part of the classical label at all? And why these tears about the lack of a TTL field in ATM/FR labels ? For the same reason:Scoping of Multicast does not need the TTL-field in the label. It is enough if the JOIN or SUBSCRIBE message has a TTL field in the IP-header. While I think the TTL in the label is superfluous, I miss a Multicast-Bit in the label. In the ATM Forum we had a lot of discussions whether we can assume that each ATM switch is capable to branch, i.e. can support multiple oifs. With respect to MPLS-hardware: Is every NHLFE prepared to have multiple oifs/outgoing labels? If there is no Multicast-Bit inside the label of each incoming label-switched packet, then this bit somehow must be part of each NHLFE. In PNNI a Multicast-branch bit was advertised by each ATM-switch,IMHO redundantly, because all people assumed that any ATM-Switch provides branching-capable hardware. Well this is good news for ATM-LSRs:they all can branch. But how is the situation with LSRs that support the 32-bit label? Can we assume that each of them is capable to branch or do we have to assume that in a Multicast-LSP some LSRs are branching-capable while others aren't and that for this reason we have to make sure to add new branches only at branching-capable LSRs ? There is much more to say technically about MPLS Multicast. Politically: I don't think there is a MPLS Multicast yet. Version 04 is equal to version 01. In Orlando a first VPN BOF failed whereby one argument was "let's do basics like Multicast first before we move on to higher applications like MPLS VPN". Well, it turned out differently :-)( Heinrich Hummel Siemens AG > This message begins a workgroup last call on > draft-ietf-mpls-multicast-04.txt, "Framework for IP Multicast in MPLS" > > The last call ends Jan 19, 5pm est. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > From owner-mpls@UU.NET Tue Jan 9 11:38:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15802 for ; Tue, 9 Jan 2001 11:38:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgc29481; Tue, 9 Jan 2001 16:36:27 GMT Received: by mail-control.mail.uu.net id QQjxgc06042 for mpls-outgoing; Tue, 9 Jan 2001 16:35:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxgc06006 for ; Tue, 9 Jan 2001 16:35:35 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjxgc04608 for ; Tue, 9 Jan 2001 16:34:55 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjxgc05283 for ; Tue, 9 Jan 2001 16:34:55 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA17014 for ; Tue, 9 Jan 2001 08:35:01 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA23104 for mpls@uu.net; Tue, 9 Jan 2001 11:34:54 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxff24451 for ; Tue, 9 Jan 2001 10:50:04 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 QQjxff00317 for ; Tue, 9 Jan 2001 10:49:58 GMT Received: from radmail.rad.co.il by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [192.116.244.108]) id QQjxff23320 for ; Tue, 9 Jan 2001 10:49:49 GMT Received: from vine ([192.168.254.52]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with SMTP id il; Tue, 9 Jan 2001 11:52:09 +0200 From: "Sasha Vainshtein" To: Cc: "Alik" , "mpls@uu.net" Subject: Requirement for LDP support in the RFC2547bis draft Date: Tue, 9 Jan 2001 12:52:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C07A3B.0EEFA760" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C07A3B.0EEFA760 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit Dear Mr. Rosen, I an relatively new to the discussions in the MPLS WG, and I would highly appreciate some explanation on the following subject: The original RFC2547 does not mention LDP at all. However, its proposed update, draft-rosen-rfc2547bis-02.txt, refers to LDP in two places: a.. In section 4.3.2. "Route Distribution Among PEs by BGP", it states: Note that the use of BGP-distributed MPLS labels is only possible if there is a label switched path between the PE router that installs the BGP-distributed route and PE router which is the BGP next hop of that route... All that matters for the VPN architecture is that some label switched path between the router and its BGP next hop exists. However, to ensure interoperability among systems which implement this VPN architecture, all such systems must support LDP b.. In section 5, "Forwarding Across the Backbone", it states: To ensure interoperability among different implementations, it is required to support LDP for setting up the label switched paths across the backbone. However, other methods of setting up these label switched paths are also possible . I assume that in both cases the LSPs in question are the paths for the outer (i.e., PE-to-PE) level encapsulation, and that requirement for LDP support states from the fact that such a support would gurantee ability to create such an LSP, e.g., by requesting a label for the egress PE IP address (known to the ingress PE as the BGP next hop) in a standard way. Is this assumption correct? If this is the case, do the two quotations actually refer to the same problem and its solution? I would also like to understand the subtle difference between the (lower case) "must" in the quoted sections of draft-rosen-rfc2547bis-02.txt and the (capitalized keyword) MUST described in RFC2119. ______________________________________________ With best regards, Sasha Vainshtein mailto: sasha@axerra.com phone: +972-3-7659993 (office) fax: +972-3-6487779 (office) ------=_NextPart_000_0063_01C07A3B.0EEFA760 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Dear = Mr.=20 Rosen,
I an = relatively=20 new to the discussions in the MPLS WG, and I would highly appreciate = some=20 explanation on the following subject:
The original=20 RFC2547 does not = mention=20 LDP at all.
However, its=20 proposed update, draft-rosen-rfc2547bis-02.txt, refers to LDP in two = places:
  • In section=20 4.3.2. "Route Distribution Among PEs by BGP", it=20 states:<quote> Note that the use = of=20 BGP-distributed MPLS labels is only possible if there is a = label=20 switched path between the PE router that installs the = BGP-distributed=20 route and PE router which is the BGP next hop of that route...=20 <skip> All = that matters=20 for the VPN architecture is that some label switched path = between the=20 router and its BGP next hop exists.  However, to ensure=20 interoperability among systems which implement this VPN = architecture,=20 all such systems must support LDP=20 <end quote>
  • In section 5,=20 "Forwarding Across the Backbone", it states:=20 <quote> To ensure interoperability = among=20 different implementations, it is required to support LDP for = setting=20 up the label switched paths across the backbone.  = However, other=20 methods of setting up these label switched paths are also = possible=20 <end quote>.
I = assume that in=20 both cases the LSPs in question are the paths for the outer (i.e., = PE-to-PE)=20 level encapsulation, and that requirement for LDP support states = from the=20 fact that such a support would gurantee ability to create such = an LSP,=20 e.g., by requesting a label for the egress PE IP address (known = to the=20 ingress PE as the BGP next hop) in a standard way. Is=20 this assumption correct? If this is the case, do the two = quotations=20 actually refer to the same problem and its = solution?
I = would also=20 like to understand the subtle difference between the (lower case)=20 "must" in the quoted sections of draft-rosen-rfc2547bis-02.txt = and=20 the (capitalized keyword) MUST described in=20 RFC2119.
______________________________________________
With best regards,
Sasha = Vainshtein
mailto: = sasha@axerra.com
phone: = +972-3-7659993=20 (office)
fax:      +972-3-6487779 = (office)
 
------=_NextPart_000_0063_01C07A3B.0EEFA760-- From owner-mpls@UU.NET Tue Jan 9 12:36:54 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17921 for ; Tue, 9 Jan 2001 12:36:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgg21327; Tue, 9 Jan 2001 17:35:16 GMT Received: by mail-control.mail.uu.net id QQjxgg22350 for mpls-outgoing; Tue, 9 Jan 2001 17:34:46 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxgg22345 for ; Tue, 9 Jan 2001 17:34:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjxgg05730 for ; Tue, 9 Jan 2001 17:34:31 GMT Received: from winstar.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fw-1.winstar.com [207.86.108.130]) id QQjxgg20671 for ; Tue, 9 Jan 2001 17:34:26 GMT Received: from vaawsh032382 (dhcp-vaa-1-183-160.winstar.com [10.1.183.160]) by winstar.com (8.9.3/8.9.1) with SMTP id MAA13208; Tue, 9 Jan 2001 12:32:54 -0500 (EST) From: "Yi Chu" To: "Randy Bush" , "Lee, Cheng-Yin [CAR:0C40:EXCH]" Cc: Subject: RE: Some queries Date: Tue, 9 Jan 2001 12:29:54 -0500 Message-ID: <001801c07a61$c79067c0$a0b7010a@winstar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit One can do engineering planning in a city-pair matrix, but one does not have to provision this way. This is where I disagree that full mesh is a disease of ATM as a protocol. I see it as something out of laziness of planning. yi -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Randy Bush Sent: Monday, January 08, 2001 6:43 PM To: Lee, Cheng-Yin [CAR:0C40:EXCH] Cc: mpls@UU.NET Subject: Re: Some queries >>> Do you mean to say SPs such as large/national ISPs use ATMs on the backbone >>> and have complete mesh with DS3/OC-3/OC-12 links >> no, complete mesh of vcs over semi-meshed physical circuits > What is the main reason for using a complete mesh of VCs? personally, i think of it as diseased. but some folk do engineering in a city-pair matrix, and like to pseud-provision analogously. sorry, i was unable to read the rest of your message. randy > > > Randy, >

Randy Bush wrote: >

> 
> Do you mean to say SPs such as large/national ISPs use ATMs on the
backbone
>> and have complete mesh with DS3/OC-3/OC-12 links 
>
> no, complete mesh of vcs over semi-meshed physical circuits
>
> >


What is the main reason for using a complete mesh of VCs? >

thanks, >
cyl From owner-mpls@UU.NET Tue Jan 9 12:49:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18231 for ; Tue, 9 Jan 2001 12:49:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgh29082; Tue, 9 Jan 2001 17:47:45 GMT Received: by mail-control.mail.uu.net id QQjxgh23425 for mpls-outgoing; Tue, 9 Jan 2001 17:47:06 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxgh23418 for ; Tue, 9 Jan 2001 17:46:58 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 QQjxgh19558 for ; Tue, 9 Jan 2001 17:46:51 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjxgh07505 for ; Tue, 9 Jan 2001 17:46:51 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA12474; Tue, 9 Jan 2001 09:46:57 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA23605; Tue, 9 Jan 2001 12:46:49 -0500 (EST) Message-Id: <200101091746.MAA23605@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: Saurabh Shrivastava cc: "mpls@uu.net" Subject: Re: Some questions(label space, NHLFE, ldp peers for an addressprefix) In-reply-to: Your message of Mon, 08 Jan 2001 11:33:45 -0800. <3A5A1619.D82ED099@efi.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Tue, 09 Jan 2001 12:46:48 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk > I think, it should be stated like this - the LSR should make sure that > when it receives a packet, it can look at the label and the interface it > was received from and know what to do with packet unambiguously. I think that's what section 3.14 says. > That is all. The standards should not enforce more rules. I don't see that any more rules are imposed by section 3.14. When this draft was being actively reviewed a couple of years ago, people seemed to want a few more clues about just what the conditions were under which the same label value could be used to represent different FECs, so some additional clues were provided. From owner-mpls@UU.NET Tue Jan 9 13:59:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19610 for ; Tue, 9 Jan 2001 13:59:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgl29795; Tue, 9 Jan 2001 18:57:57 GMT Received: by mail-control.mail.uu.net id QQjxgl11636 for mpls-outgoing; Tue, 9 Jan 2001 18:57:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxgl11630 for ; Tue, 9 Jan 2001 18:57:29 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 QQjxgl13659 for ; Tue, 9 Jan 2001 18:56:35 GMT Received: from web11408.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11408.mail.yahoo.com [216.136.131.238]) id QQjxgl13298 for ; Tue, 9 Jan 2001 18:56:34 GMT Message-ID: <20010109185634.30101.qmail@web11408.mail.yahoo.com> Received: from [132.177.121.20] by web11408.mail.yahoo.com; Tue, 09 Jan 2001 10:56:34 PST Date: Tue, 9 Jan 2001 10:56:34 -0800 (PST) From: John Sparr Subject: Src_Instance value To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi all, I have question about Src_Instance in HELLO msg RSVP. [draft-ietf-mpls-rsvp-lsp-tunnel-07.txt] The draft of says "Src_Instance is a 32 bit value that represents the sender's instance. The advertiser maintains a per neighbor representation/value. " What does the instance mean? ip address? or what else? Thanks a lot John __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From owner-mpls@UU.NET Tue Jan 9 14:18:44 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19920 for ; Tue, 9 Jan 2001 14:18:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgn27834; Tue, 9 Jan 2001 19:17:04 GMT Received: by mail-control.mail.uu.net id QQjxgn25080 for mpls-outgoing; Tue, 9 Jan 2001 19:16:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxgn24999 for ; Tue, 9 Jan 2001 19:16: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 QQjxgn22320 for ; Tue, 9 Jan 2001 19:15:04 GMT Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQjxgn25071 for ; Tue, 9 Jan 2001 19:15:03 GMT Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 9 Jan 2001 14:06:34 -0500 Received: from zcard00p.ca.nortel.com ([47.129.25.61]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CNPS448X; Tue, 9 Jan 2001 14:04:56 -0500 Received: from nortelnetworks.com (zcars02x.ca.nortel.com [47.23.81.10]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y9V1421Y; Tue, 9 Jan 2001 14:04:52 -0500 Message-ID: <3A5B60D4.6816ED1E@nortelnetworks.com> Date: Tue, 09 Jan 2001 14:04:52 -0500 From: "Cheng-Yin Lee" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Kireeti Kompella CC: long@pointreyesnet.com, vijay@umbc.edu, mpls@UU.NET Subject: Re: Some Queries References: <200101082233.OAA12544@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Kireeti, Kireeti Kompella wrote: > Hi Vijay, > > > Then we start to add hierarchy here. One design being the lets mesh the > > aggregation routers instead of the edge routers. Problem with that design > > is that now the MPLS domain does not go all the way to the edge, causing > > the edge to slosh ip traffic flows based on topology changes inside your > > network, causing your bandwidth settings on LSPS to fail miserably, as > > traffic may now start traversing LSPs which were previously (thanks to the > > wonders of SPF) never loaded, thus the automatic TE scripts set their > > reserved bandwidth to 0. > > So you advertise the LSPs into your SPF, and give them a fixed metric. > Now your SPFs behave: end of slosh. (Confess!) Could you elaborate how this scheme works, how this solves the problem described by Vijay above? thanks, cyl From owner-mpls@UU.NET Tue Jan 9 14:21:12 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19957 for ; Tue, 9 Jan 2001 14:21:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgn01742; Tue, 9 Jan 2001 19:19:37 GMT Received: by mail-control.mail.uu.net id QQjxgn25413 for mpls-outgoing; Tue, 9 Jan 2001 19:19:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxgn25284 for ; Tue, 9 Jan 2001 19:18: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 QQjxgn26969 for ; Tue, 9 Jan 2001 19:17:05 GMT Received: from mantrafive.mantranet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.mantranet.com [209.122.107.62]) id QQjxgn10445 for ; Tue, 9 Jan 2001 19:17:05 GMT Received: from venu ([209.122.107.2]) by mantrafive.mantranet.com (Post.Office MTA v3.1 release PO205e ID# 0-68542U200L2S100) with SMTP id AAA314; Tue, 9 Jan 2001 14:18:23 -0500 Message-ID: <006f01c07a6f$4eb7c9c0$1100a8c0@mantranet.com> From: vjosyula@mantranet.com (Venu Josyula) To: "Arthi Ayyangar" , "John Sparr" Cc: References: Subject: Re: Src_Instance value Date: Tue, 9 Jan 2001 14:06:44 -0500 Organization: Mantra 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 Arthi: But that number is unique to an RSVP Session. venu ----- Original Message ----- From: Arthi Ayyangar To: John Sparr Cc: Sent: Tuesday, January 09, 2001 2:09 PM Subject: Re: Src_Instance value > > It's just a sequence number. > > Thanks, > -arthi > > > I have question about Src_Instance in HELLO msg RSVP. > > [draft-ietf-mpls-rsvp-lsp-tunnel-07.txt] > > > > The draft of says "Src_Instance is a 32 bit value that > > represents the sender's instance. The advertiser > > maintains a per neighbor representation/value. " > > > > > > What does the instance mean? ip address? or what else? > > > > > > > > Thanks a lot > > > > John > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Photos - Share your holiday photos online! > > http://photos.yahoo.com/ > > > > From owner-mpls@UU.NET Tue Jan 9 14:27:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20020 for ; Tue, 9 Jan 2001 14:27:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgm20095; Tue, 9 Jan 2001 19:05:05 GMT Received: by mail-control.mail.uu.net id QQjxgm20807 for mpls-outgoing; Tue, 9 Jan 2001 19:04:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxgm20648 for ; Tue, 9 Jan 2001 19:04:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjxgm15575 for ; Tue, 9 Jan 2001 19:03:36 GMT Received: from apollo.mctr.umbc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: apollo.mctr.umbc.edu [130.85.101.89]) id QQjxgm09163 for ; Tue, 9 Jan 2001 19:03:36 GMT Received: from mercury.mctr.umbc.edu (mercury.mctr.umbc.edu [130.85.101.142]) by apollo.mctr.umbc.edu (8.9.3/8.9.3) with ESMTP id OAA29550; Tue, 9 Jan 2001 14:03:35 -0500 (EST) Received: from localhost (ayyangar@localhost) by mercury.mctr.umbc.edu (8.8.8+Sun/8.8.8) with SMTP id OAA23671; Tue, 9 Jan 2001 14:09:28 -0500 (EST) X-Authentication-Warning: mercury.mctr.umbc.edu: ayyangar owned process doing -bs Date: Tue, 9 Jan 2001 14:09:28 -0500 (EST) From: Arthi Ayyangar X-Sender: ayyangar@mercury.mctr.umbc.edu To: John Sparr cc: mpls@UU.NET Subject: Re: Src_Instance value In-Reply-To: <20010109185634.30101.qmail@web11408.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk It's just a sequence number. Thanks, -arthi > I have question about Src_Instance in HELLO msg RSVP. > [draft-ietf-mpls-rsvp-lsp-tunnel-07.txt] > > The draft of says "Src_Instance is a 32 bit value that > represents the sender's instance. The advertiser > maintains a per neighbor representation/value. " > > > What does the instance mean? ip address? or what else? > > > > Thanks a lot > > John > > __________________________________________________ > Do You Yahoo!? > Yahoo! Photos - Share your holiday photos online! > http://photos.yahoo.com/ > From owner-mpls@UU.NET Tue Jan 9 14:38:58 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20259 for ; Tue, 9 Jan 2001 14:38:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgo14231; Tue, 9 Jan 2001 19:37:35 GMT Received: by mail-control.mail.uu.net id QQjxgo27297 for mpls-outgoing; Tue, 9 Jan 2001 19:37:04 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxgo27269 for ; Tue, 9 Jan 2001 19:36: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 QQjxgo09772 for ; Tue, 9 Jan 2001 19:36:20 GMT Received: from entmail.gnilink.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: entmail.gnilink.net [199.45.47.10]) id QQjxgo12061 for ; Tue, 9 Jan 2001 19:36:19 GMT Received: by entmail.gnilink.com with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 14:34:07 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB353D0727@entmail.gnilink.com> From: "Martin, Christian" To: "'Cheng-Yin Lee'" , Kireeti Kompella Cc: long@pointreyesnet.com, vijay@umbc.edu, mpls@UU.NET Subject: RE: Some Queries Date: Tue, 9 Jan 2001 14:34:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > > > Hi Vijay, > > > > > Then we start to add hierarchy here. One design being the > lets mesh the > > > aggregation routers instead of the edge routers. Problem > with that design > > > is that now the MPLS domain does not go all the way to > the edge, causing > > > the edge to slosh ip traffic flows based on topology > changes inside your > > > network, causing your bandwidth settings on LSPS to fail > miserably, as > > > traffic may now start traversing LSPs which were > previously (thanks to the > > > wonders of SPF) never loaded, thus the automatic TE > scripts set their > > > reserved bandwidth to 0. > > > > So you advertise the LSPs into your SPF, and give them a > fixed metric. > > Now your SPFs behave: end of slosh. (Confess!) > > Could you elaborate how this scheme works, how this solves the problem > described by Vijay above? Since the edge boxen now see the core LSPs as part of the SPT, they can make more accurate decisions as to which edge-core path to use when forwarding packets towards the core. What Vijay was referring to was the problem of having TE'ed LSPs having misrepresented reservable bandwidth because edge-to-edge flows are unconstrained, and thus, do not follow the TE design. When scripts go in and observe bandwidth utilization on BB trunks, and see that they are full relative to the reservable bandwidth, they reduce that number to 0. The fixed metric approach that Kireeti mentioned appears to not offer any added benefit, unless the metrics are fixed relative to the parameters on the links, which I think was his intention. (Unless Kireeti was suggesting that a fixed metric (same everywhere) would prevent frequent SPF churn, which it would) In other words, by representing the mesh of LSPs as a dimensionless cloud, the injection of LSP information to the IGP provides little improvement over not injecting the LSPs into the IGP, in terms of path optimization. However, by injecting meaningful metrics, ie, those based on the link speed, reservable bandwidth, etc, and not adjusting them automatically, you optimize the end-to-end path. Again, this doesn't solve the SPF churn issue as well as using fixed metrics, however, it may help mitigate link sauturation. Either way, it is a sound approach, however, Vijay would know better as he has seen this applied in some _very_ large MPLS networks. It should also be noted that this approach is not uncommon given that not all edge devices support MPLS, yet may need (or should) to take advantage of an optimized SPT from edge-to-edge. regards, chris > > thanks, > cyl > > From owner-mpls@UU.NET Tue Jan 9 15:50:20 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21176 for ; Tue, 9 Jan 2001 15:50:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgs11702; Tue, 9 Jan 2001 20:33:38 GMT Received: by mail-control.mail.uu.net id QQjxgs14553 for mpls-outgoing; Tue, 9 Jan 2001 20:33:17 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxgs14545 for ; Tue, 9 Jan 2001 20:33:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjxgs00708 for ; Tue, 9 Jan 2001 20:32:45 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjxgs22353 for ; Tue, 9 Jan 2001 20:32:44 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id MAA00641 for ; Tue, 9 Jan 2001 12:32:44 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id MAA20067 for mpls@UU.NET; Tue, 9 Jan 2001 12:32:38 -0800 (PST) Date: Tue, 9 Jan 2001 12:32:38 -0800 (PST) From: Kireeti Kompella Message-Id: <200101092032.MAA20067@kummer.juniper.net> To: mpls@UU.NET Subject: RE: Some Queries In-Reply-To: <94B9091E1149D411A45C00508BACEB353D0727@entmail.gnilink.com> Sender: owner-mpls@UU.NET Precedence: bulk Hi Chris, > The fixed metric approach that Kireeti mentioned appears to > not offer any added benefit, unless the metrics are fixed relative to the > parameters on the links, which I think was his intention. "Fixed metric" means that the LSP's metric doesn't change, even if it re-routes. One of Vijay's problems is that a topology change could cause serious traffic shifts (to use his colorful language, slosh), negating the carefully constructed TE patterns and associated bandwidths. Kireeti. From owner-mpls@UU.NET Tue Jan 9 16:32:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21710 for ; Tue, 9 Jan 2001 16:32:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgv12912; Tue, 9 Jan 2001 21:29:30 GMT Received: by mail-control.mail.uu.net id QQjxgv02400 for mpls-outgoing; Tue, 9 Jan 2001 21:29:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxgv02390 for ; Tue, 9 Jan 2001 21:29:04 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 QQjxgv14451 for ; Tue, 9 Jan 2001 21:28:48 GMT Received: from entmail.gnilink.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: entmail.gnilink.net [199.45.47.10]) id QQjxgv27374 for ; Tue, 9 Jan 2001 21:28:48 GMT Received: by entmail.gnilink.com with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 16:26:35 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB353D072A@entmail.gnilink.com> From: "Martin, Christian" To: mpls@UU.NET Subject: RE: Some Queries Date: Tue, 9 Jan 2001 16:26:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Thanks for the clarification, Kireeti. > "Fixed metric" means that the LSP's metric doesn't change, even if > it re-routes. One of Vijay's problems is that a topology change could > cause serious traffic shifts (to use his colorful language, slosh), > negating the carefully constructed TE patterns and associated > bandwidths. Agreed. So you would still design meaningful metrics. I was thinking fixed relative to the other LSPs. Sounds like an IP/IGP over ATM/PNNI topology! I was looking at it from an edge to core perspective, neglecting to recognize the end-to-end thrashing that would occur due to SPT changes in the core. After more reflection, it is clear that SPF churn would occur regardless, but traffic flows would be stable. Regards, chris > > Kireeti. From owner-mpls@UU.NET Tue Jan 9 16:43:24 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21771 for ; Tue, 9 Jan 2001 16:43:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgw22285; Tue, 9 Jan 2001 21:41:47 GMT Received: by mail-control.mail.uu.net id QQjxgw03520 for mpls-outgoing; Tue, 9 Jan 2001 21:41:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxgw03484 for ; Tue, 9 Jan 2001 21:41:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjxgw07795 for ; Tue, 9 Jan 2001 21:39:14 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQjxgw29389 for ; Tue, 9 Jan 2001 21:39:14 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id NAA04861; Tue, 9 Jan 2001 13:39:13 -0800 (PST) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id NAA20618; Tue, 9 Jan 2001 13:39:06 -0800 (PST) Date: Tue, 9 Jan 2001 13:39:06 -0800 (PST) From: Kireeti Kompella Message-Id: <200101092139.NAA20618@kummer.juniper.net> To: cmartin@gnilink.net, mpls@UU.NET Subject: RE: Some Queries In-Reply-To: <94B9091E1149D411A45C00508BACEB353D072A@entmail.gnilink.com> Sender: owner-mpls@UU.NET Precedence: bulk > Sounds like an IP/IGP over ATM/PNNI topology! You got it! :-) Kireeti. From owner-mpls@UU.NET Tue Jan 9 16:45:18 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21793 for ; Tue, 9 Jan 2001 16:45:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgw06996; Tue, 9 Jan 2001 21:43:41 GMT Received: by mail-control.mail.uu.net id QQjxgw03692 for mpls-outgoing; Tue, 9 Jan 2001 21:43:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxgw03687 for ; Tue, 9 Jan 2001 21:43:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjxgw26000 for ; Tue, 9 Jan 2001 21:42:25 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 QQjxgw23463 for ; Tue, 9 Jan 2001 21:42:25 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25870 for ; Tue, 9 Jan 2001 16:42:22 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA00211 for ; Tue, 9 Jan 2001 16:42:24 -0500 (EST) Message-ID: <3A5B85EC.EC7E3782@marconi.com> Date: Tue, 09 Jan 2001 16:43:08 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: An LDP question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In the LDP document "draft-ietf-mpls-ldp-11.txt", there are two different failure detection mechanisms. One is the requirement for periodic Hello messages, and the other is the requirement for periodic KeepAlive messages in the TCP session. What is the reason for requiring both of these mechanisms? Either one alone should be sufficient to detect failures. For that matter, why not just use the TCP keepalive option and let connections remain up until the TCP connection breaks? If this has already been discussed in the past, a pointer to a document or web page containing an explanation will be sufficient. Thanks in advance. -- David From owner-mpls@UU.NET Tue Jan 9 17:01:14 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22091 for ; Tue, 9 Jan 2001 17:01:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgx18777; Tue, 9 Jan 2001 21:59:27 GMT Received: by mail-control.mail.uu.net id QQjxgx05102 for mpls-outgoing; Tue, 9 Jan 2001 21:59:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxgx05077 for ; Tue, 9 Jan 2001 21:58: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 QQjxgx01392 for ; Tue, 9 Jan 2001 21:58:23 GMT Received: from zcars04e.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) id QQjxgx24381 for ; Tue, 9 Jan 2001 21:58:22 GMT Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Tue, 9 Jan 2001 16:53:11 -0500 Received: from zcard00p.ca.nortel.com ([47.129.25.61]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id CNPSVQRN; Tue, 9 Jan 2001 16:53:10 -0500 Received: from nortelnetworks.com (zcars02x.ca.nortel.com [47.23.81.10]) by zcard00p.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y9V142YL; Tue, 9 Jan 2001 16:53:10 -0500 Message-ID: <3A5B8845.56E6E7D4@nortelnetworks.com> Date: Tue, 09 Jan 2001 16:53:09 -0500 From: "Cheng-Yin Lee" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: curtis@avici.com CC: mpls@UU.NET Subject: Re: Some queries References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis, Do you agree that : 1) the scaling issues in IGPs, are a result of fully-meshing routers, not a result of using independent control planes 2) service providers who have requirements to fully-mesh routers (for simple edge to edge traffic measurement, bandwidth management, control, as described by Vijay) have to setup fully-meshed circuits, VCs or LSPs. The needs of service providers to fully-mesh routers do not arise because of ATM (or MPLS). thanks, cyl Vijay Gill wrote: > This, along with some hierarchy, allows for precise traffic measurement > between router-router flows and at the city-pair level, and results in > fairly tractable flow data that can be used to predict traffic levels, > allowing for proper sizing of sPVC contracts, etc. These contracts are > then used by the ATM switch software to do constrained based routing of > sPVCs, allowing the network operators to do a good job of traffic > engineering and circuit layout/capacity planning. > > This might explain why people have gone with the extra expense (both in > capex and SGnA) and complexity to implement a fully meshed ATM solution. > > /vijay From owner-mpls@UU.NET Tue Jan 9 17:23:39 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22281 for ; Tue, 9 Jan 2001 17:23:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxgz24738; Tue, 9 Jan 2001 22:21:53 GMT Received: by mail-control.mail.uu.net id QQjxgz17981 for mpls-outgoing; Tue, 9 Jan 2001 22:21:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxgz17976 for ; Tue, 9 Jan 2001 22:21:21 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 QQjxgz22453 for ; Tue, 9 Jan 2001 22:18:55 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxgz18485 for ; Tue, 9 Jan 2001 22:18:55 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA02430 for mpls@uu.net; Tue, 9 Jan 2001 17:18:54 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxgz17801 for ; Tue, 9 Jan 2001 22:18: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 QQjxgz23576 for ; Tue, 9 Jan 2001 22:15:25 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 QQjxgz26426 for ; Tue, 9 Jan 2001 22:15:25 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA00542; Tue, 9 Jan 2001 14:15:35 -0800 (PST) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id RAA01688; Tue, 9 Jan 2001 17:15:23 -0500 (EST) Message-Id: <200101092215.RAA01688@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: David Charlap cc: mpls@UU.NET Subject: Re: An LDP question In-reply-to: Your message of "Tue, 09 Jan 2001 16:43:08 EST." <3A5B85EC.EC7E3782@marconi.com> Date: Tue, 09 Jan 2001 17:15:23 -0500 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk > In the LDP document "draft-ietf-mpls-ldp-11.txt", there are two > different failure detection mechanisms. One is the requirement for > periodic Hello messages, and the other is the requirement for periodic > KeepAlive messages in the TCP session. > > What is the reason for requiring both of these mechanisms? Either one > alone should be sufficient to detect failures. > > For that matter, why not just use the TCP keepalive option and let > connections remain up until the TCP connection breaks? > > If this has already been discussed in the past, a pointer to a document > or web page containing an explanation will be sufficient. This has been discussed in the past. You could try wading through: http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html Bob From owner-mpls@UU.NET Tue Jan 9 17:48:06 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22522 for ; Tue, 9 Jan 2001 17:48:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxhb19620; Tue, 9 Jan 2001 22:45:49 GMT Received: by mail-control.mail.uu.net id QQjxhb19626 for mpls-outgoing; Tue, 9 Jan 2001 22:45:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxhb19621 for ; Tue, 9 Jan 2001 22:45:21 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 QQjxha17700 for ; Tue, 9 Jan 2001 22:44:12 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 QQjxha10629 for ; Tue, 9 Jan 2001 22:44:10 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 RAA31334; Tue, 9 Jan 2001 17:40:49 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org) Message-Id: <200101092240.RAA31334@workhorse.fictitious.org> To: "Cheng-Yin Lee" cc: curtis@avici.com, mpls@UU.NET Reply-To: curtis@avici.com Subject: Re: Some queries In-reply-to: Your message of "Tue, 09 Jan 2001 16:53:09 EST." <3A5B8845.56E6E7D4@nortelnetworks.com> Date: Tue, 09 Jan 2001 17:40:49 -0500 From: Curtis Villamizar Sender: owner-mpls@UU.NET Precedence: bulk In message <3A5B8845.56E6E7D4@nortelnetworks.com>, "Cheng-Yin Lee" writes: > Curtis, > > Do you agree that : > 1) the scaling issues in IGPs, are a result of fully-meshing routers, not a > result of using independent control planes Yes, but independent control planes was the reason dense meshing in the IGP was needed. The IGP had to run over the VCs. You can have a full mesh of MPLS LSPs and a sparse mesh of IGP adjacencies. The same is not true for ATM. > 2) service providers who have requirements to fully-mesh routers (for simpl > e > edge to edge traffic measurement, bandwidth management, control, as described > by > Vijay) have to setup fully-meshed circuits, VCs or LSPs. The needs of serv > ice > providers to fully-mesh routers do not arise because of ATM (or MPLS). You don't seem to understand that with MPLS the mesh of MPLS LSPs is decoupled from the IGP adjacencies. With MPLS, the IGP does not run over the MPLS LSPs. The IGP runs over the physical links. The IGP and TE mesh are decoupled. You can have BOTH a full mesh of LSPs AND a scalable IGP. With ATM, the IGP runs over each VC. The IGP and TE mesh are coupled. You can have a full mesh of VCs OR a scalable IGP, but NOT BOTH. > thanks, > cyl I'm repeating myself above in hopes that you'll finally see the point that we've been trying to make. Curtis > Vijay Gill wrote: > > > This, along with some hierarchy, allows for precise traffic measurement > > between router-router flows and at the city-pair level, and results in > > fairly tractable flow data that can be used to predict traffic levels, > > allowing for proper sizing of sPVC contracts, etc. These contracts are > > then used by the ATM switch software to do constrained based routing of > > sPVCs, allowing the network operators to do a good job of traffic > > engineering and circuit layout/capacity planning. > > > > This might explain why people have gone with the extra expense (both in > > capex and SGnA) and complexity to implement a fully meshed ATM solution. > > > > /vijay From owner-mpls@UU.NET Wed Jan 10 00:21:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27886 for ; Wed, 10 Jan 2001 00:21:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxib27653; Wed, 10 Jan 2001 05:18:42 GMT Received: by mail-control.mail.uu.net id QQjxib06018 for mpls-outgoing; Wed, 10 Jan 2001 05:18:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxib06013 for ; Wed, 10 Jan 2001 05:18: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 QQjxib14332 for ; Wed, 10 Jan 2001 05:16:19 GMT Received: from tcb.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQjxib27003 for ; Wed, 10 Jan 2001 05:16:19 GMT Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id WAA18808 for ; Tue, 9 Jan 2001 22:16:06 -0700 Message-Id: <200101100516.WAA18808@tcb.net> To: mpls@UU.NET From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Comments on martini-l2circuit-encap-mpls-00.txt Date: Tue, 09 Jan 2001 22:16:06 -0700 Sender: owner-mpls@UU.NET Precedence: bulk Some comments here, some technical, some not so technical. I tried to suppress others that have already been addressed on the list, though I'd really like to see responses to outstanding issues brought up in Robin's message from 20 December. Also, I think considering merging this draft with the transport draft would be a good thing, I'm not sure why they're separate documents. I could understand this if each one explained a particular L2 service type. --------------------------------------- Section 3: "The next 16 bits are the sequence number that is used to guarantee ordered packet delivery." I believe you mean this: "The next 16 bits are the sequence number that is used to detect out-of-order packets." And here: "PDUs carrying the control word MUST NOT be delivered out of order. They may be discarded or reordered." I think something more along these lines would be clearer: "If PDUs carrying the control word arrive out-of-order, they MAY be discarded or reordered, they MUST NOT be delivered." Section 4: "If a packet length, once it has been encapsulated on the ingress LSR, exceeds the LSP MTU, it MUST be dropped." How is the "LSP MTU" known here? Presumably, you weren't referring to the Black LDP MTU draft. "If an egress LSR receives a packet on a VC LSP with a length, once the label stack and sequencing control word have been popped, that exceeds the MTU of the destination layer 2 interface it MUST be dropped." Wouldn't something more graceful be of benefit here? Perhaps exchanging the egress interface MTU via LDP? Section 5.1: "A Frame Relay PDU is transported in its entirety, including the Frame Relay header. The sequencing control word is OPTIONAL." Presumably, you don't actually intend to carry the FCS as well? Regarding this: "The BECN and FECN signals are carried unchanged", perhaps bits or indicators would be more appropriate than 'signals'? "The Label Edge Routers", what's a label edge router? Presumably, you mean Edge LSRs? Here: "The Label Edge Routers that implement this document MAY, when either adding or removing the encapsulation described herein, change a zero to a one in either or both of these bits in order to reflect congestion in the MPLS network that is known to the LERs." There's that LER thing again, though the acronym isn't defined (Anywhere). Also, I guess disucssion of how an 'LER' knows about "congestion in the MPLS network" is beyond the scope of the document? Regarding this: "The ingress LSR MAY consider the DE bit of the Frame Relay header when determining the value to be placed in the EXP fields of the MPLS label stack. In a similar way, the egress LSR MAY consider the EXP field of the VC label when queuing the packet for egress." Shouldn't you say something about "the DE value of the encapsulated FR frame MUST be copied to the DE field of the reconstructed packet before transmission to the CE (for lack of a better term)". I guess this would equally apply yo C/R, EA, FECN/BECN, etc.. Perhaps simply providing some wording regarding how the egress LSR handles decap, etc.. would be useful? Also, shouldn't something be said regarding the inability to fully support Frame Relay EA with this model? Section 5.2: Presumably, you're removing the FCS from the CPCS-PDU before encapsulation? Also, shouldn't you at least mention that you removed the 1 octet HEC from the ATM cell header before encapsulation? "If ATM cells, or a combination of ATM cells and AAL5 CPCS-PDUs, are to be transported the sequencing control word is required." A combination? Section 5.2.1: I think you should probably scope this sentence: "A router that does not support transport of OAM cells MUST discard incoming MPLS frames on an ATM VC LSP that contain an ATM cell with the high-order bit of the PTI field set to 1." Perhaps you should use "egress LSR" rather than "a router"? Also, how would this work if multiple cells were in the MPLS frame? Here: "If an F5 end-to-end OAM cell is received from a VC by an LSR with a loopback indication value of 1 and the LSR has a label mapping for the VC, the LSR must decrement the loopback indication value and loop back the cell on the VC. Otherwise the loopback cell must be discarded by the LSR." I think you should scope this to "egress LSR", per simple use of the term 'VC' here soesn't explicitly imply this. For that matter, defining 'VC' in this context would probably be useful as well... Hrmm, this seems to differ from the model suggested for Frame Relay: "The egress LSR MAY consider the value of the EXP field of the VC label when determining the value of the ATM CLP bit." There you only talk of "when queuing the packet for egress". Consistency would be good here, the correct model is probably obvious. And again, providing exact label decap/cell reconstructing details would be of benefit here as well. Also, why no talk of ATM and FR (I)LMI interaction on the access side? Section 5.3: "For an ethernet 802.1q VLAN the entire ethernet frame without the preamble or FCS is transported as a single packet. The sequencing control word is OPTIONAL. If a packet is received out of sequence it MUST be dropped." I think the out of sequence packet should only be dropped IF the sequencing control word is used. You could merge these sentences and provide a bit of clarity. Also, you should tighten up your use of Ethernet/IEEE 802.3/802.1q wording here. "The 4 byte VLAN tag is transported as is, and MAY be overwritten by the egress LSR." this seems loose. Handling by the egress LSR could be tightened up here. "The ingress LSR MAY consider the user priority field [4] of the VLAN tag header when determining the value to be placed in the EXP fields of the MPLS label stack. In a similar way, the egress LSR MAY consider the EXP field of the VC label when queuing the packet for egress." Why just when queuing, not mapping to the 3-bit P field? This falls into consistency issue as with ATM and FR. "Ethernet packets containing hardware level CRC, Framing errors, or runt packets MUST be discarded on input." Does this really belong in this document? Section 5.4: 5.4. Ethernet "As in the Ethernet VLAN case, ethernet packets with hardware level CRC, framing, and runt packets MUST be discarded on input." I really don't believe this belongs here either. Also, should RFC2469 be mentioned here somewhere? Finally, perhaps some consideration on Spanning Tree is in order here? Or at least providing similar functionality? From owner-mpls@UU.NET Wed Jan 10 02:18:32 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11611 for ; Wed, 10 Jan 2001 02:18:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxij15525; Wed, 10 Jan 2001 07:18:24 GMT Received: by mail-control.mail.uu.net id QQjxij06105 for mpls-outgoing; Wed, 10 Jan 2001 07:17:50 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxij06093 for ; Wed, 10 Jan 2001 07:17: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 QQjxij22398 for ; Wed, 10 Jan 2001 07:16:03 GMT Received: from mail05.rapidsite.net by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mail05.rapidsite.net [207.158.192.42]) id QQjxij18946 for ; Wed, 10 Jan 2001 07:16:02 GMT Received: from www.cwnt.com (207.158.195.100) by mail05.rapidsite.net (RS ver 1.0.58s) with SMTP id 023378447 for ; Wed, 10 Jan 2001 02:15:25 -0500 (EST) From: "Yoav Levy" To: "mpls@UU. NET" Subject: RE: Requirement for LDP support in the RFC2547bis draft Date: Wed, 10 Jan 2001 09:15:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01C07AE5.D3CF1FC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: X-Loop-Detect: 1 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C07AE5.D3CF1FC0 Content-Type: text/plain; charset="windows-1255" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQjxij15525 Content-Transfer-Encoding: quoted-printable It was really surprising to see such constrain without any good reason. I= t=92s like forcing the usage of isis (or ospf) in the BGP RFC =85 Yoav Levy Charlotte's Web Networks Ltd. http://www.cwnt.com Email: ylevy@cwnt.com Tel: +972-4-9592203 ext. 242 Fax: +972-4-9593325 2 Hamada St, P.O.B 303, Yokneam 20600, ISRAEL -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Sasha Vainshtein Sent: Tuesday, January 09, 2001 12:53 PM To: erosen@cisco.com Cc: Alik; mpls@uu.net Subject: Requirement for LDP support in the RFC2547bis draft Dear Mr. Rosen, I an relatively new to the discussions in the MPLS WG, and I would highly appreciate some explanation on the following subject: The original RFC2547 does not mention LDP at all. However, its proposed update, draft-rosen-rfc2547bis-02.txt, refers to LD= P in two places: * In section 4.3.2. "Route Distribution Among PEs by BGP", it states: Note that the use of BGP-distributed MPLS labels is only possible if there is a label switched path between the PE router that installs the BGP-distributed route and PE router which is the BGP next ho= p of that route... All that matters for the VPN architecture is that some label switched path between the router and its BGP next hop exists. However, to ensure interoperability among systems which implement this VP= N architecture, all such systems must support LDP * In section 5, "Forwarding Across the Backbone", it states: = To ensure interoperability among different implementations, it is required t= o support LDP for setting up the label switched paths across the backbone. However, other methods of setting up these label switched paths are also possible . I assume that in both cases the LSPs in question are the paths for the ou= ter (i.e., PE-to-PE) level encapsulation, and that requirement for LDP suppor= t states from the fact that such a support would gurantee ability to create such an LSP, e.g., by requesting a label for the egress PE IP address (kn= own to the ingress PE as the BGP next hop) in a standard way. Is this assumpt= ion correct? If this is the case, do the two quotations actually refer to the same problem and its solution? I would also like to understand the subtle difference between the (lower case) "must" in the quoted sections of draft-rosen-rfc2547bis-02.txt and = the (capitalized keyword) MUST described in RFC2119. ______________________________________________ With best regards, Sasha Vainshtein mailto: sasha@axerra.com phone: +972-3-7659993 (office) fax: +972-3-6487779 (office) ------=_NextPart_000_0050_01C07AE5.D3CF1FC0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

It= was really surprising to see such constrain without any good reason. It=92s = like forcing the usage of isis (or ospf) in the BGP RFC =85    

 

Yoav Levy

=

 

Charlotte's Web Networks Ltd.

 

http://www.cwnt.com

=

Email: ylevy@cwnt.com

=

Tel: +972-4-9592203  ext. 242

=

Fax: +972-4-9593325

=

2 Hamada = St, P.O.B 303, Yokneam 20600, ISRAEL

<= span class=3DEmailStyle19> 

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf = Of Sasha Vainshtein
Sent: Tuesday, January = 09, 2001 12:53 PM
To: erosen@cisco.com
Cc: Alik; mpls@uu.net
Subject: Requirement for = LDP support in the RFC2547bis draft

 

Dear Mr. Rosen,

I an relatively new to the = discussions in the MPLS WG, and I would highly appreciate some explanation on the = following subject:

The original = RFC2547 does not mention LDP at all. = <= /p>

However, its = proposed update, draft-rosen-rfc2547bis-02.txt, refers to LDP in two places:<= /p>

=B7      In section = 4.3.2. "Route Distribution Among PEs by BGP", it = states:<quote> Note that the use of BGP-distributed MPLS labels is only = possible if there is a label switched path between the PE router that installs the BGP-distributed route and PE router which is the BGP = next hop of that route... <skip&= gt; All that matters for the VPN architecture is that some = label switched path between the router and its BGP next hop exists.  However, to ensure interoperability among systems which implement = this VPN architecture, all such systems must support = LDP <end quote><= /p>

=B7      In section 5, = "Forwarding Across the Backbone", it states: <quote> = To ensure interoperability among = different implementations, it is required to support LDP for setting up the label switched paths = across the backbone.  However, other methods of setting up these = label switched paths are also possible <end quote>.<= /p>

I assume that = in both cases the LSPs in question are the paths for the outer (i.e., PE-to-PE) = level encapsulation, and that requirement for LDP support states from the fact = that such a support would gurantee ability to create such an LSP, e.g., = by requesting a label for the egress PE IP address (known to the = ingress PE as the BGP next hop) in a standard way. Is this assumption = correct? If this is the case, do the two quotations actually refer to the same = problem and its solution?

I would also = like to understand the subtle difference between the (lower case) = "must" in the quoted sections of draft-rosen-rfc2547bis-02.txt = and the (capitalized keyword) MUST = described in RFC2119.

________________= ______________________________<= /p>

With best regards,

Sasha Vainshtein<= /p>

mailto: = sasha@axerra.com<= /p>

phone: +972-3-7659993 (office)

fax:      +972-3-6487779 = (office)<= /p>

 <= /p>

------=_NextPart_000_0050_01C07AE5.D3CF1FC0-- From owner-mpls@UU.NET Wed Jan 10 02:52:05 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11871 for ; Wed, 10 Jan 2001 02:52:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxil01091; Wed, 10 Jan 2001 07:51:56 GMT Received: by mail-control.mail.uu.net id QQjxil08289 for mpls-outgoing; Wed, 10 Jan 2001 07:51:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxil08271 for ; Wed, 10 Jan 2001 07:51:04 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 QQjxil15290 for ; Wed, 10 Jan 2001 07:49:14 GMT Received: from anchor-post-33.mail.demon.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: anchor-post-33.mail.demon.net [194.217.242.91]) id QQjxil10594 for ; Wed, 10 Jan 2001 07:49:12 GMT Received: from layer8.demon.co.uk ([158.152.28.34] helo=layer8.co.uk) by anchor-post-33.mail.demon.net with smtp (Exim 2.12 #1) id 14GG0N-000Ofj-0X for mpls@uu.net; Wed, 10 Jan 2001 07:49:11 +0000 Received: from Andrew [192.168.0.5] by layer8.co.uk [127.0.0.1] with SMTP (MDaemon.v2.6.rA.b1.32-R) for ; Wed, 10 Jan 101 07:47:23 +0000 From: "Andrew Bartholomew" To: Subject: route targets and IBGP in mpls VPNs Date: Wed, 10 Jan 2001 07:47:42 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal X-MDaemon-Deliver-To: mpls@uu.net Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQjxil01091 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA11871 If I understand draft-rosen-rfc2547bis-02.txt properly I believe some clarification of the use of route targets would be helpful. My understanding is that route targets are used to control the flow of traffic within a VPN, rather than have a full mesh of routes between PEs. However, the "hub and spoke VPN" and the "firewall in an extranet" examples given in the draft suggest that all PEs do have routes to all parts of the VPN, just indirect ones in some cases. Specifically, in section 1.5 of the draft, the "firewall in an extranet" example, it says "This means that it needs to be possible to set up two routes to the server. One route, used by sites B and C, takes the traffic directly to site A. The second route, used by site D, takes the traffic instead to the firewall at site B. If the firewall allows the traffic to pass, it then appears to be traffic coming from site B, and follows the route to site A." This gives rise to the issue of IBGP speakers propagating updates received from one IBGP peer to another, something not normally allowed in IBGP, and also begs the question when such an update should be propagated, to avoid incorrect updates flooding the VPN. One could add a rule that if a PE router R installs a route with an export RT set S, and the corresponding VPN has an export RT set E (at R) such that E-S is not empty, then the route should be propagated by R with itself as the BGP next hop and with export RT set E-S. This route should only be considered by other PEs in the VPN who do not have an element of S as an import RT, since those that do should use the direct route rather than the one propagated by R. But, I do not see how other PEs could determine whether a route had been propagated or not without an explicit indication in the update from R. If propagation of routes between IBGP speakers is not allowed then some sites in a VPN will be unable to reach certain destinations without management intervention - is this really the intention? Regards, Andrew. -- Andrew Bartholomew Layer 8 Consultancy                      Observa et sapiens cresces. Services Limited                              Tel:   +44 1202 558409 Fax:   +44 1202 556748 Email: Andrewb@Layer8.co.uk From owner-mpls@UU.NET Wed Jan 10 03:00:03 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11910 for ; Wed, 10 Jan 2001 03:00:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxil08168; Wed, 10 Jan 2001 07:59:55 GMT Received: by mail-control.mail.uu.net id QQjxil08724 for mpls-outgoing; Wed, 10 Jan 2001 07:59:31 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxil08719 for ; Wed, 10 Jan 2001 07:59:26 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 QQjxil22966 for ; Wed, 10 Jan 2001 07:58:42 GMT Received: from ext1.ics.forth.gr by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.ics.forth.gr [139.91.1.2]) id QQjxil25240 for ; Wed, 10 Jan 2001 07:58:41 GMT Received: from ismene.ics.forth.gr (mailhost.ics.forth.gr [139.91.157.51]) by ext1.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.5-GATE) with ESMTP id JAA00907; Wed, 10 Jan 2001 09:44:50 +0200 (EET) Received: from sappho.ics.forth.gr (sappho-lane.ics.forth.gr [139.91.157.50]) by ismene.ics.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id JAA27423; Wed, 10 Jan 2001 09:43:12 +0200 (EET) Posted-Date: Wed, 10 Jan 2001 09:43:12 +0200 (EET) Organization: Received: from localhost (tziou@localhost) by sappho.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.2C-INTNULL) with ESMTP id JAA10145; Wed, 10 Jan 2001 09:41:58 +0200 (EET) X-Authentication-Warning: sappho.ics.forth.gr: tziou owned process doing -bs Date: Wed, 10 Jan 2001 09:41:58 +0200 (EET) From: Chrysostomos Tziouvaras To: ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: A brief question about modifying an existing CR-LSP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Dear all, Consider a CR-LSP which traverses a lightpath(tunnel). If the edge router of the optical network decides to put the CR-LSP into another optical path, is it necessary to inform the originator router of the CR-LSP or is it a strictly local matter for the edge router? Thanks in advance Chrysostomos Tziouvaras From owner-mpls@UU.NET Wed Jan 10 03:28:09 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12194 for ; Wed, 10 Jan 2001 03:28:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxin09907; Wed, 10 Jan 2001 08:27:44 GMT Received: by mail-control.mail.uu.net id QQjxin22004 for mpls-outgoing; Wed, 10 Jan 2001 08:27:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxin21999 for ; Wed, 10 Jan 2001 08:27: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 QQjxin09287 for ; Wed, 10 Jan 2001 08:26:23 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxin27665 for ; Wed, 10 Jan 2001 08:26:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA00439 for mpls@uu.net; Wed, 10 Jan 2001 03:26:22 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxin21832 for ; Wed, 10 Jan 2001 08:25:51 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 QQjxin07081 for ; Wed, 10 Jan 2001 08:25:09 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjxin05828 for ; Wed, 10 Jan 2001 08:25:08 GMT Received: from cisco.com (war-jer-dhcp82.cisco.com [144.254.89.252]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA01131; Wed, 10 Jan 2001 00:23:53 -0800 (PST) Message-ID: <3A5C0FB8.AAA5B8B9@cisco.com> Date: Tue, 09 Jan 2001 23:31:05 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Bartholomew CC: mpls@UU.NET Subject: Re: route targets and IBGP in mpls VPNs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Andrew, RTs do allow you to control the distribution of routes within each VPN among routers participating in the VPN. > This gives rise to the issue of IBGP speakers propagating updates received > from one IBGP peer to another, something not normally allowed in IBGP, and > also begs the question when such an update should be propagated, to avoid > incorrect updates flooding the VPN. The propagation of IBGP updates is done only in route relfectors. The principles of bgp do not change at all. > However, the "hub and spoke VPN" and the "firewall in an extranet" examples > given in the draft suggest that all PEs do have routes to all parts of the > VPN, just indirect ones in some cases. Let me give you a small example how hub and spoke would work. Considers three PEs: PE1, PE2 & PE3. Let PE1 be the PE connecting hub site and PE2/3 the PEs connecting the spoke sites. In the VRFs of PE2/3 you will find only local routes and the default out to PE1 hub site. Setting the right RT combination allows you to easily achive this. I am not sure what do you mean by "indirect routes" ??? I am only guessing that what you meant to say all the routes but only with different next hop (for example pointing at hub PE). If so no as you see from the above example default to hub site is what most spoke sites would use to get out. R. > Andrew Bartholomew wrote: > > If I understand draft-rosen-rfc2547bis-02.txt properly I believe some > clarification of the use of route targets would be helpful. > > My understanding is that route targets are used to control the flow of > traffic within a VPN, rather than have a full mesh of routes between PEs. > However, the "hub and spoke VPN" and the "firewall in an extranet" examples > given in the draft suggest that all PEs do have routes to all parts of the > VPN, just indirect ones in some cases. > > Specifically, in section 1.5 of the draft, the "firewall in an extranet" > example, it says > > "This means that it needs to be possible to set up two routes to the > server. One route, used by sites B and C, takes the traffic directly > to site A. The second route, used by site D, takes the traffic > instead to the firewall at site B. If the firewall allows the > traffic to pass, it then appears to be traffic coming from site B, > and follows the route to site A." > > This gives rise to the issue of IBGP speakers propagating updates received > from one IBGP peer to another, something not normally allowed in IBGP, and > also begs the question when such an update should be propagated, to avoid > incorrect updates flooding the VPN. > > One could add a rule that if a PE router R installs a route with an export > RT set S, and the corresponding VPN has an export RT set E (at R) such that > E-S is not empty, then the route should be propagated by R with itself as > the BGP next hop and with export RT set E-S. > > This route should only be considered by other PEs in the VPN who do not have > an element of S as an import RT, since those that do should use the direct > route rather than the one propagated by R. But, I do not see how other PEs > could determine whether a route had been propagated or not without an > explicit indication in the update from R. > > If propagation of routes between IBGP speakers is not allowed then some > sites in a VPN will be unable to reach certain destinations without > management intervention - is this really the intention? > > Regards, > Andrew. > > -- > Andrew Bartholomew > > Layer 8 Consultancy Observa et sapiens cresces. > Services Limited > > Tel: +44 1202 558409 > Fax: +44 1202 556748 > Email: Andrewb@Layer8.co.uk From owner-mpls@UU.NET Wed Jan 10 04:11:01 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12474 for ; Wed, 10 Jan 2001 04:11:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxiq13643; Wed, 10 Jan 2001 09:10:53 GMT Received: by mail-control.mail.uu.net id QQjxiq05658 for mpls-outgoing; Wed, 10 Jan 2001 09:10:33 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxiq05647 for ; Wed, 10 Jan 2001 09:10: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 QQjxiq20935 for ; Wed, 10 Jan 2001 09:09:45 GMT Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQjxiq16566 for ; Wed, 10 Jan 2001 09:09:44 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f0A92Rm21383; Wed, 10 Jan 2001 10:02:27 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569D0.0031A2A5; Wed, 10 Jan 2001 10:02:09 +0100 Message-ID: <3A5C2511.D05DC187@alcatel.be> Date: Wed, 10 Jan 2001 10:02:09 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Hummel Heinrich CC: "'George Swallow'" , mpls@UU.NET Subject: Re: Last call on MPLS multicast framework References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Heinrich, Hummel Heinrich wrote: > > > TTL, see Section 2 and 10.1 in draft-ietf-mpls-multicast-04.txt: > There cannot be an endless looping LSP as the IP-Header of LSP-setup messages have a TTL. An LSP-setup message is going hop-by-hop, so it can endlessly go hop-by-hop. > So why is the TTL field part of the classical label at all? And why these tears about the lack of > a TTL field in ATM/FR labels ? To avoid loops (but I won't spend more words to it, because this is outside the scope of this draft). > > For the same reason:Scoping of Multicast does not need the TTL-field in the label. It is enough if > the JOIN or SUBSCRIBE message has a TTL field in the IP-header. > > While I think the TTL in the label is superfluous, I miss a Multicast-Bit in the label. > In the ATM Forum we had a lot of discussions whether we can assume that each ATM switch is capable to branch, i.e. > can support multiple oifs. With respect to MPLS-hardware: Is every NHLFE prepared to have multiple oifs/outgoing > labels? If there is no Multicast-Bit inside the label of each incoming label-switched packet, then this bit > somehow must be part of each NHLFE. We are not assuming that every LSR supports point-to-multipoint LSPs. The branching-capability will become clear during the LSP set-up phase (if an LSP is requested for a multicast FEC), there is no need to carry this information in the data. Anyhow, even from the data one knows whether the LSP carries unicast or multicast traffic since the lower layer indicates whether the label is a unicast or a multicast label (see draft-ietf-mpls-label-encaps-08.txt). > > Politically: I don't think there is a MPLS Multicast yet. Version 04 is equal to version 01. I disagree on the first point (multiple implementations exist, some for more than 2 years). Regarding the versioning: there was a problem with the IETF database (they switched to a new one), due to that '2 versions' were skipped. 01 expired in November 2000, I reposted it as 02, but it was renumbered to 04 by the editor because of this database problem. dirk From owner-mpls@UU.NET Wed Jan 10 04:38:54 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12622 for ; Wed, 10 Jan 2001 04:38:54 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxis17999; Wed, 10 Jan 2001 09:38:44 GMT Received: by mail-control.mail.uu.net id QQjxis07613 for mpls-outgoing; Wed, 10 Jan 2001 09:38:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxis07607 for ; Wed, 10 Jan 2001 09:38: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 QQjxis05028 for ; Wed, 10 Jan 2001 09:36:55 GMT Received: from finch-post-10.mail.demon.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: finch-post-10.mail.demon.net [194.217.242.38]) id QQjxis15686 for ; Wed, 10 Jan 2001 09:36:54 GMT Received: from layer8.demon.co.uk ([158.152.28.34] helo=layer8.co.uk) by finch-post-10.mail.demon.net with smtp (Exim 2.12 #1) id 14GHga-000Cjv-0A for mpls@uu.net; Wed, 10 Jan 2001 09:36:52 +0000 Received: from Andrew [192.168.0.5] by layer8.co.uk [127.0.0.1] with SMTP (MDaemon.v2.6.rA.b1.32-R) for ; Wed, 10 Jan 101 09:36:14 +0000 From: "Andrew Bartholomew" To: Subject: RE: route targets and IBGP in mpls VPNs Date: Wed, 10 Jan 2001 09:36:32 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal X-MDaemon-Deliver-To: mpls@uu.net Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQjxis17999 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA12622 Robert, Thanks for the response, please see my comments below. Regards, Andrew -- Andrew Bartholomew Layer 8 Consultancy                      Observa et sapiens cresces. Services Limited                              Tel:   +44 1202 558409 Fax:   +44 1202 556748 Email: Andrewb@Layer8.co.uk > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: 10 January 2001 07:31 > To: Andrew Bartholomew > Cc: mpls@UU.NET > Subject: Re: route targets and IBGP in mpls VPNs > > > Andrew, > > RTs do allow you to control the distribution of routes within each VPN > among routers participating in the VPN. > > > This gives rise to the issue of IBGP speakers propagating > updates received > > from one IBGP peer to another, something not normally allowed > in IBGP, and > > also begs the question when such an update should be > propagated, to avoid > > incorrect updates flooding the VPN. > > The propagation of IBGP updates is done only in route relfectors. The > principles of bgp do not change at all. Are you assuming here that route reflectors MUST be implemented? I can give you an example of route propagation (see below) with only four sites in a VPN, where route reflectors would be overkill. > > > However, the "hub and spoke VPN" and the "firewall in an > extranet" examples > > given in the draft suggest that all PEs do have routes to all > parts of the > > VPN, just indirect ones in some cases. > > Let me give you a small example how hub and spoke would work. Considers > three PEs: PE1, PE2 & PE3. Let PE1 be the PE connecting hub site and > PE2/3 the PEs connecting the spoke sites. In the VRFs of PE2/3 you will > find only local routes and the default out to PE1 hub site. Setting the > right RT combination allows you to easily achive this. What if the route to the hub is not the default route? Can PE2 reach destinations local to PE3? These are VPN-IP4 routes and as the draft indicates, this may not always be applicable (where a site has non-VPN provided access to the Internet). Having PE1 distribute the default route to PE2 and PE3 would require additional configuration in addition to the RT values > > I am not sure what do you mean by "indirect routes" ??? I am only > guessing that what you meant to say all the routes but only with > different next hop (for example pointing at hub PE). If so no as you see > from the above example default to hub site is what most spoke sites > would use to get out. Yes, I mean one whose BGP next hop is not the most direct next hop across the VPN - one where the RT values have inhibited the installation of fully meshed (direct) connectivity. I did not mean "all the routes", consider a firewall example (slightly different to the one in the draft): If sites A, B, C, and D are in a VPN, with sites A and B belonging to one company and sites C and D belonging to another. There is a firewall at B, and servers at both A and C. One would want traffic from D to reach the server at A via the firewall at B but traffic from D to the server at C should not need to pass through the firewall at B. This is an example of where the PE router for site D needs a "direct" route to the server at C but an "indirect" route to the server at A. In particular, use of the default route would not provide the required traffic flow in the VPN in this case. > R. > > > Andrew Bartholomew wrote: > > > > If I understand draft-rosen-rfc2547bis-02.txt properly I believe some > > clarification of the use of route targets would be helpful. > > > > My understanding is that route targets are used to control the flow of > > traffic within a VPN, rather than have a full mesh of routes > between PEs. > > However, the "hub and spoke VPN" and the "firewall in an > extranet" examples > > given in the draft suggest that all PEs do have routes to all > parts of the > > VPN, just indirect ones in some cases. > > > > Specifically, in section 1.5 of the draft, the "firewall in an extranet" > > example, it says > > > > "This means that it needs to be possible to set up two routes to the > > server. One route, used by sites B and C, takes the traffic directly > > to site A. The second route, used by site D, takes the traffic > > instead to the firewall at site B. If the firewall allows the > > traffic to pass, it then appears to be traffic coming from site B, > > and follows the route to site A." > > > > This gives rise to the issue of IBGP speakers propagating > updates received > > from one IBGP peer to another, something not normally allowed > in IBGP, and > > also begs the question when such an update should be > propagated, to avoid > > incorrect updates flooding the VPN. > > > > One could add a rule that if a PE router R installs a route > with an export > > RT set S, and the corresponding VPN has an export RT set E (at > R) such that > > E-S is not empty, then the route should be propagated by R with > itself as > > the BGP next hop and with export RT set E-S. > > > > This route should only be considered by other PEs in the VPN > who do not have > > an element of S as an import RT, since those that do should use > the direct > > route rather than the one propagated by R. But, I do not see > how other PEs > > could determine whether a route had been propagated or not without an > > explicit indication in the update from R. > > > > If propagation of routes between IBGP speakers is not allowed then some > > sites in a VPN will be unable to reach certain destinations without > > management intervention - is this really the intention? > > > > Regards, > > Andrew. > > > > -- > > Andrew Bartholomew > > > > Layer 8 Consultancy Observa et sapiens cresces. > > Services Limited > > > > Tel: +44 1202 558409 > > Fax: +44 1202 556748 > > Email: Andrewb@Layer8.co.uk -- Andrew Bartholomew Layer 8 Consultancy                      Observa et sapiens cresces. Services Limited                              Tel:   +44 1202 558409 Fax:   +44 1202 556748 Email: Andrewb@Layer8.co.uk From owner-mpls@UU.NET Wed Jan 10 06:49:58 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA13451 for ; Wed, 10 Jan 2001 06:49:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxjb18077; Wed, 10 Jan 2001 11:49:44 GMT Received: by mail-control.mail.uu.net id QQjxjb08970 for mpls-outgoing; Wed, 10 Jan 2001 11:49:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxjb08957 for ; Wed, 10 Jan 2001 11:48:50 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 QQjxjb02963 for ; Wed, 10 Jan 2001 11:47:06 GMT Received: from smtp4.cluster.oleane.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp4.cluster.oleane.net [195.25.12.62]) id QQjxjb18680 for ; Wed, 10 Jan 2001 11:47:05 GMT Received: from oleane (dyn-1-1-059.Vin.dialup.oleane.fr [195.25.4.59]) by smtp4.cluster.oleane.net with SMTP id f0ABl4F78610 for ; Wed, 10 Jan 2001 12:47:04 +0100 (CET) Message-ID: <028501c07afb$3f59bec0$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: MPLS World, February 6-9, Paris Date: Wed, 10 Jan 2001 12:48:27 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0282_01C07B03.A0CA3A60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0282_01C07B03.A0CA3A60 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 MPLS World, February 6-9, Paris.=20 =20 http://www.upperside.fr/congress/congress.htm =20 With the challenges and uncertainties engendered by the development of = the MPLS architecture, the MPLS World Conference is, in essence, an open = platform for debate on the future of telecommunications networks.=20 Looking Farther Ahead=20 MPLS World is preoccupied with future developments, like using MPLS in = the access network and in the LAN. MPLambdaS, MPLS/mobility convergence = are addressed in papers never before given. MPLS is a unique occasion = for participants to unveil their work and expose new ideas.=20 =20 The exhibition =20 Already 20 exhibitors for this very first MPLS exhibition. Upper Side = will fullfill his objectives. Vendors shouldn't miss the opportunity: http://www.upperside.fr/congress/exhi.htm ------=_NextPart_000_0282_01C07B03.A0CA3A60 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
MPLS World, February 6-9, Paris.=20
 
http://www.uppersi= de.fr/congress/congress.htm
 
With the=20 challenges and uncertainties engendered by the development of the MPLS=20 architecture, the MPLS World Conference is, in essence, an open platform = for=20 debate on the future of telecommunications networks.=20

Looking=20 Farther Ahead

MPLS World is preoccupied with future = developments,=20 like using MPLS in the access network and in the LAN. MPLambdaS, = MPLS/mobility=20 convergence are addressed in papers never before given. MPLS is a unique = occasion for participants to unveil their work and expose new ideas.=20
 
The=20 exhibition
 
Already 20=20 exhibitors for this very first MPLS exhibition. Upper Side will fullfill = his=20 objectives. Vendors shouldn't miss the opportunity:
http://www.upperside.f= r/congress/exhi.htm
 
------=_NextPart_000_0282_01C07B03.A0CA3A60-- From owner-mpls@UU.NET Wed Jan 10 07:14:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13948 for ; Wed, 10 Jan 2001 07:14:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxjc24584; Wed, 10 Jan 2001 12:13:55 GMT Received: by mail-control.mail.uu.net id QQjxjc21793 for mpls-outgoing; Wed, 10 Jan 2001 12:13:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxjc21787 for ; Wed, 10 Jan 2001 12:13:29 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 QQjxjc21383 for ; Wed, 10 Jan 2001 12:12:29 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxjc21997 for ; Wed, 10 Jan 2001 12:12:27 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA09023 for mpls@uu.net; Wed, 10 Jan 2001 07:12:27 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxjc21731 for ; Wed, 10 Jan 2001 12:11: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 QQjxjc22376 for ; Wed, 10 Jan 2001 12:11:39 GMT Received: from lohi.eng.telia.fi by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQjxjc28848 for ; Wed, 10 Jan 2001 12:11:38 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f0ACBXA08625; Wed, 10 Jan 2001 14:11:33 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14940.20853.639874.178719@lohi.eng.telia.fi> Date: Wed, 10 Jan 2001 14:11:33 +0200 (EET) To: curtis@avici.com Cc: "Cheng-Yin Lee" , mpls@UU.NET Subject: Re: Some queries In-Reply-To: <200101092240.RAA31334@workhorse.fictitious.org> References: <3A5B8845.56E6E7D4@nortelnetworks.com> <200101092240.RAA31334@workhorse.fictitious.org> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Curtis Villamizar writes: > You can have a full mesh of MPLS LSPs and a sparse mesh of IGP > adjacencies. The same is not true for ATM. not true, see ftp://lohi.eng.telia.fi/tmp/draft-ietf-ion-intra-area-unicast-01.txt -- juha From owner-mpls@UU.NET Wed Jan 10 07:26:14 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14184 for ; Wed, 10 Jan 2001 07:26:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxjd17877; Wed, 10 Jan 2001 12:26:02 GMT Received: by mail-control.mail.uu.net id QQjxjd22645 for mpls-outgoing; Wed, 10 Jan 2001 12:25:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxjd22640 for ; Wed, 10 Jan 2001 12:25:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjxjd29787 for ; Wed, 10 Jan 2001 12:24:30 GMT Received: from rip.psg.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rip.psg.com [147.28.0.39]) id QQjxjd24643 for ; Wed, 10 Jan 2001 12:24:30 GMT Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14GKIl-0009RC-00; Wed, 10 Jan 2001 04:24:27 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Peter Lewis" Cc: Subject: Re: MPLS World, February 6-9, Paris References: <028501c07afb$3f59bec0$8001a8c0@oleane.com> Message-Id: Date: Wed, 10 Jan 2001 04:24:27 -0800 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > Looking Farther Ahead slime spammer finally stops polluting ietf mailing list with his scams? that's what i would like to see ahead. randy From owner-mpls@UU.NET Wed Jan 10 08:01:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15093 for ; Wed, 10 Jan 2001 08:01:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxjg03049; Wed, 10 Jan 2001 13:01:12 GMT Received: by mail-control.mail.uu.net id QQjxjg28032 for mpls-outgoing; Wed, 10 Jan 2001 13:00:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxjg27890 for ; Wed, 10 Jan 2001 13:00:52 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 QQjxjg19017 for ; Wed, 10 Jan 2001 13:00:09 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxjg26788 for ; Wed, 10 Jan 2001 13:00:08 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA11886 for mpls@uu.net; Wed, 10 Jan 2001 08:00:08 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxjb08881 for ; Wed, 10 Jan 2001 11:47:04 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 QQjxjb20999 for ; Wed, 10 Jan 2001 11:46:10 GMT Received: from ietf.org by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjxjb13541 for ; Wed, 10 Jan 2001 11:46:10 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13317; Wed, 10 Jan 2001 06:46:08 -0500 (EST) Message-Id: <200101101146.GAA13317@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-bgp4-mpls-05.txt Date: Wed, 10 Jan 2001 06:46:08 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Carrying Label Information in BGP-4 Author(s) : Y. Rekhter, E. Rosen Filename : draft-ietf-mpls-bgp4-mpls-05.txt Pages : 7 Date : 09-Jan-01 When BGP is used to distribute a particular route, it can be also be used to distribute an MPLS label which is mapped to that route [MPLS-ARCH]. This document specifies the way in which this is done. The label mapping information for a particular route is piggybacked in the same BGP Update message that is used to distribute the route itself. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-bgp4-mpls-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-bgp4-mpls-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-bgp4-mpls-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: <20010109130032.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-bgp4-mpls-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-bgp4-mpls-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010109130032.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 10 09:26:33 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17644 for ; Wed, 10 Jan 2001 09:26:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxjl07823; Wed, 10 Jan 2001 14:19:03 GMT Received: by mail-control.mail.uu.net id QQjxjl24179 for mpls-outgoing; Wed, 10 Jan 2001 14:18:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxjl24165 for ; Wed, 10 Jan 2001 14:18:24 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 QQjxjl25286 for ; Wed, 10 Jan 2001 14:16:55 GMT Received: from gorilla.mchh.siemens.de by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQjxjl09602 for ; Wed, 10 Jan 2001 14:16:52 GMT Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA26717; Wed, 10 Jan 2001 15:16:44 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA05966; Wed, 10 Jan 2001 15:16:45 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 15:16:42 +0100 Message-ID: From: Hummel Heinrich To: "'Dirk Ooms'" , Hummel Heinrich Cc: "'George Swallow'" , mpls@UU.NET Subject: AW: Last call on MPLS multicast framework Date: Wed, 10 Jan 2001 15:16:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk My newer comments are inserted. > Hummel Heinrich wrote: > > > > > > TTL, see Section 2 and 10.1 in draft-ietf-mpls-multicast-04.txt: > > There cannot be an endless looping LSP as the IP-Header of LSP-setup messages have a TTL. > > An LSP-setup message is going hop-by-hop, so it can endlessly go > hop-by-hop. And this LSP-setup message has no IP-Header with a TTL field that can be used to detect an eventual endless loop ? > > So why is the TTL field part of the classical label at all? And why these tears about the lack of > > a TTL field in ATM/FR labels ? > > To avoid loops (but I won't spend more words to it, because this is > outside the scope of this draft). > > > > > For the same reason:Scoping of Multicast does not need the TTL-field in the label. It is enough if > > the JOIN or SUBSCRIBE message has a TTL field in the IP-header. > > > > While I think the TTL in the label is superfluous, I miss a Multicast-Bit in the label. > > In the ATM Forum we had a lot of discussions whether we can assume that each ATM switch is capable to branch, i.e. > > can support multiple oifs. With respect to MPLS-hardware: Is every NHLFE prepared to have multiple oifs/outgoing > > labels? If there is no Multicast-Bit inside the label of each incoming label-switched packet, then this bit > > somehow must be part of each NHLFE. > > > We are not assuming that every LSR supports point-to-multipoint LSPs. > The branching-capability will become clear during the LSP set-up phase > (if an LSP is requested for a multicast FEC), there is no need to carry > this information in the data. Anyhow, even from the data one knows > whether the LSP carries unicast or multicast traffic since the lower > layer indicates whether the label is a unicast or a multicast label (see > draft-ietf-mpls-label-encaps-08.txt). Right. And I know that there is no necessity to have such a Multicast-flag in the label. Nevertheless I can imagine that it could be advantageous for building MPLS hardware. It is not unusual that a protocol organizes itself. More important: Branching capability. How can a JOIN message navigate towards a branching capable router ? All it knows is a root (sender S, or Rendez-vous Point RP) by which it is guided! Another point: In case there is no branching capable LSR between the sender and the very first receiver, then I think the Multicast is over. Isn't it ? How is it garanteed that this won't happen ? Heinrich From owner-mpls@UU.NET Wed Jan 10 09:37:19 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17937 for ; Wed, 10 Jan 2001 09:37:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxjm12040; Wed, 10 Jan 2001 14:30:48 GMT Received: by mail-control.mail.uu.net id QQjxjm25768 for mpls-outgoing; Wed, 10 Jan 2001 14:30:17 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxjm25727 for ; Wed, 10 Jan 2001 14:30: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 QQjxjl05612 for ; Wed, 10 Jan 2001 14:29:15 GMT Received: from prithvi.siliconsystems.co.in by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [164.164.85.131]) id QQjxjl08820 for ; Wed, 10 Jan 2001 14:29:12 GMT Received: from mail.siliconsystems.co.in (mail.siliconsystems.co.in [172.19.32.5]) by prithvi.siliconsystems.co.in (8.9.1a+p1/8.9.1/d: thinkit.m4,v 1.5 2000/06/09 23:40:41 dmccart Exp $) with ESMTP id OAA07822 for ; Wed, 10 Jan 2001 14:28:54 GMT Received: from siliconsystems.co.in (opal.siliconsystems.co.in [172.19.32.37]) by mail.siliconsystems.co.in (8.9.3/8.9.3) with ESMTP id UAA27222 for ; Wed, 10 Jan 2001 20:12:45 +0530 (IST) Message-ID: <3A5C73EC.EB182ABE@siliconsystems.co.in> Date: Wed, 10 Jan 2001 20:08:36 +0530 From: Sachin Doshi X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: query Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Can anyone clarify me on these: 1. Is it required by the MPLS standard that we should send IP packets with only Label 0 as bottom of stack? 2a. If the answer to (1) is yes, then should the ingress LSR push 2 labels for sending IP traffic (Top one for routing information and the bottom one with label 0). 2b. Or is it that the ingress LSR just sends the packet with only one label L (not == 0) and the PHP will replace that label with 0? regards, sachin doshi From owner-mpls@UU.NET Wed Jan 10 10:57:47 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19871 for ; Wed, 10 Jan 2001 10:57:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxjr26454; Wed, 10 Jan 2001 15:56:29 GMT Received: by mail-control.mail.uu.net id QQjxjr18911 for mpls-outgoing; Wed, 10 Jan 2001 15:55:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxjr18893 for ; Wed, 10 Jan 2001 15:55:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjxjr13796 for ; Wed, 10 Jan 2001 15:55:31 GMT Received: from alpha.tellium.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQjxjr25116 for ; Wed, 10 Jan 2001 15:55:31 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0AFrvW26900; Wed, 10 Jan 2001 10:53:57 -0500 (EST) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 10:49:44 -0500 Message-ID: <0CD7D73C734BD411AEE100B0D0220404C85741@mail1.tellium.com> From: Vasanthi Thirumalai To: "'Chrysostomos Tziouvaras'" , ip-optical@lists.bell-labs.com, mpls@UU.NET Subject: RE: [IP-Optical] A brief question about modifying an existing CR- LSP Date: Wed, 10 Jan 2001 10:49:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Chrysostomos, If you use the modify mechanism defined in "draft-ietf-mpls-crlsp-modify-02.txt", then the present version of that draft only allows modification requests that originate from the ingress router of the CR-LSP. -Vasanthi -----Original Message----- From: Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr] Sent: Wednesday, January 10, 2001 2:42 AM To: ip-optical@lists.bell-labs.com; mpls@UU.NET Subject: [IP-Optical] A brief question about modifying an existing CR-LSP Dear all, Consider a CR-LSP which traverses a lightpath(tunnel). If the edge router of the optical network decides to put the CR-LSP into another optical path, is it necessary to inform the originator router of the CR-LSP or is it a strictly local matter for the edge router? Thanks in advance Chrysostomos Tziouvaras _______________________________________________ IP-Optical mailing list IP-Optical@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/ip-optical From owner-mpls@UU.NET Wed Jan 10 11:21:06 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20368 for ; Wed, 10 Jan 2001 11:21:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxjt01440; Wed, 10 Jan 2001 16:19:46 GMT Received: by mail-control.mail.uu.net id QQjxjt03766 for mpls-outgoing; Wed, 10 Jan 2001 16:19:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxjt03757 for ; Wed, 10 Jan 2001 16:19:11 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 QQjxjs05787 for ; Wed, 10 Jan 2001 16:13:34 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjxjs20349 for ; Wed, 10 Jan 2001 16:13:34 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA06936 for ; Wed, 10 Jan 2001 08:13:42 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA27031 for mpls@uu.net; Wed, 10 Jan 2001 11:13:32 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxjm26949 for ; Wed, 10 Jan 2001 14:40:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjxjm23350 for ; Wed, 10 Jan 2001 14:40:20 GMT Received: from gatekeeper.cam.virata.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gatekeeper.virata.com [194.129.40.2]) id QQjxjm13023 for ; Wed, 10 Jan 2001 14:40:20 GMT Received: from boletus.cam.virata.com (boletus.cam.virata.com [192.168.219.9]) by gatekeeper.cam.virata.com (8.9.3/8.8.5) with ESMTP id OAA16290; Wed, 10 Jan 2001 14:40:15 GMT Received: from fileserv.ta.virata.com (fileserv.ta.virata.com [10.0.0.254]) by boletus.cam.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id OAA23996; Wed, 10 Jan 2001 14:40:13 GMT Received: by fileserv.ta.virata.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 16:38:20 +0200 Message-ID: From: "Korchemny, Elena" To: "'tnadeau@cisco.com'" , "'arun@force10networks.com'" , "'cheenu@tachion.com'" Cc: "'mpls@UU.NET'" , "Lipovetsky, Sergey" Subject: RE: Last call on MPLS TE MIB Date: Wed, 10 Jan 2001 16:38:19 +0200 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 Greetings, MPLS-TE-MIB has been implemented for Virata MPLS software packet. This implementation is based on draft-ietf-mpls-te-mib-05 document. A few points arose during our work on MPLS-TE-MIB. I think these points might clarify MPLS TE MIB draft before it become standard. 1. There is mplsTunnelLocalProtectInUse object in the Tunnel table Can you add reference to a document (draft, RFC, standard) explaining what is "Local protection mechanism". Is there any relation between mplsTunnelLocalProtectInUse object and "isPersistent" flag of mplsTunnelSessionAttributes object. 2. mplsTunnelOwner objects currently has 5 values: admin(1), rsvp(2), ldp(3), policyAgent(4) and other(5). It seems to me that tunnel owner should be defined as: admin, signaling, policyAgent, other. And in order to know which type of signaling was used for tunnel creating object mplsTunnelSignallingProto should be used. Existing definition causes doubling of information on transit hops (for example, a tunnel owner is rsvp(2) and signProtocol is rsvp(2)). 3. mplsTunnelIndex and mplsTunnelInstance objects How do you see mapping between TE MIB tunnel index/instance and the signaling protocol concepts? In Virata TE MIB implementation we interpreted these objects as: for RSVP signaling - mplsTunnelIndex corresponds to TunnelId of the rsvp session object, mplsTunnelInstance corresponds to LSPID of the sender template. for LDP signaling - mplsTunnelIndex corresponds to LSPId TLV in label request/mapping/... messages, for mplsTunnelInstance we don't see appropriate object in CR-LDP (CR-LDP does not support "multi-path tunnel"). We set TE MIB TunnelInstance value to 1 in this case. Does this approach correct? Or you didn't mean any relation between the Tunnel table indices and the signal protocol objects? 4. One more little note. mplsTunnelTotalUpTime and mplsTunnelInstanceUpTime objects are defined with MAX-ACCESS "read-create". I think they should be "read-only". Am I right? mplsTunnelAdminStatus is defined as read-create, it should be read-write. I think the above points might clarify the MPLS-TE_MIB draft. (And your answers to the above questions should help us to improve our MPLS-TE MIB implementation.) Regards, Elena Korchemny Senior software engineer VIRATA Tel: +972-9-7663288 (Ext. 211) ekorchemny@virata.com -----Original Message----- From: George Swallow [mailto:swallow@cisco.com] Sent: Saturday, January 06, 2001 12:18 AM To: mpls@UU.NET Subject: Last call on MPLS TE MIB This message begins a workgroup last call on draft-ietf-mpls-te-mib-05.txt, "MPLS Traffic Engineering Management Information Base Using SMIv2". The last call ends Jan 19, 5pm est. ...George ====================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Jan 10 11:25:23 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20523 for ; Wed, 10 Jan 2001 11:25:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxjt08049; Wed, 10 Jan 2001 16:24:03 GMT Received: by mail-control.mail.uu.net id QQjxjt04429 for mpls-outgoing; Wed, 10 Jan 2001 16:23:35 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxjt04416 for ; Wed, 10 Jan 2001 16:23:30 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 QQjxjt28113 for ; Wed, 10 Jan 2001 16:21:37 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxjt01658 for ; Wed, 10 Jan 2001 16:21:36 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA27500 for mpls@uu.net; Wed, 10 Jan 2001 11:21:35 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxjt04100 for ; Wed, 10 Jan 2001 16:21: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 QQjxjt20697 for ; Wed, 10 Jan 2001 16:18:14 GMT Received: from albatross-ext.wise.edt.ericsson.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: albatross-ext.wise.edt.ericsson.se [194.237.142.116]) id QQjxjt29240 for ; Wed, 10 Jan 2001 16:18:13 GMT Received: from esealnt462.al.sw.ericsson.se (esealnt462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0AGICC03919 for ; Wed, 10 Jan 2001 17:18:12 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Jan 10 17:17:56 2001 +0100 Received: by esealnt747.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Wed, 10 Jan 2001 17:17:55 +0100 Message-ID: From: "Marco de Gier (ETM)" To: "'mpls@uunet.net'" Subject: subscribe Date: Wed, 10 Jan 2001 17:17:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Marco de Gier > Product Manager Datacom & IP > Tel +31 161 247359 > Mobile +31 6 29562388 > Fax +31 161 242663 > > Ericsson > Telecom Solutions > P.O. Pox 8, 5120 AA Rijen > The Netherlands E-Mail: marco.de.gier@ericsson.com Homepage: http://www.ericsson.com/datacom From owner-mpls@UU.NET Wed Jan 10 11:28:18 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20615 for ; Wed, 10 Jan 2001 11:28:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxjt15765; Wed, 10 Jan 2001 16:26:49 GMT Received: by mail-control.mail.uu.net id QQjxjt04949 for mpls-outgoing; Wed, 10 Jan 2001 16:26:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxjt04939 for ; Wed, 10 Jan 2001 16:26:23 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 QQjxjt13848 for ; Wed, 10 Jan 2001 16:26:13 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjxjt07923 for ; Wed, 10 Jan 2001 16:26:12 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA16041; Wed, 10 Jan 2001 08:26:20 -0800 (PST) Received: from localhost (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id LAA27072; Wed, 10 Jan 2001 11:26:10 -0500 (EST) Message-Id: <200101101626.LAA27072@erosen-sun.cisco.com> X-Authentication-Warning: erosen-sun.cisco.com: erosen owned process doing -bs To: "Sasha Vainshtein" cc: "Alik" , "mpls@uu.net" Subject: Re: Requirement for LDP support in the RFC2547bis draft In-reply-to: Your message of Tue, 09 Jan 2001 12:52:43 +0200. Reply-To: erosen@cisco.com User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1 (=?ISO-8859-4?Q?Nishinoky=F2?=) Emacs/20.6 (sparc-sun-solaris2.5.1) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by WEMI 1.13.2 - "Mochimune") Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Jan 2001 11:26:10 -0500 From: Eric Rosen Sender: owner-mpls@UU.NET Precedence: bulk Sasha> I assume that in both cases the LSPs in question are the paths for Sasha> the outer (i.e., PE-to-PE) level encapsulation, and that requirement Sasha> for LDP support states from the fact that such a support would Sasha> gurantee ability to create such an LSP, e.g., by requesting a label Sasha> for the egress PE IP address (known to the ingress PE as the BGP next Sasha> hop) in a standard way. Is this assumption correct? If this is the Sasha> case, do the two quotations actually refer to the same problem and Sasha> its solution? Yes. The requirement for LDP support is there to ensure that two compliant implementations can interoperate. There is no requirement that LDP actually be used, if some other method is available. Sasha> I would also like to understand the subtle difference between the Sasha> (lower case) "must" in the quoted sections of draft-rosen-rfc2547bis- Sasha> 02.txt and the (capitalized keyword) MUST described in RFC2119. I don't think there is any difference between "must" and "MUST" in the section you quoted. From owner-mpls@UU.NET Wed Jan 10 12:15:56 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21609 for ; Wed, 10 Jan 2001 12:15:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxjw26691; Wed, 10 Jan 2001 17:14:34 GMT Received: by mail-control.mail.uu.net id QQjxjw24090 for mpls-outgoing; Wed, 10 Jan 2001 17:13:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxjw24073 for ; Wed, 10 Jan 2001 17:13:49 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 QQjxjw24315 for ; Wed, 10 Jan 2001 17:10:51 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxjw18413 for ; Wed, 10 Jan 2001 17:10:50 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA02187 for mpls@uu.net; Wed, 10 Jan 2001 12:10:49 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxjw20606 for ; Wed, 10 Jan 2001 17:10:16 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjxjw16044 for ; Wed, 10 Jan 2001 17:08:36 GMT Received: from pilgrim.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQjxjw14589 for ; Wed, 10 Jan 2001 17:08:36 GMT Received: from swallow-pc01 (sj-dial-2-106.cisco.com [10.19.226.107]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id MAA19759; Wed, 10 Jan 2001 12:08:31 -0500 (EST) Message-Id: <4.1.20010110121347.00a28730@pilgrim.cisco.com> X-Sender: swallow@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 10 Jan 2001 12:16:04 -0500 To: "Peter Lewis" , From: George Swallow Subject: Re: MPLS World, February 6-9, Paris In-Reply-To: <028501c07afb$3f59bec0$8001a8c0@oleane.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Peter - To echo Randy's comments with a bit more tact.... Much as I like your conference, advertising it on IETF work group lists is entirely inappropriate. Further you risk the ire of many of the folks you hope to attract. Please refrain in the future. Thank you, ...George From owner-mpls@UU.NET Wed Jan 10 17:35:10 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00331 for ; Wed, 10 Jan 2001 17:35:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxks25283; Wed, 10 Jan 2001 22:34:06 GMT Received: by mail-control.mail.uu.net id QQjxks27595 for mpls-outgoing; Wed, 10 Jan 2001 22:33:49 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxks27590 for ; Wed, 10 Jan 2001 22:33:45 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 QQjxks15642 for ; Wed, 10 Jan 2001 22:32:48 GMT Received: from NOD.RESTON.MCI.NET by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [166.60.6.38]) id QQjxks23397 for ; Wed, 10 Jan 2001 22:32:48 GMT Received: from rbonica ([166.60.14.45]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JYR0XU77R09N4I78@shoe.reston.mci.net> for mpls@UU.NET; Wed, 10 Jan 2001 17:32:47 EST Date: Wed, 10 Jan 2001 17:23:21 -0500 From: Ron Bonica Subject: RE: Last call on MPLS multicast framework In-reply-to: <200101052231.RAA04518@lir.cisco.com> To: mpls@UU.NET Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Dirk, Two questions: 1) In section 3.8, you say that RPF checks will fail when explicit routing causes multicast traffic to arrive on "the wrong interface". Won't RPF checks also fail when MPLS routes traffic through "the wrong interface" for any other reason (e.g., traffic engineering constraints)? 2) If RPF checks succeed only when traffic arrives on the interface that IGP metrics dictate, what is the benefit of running IP multicast over MPLS? Ron From owner-mpls@UU.NET Wed Jan 10 17:51:58 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02004 for ; Wed, 10 Jan 2001 17:51:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxkt04367; Wed, 10 Jan 2001 22:50:37 GMT Received: by mail-control.mail.uu.net id QQjxkt29198 for mpls-outgoing; Wed, 10 Jan 2001 22:50:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxkt29179 for ; Wed, 10 Jan 2001 22:49: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 QQjxkt09438 for ; Wed, 10 Jan 2001 22:48:28 GMT Received: from mx1out.umbc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx1out.umbc.edu [130.85.253.51]) id QQjxkt02087 for ; Wed, 10 Jan 2001 22:48:28 GMT Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx1out.umbc.edu (8.9.3/8.9.3) with ESMTP id RAA00818; Wed, 10 Jan 2001 17:48:27 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id RAA765649; Wed, 10 Jan 2001 17:48:26 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Wed, 10 Jan 2001 17:48:26 -0500 From: Vijay Gill X-Sender: vijay@irix2.gl.umbc.edu To: Ron Bonica cc: mpls@UU.NET Subject: RE: Last call on MPLS multicast framework In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 10 Jan 2001, Ron Bonica wrote: > 2) If RPF checks succeed only when traffic arrives on the interface > that IGP metrics dictate, what is the benefit of running IP multicast > over MPLS? Raising a heretical thought here, has someone raised the (operational) solution of just providing an overlay multicast network by emulating a layer 2 network over mpls and running multicast over that? This also manages to eliminate a possible S,G state explosion affecting the current revenue generating unicast network. [1] Not a very clever solution, but has the added benefit of working without adding more protocol fragility into already broken system implementations. /vijay [1] credit must be given to Giles Heron (L3) for this. From owner-mpls@UU.NET Thu Jan 11 08:47:29 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00792 for ; Thu, 11 Jan 2001 08:47:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxnb22657; Thu, 11 Jan 2001 13:46:58 GMT Received: by mail-control.mail.uu.net id QQjxnb20480 for mpls-outgoing; Thu, 11 Jan 2001 13:46:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxnb20465 for ; Thu, 11 Jan 2001 13:46:04 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 QQjxna26702 for ; Thu, 11 Jan 2001 13:43:29 GMT Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQjxna26706 for ; Thu, 11 Jan 2001 13:43:25 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f0BDhB609621; Thu, 11 Jan 2001 14:43:12 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569D1.004B551C; Thu, 11 Jan 2001 14:42:49 +0100 Message-ID: <3A5DB857.6C65AAC3@alcatel.be> Date: Thu, 11 Jan 2001 14:42:47 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ron Bonica CC: mpls@UU.NET Subject: Re: Last call on MPLS multicast framework References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ron, Thanks for your question, it made me revisit the RPF stuff and it turns out that it is not correct anymore (because of an 'evolution' in the definition of RPF). from draft-ietf-idmr-dvmrp-v3-10.txt: The interface on which the best route to the source of the datagram was received is called the upstream (also called RPF) interface. from draft-ietf-pim-sm-v2-new-01.txt: RPF stands for "Reverse Path Forwarding". The RPF Neighbor of a router with respect to an address is the neighbor that the MRIB indicates should be used to forward packets to that address. In the case of a PIM-SM multicast group, the RPF neighbor is the router that a Join message for that group would be directed to, in the absence of modifying Assert state. The second definition is more precise because it distinguishes the unicast and the multicast topology (MRIB) and it does not mention the confusing word 'best' (='shortest'?) anymore. According to the newest 'definition' of RPF in the PIM draft the issue mentioned in section 3.8 (and section 7) does not occur anymore, so I will remove it. dirk Ron Bonica wrote: > > Dirk, > > Two questions: > > 1) In section 3.8, you say that RPF checks will fail when explicit routing > causes multicast traffic to arrive on "the wrong interface". Won't RPF > checks also fail when MPLS routes traffic through "the wrong interface" for > any other reason (e.g., traffic engineering constraints)? > > 2) If RPF checks succeed only when traffic arrives on the interface that IGP > metrics dictate, what is the benefit of running IP multicast over MPLS? > > Ron From owner-mpls@UU.NET Thu Jan 11 09:41:19 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02027 for ; Thu, 11 Jan 2001 09:41:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxne24512; Thu, 11 Jan 2001 14:40:52 GMT Received: by mail-control.mail.uu.net id QQjxne06723 for mpls-outgoing; Thu, 11 Jan 2001 14:40:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxne06712 for ; Thu, 11 Jan 2001 14:40: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 QQjxne09424 for ; Thu, 11 Jan 2001 14:40:00 GMT Received: from sky.irisa.fr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sky.irisa.fr [131.254.60.147]) id QQjxne18626 for ; Thu, 11 Jan 2001 14:39:59 GMT Received: from irisa.fr (rocha.irisa.fr [131.254.13.52]) by sky.irisa.fr (8.9.3/8.9.3) with ESMTP id PAA05933; Thu, 11 Jan 2001 15:39:47 +0100 (MET) Message-ID: <3A5DC5B4.A86BF26E@irisa.fr> Date: Thu, 11 Jan 2001 15:39:48 +0100 From: Ali Boudani Organization: INRIA - RENNES X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en, fr MIME-Version: 1.0 To: Vijay Gill CC: Ron Bonica , mpls@UU.NET Subject: Re: Last call on MPLS multicast framework References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, DIRK Do you mean : that the best route (who's maybe not the shortest one due to some constraints) is considered as the RPF now and vijay what exactly do you mean about your question ?? Thanx Ali Vijay Gill wrote: > On Wed, 10 Jan 2001, Ron Bonica wrote: > > > 2) If RPF checks succeed only when traffic arrives on the interface > > that IGP metrics dictate, what is the benefit of running IP multicast > > over MPLS? > > Raising a heretical thought here, has someone raised the (operational) > solution of just providing an overlay multicast network by emulating a > layer 2 network over mpls and running multicast over that? This also > manages to eliminate a possible S,G state explosion affecting the current > revenue generating unicast network. [1] > > Not a very clever solution, but has the added benefit of working without > adding more protocol fragility into already broken system implementations. > > /vijay > > [1] credit must be given to Giles Heron (L3) for this. From owner-mpls@UU.NET Thu Jan 11 10:01:13 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02451 for ; Thu, 11 Jan 2001 10:01:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxng23541; Thu, 11 Jan 2001 15:01:02 GMT Received: by mail-control.mail.uu.net id QQjxng10073 for mpls-outgoing; Thu, 11 Jan 2001 15:00:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxng09831 for ; Thu, 11 Jan 2001 15:00:26 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 QQjxnf11264 for ; Thu, 11 Jan 2001 14:59:55 GMT Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQjxnf11246 for ; Thu, 11 Jan 2001 14:59:51 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f0BEwQN29855; Thu, 11 Jan 2001 15:58:26 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569D1.005238E6; Thu, 11 Jan 2001 15:58:05 +0100 Message-ID: <3A5DC9FA.8F2B6466@alcatel.be> Date: Thu, 11 Jan 2001 15:58:02 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ali Boudani CC: Vijay Gill , Ron Bonica , mpls@UU.NET Subject: Re: Last call on MPLS multicast framework References: <3A5DC5B4.A86BF26E@irisa.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ali Boudani wrote: > > Hello, > > DIRK > Do you mean : that the best route (who's maybe not the shortest one due to > some constraints) is considered as the RPF now I think you got it, but I want to avoid the word 'best'. In the multicast topology, there will be a route to the source and this route is taken into account for the RPF (this can be the shortest route calculated by e.g. OSPF, but it can also be a route calculated by a more sophisticated routing algorithm). dirk dirk > > and vijay > what exactly do you mean about your question ?? > > Thanx > Ali > > Vijay Gill wrote: > > > On Wed, 10 Jan 2001, Ron Bonica wrote: > > > > > 2) If RPF checks succeed only when traffic arrives on the interface > > > that IGP metrics dictate, what is the benefit of running IP multicast > > > over MPLS? > > > > Raising a heretical thought here, has someone raised the (operational) > > solution of just providing an overlay multicast network by emulating a > > layer 2 network over mpls and running multicast over that? This also > > manages to eliminate a possible S,G state explosion affecting the current > > revenue generating unicast network. [1] > > > > Not a very clever solution, but has the added benefit of working without > > adding more protocol fragility into already broken system implementations. > > > > /vijay > > > > [1] credit must be given to Giles Heron (L3) for this. From owner-mpls@UU.NET Thu Jan 11 12:38:08 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09980 for ; Thu, 11 Jan 2001 12:38:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxnq02326; Thu, 11 Jan 2001 17:35:04 GMT Received: by mail-control.mail.uu.net id QQjxnq27929 for mpls-outgoing; Thu, 11 Jan 2001 17:34:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxnq27921 for ; Thu, 11 Jan 2001 17:34: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 QQjxnq00834 for ; Thu, 11 Jan 2001 17:34:14 GMT Received: from NOD.RESTON.MCI.NET by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [166.60.6.38]) id QQjxnq03424 for ; Thu, 11 Jan 2001 17:34:14 GMT Received: from rbonica ([166.60.14.45]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JYS4T0U4JG9LVT7P@shoe.reston.mci.net> for mpls@UU.NET; Thu, 11 Jan 2001 12:34:14 EST Date: Thu, 11 Jan 2001 12:24:45 -0500 From: Ron Bonica Subject: RE: Last call on MPLS multicast framework In-reply-to: <3A5DB857.6C65AAC3@alcatel.be> To: Dirk Ooms Cc: mpls@UU.NET Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Dirk, Now I am really confused. From your response, I infer that the RPF check will succeed, even if traffic arrives on an interface other than that through which the router would send traffic in order to reach the source. Is this inference correct? If it is correct, wouldn't RPF code have to change? Ron > -----Original Message----- > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > Sent: Thursday, January 11, 2001 8:43 AM > To: Ron Bonica > Cc: mpls@UU.NET > Subject: Re: Last call on MPLS multicast framework > > > Ron, > > Thanks for your question, it made me revisit the RPF stuff and it turns > out that it is not correct anymore (because of an 'evolution' in the > definition of RPF). > > from draft-ietf-idmr-dvmrp-v3-10.txt: > The interface on which the best route to the source of the datagram was > received is called the upstream (also called RPF) interface. > > from draft-ietf-pim-sm-v2-new-01.txt: > RPF stands for "Reverse Path Forwarding". The RPF Neighbor of a router > with respect to an address is the neighbor that the MRIB indicates > should be used to forward packets to that address. In the case of a > PIM-SM multicast group, the RPF neighbor is the router that a Join > message for that group would be directed to, in the absence of modifying > Assert state. > > The second definition is more precise because it distinguishes the > unicast and the multicast topology (MRIB) and it does not mention the > confusing word 'best' (='shortest'?) anymore. > > According to the newest 'definition' of RPF in the PIM draft the issue > mentioned in section 3.8 (and section 7) does not occur anymore, so I > will remove it. > > dirk > > Ron Bonica wrote: > > > > Dirk, > > > > Two questions: > > > > 1) In section 3.8, you say that RPF checks will fail when > explicit routing > > causes multicast traffic to arrive on "the wrong interface". Won't RPF > > checks also fail when MPLS routes traffic through "the wrong > interface" for > > any other reason (e.g., traffic engineering constraints)? > > > > 2) If RPF checks succeed only when traffic arrives on the > interface that IGP > > metrics dictate, what is the benefit of running IP multicast over MPLS? > > > > Ron > From owner-mpls@UU.NET Thu Jan 11 14:12:18 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12728 for ; Thu, 11 Jan 2001 14:12:18 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxnw02941; Thu, 11 Jan 2001 19:05:26 GMT Received: by mail-control.mail.uu.net id QQjxnw28964 for mpls-outgoing; Thu, 11 Jan 2001 19:05:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxnw28725 for ; Thu, 11 Jan 2001 19:04:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjxnw23333 for ; Thu, 11 Jan 2001 19:04:07 GMT Received: from web12003.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web12003.mail.yahoo.com [216.136.172.211]) id QQjxnw12284 for ; Thu, 11 Jan 2001 19:04:07 GMT Message-ID: <20010111190406.1200.qmail@web12003.mail.yahoo.com> Received: from [149.99.118.91] by web12003.mail.yahoo.com; Thu, 11 Jan 2001 11:04:06 PST Date: Thu, 11 Jan 2001 11:04:06 -0800 (PST) From: Greg Richardson Subject: LSP path setup time To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hello, I have a question about establishing explicit LSPs within an AS. Lets assume an ingress would like to setup a fixed bandwidth LSP between itself and a destination node. Suppose we define the establishment phase as two step process: 1) Routing Decision - The ingress typically uses an iteration of dijkstra's algorithm to compute the shortest path (based on hop-count or other constraints). 2) Resource Reservation - The ingress uses an appropriate signaling protocol (such as RSVP-TE)to explicitly establish the LSP. This includes any admission control at intermediate nodes, and perhaps label distribution between peers. Although vendor implementation is a huge factor in determining the relative times to complete either phase, is it safe to say that the time to complete 2nd phase almost always dominates the first for a network consisting of 100's of nodes. __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From owner-mpls@UU.NET Thu Jan 11 15:57:46 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14460 for ; Thu, 11 Jan 2001 15:57:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxod24744; Thu, 11 Jan 2001 20:57:11 GMT Received: by mail-control.mail.uu.net id QQjxod23249 for mpls-outgoing; Thu, 11 Jan 2001 20:56:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxod23243 for ; Thu, 11 Jan 2001 20:56:42 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 QQjxod15052 for ; Thu, 11 Jan 2001 20:55:33 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjxod27867 for ; Thu, 11 Jan 2001 20:55:33 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA10738 for ; Thu, 11 Jan 2001 12:55:40 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id PAA02091 for mpls@uu.net; Thu, 11 Jan 2001 15:55:31 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxoc21719 for ; Thu, 11 Jan 2001 20:40: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 QQjxoc22258 for ; Thu, 11 Jan 2001 20:39:42 GMT Received: from celoxnetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-stl-ns1.celoxnetworks.com [12.104.200.2]) id QQjxoc07164 for ; Thu, 11 Jan 2001 20:39:41 GMT Received: from celox-stl-ems1.celoxnetworks.com (celox-stl-imap1.celoxnetworks.com [12.104.200.29]) by celoxnetworks.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12363; Thu, 11 Jan 2001 14:39:36 -0600 (CST) Received: from celoxnetworks.com (copper.celoxnetworks.com [192.168.30.79]) by celox-stl-ems1.celoxnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Z39H0XFM; Thu, 11 Jan 2001 14:37:46 -0600 Message-ID: <3A5E1B78.D40AA120@celoxnetworks.com> Date: Thu, 11 Jan 2001 14:45:44 -0600 From: Chandra Mohan P X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: cheenu@tachion.com CC: mpls@UU.NET Subject: Regd: Static LSP Configuration!! Content-Type: multipart/alternative; boundary="------------52A01514944F21D2DE277423" Sender: owner-mpls@UU.NET Precedence: bulk --------------52A01514944F21D2DE277423 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, If I understand correctly, In the draft , Sec 8 (Example of LSP Setup) describes the scenario, How to set up static LSP configuration at core LSR and Egress LSR using LSR MIB. How will be configure static LSP(Creating FTN Entry) at Ingress LSR using LSR MIB? Thanks in Advance, cmp. --------------52A01514944F21D2DE277423 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

If I understand correctly, In the draft <darft-ietf-mpls-lsr-mib-07.txt> , Sec 8 (Example of LSP Setup) describes the scenario, How to set up static LSP configuration at core LSR and Egress LSR using LSR MIB.

How will be configure static LSP(Creating FTN Entry) at Ingress LSR using LSR MIB?

Thanks in Advance,
cmp.
 
 
  --------------52A01514944F21D2DE277423-- From owner-mpls@UU.NET Thu Jan 11 16:03:24 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14557 for ; Thu, 11 Jan 2001 16:03:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxoe09851; Thu, 11 Jan 2001 21:03:02 GMT Received: by mail-control.mail.uu.net id QQjxoe28550 for mpls-outgoing; Thu, 11 Jan 2001 21:02:45 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxoe28404 for ; Thu, 11 Jan 2001 21:02:40 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjxoe29116 for ; Thu, 11 Jan 2001 21:01:51 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxoe02007 for ; Thu, 11 Jan 2001 21:01:50 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA08458 for mpls@uu.net; Thu, 11 Jan 2001 16:01:50 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxoe26011 for ; Thu, 11 Jan 2001 21:01:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjxoe28688 for ; Thu, 11 Jan 2001 21:01:09 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjxoe07024 for ; Thu, 11 Jan 2001 21:01:09 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA20543; Thu, 11 Jan 2001 13:01:03 -0800 (PST) Message-ID: <3A5E1F0E.D3CEA8B9@pluris.com> Date: Thu, 11 Jan 2001 13:01:03 -0800 From: Bora Akyol X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Greg Richardson CC: mpls@UU.NET Subject: Re: LSP path setup time References: <20010111190406.1200.qmail@web12003.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 It depends on how many hops the LSP is tracing. t_setup= t_comp + N*(t_prop+t_proc) where t_comp is the computation time at the head end, t_prop is the propagation time and t_proc is the per hop processing time and N is the number of hops. t_comp should be in the 10s of milisecond range (if not less, depending on the complexity of the query). Note that after the LSP is setup and the tunnel is declared to be UP, you still have to wait for traffic get redirected into the tunnel either via configuration or via routing protocols. Bora Greg Richardson wrote: > Hello, > > I have a question about establishing explicit LSPs > within an AS. > > Lets assume an ingress would like to setup a fixed > bandwidth LSP between itself and a destination node. > > Suppose we define the establishment phase as two step > process: > > 1) Routing Decision - The ingress typically uses an > iteration of dijkstra's algorithm to compute the > shortest path (based on hop-count or other > constraints). > > 2) Resource Reservation - The ingress uses an > appropriate signaling protocol (such as RSVP-TE)to > explicitly establish the LSP. This includes any > admission control at intermediate nodes, and perhaps > label distribution between peers. > > Although vendor implementation is a huge factor in > determining the relative times to complete either > phase, is it safe to say that the time to complete 2nd > phase almost always dominates the first for a network > consisting of 100's of nodes. > > __________________________________________________ > Do You Yahoo!? > Yahoo! Photos - Share your holiday photos online! > http://photos.yahoo.com/ From owner-mpls@UU.NET Thu Jan 11 16:06:31 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14578 for ; Thu, 11 Jan 2001 16:06:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxoe14719; Thu, 11 Jan 2001 21:06:15 GMT Received: by mail-control.mail.uu.net id QQjxoe04866 for mpls-outgoing; Thu, 11 Jan 2001 21:05:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxoe04478 for ; Thu, 11 Jan 2001 21:05: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 QQjxoe02320 for ; Thu, 11 Jan 2001 21:05:11 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxoe07059 for ; Thu, 11 Jan 2001 21:05:10 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA08986 for mpls@uu.net; Thu, 11 Jan 2001 16:05:10 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxoe02039 for ; Thu, 11 Jan 2001 21:04: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 QQjxoe29920 for ; Thu, 11 Jan 2001 21:04:09 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjxoe11646 for ; Thu, 11 Jan 2001 21:04:08 GMT Received: from pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA20734; Thu, 11 Jan 2001 13:03:58 -0800 (PST) Message-ID: <3A5E1FBE.523814@pluris.com> Date: Thu, 11 Jan 2001 13:03:58 -0800 From: Bora Akyol X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: danny@ambernetworks.com CC: mpls@UU.NET Subject: Re: Comments on martini-l2circuit-encap-mpls-00.txt References: <200101100516.WAA18808@tcb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Danny 1. I believe that you have the option to buffer and reorder packets to an extent if you want to guarantee in-order delivery. 2. RSVP messaging can be used to determine the LSP MTU as well (or configuration as a matter of fact) Bora Danny McPherson wrote: > Section 3: > > "The next 16 bits are the sequence number that is used to guarantee > ordered packet delivery." > > I believe you mean this: > > "The next 16 bits are the sequence number that is used to detect > out-of-order packets." > > And here: > > "PDUs carrying the control word MUST NOT be delivered out of order. > They may be discarded or reordered." > > I think something more along these lines would be clearer: > > "If PDUs carrying the control word arrive out-of-order, they MAY > be discarded or reordered, they MUST NOT be delivered." > > Section 4: > > "If a packet length, once it has been encapsulated on the > ingress LSR, exceeds the LSP MTU, it MUST be dropped." > > How is the "LSP MTU" known here? Presumably, you weren't > referring to the Black LDP MTU draft. > > "If an egress LSR receives a packet on a VC LSP with a length, > once the label stack and sequencing control word have been popped, > that exceeds the MTU of the destination layer 2 interface it MUST > be dropped." > > Wouldn't something more graceful be of benefit here? Perhaps > exchanging the egress interface MTU via LDP? > > Section 5.1: > > "A Frame Relay PDU is transported in its entirety, including the Frame > Relay header. The sequencing control word is OPTIONAL." > > Presumably, you don't actually intend to carry the FCS as well? > > Regarding this: "The BECN and FECN signals are carried unchanged", > perhaps bits or indicators would be more appropriate than 'signals'? > > "The Label Edge Routers", what's a label edge router? Presumably, > you mean Edge LSRs? > > Here: > > "The Label Edge Routers that implement this document MAY, when either > adding or removing the encapsulation described herein, change a zero > to a one in either or both of these bits in order to reflect congestion > in the MPLS network that is known to the LERs." > > There's that LER thing again, though the acronym isn't defined (Anywhere). > Also, I guess disucssion of how an 'LER' knows about "congestion in the > MPLS network" is beyond the scope of the document? > > Regarding this: > > "The ingress LSR MAY consider the DE bit of the Frame Relay header > when determining the value to be placed in the EXP fields of the MPLS > label stack. In a similar way, the egress LSR MAY consider the EXP > field of the VC label when queuing the packet for egress." > > Shouldn't you say something about "the DE value of the encapsulated FR > frame MUST be copied to the DE field of the reconstructed packet before > transmission to the CE (for lack of a better term)". I guess this > would equally apply yo C/R, EA, FECN/BECN, etc.. > > Perhaps simply providing some wording regarding how the egress LSR > handles decap, etc.. would be useful? > > Also, shouldn't something be said regarding the inability to fully > support Frame Relay EA with this model? > > Section 5.2: > > Presumably, you're removing the FCS from the CPCS-PDU before > encapsulation? > > Also, shouldn't you at least mention that you removed the 1 octet > HEC from the ATM cell header before encapsulation? > > "If ATM cells, or a combination of ATM cells and AAL5 CPCS-PDUs, > are to be transported the sequencing control word is required." > > A combination? > > Section 5.2.1: > > I think you should probably scope this sentence: "A router that does > not support transport of OAM cells MUST discard incoming MPLS frames > on an ATM VC LSP that contain an ATM cell with the high-order bit of > the PTI field set to 1." Perhaps you should use "egress LSR" rather > than "a router"? > > Also, how would this work if multiple cells were in the MPLS frame? > > Here: "If an F5 end-to-end OAM cell is received from a VC by an LSR > with a loopback indication value of 1 and the LSR has a label mapping > for the VC, the LSR must decrement the loopback indication value and > loop back the cell on the VC. Otherwise the loopback cell must be > discarded by the LSR." I think you should scope this to "egress LSR", > per simple use of the term 'VC' here soesn't explicitly imply this. > For that matter, defining 'VC' in this context would probably be > useful as well... > > Hrmm, this seems to differ from the model suggested for Frame Relay: > "The egress LSR MAY consider the value of the EXP field of the VC > label when determining the value of the ATM CLP bit." There you only > talk of "when queuing the packet for egress". Consistency would be > good here, the correct model is probably obvious. > > And again, providing exact label decap/cell reconstructing details > would be of benefit here as well. > > Also, why no talk of ATM and FR (I)LMI interaction on the access > side? > > Section 5.3: > > "For an ethernet 802.1q VLAN the entire ethernet frame without the > preamble or FCS is transported as a single packet. The sequencing > control word is OPTIONAL. If a packet is received out of sequence it > MUST be dropped." I think the out of sequence packet should only > be dropped IF the sequencing control word is used. You could merge > these sentences and provide a bit of clarity. Also, you should > tighten up your use of Ethernet/IEEE 802.3/802.1q wording here. > > "The 4 byte VLAN tag is transported as is, and MAY be overwritten by > the egress LSR." this seems loose. Handling by the egress LSR > could be tightened up here. > > "The ingress LSR MAY consider the user priority field [4] of the VLAN > tag header when determining the value to be placed in the EXP fields > of the MPLS label stack. In a similar way, the egress LSR MAY > consider the EXP field of the VC label when queuing the packet for > egress." Why just when queuing, not mapping to the 3-bit P field? > This falls into consistency issue as with ATM and FR. > > "Ethernet packets containing hardware level CRC, Framing > errors, or runt packets MUST be discarded on input." Does > this really belong in this document? > > Section 5.4: > > 5.4. Ethernet > > "As in the Ethernet VLAN case, ethernet packets with hardware level > CRC, framing, and runt packets MUST be discarded on input." I really > don't believe this belongs here either. > > Also, should RFC2469 be mentioned here somewhere? > > Finally, perhaps some consideration on Spanning Tree is in > order here? Or at least providing similar functionality? From owner-mpls@UU.NET Thu Jan 11 16:24:20 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14955 for ; Thu, 11 Jan 2001 16:24:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxof01388; Thu, 11 Jan 2001 21:21:54 GMT Received: by mail-control.mail.uu.net id QQjxof07230 for mpls-outgoing; Thu, 11 Jan 2001 21:21:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxof07224 for ; Thu, 11 Jan 2001 21:21: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 QQjxof07568 for ; Thu, 11 Jan 2001 21:19:32 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxof27813 for ; Thu, 11 Jan 2001 21:19:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA10700 for mpls@uu.net; Thu, 11 Jan 2001 16:19:30 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxof07067 for ; Thu, 11 Jan 2001 21:19: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 QQjxof28525 for ; Thu, 11 Jan 2001 21:17:02 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 QQjxof27779 for ; Thu, 11 Jan 2001 21:17:02 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA22136; Thu, 11 Jan 2001 16:16:36 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-153.cisco.com [161.44.134.153]) by bucket.cisco.com (Mirapoint) with ESMTP id AAM15973; Thu, 11 Jan 2001 16:16:49 -0500 (EST) Message-Id: <4.3.2.7.2.20010111161826.0230c4e8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Jan 2001 16:20:14 -0500 To: Chandra Mohan P From: "Thomas D. Nadeau" Subject: Re: Regd: Static LSP Configuration!! Cc: mpls@UU.NET, cheenu Srinivasan , Arun Viswanathan In-Reply-To: <3A5E1B78.D40AA120@celoxnetworks.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_153762048==_.ALT" Sender: owner-mpls@UU.NET Precedence: bulk --=====================_153762048==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, >If I understand correctly, In the draft , >Sec 8 (Example of LSP Setup) describes the scenario, How to set up static >LSP configuration at core LSR and Egress LSR using LSR MIB. > >How will be configure static LSP(Creating FTN Entry) at Ingress LSR using >LSR MIB? You should point the FTN MIB at the XcIndex of the hand-routed LSP which you just created in the LSR MIB. You create hand-routed LSPs in the LSR MIB by creating XCentries, inSegment, and outSegment entries. --Tom --=====================_153762048==_.ALT Content-Type: text/html; charset="us-ascii"         
        Hi,

If I understand correctly, In the draft <darft-ietf-mpls-lsr-mib-07.txt> , Sec 8 (Example of LSP Setup) describes the scenario, How to set up static LSP configuration at core LSR and Egress LSR using LSR MIB.

How will be configure static LSP(Creating FTN Entry) at Ingress LSR using LSR MIB?

        You should point the FTN MIB at the XcIndex of the hand-routed
LSP which you just created in the LSR MIB. You create hand-routed
LSPs in the LSR MIB by creating XCentries, inSegment, and outSegment
entries.

        --Tom


--=====================_153762048==_.ALT-- From owner-mpls@UU.NET Thu Jan 11 17:11:49 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15522 for ; Thu, 11 Jan 2001 17:11:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxoi20825; Thu, 11 Jan 2001 22:11:25 GMT Received: by mail-control.mail.uu.net id QQjxoi23595 for mpls-outgoing; Thu, 11 Jan 2001 22:10:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxoi23587 for ; Thu, 11 Jan 2001 22:10:49 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 QQjxoi01517 for ; Thu, 11 Jan 2001 22:10:33 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxoi28206 for ; Thu, 11 Jan 2001 22:10:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA14699 for mpls@uu.net; Thu, 11 Jan 2001 17:10:30 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxoi23479 for ; Thu, 11 Jan 2001 22:10:00 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 QQjxoi25311 for ; Thu, 11 Jan 2001 22:09:00 GMT Received: from dnsmx1pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQjxoi12452 for ; Thu, 11 Jan 2001 22:09:00 GMT Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id RAA22461 for ; Thu, 11 Jan 2001 17:06:46 -0500 (EST) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852569D1.007976BE ; Thu, 11 Jan 2001 17:06:42 -0500 X-Lotus-FromDomain: TELCORDIA From: "Ibrahim W. Habib" To: mpls@UU.NET Message-ID: <852569D1.007974D3.00@notes950.cc.telcordia.com> Date: Thu, 11 Jan 2001 17:06:04 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk auth 653fbcd0 subscribe mpls ihabib@telcordia.com From owner-mpls@UU.NET Fri Jan 12 04:50:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06594 for ; Fri, 12 Jan 2001 04:50:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxqd23071; Fri, 12 Jan 2001 09:49:56 GMT Received: by mail-control.mail.uu.net id QQjxqd23949 for mpls-outgoing; Fri, 12 Jan 2001 09:49:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxqd23944 for ; Fri, 12 Jan 2001 09:49:34 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 QQjxqd27028 for ; Fri, 12 Jan 2001 09:48:36 GMT Received: from relay2.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc239.alcatel.be [195.207.101.239]) id QQjxqd25742 for ; Fri, 12 Jan 2001 09:48:36 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.10.1) with SMTP id f0C9jMI07162; Fri, 12 Jan 2001 10:45:22 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569D2.00353C0D; Fri, 12 Jan 2001 10:41:27 +0100 Message-ID: <3A5ED147.348D60DC@alcatel.be> Date: Fri, 12 Jan 2001 10:41:27 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ron Bonica CC: mpls@UU.NET Subject: Re: Last call on MPLS multicast framework References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ron, Sorry for creating the confusion (I guess it is caused by my interpretation of the word 'best' in the dvmrp draft). The RPF check will succeed on the interface where the JOIN message is sent upstream. This can be on an interface different from the interface through which the unicast route would send traffic to reach the source/root (because the multicast topology can differ from the unicast topology). Also, this can be on an interface different from the interface through which the shortest path (in the multicast topology) to the source/root goes (because of traffic-engineered multicast trees, i.e. JOIN messages are not sent on the shortest path to the source/root). The 'RPF check' implementations that I know behave this way (i.e. according to the RPF definition in the PIM spec). dirk Ron Bonica wrote: > > Dirk, > > Now I am really confused. > > From your response, I infer that the RPF check will succeed, even if traffic > arrives on an interface other than that through which the router would send > traffic in order to reach the source. Is this inference correct? If it is > correct, wouldn't RPF code have to change? > > Ron > > > -----Original Message----- > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > Sent: Thursday, January 11, 2001 8:43 AM > > To: Ron Bonica > > Cc: mpls@UU.NET > > Subject: Re: Last call on MPLS multicast framework > > > > > > Ron, > > > > Thanks for your question, it made me revisit the RPF stuff and it turns > > out that it is not correct anymore (because of an 'evolution' in the > > definition of RPF). > > > > from draft-ietf-idmr-dvmrp-v3-10.txt: > > The interface on which the best route to the source of the datagram was > > received is called the upstream (also called RPF) interface. > > > > from draft-ietf-pim-sm-v2-new-01.txt: > > RPF stands for "Reverse Path Forwarding". The RPF Neighbor of a router > > with respect to an address is the neighbor that the MRIB indicates > > should be used to forward packets to that address. In the case of a > > PIM-SM multicast group, the RPF neighbor is the router that a Join > > message for that group would be directed to, in the absence of modifying > > Assert state. > > > > The second definition is more precise because it distinguishes the > > unicast and the multicast topology (MRIB) and it does not mention the > > confusing word 'best' (='shortest'?) anymore. > > > > According to the newest 'definition' of RPF in the PIM draft the issue > > mentioned in section 3.8 (and section 7) does not occur anymore, so I > > will remove it. > > > > dirk > > > > Ron Bonica wrote: > > > > > > Dirk, > > > > > > Two questions: > > > > > > 1) In section 3.8, you say that RPF checks will fail when > > explicit routing > > > causes multicast traffic to arrive on "the wrong interface". Won't RPF > > > checks also fail when MPLS routes traffic through "the wrong > > interface" for > > > any other reason (e.g., traffic engineering constraints)? > > > > > > 2) If RPF checks succeed only when traffic arrives on the > > interface that IGP > > > metrics dictate, what is the benefit of running IP multicast over MPLS? > > > > > > Ron > > From owner-mpls@UU.NET Fri Jan 12 09:33:25 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09637 for ; Fri, 12 Jan 2001 09:33:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxqw07683; Fri, 12 Jan 2001 14:31:52 GMT Received: by mail-control.mail.uu.net id QQjxqw12402 for mpls-outgoing; Fri, 12 Jan 2001 14:31:19 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxqw12372 for ; Fri, 12 Jan 2001 14:30:58 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 QQjxqw05424 for ; Fri, 12 Jan 2001 14:30:21 GMT Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQjxqw29474 for ; Fri, 12 Jan 2001 14:30:21 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f0CETmF04381; Fri, 12 Jan 2001 09:29:48 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; FRI, 12 Jan 2001 09:17:26 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 09:17:26 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E563A817A@newman.tenornet.com> From: "Shah, Himanshu" To: "'erosen@cisco.com'" , Sasha Vainshtein Cc: Alik , "mpls@uu.net" Subject: RE: Requirement for LDP support in the RFC2547bis draft Date: Fri, 12 Jan 2001 09:17:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Eric, Hate to drag this on But.. I am worried that making the LDP as a requirement and therefore a +checkoff+ item for 2547 based VPN, may unnecessarily prohibit some vendors to sell 2547 based VPN with RSVP (and minus LDP). As per somebody's comment on nonog list about early MPLS deployments, RSVP seems to be the "choice for MPLS Traffic Engineering and label switch path creation". Do you think may be a text like following would then be more appropriate? "support for LDP as a mean for LSP setup is desirable for the guarenteed interoperability purposes. However, there is no requirement that LDP actually be used, if some other method is available" Himanshu Tenor networks Acton, MA -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Wednesday, January 10, 2001 11:26 AM To: Sasha Vainshtein Cc: Alik; mpls@uu.net Subject: Re: Requirement for LDP support in the RFC2547bis draft Sasha> I assume that in both cases the LSPs in question are the paths for Sasha> the outer (i.e., PE-to-PE) level encapsulation, and that requirement Sasha> for LDP support states from the fact that such a support would Sasha> gurantee ability to create such an LSP, e.g., by requesting a label Sasha> for the egress PE IP address (known to the ingress PE as the BGP next Sasha> hop) in a standard way. Is this assumption correct? If this is the Sasha> case, do the two quotations actually refer to the same problem and Sasha> its solution? Yes. The requirement for LDP support is there to ensure that two compliant implementations can interoperate. There is no requirement that LDP actually be used, if some other method is available. Sasha> I would also like to understand the subtle difference between the Sasha> (lower case) "must" in the quoted sections of draft-rosen-rfc2547bis- Sasha> 02.txt and the (capitalized keyword) MUST described in RFC2119. I don't think there is any difference between "must" and "MUST" in the section you quoted. From owner-mpls@UU.NET Fri Jan 12 09:47:45 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09926 for ; Fri, 12 Jan 2001 09:47:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxqx23617; Fri, 12 Jan 2001 14:45:48 GMT Received: by mail-control.mail.uu.net id QQjxqx14109 for mpls-outgoing; Fri, 12 Jan 2001 14:45:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxqx14102 for ; Fri, 12 Jan 2001 14:45: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 QQjxqw24560 for ; Fri, 12 Jan 2001 14:43:35 GMT Received: from hermes.research.kpn.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hermes.research.kpn.com [139.63.192.8]) id QQjxqw25544 for ; Fri, 12 Jan 2001 14:43:35 GMT Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JYTPP3NUHW0002XM@research.kpn.com> for mpls@UU.NET; Fri, 12 Jan 2001 15:43:33 +0100 Received: by L04 with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jan 2001 15:43:23 +0100 Content-return: allowed Date: Fri, 12 Jan 2001 15:43:23 +0100 From: "Metz, E.T." Subject: RE: Requirement for LDP support in the RFC2547bis draft To: "'erosen@cisco.com'" , Sasha Vainshtein , "'Shah, Himanshu'" Cc: Alik , "mpls@uu.net" Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A787@L04> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk on the other hand you are at the risk of making a "standard" that is sufficiently open-ended that interoperability is no longer an option. i think this is a big issue. cheers, eduard > ---------- > From: Shah, Himanshu[SMTP:hshah@tenornetworks.com] > Sent: vrijdag 12 januari 2001 15:17 > To: 'erosen@cisco.com'; Sasha Vainshtein > Cc: Alik; mpls@uu.net > Subject: RE: Requirement for LDP support in the RFC2547bis draft > > Eric, > > Hate to drag this on But.. > > I am worried that making the LDP as a requirement and therefore > a +checkoff+ item for 2547 based VPN, may unnecessarily prohibit > some vendors to sell 2547 based VPN with RSVP (and minus LDP). > > As per somebody's comment on nonog list about early MPLS deployments, > RSVP seems to be the "choice for MPLS Traffic Engineering and label switch > > path creation". > > Do you think may be a text like following would then be more appropriate? > > "support for LDP as a mean for LSP setup is desirable for the guarenteed > interoperability purposes. However, there is no requirement that LDP > actually be used, if some other method is available" > > Himanshu > Tenor networks > Acton, MA > > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Wednesday, January 10, 2001 11:26 AM > To: Sasha Vainshtein > Cc: Alik; mpls@uu.net > Subject: Re: Requirement for LDP support in the RFC2547bis draft > > > Sasha> I assume that in both cases the LSPs in question are the paths > for > Sasha> the outer (i.e., PE-to-PE) level encapsulation, and that > requirement > Sasha> for LDP support states from the fact that such a support > would > Sasha> gurantee ability to create such an LSP, e.g., by requesting a > label > Sasha> for the egress PE IP address (known to the ingress PE as the BGP > next > Sasha> hop) in a standard way. Is this assumption correct? If this is > the > Sasha> case, do the two quotations actually refer to the same problem > and > Sasha> its solution? > > Yes. The requirement for LDP support is there to ensure that two > compliant > implementations can interoperate. There is no requirement that LDP > actually > be used, if some other method is available. > > Sasha> I would also like to understand the subtle difference between > the > Sasha> (lower case) "must" in the quoted sections of > draft-rosen-rfc2547bis- > Sasha> 02.txt and the (capitalized keyword) MUST described in RFC2119. > > I don't think there is any difference between "must" and "MUST" in > the > section you quoted. > From owner-mpls@UU.NET Fri Jan 12 10:13:16 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10294 for ; Fri, 12 Jan 2001 10:13:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxqy10767; Fri, 12 Jan 2001 15:09:46 GMT Received: by mail-control.mail.uu.net id QQjxqy24955 for mpls-outgoing; Fri, 12 Jan 2001 15:09:19 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxqy24881 for ; Fri, 12 Jan 2001 15:09:14 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 QQjxqy20672 for ; Fri, 12 Jan 2001 15:08:12 GMT Received: from redbaron.nexabit.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: d28.nexabit.com [209.6.34.253]) id QQjxqy07506 for ; Fri, 12 Jan 2001 15:08:12 GMT Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id KAA07708; Fri, 12 Jan 2001 10:09:33 -0500 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 10:07:24 -0500 Message-ID: From: Barry Hass To: "Metz, E.T." , "'erosen@cisco.com'" , Sasha Vainshtein , "'Shah, Himanshu'" Cc: Alik , "mpls@uu.net" Subject: RE: Requirement for LDP support in the RFC2547bis draft Date: Fri, 12 Jan 2001 10:07:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk True. But my sense is that there are currently more vendors delivering RSVP-TE than LDP. So what is the rationale for choosing LDP as the standard for this application? Barry > -----Original Message----- > From: Metz, E.T. [mailto:E.T.Metz@kpn.com] > Sent: Friday, January 12, 2001 9:43 AM > To: 'erosen@cisco.com'; Sasha Vainshtein; 'Shah, Himanshu' > Cc: Alik; mpls@uu.net > Subject: RE: Requirement for LDP support in the RFC2547bis draft > > > on the other hand you are at the risk of making a "standard" that is > sufficiently open-ended that interoperability is no longer an > option. i > think this is a big issue. > > cheers, > eduard > > > ---------- > > From: Shah, Himanshu[SMTP:hshah@tenornetworks.com] > > Sent: vrijdag 12 januari 2001 15:17 > > To: 'erosen@cisco.com'; Sasha Vainshtein > > Cc: Alik; mpls@uu.net > > Subject: RE: Requirement for LDP support in the RFC2547bis draft > > > > Eric, > > > > Hate to drag this on But.. > > > > I am worried that making the LDP as a requirement and therefore > > a +checkoff+ item for 2547 based VPN, may unnecessarily prohibit > > some vendors to sell 2547 based VPN with RSVP (and minus LDP). > > > > As per somebody's comment on nonog list about early MPLS > deployments, > > RSVP seems to be the "choice for MPLS Traffic Engineering > and label switch > > > > path creation". > > > > Do you think may be a text like following would then be > more appropriate? > > > > "support for LDP as a mean for LSP setup is desirable for > the guarenteed > > interoperability purposes. However, there is no requirement > that LDP > > actually be used, if some other method is available" > > > > Himanshu > > Tenor networks > > Acton, MA > > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Wednesday, January 10, 2001 11:26 AM > > To: Sasha Vainshtein > > Cc: Alik; mpls@uu.net > > Subject: Re: Requirement for LDP support in the RFC2547bis draft > > > > > > Sasha> I assume that in both cases the LSPs in question > are the paths > > for > > Sasha> the outer (i.e., PE-to-PE) level encapsulation, and that > > requirement > > Sasha> for LDP support states from the fact that such > a support > > would > > Sasha> gurantee ability to create such an LSP, e.g., by > requesting a > > label > > Sasha> for the egress PE IP address (known to the ingress > PE as the BGP > > next > > Sasha> hop) in a standard way. Is this assumption > correct? If this is > > the > > Sasha> case, do the two quotations actually refer to the > same problem > > and > > Sasha> its solution? > > > > Yes. The requirement for LDP support is there to ensure that two > > compliant > > implementations can interoperate. There is no requirement that LDP > > actually > > be used, if some other method is available. > > > > Sasha> I would also like to understand the subtle > difference between > > the > > Sasha> (lower case) "must" in the quoted sections of > > draft-rosen-rfc2547bis- > > Sasha> 02.txt and the (capitalized keyword) MUST described > in RFC2119. > > > > I don't think there is any difference between "must" > and "MUST" in > > the > > section you quoted. > > > From owner-mpls@UU.NET Fri Jan 12 10:17:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10366 for ; Fri, 12 Jan 2001 10:17:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxqz14597; Fri, 12 Jan 2001 15:16:30 GMT Received: by mail-control.mail.uu.net id QQjxqz29753 for mpls-outgoing; Fri, 12 Jan 2001 15:15:53 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxqz29734 for ; Fri, 12 Jan 2001 15:15: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 QQjxqz15651 for ; Fri, 12 Jan 2001 15:15:00 GMT Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQjxqz21220 for ; Fri, 12 Jan 2001 15:15:00 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f0CFEKF13712; Fri, 12 Jan 2001 10:14:20 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; FRI, 12 Jan 2001 10:01:59 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 10:01:59 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E563A817B@newman.tenornet.com> From: "Shah, Himanshu" To: "'Metz, E.T.'" , "'erosen@cisco.com'" , Sasha Vainshtein , "Shah, Himanshu" Cc: Alik , "mpls@uu.net" Subject: RE: Requirement for LDP support in the RFC2547bis draft Date: Fri, 12 Jan 2001 10:01:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I understand your point. But I am not sure if RSVP-TE draft notes that it is only an alternative LSP setup method and in order to be interoperable in MPLS deployments one must support LDP. If that is true, then it would be unfair to have service specifications on top of MPLS dictate one or other LSP setup mechanism as the 'must' requirement, IMHO. -----Original Message----- From: Metz, E.T. [mailto:E.T.Metz@kpn.com] Sent: Friday, January 12, 2001 9:43 AM To: 'erosen@cisco.com'; Sasha Vainshtein; 'Shah, Himanshu' Cc: Alik; mpls@uu.net Subject: RE: Requirement for LDP support in the RFC2547bis draft on the other hand you are at the risk of making a "standard" that is sufficiently open-ended that interoperability is no longer an option. i think this is a big issue. cheers, eduard > ---------- > From: Shah, Himanshu[SMTP:hshah@tenornetworks.com] > Sent: vrijdag 12 januari 2001 15:17 > To: 'erosen@cisco.com'; Sasha Vainshtein > Cc: Alik; mpls@uu.net > Subject: RE: Requirement for LDP support in the RFC2547bis draft > > Eric, > > Hate to drag this on But.. > > I am worried that making the LDP as a requirement and therefore > a +checkoff+ item for 2547 based VPN, may unnecessarily prohibit > some vendors to sell 2547 based VPN with RSVP (and minus LDP). > > As per somebody's comment on nonog list about early MPLS deployments, > RSVP seems to be the "choice for MPLS Traffic Engineering and label switch > > path creation". > > Do you think may be a text like following would then be more appropriate? > > "support for LDP as a mean for LSP setup is desirable for the guarenteed > interoperability purposes. However, there is no requirement that LDP > actually be used, if some other method is available" > > Himanshu > Tenor networks > Acton, MA > > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: Wednesday, January 10, 2001 11:26 AM > To: Sasha Vainshtein > Cc: Alik; mpls@uu.net > Subject: Re: Requirement for LDP support in the RFC2547bis draft > > > Sasha> I assume that in both cases the LSPs in question are the paths > for > Sasha> the outer (i.e., PE-to-PE) level encapsulation, and that > requirement > Sasha> for LDP support states from the fact that such a support > would > Sasha> gurantee ability to create such an LSP, e.g., by requesting a > label > Sasha> for the egress PE IP address (known to the ingress PE as the BGP > next > Sasha> hop) in a standard way. Is this assumption correct? If this is > the > Sasha> case, do the two quotations actually refer to the same problem > and > Sasha> its solution? > > Yes. The requirement for LDP support is there to ensure that two > compliant > implementations can interoperate. There is no requirement that LDP > actually > be used, if some other method is available. > > Sasha> I would also like to understand the subtle difference between > the > Sasha> (lower case) "must" in the quoted sections of > draft-rosen-rfc2547bis- > Sasha> 02.txt and the (capitalized keyword) MUST described in RFC2119. > > I don't think there is any difference between "must" and "MUST" in > the > section you quoted. > From owner-mpls@UU.NET Fri Jan 12 11:28:15 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11736 for ; Fri, 12 Jan 2001 11:28:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxrd08837; Fri, 12 Jan 2001 16:26:36 GMT Received: by mail-control.mail.uu.net id QQjxrd21357 for mpls-outgoing; Fri, 12 Jan 2001 16:26:02 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxrd21332 for ; Fri, 12 Jan 2001 16:25: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 QQjxrd07013 for ; Fri, 12 Jan 2001 16:24:56 GMT Received: from hermes.research.kpn.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hermes.research.kpn.com [139.63.192.8]) id QQjxrd06014 for ; Fri, 12 Jan 2001 16:24:51 GMT Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JYTT8IRFKM0002AR@research.kpn.com> for mpls@UU.NET; Fri, 12 Jan 2001 17:24:46 +0100 Received: by L04 with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jan 2001 17:24:33 +0100 Content-return: allowed Date: Fri, 12 Jan 2001 17:24:30 +0100 From: "Metz, E.T." Subject: RE: Requirement for LDP support in the RFC2547bis draft To: "'Metz, E.T.'" , "'erosen@cisco.com'" , Sasha Vainshtein , "'Shah, Himanshu'" Cc: Alik , "mpls@uu.net" Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A78D@L04> 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'm not exactly sure I understand what you mean with your remark on RSVP-TE. What really is required for rfc2547bis VPN is that there is an LSP between a PE and the BGP nexthop (another PE) for the VPN traffic it needs to forward. It is true that it does not really matter how this LSP gets there, as long as it does. However, if you leave at this, there is no way to ensure even minimal interoperability. Therefor, to ensure minimal interoperability between multiple, different implementations one method of setting this LSP has to be chosen. Since LDP is a basic label distribution protocol that does the trick this seems to me a valid choice (out of static, RSVP -designed for traffic engineering-, CR-LDP -designed for traffic engineering-, pigeons -to pollute amsterdam-, etc ...) In addition to minimal interoperability anyone is free to add more ways of setting up the PE-to-PE LSPs. I can understand your feeling of unfairness, in particular since base-MPLS documents do not really lay down the law when it comes to label distribution. However, these are the choices made (which have resulted in the majority of vendors implementing RSVP-TE since traffic engineering was the most interesting application ... ). But in general standards tend to dictate, that is more or less what makes them standards. cheers, Eduard > ---------- > From: Shah, Himanshu[SMTP:hshah@tenornetworks.com] > Sent: vrijdag 12 januari 2001 16:01 > To: 'Metz, E.T.'; 'erosen@cisco.com'; Sasha Vainshtein; Shah, Himanshu > Cc: Alik; mpls@uu.net > Subject: RE: Requirement for LDP support in the RFC2547bis draft > > I understand your point. But I am not sure if RSVP-TE draft > notes that it is only an alternative LSP setup method and > in order to be interoperable in MPLS deployments one must > support LDP. > > If that is true, then it would be unfair to > have service specifications on top of MPLS dictate one or > other LSP setup mechanism as the 'must' requirement, IMHO. > > > -----Original Message----- > From: Metz, E.T. [mailto:E.T.Metz@kpn.com] > Sent: Friday, January 12, 2001 9:43 AM > To: 'erosen@cisco.com'; Sasha Vainshtein; 'Shah, Himanshu' > Cc: Alik; mpls@uu.net > Subject: RE: Requirement for LDP support in the RFC2547bis draft > > > on the other hand you are at the risk of making a "standard" that is > sufficiently open-ended that interoperability is no longer an option. i > think this is a big issue. > > cheers, > eduard > > > ---------- > > From: Shah, Himanshu[SMTP:hshah@tenornetworks.com] > > Sent: vrijdag 12 januari 2001 15:17 > > To: 'erosen@cisco.com'; Sasha Vainshtein > > Cc: Alik; mpls@uu.net > > Subject: RE: Requirement for LDP support in the RFC2547bis draft > > > > Eric, > > > > Hate to drag this on But.. > > > > I am worried that making the LDP as a requirement and therefore > > a +checkoff+ item for 2547 based VPN, may unnecessarily prohibit > > some vendors to sell 2547 based VPN with RSVP (and minus LDP). > > > > As per somebody's comment on nonog list about early MPLS deployments, > > RSVP seems to be the "choice for MPLS Traffic Engineering and label > switch > > > > path creation". > > > > Do you think may be a text like following would then be more > appropriate? > > > > "support for LDP as a mean for LSP setup is desirable for the guarenteed > > interoperability purposes. However, there is no requirement that LDP > > actually be used, if some other method is available" > > > > Himanshu > > Tenor networks > > Acton, MA > > > > -----Original Message----- > > From: Eric Rosen [mailto:erosen@cisco.com] > > Sent: Wednesday, January 10, 2001 11:26 AM > > To: Sasha Vainshtein > > Cc: Alik; mpls@uu.net > > Subject: Re: Requirement for LDP support in the RFC2547bis draft > > > > > > Sasha> I assume that in both cases the LSPs in question are the paths > > for > > Sasha> the outer (i.e., PE-to-PE) level encapsulation, and that > > requirement > > Sasha> for LDP support states from the fact that such a support > > would > > Sasha> gurantee ability to create such an LSP, e.g., by requesting a > > label > > Sasha> for the egress PE IP address (known to the ingress PE as the BGP > > next > > Sasha> hop) in a standard way. Is this assumption correct? If this is > > the > > Sasha> case, do the two quotations actually refer to the same problem > > and > > Sasha> its solution? > > > > Yes. The requirement for LDP support is there to ensure that two > > compliant > > implementations can interoperate. There is no requirement that LDP > > actually > > be used, if some other method is available. > > > > Sasha> I would also like to understand the subtle difference between > > the > > Sasha> (lower case) "must" in the quoted sections of > > draft-rosen-rfc2547bis- > > Sasha> 02.txt and the (capitalized keyword) MUST described in RFC2119. > > > > I don't think there is any difference between "must" and "MUST" in > > the > > section you quoted. > > > From owner-mpls@UU.NET Fri Jan 12 11:40:10 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11925 for ; Fri, 12 Jan 2001 11:40:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxre02032; Fri, 12 Jan 2001 16:38:32 GMT Received: by mail-control.mail.uu.net id QQjxre22870 for mpls-outgoing; Fri, 12 Jan 2001 16:38:00 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxre22865 for ; Fri, 12 Jan 2001 16:37: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 QQjxre08752 for ; Fri, 12 Jan 2001 16:36:08 GMT Received: from bridge.axiowave.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.axiowave.com [209.6.34.2]) id QQjxre23842 for ; Fri, 12 Jan 2001 16:36:08 GMT Message-ID: From: Jeff Parker To: "'Metz, E.T.'" , "'Shah, Himanshu'" Cc: "'mpls@UU.NET'" Subject: RE: Requirement for LDP support in the RFC2547bis draft Date: Fri, 12 Jan 2001 11:35:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > But in general standards tend to dictate, > that is more or less what makes them standards. Agreed. But it is a good dictator that manages to stay out in front of where he people are going anyway. - jeff parker From owner-mpls@UU.NET Fri Jan 12 11:45:01 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12059 for ; Fri, 12 Jan 2001 11:45:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxre16236; Fri, 12 Jan 2001 16:43:27 GMT Received: by mail-control.mail.uu.net id QQjxre23472 for mpls-outgoing; Fri, 12 Jan 2001 16:43:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxre23464 for ; Fri, 12 Jan 2001 16:42:59 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 QQjxre14876 for ; Fri, 12 Jan 2001 16:42:18 GMT Received: from redbaron.nexabit.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: d28.nexabit.com [209.6.34.253]) id QQjxre03278 for ; Fri, 12 Jan 2001 16:42:17 GMT Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id LAA08232; Fri, 12 Jan 2001 11:43:33 -0500 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 11:41:24 -0500 Message-ID: From: Barry Hass To: "Metz, E.T." , "'erosen@cisco.com'" , Sasha Vainshtein , "'Shah, Himanshu'" Cc: Alik , "mpls@uu.net" Subject: RE: Requirement for LDP support in the RFC2547bis draft Date: Fri, 12 Jan 2001 11:41:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I think Himanshu's suggested wording, or something close to it, is a reasonable compromise. "support for LDP as a mean for LSP setup is desirable for the guarenteed interoperability purposes. However, there is no requirement that LDP actually be used, if some other method is available" I read this as encouraging LDP support for interoperability purposes, but allowing vendors who don't have it to still claim compliance with the spec, albeit under a limited set of conditions. Can people live with that? From owner-mpls@UU.NET Fri Jan 12 13:49:58 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14945 for ; Fri, 12 Jan 2001 13:49:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxrn17766; Fri, 12 Jan 2001 18:47:54 GMT Received: by mail-control.mail.uu.net id QQjxrn28130 for mpls-outgoing; Fri, 12 Jan 2001 18:47:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxrn28125 for ; Fri, 12 Jan 2001 18:47:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjxrm17950 for ; Fri, 12 Jan 2001 18:44:23 GMT Received: from hermes.research.kpn.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hermes.research.kpn.com [139.63.192.8]) id QQjxrm12093 for ; Fri, 12 Jan 2001 18:44:23 GMT Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JYTY4MF2EQ0003FL@research.kpn.com> for mpls@UU.NET; Fri, 12 Jan 2001 19:44:22 +0100 Received: by L04 with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Jan 2001 19:44:11 +0100 Content-return: allowed Date: Fri, 12 Jan 2001 19:44:10 +0100 From: "Metz, E.T." Subject: RE: Requirement for LDP support in the RFC2547bis draft To: "Metz, E.T." , "'erosen@cisco.com'" , Sasha Vainshtein , "'Shah, Himanshu'" , "'Barry Hass'" Cc: Alik , "mpls@uu.net" Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A790@L04> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk I do not really like trading required (always interoperable), for something less (if you're lucky) If the requirement is to be removed anyway, then I'd suggest to make: - LDP RECOMMENDED / SHOULD be supported, - any other method OPTIONAL / MAY be supported, - and the presence of the PE-to-PE LSPs REQUIRED / MUST be there. ("desirable" has no real meaning to it, "should" more or less represents what Barry describes below as "encouraging LDP support") cheers, Eduard ps may "any other method" should be somewhat limited to a smaller, more standard set of methods. > ---------- > From: Barry Hass[SMTP:BHass@nexabit.com] > Sent: vrijdag 12 januari 2001 17:41 > To: Metz, E.T.; 'erosen@cisco.com'; Sasha Vainshtein; 'Shah, Himanshu' > Cc: Alik; mpls@uu.net > Subject: RE: Requirement for LDP support in the RFC2547bis draft > > I think Himanshu's suggested wording, or something close > to it, is a reasonable compromise. > > "support for LDP as a mean for LSP setup is desirable for the guarenteed > interoperability purposes. However, there is no requirement that LDP > actually be used, if some other method is available" > > I read this as encouraging LDP support for interoperability > purposes, but allowing vendors who don't have it to still claim > compliance with the spec, albeit under a limited set of conditions. > > Can people live with that? > From owner-mpls@UU.NET Fri Jan 12 16:35:12 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25174 for ; Fri, 12 Jan 2001 16:35:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxry15933; Fri, 12 Jan 2001 21:34:54 GMT Received: by mail-control.mail.uu.net id QQjxry12150 for mpls-outgoing; Fri, 12 Jan 2001 21:34:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxry12143 for ; Fri, 12 Jan 2001 21:34: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 QQjxry14154 for ; Fri, 12 Jan 2001 21:33:36 GMT Received: from redbaron.nexabit.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: d28.nexabit.com [209.6.34.253]) id QQjxry13138 for ; Fri, 12 Jan 2001 21:33:36 GMT Received: from bandito.nexabit.com (bandito.nexabit.com [135.17.240.4]) by redbaron.nexabit.com (8.9.3/8.9.3) with ESMTP id QAA09825; Fri, 12 Jan 2001 16:33:50 -0500 Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Jan 2001 16:31:38 -0500 Message-ID: From: Barry Hass To: "Metz, E.T." , "'erosen@cisco.com'" , Sasha Vainshtein , "'Shah, Himanshu'" , Barry Hass Cc: Alik , "mpls@uu.net" Subject: RE: Requirement for LDP support in the RFC2547bis draft Date: Fri, 12 Jan 2001 16:31:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Eduard, In theory, I agree with you. But in this particular case, specifying a requirement for one signalling protocol is liable to lead to a discussion of which one it should be. And I REALLY don't want to go there. I think your suggested wording is fine. Thank you for translating the original suggestion into standard draft-speak. As an aside, and keeping in mind that I don't want to start a discussion of the merits of the choice, I would be curious to know why the authors of 2547 chose LDP, rather than RSVP-TE as a standard for interoperability. Barry > -----Original Message----- > From: Metz, E.T. [mailto:E.T.Metz@kpn.com] > Sent: Friday, January 12, 2001 1:44 PM > To: Metz, E.T.; 'erosen@cisco.com'; Sasha Vainshtein; 'Shah, > Himanshu'; > 'Barry Hass' > Cc: Alik; mpls@uu.net > Subject: RE: Requirement for LDP support in the RFC2547bis draft > > > I do not really like trading required (always interoperable), > for something > less (if you're lucky) > > If the requirement is to be removed anyway, then I'd suggest to make: > - LDP RECOMMENDED / SHOULD be supported, > - any other method OPTIONAL / MAY be supported, > - and the presence of the PE-to-PE LSPs REQUIRED / MUST be there. > ("desirable" has no real meaning to it, "should" more or less > represents > what Barry describes below as "encouraging LDP support") > > cheers, > Eduard > > ps may "any other method" should be somewhat limited to a > smaller, more > standard set of methods. > > > ---------- > > From: Barry Hass[SMTP:BHass@nexabit.com] > > Sent: vrijdag 12 januari 2001 17:41 > > To: Metz, E.T.; 'erosen@cisco.com'; Sasha > Vainshtein; 'Shah, Himanshu' > > Cc: Alik; mpls@uu.net > > Subject: RE: Requirement for LDP support in the RFC2547bis draft > > > > I think Himanshu's suggested wording, or something close > > to it, is a reasonable compromise. > > > > "support for LDP as a mean for LSP setup is desirable for > the guarenteed > > interoperability purposes. However, there is no requirement > that LDP > > actually be used, if some other method is available" > > > > I read this as encouraging LDP support for interoperability > > purposes, but allowing vendors who don't have it to still claim > > compliance with the spec, albeit under a limited set of conditions. > > > > Can people live with that? > > > From owner-mpls@UU.NET Fri Jan 12 18:08:30 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26707 for ; Fri, 12 Jan 2001 18:08:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxse06980; Fri, 12 Jan 2001 23:08:15 GMT Received: by mail-control.mail.uu.net id QQjxse14876 for mpls-outgoing; Fri, 12 Jan 2001 23:07:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxse14785 for ; Fri, 12 Jan 2001 23:07:31 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 QQjxse22442 for ; Fri, 12 Jan 2001 23:07:02 GMT Received: from postal.redback.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: postal.redback.com [155.53.12.9]) id QQjxse01567 for ; Fri, 12 Jan 2001 23:07:01 GMT Received: from cheers.redback.com (cheers.redback.com [155.53.36.203]) by postal.redback.com (Postfix) with ESMTP id 1E72D17BC47; Fri, 12 Jan 2001 15:07:01 -0800 (PST) Received: (from roque@localhost) by cheers.redback.com (8.8.8/8.8.8/null redback bsdclient) id PAA13317; Fri, 12 Jan 2001 15:07:01 -0800 (PST) From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14943.36372.879465.605730@cheers.redback.com> Date: Fri, 12 Jan 2001 15:07:00 -0800 (PST) To: Barry Hass Cc: "mpls@uu.net" Subject: RE: Requirement for LDP support in the RFC2547bis draft In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Barry" == Barry Hass writes: Barry> As an aside, and keeping in mind that I don't want to start Barry> a discussion of the merits of the choice, I would be Barry> curious to know why the authors of 2547 chose LDP, rather Barry> than RSVP-TE as a standard for interoperability. With LDP you have much less signaling to do... you have it assign labels for your possible paths and you are just using your IGP to pick the shortest-path. RSVP + a path computation tool requires significantly more signaling in the network and it is an overkill on the simplest case since typically an explicit path is not needed. LDP + IGP will also converge faster than IGP + path computation tool + RSVP, unless you calculate an very substantial number of backup paths. These are different tools for different problem sets... LDP maps well to the problem of providing full-mesh LSP connectivity to all edges of your network following IGP shortest path. Computing explicit paths maps well to divert parts of your traffic from shortest path. You can* use explicit paths (+ whatever signaling protocol your fancy) to run a tag vpn network on top. But that is not the simplest solution to the problem and it will (most likely) require engineering the network apropriatly. Pedro. *It would be actually interesting to know how far a full mesh edge-to-edge of explicit paths would scale. From owner-mpls@UU.NET Fri Jan 12 19:28:31 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27232 for ; Fri, 12 Jan 2001 19:28:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxsj23912; Sat, 13 Jan 2001 00:28:16 GMT Received: by mail-control.mail.uu.net id QQjxsj04893 for mpls-outgoing; Sat, 13 Jan 2001 00:26:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxsj04859 for ; Sat, 13 Jan 2001 00:26:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjxsj16303 for ; Sat, 13 Jan 2001 00:26:21 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxsj21010 for ; Sat, 13 Jan 2001 00:26:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA12013 for mpls@uu.net; Fri, 12 Jan 2001 19:26:20 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxsj04819 for ; Sat, 13 Jan 2001 00:26:07 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 QQjxsj14606 for ; Sat, 13 Jan 2001 00:25:38 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjxsj28920 for ; Sat, 13 Jan 2001 00:25:37 GMT Received: from cisco.com (war-jer-dhcp84.cisco.com [144.254.89.254]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA09828; Fri, 12 Jan 2001 16:25:32 -0800 (PST) Message-ID: <3A5F9421.70197C7C@cisco.com> Date: Fri, 12 Jan 2001 15:32:49 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pedro Roque Marques CC: Barry Hass , "mpls@uu.net" Subject: Re: Requirement for LDP support in the RFC2547bis draft References: <14943.36372.879465.605730@cheers.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit In addition to what Pedro already said let me add a comment that running a mpls-vpns on mpls-te only without LDP is a quite challanging task. TE in genral was build to optimize the routing paths. When it fails for whatever reason you fall back to pure IP and IP reachability is fine. When TE fails for whatever reason while you are using it for mpls-vpns your 10s or 100s of customers connected to given PEs are simply unreachable with the peers to which PE's broken TE tunnel was going to. P routers do not maintain any of the VPN information. I am not going to bring here all protection you can use for TE just wanted to bring up this point. LDP by it's nature has much more less constrains which could cause it to fail and in most of today's implementations I have seen can be as robust as the IGP you are running. R. > Pedro Roque Marques wrote: > > >>>>> "Barry" == Barry Hass writes: > > Barry> As an aside, and keeping in mind that I don't want to start > Barry> a discussion of the merits of the choice, I would be > Barry> curious to know why the authors of 2547 chose LDP, rather > Barry> than RSVP-TE as a standard for interoperability. > > With LDP you have much less signaling to do... you have it assign > labels for your possible paths and you are just using your IGP to pick > the shortest-path. RSVP + a path computation tool requires > significantly more signaling in the network and it is an overkill on > the simplest case since typically an explicit path is not needed. > > LDP + IGP will also converge faster than IGP + path computation tool + > RSVP, unless you calculate an very substantial number of backup paths. > > These are different tools for different problem sets... LDP maps well > to the problem of providing full-mesh LSP connectivity to all edges of > your network following IGP shortest path. Computing explicit paths > maps well to divert parts of your traffic from shortest path. > > You can* use explicit paths (+ whatever signaling protocol your fancy) > to run a tag vpn network on top. But that is not the simplest solution > to the problem and it will (most likely) require engineering the > network apropriatly. > > Pedro. > > *It would be actually interesting to know how far a full mesh > edge-to-edge of explicit paths would scale. From owner-mpls@UU.NET Fri Jan 12 20:21:58 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27579 for ; Fri, 12 Jan 2001 20:21:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxsn28740; Sat, 13 Jan 2001 01:21:45 GMT Received: by mail-control.mail.uu.net id QQjxsn21537 for mpls-outgoing; Sat, 13 Jan 2001 01:21:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxsn21505 for ; Sat, 13 Jan 2001 01:21:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjxsn17020 for ; Sat, 13 Jan 2001 01:20:31 GMT Received: from tcb.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQjxsn09603 for ; Sat, 13 Jan 2001 01:20:31 GMT Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id SAA30862 for ; Fri, 12 Jan 2001 18:20:17 -0700 Message-Id: <200101130120.SAA30862@tcb.net> X-Mailer: exmh version 2.0.3 To: mpls@UU.NET From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: Re: Comments on martini-l2circuit-encap-mpls-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Jan 2001 18:20:17 -0700 Sender: owner-mpls@UU.NET Precedence: bulk > 1. I believe that you have the option to buffer and reorder > packets to an extent if you want to guarantee in-order > delivery. Yeah, I was aware of this, though I'd be interested in knowing how many folks could actually do it (I know if at least one :-) My point was only that the wording makes it sound as if it *ensures* in order delivery -- it doesn't. It only provides a mechanism to detect out-of-order PDUs. > 2. RSVP messaging can be used to determine the LSP MTU as > well (or configuration as a matter of fact) Yeah, guess I should have mentioned this (and perhaps the draft as well) along with the LDP stuff. -danny From owner-mpls@UU.NET Fri Jan 12 20:40:24 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27740 for ; Fri, 12 Jan 2001 20:40:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxso18283; Sat, 13 Jan 2001 01:39:52 GMT Received: by mail-control.mail.uu.net id QQjxso23104 for mpls-outgoing; Sat, 13 Jan 2001 01:39:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxso23092 for ; Sat, 13 Jan 2001 01:39:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjxso18006 for ; Sat, 13 Jan 2001 01:38:43 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxso02366 for ; Sat, 13 Jan 2001 01:38:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA15909 for mpls@uu.net; Fri, 12 Jan 2001 20:38:42 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxso23038 for ; Sat, 13 Jan 2001 01:38:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjxso10370 for ; Sat, 13 Jan 2001 01:37:57 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjxso23588 for ; Sat, 13 Jan 2001 01:37:57 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA12550; Fri, 12 Jan 2001 17:37:56 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14943.45427.950000.432351@gargle.gargle.HOWL> Date: Fri, 12 Jan 2001 17:37:55 -0800 To: danny@ambernetworks.com Cc: mpls@UU.NET Subject: Re: Comments on martini-l2circuit-encap-mpls-00.txt In-Reply-To: <200101130120.SAA30862@tcb.net> References: <200101130120.SAA30862@tcb.net> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Agreed, but the proposed mods that were mentioned earlier would almost possibly ban buffering and ordering packets with the sequence numbers altogether. Bora >>>>> "Danny" == Danny McPherson writes: >> 1. I believe that you have the option to buffer and >> reorder packets to an extent if you want to guarantee >> in-order delivery. Danny> Yeah, I was aware of this, though I'd be interested Danny> in knowing how many folks could actually do it (I Danny> know if at least one :-) My point was only that the Danny> wording makes it sound as if it *ensures* in order Danny> delivery -- it doesn't. It only provides a mechanism Danny> to detect out-of-order PDUs. >> 2. RSVP messaging can be used to determine the LSP MTU as >> well (or configuration as a matter of fact) Danny> Yeah, guess I should have mentioned this (and perhaps Danny> the draft as well) along with the LDP stuff. Danny> -danny From owner-mpls@UU.NET Fri Jan 12 20:55:03 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27898 for ; Fri, 12 Jan 2001 20:55:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxsp17455; Sat, 13 Jan 2001 01:54:52 GMT Received: by mail-control.mail.uu.net id QQjxsp24757 for mpls-outgoing; Sat, 13 Jan 2001 01:54:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxsp24747 for ; Sat, 13 Jan 2001 01:54:22 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 QQjxsp04350 for ; Sat, 13 Jan 2001 01:54:03 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxsp21727 for ; Sat, 13 Jan 2001 01:54:03 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA16995 for mpls@uu.net; Fri, 12 Jan 2001 20:54:02 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxsp24709 for ; Sat, 13 Jan 2001 01:53: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 QQjxsp12426 for ; Sat, 13 Jan 2001 01:53:02 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjxsp14957 for ; Sat, 13 Jan 2001 01:53:02 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA13805; Fri, 12 Jan 2001 17:53:01 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14943.46332.703000.553768@gargle.gargle.HOWL> Date: Fri, 12 Jan 2001 17:53:00 -0800 To: mpls@UU.NET, kireeti@juniper.net, yakov@juniper.net Subject: ERO object for unnumbered interfaces X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit All for the sake of clarity, can we change the ERO object for unnumbered interfaces from: Figure 2: Unnumbered Interface ID Subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Reserved (MUST be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ to: Figure 2: Unnumbered Interface ID Subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Reserved (MUST be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (32 bits) | ----------------------------------------------------------------- | Interface ID (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This makes the ERO object globally unique for even an unnumbered interface and it makes implementation much easier. This also aligns better with the TLVs that are coming from the IGPs. Thanks Bora From owner-mpls@UU.NET Fri Jan 12 21:06:49 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27995 for ; Fri, 12 Jan 2001 21:06:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxsq12789; Sat, 13 Jan 2001 02:06:40 GMT Received: by mail-control.mail.uu.net id QQjxsq07495 for mpls-outgoing; Sat, 13 Jan 2001 02:06:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxsq07458 for ; Sat, 13 Jan 2001 02:06: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 QQjxsq01099 for ; Sat, 13 Jan 2001 02:05:55 GMT Received: from tcb.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tcb.net [205.168.100.1]) id QQjxsq24638 for ; Sat, 13 Jan 2001 02:05:55 GMT Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id TAA31097 for ; Fri, 12 Jan 2001 19:05:41 -0700 Message-Id: <200101130205.TAA31097@tcb.net> X-Mailer: exmh version 2.0.3 To: mpls@UU.NET From: Danny McPherson Reply-To: danny@ambernetworks.com Subject: draft-malis-sonet-ces-mpls-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 12 Jan 2001 19:05:41 -0700 Sender: owner-mpls@UU.NET Precedence: bulk [Modified Resend] In this document you specify that you're encapsulating TDM digital signals for transmission over a packet- oriented network. Before one can ask to many questions, it's important to know whether you're attempting to emulate Section, Line or Path? Seemingly, the only hint of this relates to the terse discussion of Path AIS is Section 6.1, though it's by no means explicit. Presumably, the intent is to emulate Path, though I'm quite sure the current specification is insufficient. For example, handling of SOH & LOH can't simply be ignored and/or replayed as 'raw bit streams'. I guess there are a number of ways to go about doing this, though ALL the apparent ones seem to introduce a number of interesting implications. I agree that it's indeed feasible, but such implications brought about by ANY such proposal need to be expressly documented therein. Thanks! -danny From owner-mpls@UU.NET Sat Jan 13 17:46:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20598 for ; Sat, 13 Jan 2001 17:46:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxvv24143; Sat, 13 Jan 2001 22:46:11 GMT Received: by mail-control.mail.uu.net id QQjxvv01790 for mpls-outgoing; Sat, 13 Jan 2001 22:45:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxvv01785 for ; Sat, 13 Jan 2001 22:45:42 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 QQjxvv06144 for ; Sat, 13 Jan 2001 22:45:28 GMT Received: from NOD.RESTON.MCI.NET by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [166.60.6.38]) id QQjxvv01222 for ; Sat, 13 Jan 2001 22:45:27 GMT Received: from rbonica ([166.60.18.132]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JYV89JV6CK9LVTZY@shoe.reston.mci.net> for mpls@UU.NET; Sat, 13 Jan 2001 17:45:27 EST Date: Sat, 13 Jan 2001 17:35:52 -0500 From: Ron Bonica Subject: RE: Last call on MPLS multicast framework In-reply-to: <3A5ED147.348D60DC@alcatel.be> To: Dirk Ooms Cc: mpls@UU.NET Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Dirk, If this is the case, what benefit does an ISP derive by running IP multicast traffic over MPLS? I may be missing something very fundamental. Please reorient me if I am. Ron > -----Original Message----- > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > Sent: Friday, January 12, 2001 4:41 AM > To: Ron Bonica > Cc: mpls@UU.NET > Subject: Re: Last call on MPLS multicast framework > > > Ron, > > Sorry for creating the confusion (I guess it is caused by my > interpretation of the word 'best' in the dvmrp draft). > > The RPF check will succeed on the interface where the JOIN message is > sent upstream. This can be on an interface different from the interface > through which the unicast route would send traffic to reach the > source/root (because the multicast topology can differ from the unicast > topology). Also, this can be on an interface different from the > interface through which the shortest path (in the multicast topology) to > the source/root goes (because of traffic-engineered multicast trees, > i.e. JOIN messages are not sent on the shortest path to the > source/root). The 'RPF check' implementations that I know behave this > way (i.e. according to the RPF definition in the PIM spec). > > dirk > > Ron Bonica wrote: > > > > Dirk, > > > > Now I am really confused. > > > > From your response, I infer that the RPF check will succeed, > even if traffic > > arrives on an interface other than that through which the > router would send > > traffic in order to reach the source. Is this inference > correct? If it is > > correct, wouldn't RPF code have to change? > > > > Ron > > > > > -----Original Message----- > > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > > Sent: Thursday, January 11, 2001 8:43 AM > > > To: Ron Bonica > > > Cc: mpls@UU.NET > > > Subject: Re: Last call on MPLS multicast framework > > > > > > > > > Ron, > > > > > > Thanks for your question, it made me revisit the RPF stuff > and it turns > > > out that it is not correct anymore (because of an 'evolution' in the > > > definition of RPF). > > > > > > from draft-ietf-idmr-dvmrp-v3-10.txt: > > > The interface on which the best route to the source of the > datagram was > > > received is called the upstream (also called RPF) interface. > > > > > > from draft-ietf-pim-sm-v2-new-01.txt: > > > RPF stands for "Reverse Path Forwarding". The RPF Neighbor > of a router > > > with respect to an address is the neighbor that the MRIB indicates > > > should be used to forward packets to that address. In the case of a > > > PIM-SM multicast group, the RPF neighbor is the router that a Join > > > message for that group would be directed to, in the absence > of modifying > > > Assert state. > > > > > > The second definition is more precise because it distinguishes the > > > unicast and the multicast topology (MRIB) and it does not mention the > > > confusing word 'best' (='shortest'?) anymore. > > > > > > According to the newest 'definition' of RPF in the PIM draft the issue > > > mentioned in section 3.8 (and section 7) does not occur anymore, so I > > > will remove it. > > > > > > dirk > > > > > > Ron Bonica wrote: > > > > > > > > Dirk, > > > > > > > > Two questions: > > > > > > > > 1) In section 3.8, you say that RPF checks will fail when > > > explicit routing > > > > causes multicast traffic to arrive on "the wrong > interface". Won't RPF > > > > checks also fail when MPLS routes traffic through "the wrong > > > interface" for > > > > any other reason (e.g., traffic engineering constraints)? > > > > > > > > 2) If RPF checks succeed only when traffic arrives on the > > > interface that IGP > > > > metrics dictate, what is the benefit of running IP > multicast over MPLS? > > > > > > > > Ron > > > > From owner-mpls@UU.NET Sat Jan 13 18:09:13 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20743 for ; Sat, 13 Jan 2001 18:09:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxvw27708; Sat, 13 Jan 2001 23:08:49 GMT Received: by mail-control.mail.uu.net id QQjxvw14747 for mpls-outgoing; Sat, 13 Jan 2001 23:08:32 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjxvw14742 for ; Sat, 13 Jan 2001 23:08:29 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 QQjxvw12783 for ; Sat, 13 Jan 2001 23:08:18 GMT Received: from smtp1.phx.gblx.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp1.phx.gblx.net [64.208.25.103]) id QQjxvw26954 for ; Sat, 13 Jan 2001 23:08:18 GMT Received: (from daemon@localhost) by smtp1.phx.gblx.net (8.11.1/8.11.0.Beta1) id f0DN89u22402; Sat, 13 Jan 2001 16:08:09 -0700 (MST) Received: from UNKNOWN(208.50.189.218), claiming to be "plonka" via SMTP by smtp1, id smtpdAAAljaaVR; Sat Jan 13 16:08:03 2001 From: Jonathon Plonka To: Ron Bonica Cc: Dirk Ooms , mpls@UU.NET Subject: Re: Last call on MPLS multicast framework Date: Sat, 13 Jan 2001 15:07:53 -0800 Organization: Global Crossing Reply-To: jplonka@gblx.net Message-ID: References: <3A5ED147.348D60DC@alcatel.be> In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA20743 Some ISPs are moving to a strict MPLS backbone and minimizing as much native IP traffic as possible. This is in preparation for the eventual transition to an mpls enabled optically switched core. -jonp On Sat, 13 Jan 2001 17:35:52 -0500, Ron Bonica wrote: >Dirk, > >If this is the case, what benefit does an ISP derive by running IP multicast >traffic over MPLS? > >I may be missing something very fundamental. Please reorient me if I am. > > Ron > > >> -----Original Message----- >> From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] >> Sent: Friday, January 12, 2001 4:41 AM >> To: Ron Bonica >> Cc: mpls@UU.NET >> Subject: Re: Last call on MPLS multicast framework >> >> >> Ron, >> >> Sorry for creating the confusion (I guess it is caused by my >> interpretation of the word 'best' in the dvmrp draft). >> >> The RPF check will succeed on the interface where the JOIN message is >> sent upstream. This can be on an interface different from the interface >> through which the unicast route would send traffic to reach the >> source/root (because the multicast topology can differ from the unicast >> topology). Also, this can be on an interface different from the >> interface through which the shortest path (in the multicast topology) to >> the source/root goes (because of traffic-engineered multicast trees, >> i.e. JOIN messages are not sent on the shortest path to the >> source/root). The 'RPF check' implementations that I know behave this >> way (i.e. according to the RPF definition in the PIM spec). >> >> dirk >> >> Ron Bonica wrote: >> > >> > Dirk, >> > >> > Now I am really confused. >> > >> > From your response, I infer that the RPF check will succeed, >> even if traffic >> > arrives on an interface other than that through which the >> router would send >> > traffic in order to reach the source. Is this inference >> correct? If it is >> > correct, wouldn't RPF code have to change? >> > >> > Ron >> > >> > > -----Original Message----- >> > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] >> > > Sent: Thursday, January 11, 2001 8:43 AM >> > > To: Ron Bonica >> > > Cc: mpls@UU.NET >> > > Subject: Re: Last call on MPLS multicast framework >> > > >> > > >> > > Ron, >> > > >> > > Thanks for your question, it made me revisit the RPF stuff >> and it turns >> > > out that it is not correct anymore (because of an 'evolution' in the >> > > definition of RPF). >> > > >> > > from draft-ietf-idmr-dvmrp-v3-10.txt: >> > > The interface on which the best route to the source of the >> datagram was >> > > received is called the upstream (also called RPF) interface. >> > > >> > > from draft-ietf-pim-sm-v2-new-01.txt: >> > > RPF stands for "Reverse Path Forwarding". The RPF Neighbor >> of a router >> > > with respect to an address is the neighbor that the MRIB indicates >> > > should be used to forward packets to that address. In the case of a >> > > PIM-SM multicast group, the RPF neighbor is the router that a Join >> > > message for that group would be directed to, in the absence >> of modifying >> > > Assert state. >> > > >> > > The second definition is more precise because it distinguishes the >> > > unicast and the multicast topology (MRIB) and it does not mention the >> > > confusing word 'best' (='shortest'?) anymore. >> > > >> > > According to the newest 'definition' of RPF in the PIM draft the issue >> > > mentioned in section 3.8 (and section 7) does not occur anymore, so I >> > > will remove it. >> > > >> > > dirk >> > > >> > > Ron Bonica wrote: >> > > > >> > > > Dirk, >> > > > >> > > > Two questions: >> > > > >> > > > 1) In section 3.8, you say that RPF checks will fail when >> > > explicit routing >> > > > causes multicast traffic to arrive on "the wrong >> interface". Won't RPF >> > > > checks also fail when MPLS routes traffic through "the wrong >> > > interface" for >> > > > any other reason (e.g., traffic engineering constraints)? >> > > > >> > > > 2) If RPF checks succeed only when traffic arrives on the >> > > interface that IGP >> > > > metrics dictate, what is the benefit of running IP >> multicast over MPLS? >> > > > >> > > > Ron >> > > >> > From owner-mpls@UU.NET Sun Jan 14 07:50:56 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08245 for ; Sun, 14 Jan 2001 07:50:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxxz00552; Sun, 14 Jan 2001 12:50:46 GMT Received: by mail-control.mail.uu.net id QQjxxz09246 for mpls-outgoing; Sun, 14 Jan 2001 12:50:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjxxz09241 for ; Sun, 14 Jan 2001 12:50:23 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 QQjxxz19378 for ; Sun, 14 Jan 2001 12:50:00 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjxxz09690 for ; Sun, 14 Jan 2001 12:49:59 GMT Received: from cirwm3nt01.nor.bt.com by gandalf (local) with ESMTP; Sun, 14 Jan 2001 12:49:03 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Sun, 14 Jan 2001 12:49:45 -0000 Message-ID: To: raszuk@cisco.com, roque@redback.com Cc: BHass@nexabit.com, mpls@UU.NET, peter.j.willis@bt.com Subject: RE: Requirement for LDP support in the RFC2547bis draft Date: Sun, 14 Jan 2001 12:49:39 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Here's an observation for you all to consider, and something I think should be an important factor in this discussion: If, as an operator, I sell a VPN (any technology....so think about all possibilities here) then I really need to associate that VPN with a pair of SLAs. One SLA covers the up-sate (=availability) performance of the VPN and the other SLA covers QoS (ie the transfer performance which is expected *when, and only when* the VPN is available). IP alone is cnls in behaviour. This means that failures are converted into 'QoS hits', ie when the IGP re-converges after a failure, whatever BW resources that are left are shared amongst the *same* number of users. If there is only one forwarding class (eg BE say) then all affected customers get a uniform reduction in resource. If there are multiple forwarding classes (ie DiffServ) then there is a skewed bias of resource to favour EF, then AF11, then....etc. This is fine for certain traffic types, but not others.....and esp not for VPNs IMHO. That is, in a cnls fabric we cannot differentiate between the up-state SLA and the QoS SLA. This observation has the further corollaries: (i) the *survivability* of a certain traffic-type has no relationship to its required up-state QoS forwarding treatment. For example, irrespective of whether voice is or is-not a mission critical traffic entity in a given VPN (or work-group partition of a given VPN) it has to go EF to meet the jitter transfer requirements of such a traffic type. (ii) if same-DS-classes are merged (eg on an LSP) across multiple VPNs, then on failure the traffic that survives is a function of the traffic types (ie EF, AFxy) that were active at the time of failure *and* across all VPNs. It is therefore not clear (to me anyway) how to state what % of what VPN has therefore survived post-failure. This means that it may be very hard (=impossible?) to create distinct avail and QoS SLAs for VPNs using certain technologies. However, if I was a customer buying a VPN I would not care about any other customer's VPN or how the operator was delivering my VPN, all I would care about was knowing that my VPN had a certain overall survivability index (which I am paying for) and that the operator would be able to detect all failures and take appropriate actions (including protecting my traffic from leaking out or being 'hit' by any mismerging defects......there is someway to go on just these aspects that OAM work is trying to address). The QoS aspects would be of secondary importance to the avail behaviour and its SLA. And it was against the above considerations that I have already suggested to colleagues here that RSVP (say) LSPs might be a better way to provide VPNs rather than using LDP (as the server LSP layers). We note of course, that what we are really talking about here is the emulation of traditional hard-BW partioned L2 VPNs. However, if one wants to offer disjoint(across VPN pop)/robust/measurable/varying(on price) avail SLAs for VPNs, one has to consider the above factors. Neil -----Original Message----- From: Robert Raszuk [mailto:raszuk@cisco.com] Sent: 12 January 2001 23:33 To: Pedro Roque Marques Cc: Barry Hass; mpls@uu.net Subject: Re: Requirement for LDP support in the RFC2547bis draft In addition to what Pedro already said let me add a comment that running a mpls-vpns on mpls-te only without LDP is a quite challanging task. TE in genral was build to optimize the routing paths. When it fails for whatever reason you fall back to pure IP and IP reachability is fine. When TE fails for whatever reason while you are using it for mpls-vpns your 10s or 100s of customers connected to given PEs are simply unreachable with the peers to which PE's broken TE tunnel was going to. P routers do not maintain any of the VPN information. I am not going to bring here all protection you can use for TE just wanted to bring up this point. LDP by it's nature has much more less constrains which could cause it to fail and in most of today's implementations I have seen can be as robust as the IGP you are running. R. > Pedro Roque Marques wrote: > > >>>>> "Barry" == Barry Hass writes: > > Barry> As an aside, and keeping in mind that I don't want to start > Barry> a discussion of the merits of the choice, I would be > Barry> curious to know why the authors of 2547 chose LDP, rather > Barry> than RSVP-TE as a standard for interoperability. > > With LDP you have much less signaling to do... you have it assign > labels for your possible paths and you are just using your IGP to pick > the shortest-path. RSVP + a path computation tool requires > significantly more signaling in the network and it is an overkill on > the simplest case since typically an explicit path is not needed. > > LDP + IGP will also converge faster than IGP + path computation tool + > RSVP, unless you calculate an very substantial number of backup paths. > > These are different tools for different problem sets... LDP maps well > to the problem of providing full-mesh LSP connectivity to all edges of > your network following IGP shortest path. Computing explicit paths > maps well to divert parts of your traffic from shortest path. > > You can* use explicit paths (+ whatever signaling protocol your fancy) > to run a tag vpn network on top. But that is not the simplest solution > to the problem and it will (most likely) require engineering the > network apropriatly. > > Pedro. > > *It would be actually interesting to know how far a full mesh > edge-to-edge of explicit paths would scale. From owner-mpls@UU.NET Sun Jan 14 15:10:19 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10376 for ; Sun, 14 Jan 2001 15:10:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxzc27902; Sun, 14 Jan 2001 20:10:00 GMT Received: by mail-control.mail.uu.net id QQjxzc10481 for mpls-outgoing; Sun, 14 Jan 2001 20:09:29 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxzc10474 for ; Sun, 14 Jan 2001 20:09:19 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 QQjxzc10543 for ; Sun, 14 Jan 2001 20:09:16 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxzc21059 for ; Sun, 14 Jan 2001 20:09:15 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA06472 for mpls@uu.net; Sun, 14 Jan 2001 15:09:14 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxzc10465 for ; Sun, 14 Jan 2001 20:08:59 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 QQjxzc07760 for ; Sun, 14 Jan 2001 20:08:04 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjxzc23723 for ; Sun, 14 Jan 2001 20:08:03 GMT Received: from cisco.com (war-jer-dhcp84.cisco.com [144.254.89.254]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA06869; Sun, 14 Jan 2001 12:07:35 -0800 (PST) Message-ID: <3A61FAAF.FD8FA1D5@cisco.com> Date: Sun, 14 Jan 2001 11:14:55 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jplonka@gblx.net CC: Ron Bonica , Dirk Ooms , mpls@UU.NET Subject: Re: Last call on MPLS multicast framework References: <3A5ED147.348D60DC@alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > >If this is the case, what benefit does an ISP derive by running IP multicast > >traffic over MPLS? Another one would be a drastic reduction of m-cast states in the core if runned in conjunction with hierarchical PIM for example. R. > Jonathon Plonka wrote: > > Some ISPs are moving to a strict MPLS backbone and minimizing as much > native IP traffic as possible. This is in preparation for the eventual > transition to an mpls enabled optically switched core. > -jonp > > On Sat, 13 Jan 2001 17:35:52 -0500, Ron Bonica wrote: > > >Dirk, > > > >If this is the case, what benefit does an ISP derive by running IP multicast > >traffic over MPLS? > > > >I may be missing something very fundamental. Please reorient me if I am. > > > > Ron > > > > > >> -----Original Message----- > >> From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > >> Sent: Friday, January 12, 2001 4:41 AM > >> To: Ron Bonica > >> Cc: mpls@UU.NET > >> Subject: Re: Last call on MPLS multicast framework > >> > >> > >> Ron, > >> > >> Sorry for creating the confusion (I guess it is caused by my > >> interpretation of the word 'best' in the dvmrp draft). > >> > >> The RPF check will succeed on the interface where the JOIN message is > >> sent upstream. This can be on an interface different from the interface > >> through which the unicast route would send traffic to reach the > >> source/root (because the multicast topology can differ from the unicast > >> topology). Also, this can be on an interface different from the > >> interface through which the shortest path (in the multicast topology) to > >> the source/root goes (because of traffic-engineered multicast trees, > >> i.e. JOIN messages are not sent on the shortest path to the > >> source/root). The 'RPF check' implementations that I know behave this > >> way (i.e. according to the RPF definition in the PIM spec). > >> > >> dirk > >> > >> Ron Bonica wrote: > >> > > >> > Dirk, > >> > > >> > Now I am really confused. > >> > > >> > From your response, I infer that the RPF check will succeed, > >> even if traffic > >> > arrives on an interface other than that through which the > >> router would send > >> > traffic in order to reach the source. Is this inference > >> correct? If it is > >> > correct, wouldn't RPF code have to change? > >> > > >> > Ron > >> > > >> > > -----Original Message----- > >> > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > >> > > Sent: Thursday, January 11, 2001 8:43 AM > >> > > To: Ron Bonica > >> > > Cc: mpls@UU.NET > >> > > Subject: Re: Last call on MPLS multicast framework > >> > > > >> > > > >> > > Ron, > >> > > > >> > > Thanks for your question, it made me revisit the RPF stuff > >> and it turns > >> > > out that it is not correct anymore (because of an 'evolution' in the > >> > > definition of RPF). > >> > > > >> > > from draft-ietf-idmr-dvmrp-v3-10.txt: > >> > > The interface on which the best route to the source of the > >> datagram was > >> > > received is called the upstream (also called RPF) interface. > >> > > > >> > > from draft-ietf-pim-sm-v2-new-01.txt: > >> > > RPF stands for "Reverse Path Forwarding". The RPF Neighbor > >> of a router > >> > > with respect to an address is the neighbor that the MRIB indicates > >> > > should be used to forward packets to that address. In the case of a > >> > > PIM-SM multicast group, the RPF neighbor is the router that a Join > >> > > message for that group would be directed to, in the absence > >> of modifying > >> > > Assert state. > >> > > > >> > > The second definition is more precise because it distinguishes the > >> > > unicast and the multicast topology (MRIB) and it does not mention the > >> > > confusing word 'best' (='shortest'?) anymore. > >> > > > >> > > According to the newest 'definition' of RPF in the PIM draft the issue > >> > > mentioned in section 3.8 (and section 7) does not occur anymore, so I > >> > > will remove it. > >> > > > >> > > dirk > >> > > > >> > > Ron Bonica wrote: > >> > > > > >> > > > Dirk, > >> > > > > >> > > > Two questions: > >> > > > > >> > > > 1) In section 3.8, you say that RPF checks will fail when > >> > > explicit routing > >> > > > causes multicast traffic to arrive on "the wrong > >> interface". Won't RPF > >> > > > checks also fail when MPLS routes traffic through "the wrong > >> > > interface" for > >> > > > any other reason (e.g., traffic engineering constraints)? > >> > > > > >> > > > 2) If RPF checks succeed only when traffic arrives on the > >> > > interface that IGP > >> > > > metrics dictate, what is the benefit of running IP > >> multicast over MPLS? > >> > > > > >> > > > Ron > >> > > > >> > > From owner-mpls@UU.NET Sun Jan 14 15:21:49 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10430 for ; Sun, 14 Jan 2001 15:21:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjxzd00123; Sun, 14 Jan 2001 20:21:23 GMT Received: by mail-control.mail.uu.net id QQjxzd11509 for mpls-outgoing; Sun, 14 Jan 2001 20:20:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjxzd11503 for ; Sun, 14 Jan 2001 20:20: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 QQjxzd20653 for ; Sun, 14 Jan 2001 20:19:56 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjxzd18110 for ; Sun, 14 Jan 2001 20:19:55 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA07140 for mpls@uu.net; Sun, 14 Jan 2001 15:19:54 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjxzd11467 for ; Sun, 14 Jan 2001 20:19: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 QQjxzd29631 for ; Sun, 14 Jan 2001 20:18:00 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjxzd13867 for ; Sun, 14 Jan 2001 20:18:00 GMT Received: from cisco.com (war-jer-dhcp84.cisco.com [144.254.89.254]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA07172; Sun, 14 Jan 2001 12:17:51 -0800 (PST) Message-ID: <3A61FD17.C02D08BC@cisco.com> Date: Sun, 14 Jan 2001 11:25:11 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: roque@redback.com, BHass@nexabit.com, mpls@UU.NET, peter.j.willis@bt.com Subject: Re: Requirement for LDP support in the RFC2547bis draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Neil, > And it was against the above considerations that I have already suggested to > colleagues here that RSVP (say) LSPs might be a better way to provide VPNs > rather than using LDP (as the server LSP layers). By all means the suggestions to use RSVP LSPs for achiving your SLA goals are fine. My comment was issued from a bit of a different angle. What I meant to say that this is good to engineer your VPN traffic either for L3VPN or L2VPN with TE LSPs but it is also somewhow desirable to have a fall back protection just in case your TE LSPs fail. Yes you may protect it locally on each link it travels through or protect your LSPs end to end but still I would fell much better as the operator when I know that even if my entire TE fails VPN packets are still not lost but delivered to the other end based on the EXP field bits they carry. So my comment was addressing this scenario rather then intending to say that RSVP established LSPs are not good at all. In the same light I read Eric's indication that LDP should be the least common denominator for interoperable VPNs implementations. R. > neil.2.harrison@bt.com wrote: > > Here's an observation for you all to consider, and something I think should > be an important factor in this discussion: > > If, as an operator, I sell a VPN (any technology....so think about all > possibilities here) then I really need to associate that VPN with a pair of > SLAs. One SLA covers the up-sate (=availability) performance of the VPN and > the other SLA covers QoS (ie the transfer performance which is expected > *when, and only when* the VPN is available). > > IP alone is cnls in behaviour. This means that failures are converted into > 'QoS hits', ie when the IGP re-converges after a failure, whatever BW > resources that are left are shared amongst the *same* number of users. If > there is only one forwarding class (eg BE say) then all affected customers > get a uniform reduction in resource. If there are multiple forwarding > classes (ie DiffServ) then there is a skewed bias of resource to favour EF, > then AF11, then....etc. This is fine for certain traffic types, but not > others.....and esp not for VPNs IMHO. That is, in a cnls fabric we cannot > differentiate between the up-state SLA and the QoS SLA. This observation > has the further corollaries: > (i) the *survivability* of a certain traffic-type has no relationship to its > required up-state QoS forwarding treatment. For example, irrespective of > whether voice is or is-not a mission critical traffic entity in a given VPN > (or work-group partition of a given VPN) it has to go EF to meet the jitter > transfer requirements of such a traffic type. > (ii) if same-DS-classes are merged (eg on an LSP) across multiple VPNs, then > on failure the traffic that survives is a function of the traffic types (ie > EF, AFxy) that were active at the time of failure *and* across all VPNs. It > is therefore not clear (to me anyway) how to state what % of what VPN has > therefore survived post-failure. > > This means that it may be very hard (=impossible?) to create distinct avail > and QoS SLAs for VPNs using certain technologies. However, if I was a > customer buying a VPN I would not care about any other customer's VPN or how > the operator was delivering my VPN, all I would care about was knowing that > my VPN had a certain overall survivability index (which I am paying for) and > that the operator would be able to detect all failures and take appropriate > actions (including protecting my traffic from leaking out or being 'hit' by > any mismerging defects......there is someway to go on just these aspects > that OAM work is trying to address). The QoS aspects would be of secondary > importance to the avail behaviour and its SLA. > > And it was against the above considerations that I have already suggested to > colleagues here that RSVP (say) LSPs might be a better way to provide VPNs > rather than using LDP (as the server LSP layers). We note of course, that > what we are really talking about here is the emulation of traditional > hard-BW partioned L2 VPNs. However, if one wants to offer disjoint(across > VPN pop)/robust/measurable/varying(on price) avail SLAs for VPNs, one has to > consider the above factors. > > Neil > > -----Original Message----- > From: Robert Raszuk [mailto:raszuk@cisco.com] > Sent: 12 January 2001 23:33 > To: Pedro Roque Marques > Cc: Barry Hass; mpls@uu.net > Subject: Re: Requirement for LDP support in the RFC2547bis draft > > In addition to what Pedro already said let me add a comment that running > a mpls-vpns on mpls-te only without LDP is a quite challanging task. TE > in genral was build to optimize the routing paths. When it fails for > whatever reason you fall back to pure IP and IP reachability is fine. > > When TE fails for whatever reason while you are using it for mpls-vpns > your 10s or 100s of customers connected to given PEs are simply > unreachable with the peers to which PE's broken TE tunnel was going to. > P routers do not maintain any of the VPN information. > > I am not going to bring here all protection you can use for TE just > wanted to bring up this point. LDP by it's nature has much more less > constrains which could cause it to fail and in most of today's > implementations I have seen can be as robust as the IGP you are running. > > R. > > > Pedro Roque Marques wrote: > > > > >>>>> "Barry" == Barry Hass writes: > > > > Barry> As an aside, and keeping in mind that I don't want to start > > Barry> a discussion of the merits of the choice, I would be > > Barry> curious to know why the authors of 2547 chose LDP, rather > > Barry> than RSVP-TE as a standard for interoperability. > > > > With LDP you have much less signaling to do... you have it assign > > labels for your possible paths and you are just using your IGP to pick > > the shortest-path. RSVP + a path computation tool requires > > significantly more signaling in the network and it is an overkill on > > the simplest case since typically an explicit path is not needed. > > > > LDP + IGP will also converge faster than IGP + path computation tool + > > RSVP, unless you calculate an very substantial number of backup paths. > > > > These are different tools for different problem sets... LDP maps well > > to the problem of providing full-mesh LSP connectivity to all edges of > > your network following IGP shortest path. Computing explicit paths > > maps well to divert parts of your traffic from shortest path. > > > > You can* use explicit paths (+ whatever signaling protocol your fancy) > > to run a tag vpn network on top. But that is not the simplest solution > > to the problem and it will (most likely) require engineering the > > network apropriatly. > > > > Pedro. > > > > *It would be actually interesting to know how far a full mesh > > edge-to-edge of explicit paths would scale. From owner-mpls@UU.NET Mon Jan 15 04:48:23 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00022 for ; Mon, 15 Jan 2001 04:48:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjybf15907; Mon, 15 Jan 2001 09:48:12 GMT Received: by mail-control.mail.uu.net id QQjybf04844 for mpls-outgoing; Mon, 15 Jan 2001 09:47:39 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjybf04837 for ; Mon, 15 Jan 2001 09:47: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 QQjybf07751 for ; Mon, 15 Jan 2001 09:46:20 GMT Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQjybf15345 for ; Mon, 15 Jan 2001 09:46:19 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f0F9k5x17758; Mon, 15 Jan 2001 10:46:05 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569D5.0035A23D; Mon, 15 Jan 2001 10:45:49 +0100 Message-ID: <3A62C6CD.A92B9535@alcatel.be> Date: Mon, 15 Jan 2001 10:45:49 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ron Bonica CC: mpls@UU.NET Subject: Re: Last call on MPLS multicast framework References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The same benefits as running IP unicast over MPLS. dirk Ron Bonica wrote: > > Dirk, > > If this is the case, what benefit does an ISP derive by running IP multicast > traffic over MPLS? > > I may be missing something very fundamental. Please reorient me if I am. > > Ron > > > -----Original Message----- > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > Sent: Friday, January 12, 2001 4:41 AM > > To: Ron Bonica > > Cc: mpls@UU.NET > > Subject: Re: Last call on MPLS multicast framework > > > > > > Ron, > > > > Sorry for creating the confusion (I guess it is caused by my > > interpretation of the word 'best' in the dvmrp draft). > > > > The RPF check will succeed on the interface where the JOIN message is > > sent upstream. This can be on an interface different from the interface > > through which the unicast route would send traffic to reach the > > source/root (because the multicast topology can differ from the unicast > > topology). Also, this can be on an interface different from the > > interface through which the shortest path (in the multicast topology) to > > the source/root goes (because of traffic-engineered multicast trees, > > i.e. JOIN messages are not sent on the shortest path to the > > source/root). The 'RPF check' implementations that I know behave this > > way (i.e. according to the RPF definition in the PIM spec). > > > > dirk > > > > Ron Bonica wrote: > > > > > > Dirk, > > > > > > Now I am really confused. > > > > > > From your response, I infer that the RPF check will succeed, > > even if traffic > > > arrives on an interface other than that through which the > > router would send > > > traffic in order to reach the source. Is this inference > > correct? If it is > > > correct, wouldn't RPF code have to change? > > > > > > Ron > > > > > > > -----Original Message----- > > > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > > > Sent: Thursday, January 11, 2001 8:43 AM > > > > To: Ron Bonica > > > > Cc: mpls@UU.NET > > > > Subject: Re: Last call on MPLS multicast framework > > > > > > > > > > > > Ron, > > > > > > > > Thanks for your question, it made me revisit the RPF stuff > > and it turns > > > > out that it is not correct anymore (because of an 'evolution' in the > > > > definition of RPF). > > > > > > > > from draft-ietf-idmr-dvmrp-v3-10.txt: > > > > The interface on which the best route to the source of the > > datagram was > > > > received is called the upstream (also called RPF) interface. > > > > > > > > from draft-ietf-pim-sm-v2-new-01.txt: > > > > RPF stands for "Reverse Path Forwarding". The RPF Neighbor > > of a router > > > > with respect to an address is the neighbor that the MRIB indicates > > > > should be used to forward packets to that address. In the case of a > > > > PIM-SM multicast group, the RPF neighbor is the router that a Join > > > > message for that group would be directed to, in the absence > > of modifying > > > > Assert state. > > > > > > > > The second definition is more precise because it distinguishes the > > > > unicast and the multicast topology (MRIB) and it does not mention the > > > > confusing word 'best' (='shortest'?) anymore. > > > > > > > > According to the newest 'definition' of RPF in the PIM draft the issue > > > > mentioned in section 3.8 (and section 7) does not occur anymore, so I > > > > will remove it. > > > > > > > > dirk > > > > > > > > Ron Bonica wrote: > > > > > > > > > > Dirk, > > > > > > > > > > Two questions: > > > > > > > > > > 1) In section 3.8, you say that RPF checks will fail when > > > > explicit routing > > > > > causes multicast traffic to arrive on "the wrong > > interface". Won't RPF > > > > > checks also fail when MPLS routes traffic through "the wrong > > > > interface" for > > > > > any other reason (e.g., traffic engineering constraints)? > > > > > > > > > > 2) If RPF checks succeed only when traffic arrives on the > > > > interface that IGP > > > > > metrics dictate, what is the benefit of running IP > > multicast over MPLS? > > > > > > > > > > Ron > > > > > > From owner-mpls@UU.NET Mon Jan 15 10:05:45 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06951 for ; Mon, 15 Jan 2001 10:05:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyca12079; Mon, 15 Jan 2001 15:05:09 GMT Received: by mail-control.mail.uu.net id QQjyca04954 for mpls-outgoing; Mon, 15 Jan 2001 15:04:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjyca04899 for ; Mon, 15 Jan 2001 15:04:28 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 QQjyca28053 for ; Mon, 15 Jan 2001 15:03:28 GMT Received: from wiprom2mx1.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQjyca12564 for ; Mon, 15 Jan 2001 15:03:25 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id UAA02545 for ; Mon, 15 Jan 2001 20:40:44 GMT Received: from wipro.com ([192.168.220.54]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA6350 for ; Mon, 15 Jan 2001 20:30:44 +0530 Message-ID: <3A6311EC.A3A09868@wipro.com> Date: Mon, 15 Jan 2001 20:36:22 +0530 From: "Amarnath Honnavalli Anantharamaiah" X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Doubts in ldp draft ???? Content-Type: multipart/alternative; boundary="------------7FAF3A4CB456B120710FE646" Sender: owner-mpls@UU.NET Precedence: bulk --------------7FAF3A4CB456B120710FE646 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQjyca12079 Content-Transfer-Encoding: quoted-printable In the Appendix of the LDP draft A.1.6 Recognize New FEC [1] FEC.5. Generate Event Received Label Mapping from Next Hop ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I don=92t understand this.......................... Does'nt this repeat the process of distributing Label mapping message to the peers again. This is already done in FEC.1 for Downstream Unsolicited Independent as well as Downstream Unsolicited Ordered contro mode ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [2] FEC.1, In case of downstream unsolicited Ordered control mode, Why should we loop between 1, 2 when we are not egress or label mapping is not received from next hop. I feel that this is meaning less. We can straight away go to FEC.2 if above condition not satisfied else loop for each peer and distribute the mapping message to all the peers. I just wanted to confirm with my understanding. Am I right in saying like this.... For Downstream Unsolicited Ordered Control 1. Is LSR egress for FEC? OR Has LSR previously received and retained a label mapping for FEC from Next Hop? Then go to FEC.2 2. Iterate through 5 for each Peer. 3. Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, InitAttributes, SAttributes, Propagating, StoredHopCount). 4. Execute procedure Send_Label (Peer, FEC, SAttributes) 5. End iteration from 2. Goto FEC.2. If any of these is discussed, please let me know or give me a pointer to when it was done.... Thanks in Advance Amar --------------7FAF3A4CB456B120710FE646 Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by cmr2.ash.ops.us.uu.net id QQjyca12079 Content-Transfer-Encoding: quoted-printable In the Appendix of the LDP draft
A.1.6 Recognize New FEC

[1] FEC.5. Generate Event Received Label Mapping from Next Hop

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I don=92t understand this..........................
Does'nt this repeat the process of distributing Label mapping message to the peers again. This is already done in FEC.1 for Downstream Unsolici= ted Independent as well as Downstream Unsolicited Ordered contro mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[2] FEC.1, In case of downstream unsolicited Ordered control mode, Why should we loop between 1, 2 when we are not egress or label mapping is not received from next hop. I feel that this is meaning less. We can stra= ight away go to FEC.2 if above condition not satisfied else loop for each peer and distribute the mapping message to all the peers. I just wanted to con= firm with my understanding. Am I right in saying like this....

           &nbs= p; For Downstream Unsolicited Ordered Control

           &nbs= p;   1.  Is LSR egress for FEC? OR
           &nb= sp;        Has LSR previously received and retained a label
           &nb= sp;        mapping for FEC from Next Hop? Then go to FEC.2

           &nbs= p;   2.  Iterate through 5 for each Peer.

           &nbs= p;   3.  Execute procedure Prepare_Label_Mapping_Attributes
           &nb= sp;       (Peer, FEC, InitAttributes, SAttributes, Propagating,
           &nb= sp;       StoredHopCount).

           &nbs= p;   4.  Execute procedure Send_Label (Peer, FEC, SAttributes)

           &nbs= p;   5.  End iteration from 2.
           &nb= sp;       Goto FEC.2.
 

If any of these is discussed, please let me know or give me a point= er to when it was done....

Thanks in Advance
Amar
 
 
  --------------7FAF3A4CB456B120710FE646-- From owner-mpls@UU.NET Mon Jan 15 10:31:13 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07439 for ; Mon, 15 Jan 2001 10:31:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjycc22152; Mon, 15 Jan 2001 15:30:41 GMT Received: by mail-control.mail.uu.net id QQjycc06869 for mpls-outgoing; Mon, 15 Jan 2001 15:30:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjycc06864 for ; Mon, 15 Jan 2001 15:30:13 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjycb00069 for ; Mon, 15 Jan 2001 15:24:16 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 QQjycb09649 for ; Mon, 15 Jan 2001 15:24:09 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id VAA04366 for ; Mon, 15 Jan 2001 21:01:29 GMT Received: from wipro.com ([192.168.220.54]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA6E1E for ; Mon, 15 Jan 2001 20:51:29 +0530 Message-ID: <3A6316CF.AD654E23@wipro.com> Date: Mon, 15 Jan 2001 20:57:12 +0530 From: "Amarnath Honnavalli Anantharamaiah" X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Why address Message Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit It has been discussed long time back, about this topic. It has also been discussed that it is sufficient to advertise only the following in this message 1. LSRId of the LSR 2. Transport IP address on which session is established & 3. Only All the interfaces those which are connected to the peer. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ My question is, how can we determine whcih are the addresses which are connected to the peer in case of a very big router which has as many as 8K interfaces let's say.... Thanks Amar From owner-mpls@UU.NET Mon Jan 15 11:33:13 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09656 for ; Mon, 15 Jan 2001 11:33:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjycg08711; Mon, 15 Jan 2001 16:31:53 GMT Received: by mail-control.mail.uu.net id QQjycg22906 for mpls-outgoing; Mon, 15 Jan 2001 16:31:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjycg22837 for ; Mon, 15 Jan 2001 16:31:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjycf01338 for ; Mon, 15 Jan 2001 16:25:16 GMT Received: from NOD.RESTON.MCI.NET by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [166.60.6.38]) id QQjycf06204 for ; Mon, 15 Jan 2001 16:25:16 GMT Received: from rbonica ([166.60.18.132]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with SMTP id <01JYXNJSXHN09LVTWP@shoe.reston.mci.net> for mpls@UU.NET; Mon, 15 Jan 2001 11:25:11 EST Date: Mon, 15 Jan 2001 11:15:32 -0500 From: Ron Bonica Subject: RE: Last call on MPLS multicast framework In-reply-to: <3A62C6CD.A92B9535@alcatel.be> To: Dirk Ooms Cc: mpls@UU.NET Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Traffic engineering? VPN? Could you say a few words about what it means to traffic engineer a multicast distribution tree? Would multicast routing modules need to consider traffic engineering attributes when building multicast distribution trees? Ron > -----Original Message----- > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > Sent: Monday, January 15, 2001 4:46 AM > To: Ron Bonica > Cc: mpls@UU.NET > Subject: Re: Last call on MPLS multicast framework > > > The same benefits as running IP unicast over MPLS. > > dirk > > Ron Bonica wrote: > > > > Dirk, > > > > If this is the case, what benefit does an ISP derive by running > IP multicast > > traffic over MPLS? > > > > I may be missing something very fundamental. Please reorient me if I am. > > > > Ron > > > > > -----Original Message----- > > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > > Sent: Friday, January 12, 2001 4:41 AM > > > To: Ron Bonica > > > Cc: mpls@UU.NET > > > Subject: Re: Last call on MPLS multicast framework > > > > > > > > > Ron, > > > > > > Sorry for creating the confusion (I guess it is caused by my > > > interpretation of the word 'best' in the dvmrp draft). > > > > > > The RPF check will succeed on the interface where the JOIN message is > > > sent upstream. This can be on an interface different from > the interface > > > through which the unicast route would send traffic to reach the > > > source/root (because the multicast topology can differ from > the unicast > > > topology). Also, this can be on an interface different from the > > > interface through which the shortest path (in the multicast > topology) to > > > the source/root goes (because of traffic-engineered multicast trees, > > > i.e. JOIN messages are not sent on the shortest path to the > > > source/root). The 'RPF check' implementations that I know behave this > > > way (i.e. according to the RPF definition in the PIM spec). > > > > > > dirk > > > > > > Ron Bonica wrote: > > > > > > > > Dirk, > > > > > > > > Now I am really confused. > > > > > > > > From your response, I infer that the RPF check will succeed, > > > even if traffic > > > > arrives on an interface other than that through which the > > > router would send > > > > traffic in order to reach the source. Is this inference > > > correct? If it is > > > > correct, wouldn't RPF code have to change? > > > > > > > > Ron > > > > > > > > > -----Original Message----- > > > > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > > > > Sent: Thursday, January 11, 2001 8:43 AM > > > > > To: Ron Bonica > > > > > Cc: mpls@UU.NET > > > > > Subject: Re: Last call on MPLS multicast framework > > > > > > > > > > > > > > > Ron, > > > > > > > > > > Thanks for your question, it made me revisit the RPF stuff > > > and it turns > > > > > out that it is not correct anymore (because of an > 'evolution' in the > > > > > definition of RPF). > > > > > > > > > > from draft-ietf-idmr-dvmrp-v3-10.txt: > > > > > The interface on which the best route to the source of the > > > datagram was > > > > > received is called the upstream (also called RPF) interface. > > > > > > > > > > from draft-ietf-pim-sm-v2-new-01.txt: > > > > > RPF stands for "Reverse Path Forwarding". The RPF Neighbor > > > of a router > > > > > with respect to an address is the neighbor that the MRIB indicates > > > > > should be used to forward packets to that address. In > the case of a > > > > > PIM-SM multicast group, the RPF neighbor is the router that a Join > > > > > message for that group would be directed to, in the absence > > > of modifying > > > > > Assert state. > > > > > > > > > > The second definition is more precise because it distinguishes the > > > > > unicast and the multicast topology (MRIB) and it does not > mention the > > > > > confusing word 'best' (='shortest'?) anymore. > > > > > > > > > > According to the newest 'definition' of RPF in the PIM > draft the issue > > > > > mentioned in section 3.8 (and section 7) does not occur > anymore, so I > > > > > will remove it. > > > > > > > > > > dirk > > > > > > > > > > Ron Bonica wrote: > > > > > > > > > > > > Dirk, > > > > > > > > > > > > Two questions: > > > > > > > > > > > > 1) In section 3.8, you say that RPF checks will fail when > > > > > explicit routing > > > > > > causes multicast traffic to arrive on "the wrong > > > interface". Won't RPF > > > > > > checks also fail when MPLS routes traffic through "the wrong > > > > > interface" for > > > > > > any other reason (e.g., traffic engineering constraints)? > > > > > > > > > > > > 2) If RPF checks succeed only when traffic arrives on the > > > > > interface that IGP > > > > > > metrics dictate, what is the benefit of running IP > > > multicast over MPLS? > > > > > > > > > > > > Ron > > > > > > > > > From owner-mpls@UU.NET Tue Jan 16 03:22:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07046 for ; Tue, 16 Jan 2001 03:22:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyer20145; Tue, 16 Jan 2001 08:22:38 GMT Received: by mail-control.mail.uu.net id QQjyer00429 for mpls-outgoing; Tue, 16 Jan 2001 08:22:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjyer00424 for ; Tue, 16 Jan 2001 08:22: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 QQjyer02976 for ; Tue, 16 Jan 2001 08:21:58 GMT Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQjyer19270 for ; Tue, 16 Jan 2001 08:21:57 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f0G8Lfp16770; Tue, 16 Jan 2001 09:21:41 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569D6.002DE027; Tue, 16 Jan 2001 09:21:05 +0100 Message-ID: <3A640471.CAF93A49@alcatel.be> Date: Tue, 16 Jan 2001 09:21:05 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Ron Bonica CC: mpls@UU.NET Subject: Re: Last call on MPLS multicast framework References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ron Bonica wrote: > > Traffic engineering? VPN? both Traffic Engineering: section 7 talks about one way of traffic engineering, namely explicit routing (I didn't want to use 'Traffic Engineering' as title of this section, because TE can be more than that, e.g. things like OMP), this is about overriding the shortest path (shortest path according to unicast routing) tree by another tree. I see two ways of doing this: 1) an offline calculation and then the tree is created by e.g. LDP signaling (no multicast routing involved anymore) 2) a multicast routing protocol is running, but the multicast routing messages are not following the shortest path, they follow traffic-engineered unicast paths Early 1999 there were two drafts on te-multicast, each describing the signaling (not the algorithms) for the above approaches (draft-wu-mpls-multicast-te-00.txt, draft-leecy-multicast-te-01.txt). If you want, I can send these long-expired drafts to you. VPN: the recent draft draft-rosen-vpn-mcast-00.txt describes how one could support IP multicast in VPNs: two of the three methods described will map the IP multicast tree on a point-to-multipoint LSP. dirk > > Could you say a few words about what it means to traffic engineer a > multicast distribution tree? Would multicast routing modules need to > consider traffic engineering attributes when building multicast distribution > trees? > > Ron > > > -----Original Message----- > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > Sent: Monday, January 15, 2001 4:46 AM > > To: Ron Bonica > > Cc: mpls@UU.NET > > Subject: Re: Last call on MPLS multicast framework > > > > > > The same benefits as running IP unicast over MPLS. > > > > dirk > > > > Ron Bonica wrote: > > > > > > Dirk, > > > > > > If this is the case, what benefit does an ISP derive by running > > IP multicast > > > traffic over MPLS? > > > > > > I may be missing something very fundamental. Please reorient me if I am. > > > > > > Ron > > > > > > > -----Original Message----- > > > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > > > Sent: Friday, January 12, 2001 4:41 AM > > > > To: Ron Bonica > > > > Cc: mpls@UU.NET > > > > Subject: Re: Last call on MPLS multicast framework > > > > > > > > > > > > Ron, > > > > > > > > Sorry for creating the confusion (I guess it is caused by my > > > > interpretation of the word 'best' in the dvmrp draft). > > > > > > > > The RPF check will succeed on the interface where the JOIN message is > > > > sent upstream. This can be on an interface different from > > the interface > > > > through which the unicast route would send traffic to reach the > > > > source/root (because the multicast topology can differ from > > the unicast > > > > topology). Also, this can be on an interface different from the > > > > interface through which the shortest path (in the multicast > > topology) to > > > > the source/root goes (because of traffic-engineered multicast trees, > > > > i.e. JOIN messages are not sent on the shortest path to the > > > > source/root). The 'RPF check' implementations that I know behave this > > > > way (i.e. according to the RPF definition in the PIM spec). > > > > > > > > dirk > > > > > > > > Ron Bonica wrote: > > > > > > > > > > Dirk, > > > > > > > > > > Now I am really confused. > > > > > > > > > > From your response, I infer that the RPF check will succeed, > > > > even if traffic > > > > > arrives on an interface other than that through which the > > > > router would send > > > > > traffic in order to reach the source. Is this inference > > > > correct? If it is > > > > > correct, wouldn't RPF code have to change? > > > > > > > > > > Ron > > > > > > > > > > > -----Original Message----- > > > > > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > > > > > Sent: Thursday, January 11, 2001 8:43 AM > > > > > > To: Ron Bonica > > > > > > Cc: mpls@UU.NET > > > > > > Subject: Re: Last call on MPLS multicast framework > > > > > > > > > > > > > > > > > > Ron, > > > > > > > > > > > > Thanks for your question, it made me revisit the RPF stuff > > > > and it turns > > > > > > out that it is not correct anymore (because of an > > 'evolution' in the > > > > > > definition of RPF). > > > > > > > > > > > > from draft-ietf-idmr-dvmrp-v3-10.txt: > > > > > > The interface on which the best route to the source of the > > > > datagram was > > > > > > received is called the upstream (also called RPF) interface. > > > > > > > > > > > > from draft-ietf-pim-sm-v2-new-01.txt: > > > > > > RPF stands for "Reverse Path Forwarding". The RPF Neighbor > > > > of a router > > > > > > with respect to an address is the neighbor that the MRIB indicates > > > > > > should be used to forward packets to that address. In > > the case of a > > > > > > PIM-SM multicast group, the RPF neighbor is the router that a Join > > > > > > message for that group would be directed to, in the absence > > > > of modifying > > > > > > Assert state. > > > > > > > > > > > > The second definition is more precise because it distinguishes the > > > > > > unicast and the multicast topology (MRIB) and it does not > > mention the > > > > > > confusing word 'best' (='shortest'?) anymore. > > > > > > > > > > > > According to the newest 'definition' of RPF in the PIM > > draft the issue > > > > > > mentioned in section 3.8 (and section 7) does not occur > > anymore, so I > > > > > > will remove it. > > > > > > > > > > > > dirk > > > > > > > > > > > > Ron Bonica wrote: > > > > > > > > > > > > > > Dirk, > > > > > > > > > > > > > > Two questions: > > > > > > > > > > > > > > 1) In section 3.8, you say that RPF checks will fail when > > > > > > explicit routing > > > > > > > causes multicast traffic to arrive on "the wrong > > > > interface". Won't RPF > > > > > > > checks also fail when MPLS routes traffic through "the wrong > > > > > > interface" for > > > > > > > any other reason (e.g., traffic engineering constraints)? > > > > > > > > > > > > > > 2) If RPF checks succeed only when traffic arrives on the > > > > > > interface that IGP > > > > > > > metrics dictate, what is the benefit of running IP > > > > multicast over MPLS? > > > > > > > > > > > > > > Ron > > > > > > > > > > > > From owner-mpls@UU.NET Tue Jan 16 17:29:12 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22738 for ; Tue, 16 Jan 2001 17:29:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjygv01702; Tue, 16 Jan 2001 22:26:51 GMT Received: by mail-control.mail.uu.net id QQjygv00588 for mpls-outgoing; Tue, 16 Jan 2001 22:26:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjygv00565 for ; Tue, 16 Jan 2001 22:26:04 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 QQjygv26763 for ; Tue, 16 Jan 2001 22:25:25 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjygv17219 for ; Tue, 16 Jan 2001 22:25:24 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA12122 for mpls@uu.net; Tue, 16 Jan 2001 17:25:23 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjygv00465 for ; Tue, 16 Jan 2001 22:24:53 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 QQjygv12823 for ; Tue, 16 Jan 2001 22:24:31 GMT Received: from zcars04f.ca.nortel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQjygv15931 for ; Tue, 16 Jan 2001 22:24:30 GMT Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Tue, 16 Jan 2001 16:39:22 -0500 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZLK0BM1K; Tue, 16 Jan 2001 16:35:43 -0500 Received: from nortelnetworks.com (sandick2k.corpeast.baynetworks.com [132.245.252.71]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id C22AADL9; Tue, 16 Jan 2001 16:35:43 -0500 Message-ID: <3A64BEAF.A38197A7@nortelnetworks.com> Date: Tue, 16 Jan 2001 16:35:43 -0500 X-Sybari-Space: 00000000 00000000 00000000 From: "Hal Sandick" Reply-To: "Hal Sandick" Organization: Nortel Networks X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 CC: mpls@UU.NET Subject: Re: Last call on MPLS multicast framework References: <3A640471.CAF93A49@alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dirk, Dirk Ooms wrote: > Ron Bonica wrote: > > > > Traffic engineering? VPN? > > both > > Traffic Engineering: > section 7 talks about one way of traffic engineering, namely explicit > routing (I didn't want to use 'Traffic Engineering' as title of this > section, because TE can be more than that, e.g. things like OMP), this > is about overriding the shortest path (shortest path according to > unicast routing) tree by another tree. I see two ways of doing this: > 1) an offline calculation and then the tree is created by e.g. LDP > signaling (no multicast routing involved anymore) > 2) a multicast routing protocol is running, but the multicast routing > messages are not following the shortest path, they follow > traffic-engineered unicast paths I have a feeling I've missed earlier discussion on this. But if you do "2)" how do you maintain a consistent network view so that there aren't loops? Regards, Hal > > Early 1999 there were two drafts on te-multicast, each describing the > signaling (not the algorithms) for the above approaches > (draft-wu-mpls-multicast-te-00.txt, draft-leecy-multicast-te-01.txt). > If you want, I can send these long-expired drafts to you. > > VPN: > the recent draft draft-rosen-vpn-mcast-00.txt describes how one could > support IP multicast in VPNs: two of the three methods described will > map the IP multicast tree on a point-to-multipoint LSP. > > dirk > > > > > Could you say a few words about what it means to traffic engineer a > > multicast distribution tree? Would multicast routing modules need to > > consider traffic engineering attributes when building multicast distribution > > trees? > > > > Ron > > > > > -----Original Message----- > > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > > Sent: Monday, January 15, 2001 4:46 AM > > > To: Ron Bonica > > > Cc: mpls@UU.NET > > > Subject: Re: Last call on MPLS multicast framework > > > > > > > > > The same benefits as running IP unicast over MPLS. > > > > > > dirk > > > > > > Ron Bonica wrote: > > > > > > > > Dirk, > > > > > > > > If this is the case, what benefit does an ISP derive by running > > > IP multicast > > > > traffic over MPLS? > > > > > > > > I may be missing something very fundamental. Please reorient me if I am. > > > > > > > > Ron > > > > > > > > > -----Original Message----- > > > > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > > > > Sent: Friday, January 12, 2001 4:41 AM > > > > > To: Ron Bonica > > > > > Cc: mpls@UU.NET > > > > > Subject: Re: Last call on MPLS multicast framework > > > > > > > > > > > > > > > Ron, > > > > > > > > > > Sorry for creating the confusion (I guess it is caused by my > > > > > interpretation of the word 'best' in the dvmrp draft). > > > > > > > > > > The RPF check will succeed on the interface where the JOIN message is > > > > > sent upstream. This can be on an interface different from > > > the interface > > > > > through which the unicast route would send traffic to reach the > > > > > source/root (because the multicast topology can differ from > > > the unicast > > > > > topology). Also, this can be on an interface different from the > > > > > interface through which the shortest path (in the multicast > > > topology) to > > > > > the source/root goes (because of traffic-engineered multicast trees, > > > > > i.e. JOIN messages are not sent on the shortest path to the > > > > > source/root). The 'RPF check' implementations that I know behave this > > > > > way (i.e. according to the RPF definition in the PIM spec). > > > > > > > > > > dirk > > > > > > > > > > Ron Bonica wrote: > > > > > > > > > > > > Dirk, > > > > > > > > > > > > Now I am really confused. > > > > > > > > > > > > From your response, I infer that the RPF check will succeed, > > > > > even if traffic > > > > > > arrives on an interface other than that through which the > > > > > router would send > > > > > > traffic in order to reach the source. Is this inference > > > > > correct? If it is > > > > > > correct, wouldn't RPF code have to change? > > > > > > > > > > > > Ron > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > > > > > > Sent: Thursday, January 11, 2001 8:43 AM > > > > > > > To: Ron Bonica > > > > > > > Cc: mpls@UU.NET > > > > > > > Subject: Re: Last call on MPLS multicast framework > > > > > > > > > > > > > > > > > > > > > Ron, > > > > > > > > > > > > > > Thanks for your question, it made me revisit the RPF stuff > > > > > and it turns > > > > > > > out that it is not correct anymore (because of an > > > 'evolution' in the > > > > > > > definition of RPF). > > > > > > > > > > > > > > from draft-ietf-idmr-dvmrp-v3-10.txt: > > > > > > > The interface on which the best route to the source of the > > > > > datagram was > > > > > > > received is called the upstream (also called RPF) interface. > > > > > > > > > > > > > > from draft-ietf-pim-sm-v2-new-01.txt: > > > > > > > RPF stands for "Reverse Path Forwarding". The RPF Neighbor > > > > > of a router > > > > > > > with respect to an address is the neighbor that the MRIB indicates > > > > > > > should be used to forward packets to that address. In > > > the case of a > > > > > > > PIM-SM multicast group, the RPF neighbor is the router that a Join > > > > > > > message for that group would be directed to, in the absence > > > > > of modifying > > > > > > > Assert state. > > > > > > > > > > > > > > The second definition is more precise because it distinguishes the > > > > > > > unicast and the multicast topology (MRIB) and it does not > > > mention the > > > > > > > confusing word 'best' (='shortest'?) anymore. > > > > > > > > > > > > > > According to the newest 'definition' of RPF in the PIM > > > draft the issue > > > > > > > mentioned in section 3.8 (and section 7) does not occur > > > anymore, so I > > > > > > > will remove it. > > > > > > > > > > > > > > dirk > > > > > > > > > > > > > > Ron Bonica wrote: > > > > > > > > > > > > > > > > Dirk, > > > > > > > > > > > > > > > > Two questions: > > > > > > > > > > > > > > > > 1) In section 3.8, you say that RPF checks will fail when > > > > > > > explicit routing > > > > > > > > causes multicast traffic to arrive on "the wrong > > > > > interface". Won't RPF > > > > > > > > checks also fail when MPLS routes traffic through "the wrong > > > > > > > interface" for > > > > > > > > any other reason (e.g., traffic engineering constraints)? > > > > > > > > > > > > > > > > 2) If RPF checks succeed only when traffic arrives on the > > > > > > > interface that IGP > > > > > > > > metrics dictate, what is the benefit of running IP > > > > > multicast over MPLS? > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > From owner-mpls@UU.NET Tue Jan 16 18:02:14 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23096 for ; Tue, 16 Jan 2001 18:02:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjygy29537; Tue, 16 Jan 2001 23:01:41 GMT Received: by mail-control.mail.uu.net id QQjygy07545 for mpls-outgoing; Tue, 16 Jan 2001 23:01:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjygy07081 for ; Tue, 16 Jan 2001 23:01: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 QQjygy18670 for ; Tue, 16 Jan 2001 23:00:33 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjygy13737 for ; Tue, 16 Jan 2001 23:00:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA14712 for mpls@uu.net; Tue, 16 Jan 2001 18:00:32 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjygy04032 for ; Tue, 16 Jan 2001 23:00:04 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 QQjygx05355 for ; Tue, 16 Jan 2001 22:59:53 GMT Received: from brixcorp2.brixnet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.91.233.5]) id QQjygx26353 for ; Tue, 16 Jan 2001 22:59:51 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Jan 2001 17:59:39 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B7E78@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'tnadeau@cisco.com'" , "'arun@force10networks.com'" , "'cheenu@tachion.com'" , mpls@UU.NET Cc: "Cucchiara, Joan" , "'slakkapr@nortelnetworks.com'" Subject: RE: Last call on MPLS TE MIB Date: Tue, 16 Jan 2001 17:59:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Tom, Arun and Cheenu, Shobhan Lakkapragada was involved in an implementation of CR-LDP and found that the following objects are needed to fully support the CR-LDP protocol using the MPLS TE MIB (draft-ietf-mpls-te-mib-05.txt). Also, I have reviewed these objects and would like to see these added to MPLS TE MIB. That way, the MPLS TE MIB could be used for both MPLS-RSVP and CR-LDP which is, we believe, the intent of the MIB, i.e. one MIB for both of the TE MPLS protocols, namely, MPLS-RSVP and CR-LDP. We think that the addition of these objects to the MPLS TE MIB would obviate the need for a separate CR-LDP specific MIB since most of the objects in the MPLS TE MIB can be used for both protocols. Please note, we have suggested where these objects be placed but this is certainly open for discussion. Thanks. - Joan and Shobhan -------------- The following objects would fit in the mplsTunnelResourceEntry. These objects are important in order to fully utilize the Traffic Parameters offered by CR-LDP. mplsTunnelResourceMeanBurstSize MplsBurstSize, mplsTunnelResourceExcessBurstSize MplsBurstSize, mplsTunnelResourceFrequency Integer32, mplsTunnelResourceWeight Unsigned32 mplsTunnelResourceMeanBurstSize OBJECT-TYPE SYNTAX MplsBurstSize UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The mean burst size in bytes." mplsTunnelResourceExcessBurstSize OBJECT-TYPE SYNTAX MplsBurstSize UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The Excess burst size in bytes." REFERENCE "CR-LDP Specification, Section 4.3." mplsTunnelResourceFrequency OBJECT-TYPE SYNTAX INTEGER { unspecified(0), frequent(1), veryFrequent(2), } MAX-ACCESS read-create STATUS current DESCRIPTION "The granularity of the availability of committed rate. " REFERENCE "CR-LDP Specification, Section 4.3." mplsTunnelResourceWeight OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The relative weight for using excess bandwidth above its committed rate. The value of 0 means that weight is not applicable for the CR-LSP." REFERENCE "CR-LDP Specification, Section 4.3." > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Friday, January 05, 2001 5:18 PM > To: mpls@UU.NET > Subject: Last call on MPLS TE MIB > > > > This message begins a workgroup last call on > draft-ietf-mpls-te-mib-05.txt, "MPLS Traffic Engineering Management > Information Base Using SMIv2". > > The last call ends Jan 19, 5pm est. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > From owner-mpls@UU.NET Tue Jan 16 23:44:24 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00099 for ; Tue, 16 Jan 2001 23:44:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyhu17197; Wed, 17 Jan 2001 04:44:14 GMT Received: by mail-control.mail.uu.net id QQjyhu09451 for mpls-outgoing; Wed, 17 Jan 2001 04:43:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjyhu09446 for ; Wed, 17 Jan 2001 04:43:44 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 QQjyhu17802 for ; Wed, 17 Jan 2001 04:43:38 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjyhu08778 for ; Wed, 17 Jan 2001 04:43:37 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 17 Jan 2001 10:19:15 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f0HAGQU12052; Wed, 17 Jan 2001 15:46:26 +0530 Reply-To: From: "Manikantan S" To: "'Cucchiara, Joan'" , , , , Cc: Subject: RE: Last call on MPLS TE MIB Date: Wed, 17 Jan 2001 10:00:50 +0530 Message-Id: <000101c0803e$465cfa00$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB9B7E78@brixcorp2.brixnet.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello It would help, as suggested in the mail to include the CRLDP-Specific MIB objects in the TE MIB. Currently we have them as Enterprise MIB objects in our implementation and we can move to the standard MIB if they are available there. I have the following question/doubt for Joan. 1) We have a field "flags" in the CRLDP Traffic Parameters TLV. This helps in conveying the set of negotiable parameters. The value of "Flags" being added as a configurable object will provide added flexibility. what do you suggest? 2) Do we need to use the value of the MIB object "mplsTunnelIncludeAnyAffinity" for the "RsCls" field in Resource Class TLV? thanks and best regards mani ----------------------------------------- S.Manikantan Future Software Limited 480-481, Anna Salai, Nandanam, Chennai, India. Zip (PIN CODE) : 600 035 Phone : 91-44-4330550 Fax : 91-44-4344157 email : manis@future.futsoft.com ----------------------------------------- -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Cucchiara, Joan Sent: Wednesday, 17 January 2001 4:30 AM To: 'tnadeau@cisco.com'; 'arun@force10networks.com'; 'cheenu@tachion.com'; mpls@uu.net Cc: Cucchiara, Joan; 'slakkapr@nortelnetworks.com' Subject: RE: Last call on MPLS TE MIB Tom, Arun and Cheenu, Shobhan Lakkapragada was involved in an implementation of CR-LDP and found that the following objects are needed to fully support the CR-LDP protocol using the MPLS TE MIB (draft-ietf-mpls-te-mib-05.txt). Also, I have reviewed these objects and would like to see these added to MPLS TE MIB. That way, the MPLS TE MIB could be used for both MPLS-RSVP and CR-LDP which is, we believe, the intent of the MIB, i.e. one MIB for both of the TE MPLS protocols, namely, MPLS-RSVP and CR-LDP. We think that the addition of these objects to the MPLS TE MIB would obviate the need for a separate CR-LDP specific MIB since most of the objects in the MPLS TE MIB can be used for both protocols. Please note, we have suggested where these objects be placed but this is certainly open for discussion. Thanks. - Joan and Shobhan -------------- The following objects would fit in the mplsTunnelResourceEntry. These objects are important in order to fully utilize the Traffic Parameters offered by CR-LDP. mplsTunnelResourceMeanBurstSize MplsBurstSize, mplsTunnelResourceExcessBurstSize MplsBurstSize, mplsTunnelResourceFrequency Integer32, mplsTunnelResourceWeight Unsigned32 mplsTunnelResourceMeanBurstSize OBJECT-TYPE SYNTAX MplsBurstSize UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The mean burst size in bytes." mplsTunnelResourceExcessBurstSize OBJECT-TYPE SYNTAX MplsBurstSize UNITS "bytes" MAX-ACCESS read-create STATUS current DESCRIPTION "The Excess burst size in bytes." REFERENCE "CR-LDP Specification, Section 4.3." mplsTunnelResourceFrequency OBJECT-TYPE SYNTAX INTEGER { unspecified(0), frequent(1), veryFrequent(2), } MAX-ACCESS read-create STATUS current DESCRIPTION "The granularity of the availability of committed rate. " REFERENCE "CR-LDP Specification, Section 4.3." mplsTunnelResourceWeight OBJECT-TYPE SYNTAX Unsigned32(0..255) MAX-ACCESS read-create STATUS current DESCRIPTION "The relative weight for using excess bandwidth above its committed rate. The value of 0 means that weight is not applicable for the CR-LSP." REFERENCE "CR-LDP Specification, Section 4.3." > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Friday, January 05, 2001 5:18 PM > To: mpls@UU.NET > Subject: Last call on MPLS TE MIB > > > > This message begins a workgroup last call on > draft-ietf-mpls-te-mib-05.txt, "MPLS Traffic Engineering Management > Information Base Using SMIv2". > > The last call ends Jan 19, 5pm est. > > ...George > > ====================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 > > > From owner-mpls@UU.NET Wed Jan 17 04:49:42 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14993 for ; Wed, 17 Jan 2001 04:49:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyip21521; Wed, 17 Jan 2001 09:49:30 GMT Received: by mail-control.mail.uu.net id QQjyip27524 for mpls-outgoing; Wed, 17 Jan 2001 09:48:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjyip27509 for ; Wed, 17 Jan 2001 09:48:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjyip10771 for ; Wed, 17 Jan 2001 09:48:17 GMT Received: from relay1.alcatel.be by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQjyip15383 for ; Wed, 17 Jan 2001 09:48:08 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f0H9kxU16772; Wed, 17 Jan 2001 10:47:04 +0100 (MET) Received: from alcatel.be ([138.203.195.108]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569D7.0035B5E6; Wed, 17 Jan 2001 10:46:39 +0100 Message-ID: <3A656A34.23783B47@alcatel.be> Date: Wed, 17 Jan 2001 10:47:32 +0100 From: Francis Arts Organization: Alcatel Telecom X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: rsvp , mpls Subject: RESV message in RSVP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I am trying to find out which IP address should be used as the source IP address of a RESV message in RSVP. In RFC 2205 I find the following statements: 1) [RFC 2205, p.38, section 3.1.4] states the following: "The IP source address is an address of the node that sent the message." 2) [RFC 2205, p.39] states the following: "The NHOP (i.e., the RSVP_HOP) object contains the IP address of the interface through which the Resv message was sent and the LIH for the logical interface on which the reservation is required." From these quotes I understand the following: * The source IP address in the IP header of a RESV message can be any IP address configured on the router that originates the RESV message. So this can but does not have to be the IP address of the interface on which the RESV message is sent out [refer to quotes of RFC 2205 below]. * The NHOP object in the RESV message has to be the IP address configured on the interface via which the RESV message is sent out. This implies that the source IP address in the IP header of the RESV message and the NHOP object in the payload of the RESV message may but do not have to carry different IP addresses. Is this the correct understanding? Thank you for your reply. Kind regards, Francis. From owner-mpls@UU.NET Wed Jan 17 07:16:25 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15744 for ; Wed, 17 Jan 2001 07:16:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyiz21829; Wed, 17 Jan 2001 12:15:59 GMT Received: by mail-control.mail.uu.net id QQjyiz12215 for mpls-outgoing; Wed, 17 Jan 2001 12:15:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjyiz12210 for ; Wed, 17 Jan 2001 12:15:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjyiy26760 for ; Wed, 17 Jan 2001 12:14:24 GMT Received: from penguin-ext.wise.edt.ericsson.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: penguin-ext.wise.edt.ericsson.se [194.237.142.110]) id QQjyiy19725 for ; Wed, 17 Jan 2001 12:14:23 GMT Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f0HCEMd19649 for ; Wed, 17 Jan 2001 13:14:22 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Jan 17 13:14:22 2001 +0100 Received: by esealnt746.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Wed, 17 Jan 2001 13:14:22 +0100 Message-ID: <7BA41B5547CCD411833B0002A52CD457DC2B02@enlrynt306.etm.ericsson.se> From: "Christophe Bouhier (ETM)" To: "'mpls@uu.net'" Subject: ATM Signalling translation/mapping Date: Wed, 17 Jan 2001 13:14:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello all, Is there anybody outhere aware of any work being done on signalling translation/mapping between ATM PNNI and RSVP/LDP. The idea would be to map ATM SVC's to MPLS LSP's Thanx, Christophe Bouhier Multiservice Solutions Ericsson Telecommunicatie b.v. P.O. Box 8, 5120 AA Rijen The Netherlands Tel.: +31 161 246271 Fax.: +31 161 249922 E-mail: christophe.bouhier@etm.ericsson.se Internet: http://www.ericsson.nl From owner-mpls@UU.NET Wed Jan 17 09:34:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18823 for ; Wed, 17 Jan 2001 09:34:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyji00623; Wed, 17 Jan 2001 14:32:44 GMT Received: by mail-control.mail.uu.net id QQjyji15044 for mpls-outgoing; Wed, 17 Jan 2001 14:32:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjyji15039 for ; Wed, 17 Jan 2001 14:32:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjyji18104 for ; Wed, 17 Jan 2001 14:32:17 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjyji29899 for ; Wed, 17 Jan 2001 14:32:16 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA24358 for mpls@uu.net; Wed, 17 Jan 2001 09:32:15 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjyji15014 for ; Wed, 17 Jan 2001 14:31:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjyji01105 for ; Wed, 17 Jan 2001 14:31:17 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjyji05797 for ; Wed, 17 Jan 2001 14:31:17 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id GAA06996; Wed, 17 Jan 2001 06:31:10 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 06:31:25 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9B89@BBY1EXM01> From: Shahram Davari To: "'Christophe Bouhier (ETM)'" , "'mpls@uu.net'" Subject: RE: ATM Signalling translation/mapping Date: Wed, 17 Jan 2001 06:33:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, What you are asking is the interworking between ATM and MPLS. There has not been any significant work on this issue. Most of the work has been done on tunneling ATM over MPLS or MPLS over ATM. Yours, -Shahram > -----Original Message----- > From: Christophe Bouhier (ETM) > [mailto:Christophe.Bouhier@etm.ericsson.se] > Sent: Wednesday, January 17, 2001 7:14 AM > To: 'mpls@uu.net' > Subject: ATM Signalling translation/mapping > > > Hello all, > > Is there anybody outhere aware of any work being done on > signalling translation/mapping > between ATM PNNI and RSVP/LDP. The idea would be to map ATM > SVC's to MPLS LSP's > > Thanx, > > Christophe Bouhier > Multiservice Solutions > Ericsson Telecommunicatie b.v. > P.O. Box 8, 5120 AA Rijen > The Netherlands > > Tel.: +31 161 246271 Fax.: +31 161 249922 > E-mail: christophe.bouhier@etm.ericsson.se Internet: > http://www.ericsson.nl > > > From owner-mpls@UU.NET Wed Jan 17 12:02:30 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22040 for ; Wed, 17 Jan 2001 12:02:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyjs20295; Wed, 17 Jan 2001 17:01:01 GMT Received: by mail-control.mail.uu.net id QQjyjs24052 for mpls-outgoing; Wed, 17 Jan 2001 17:00:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjyjs23975 for ; Wed, 17 Jan 2001 17:00: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 QQjyjr10933 for ; Wed, 17 Jan 2001 16:59:18 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjyjr14462 for ; Wed, 17 Jan 2001 16:59:17 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA06636 for mpls@uu.net; Wed, 17 Jan 2001 11:59:16 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjyjr21902 for ; Wed, 17 Jan 2001 16:58:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjyjr22136 for ; Wed, 17 Jan 2001 16:58:07 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 QQjyjr12082 for ; Wed, 17 Jan 2001 16:58:06 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA05452; Wed, 17 Jan 2001 11:38:20 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABD03079; Wed, 17 Jan 2001 11:38:34 -0500 (EST) Message-Id: <4.3.2.7.2.20010117113330.020cb138@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Jan 2001 11:42:20 -0500 To: "Cucchiara, Joan" , "'arun@force10networks.com'" , "'cheenu@tachion.com'" , mpls@UU.NET From: "Thomas D. Nadeau" Subject: RE: Last call on MPLS TE MIB Cc: "Cucchiara, Joan" , "'slakkapr@nortelnetworks.com'" In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB9B7E78@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi Joan and Shobhan, Thanks for the comments. >Shobhan Lakkapragada was involved in an implementation of >CR-LDP and found that the following objects are needed >to fully support the CR-LDP protocol using the >MPLS TE MIB (draft-ietf-mpls-te-mib-05.txt). > >Also, I have reviewed these objects and would like to >see these added to MPLS TE MIB. That way, the MPLS TE >MIB could be used for both MPLS-RSVP and CR-LDP which >is, we believe, the intent of the MIB, i.e. one MIB for >both of the TE MPLS protocols, namely, MPLS-RSVP and >CR-LDP. Agreed. It was and still is, one of our goals for this MIB to have a single MIB used for TE, regardless of signaling protocol or implementation. >The following objects would fit in the mplsTunnelResourceEntry. >These objects are important in order to fully utilize the >Traffic Parameters offered by CR-LDP. These all look okay to me. As long as there are no other objections from the WG, I think that we can add these. Would anyone object to these objects being made mandatory in the conformance statement for only those implementations utilizing CR-LDP for signaling? --Tom > mplsTunnelResourceMeanBurstSize MplsBurstSize, > mplsTunnelResourceExcessBurstSize MplsBurstSize, > mplsTunnelResourceFrequency Integer32, > mplsTunnelResourceWeight Unsigned32 > > mplsTunnelResourceMeanBurstSize OBJECT-TYPE > SYNTAX MplsBurstSize > UNITS "bytes" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The mean burst size in bytes." > > mplsTunnelResourceExcessBurstSize OBJECT-TYPE > SYNTAX MplsBurstSize > UNITS "bytes" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The Excess burst size in bytes." > REFERENCE > "CR-LDP Specification, Section 4.3." > > mplsTunnelResourceFrequency OBJECT-TYPE > SYNTAX INTEGER { > unspecified(0), > frequent(1), > veryFrequent(2), > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The granularity of the availability of committed rate. " > REFERENCE > "CR-LDP Specification, Section 4.3." > > mplsTunnelResourceWeight OBJECT-TYPE > SYNTAX Unsigned32(0..255) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The relative weight for using excess bandwidth > above its committed rate. The value of 0 means > that weight is not applicable for the CR-LSP." > REFERENCE > "CR-LDP Specification, Section 4.3." > > > > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Friday, January 05, 2001 5:18 PM > > To: mpls@UU.NET > > Subject: Last call on MPLS TE MIB > > > > > > > > This message begins a workgroup last call on > > draft-ietf-mpls-te-mib-05.txt, "MPLS Traffic Engineering Management > > Information Base Using SMIv2". > > > > The last call ends Jan 19, 5pm est. > > > > ...George > > > > ====================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > > > From owner-mpls@UU.NET Wed Jan 17 15:51:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25976 for ; Wed, 17 Jan 2001 15:51:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjykh24369; Wed, 17 Jan 2001 20:48:57 GMT Received: by mail-control.mail.uu.net id QQjykh05798 for mpls-outgoing; Wed, 17 Jan 2001 20:48:32 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjykh05793 for ; Wed, 17 Jan 2001 20:48:25 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 QQjykh26448 for ; Wed, 17 Jan 2001 20:47:19 GMT Received: from web11401.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web11401.mail.yahoo.com [216.136.131.231]) id QQjykh01027 for ; Wed, 17 Jan 2001 20:47:19 GMT Message-ID: <20010117204719.77664.qmail@web11401.mail.yahoo.com> Received: from [132.177.121.29] by web11401.mail.yahoo.com; Wed, 17 Jan 2001 12:47:19 PST Date: Wed, 17 Jan 2001 12:47:19 -0800 (PST) From: John Sparr Subject: SESSION object in 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 all, I have a question about SESSION object in RSVP-TE: SESSION object is mandatorry in both Pathe and Resv message, what's the diffrence for SESSION objects in Ptah and Resv message? Should the receiver node make something diffrent for the SESSION object from the one received from Path message? Thanks, --John __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From owner-mpls@UU.NET Wed Jan 17 16:16:05 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26238 for ; Wed, 17 Jan 2001 16:16:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyki23085; Wed, 17 Jan 2001 21:14:06 GMT Received: by mail-control.mail.uu.net id QQjyki19305 for mpls-outgoing; Wed, 17 Jan 2001 21:13:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjyki19279 for ; Wed, 17 Jan 2001 21:13:32 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 QQjyki27777 for ; Wed, 17 Jan 2001 21:13:14 GMT Received: from ape.isi.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ape.isi.edu [128.9.160.225]) id QQjyki10684 for ; Wed, 17 Jan 2001 21:13:13 GMT Received: from localhost (berson@localhost) by ape.isi.edu (8.11.0/8.11.0) with ESMTP id f0HLD6c04124; Wed, 17 Jan 2001 13:13:07 -0800 X-Authentication-Warning: ape.isi.edu: berson owned process doing -bs Date: Wed, 17 Jan 2001 13:13:06 -0800 (PST) From: Steven Berson To: "Christophe Bouhier (ETM)" cc: "'mpls@uu.net'" Subject: Re: ATM Signalling translation/mapping In-Reply-To: <7BA41B5547CCD411833B0002A52CD457DC2B02@enlrynt306.etm.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk There was work done in the ISSLL Working Group on mapping RSVP reservations to ATM. Look at RFCs 2379-2382. Regards, Steve On Wed, 17 Jan 2001, Christophe Bouhier (ETM) wrote: > Hello all, > > Is there anybody outhere aware of any work being done on signalling translation/mapping > between ATM PNNI and RSVP/LDP. The idea would be to map ATM SVC's to MPLS LSP's > > Thanx, > > Christophe Bouhier > Multiservice Solutions > Ericsson Telecommunicatie b.v. > P.O. Box 8, 5120 AA Rijen > The Netherlands > > Tel.: +31 161 246271 Fax.: +31 161 249922 > E-mail: christophe.bouhier@etm.ericsson.se Internet: http://www.ericsson.nl > > > > From owner-mpls@UU.NET Wed Jan 17 16:25:09 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26376 for ; Wed, 17 Jan 2001 16:25:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjykj09208; Wed, 17 Jan 2001 21:21:00 GMT Received: by mail-control.mail.uu.net id QQjykj20208 for mpls-outgoing; Wed, 17 Jan 2001 21:20:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjykj20192 for ; Wed, 17 Jan 2001 21:20:11 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 QQjykj05537 for ; Wed, 17 Jan 2001 21:19:51 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjykj22206 for ; Wed, 17 Jan 2001 21:19:50 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA27536 for mpls@uu.net; Wed, 17 Jan 2001 16:19:50 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjykj20069 for ; Wed, 17 Jan 2001 21:19:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjykj00790 for ; Wed, 17 Jan 2001 21:18:01 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 QQjykj02300 for ; Wed, 17 Jan 2001 21:18:01 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA18856; Wed, 17 Jan 2001 16:17:11 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABD07567; Wed, 17 Jan 2001 16:17:20 -0500 (EST) Message-Id: <4.3.2.7.2.20010117154845.01797ad8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Jan 2001 16:21:06 -0500 To: "Korchemny, Elena" , "'arun@force10networks.com'" , "'cheenu@tachion.com'" From: "Thomas D. Nadeau" Subject: RE: Last call on MPLS TE MIB Cc: "'mpls@UU.NET'" , "Lipovetsky, Sergey" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, >MPLS-TE-MIB has been implemented for Virata MPLS software packet. >This implementation is based on draft-ietf-mpls-te-mib-05 document. > >A few points arose during our work on MPLS-TE-MIB. I think these >points might clarify MPLS TE MIB draft before it become standard. > > 1. There is mplsTunnelLocalProtectInUse object in the Tunnel table > Can you add reference to a document (draft, RFC, standard) explaining > what is "Local protection mechanism". Certainly. I believe there is mention of this in the mpls framework document. > Is there any relation between mplsTunnelLocalProtectInUse object and > "isPersistent" flag of mplsTunnelSessionAttributes object. Not necessarily. LocalProtect equates to a local path repair (perhaps temporary) having taken place. The 'isPersistent' bit indicates whether this tunnel should be restored automatically after a link/LSR failure occurs. > 2. mplsTunnelOwner objects currently has 5 values: > admin(1), rsvp(2), ldp(3), policyAgent(4) and other(5). > It seems to me that tunnel owner should be defined as: > admin, signaling, policyAgent, other. And in order to know which type >of > signaling was used for tunnel creating object mplsTunnelSignallingProto > should be used. > Existing definition causes doubling of information on transit hops > (for example, a tunnel owner is rsvp(2) and signProtocol is rsvp(2)). Although it is a duplication in one or two cases, I don't think that a change is necessary, as there is really no operational impact or confusion if it is left the way it is. > 3. mplsTunnelIndex and mplsTunnelInstance objects > How do you see mapping between TE MIB tunnel index/instance and > the signaling protocol concepts? > In Virata TE MIB implementation we interpreted these objects as: > for RSVP signaling - > mplsTunnelIndex corresponds to TunnelId of the rsvp session object, > mplsTunnelInstance corresponds to LSPID of the sender template. Yes. > for LDP signaling - > mplsTunnelIndex corresponds to LSPId TLV in label >request/mapping/... > messages, > for mplsTunnelInstance we don't see appropriate object in CR-LDP > (CR-LDP does not support "multi-path tunnel"). > We set TE MIB TunnelInstance value to 1 in this case. I believe that this is true. > 4. One more little note. > mplsTunnelTotalUpTime and mplsTunnelInstanceUpTime objects are defined >with > MAX-ACCESS "read-create". I think they should be "read-only". Am I >right? Yes, that is a typo on our part. > mplsTunnelAdminStatus is defined as read-create, it should be >read-write. Yes; typo. --Tom > I think the above points might clarify the MPLS-TE_MIB draft. > (And your answers to the above questions should help us to improve our >MPLS-TE MIB implementation.) > >Regards, >Elena Korchemny > >Senior software engineer >VIRATA >Tel: +972-9-7663288 (Ext. 211) >ekorchemny@virata.com > > > > > >-----Original Message----- >From: George Swallow [mailto:swallow@cisco.com] >Sent: Saturday, January 06, 2001 12:18 AM >To: mpls@UU.NET >Subject: Last call on MPLS TE MIB > > > >This message begins a workgroup last call on >draft-ietf-mpls-te-mib-05.txt, "MPLS Traffic Engineering Management >Information Base Using SMIv2". > >The last call ends Jan 19, 5pm est. > >...George > >====================================================================== >George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Wed Jan 17 17:35:05 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27365 for ; Wed, 17 Jan 2001 17:35:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyko18546; Wed, 17 Jan 2001 22:34:36 GMT Received: by mail-control.mail.uu.net id QQjyko09229 for mpls-outgoing; Wed, 17 Jan 2001 22:34:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjyko09224 for ; Wed, 17 Jan 2001 22:33:57 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 QQjyko02786 for ; Wed, 17 Jan 2001 22:33:31 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 QQjyko26890 for ; Wed, 17 Jan 2001 22:33:31 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA20909 for ; Wed, 17 Jan 2001 17:33:28 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06454 for ; Wed, 17 Jan 2001 17:33:31 -0500 (EST) Message-ID: <3A661DBC.DBDA3EA@marconi.com> Date: Wed, 17 Jan 2001 17:33:32 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: SESSION object in RSVP-TE References: <20010117204719.77664.qmail@web11401.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 John Sparr wrote: > > I have a question about SESSION object in RSVP-TE: SESSION object is > mandatorry in both Pathe and Resv message, what's the diffrence for > SESSION objects in Ptah and Resv message? Should the receiver node > make something diffrent for the SESSION object from the one received > from Path message? The SESSION object identifies the receiving endpoint of communication (or the egress node of an LSP). The values used in the Resv message are identical to those used in the corresponding Path message. -- David From owner-mpls@UU.NET Wed Jan 17 18:51:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28939 for ; Wed, 17 Jan 2001 18:51:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjykt21037; Wed, 17 Jan 2001 23:51:08 GMT Received: by mail-control.mail.uu.net id QQjykt29229 for mpls-outgoing; Wed, 17 Jan 2001 23:50:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjykt29223 for ; Wed, 17 Jan 2001 23:50: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 QQjykt24972 for ; Wed, 17 Jan 2001 23:50:31 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjykt19838 for ; Wed, 17 Jan 2001 23:50:30 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA07735 for mpls@uu.net; Wed, 17 Jan 2001 18:50:30 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjykt29203 for ; Wed, 17 Jan 2001 23:50: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 QQjykt21362 for ; Wed, 17 Jan 2001 23:48:47 GMT Received: from boreas.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQjykt01089 for ; Wed, 17 Jan 2001 23:48:46 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA13500; Wed, 17 Jan 2001 15:48:43 -0800 (PST) Message-Id: <200101172348.PAA13500@boreas.isi.edu> To: IETF-Announce:; Subject: RFC 3031 on MPLS Architecture Cc: rfc-ed@ISI.EDU, mpls@UU.NET Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 17 Jan 2001 15:48:43 -0800 From: RFC Editor Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3031 Title: Multiprotocol Label Switching Architecture Author(s): E. Rosen, A. Viswanathan, R. Callon Status: Standards Track Date: January 2001 Mailbox: erosen@cisco.com, arun@force10networks.com, rcallon@juniper.net Pages: 61 Characters: 147175 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-arch-07.txt URL: ftp://ftp.isi.edu/in-notes/rfc3031.txt This document specifies the architecture for Multiprotocol Label Switching (MPLS). This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010117154556.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3031 --OtherAccess Content-Type: Message/External-body; name="rfc3031.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010117154556.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 17 18:53:31 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29087 for ; Wed, 17 Jan 2001 18:53:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjykt25217; Wed, 17 Jan 2001 23:53:20 GMT Received: by mail-control.mail.uu.net id QQjykt29501 for mpls-outgoing; Wed, 17 Jan 2001 23:52:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjykt29495 for ; Wed, 17 Jan 2001 23:52:47 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 QQjykt08272 for ; Wed, 17 Jan 2001 23:52:15 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjykt06693 for ; Wed, 17 Jan 2001 23:52:15 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA07898 for mpls@uu.net; Wed, 17 Jan 2001 18:52:14 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjykt29399 for ; Wed, 17 Jan 2001 23:51: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 QQjykt27809 for ; Wed, 17 Jan 2001 23:51:38 GMT Received: from boreas.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQjykt05655 for ; Wed, 17 Jan 2001 23:51:36 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA14049; Wed, 17 Jan 2001 15:51:29 -0800 (PST) Message-Id: <200101172351.PAA14049@boreas.isi.edu> To: IETF-Announce:; Subject: RFC 3032 on MPLS Label Stack Encoding Cc: rfc-ed@ISI.EDU, mpls@UU.NET Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 17 Jan 2001 15:51:29 -0800 From: RFC Editor Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3032 Title: MPLS Label Stack Encoding Author(s): E. Rosen, Y. Rekhter, D. Tappan, G. Fedorkow, D. Farinacci, T. Li, A. Conta Status: Standards Track Date: January 2001 Mailbox: erosen@cisco.com, tappan@cisco.com, yakov@juniper.net, fedorkow@cisco.com, dino@procket.com, tli@procket.com, aconta@txc.com Pages: 23 Characters: 48314 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-label-encaps-08.txt URL: ftp://ftp.isi.edu/in-notes/rfc3032.txt "Multi-Protocol Label Switching (MPLS)" [1] requires a set of procedures for augmenting network layer packets with "label stacks", thereby turning them into "labeled packets". Routers which support MPLS are known as "Label Switching Routers", or "LSRs". In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. On some data links, the label at the top of the stack may be encoded in a different manner, but the techniques described here MUST be used to encode the remainder of the label stack. This document also specifies rules and procedures for processing the various fields of the label stack encoding. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010117154927.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3032 --OtherAccess Content-Type: Message/External-body; name="rfc3032.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010117154927.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 17 18:59:29 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29170 for ; Wed, 17 Jan 2001 18:59:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjykt05379; Wed, 17 Jan 2001 23:58:41 GMT Received: by mail-control.mail.uu.net id QQjykt29767 for mpls-outgoing; Wed, 17 Jan 2001 23:57:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjykt29754 for ; Wed, 17 Jan 2001 23:57:36 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjykt19824 for ; Wed, 17 Jan 2001 23:57:00 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjykt02200 for ; Wed, 17 Jan 2001 23:56:59 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA08858 for mpls@uu.net; Wed, 17 Jan 2001 18:56:58 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjykt29680 for ; Wed, 17 Jan 2001 23:56: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 QQjykt04691 for ; Wed, 17 Jan 2001 23:54:39 GMT Received: from boreas.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQjykt10214 for ; Wed, 17 Jan 2001 23:54:38 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA14839; Wed, 17 Jan 2001 15:54:33 -0800 (PST) Message-Id: <200101172354.PAA14839@boreas.isi.edu> To: IETF-Announce:; Subject: RFC 3033 on GIT and UUS Assignment for IP Cc: rfc-ed@ISI.EDU, mpls@UU.NET Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 17 Jan 2001 15:54:33 -0800 From: RFC Editor Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3033 Title: The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol Author(s): M. Suzuki Status: Standards Track Date: January 2001 Mailbox: suzuki.muneyoshi@lab.ntt.co.jp Pages: 25 Characters: 52188 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-git-uus-04.txt URL: ftp://ftp.isi.edu/in-notes/rfc3033.txt The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. The assignment, that is specified in section 4 of this document, is designed for advanced B-ISDN signaling support of the Internet protocol, especially the B-ISDN signaling support for the connection that corresponds to the session in the Internet protocol which is clarified in section 2. This specification provides an indispensable framework for the implementation of long-lived session and QoS-sensitive session transfers over ATM. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010117155218.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3033 --OtherAccess Content-Type: Message/External-body; name="rfc3033.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010117155218.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 17 19:01:39 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29217 for ; Wed, 17 Jan 2001 19:01:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyku20339; Thu, 18 Jan 2001 00:01:08 GMT Received: by mail-control.mail.uu.net id QQjyku01888 for mpls-outgoing; Thu, 18 Jan 2001 00:00:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjyku00201 for ; Thu, 18 Jan 2001 00:00:03 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 QQjykt24201 for ; Wed, 17 Jan 2001 23:59:05 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjykt06174 for ; Wed, 17 Jan 2001 23:59:04 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA08986 for mpls@uu.net; Wed, 17 Jan 2001 18:59:04 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjykt29786 for ; Wed, 17 Jan 2001 23:58:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjykt17579 for ; Wed, 17 Jan 2001 23:58:00 GMT Received: from boreas.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQjykt15224 for ; Wed, 17 Jan 2001 23:57:59 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA15653; Wed, 17 Jan 2001 15:57:57 -0800 (PST) Message-Id: <200101172357.PAA15653@boreas.isi.edu> To: IETF-Announce:; Subject: RFC 3034 on Label Switching with Frame Relay Cc: rfc-ed@ISI.EDU, mpls@UU.NET Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 17 Jan 2001 15:57:57 -0800 From: RFC Editor Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3034 Title: Use of Label Switching on Frame Relay Networks Specification Author(s): A. Conta, P. Doolan, A. Malis Status: Standards Track Date: January 2001 Mailbox: aconta@txc.com, pdoolan@ennovatenetworks.com, Andy.Malis@vivacenetworks.com Pages: 24 Characters: 53176 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-fr-06.txt URL: ftp://ftp.isi.edu/in-notes/rfc3034.txt This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. Furthermore, it extends and clarifies portions of the Multiprotocol Label Switching Architecture described in [ARCH] and the Label Distribution Protocol (LDP) described in [LDP] relative to Frame Relay Networks. MPLS enables the use of Frame Relay Switches as Label Switching Routers (LSRs). This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010117155554.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3034 --OtherAccess Content-Type: Message/External-body; name="rfc3034.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010117155554.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 17 19:05:05 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29243 for ; Wed, 17 Jan 2001 19:05:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyku29735; Thu, 18 Jan 2001 00:04:16 GMT Received: by mail-control.mail.uu.net id QQjyku11409 for mpls-outgoing; Thu, 18 Jan 2001 00:03:29 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjyku09995 for ; Thu, 18 Jan 2001 00:03: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 QQjyku03462 for ; Thu, 18 Jan 2001 00:02:53 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjyku23356 for ; Thu, 18 Jan 2001 00:02:52 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA09651 for mpls@uu.net; Wed, 17 Jan 2001 19:02:51 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjyku06316 for ; Thu, 18 Jan 2001 00:01:42 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 QQjyku27665 for ; Thu, 18 Jan 2001 00:01:17 GMT Received: from brixcorp2.brixnet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.91.233.5]) id QQjyku20650 for ; Thu, 18 Jan 2001 00:01:17 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 18:59:11 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B7E86@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'manis@future.futsoft.com'" , "Cucchiara, Joan" , tnadeau@cisco.com, arun@force10networks.com, cheenu@tachion.com, mpls@UU.NET Cc: slakkapr@nortelnetworks.com Subject: RE: Last call on MPLS TE MIB Date: Wed, 17 Jan 2001 18:59:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Mani, > Hello > > It would help, as suggested in the mail to include > the CRLDP-Specific MIB objects in the TE MIB. > > Currently we have them as Enterprise MIB objects > in our implementation and we can move to the > standard MIB if they are available there. > > I have the following question/doubt for Joan. > > 1) We have a field "flags" in the CRLDP Traffic > Parameters TLV. This helps in conveying the > set of negotiable parameters. The value of "Flags" > being added as a configurable object will provide > added flexibility. what do you suggest? I agree with you that an ActiveFlags object would be useful for CR-LDP. If possible, would you be able to email what this object looked like in your enterprise MIB? Having actual implementation feedback is very useful for MIB objects. > > 2) Do we need to use the value of the MIB object > "mplsTunnelIncludeAnyAffinity" for the > "RsCls" field in Resource Class TLV? This seems like a reasonable approach. Are you suggesting that the wording of the "mplsTunnelIncludeAnyAffinity" object be enhanced to include CR-LDP's Resource Class TLV? Thanks, Joan > > > thanks and best regards > mani > ----------------------------------------- > S.Manikantan > Future Software Limited > 480-481, Anna Salai, > Nandanam, Chennai, India. > Zip (PIN CODE) : 600 035 > Phone : 91-44-4330550 > Fax : 91-44-4344157 > email : manis@future.futsoft.com > ----------------------------------------- > > > -----Original Message----- > From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of > Cucchiara, Joan > Sent: Wednesday, 17 January 2001 4:30 AM > To: 'tnadeau@cisco.com'; 'arun@force10networks.com'; > 'cheenu@tachion.com'; mpls@uu.net > Cc: Cucchiara, Joan; 'slakkapr@nortelnetworks.com' > Subject: RE: Last call on MPLS TE MIB > > > > Tom, Arun and Cheenu, > > Shobhan Lakkapragada was involved in an implementation of > CR-LDP and found that the following objects are needed > to fully support the CR-LDP protocol using the > MPLS TE MIB (draft-ietf-mpls-te-mib-05.txt). > > Also, I have reviewed these objects and would like to > see these added to MPLS TE MIB. That way, the MPLS TE > MIB could be used for both MPLS-RSVP and CR-LDP which > is, we believe, the intent of the MIB, i.e. one MIB for > both of the TE MPLS protocols, namely, MPLS-RSVP and > CR-LDP. > > We think that the addition of these objects to > the MPLS TE MIB would obviate the need for a > separate CR-LDP specific MIB since most of the objects > in the MPLS TE MIB can be used for both protocols. > > Please note, we have suggested where these objects be > placed but this is certainly open for discussion. > > Thanks. > > - Joan and Shobhan > > -------------- > > The following objects would fit in the mplsTunnelResourceEntry. > These objects are important in order to fully utilize the > Traffic Parameters offered by CR-LDP. > > mplsTunnelResourceMeanBurstSize MplsBurstSize, > mplsTunnelResourceExcessBurstSize MplsBurstSize, > mplsTunnelResourceFrequency Integer32, > mplsTunnelResourceWeight Unsigned32 > > mplsTunnelResourceMeanBurstSize OBJECT-TYPE > SYNTAX MplsBurstSize > UNITS "bytes" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The mean burst size in bytes." > > mplsTunnelResourceExcessBurstSize OBJECT-TYPE > SYNTAX MplsBurstSize > UNITS "bytes" > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The Excess burst size in bytes." > REFERENCE > "CR-LDP Specification, Section 4.3." > > mplsTunnelResourceFrequency OBJECT-TYPE > SYNTAX INTEGER { > unspecified(0), > frequent(1), > veryFrequent(2), > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The granularity of the availability of > committed rate. " > REFERENCE > "CR-LDP Specification, Section 4.3." > > mplsTunnelResourceWeight OBJECT-TYPE > SYNTAX Unsigned32(0..255) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The relative weight for using excess bandwidth > above its committed rate. The value of 0 means > that weight is not applicable for the CR-LSP." > REFERENCE > "CR-LDP Specification, Section 4.3." > > > > > > -----Original Message----- > > From: George Swallow [mailto:swallow@cisco.com] > > Sent: Friday, January 05, 2001 5:18 PM > > To: mpls@UU.NET > > Subject: Last call on MPLS TE MIB > > > > > > > > This message begins a workgroup last call on > > draft-ietf-mpls-te-mib-05.txt, "MPLS Traffic Engineering Management > > Information Base Using SMIv2". > > > > The last call ends Jan 19, 5pm est. > > > > ...George > > > > > ====================================================================== > > George Swallow Cisco Systems (978) 244-8143 > > 250 Apollo Drive > > Chelmsford, Ma 01824 > > > > > > > From owner-mpls@UU.NET Wed Jan 17 19:05:24 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29258 for ; Wed, 17 Jan 2001 19:05:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyku01348; Thu, 18 Jan 2001 00:05:10 GMT Received: by mail-control.mail.uu.net id QQjyku11784 for mpls-outgoing; Thu, 18 Jan 2001 00:04:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjyku11519 for ; Thu, 18 Jan 2001 00:04:02 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 QQjyku05785 for ; Thu, 18 Jan 2001 00:03:53 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjyku15611 for ; Thu, 18 Jan 2001 00:03:52 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA09910 for mpls@uu.net; Wed, 17 Jan 2001 19:03:52 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjyku09779 for ; Thu, 18 Jan 2001 00:03:09 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjyku02118 for ; Thu, 18 Jan 2001 00:02:19 GMT Received: from boreas.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQjyku22360 for ; Thu, 18 Jan 2001 00:02:17 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA16614; Wed, 17 Jan 2001 16:02:13 -0800 (PST) Message-Id: <200101180002.QAA16614@boreas.isi.edu> To: IETF-Announce:; Subject: RFC 3035 on MPLS using LDP and ATM VC Switching Cc: rfc-ed@ISI.EDU, mpls@UU.NET Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 17 Jan 2001 16:02:13 -0800 From: RFC Editor Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3035 Title: MPLS using LDP and ATM VC Switching Author(s): B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. Swallow, P. Doolan Status: Standards Track Date: January 2001 Mailbox: bsd@cisco.com, pdoolan@ennovatenetworks.com, jlawrenc@cisco.com, kzm@cisco.com, yakov@juniper.net, erosen@cisco.com, swallow@cisco.com Pages: 20 Characters: 46463 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-atm-04.txt URL: ftp://ftp.isi.edu/in-notes/rfc3035.txt The Multiprotocol Label Switching (MPLS) Architecture discusses a way in which Asynchronous Transfer Mode (ATM) switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs (Label Switching Routers). This document extends and clarifies the relevant portions of and by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010117155853.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3035 --OtherAccess Content-Type: Message/External-body; name="rfc3035.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010117155853.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 17 19:10:27 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29358 for ; Wed, 17 Jan 2001 19:10:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyku25475; Thu, 18 Jan 2001 00:09:05 GMT Received: by mail-control.mail.uu.net id QQjyku12257 for mpls-outgoing; Thu, 18 Jan 2001 00:08:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjyku12238 for ; Thu, 18 Jan 2001 00:07:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjyku17556 for ; Thu, 18 Jan 2001 00:06:38 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjyku03894 for ; Thu, 18 Jan 2001 00:06:38 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA10383 for mpls@uu.net; Wed, 17 Jan 2001 19:06:37 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjyku11971 for ; Thu, 18 Jan 2001 00:05:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjyku08865 for ; Thu, 18 Jan 2001 00:05:10 GMT Received: from boreas.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQjyku27032 for ; Thu, 18 Jan 2001 00:05:09 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA17309; Wed, 17 Jan 2001 16:05:05 -0800 (PST) Message-Id: <200101180005.QAA17309@boreas.isi.edu> To: IETF-Announce:; Subject: RFC 3036 on LDP Specification Cc: rfc-ed@ISI.EDU, mpls@UU.NET Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 17 Jan 2001 16:05:05 -0800 From: RFC Editor Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3036 Title: LDP Specification Author(s): L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas Status: Standards Track Date: January 2001 Mailbox: loa.andersson@nortelnetworks.com, pdoolan@ennovatenetworks.com, nkf@us.ibm.com, fredette@photonex.com, rhthomas@cisco.com Pages: 132 Characters: 274855 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-ldp-11.txt URL: ftp://ftp.isi.edu/in-notes/rfc3036.txt The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010117160305.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3036 --OtherAccess Content-Type: Message/External-body; name="rfc3036.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010117160305.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 17 19:10:48 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29369 for ; Wed, 17 Jan 2001 19:10:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyku09137; Thu, 18 Jan 2001 00:09:54 GMT Received: by mail-control.mail.uu.net id QQjyku12333 for mpls-outgoing; Thu, 18 Jan 2001 00:08:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjyku12327 for ; Thu, 18 Jan 2001 00:08: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 QQjyku19142 for ; Thu, 18 Jan 2001 00:08:22 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjyku01943 for ; Thu, 18 Jan 2001 00:08:21 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA10880 for mpls@uu.net; Wed, 17 Jan 2001 19:08:21 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjyku12220 for ; Thu, 18 Jan 2001 00:07:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjyku04809 for ; Thu, 18 Jan 2001 00:07:47 GMT Received: from boreas.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQjyku01020 for ; Thu, 18 Jan 2001 00:07:45 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA17898; Wed, 17 Jan 2001 16:07:41 -0800 (PST) Message-Id: <200101180007.QAA17898@boreas.isi.edu> To: IETF-Announce:; Subject: RFC 3037 on LDP Applicability Cc: rfc-ed@ISI.EDU, mpls@UU.NET Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 17 Jan 2001 16:07:41 -0800 From: RFC Editor Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3037 Title: LDP Applicability Author(s): B. Thomas, E. Gray Status: Standards Track Date: January 2001 Mailbox: rhthomas@cisco.com, ewgray@mindspring.com Pages: 7 Characters: 13601 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-ldp-applic-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc3037.txt Multiprotocol Label Switching (MPLS) is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet nexthops. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document describes the applicability of a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010117160548.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3037 --OtherAccess Content-Type: Message/External-body; name="rfc3037.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010117160548.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 17 19:14:37 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29435 for ; Wed, 17 Jan 2001 19:14:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyku09898; Thu, 18 Jan 2001 00:13:42 GMT Received: by mail-control.mail.uu.net id QQjyku12854 for mpls-outgoing; Thu, 18 Jan 2001 00:13:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjyku12835 for ; Thu, 18 Jan 2001 00:12:58 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 QQjyku29475 for ; Thu, 18 Jan 2001 00:11:48 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjyku12586 for ; Thu, 18 Jan 2001 00:11:48 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA11375 for mpls@uu.net; Wed, 17 Jan 2001 19:11:47 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjyku12477 for ; Thu, 18 Jan 2001 00:10:26 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjyku09869 for ; Thu, 18 Jan 2001 00:09:59 GMT Received: from boreas.isi.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQjyku04243 for ; Thu, 18 Jan 2001 00:09:57 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA18699; Wed, 17 Jan 2001 16:09:53 -0800 (PST) Message-Id: <200101180009.QAA18699@boreas.isi.edu> To: IETF-Announce:; Subject: RFC 3038 on VCID Notification for LDP Cc: rfc-ed@ISI.EDU, mpls@UU.NET Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 17 Jan 2001 16:09:52 -0800 From: RFC Editor Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3038 Title: VCID Notification over ATM link for LDP Author(s): K. Nagami, Y. Katsube, N. Demizu, H. Esaki, P. Doolan Status: Standards Track Date: January 2001 Mailbox: ken.nagami@toshiba.co.jp, demizu@dd.iij4u.or.jp, hiroshi@wide.ad.jp, yasuhiro.katsube@toshiba.co.jp, pdoolan@ennovatenetworks.com Pages: 19 Characters: 39134 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-vcid-atm-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc3038.txt The Asynchronous Transfer Mode Label Switching Router (ATM-LSR) is one of the major applications of label switching. Because the ATM layer labels (VPI and VCI) associated with a VC rewritten with new value at every ATM switch nodes, it is not possible to use them to identify a VC in label mapping messages. The concept of Virtual Connection Identifier (VCID) is introduced to solve this problem. VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010117160809.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3038 --OtherAccess Content-Type: Message/External-body; name="rfc3038.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010117160809.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 17 19:33:36 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29761 for ; Wed, 17 Jan 2001 19:33:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjykw05233; Thu, 18 Jan 2001 00:32:03 GMT Received: by mail-control.mail.uu.net id QQjykw14757 for mpls-outgoing; Thu, 18 Jan 2001 00:31:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjykw14748 for ; Thu, 18 Jan 2001 00:31:21 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 QQjykw25710 for ; Thu, 18 Jan 2001 00:30:27 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjykw08956 for ; Thu, 18 Jan 2001 00:30:27 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA12998 for mpls@uu.net; Wed, 17 Jan 2001 19:30:26 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjykv14488 for ; Thu, 18 Jan 2001 00:29:51 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 QQjykv01727 for ; Thu, 18 Jan 2001 00:28:49 GMT Received: from boreas.isi.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQjykv08925 for ; Thu, 18 Jan 2001 00:28:47 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA24846; Wed, 17 Jan 2001 16:28:42 -0800 (PST) Message-Id: <200101180028.QAA24846@boreas.isi.edu> To: IETF-Announce:; Subject: RFC 3035 on MPLS using LDP and ATM VC Switching Cc: rfc-ed@ISI.EDU, mpls@UU.NET Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 17 Jan 2001 16:28:42 -0800 From: RFC Editor Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3035 Title: MPLS using LDP and ATM VC Switching Author(s): B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. Swallow, P. Doolan Status: Standards Track Date: January 2001 Mailbox: bsd@cisco.com, pdoolan@ennovatenetworks.com, jlawrenc@cisco.com, kzm@cisco.com, yakov@juniper.net, erosen@cisco.com, swallow@cisco.com Pages: 20 Characters: 46463 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-atm-04.txt URL: ftp://ftp.isi.edu/in-notes/rfc3.txt The Multiprotocol Label Switching (MPLS) Architecture discusses a way in which Asynchronous Transfer Mode (ATM) switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs (Label Switching Routers). This document extends and clarifies the relevant portions of RFC 3031 and RFC 3036 by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see RFC 3031) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to RFC 3032. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010117162432.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3 --OtherAccess Content-Type: Message/External-body; name="rfc3.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010117162432.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 17 23:46:49 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05579 for ; Wed, 17 Jan 2001 23:46:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyln00564; Thu, 18 Jan 2001 04:46:36 GMT Received: by mail-control.mail.uu.net id QQjyln26842 for mpls-outgoing; Thu, 18 Jan 2001 04:46:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjyln26822 for ; Thu, 18 Jan 2001 04:46: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 QQjyln27992 for ; Thu, 18 Jan 2001 04:45:29 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjyln28771 for ; Thu, 18 Jan 2001 04:45:28 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 18 Jan 2001 10:21:16 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f0IAIKU09120; Thu, 18 Jan 2001 15:48:20 +0530 Reply-To: From: "Manikantan S" To: "'Cucchiara, Joan'" Cc: , , , , Subject: RE: Last call on MPLS TE MIB Date: Thu, 18 Jan 2001 10:02:39 +0530 Message-Id: <002b01c08107$b16f7600$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB9B7E86@brixcorp2.brixnet.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Joan #> Hello #> #> It would help, as suggested in the mail to include #> the CRLDP-Specific MIB objects in the TE MIB. #> #> Currently we have them as Enterprise MIB objects #> in our implementation and we can move to the #> standard MIB if they are available there. #> #> I have the following question/doubt for Joan. #> #> 1) We have a field "flags" in the CRLDP Traffic #> Parameters TLV. This helps in conveying the #> set of negotiable parameters. The value of "Flags" #> being added as a configurable object will provide #> added flexibility. what do you suggest? # #I agree with you that an ActiveFlags object would #be useful for CR-LDP. If possible, would you #be able to email what this object looked like in #your enterprise MIB? # #Having actual implementation feedback is very useful #for MIB objects. I currently have the following definition in the Enterprises MIB. fsMplsLdpCrlspTnlFlags INTEGER fsMplsLdpCrlspTnlFlags OBJECT-TYPE SYNTAX INTEGER (0..63) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of Flags conveyed as part of the Traffic Parameters during the establishment of the CRLSP. The Bit value indicates the set of Traffic parameters that are negotiable during the CRLSP setup." REFERENCE "Section 4.3, Constraint-Based LSP Setup using LDP, Jamoussi, et. al, , July 2000." DEFVAL { 0 } -- Parameters not negotiable. #> #> 2) Do we need to use the value of the MIB object #> "mplsTunnelIncludeAnyAffinity" for the #> "RsCls" field in Resource Class TLV? # #This seems like a reasonable approach. Are you #suggesting that the wording of the "mplsTunnelIncludeAnyAffinity" #object be enhanced to include CR-LDP's Resource Class TLV? Yes. I feel it will be clear and very helpful. Thanks and best regards mani ----------------------------------------- S.Manikantan Future Software Limited 480-481, Anna Salai, Nandanam, Chennai, India. Zip (PIN CODE) : 600 035 Phone : 91-44-4330550 Fax : 91-44-4344157 email : manis@future.futsoft.com ----------------------------------------- From owner-mpls@UU.NET Thu Jan 18 04:12:05 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21225 for ; Thu, 18 Jan 2001 04:12:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyme11550; Thu, 18 Jan 2001 09:11:30 GMT Received: by mail-control.mail.uu.net id QQjyme23905 for mpls-outgoing; Thu, 18 Jan 2001 09:10:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjyme23896 for ; Thu, 18 Jan 2001 09:10: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 QQjyme09790 for ; Thu, 18 Jan 2001 09:08:32 GMT Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQjyme24999 for ; Thu, 18 Jan 2001 09:08:31 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f0I98JK19816; Thu, 18 Jan 2001 10:08:23 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569D8.00322EF1; Thu, 18 Jan 2001 10:08:08 +0100 Message-ID: <3A66B285.3B58EE83@alcatel.be> Date: Thu, 18 Jan 2001 10:08:21 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Hal Sandick CC: mpls@UU.NET Subject: Re: Last call on MPLS multicast framework References: <3A640471.CAF93A49@alcatel.be> <3A64BEAF.A38197A7@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hal, see below Hal Sandick wrote: > > Dirk, > > Dirk Ooms wrote: > > > Ron Bonica wrote: > > > > > > Traffic engineering? VPN? > > > > both > > > > Traffic Engineering: > > section 7 talks about one way of traffic engineering, namely explicit > > routing (I didn't want to use 'Traffic Engineering' as title of this > > section, because TE can be more than that, e.g. things like OMP), this > > is about overriding the shortest path (shortest path according to > > unicast routing) tree by another tree. I see two ways of doing this: > > 1) an offline calculation and then the tree is created by e.g. LDP > > signaling (no multicast routing involved anymore) > > 2) a multicast routing protocol is running, but the multicast routing > > messages are not following the shortest path, they follow > > traffic-engineered unicast paths > > I have a feeling I've missed earlier discussion on this. But if you do "2)" how > do you maintain a consistent network view so that there aren't loops? If the traffic-engineered unicast paths are loop-free, the multicast tree constructed with "2)" will be loop-free as well (the multicast routing messages are just following unicast routes towards the source/root). dirk > > Regards, > > Hal > > > > > Early 1999 there were two drafts on te-multicast, each describing the > > signaling (not the algorithms) for the above approaches > > (draft-wu-mpls-multicast-te-00.txt, draft-leecy-multicast-te-01.txt). > > If you want, I can send these long-expired drafts to you. > > > > VPN: > > the recent draft draft-rosen-vpn-mcast-00.txt describes how one could > > support IP multicast in VPNs: two of the three methods described will > > map the IP multicast tree on a point-to-multipoint LSP. > > > > dirk > > > > > > > > Could you say a few words about what it means to traffic engineer a > > > multicast distribution tree? Would multicast routing modules need to > > > consider traffic engineering attributes when building multicast distribution > > > trees? > > > > > > Ron > > > > > > > -----Original Message----- > > > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > > > Sent: Monday, January 15, 2001 4:46 AM > > > > To: Ron Bonica > > > > Cc: mpls@UU.NET > > > > Subject: Re: Last call on MPLS multicast framework > > > > > > > > > > > > The same benefits as running IP unicast over MPLS. > > > > > > > > dirk > > > > > > > > Ron Bonica wrote: > > > > > > > > > > Dirk, > > > > > > > > > > If this is the case, what benefit does an ISP derive by running > > > > IP multicast > > > > > traffic over MPLS? > > > > > > > > > > I may be missing something very fundamental. Please reorient me if I am. > > > > > > > > > > Ron > > > > > > > > > > > -----Original Message----- > > > > > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > > > > > Sent: Friday, January 12, 2001 4:41 AM > > > > > > To: Ron Bonica > > > > > > Cc: mpls@UU.NET > > > > > > Subject: Re: Last call on MPLS multicast framework > > > > > > > > > > > > > > > > > > Ron, > > > > > > > > > > > > Sorry for creating the confusion (I guess it is caused by my > > > > > > interpretation of the word 'best' in the dvmrp draft). > > > > > > > > > > > > The RPF check will succeed on the interface where the JOIN message is > > > > > > sent upstream. This can be on an interface different from > > > > the interface > > > > > > through which the unicast route would send traffic to reach the > > > > > > source/root (because the multicast topology can differ from > > > > the unicast > > > > > > topology). Also, this can be on an interface different from the > > > > > > interface through which the shortest path (in the multicast > > > > topology) to > > > > > > the source/root goes (because of traffic-engineered multicast trees, > > > > > > i.e. JOIN messages are not sent on the shortest path to the > > > > > > source/root). The 'RPF check' implementations that I know behave this > > > > > > way (i.e. according to the RPF definition in the PIM spec). > > > > > > > > > > > > dirk > > > > > > > > > > > > Ron Bonica wrote: > > > > > > > > > > > > > > Dirk, > > > > > > > > > > > > > > Now I am really confused. > > > > > > > > > > > > > > From your response, I infer that the RPF check will succeed, > > > > > > even if traffic > > > > > > > arrives on an interface other than that through which the > > > > > > router would send > > > > > > > traffic in order to reach the source. Is this inference > > > > > > correct? If it is > > > > > > > correct, wouldn't RPF code have to change? > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Dirk Ooms [mailto:Dirk.Ooms@alcatel.be] > > > > > > > > Sent: Thursday, January 11, 2001 8:43 AM > > > > > > > > To: Ron Bonica > > > > > > > > Cc: mpls@UU.NET > > > > > > > > Subject: Re: Last call on MPLS multicast framework > > > > > > > > > > > > > > > > > > > > > > > > Ron, > > > > > > > > > > > > > > > > Thanks for your question, it made me revisit the RPF stuff > > > > > > and it turns > > > > > > > > out that it is not correct anymore (because of an > > > > 'evolution' in the > > > > > > > > definition of RPF). > > > > > > > > > > > > > > > > from draft-ietf-idmr-dvmrp-v3-10.txt: > > > > > > > > The interface on which the best route to the source of the > > > > > > datagram was > > > > > > > > received is called the upstream (also called RPF) interface. > > > > > > > > > > > > > > > > from draft-ietf-pim-sm-v2-new-01.txt: > > > > > > > > RPF stands for "Reverse Path Forwarding". The RPF Neighbor > > > > > > of a router > > > > > > > > with respect to an address is the neighbor that the MRIB indicates > > > > > > > > should be used to forward packets to that address. In > > > > the case of a > > > > > > > > PIM-SM multicast group, the RPF neighbor is the router that a Join > > > > > > > > message for that group would be directed to, in the absence > > > > > > of modifying > > > > > > > > Assert state. > > > > > > > > > > > > > > > > The second definition is more precise because it distinguishes the > > > > > > > > unicast and the multicast topology (MRIB) and it does not > > > > mention the > > > > > > > > confusing word 'best' (='shortest'?) anymore. > > > > > > > > > > > > > > > > According to the newest 'definition' of RPF in the PIM > > > > draft the issue > > > > > > > > mentioned in section 3.8 (and section 7) does not occur > > > > anymore, so I > > > > > > > > will remove it. > > > > > > > > > > > > > > > > dirk > > > > > > > > > > > > > > > > Ron Bonica wrote: > > > > > > > > > > > > > > > > > > Dirk, > > > > > > > > > > > > > > > > > > Two questions: > > > > > > > > > > > > > > > > > > 1) In section 3.8, you say that RPF checks will fail when > > > > > > > > explicit routing > > > > > > > > > causes multicast traffic to arrive on "the wrong > > > > > > interface". Won't RPF > > > > > > > > > checks also fail when MPLS routes traffic through "the wrong > > > > > > > > interface" for > > > > > > > > > any other reason (e.g., traffic engineering constraints)? > > > > > > > > > > > > > > > > > > 2) If RPF checks succeed only when traffic arrives on the > > > > > > > > interface that IGP > > > > > > > > > metrics dictate, what is the benefit of running IP > > > > > > multicast over MPLS? > > > > > > > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > From owner-mpls@UU.NET Thu Jan 18 05:10:09 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21641 for ; Thu, 18 Jan 2001 05:10:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjymi01122; Thu, 18 Jan 2001 10:09:53 GMT Received: by mail-control.mail.uu.net id QQjymi12162 for mpls-outgoing; Thu, 18 Jan 2001 10:09:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjymi12155 for ; Thu, 18 Jan 2001 10:09:22 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 QQjymi08567 for ; Thu, 18 Jan 2001 10:08:55 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjymi04411 for ; Thu, 18 Jan 2001 10:08:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id FAA06585 for mpls@uu.net; Thu, 18 Jan 2001 05:08:53 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjymi12088 for ; Thu, 18 Jan 2001 10:08:22 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjymi10014 for ; Thu, 18 Jan 2001 10:07:55 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjymi20286 for ; Thu, 18 Jan 2001 10:07:54 GMT Received: from fedex.cisco.com (fedex.cisco.com [171.69.18.27]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id CAA17943; Thu, 18 Jan 2001 02:08:07 -0800 (PST) Received: from cisco.com ([64.104.135.245]) by fedex.cisco.com (Mirapoint) with ESMTP id AMI48443 (AUTH mchawla); Thu, 18 Jan 2001 02:07:51 -0800 (PST) Message-ID: <3A66C293.CA37E0A5@cisco.com> Date: Thu, 18 Jan 2001 15:46:52 +0530 From: Mukul Chawla X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Steven Berson CC: "Christophe Bouhier (ETM)" , "'mpls@uu.net'" Subject: Re: ATM Signalling translation/mapping References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Some work done on mapping RSVP to ATM in academia/research also: (1) Alex Birman, Victor Firoiu, Roch Guerin, and Dilip Kandlur "Support for RSVP-based Services over ATM networks" IEEE Global Internet '96. (2) Mukul Chawla, Yuxin Zhou, Klara Nahrstedt "QoS Translations and end-to-end signaling for RSVP over CBR/ATM", OPNETWORK '99. Regards, Mukul Steven Berson wrote: > There was work done in the ISSLL Working Group on mapping RSVP > reservations to ATM. Look at RFCs 2379-2382. > > Regards, > Steve > > On Wed, 17 Jan 2001, Christophe Bouhier (ETM) wrote: > > > Hello all, > > > > Is there anybody outhere aware of any work being done on signalling translation/mapping > > between ATM PNNI and RSVP/LDP. The idea would be to map ATM SVC's to MPLS LSP's > > > > Thanx, > > > > Christophe Bouhier > > Multiservice Solutions > > Ericsson Telecommunicatie b.v. > > P.O. Box 8, 5120 AA Rijen > > The Netherlands > > > > Tel.: +31 161 246271 Fax.: +31 161 249922 > > E-mail: christophe.bouhier@etm.ericsson.se Internet: http://www.ericsson.nl > > > > > > > > From owner-mpls@UU.NET Thu Jan 18 11:45:59 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28200 for ; Thu, 18 Jan 2001 11:45:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyni02160; Thu, 18 Jan 2001 16:43:38 GMT Received: by mail-control.mail.uu.net id QQjyni21006 for mpls-outgoing; Thu, 18 Jan 2001 16:43:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjyni21001 for ; Thu, 18 Jan 2001 16:43: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 QQjyni16449 for ; Thu, 18 Jan 2001 16:41:53 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjyni16841 for ; Thu, 18 Jan 2001 16:41:52 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA29222 for mpls@uu.net; Thu, 18 Jan 2001 11:41:52 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjyni20895 for ; Thu, 18 Jan 2001 16:41:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjyni11147 for ; Thu, 18 Jan 2001 16:40:09 GMT Received: from boreas.isi.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQjyni20655 for ; Thu, 18 Jan 2001 16:40:08 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id IAA07542; Thu, 18 Jan 2001 08:40:03 -0800 (PST) Message-Id: <200101181640.IAA07542@boreas.isi.edu> To: IETF-Announce:; Subject: RFC 3035 on MPLS using LDP and ATM VC Switching Cc: rfc-ed@ISI.EDU, mpls@UU.NET Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 18 Jan 2001 08:40:03 -0800 From: RFC Editor Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3035 Title: MPLS using LDP and ATM VC Switching Author(s): B. Davie, J. Lawrence, K. McCloghrie, Y. Rekhter, E. Rosen, G. Swallow, P. Doolan Status: Standards Track Date: January 2001 Mailbox: bsd@cisco.com, pdoolan@ennovatenetworks.com, jlawrenc@cisco.com, kzm@cisco.com, yakov@juniper.net, erosen@cisco.com, swallow@cisco.com Pages: 20 Characters: 46463 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-atm-04.txt URL: ftp://ftp.isi.edu/in-notes/rfc3035.txt The Multiprotocol Label Switching (MPLS) Architecture discusses a way in which Asynchronous Transfer Mode (ATM) switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs (Label Switching Routers). This document extends and clarifies the relevant portions of RFC 3031 and RFC 3036 by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see RFC 3031) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to RFC 3032. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010118083701.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3035 --OtherAccess Content-Type: Message/External-body; name="rfc3035.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010118083701.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Jan 18 11:48:09 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28233 for ; Thu, 18 Jan 2001 11:48:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjynj25054; Thu, 18 Jan 2001 16:46:29 GMT Received: by mail-control.mail.uu.net id QQjynj21328 for mpls-outgoing; Thu, 18 Jan 2001 16:45:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjynj21320 for ; Thu, 18 Jan 2001 16:45:49 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 QQjynj28001 for ; Thu, 18 Jan 2001 16:45:42 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjynj23498 for ; Thu, 18 Jan 2001 16:45:41 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA29708 for mpls@uu.net; Thu, 18 Jan 2001 11:45:41 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjynj21291 for ; Thu, 18 Jan 2001 16:45:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjyni24763 for ; Thu, 18 Jan 2001 16:44:37 GMT Received: from boreas.isi.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: boreas.isi.edu [128.9.160.161]) id QQjyni28500 for ; Thu, 18 Jan 2001 16:44:34 GMT Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id IAA08098; Thu, 18 Jan 2001 08:44:30 -0800 (PST) Message-Id: <200101181644.IAA08098@boreas.isi.edu> To: IETF-Announce:; Subject: Corrected: RFC 3037 on LDP Applicability Cc: rfc-ed@ISI.EDU, mpls@UU.NET Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 18 Jan 2001 08:44:30 -0800 From: RFC Editor Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3037 Title: LDP Applicability Author(s): B. Thomas, E. Gray Status: Informational Date: January 2001 Mailbox: rhthomas@cisco.com, ewgray@mindspring.com Pages: 7 Characters: 13601 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-ldp-applic-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc3037.txt Multiprotocol Label Switching (MPLS) is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet nexthops. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document describes the applicability of a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010118084136.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3037 --OtherAccess Content-Type: Message/External-body; name="rfc3037.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010118084136.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Fri Jan 19 09:57:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29991 for ; Fri, 19 Jan 2001 09:57:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyqt15257; Fri, 19 Jan 2001 14:56:56 GMT Received: by mail-control.mail.uu.net id QQjyqt19903 for mpls-outgoing; Fri, 19 Jan 2001 14:56:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjyqt19898 for ; Fri, 19 Jan 2001 14:56: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 QQjyqt18926 for ; Fri, 19 Jan 2001 14:56:09 GMT From: richard.crouch@vf.vodafone.co.uk Received: from igate2.vodafone.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: igate2.vodafone.co.uk [194.62.232.10]) id QQjyqt13861 for ; Fri, 19 Jan 2001 14:56:04 GMT Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id OAA29032; Fri, 19 Jan 2001 14:55:56 GMT Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 19 Jan 2001 14:53:45 +0000 Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2448.0) id ; Fri, 19 Jan 2001 14:53:51 -0000 Message-Id: <1763F57BB8BAD211B06500A0C9E5D9200366C5CA@barking.vfl.vodafone> To: mpls@UU.NET Subject: Implications of cell-based or frame-based MPLS Date: Fri, 19 Jan 2001 14:53:43 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Given two homogenous carrier MPLS networks providing only IP services :- Network A : where "cell-based" MPLS is used (e.g. an ATM network got upgraded to include MPLS, -> label carried in the VPI/VCI) and Network B : where "frame/packet-based" MPLS is used (e.g. a router network got upgraded to include MPLS -> label shimmed between L2 and L3 headers) then apart from the additional time to complete convergence in the event of link failure for the cell-based MPLS network (due to additional convergence time of LDP where conservative label retention mode is used by the "cell-based" MPLS network), (1) What are the other major differences in performance/capabilities as a consequence of these two different implementations of MPLS (cell versus packet-based) ? (2) In the area of MPLS applications such as MPLS-VPNs, MPLS traffic-engineering and fast-reroute, what impacts are caused by the inability of an ATM-LSR to pop/push labels in the label stack compared to a "frame/packet-based" LSR (which can pop/push labels in the label stack) ? In a most crude form, I am asking the question "what's better : cell-mode or frame/packet-mode MPLS" Richard Crouch (CND-T - Vodafone Ltd.) From owner-mpls@UU.NET Fri Jan 19 10:37:45 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00685 for ; Fri, 19 Jan 2001 10:37:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyqw00083; Fri, 19 Jan 2001 15:36:51 GMT Received: by mail-control.mail.uu.net id QQjyqw04994 for mpls-outgoing; Fri, 19 Jan 2001 15:36:14 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjyqw04959 for ; Fri, 19 Jan 2001 15:36: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 QQjyqw07501 for ; Fri, 19 Jan 2001 15:35:33 GMT Received: from hermes.research.kpn.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hermes.research.kpn.com [139.63.192.8]) id QQjyqw27812 for ; Fri, 19 Jan 2001 15:35:32 GMT Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JZ3JJX12TO0005AH@research.kpn.com> for mpls@UU.NET; Fri, 19 Jan 2001 16:35:29 +0100 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jan 2001 16:35:29 +0100 Content-return: allowed Date: Fri, 19 Jan 2001 16:35:27 +0100 From: "Metz, E.T." Subject: RE: Implications of cell-based or frame-based MPLS To: "'richard.crouch@vf.vodafone.co.uk'" Cc: mpls@UU.NET Message-id: <59063B5B4D98D311BC0D0001FA7E45220316A7CF@l04.research.kpn.com> 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 > > (1) What are the other major differences in > performance/capabilities as a > consequence of these two different implementations of MPLS > (cell versus > packet-based) ? > One is segmentation and reassembly. Even in the cell-based network you will have a boundary (typically the PE) where you transform the IP packets into cells and vice-versa. As far as I know this is not a function that performs really well at high-speeds. > (2) In the area of MPLS applications such as MPLS-VPNs, MPLS > traffic-engineering and fast-reroute, what impacts are caused by the > inability of an ATM-LSR to pop/push labels in the label stack > compared to a > "frame/packet-based" LSR (which can pop/push labels in the > label stack) ? > The inability of ATM-LSR to deal with stack depths > 1 requires you to use packet-based PEs with a cell-interface towards the core (introducing the SAR issue). Alternatively, you could make an ATM switch perform packet operations (having the SAR issue twice), however, I doubt if this would perform really well. > In a most crude form, I am asking the question "what's better > : cell-mode or > frame/packet-mode MPLS" It is not a matter of good and bad, but rather a matter of needs. If you only use the network for IP traffic only, I do not see a particular need to introduce cell-based platforms. On the other hand they may prove to be very useful if a significant part of your traffic is e.g. due to (native) ATM services. In that case you could mix IP and ATM in the same core platform (although there are sufficient people that would argue this is a bad idea as well) Hope this helped a bit ... cheers, Eduard > > Richard Crouch (CND-T - Vodafone Ltd.) > From owner-mpls@UU.NET Fri Jan 19 11:51:08 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02077 for ; Fri, 19 Jan 2001 11:51:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyrb16981; Fri, 19 Jan 2001 16:48:16 GMT Received: by mail-control.mail.uu.net id QQjyrb23416 for mpls-outgoing; Fri, 19 Jan 2001 16:47:45 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjyrb23402 for ; Fri, 19 Jan 2001 16:47:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjyrb16123 for ; Fri, 19 Jan 2001 16:47:26 GMT Received: from ihemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQjyrb20580 for ; Fri, 19 Jan 2001 16:47:25 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA06168 for ; Fri, 19 Jan 2001 11:47:25 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA06161; Fri, 19 Jan 2001 11:47:25 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA05954; Fri, 19 Jan 2001 11:47:23 -0500 (EST) Received: from ldvrwks_067 ([135.114.93.131]) by md7102notes01.ins.lucent.com (Lotus Domino Release 5.0.4) with ESMTP id 2001011911442589:26 ; Fri, 19 Jan 2001 11:44:25 -0500 From: "Aris Kyriakopoulos" Organization: Lucent Technologies To: "Metz, E.T." , mpls@UU.NET Date: Fri, 19 Jan 2001 11:44:01 -0500 MIME-Version: 1.0 Subject: RE: Implications of cell-based or frame-based MPLS CC: mpls@UU.NET Message-ID: <3A682881.29738.E1FB7FC@localhost> In-reply-to: <59063B5B4D98D311BC0D0001FA7E45220316A7CF@l04.research.kpn.com> X-mailer: Pegasus Mail for Win32 (v3.12c) X-MIMETrack: Itemize by SMTP Server on Notes01/SVR/Yurie(Release 5.0.4 |June 8, 2000) at 01/19/2001 11:44:25, Serialize by Router on Notes01/SVR/Yurie(Release 5.0.4 |June 8, 2000) at 01/19/2001 11:44:27, Serialize complete at 01/19/2001 11:44:27 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT On 19 Jan 2001, at 16:35, Metz, E.T. wrote: > > > > > > (1) What are the other major differences in > > performance/capabilities as a > > consequence of these two different implementations of MPLS > > (cell versus > > packet-based) ? > > > > One is segmentation and reassembly. Even in the cell-based network you will > have a boundary (typically the PE) where you transform the IP packets into > cells and vice-versa. As far as I know this is not a function that performs > really well at high-speeds. Another issue is backbone speed. If a carrier wishes to aggregate OC-12 or OC-48 IP traffic into an OC-192 core, to my knowledge there are no physical standards for cell switching at speeds > OC-48. This means that, even if SAR were performed at OC-12, the ATM backbone would be maxed out at OC-48 speeds. > > In a most crude form, I am asking the question "what's better > > : cell-mode or > > frame/packet-mode MPLS" > > It is not a matter of good and bad, but rather a matter of needs. > > If you only use the network for IP traffic only, I do not see a particular > need to introduce cell-based platforms. On the other hand they may prove to > be very useful if a significant part of your traffic is e.g. due to (native) > ATM services. In that case you could mix IP and ATM in the same core > platform (although there are sufficient people that would argue this is a > bad idea as well) Quite correct, but most major telcos offering a combination of circuit and packet data services will opt for the "ships in the night" approach. At least until Voice over IP becomes a viable alternative to Voice over ATM, in my opinion. Cheers, Aris -- Aris Kyriakopoulos Interoperability Test Engineering, PSAX CO Products Lucent Technologies Landover, MD mobile: (301) 332-2840 office: (301) 809-4509 mailto:aris@lucent.com From owner-mpls@UU.NET Fri Jan 19 12:02:53 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02432 for ; Fri, 19 Jan 2001 12:02:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyrc18503; Fri, 19 Jan 2001 17:01:03 GMT Received: by mail-control.mail.uu.net id QQjyrc27316 for mpls-outgoing; Fri, 19 Jan 2001 17:00:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjyrc27115 for ; Fri, 19 Jan 2001 17:00:35 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 QQjyrc01339 for ; Fri, 19 Jan 2001 17:00:25 GMT Received: from develop.eu.level3.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: develop.eu.level3.net [212.113.1.30]) id QQjyrc06522 for ; Fri, 19 Jan 2001 17:00:24 GMT Received: from develop.eu.level3.net ([212.113.1.30] helo=level3.net) by develop.eu.level3.net with esmtp (Exim 2.05 #2) id 14Jeti-0003D3-00; Fri, 19 Jan 2001 17:00:22 +0000 Message-ID: <3A6872BC.A59D8842@level3.net> Date: Fri, 19 Jan 2001 17:00:44 +0000 From: Giles Heron Organization: Level 3 Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: richard.crouch@vf.vodafone.co.uk CC: mpls@UU.NET Subject: Re: Implications of cell-based or frame-based MPLS References: <1763F57BB8BAD211B06500A0C9E5D9200366C5CA@barking.vfl.vodafone> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit richard.crouch@vf.vodafone.co.uk wrote: > > Given two homogenous carrier MPLS networks providing only IP services :- > > Network A : where "cell-based" MPLS is used (e.g. an ATM network got > upgraded to include MPLS, -> label carried in the VPI/VCI) and > Network B : where "frame/packet-based" MPLS is used (e.g. a router network > got upgraded to include MPLS -> label shimmed between L2 and L3 headers) > > then apart from the additional time to complete convergence in the event of > link failure for the cell-based MPLS network (due to additional convergence > time of LDP where conservative label retention mode is used by the > "cell-based" MPLS network), That's a pretty good reason to prefer frame-based for starters! > (1) What are the other major differences in performance/capabilities as a > consequence of these two different implementations of MPLS (cell versus > packet-based) ? Frame-based should be faster (no SAR bottlenecks, plus ready support for trunk interfaces above OC-48), and more efficient (no "cell tax"). It's also nice to be able to mix media types (e.g. GigE for the LAN and POS for the WAN). One major issue with cell-based MPLS is support for LSP-merge. In a frame-based MPLS network with LDP label distribution you require only O(n) labels, where n is the number of PE devices. With cell-based you require O(n squared) - unless you have a VC-merge capable ATM switch (where the switch buffers cells from different frames to ensure they don't get interleaved). So that's a major scalability issue for cell-based MPLS. With frame-based you'd also have the option of doing IP forwarding at wire-speed if required, since most routers will forward IP and MPLS in the same fast path. > (2) In the area of MPLS applications such as MPLS-VPNs, MPLS > traffic-engineering and fast-reroute, what impacts are caused by the > inability of an ATM-LSR to pop/push labels in the label stack compared to a > "frame/packet-based" LSR (which can pop/push labels in the label stack) ? I don't think VPN is impacted by this? The VPN label should only be in the AAL5 frame (and not in the cell header) since it is carried unchanged from PE to PE? TE and fast-reroute however are a different story, since labels are being pushed and popped in the middle of the path. I can't see how this can be done with ATM MPLS? > In a most crude form, I am asking the question "what's better : cell-mode or > frame/packet-mode MPLS" I guess you can figure out my answer from the above? ;-) Giles -- =================================================== Giles Heron - IP Architect - Level 3 Communications phone: +44 20 7864 0719 mobile: +44 7880 506185 =================================================== From owner-mpls@UU.NET Fri Jan 19 22:01:27 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10323 for ; Fri, 19 Jan 2001 22:01:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjysq19100; Sat, 20 Jan 2001 03:00:57 GMT Received: by mail-control.mail.uu.net id QQjysq24848 for mpls-outgoing; Sat, 20 Jan 2001 03:00:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjysq24743 for ; Sat, 20 Jan 2001 03:00:21 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 QQjysq14042 for ; Sat, 20 Jan 2001 03:00:10 GMT From: James_Huang@Mitel.COM Received: from Mitel.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newgate.mitel.com [198.53.180.100]) id QQjysq17688 for ; Sat, 20 Jan 2001 03:00:09 GMT Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id WAA26193 for ; Fri, 19 Jan 2001 22:00:09 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 852569DA.00107DA0 ; Fri, 19 Jan 2001 22:00:07 -0500 X-Lotus-FromDomain: MITEL To: mpls@UU.NET Message-ID: <852569DA.00107C57.00@kanmta01.software.mitel.com> Date: Fri, 19 Jan 2001 18:59:51 -0800 Subject: FEC element for RSVP-TE? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi all: I have one question in mind when reading the RSVP-TE draft. Does RSVP-TE define some object similar to FEC element in the LDP draft so that we can set up a LSP for traffics belonging to the FEC? If the RSVP path message does not carry such object and it does not carry a ER object, then intermediate LSR can only use the destination IP address in the session object to determine the next hop. This means the ingress RSVP initiator need to know exactly who will be the egress router when it sends out the RSVP path message. This does not seem to be very pratical to me in the case where RSVP-TE is used to set up a LSP tunnel for traffics belonging to a FEC to meet its bandwidth requirements. Am I missing something here? -- James Huang From owner-mpls@UU.NET Sat Jan 20 01:19:25 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14373 for ; Sat, 20 Jan 2001 01:19:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjytd29927; Sat, 20 Jan 2001 06:18:56 GMT Received: by mail-control.mail.uu.net id QQjytd00109 for mpls-outgoing; Sat, 20 Jan 2001 06:18:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjytd00103 for ; Sat, 20 Jan 2001 06:18:29 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 QQjytd16008 for ; Sat, 20 Jan 2001 06:16:58 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjytd13136 for ; Sat, 20 Jan 2001 06:16:55 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Sat, 20 Jan 2001 11:47:03 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f0KBi7U11028; Sat, 20 Jan 2001 17:14:07 +0530 Reply-To: From: "Manikantan S" To: , Subject: Egress Address for CRLDP tunnels Date: Sat, 20 Jan 2001 11:28:13 +0530 Message-Id: <000c01c082a5$fa8e0500$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Good day to you. While implementing the TE MIB I have come across with following questions/suggestions. This is regarding the usage of the single TE MIB for both RSVP-TE based tunnel setup and CRLSP based tunnel setup. In the latest draft of the TE MIB (05.txt) the Tunnel table has destination address too as an index to a row in the tunnel table in addition to the other three indices 1) tunnel index, 2) tunnel instance and 3) tunnel ingress address. These four values are used in the RSVP-TE messages. The destination address is carried in the Session object while the source address (sender address) is carried in the sender template. In CRLSP, only the source address is conveyed in the LSPID TLV. The scope to convey the destination address is currently not available. 1) My question is, can we extended the LSPID TLV to hold the destination address (Tunnel Egress address) too? 2) The ER Hop TLV is mentioned as optional TLV in the CRLDP Draft. While implementing the support I feel when a CRLDP label request is received with no ER Hops we cannot forward the request. At least one ER Hop is required. This seems that it becomes mandatory and not optional. Adding the Destination address in the LSPID TLV can remove the "mandatory" expectation of the ER Hop. 3)I agree that we can use a FEC TLV of host address type, and provide the CRLDP TLVs such as Traffic parameters TLV etc, (which the CRLDP draft do suggest) but I feel that is not very simple. It is easy to handle when we know that the label request is for a CRLSP type or otherwise. 4) Suppose the TE MIB is used for CRLSP based Tunnel initializations, what will be intended use of the destination address (which is a prefix) in the current context? Can we make that value as the last ERHOP for the tunnel, with strict hop type and prefix length of 32? I request your comments/feedback. Thanks in advance with best regards mani ----------------------------------------- S.Manikantan Future Software Limited 480-481, Anna Salai, Nandanam, Chennai, India. Zip (PIN CODE) : 600 035 Phone : 91-44-4330550 Fax : 91-44-4344157 email : manis@future.futsoft.com ----------------------------------------- From owner-mpls@UU.NET Sun Jan 21 00:08:43 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03955 for ; Sun, 21 Jan 2001 00:08:43 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjywq15930; Sun, 21 Jan 2001 05:08:09 GMT Received: by mail-control.mail.uu.net id QQjywq13080 for mpls-outgoing; Sun, 21 Jan 2001 05:07:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjywq12913 for ; Sun, 21 Jan 2001 05:07:32 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 QQjywq16173 for ; Sun, 21 Jan 2001 05:07:16 GMT Received: from longwood.cs.ucf.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: longwood.cs.ucf.edu [132.170.108.1]) id QQjywq13994 for ; Sun, 21 Jan 2001 05:07:16 GMT Received: from eola.cs.ucf.edu (eola [132.170.108.2]) by longwood.cs.ucf.edu (8.11.1/8.11.1) with ESMTP id f0L56sw27306 for ; Sun, 21 Jan 2001 00:06:54 -0500 (EST) From: Arturo Nunez Received: (from artnpp@localhost) by eola.cs.ucf.edu (8.9.3/8.9.0) id AAA14712 for mpls@uu.net; Sun, 21 Jan 2001 00:05:45 -0500 (EST) Message-Id: <200101210505.AAA14712@eola.cs.ucf.edu> Subject: TEST To: mpls@UU.NET Date: Sun, 21 Jan 2001 00:05:45 -0500 (EST) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit From owner-mpls@UU.NET Sun Jan 21 00:19:47 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03982 for ; Sun, 21 Jan 2001 00:19:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjywr08513; Sun, 21 Jan 2001 05:19:13 GMT Received: by mail-control.mail.uu.net id QQjywr17362 for mpls-outgoing; Sun, 21 Jan 2001 05:18:42 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjywr17345 for ; Sun, 21 Jan 2001 05:18: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 QQjywr11706 for ; Sun, 21 Jan 2001 05:17:56 GMT Received: from longwood.cs.ucf.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: longwood.cs.ucf.edu [132.170.108.1]) id QQjywr05756 for ; Sun, 21 Jan 2001 05:17:56 GMT Received: from eola.cs.ucf.edu (eola [132.170.108.2]) by longwood.cs.ucf.edu (8.11.1/8.11.1) with ESMTP id f0L5Htw27429 for ; Sun, 21 Jan 2001 00:17:55 -0500 (EST) From: Arturo Nunez Received: (from artnpp@localhost) by eola.cs.ucf.edu (8.9.3/8.9.0) id AAA14924 for mpls@uu.net; Sun, 21 Jan 2001 00:16:46 -0500 (EST) Message-Id: <200101210516.AAA14924@eola.cs.ucf.edu> Subject: Question about Labels To: mpls@UU.NET Date: Sun, 21 Jan 2001 00:16:46 -0500 (EST) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi: I would like to know: - Why when the routers build their tables and assign the labels, why are they different in for example 2 switches that are adjacent ?? - What happends if the tables in the routers change, as the routes, how are they reflected in the labels, should it be through the LDP ?? Any comment will be welcome .. Regards. Arturo Nunez From owner-mpls@UU.NET Sun Jan 21 00:55:56 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04111 for ; Sun, 21 Jan 2001 00:55:55 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjywt02595; Sun, 21 Jan 2001 05:55:29 GMT Received: by mail-control.mail.uu.net id QQjywt20659 for mpls-outgoing; Sun, 21 Jan 2001 05:54:52 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjywt20632 for ; Sun, 21 Jan 2001 05:54:27 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 QQjywt26956 for ; Sun, 21 Jan 2001 05:52:23 GMT Received: from longwood.cs.ucf.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: longwood.cs.ucf.edu [132.170.108.1]) id QQjywt11019 for ; Sun, 21 Jan 2001 05:52:23 GMT Received: from eola.cs.ucf.edu (eola [132.170.108.2]) by longwood.cs.ucf.edu (8.11.1/8.11.1) with ESMTP id f0L5qLw27758; Sun, 21 Jan 2001 00:52:21 -0500 (EST) From: Arturo Nunez Received: (from artnpp@localhost) by eola.cs.ucf.edu (8.9.3/8.9.0) id AAA15563; Sun, 21 Jan 2001 00:51:12 -0500 (EST) Message-Id: <200101210551.AAA15563@eola.cs.ucf.edu> Subject: Re: Question about Labels To: ytr@csa.iisc.ernet.in (Ramanjaneyulu Y T) Date: Sun, 21 Jan 2001 00:51:12 -0500 (EST) Cc: mpls@UU.NET In-Reply-To: from "Ramanjaneyulu Y T" at Jan 21, 2001 10:52:04 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi: Thanks for the answer.. > Hi > I would like to answer ur questions. pls describe clearly ur questions. I will clarify as well I can do.. 1) Suppose I have a network as these: Ingress LSR--- Core LSR ---- Egress LSR - In the middle (Core) We may have 2 switches that Support LSR Now when I have a path = service will be then labels in the devices that are involved. Why should be labels different in the devices that are near and even why are they different in all the devices involved in all the route ?? If we want do the things easier shouldnt be just be a label, the same , for the path = service ?? 2) What happend if the the tables, routes, in the Network change, what is that related with the labels, how do they change ?? Does it has to be with the LDP ?? Regards. Arturo Nunez From owner-mpls@UU.NET Sun Jan 21 20:31:15 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12403 for ; Sun, 21 Jan 2001 20:31:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjyzu21772; Mon, 22 Jan 2001 01:30:43 GMT Received: by mail-control.mail.uu.net id QQjyzu01963 for mpls-outgoing; Mon, 22 Jan 2001 01:30:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjyzt01924 for ; Mon, 22 Jan 2001 01:29: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 QQjyzt20059 for ; Mon, 22 Jan 2001 01:28:58 GMT Received: from sktelecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.236.1.20]) id QQjyzt00064 for ; Mon, 22 Jan 2001 01:28:57 GMT Received: from skt (localhost [127.0.0.1]) by sktelecom.com (8.10.1/8.10.1) with SMTP id f0M1VSR29271 for ; Mon, 22 Jan 2001 10:31:29 +0900 (KST) Message-ID: <007a01c08412$95160560$7f131796@sktelecom.com> From: "Rae M. Chang" To: Subject: MPLS interoperable btw ATM and router? Date: Mon, 22 Jan 2001 10:28:09 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01C0845E.04098960" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0077_01C0845E.04098960 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8uDQoNCkhhdmUgeW91IGV2ZXIgYW55IGV4cGVyaWVuY2VzIG9mIE1QTFMgYmFzZWQgaW50 ZXJvcGVyYWJpbGl0eSB0ZXN0IA0KYmV0d2VlbiBBVE0gc3dpdGNoZSBhbmQgSVAgcm91dGVyPyBO ZWVkIGFueSBtYXBwaW5nIG1vZHVsZSB0byBkbyB0aGF0Pw0KIA0KQW55IGluZm9ybWF0aW9uIHdp bGwgYmUgaGlnaGx5IGFwcHJlY2lhdGVkLg0KDQpUaGFuayB5b3UuDQo= ------=_NextPart_000_0077_01C0845E.04098960 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQxMzQuNjAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPbG8uLLDvCBjb2xv cj0jMDAwMDAwIHNpemU9Mj5IZWxsby48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9sby4 ssO8IGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT2xvLiyw7wgY29sb3I9IzAwMDAwMCBzaXplPTI+SGF2ZSB5b3UgZXZlciBhbnkgZXhwZXJp ZW5jZXMgb2YgTVBMUyANCmJhc2VkIGludGVyb3BlcmFiaWxpdHkgdGVzdCA8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9sby4ssO8IGNvbG9yPSMwMDAwMDAgc2l6ZT0yPmJldHdlZW4mbmJz cDtBVE0gc3dpdGNoZSBhbmQgSVAgcm91dGVyPyANCk5lZWQgYW55IG1hcHBpbmcgbW9kdWxlIHRv IGRvIHRoYXQ/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPbG8uLLDvCBjb2xvcj0jMDAw MDAwIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9sby4ssO8IGNv bG9yPSMwMDAwMDAgc2l6ZT0yPkFueSBpbmZvcm1hdGlvbiB3aWxsIGJlIGhpZ2hseSANCmFwcHJl Y2lhdGVkLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT2xvLiyw7wgY29sb3I9IzAwMDAw MCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPbG8uLLDvCBjb2xv cj0jMDAwMDAwIHNpemU9Mj5UaGFuayB5b3UuPC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0077_01C0845E.04098960-- From owner-mpls@UU.NET Sun Jan 21 23:14:40 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15477 for ; Sun, 21 Jan 2001 23:14:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzae25789; Mon, 22 Jan 2001 04:13:28 GMT Received: by mail-control.mail.uu.net id QQjzae23944 for mpls-outgoing; Mon, 22 Jan 2001 04:13:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzae23939 for ; Mon, 22 Jan 2001 04:13: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 QQjzae11518 for ; Mon, 22 Jan 2001 04:09:49 GMT Received: from eel.ece.ucdavis.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: eel.ece.ucdavis.edu [169.237.32.164]) id QQjzae21292 for ; Mon, 22 Jan 2001 04:09:49 GMT Received: from localhost (wswen@localhost) by eel.ece.ucdavis.edu (8.9.3/8.9.3) with ESMTP id UAA05016 for ; Sun, 21 Jan 2001 20:09:33 -0800 (PST) Date: Sun, 21 Jan 2001 20:09:32 -0800 (PST) From: Wushao Wen To: mpls@UU.NET Subject: Book on calculating two alternative shortest paths Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, I remember there is a book or paper on how to calculate two shortest paths from a source to a destination in a mesh network. The author also mention it in this mailing list. Can someone please tell me the book name or the author name? Thank you very much! Wushao Wen From owner-mpls@UU.NET Sun Jan 21 23:38:15 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16025 for ; Sun, 21 Jan 2001 23:38:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzag25364; Mon, 22 Jan 2001 04:37:37 GMT Received: by mail-control.mail.uu.net id QQjzag26422 for mpls-outgoing; Mon, 22 Jan 2001 04:37:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzag26414 for ; Mon, 22 Jan 2001 04:37:16 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 QQjzag28940 for ; Mon, 22 Jan 2001 04:36:12 GMT Received: from femail1.sdc1.sfba.home.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail1.sdc1.sfba.home.com [24.0.95.81]) id QQjzag26421 for ; Mon, 22 Jan 2001 04:36:11 GMT Received: from c1052242a.frmt1.sfba.home.com ([24.19.208.28]) by femail1.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010122043540.TKOF2567.femail1.sdc1.sfba.home.com@c1052242a.frmt1.sfba.home.com>; Sun, 21 Jan 2001 20:35:40 -0800 Message-ID: <009601c08491$55d942c0$1cd01318@frmt1.sfba.home.com> Reply-To: "Manohar Ellanti" From: "Manohar Ellanti" To: "Wushao Wen" , References: Subject: Re: Book on calculating two alternative shortest paths Date: Mon, 22 Jan 2001 08:35:30 -0800 Organization: @home MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Wushao Wen, original work on this problem is done by Sururballe that provides not only 2-shortest paths but also for k-shortest paths in a mesh network. You can find , specifically for 2-shortest paths, details in here; J.W. Suurballe, R.E.Tarjan, "A Quick Method for Finding Shortest Pairs of Disjoint Paths", Networks, Vol. 14, 1984 pp 325-336. A generalized version of this algorithm for k-shortest paths can be found here though I find it difficult to understand J.W.Suurballe, "Disjoint Paths in a Network", Networks, Vol. 4., 1974, pp125-145. Some other work is also done for k-shortest paths by Ramesh Bhandari (He has published a book and provided reference in a previous mail on this list), Eppstein (UC,Berkely), Prof Grover at University of Alberta (also TRLabs). Marali K and T.V.Laksham work has references to the above work as well. Hope this answers your questions. Manohar ----- Original Message ----- From: "Wushao Wen" To: Sent: Sunday, January 21, 2001 8:09 PM Subject: Book on calculating two alternative shortest paths > Hi, > I remember there is a book or paper on how to calculate two shortest > paths from a source to a destination in a mesh network. The author also > mention it in this mailing list. Can someone please tell me the book name > or the author name? > Thank you very much! > > > Wushao Wen > From owner-mpls@UU.NET Mon Jan 22 06:20:20 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01559 for ; Mon, 22 Jan 2001 06:20:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbh16751; Mon, 22 Jan 2001 11:19:52 GMT Received: by mail-control.mail.uu.net id QQjzbh28570 for mpls-outgoing; Mon, 22 Jan 2001 11:19:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzbh28554 for ; Mon, 22 Jan 2001 11:19: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 QQjzbh00715 for ; Mon, 22 Jan 2001 11:19:07 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzbh15080 for ; Mon, 22 Jan 2001 11:19:06 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA26140 for mpls@uu.net; Mon, 22 Jan 2001 06:19:03 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzbh28518 for ; Mon, 22 Jan 2001 11:18:45 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 QQjzbh12857 for ; Mon, 22 Jan 2001 11:18:05 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjzbh22539 for ; Mon, 22 Jan 2001 11:18:05 GMT Received: from p7020-img-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id DAA18501; Mon, 22 Jan 2001 03:17:44 -0800 (PST) Message-Id: <5.0.2.1.2.20010122115626.02caf9b0@127.0.0.1> X-Sender: fred@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 22 Jan 2001 12:02:59 +0100 To: Wushao Wen From: Fred Baker Subject: Re: Book on calculating two alternative shortest paths Cc: mpls@UU.NET In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 08:09 PM 1/21/01 -0800, Wushao Wen wrote: >I remember there is a book or paper on how to calculate two shortest >paths from a source to a destination in a mesh network. The author also >mention it in this mailing list. Can someone please tell me the book name >or the author name? there are a number of them. What I would suggest is starting from the Collected Algorithms of the ACM, Algorithm named "Shortest Path First", dated 1968, and modify it a bit. It will, if recollection serves, calculate all paths through the mesh between here and there, producing them in the order "shortest first" for some definition of "short". What I think you want to do is add some "yes, that is shortest, but has some disqualifying characteristic" code, and probably some administrative metric code, to reject the first few you calculate. The first one you wind up with that meets your criteria is your happy route. These appear to be on-line at http://www.mirror.ac.uk/sites/netlib.bell-labs.com/netlib/toms/ From owner-mpls@UU.NET Mon Jan 22 08:02:03 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02952 for ; Mon, 22 Jan 2001 08:02:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbo21334; Mon, 22 Jan 2001 13:01:23 GMT Received: by mail-control.mail.uu.net id QQjzbo23491 for mpls-outgoing; Mon, 22 Jan 2001 13:00:51 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzbo23279 for ; Mon, 22 Jan 2001 13:00:43 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 QQjzbo19154 for ; Mon, 22 Jan 2001 13:00:17 GMT Received: from mail2.orchestream.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [195.153.64.126]) id QQjzbo10238 for ; Mon, 22 Jan 2001 13:00:12 GMT Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 22 Jan 2001 13:00:48 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id MAA14786; Mon, 22 Jan 2001 12:52:12 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 12:57:25 -0000 Message-ID: From: "Morgan, Richard" To: "'Arturo Nunez'" Cc: mpls@UU.NET Subject: RE: Question about Labels Date: Mon, 22 Jan 2001 12:57:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Why should be labels different in the devices that are near > and even why > are they different in all the devices involved in all the route ?? Labels only have local significance - ie a LSR need only know that to send a packet to get a final destination it needs to send it in a direction with a particalar label, also an LSR must know that a packet recieved with a label on a interface must be sent out on another interface as it is destination is already known (ie. where the label is popped). There is no requirement for anything other than adjacent routers knowing the association between a route and a label. Consider a ordinary ipv4 routing table, it has no knowledge of what any other routing table contains, the IGP that populates that table *does* have knowledge of the connections of the adjacent routers. The same with MPLS - the protocols that populate the tables know what they are doing and neogate the other MPLS tables so that they work together. Consider an LSP across a series of LSR's as a physical chain, any link in the middle of chain is connectioned to two other links. Local significances means it only has to cooperate with these two links. The label swapping ensures that the link between two routers is only know to the two connected routers - local significance is up held things are simple. > Hi: > If we want do the things easier shouldnt be just be a > label, the same , > for the path = service ?? There is an attempt to bring MPLS to optical switched paths, this is known as GMPLS. In an optical path you want to keep the wave length of light for a path constant across the entire network. In GMPLS the label used relates the wavelength of light, hence you don't want to label swap - ie local significances is broken and the orginal LSP setup gets a lot more complicated. > 2) What happend if the the tables, routes, in the Network > change, what is > that related with the labels, how do they change ?? Does it > has to be with > the LDP ?? The IGP routes in the table are kept separate from LDP / RSVP LSP routes. Should the LSP break in response to a link being broken the information is communicated back down the path to the source of the LSP and is be recalculated using IGP information from there. There are a few extra failovers a LSP can deploy to help the switch over - these are known as secondary routes and fast reroute. I hope that I understood your question and that this helps :) Rich From owner-mpls@UU.NET Mon Jan 22 09:17:52 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04900 for ; Mon, 22 Jan 2001 09:17:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbt01309; Mon, 22 Jan 2001 14:16:11 GMT Received: by mail-control.mail.uu.net id QQjzbt22982 for mpls-outgoing; Mon, 22 Jan 2001 14:15:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzbt22935 for ; Mon, 22 Jan 2001 14:15:37 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjzbs01057 for ; Mon, 22 Jan 2001 14:14:49 GMT Received: from entmail.gnilink.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: entmail.gnilink.net [199.45.47.10]) id QQjzbs13100 for ; Mon, 22 Jan 2001 14:14:49 GMT Received: by entmail.gnilink.com with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 09:12:28 -0500 Message-ID: <94B9091E1149D411A45C00508BACEB353D07B8@entmail.gnilink.com> From: "Martin, Christian" To: "'Wushao Wen'" , mpls@UU.NET Subject: RE: Book on calculating two alternative shortest paths Date: Mon, 22 Jan 2001 09:12:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk This paper details an algorithm for finding diverse shortest paths in both edge and vertex redundant graphs. Redundant Trees for Preplanned Recovery in Arbitrary Vertex-Redundant or Edge-Redundant Graphs Transactions on Networking October 1999 We present a new algorithm which creates redundant trees on arbitrary node-redundant or link-redundant networks. These trees are such that any node is connected to the common root of the trees by at least one of the trees in case of node or link failure. Our scheme provides rapid preplanned recovery of communications with great flexibility in the topology design. Unlike previous algorithms, our algorithm can establish two redundant trees in the case of a node failing in the network. In the case of failure of a communications link, our algorithm provides a superset of the previously known trees. Muriel Medard, Member, IEEE, Steven G. Finn, Member, IEEE, Richard A. Barry, and Robert G. Gallager, Life Fellow, IEEE http://www.comsoc.org/ieee/comsoc/abstract.asp?article_id=5624 This paper is more of a design instruction on how to build networks that can reroute in the event of a node and or link failure. May be of use. Requires Comsoc Digital Library access. Regards, chris > -----Original Message----- > From: Wushao Wen [mailto:wswen@ece.ucdavis.edu] > Sent: Sunday, January 21, 2001 11:10 PM > To: mpls@UU.NET > Subject: Book on calculating two alternative shortest paths > > > Hi, > I remember there is a book or paper on how to calculate > two shortest > paths from a source to a destination in a mesh network. The > author also > mention it in this mailing list. Can someone please tell me > the book name > or the author name? > Thank you very much! > > > Wushao Wen > From owner-mpls@UU.NET Mon Jan 22 09:26:50 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05129 for ; Mon, 22 Jan 2001 09:26:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbt10871; Mon, 22 Jan 2001 14:25:09 GMT Received: by mail-control.mail.uu.net id QQjzbt24184 for mpls-outgoing; Mon, 22 Jan 2001 14:24:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzbt24177 for ; Mon, 22 Jan 2001 14:24: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 QQjzbt24088 for ; Mon, 22 Jan 2001 14:23:35 GMT Received: from winstar.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fw-1.winstar.com [207.86.108.130]) id QQjzbt27540 for ; Mon, 22 Jan 2001 14:23:30 GMT Received: from vaawsh032382 (dhcp-vaa-1-183-046.winstar.com [10.1.183.46]) by winstar.com (8.9.3/8.9.1) with SMTP id JAA24723; Mon, 22 Jan 2001 09:18:12 -0500 (EST) From: "Yi Chu" To: "Morgan, Richard" , "'Arturo Nunez'" Cc: Subject: RE: Question about Labels Date: Mon, 22 Jan 2001 09:15:13 -0500 Message-ID: <000201c0847d$bc7422c0$2eb7010a@winstar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Morgan, Richard Sent: Monday, January 22, 2001 7:57 AM To: 'Arturo Nunez' Cc: mpls@UU.NET Subject: RE: Question about Labels > Hi: > If we want do the things easier shouldnt be just be a > label, the same , > for the path = service ?? There is an attempt to bring MPLS to optical switched paths, this is known as GMPLS. In an optical path you want to keep the wave length of light for a path constant across the entire network. In GMPLS the label used relates the wavelength of light, hence you don't want to label swap - ie local significances is broken and the orginal LSP setup gets a lot more complicated. If we solve the technical problem of optically swapping lambda's, then labels of GMPLS will only be locally significant too. Any idea if and when this will ever happen? Yi Winstar Communications From owner-mpls@UU.NET Mon Jan 22 09:36:56 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05346 for ; Mon, 22 Jan 2001 09:36:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbu14968; Mon, 22 Jan 2001 14:33:35 GMT Received: by mail-control.mail.uu.net id QQjzbu25252 for mpls-outgoing; Mon, 22 Jan 2001 14:33:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzbu25246 for ; Mon, 22 Jan 2001 14:33: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 QQjzbu23431 for ; Mon, 22 Jan 2001 14:32:00 GMT Received: from smtp2.cluster.oleane.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp2.cluster.oleane.net [195.25.12.17]) id QQjzbu27720 for ; Mon, 22 Jan 2001 14:31:59 GMT Received: from oleane (dyn-1-1-066.Vin.dialup.oleane.fr [195.25.4.66]) by smtp2.cluster.oleane.net with SMTP id f0MEVwY78364 for ; Mon, 22 Jan 2001 15:31:58 +0100 (CET) Message-ID: <027701c08480$399c5180$8001a8c0@oleane.com> From: "Peter Lewis" To: Subject: First international MPLS exhibition Date: Mon, 22 Jan 2001 15:14:37 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0163_01C08486.0903C520" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0163_01C08486.0903C520 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable http://www.upperside.fr/congress/exhi.htm First international MPLS exhibition floorplan. Paris. ------=_NextPart_000_0163_01C08486.0903C520 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

http://www.upperside.f= r/congress/exhi.htm
First international MPLS exhibition = floorplan.=20 Paris.
 
------=_NextPart_000_0163_01C08486.0903C520-- From owner-mpls@UU.NET Mon Jan 22 09:56:49 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05738 for ; Mon, 22 Jan 2001 09:56:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbv21399; Mon, 22 Jan 2001 14:53:41 GMT Received: by mail-control.mail.uu.net id QQjzbv27454 for mpls-outgoing; Mon, 22 Jan 2001 14:53:10 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzbv27443 for ; Mon, 22 Jan 2001 14:53: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 QQjzbv29968 for ; Mon, 22 Jan 2001 14:52:36 GMT Received: from mail-gw3.njit.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-gw3.njit.edu [128.235.251.11]) id QQjzbv09550 for ; Mon, 22 Jan 2001 14:52:36 GMT Received: from lycia.njit.edu (lycia.njit.edu [128.235.205.120]) by mail-gw3.njit.edu (8.10.0/8.10.0) with ESMTP id f0MFjvX18249; Mon, 22 Jan 2001 10:45:57 -0500 Received: (from jxy9918@localhost) by lycia.njit.edu (8.8.8+Sun/8.8.5) id JAA07275; Mon, 22 Jan 2001 09:51:49 -0500 (EST) Date: Mon, 22 Jan 2001 09:51:49 -0500 (EST) From: jie yang ee stnt Message-Id: <200101221451.JAA07275@lycia.njit.edu> To: wswen@ece.ucdavis.edu Subject: Re:Book on calculating two alternative shortest paths Cc: mpls@UU.NET X-Sun-Charset: US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, Wushao, here is the book information you might be looking for. Jie ----- Begin Included Message ----- >From bhandari@hotair.hobl.lucent.com Thu Jan 4 13:35 EST 2001 X-Accept-Language: en MIME-Version: 1.0 To: jie yang ee stnt Subject: Re: Routing Content-Transfer-Encoding: 7bit Hi, You can order the book online at amazon.com or fatbrain.com, but it may take a few weeks to get it. If you want it right away, you may want to call the publisher, Kluwer, directly at (781) 871-6600. They should be able to ship it immediately. The ISBN is 0-7923-8381-8. If you have any problems, let me know. Ramesh > } From bhandari@hotair.hobl.lucent.com Thu Jan 4 12:03 EST 2001 > } X-Accept-Language: en > } MIME-Version: 1.0 > } To: curtis@avici.com > } CC: jie yang ee stnt , mpls@UU.NET > } Subject: Re: Routing > } Content-Transfer-Encoding: 7bit > } > } You can also look up my book "Survivable Networks:Algorithms for Diverse Routing", > } Kluwer (1999) for concepts on traffic splitting over a number of disjoint paths > } (inclduing algorithms for their determinations within a given network)), and full > } restoration, when a link or node fails. > } > } Ramesh Bhandari ----- End Included Message ----- ----- End Included Message ----- From owner-mpls@UU.NET Mon Jan 22 10:04:00 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05975 for ; Mon, 22 Jan 2001 10:04:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbw03811; Mon, 22 Jan 2001 15:01:44 GMT Received: by mail-control.mail.uu.net id QQjzbw01169 for mpls-outgoing; Mon, 22 Jan 2001 15:01:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzbw00708 for ; Mon, 22 Jan 2001 15:00:57 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 QQjzbw18323 for ; Mon, 22 Jan 2001 15:00:33 GMT Received: from mail2.orchestream.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [195.153.64.126]) id QQjzbw01607 for ; Mon, 22 Jan 2001 15:00:31 GMT Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 22 Jan 2001 15:01:00 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id OAA16061; Mon, 22 Jan 2001 14:52:24 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 14:57:37 -0000 Message-ID: From: "Morgan, Richard" To: "'Yi Chu'" , "Morgan, Richard" , "'Arturo Nunez'" Cc: mpls@UU.NET Subject: RE: Question about Labels Date: Mon, 22 Jan 2001 14:57:33 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > If we solve the technical problem of optically swapping lambda's, then > labels of GMPLS will only be locally significant too. Any > idea if and when > this will ever happen? AFAIK 'they' have been able to change the frequency of light in a lab enviroment, they slow it down or put it through a crystal with huge charges across it. Currently there is little chance of this being small / easy / safe enough to put into an optical switched router. Meanwhile you can 'sort of' swap labels by moving the light beam in space, ie push it down a physically different fibre within the same bundle. I'm going to stop there before my very small knowledge on this subject offends someone on the list ! Rich From owner-mpls@UU.NET Mon Jan 22 10:04:20 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05987 for ; Mon, 22 Jan 2001 10:04:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbw00788; Mon, 22 Jan 2001 15:01:45 GMT Received: by mail-control.mail.uu.net id QQjzbw01172 for mpls-outgoing; Mon, 22 Jan 2001 15:01:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzbw01030 for ; Mon, 22 Jan 2001 15:01:07 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 QQjzbv16231 for ; Mon, 22 Jan 2001 14:59:40 GMT Received: from hoemail2.firewall.lucent.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQjzbv16666 for ; Mon, 22 Jan 2001 14:59:40 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA25005 for ; Mon, 22 Jan 2001 09:59:39 -0500 (EST) Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com [199.118.135.2]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id JAA24998; Mon, 22 Jan 2001 09:59:39 -0500 (EST) Received: from hotair.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA15285; Mon, 22 Jan 2001 09:59:39 -0500 Message-ID: <3A6C4B75.A9191D4D@hotair.hobl.lucent.com> Date: Mon, 22 Jan 2001 10:02:13 -0500 From: Ramesh Bhandari X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Manohar Ellanti CC: Wushao Wen , mpls@UU.NET Subject: Re: Book on calculating two alternative shortest paths References: <009601c08491$55d942c0$1cd01318@frmt1.sfba.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Wushao Wen, I am the author of the book in question. The title is "Survivable Networks: Algorithms for Diverse Routing", Kluwer Academic Publishers (1999). The book contains detailed algorithsm on calculating disjoint pair of paths, maximally disjoint paths, if full diversiry does not exit, K (>2) disjoint paths, and also for calculating disjoint paths in real-life fiber networks involving SRLG's (or simply span-sharing links). The algorithms are in a form simpler than those of Suurballe, whose versions are not easy to follow especially for K (>2) disjoint paths, which was also the experience of Manohar Ellanti (see below). The above book can be obtained easily from fatbrain.com or by simply calling the publisher at (781) 871-6600. If there are any questions, please let me know. Ramesh Bhandari Manohar Ellanti wrote: > Wushao Wen, > > original work on this problem is done by Sururballe that provides not only > 2-shortest paths but also for k-shortest paths in a mesh network. > > You can find , specifically for 2-shortest paths, details in here; > J.W. Suurballe, R.E.Tarjan, "A Quick Method for Finding Shortest Pairs of > Disjoint Paths", Networks, Vol. 14, 1984 pp 325-336. > > A generalized version of this algorithm for k-shortest paths can be found > here though I find it difficult to understand > J.W.Suurballe, "Disjoint Paths in a Network", Networks, Vol. 4., 1974, > pp125-145. > > Some other work is also done for k-shortest paths by Ramesh Bhandari (He has > published a book and provided reference in a previous mail on this list), > Eppstein (UC,Berkely), Prof Grover at University of Alberta (also TRLabs). > Marali K and T.V.Laksham work has references to the above work as well. > > Hope this answers your questions. > > Manohar > > ----- Original Message ----- > From: "Wushao Wen" > To: > Sent: Sunday, January 21, 2001 8:09 PM > Subject: Book on calculating two alternative shortest paths > > > Hi, > > I remember there is a book or paper on how to calculate two shortest > > paths from a source to a destination in a mesh network. The author also > > mention it in this mailing list. Can someone please tell me the book name > > or the author name? > > Thank you very much! > > > > > > Wushao Wen > > From owner-mpls@UU.NET Mon Jan 22 10:13:00 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06128 for ; Mon, 22 Jan 2001 10:13:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbw13297; Mon, 22 Jan 2001 15:11:03 GMT Received: by mail-control.mail.uu.net id QQjzbw10921 for mpls-outgoing; Mon, 22 Jan 2001 15:10:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzbw10913 for ; Mon, 22 Jan 2001 15:10:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzbw19049 for ; Mon, 22 Jan 2001 15:10:21 GMT Received: from roam.psg.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dhcp70.ripemtg.ripe.net [193.0.4.70]) id QQjzbw12220 for ; Mon, 22 Jan 2001 15:10:20 GMT Received: from randy by roam.psg.com with local (Exim 3.12 #1) id 14Kibh-0000c1-00; Mon, 22 Jan 2001 16:10:09 +0100 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Peter Lewis" Cc: Subject: Re: First international MPLS exhibition References: <027701c08480$399c5180$8001a8c0@oleane.com> Message-Id: Date: Mon, 22 Jan 2001 16:10:09 +0100 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > http://www.upperside.fr/congress/exhi.htm > First international MPLS exhibition floorplan. Paris. where is the drain for the slime spammers like you? randy From owner-mpls@UU.NET Mon Jan 22 10:26:54 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06408 for ; Mon, 22 Jan 2001 10:26:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbx05710; Mon, 22 Jan 2001 15:24:38 GMT Received: by mail-control.mail.uu.net id QQjzbx12716 for mpls-outgoing; Mon, 22 Jan 2001 15:24:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzbx12703 for ; Mon, 22 Jan 2001 15:23:54 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 QQjzbx05845 for ; Mon, 22 Jan 2001 15:21:58 GMT Received: from longwood.cs.ucf.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: longwood.cs.ucf.edu [132.170.108.1]) id QQjzbx01368 for ; Mon, 22 Jan 2001 15:21:58 GMT Received: from eola.cs.ucf.edu (eola [132.170.108.2]) by longwood.cs.ucf.edu (8.11.1/8.11.1) with ESMTP id f0MFLvw22346 for ; Mon, 22 Jan 2001 10:21:57 -0500 (EST) From: Arturo Nunez Received: (from artnpp@localhost) by eola.cs.ucf.edu (8.9.3/8.9.0) id KAA20862 for mpls@uu.net; Mon, 22 Jan 2001 10:20:43 -0500 (EST) Message-Id: <200101221520.KAA20862@eola.cs.ucf.edu> Subject: RE: RE: Question about Labels To: mpls@UU.NET Date: Mon, 22 Jan 2001 10:20:42 -0500 (EST) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi: Thanks for the answer. I have another questions > > > > Why should be labels different in the devices that are near > > > and even why > > > are they different in all the devices involved in all the route ?? > > > > Labels only have local significance - OK.. Thats clear now. Now, what about multiple services (FECs) that may follow a same path ?? How the protocol manage the same route, just with another labels ?? > > > 2) What happend if the the tables, routes, in the Network > > change, what is > > that related with the labels, how do they change ?? Does it > > has to be with > > the LDP ?? > >The IGP routes in the table are kept separate from LDP / RSVP LSP routes. > >Should the LSP break in response to a link being broken the information is > > communicated back down the path to the source of the LSP and is be > > recalculated using IGP information from there. There are a few extra > > failovers a LSP can deploy to help the switch over - these are known as > > secondary routes and fast reroute. So as I understand the RVSP must be checking for the integrity of the LSP, is that correct ?? Regards Arturo Nunez From owner-mpls@UU.NET Mon Jan 22 10:27:49 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06432 for ; Mon, 22 Jan 2001 10:27:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbx08102; Mon, 22 Jan 2001 15:26:22 GMT Received: by mail-control.mail.uu.net id QQjzbx12991 for mpls-outgoing; Mon, 22 Jan 2001 15:25:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzbx12981 for ; Mon, 22 Jan 2001 15:25:48 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 QQjzbx24784 for ; Mon, 22 Jan 2001 15:24:20 GMT From: emildrottar@auranetinc.com Received: from tardis.lancast.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tardis.lancast.com [12.25.4.9]) id QQjzbx11493 for ; Mon, 22 Jan 2001 15:24:19 GMT Received: by TARDIS with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jan 2001 10:25:48 -0500 Message-ID: <6FBF00711D96D31193EA009027D5E5CE743AAA@TARDIS> To: randy@psg.com, peter.lewis@upperside.fr Cc: mpls@UU.NET Subject: RE: First international MPLS exhibition Date: Mon, 22 Jan 2001 10:25:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I would like to ask that Mr Lewis either refrain from abusing this reflector, or that he be removed from the subscription list and all his future EMAIL be blocked upon his next offense. Emil -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, January 22, 2001 10:10 AM To: Peter Lewis Cc: mpls@UU.NET Subject: Re: First international MPLS exhibition > http://www.upperside.fr/congress/exhi.htm > First international MPLS exhibition floorplan. Paris. where is the drain for the slime spammers like you? randy From owner-mpls@UU.NET Mon Jan 22 10:33:20 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06587 for ; Mon, 22 Jan 2001 10:33:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbw25107; Mon, 22 Jan 2001 15:07:31 GMT Received: by mail-control.mail.uu.net id QQjzbw10493 for mpls-outgoing; Mon, 22 Jan 2001 15:07:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzbw10488 for ; Mon, 22 Jan 2001 15:07:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjzbw03218 for ; Mon, 22 Jan 2001 15:06:57 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQjzbw12916 for ; Mon, 22 Jan 2001 15:06:56 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA11499 for ; Mon, 22 Jan 2001 07:07:09 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA00450 for mpls@uu.net; Mon, 22 Jan 2001 10:06:54 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjyri28813 for ; Fri, 19 Jan 2001 18:42:28 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 QQjyri02244 for ; Fri, 19 Jan 2001 18:42:11 GMT Received: from jasmine1.ad.jasminenetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQjyri13326 for ; Fri, 19 Jan 2001 18:42:10 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Jan 2001 10:42:07 -0800 Message-ID: From: Vishal Sharma To: "'Metz, E.T.'" , "'richard.crouch@vf.vodafone.co.uk'" Cc: mpls@UU.NET Subject: RE: Implications of cell-based or frame-based MPLS Date: Fri, 19 Jan 2001 10:42:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Richard, One thing that wasn't clear from your question was whether in the cell-based network you were planning to run only MPLS or were you thinking of, as Eduard has pointed out, mixing ATM and cell-based MPLS? If the former, then why can you not have a two level label stack, comprised of switching on both VPI and VCI? (Of course, if you are thinking of somehow mixing services, you'd probably have to keep the VPI for switching native ATM services.) Also, on the subject of mixing services. Are you then thinking of running a "ships-in-the-night" mode on the cell-based, ATM devices ? -Vishal > -----Original Message----- > From: Metz, E.T. [mailto:E.T.Metz@kpn.com] > Sent: Friday, January 19, 2001 7:35 AM > To: 'richard.crouch@vf.vodafone.co.uk' > Cc: mpls@UU.NET > Subject: RE: Implications of cell-based or frame-based MPLS > > > > > > > > (1) What are the other major differences in > > performance/capabilities as a > > consequence of these two different implementations of MPLS > > (cell versus > > packet-based) ? > > > > One is segmentation and reassembly. Even in the cell-based > network you will > have a boundary (typically the PE) where you transform the IP > packets into > cells and vice-versa. As far as I know this is not a function > that performs > really well at high-speeds. > > > (2) In the area of MPLS applications such as MPLS-VPNs, MPLS > > traffic-engineering and fast-reroute, what impacts are caused by the > > inability of an ATM-LSR to pop/push labels in the label stack > > compared to a > > "frame/packet-based" LSR (which can pop/push labels in the > > label stack) ? > > > > The inability of ATM-LSR to deal with stack depths > 1 > requires you to use > packet-based PEs with a cell-interface towards the core > (introducing the SAR > issue). Alternatively, you could make an ATM switch perform packet > operations (having the SAR issue twice), however, I doubt if > this would > perform really well. > > > In a most crude form, I am asking the question "what's better > > : cell-mode or > > frame/packet-mode MPLS" > > It is not a matter of good and bad, but rather a matter of needs. > > If you only use the network for IP traffic only, I do not see > a particular > need to introduce cell-based platforms. On the other hand > they may prove to > be very useful if a significant part of your traffic is e.g. > due to (native) > ATM services. In that case you could mix IP and ATM in the same core > platform (although there are sufficient people that would > argue this is a > bad idea as well) > > Hope this helped a bit ... > > cheers, > Eduard > > > > Richard Crouch (CND-T - Vodafone Ltd.) > > > From owner-mpls@UU.NET Mon Jan 22 10:39:40 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06684 for ; Mon, 22 Jan 2001 10:39:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzby00313; Mon, 22 Jan 2001 15:37:43 GMT Received: by mail-control.mail.uu.net id QQjzby14628 for mpls-outgoing; Mon, 22 Jan 2001 15:37:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzby14622 for ; Mon, 22 Jan 2001 15:37:04 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 QQjzby27694 for ; Mon, 22 Jan 2001 15:35:51 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 QQjzby19161 for ; Mon, 22 Jan 2001 15:35:51 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 KAA03554 for ; Mon, 22 Jan 2001 10:35:49 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10476 for ; Mon, 22 Jan 2001 10:35:50 -0500 (EST) Message-ID: <3A6C536B.FD44FFB6@marconi.com> Date: Mon, 22 Jan 2001 10:36:11 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: FEC element for RSVP-TE? References: <852569DA.00107C57.00@kanmta01.software.mitel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit James_Huang@Mitel.COM wrote: > > I have one question in mind when reading the RSVP-TE draft. Does > RSVP-TE define some object similar to FEC element in the LDP draft so > that we can set up a LSP for traffics belonging to the FEC? No. RSVP-TE is not a label-distribution protocol. It is a tunnel setup protocol. This is an important semantic difference. > If the RSVP path message does not carry such object and it does not > carry a ER object, then intermediate LSR can only use the destination > IP address in the session object to determine the next hop. Correct. > This means the ingress RSVP initiator need to know exactly who will be > the egress router when it sends out the RSVP path message. This > does not seem to be very pratical to me in the case where RSVP-TE is > used to set up a LSP tunnel for traffics belonging to a FEC to meet > its bandwidth requirements. RSVP-TE is addressing a different problem from LDP. LDP's goal is to get labels on all the switches so that they may be used in lieu of IP best-match algorithms when forwarding traffic. Its goal is not to establish tunnels, although that does happen as a result of label distribution. RSVP-TE's goal is to establish tunnels between endpoints. In order to do so, it must know what those endpoints are. Its goal is not to distribute labels, although that does happen as a part of establishing tunnels. In other words, there are situations where LDP makes more sense than RSVP. One such situation is where you don't know, and can't determine, where your tunnel endpoints will be. There are also situations where RSVP makes more sense than LDP. One such sitation is where shared reservations (for make-before-break rerouting) is required. -- David From owner-mpls@UU.NET Mon Jan 22 10:45:06 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06854 for ; Mon, 22 Jan 2001 10:45:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzby26459; Mon, 22 Jan 2001 15:42:08 GMT Received: by mail-control.mail.uu.net id QQjzby15323 for mpls-outgoing; Mon, 22 Jan 2001 15:41:36 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzby15303 for ; Mon, 22 Jan 2001 15:41: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 QQjzby20511 for ; Mon, 22 Jan 2001 15:41:20 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzby25515 for ; Mon, 22 Jan 2001 15:41:20 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA13038 for mpls@uu.net; Mon, 22 Jan 2001 10:41:19 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzby15086 for ; Mon, 22 Jan 2001 15:40:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzby18443 for ; Mon, 22 Jan 2001 15:40:24 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQjzby24382 for ; Mon, 22 Jan 2001 15:40:23 GMT Received: from lir.cisco.com (lir.cisco.com [161.44.172.144]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA19772; Mon, 22 Jan 2001 10:40:22 -0500 (EST) Received: from localhost (swallow@localhost) by lir.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id KAA26619; Mon, 22 Jan 2001 10:40:22 -0500 (EST) Message-Id: <200101221540.KAA26619@lir.cisco.com> X-Authentication-Warning: lir.cisco.com: swallow owned process doing -bs To: emildrottar@auranetinc.com cc: randy@psg.com, peter.lewis@upperside.fr, mpls@UU.NET, swallow@cisco.com Subject: Re: First international MPLS exhibition In-reply-to: Your message of "Mon, 22 Jan 2001 10:25:41 EST." <6FBF00711D96D31193EA009027D5E5CE743AAA@TARDIS> Date: Mon, 22 Jan 2001 10:40:22 -0500 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Emil - > I would like to ask that Mr Lewis either refrain from abusing this > reflector, or that he be removed from the subscription list and all his > future EMAIL be blocked upon his next offense. I've already sent private mail to Mr Lewis that one more offense will result in a filter. (Or maybe I should just ask everyone on the list to spam Upperside ;-). ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Mon Jan 22 10:51:09 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06960 for ; Mon, 22 Jan 2001 10:51:08 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbz21577; Mon, 22 Jan 2001 15:49:06 GMT Received: by mail-control.mail.uu.net id QQjzbz16536 for mpls-outgoing; Mon, 22 Jan 2001 15:48:20 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzbz16485 for ; Mon, 22 Jan 2001 15:48: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 QQjzbz00420 for ; Mon, 22 Jan 2001 15:47:27 GMT Received: from winstar.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fw-1.winstar.com [207.86.108.130]) id QQjzbz11674 for ; Mon, 22 Jan 2001 15:47:26 GMT Received: from vaawsh032382 (dhcp-vaa-1-183-046.winstar.com [10.1.183.46]) by winstar.com (8.9.3/8.9.1) with SMTP id KAA26006; Mon, 22 Jan 2001 10:46:56 -0500 (EST) From: "Yi Chu" To: "Vishal Sharma" , "'Metz, E.T.'" , Cc: Subject: RE: Implications of cell-based or frame-based MPLS Date: Mon, 22 Jan 2001 10:43:56 -0500 Message-ID: <000701c0848a$21cd7480$2eb7010a@winstar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I am not clear as to how 'ships-in-the-night' works on an ATM device. Can someone explain the concept or point me to an archive if it has been discussed before? Thanks. yi -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Vishal Sharma Sent: Friday, January 19, 2001 1:42 PM To: 'Metz, E.T.'; 'richard.crouch@vf.vodafone.co.uk' Cc: mpls@UU.NET Subject: RE: Implications of cell-based or frame-based MPLS Richard, One thing that wasn't clear from your question was whether in the cell-based network you were planning to run only MPLS or were you thinking of, as Eduard has pointed out, mixing ATM and cell-based MPLS? If the former, then why can you not have a two level label stack, comprised of switching on both VPI and VCI? (Of course, if you are thinking of somehow mixing services, you'd probably have to keep the VPI for switching native ATM services.) Also, on the subject of mixing services. Are you then thinking of running a "ships-in-the-night" mode on the cell-based, ATM devices ? -Vishal > -----Original Message----- > From: Metz, E.T. [mailto:E.T.Metz@kpn.com] > Sent: Friday, January 19, 2001 7:35 AM > To: 'richard.crouch@vf.vodafone.co.uk' > Cc: mpls@UU.NET > Subject: RE: Implications of cell-based or frame-based MPLS > > > > > > > > (1) What are the other major differences in > > performance/capabilities as a > > consequence of these two different implementations of MPLS > > (cell versus > > packet-based) ? > > > > One is segmentation and reassembly. Even in the cell-based > network you will > have a boundary (typically the PE) where you transform the IP > packets into > cells and vice-versa. As far as I know this is not a function > that performs > really well at high-speeds. > > > (2) In the area of MPLS applications such as MPLS-VPNs, MPLS > > traffic-engineering and fast-reroute, what impacts are caused by the > > inability of an ATM-LSR to pop/push labels in the label stack > > compared to a > > "frame/packet-based" LSR (which can pop/push labels in the > > label stack) ? > > > > The inability of ATM-LSR to deal with stack depths > 1 > requires you to use > packet-based PEs with a cell-interface towards the core > (introducing the SAR > issue). Alternatively, you could make an ATM switch perform packet > operations (having the SAR issue twice), however, I doubt if > this would > perform really well. > > > In a most crude form, I am asking the question "what's better > > : cell-mode or > > frame/packet-mode MPLS" > > It is not a matter of good and bad, but rather a matter of needs. > > If you only use the network for IP traffic only, I do not see > a particular > need to introduce cell-based platforms. On the other hand > they may prove to > be very useful if a significant part of your traffic is e.g. > due to (native) > ATM services. In that case you could mix IP and ATM in the same core > platform (although there are sufficient people that would > argue this is a > bad idea as well) > > Hope this helped a bit ... > > cheers, > Eduard > > > > Richard Crouch (CND-T - Vodafone Ltd.) > > > From owner-mpls@UU.NET Mon Jan 22 10:55:50 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07079 for ; Mon, 22 Jan 2001 10:55:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzbz00409; Mon, 22 Jan 2001 15:54:13 GMT Received: by mail-control.mail.uu.net id QQjzbz17202 for mpls-outgoing; Mon, 22 Jan 2001 15:53:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzbz17179 for ; Mon, 22 Jan 2001 15:53: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 QQjzbz16179 for ; Mon, 22 Jan 2001 15:52:36 GMT Received: from mail2.orchestream.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [195.153.64.126]) id QQjzbz17905 for ; Mon, 22 Jan 2001 15:52:35 GMT Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 22 Jan 2001 15:53:12 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id PAA16700; Mon, 22 Jan 2001 15:44:35 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 15:49:48 -0000 Message-ID: From: "Morgan, Richard" To: "'Arturo Nunez'" , mpls@UU.NET Subject: RE: RE: Question about Labels Date: Mon, 22 Jan 2001 15:49:43 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > OK.. Thats clear now. > Now, what about multiple services (FECs) that may follow a > same path ?? > How the protocol manage the same route, just with another labels ?? Yep one LSP per FEC, they may well take entirely different routes around the network. For instance one might be low latency and use different physical links. So it is irrelavant that they use the same path, as each stream is separated into different LSP's and these are dealt with individually. > So as I understand the RVSP must be checking for the > integrity of the LSP, > is that correct ?? Yes a static LSP which is hand configured has no fail over, should a link fail it will become a black hole for packets. RSVP sends periodic Hello messages up stream, this is done node to node rather than end to end. Should the hello message not be acknowledged RSVP will give the link a little more time to recover and on failing this it will send a tear down message down stream to the originating router. The timers on these checks can be set on the RSVP path setup. Interestingly this is one of the scalabity problems with RSVP tunnels - how many RSVP tunnels can a router be expected to mantain and check? I don't know much about how LDP copes with link failure but it also has to check. Rich From owner-mpls@UU.NET Mon Jan 22 11:04:45 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07355 for ; Mon, 22 Jan 2001 11:04:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzca18157; Mon, 22 Jan 2001 16:01:02 GMT Received: by mail-control.mail.uu.net id QQjzca18704 for mpls-outgoing; Mon, 22 Jan 2001 16:00:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzca18658 for ; Mon, 22 Jan 2001 16:00:24 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 QQjzbz01766 for ; Mon, 22 Jan 2001 15:58:18 GMT Received: from bgslc02.TBG.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQjzbz07164 for ; Mon, 22 Jan 2001 15:58:17 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 08:51:51 -0700 Message-ID: <0C875DC28791D21192CD00104B95BFE70146D307@BGSLC02> From: Irwin Lazar To: mpls@UU.NET Subject: RE: Implications of cell-based or frame-based MPLS Date: Mon, 22 Jan 2001 08:51:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk The basic concept is that an ATM switch can play dual roles. It can continue to switch native ATM traffic on some interfaces, while also supporting MPLS on other interfaces. I've seen a few products in which the MPLS and ATM control planes can actually communicate, so that the MPLS control plane doesn't try to reserve resources that are currently allocated to the ATM control plane and vice-versa. In other devices, there is no communication so you run the risk of oversubscription. This question is answered in greater detail in the MPLS FAQ at www.mplsrc.com/mplsfaq.shtml Irwin -----Original Message----- From: Yi Chu [mailto:ychu@winstar.com] Sent: Monday, January 22, 2001 10:44 AM To: Vishal Sharma; 'Metz, E.T.'; richard.crouch@vf.vodafone.co.uk Cc: mpls@UU.NET Subject: RE: Implications of cell-based or frame-based MPLS I am not clear as to how 'ships-in-the-night' works on an ATM device. Can someone explain the concept or point me to an archive if it has been discussed before? Thanks. yi -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET] On Behalf Of Vishal Sharma Sent: Friday, January 19, 2001 1:42 PM To: 'Metz, E.T.'; 'richard.crouch@vf.vodafone.co.uk' Cc: mpls@UU.NET Subject: RE: Implications of cell-based or frame-based MPLS Richard, One thing that wasn't clear from your question was whether in the cell-based network you were planning to run only MPLS or were you thinking of, as Eduard has pointed out, mixing ATM and cell-based MPLS? If the former, then why can you not have a two level label stack, comprised of switching on both VPI and VCI? (Of course, if you are thinking of somehow mixing services, you'd probably have to keep the VPI for switching native ATM services.) Also, on the subject of mixing services. Are you then thinking of running a "ships-in-the-night" mode on the cell-based, ATM devices ? -Vishal > -----Original Message----- > From: Metz, E.T. [mailto:E.T.Metz@kpn.com] > Sent: Friday, January 19, 2001 7:35 AM > To: 'richard.crouch@vf.vodafone.co.uk' > Cc: mpls@UU.NET > Subject: RE: Implications of cell-based or frame-based MPLS > > > > > > > > (1) What are the other major differences in > > performance/capabilities as a > > consequence of these two different implementations of MPLS > > (cell versus > > packet-based) ? > > > > One is segmentation and reassembly. Even in the cell-based > network you will > have a boundary (typically the PE) where you transform the IP > packets into > cells and vice-versa. As far as I know this is not a function > that performs > really well at high-speeds. > > > (2) In the area of MPLS applications such as MPLS-VPNs, MPLS > > traffic-engineering and fast-reroute, what impacts are caused by the > > inability of an ATM-LSR to pop/push labels in the label stack > > compared to a > > "frame/packet-based" LSR (which can pop/push labels in the > > label stack) ? > > > > The inability of ATM-LSR to deal with stack depths > 1 > requires you to use > packet-based PEs with a cell-interface towards the core > (introducing the SAR > issue). Alternatively, you could make an ATM switch perform packet > operations (having the SAR issue twice), however, I doubt if > this would > perform really well. > > > In a most crude form, I am asking the question "what's better > > : cell-mode or > > frame/packet-mode MPLS" > > It is not a matter of good and bad, but rather a matter of needs. > > If you only use the network for IP traffic only, I do not see > a particular > need to introduce cell-based platforms. On the other hand > they may prove to > be very useful if a significant part of your traffic is e.g. > due to (native) > ATM services. In that case you could mix IP and ATM in the same core > platform (although there are sufficient people that would > argue this is a > bad idea as well) > > Hope this helped a bit ... > > cheers, > Eduard > > > > Richard Crouch (CND-T - Vodafone Ltd.) > > > From owner-mpls@UU.NET Mon Jan 22 11:22:24 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07883 for ; Mon, 22 Jan 2001 11:22:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzcb19350; Mon, 22 Jan 2001 16:20:19 GMT Received: by mail-control.mail.uu.net id QQjzcb02552 for mpls-outgoing; Mon, 22 Jan 2001 16:19:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzcb02539 for ; Mon, 22 Jan 2001 16:19: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 QQjzcb00641 for ; Mon, 22 Jan 2001 16:18:32 GMT Received: from dnsmx2pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQjzcb17451 for ; Mon, 22 Jan 2001 16:18:32 GMT Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id LAA16185 for ; Mon, 22 Jan 2001 11:16:09 -0500 (EST) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852569DC.00595AB6 ; Mon, 22 Jan 2001 11:15:59 -0500 X-Lotus-FromDomain: TELCORDIA From: "Robert Streijl" To: mpls@UU.NET Message-ID: <852569DC.005958D2.00@notes950.cc.telcordia.com> Date: Mon, 22 Jan 2001 11:15:45 -0500 Subject: MPLS OAM? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi, Quick question: Is there any work going on in OAM functionality for MPLS? If so, can anybody tell me where? If not, why not? Thanks very much. Regards, Robert From owner-mpls@UU.NET Mon Jan 22 11:33:21 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08119 for ; Mon, 22 Jan 2001 11:33:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzcc29915; Mon, 22 Jan 2001 16:31:31 GMT Received: by mail-control.mail.uu.net id QQjzcc04097 for mpls-outgoing; Mon, 22 Jan 2001 16:30:58 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzcc04078 for ; Mon, 22 Jan 2001 16:30:50 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 QQjzcc15140 for ; Mon, 22 Jan 2001 16:30: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 QQjzcc01515 for ; Mon, 22 Jan 2001 16:30:16 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 LAA09673 for ; Mon, 22 Jan 2001 11:30:09 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27379 for ; Mon, 22 Jan 2001 11:30:10 -0500 (EST) Message-ID: <3A6C6027.4E5D4F68@marconi.com> Date: Mon, 22 Jan 2001 11:30:31 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Question about Labels References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Morgan, Richard" wrote: >> >> OK.. Thats clear now. Now, what about multiple services (FECs) that >> may follow a same path ?? >> How the protocol manage the same route, just with another labels ?? > > Yep one LSP per FEC, they may well take entirely different routes > around the network. For instance one might be low latency and use > different physical links. So it is irrelavant that they use the same > path, as each stream is separated into different LSP's and these are > dealt with individually. Note that per FEC does not necessarily mean per IP prefix. Multiple prefixes that all leave the MPLS cloud through a common router interface and have identical traffic characteristics can be considered a single FEC and can use a single LSP. >> So as I understand the RVSP must be checking for the >> integrity of the LSP, >> is that correct ?? > > Yes a static LSP which is hand configured has no fail over, should a > link fail it will become a black hole for packets. RSVP sends periodic > Hello messages up stream, this is done node to node rather than end to > end. Should the hello message not be acknowledged RSVP will give the > link a little more time to recover and on failing this it will send a > tear down message down stream to the originating router. The timers on > these checks can be set on the RSVP path setup. Interestingly this is > one of the scalabity problems with RSVP tunnels - how many RSVP > tunnels can a router be expected to mantain and check? I don't know > much about how LDP copes with link failure but it also has to check. RSVP is a soft-state protocol. Every setup message (Path and Resv) that is sent is periodically resent. If these refreshes stop happening, then the neighbor switch assumes that it missed a teardown message and does its own teardown of the corresponding state. RSVP Hello is an extension, provided by the -TE extensions. RSVP Hello can detect node and link failure. It does not, however, provide for reliable message delivery, and so does not eliminate the need for refreshing state. Note that Hello messages are sent on a per-interface basis, while refreshes are on a per-LSP basis. The RSVP working group has a set of optional refresh-reduction extensions which (among other things) does provide a mechanism for reliable message delivery. When used in conjunction with hello messages, it can eliminate the need for periodic refreshes. This is one of the key ways of getting RSVP to scale up to huge numbers of sessions. WRT LDP, this isn't a problem. LDP messages are not periodically refreshed. Since TCP is used for message delivery, reliability is assumed. State remains until neighbor failure is detected or the state is explicitly torn. Neighbor failure is detected under one of three conditions: - The neighbor stops broadcasting Hello discovery messages - The neighbor stops sending Keepalive messages on the TCP connection. - The TCP connection to the neighbor breaks. -- David From owner-mpls@UU.NET Mon Jan 22 11:37:26 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08214 for ; Mon, 22 Jan 2001 11:37:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzcc07821; Mon, 22 Jan 2001 16:35:02 GMT Received: by mail-control.mail.uu.net id QQjzcc04574 for mpls-outgoing; Mon, 22 Jan 2001 16:34:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzcc04550 for ; Mon, 22 Jan 2001 16:34:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzcc27603 for ; Mon, 22 Jan 2001 16:34:12 GMT From: neil.2.harrison@bt.com Received: from gollum.axion.bt.co.uk by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gollum.axion.bt.co.uk [132.146.17.41]) id QQjzcc27557 for ; Mon, 22 Jan 2001 16:34:12 GMT Received: from cirwm3nt01.nor.bt.com by gollum (local) with ESMTP; Mon, 22 Jan 2001 16:31:22 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Mon, 22 Jan 2001 16:30:51 -0000 Message-ID: To: rstreijl@telcordia.com, mpls@UU.NET Subject: RE: MPLS OAM? Date: Mon, 22 Jan 2001 16:30:51 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Robert Strenijl asked: Quick question: Is there any work going on in OAM functionality for MPLS? If so, can anybody tell me where? If not, why not? NH=> Yes there is. I and a couple of other peopl (eg Shahram Davari and Ben Mack-Crane) are looking into this. I'll send you a separate/direct mail with some attachments on where things stand. From owner-mpls@UU.NET Mon Jan 22 11:53:25 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08575 for ; Mon, 22 Jan 2001 11:53:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzcd18278; Mon, 22 Jan 2001 16:51:04 GMT Received: by mail-control.mail.uu.net id QQjzcd06411 for mpls-outgoing; Mon, 22 Jan 2001 16:50:29 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzcd06397 for ; Mon, 22 Jan 2001 16:50:19 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 QQjzcd25392 for ; Mon, 22 Jan 2001 16:49:48 GMT Received: from longwood.cs.ucf.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: longwood.cs.ucf.edu [132.170.108.1]) id QQjzcd26470 for ; Mon, 22 Jan 2001 16:49:48 GMT Received: from iris.cs.ucf.edu (iris [132.170.108.55]) by longwood.cs.ucf.edu (8.11.1/8.11.1) with ESMTP id f0MGnlw25718 for ; Mon, 22 Jan 2001 11:49:47 -0500 (EST) From: Arturo Nunez Received: (from artnpp@localhost) by iris.cs.ucf.edu (8.9.3/8.9.0) id LAA03714 for mpls@uu.net; Mon, 22 Jan 2001 11:48:05 -0500 (EST) Message-Id: <200101221648.LAA03714@iris.cs.ucf.edu> Subject: Re: Question about Labels To: mpls@UU.NET Date: Mon, 22 Jan 2001 11:48:05 -0500 (EST) In-Reply-To: <3A6C6027.4E5D4F68@marconi.com> from "David Charlap" at Jan 22, 2001 11:30:31 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit HI: > >> > >> OK.. Thats clear now. Now, what about multiple services (FECs) that > >> may follow a same path ?? > >> How the protocol manage the same route, just with another labels ?? > > > > Yep one LSP per FEC, they may well take entirely different routes > > around the network. For instance one might be low latency and use > > different physical links. So it is irrelavant that they use the same > > path, as each stream is separated into different LSP's and these are > > dealt with individually. > > Note that per FEC does not necessarily mean per IP prefix. Multiple > prefixes that all leave the MPLS cloud through a common router interface > and have identical traffic characteristics can be considered a single > FEC and can use a single LSP. In the worst case. If we have different FECs[Services] that have the same [origin] and the same [desteny] Will they have different LSPs , created with different labels ?? I guess yes .. Regards Arturo Nunez From owner-mpls@UU.NET Mon Jan 22 12:26:23 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09537 for ; Mon, 22 Jan 2001 12:26:23 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzcf09171; Mon, 22 Jan 2001 17:24:28 GMT Received: by mail-control.mail.uu.net id QQjzcf22199 for mpls-outgoing; Mon, 22 Jan 2001 17:23:58 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzcf22191 for ; Mon, 22 Jan 2001 17:23:56 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 QQjzcf17712 for ; Mon, 22 Jan 2001 17:22:37 GMT Received: from longwood.cs.ucf.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: longwood.cs.ucf.edu [132.170.108.1]) id QQjzcf06896 for ; Mon, 22 Jan 2001 17:22:37 GMT Received: from iris.cs.ucf.edu (iris [132.170.108.55]) by longwood.cs.ucf.edu (8.11.1/8.11.1) with ESMTP id f0MHMaw26956 for ; Mon, 22 Jan 2001 12:22:36 -0500 (EST) From: Arturo Nunez Received: (from artnpp@localhost) by iris.cs.ucf.edu (8.9.3/8.9.0) id MAA03741 for mpls@uu.net; Mon, 22 Jan 2001 12:20:54 -0500 (EST) Message-Id: <200101221720.MAA03741@iris.cs.ucf.edu> Subject: Re: Question about Labels To: mpls@UU.NET Date: Mon, 22 Jan 2001 12:20:54 -0500 (EST) In-Reply-To: <200101221648.LAA03714@iris.cs.ucf.edu> from "Arturo Nunez" at Jan 22, 2001 11:48:05 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit HI: > HI: > > > >> > > >> OK.. Thats clear now. Now, what about multiple services (FECs) that > > >> may follow a same path ?? > > >> How the protocol manage the same route, just with another labels ?? > > > > > > Yep one LSP per FEC, they may well take entirely different routes > > > around the network. For instance one might be low latency and use > > > different physical links. So it is irrelavant that they use the same > > > path, as each stream is separated into different LSP's and these are > > > dealt with individually. > > > > Note that per FEC does not necessarily mean per IP prefix. Multiple > > prefixes that all leave the MPLS cloud through a common router interface > > and have identical traffic characteristics can be considered a single > > FEC and can use a single LSP. > In the worst case. > If we have different FECs[Services] that have the same [origin] and the same [desteny] > Will they have different LSPs , created with different labels ?? > I guess yes .. > As I have readed a Label has the following fields Label|CoS|Stack|TTL So if we have almost the same path from the origin to the destiny and the only difference is the FEC , in what field will be the difference: - Label or Stack ?? Regards Arturo Nunez From owner-mpls@UU.NET Mon Jan 22 12:37:21 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09803 for ; Mon, 22 Jan 2001 12:37:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzcg28016; Mon, 22 Jan 2001 17:34:54 GMT Received: by mail-control.mail.uu.net id QQjzcg23352 for mpls-outgoing; Mon, 22 Jan 2001 17:34:21 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzcg23337 for ; Mon, 22 Jan 2001 17:34:04 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 QQjzcg04868 for ; Mon, 22 Jan 2001 17:33:10 GMT Received: from mail2.orchestream.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [195.153.64.126]) id QQjzcg25691 for ; Mon, 22 Jan 2001 17:33:09 GMT Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 22 Jan 2001 17:33:46 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id RAA18179; Mon, 22 Jan 2001 17:25:08 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 17:30:22 -0000 Message-ID: From: "Morgan, Richard" To: "'David Charlap'" Cc: "'Arturo Nunez'" , "'mpls@uu.net'" Subject: RE: Question about Labels Date: Mon, 22 Jan 2001 17:30:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > Note that per FEC does not necessarily mean per IP prefix. Multiple > prefixes that all leave the MPLS cloud through a common > router interface > and have identical traffic characteristics can be considered a single > FEC and can use a single LSP. Opps! I was wondering when I would finally put my foot in my mouth. I was considering FEC to be a diffserv thing and it is not. I was also considering LSP's created by an IGP to be a tree following the FEC, as opposed to point to point LSP's like generated by LDP / RSVP, of course they are also called LSP's and I misunderstood the question. Thankyou for correcting me :) > WRT LDP, this isn't a problem. LDP messages are not periodically > refreshed. Since TCP is used for message delivery, reliability is > assumed. State remains until neighbor failure is detected or > the state > is explicitly torn. Neighbor failure is detected under one of three > conditions: > - The neighbor stops broadcasting Hello discovery messages > - The neighbor stops sending Keepalive messages on the TCP > connection. > - The TCP connection to the neighbor breaks. That's cleared that for me Rich From owner-mpls@UU.NET Mon Jan 22 12:39:37 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09851 for ; Mon, 22 Jan 2001 12:39:37 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzcg14950; Mon, 22 Jan 2001 17:37:48 GMT Received: by mail-control.mail.uu.net id QQjzcg23694 for mpls-outgoing; Mon, 22 Jan 2001 17:37:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzcg23681 for ; Mon, 22 Jan 2001 17:37: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 QQjzcg13926 for ; Mon, 22 Jan 2001 17:37:02 GMT Received: from zcars04f.ca.nortel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) id QQjzcg13976 for ; Mon, 22 Jan 2001 17:37:01 GMT Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 22 Jan 2001 11:51:20 -0500 Received: from pftzd0fc.ca.nortel.com (bcarua63.ca.nortel.com [47.130.9.7]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DLANJ373; Mon, 22 Jan 2001 11:47:42 -0500 Received: from americasm01.nt.com (bcarse58.ca.nortel.com [47.129.149.168]) by pftzd0fc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YFWAR3HN; Mon, 22 Jan 2001 11:47:43 -0500 Message-ID: <3A6C642F.E5069BB9@americasm01.nt.com> Date: Mon, 22 Jan 2001 11:47:43 -0500 From: "Eugene Plaoude" Organization: Nortel Networks X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: rstreijl@telcordia.com, mpls@UU.NET Subject: Re: MPLS OAM? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Could you please share that with me as well ? Thanks in advance, Eugene. neil.2.harrison@bt.com wrote: > Robert Strenijl asked: > Quick question: Is there any work going on in OAM functionality for MPLS? > If so, can anybody tell me where? If not, why not? > > NH=> Yes there is. I and a couple of other peopl (eg Shahram Davari and Ben > Mack-Crane) are looking into this. I'll send you a separate/direct mail > with some attachments on where things stand. From owner-mpls@UU.NET Mon Jan 22 13:48:10 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11572 for ; Mon, 22 Jan 2001 13:48:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzcl16795; Mon, 22 Jan 2001 18:46:14 GMT Received: by mail-control.mail.uu.net id QQjzcl13779 for mpls-outgoing; Mon, 22 Jan 2001 18:45:42 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzcl13760 for ; Mon, 22 Jan 2001 18:45:26 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 QQjzck19561 for ; Mon, 22 Jan 2001 18:44:14 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzck14728 for ; Mon, 22 Jan 2001 18:44:13 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA00052 for mpls@uu.net; Mon, 22 Jan 2001 13:44:12 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzck13365 for ; Mon, 22 Jan 2001 18:43:30 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 QQjzck16721 for ; Mon, 22 Jan 2001 18:43:01 GMT Received: from mta6.snfc21.pbi.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mta6.snfc21.pbi.net [206.13.28.240]) id QQjzck02794 for ; Mon, 22 Jan 2001 18:43:01 GMT Received: from redback.com ([63.200.49.242]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G7K0067GTLCO8@mta6.snfc21.pbi.net> for mpls@UU.NET; Mon, 22 Jan 2001 10:20:00 -0800 (PST) Date: Mon, 22 Jan 2001 09:15:29 -0800 From: Tony Przygienda Subject: Re: Book on calculating two alternative shortest paths To: Ramesh Bhandari Cc: Manohar Ellanti , Wushao Wen , mpls@UU.NET Message-id: <3A6C6AB0.28FDB171@redback.com> Organization: Siara Systems MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; NetBSD 1.4.1 i386) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <009601c08491$55d942c0$1cd01318@frmt1.sfba.home.com> <3A6C4B75.A9191D4D@hotair.hobl.lucent.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ramesh Bhandari wrote: > Wushao Wen, > > I am the author of the book in question. The title is "Survivable Networks: > Algorithms for Diverse Routing", Kluwer Academic Publishers (1999). The book > contains detailed algorithsm on calculating disjoint pair of paths, maximally > disjoint paths, if full diversiry does not exit, K (>2) disjoint paths, and > also for calculating disjoint paths in real-life fiber networks involving SRLG's > (or simply span-sharing links). The algorithms are in a form simpler than those > of Suurballe, whose versions are not easy to follow especially for K (>2) > disjoint paths, which was also the experience of Manohar Ellanti (see below). > > The above book can be obtained easily from fatbrain.com or by simply calling the > publisher at (781) 871-6600. > Ramesh, read it a while ago and yes, good book & a nifty, fairly easy to understand algorithm ;-) about the right length for a coast-to-coast plane reading -- tony From owner-mpls@UU.NET Mon Jan 22 14:00:04 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11904 for ; Mon, 22 Jan 2001 14:00:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzcl21562; Mon, 22 Jan 2001 18:58:56 GMT Received: by mail-control.mail.uu.net id QQjzcl15373 for mpls-outgoing; Mon, 22 Jan 2001 18:58:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzcl15332 for ; Mon, 22 Jan 2001 18:58:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzcl03651 for ; Mon, 22 Jan 2001 18:56:18 GMT Received: from thalia.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: thalia.fm.intel.com [132.233.247.11]) id QQjzcl18232 for ; Mon, 22 Jan 2001 18:56:16 GMT Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id SAA20938 for ; Mon, 22 Jan 2001 18:57:38 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 22 Jan 2001 18:56:15 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 10:56:13 -0800 Message-ID: <98B0F9BA93FAD211AC4D00A0C95D19F205C0CFFF@fmsmsx68.fm.intel.com> From: "Singh, Sukhbinder Takhar" To: "'mpls@uu.net'" Subject: Actions to be taken by a frame based LSR in an ATM LSR domain Date: Mon, 22 Jan 2001 10:56:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk What actions does a frame based LSR(Edge ATM-LSR) in an ATM LSR domain take on recving- 1. Unlabeled IP packets(on the ethernet ) required to be sent to another MPLS IP router connected via ATM-LSR Domain(ie the o/p is to be over LC ATM interface) to this Edge ATM-LSR. 2. Labeled packets as cells(with label stack ie labels exist besides the one in VPI/VCI field) over the LCATM interface and on lookup is required to be sent to MPLS domain LSR on ethernet. 3. Labeled IP (as cells over an LC-ATM interface) packets with a single label in VPI/VCI field and on lookup it is required to send the IP pkt to the MPLS domain(frame based) LSR. thanks in advance sukhbinder From owner-mpls@UU.NET Mon Jan 22 15:00:12 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13226 for ; Mon, 22 Jan 2001 15:00:12 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzcp28646; Mon, 22 Jan 2001 19:57:21 GMT Received: by mail-control.mail.uu.net id QQjzcp06029 for mpls-outgoing; Mon, 22 Jan 2001 19:56:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzcp06024 for ; Mon, 22 Jan 2001 19:56:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzcp20510 for ; Mon, 22 Jan 2001 19:55:26 GMT Received: from mail.disney.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.disney.com [204.128.192.15]) id QQjzcp26370 for ; Mon, 22 Jan 2001 19:55:26 GMT Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100]) by mail.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0MJsxp01500 for ; Mon, 22 Jan 2001 11:54:59 -0800 (PST) Received: from 1crp232.corp.disney.com by pain.corp.disney.com with ESMTP; Mon, 22 Jan 2001 11:54:07 -0800 Received: by 1crp232.corp.disney.com with Internet Mail Service (5.5.2651.58) id ; Mon, 22 Jan 2001 11:52:43 -0800 Message-Id: From: "Holmes, David A." To: emildrottar@auranetinc.com, randy@psg.com, peter.lewis@upperside.fr Cc: mpls@UU.NET Subject: RE: First international MPLS exhibition Date: Mon, 22 Jan 2001 11:52:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I don't get the vitriol directed at Mr Lewis. Upon inspection of his web site, Mr Lewis is informing the MPLS-interested community about an event that could have productive value. It is not as if he is selling get-rich-quick schemes. There appears to be a purist viewpoint that the mailing list be used solely for technical exchanges, and not for notification of events of interest. Where else can the MPLS community be notified of events of common interest? David -----Original Message----- From: emildrottar@auranetinc.com [mailto:emildrottar@auranetinc.com] Sent: Monday, January 22, 2001 7:26 AM To: randy@psg.com; peter.lewis@upperside.fr Cc: mpls@UU.NET Subject: RE: First international MPLS exhibition I would like to ask that Mr Lewis either refrain from abusing this reflector, or that he be removed from the subscription list and all his future EMAIL be blocked upon his next offense. Emil -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, January 22, 2001 10:10 AM To: Peter Lewis Cc: mpls@UU.NET Subject: Re: First international MPLS exhibition > http://www.upperside.fr/congress/exhi.htm > First international MPLS exhibition floorplan. Paris. where is the drain for the slime spammers like you? randy From owner-mpls@UU.NET Mon Jan 22 15:40:19 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13933 for ; Mon, 22 Jan 2001 15:40:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzcs23540; Mon, 22 Jan 2001 20:38:25 GMT Received: by mail-control.mail.uu.net id QQjzcs21666 for mpls-outgoing; Mon, 22 Jan 2001 20:37:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzcs21644 for ; Mon, 22 Jan 2001 20:37:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjzcs17950 for ; Mon, 22 Jan 2001 20:36:58 GMT From: James_Huang@Mitel.COM Received: from Mitel.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newgate.mitel.com [198.53.180.100]) id QQjzcs21042 for ; Mon, 22 Jan 2001 20:36:58 GMT Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id PAA06909; Mon, 22 Jan 2001 15:33:56 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 852569DC.0070F61F ; Mon, 22 Jan 2001 15:33:50 -0500 X-Lotus-FromDomain: MITEL To: David Charlap cc: mpls@UU.NET Message-ID: <852569DC.0070F4A7.00@kanmta01.software.mitel.com> Date: Mon, 22 Jan 2001 12:33:33 -0800 Subject: Questions on RSVP-TE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk From: James Huang@MITEL on 01/22/2001 12:33 PM PST David, Thanks for answering my question. I have some more questions about RSVP-TE. (1) Why do we need both a generic RSVP session object and RSVP-TE specific LSP_TUNNEL_IPV4 object? (2) When a edge router of a MPLS domain receives a RSVP PATH message from the non-MPLS domain, what is the correct behavor? (a) Should the edge router convert it into a RSVP-TE PATH message, or (b) should the edge router uses CR-LDP to create a LSP (using the destination IP address in the session object as the FEC) and then label-switched the RSVP PATH message across the MPSL domain (so that resources will not be double-booked in the MPLS domain)? Both of the choices above seems to have scalability problem. Also in (a), how does the edge router know what should be the other end point of the RSVP tunnel? (3) Same question as (2) above for RSVP RESV message. Thanks in advance for your reply. -- James Huang David Charlap on 01/22/2001 07:36:11 AM To: mpls@UU.NET cc: (bcc: James Huang/USA/Mitel) Subject: Re: FEC element for RSVP-TE? James_Huang@Mitel.COM wrote: > > I have one question in mind when reading the RSVP-TE draft. Does > RSVP-TE define some object similar to FEC element in the LDP draft so > that we can set up a LSP for traffics belonging to the FEC? No. RSVP-TE is not a label-distribution protocol. It is a tunnel setup protocol. This is an important semantic difference. > If the RSVP path message does not carry such object and it does not > carry a ER object, then intermediate LSR can only use the destination > IP address in the session object to determine the next hop. Correct. > This means the ingress RSVP initiator need to know exactly who will be > the egress router when it sends out the RSVP path message. This > does not seem to be very pratical to me in the case where RSVP-TE is > used to set up a LSP tunnel for traffics belonging to a FEC to meet > its bandwidth requirements. RSVP-TE is addressing a different problem from LDP. LDP's goal is to get labels on all the switches so that they may be used in lieu of IP best-match algorithms when forwarding traffic. Its goal is not to establish tunnels, although that does happen as a result of label distribution. RSVP-TE's goal is to establish tunnels between endpoints. In order to do so, it must know what those endpoints are. Its goal is not to distribute labels, although that does happen as a part of establishing tunnels. In other words, there are situations where LDP makes more sense than RSVP. One such situation is where you don't know, and can't determine, where your tunnel endpoints will be. There are also situations where RSVP makes more sense than LDP. One such sitation is where shared reservations (for make-before-break rerouting) is required. -- David From owner-mpls@UU.NET Mon Jan 22 16:59:50 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15415 for ; Mon, 22 Jan 2001 16:59:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzcv02770; Mon, 22 Jan 2001 21:21:01 GMT Received: by mail-control.mail.uu.net id QQjzcv07258 for mpls-outgoing; Mon, 22 Jan 2001 21:20:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzcv07245 for ; Mon, 22 Jan 2001 21:20:30 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 QQjzcv08265 for ; Mon, 22 Jan 2001 21:18:32 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 QQjzcv00380 for ; Mon, 22 Jan 2001 21:18:32 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA04427 for ; Mon, 22 Jan 2001 16:18:30 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA08555 for ; Mon, 22 Jan 2001 16:18:31 -0500 (EST) Message-ID: <3A6CA3BD.EE9026E3@marconi.com> Date: Mon, 22 Jan 2001 16:18:53 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Questions on RSVP-TE References: <852569DC.0070F4A7.00@kanmta01.software.mitel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit James_Huang@Mitel.COM wrote: > > I have some more questions about RSVP-TE. > (1) Why do we need both a generic RSVP session object and RSVP-TE > specific LSP_TUNNEL_IPV4 object? You never use both at once. The nature of RSVP is that each object class has one or more C-Types, which may be thought of as subclasses. You only use one C-Type or another, not both. You would use an IP4 session object for an RSVP session that does not involve MPLS. You would use an LSP-IP4 session object for an RSVP session that is being used for MPLS tunnel setup. > (2) When a edge router of a MPLS domain receives a RSVP PATH message > from the non-MPLS domain, what is the correct behavor? If an RSVP message arrives from outside the MPLS cloud, then that message obviously is not meant for tunnel setup. It is some application somewhere (possibly far away on the internet somewhere) that wants to reserve resources wherever possible along the route to the destination address. If you are running a network providing transit to that destination, you can either choose to reserve those resources, or you can choose not to reserve them. If the source, destination and MPLS cloud are all part of the same enterprise, you will probably want to make the reservation. If the MPLS cloud is some third party carrier, you will probably not want to make the reservation. I doubt many carriers will want random third parties from the internet creating LSPs in their network cores. If you don't want to reserve resources, you just forward the RSVP messages like any other data packet. The next RSVP router along the path will detect your MPLS cloud as a non-RSVP segment and will act accordingly. If you want to reserve resources, your best bet is probably to create an LSP through the cloud with a QoS level similar to those being requested. How you do that is beyond the scope of this working group, I think. > (a) Should the edge router convert it into a RSVP-TE PATH > message, or I don't think this will work. RSVP-TE doesn't work over non-RSVP links, so you'll have to rewrite the session object's destiation address with the tunnel egress address. And when the message gets there, there won't be any way to get back the original message, to forward on to the original destination. > (b) should the edge router uses CR-LDP to create a LSP (using the > destination IP address in the session object as the FEC) and > then label-switched the RSVP PATH message across the MPSL > domain (so that resources will not be double-booked in the > MPLS domain)? This is one way. You can even choose to use RSVP-TE to set up the LSP if you like. Once the LSP is established, the data packets (even ones containing RSVP control traffic) will be labeled and blindly forwarded through the LSP to the other side of the MPLS cloud. > Both of the choices above seems to have scalability problem. Another reason why carriers will probably do nothing and forward the RSVP message like an ordinary data packet. -- David From owner-mpls@UU.NET Mon Jan 22 23:32:03 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22522 for ; Mon, 22 Jan 2001 23:32:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzdy02957; Tue, 23 Jan 2001 04:31:25 GMT Received: by mail-control.mail.uu.net id QQjzdy15553 for mpls-outgoing; Tue, 23 Jan 2001 04:30:56 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzdy15529 for ; Tue, 23 Jan 2001 04:30:53 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 QQjzdy08046 for ; Tue, 23 Jan 2001 04:30:28 GMT Received: from bbvproxy.satyam.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [208.220.247.7]) id QQjzdy01937 for ; Tue, 23 Jan 2001 04:30:25 GMT Received: from 208.220.247.3 by bbvproxy.satyam.com (InterScan E-Mail VirusWall NT) Received: by BBVNT001 with Internet Mail Service (5.5.2650.21) id ; Tue, 23 Jan 2001 09:53:00 +0530 Message-ID: From: Ravindra_Joshi To: neil.2.harrison@bt.com, Eugene Plaoude Cc: rstreijl@telcordia.com, mpls@UU.NET Subject: RE: MPLS OAM? Date: Tue, 23 Jan 2001 09:52:59 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C084F4.2B357610" 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_01C084F4.2B357610 Content-Type: text/plain Hi, New to this list.... Yes, I am also interested in OAM functionality for MPLS but I could find only one draft as below, which has expired in April 2000. "Requirements for OAM Functionality in MPLS", T. Theimer, J. Klink, Oct 1999 < draft-theimer-mpls-oam-requ-00.txt> Pls include my name in update list Regards, RB > ---------- > From: Eugene Plaoude[SMTP:plaoude@nortelnetworks.com] > Sent: Monday, January 22, 2001 10:17 PM > To: neil.2.harrison@bt.com > Cc: rstreijl@telcordia.com; mpls@UU.NET > Subject: Re: MPLS OAM? > > Could you please share that with me as well ? > > Thanks in advance, > Eugene. > > neil.2.harrison@bt.com wrote: > > > Robert Strenijl asked: > > Quick question: Is there any work going on in OAM functionality for > MPLS? > > If so, can anybody tell me where? If not, why not? > > > > NH=> Yes there is. I and a couple of other peopl (eg Shahram Davari and > Ben > > Mack-Crane) are looking into this. I'll send you a separate/direct mail > > with some attachments on where things stand. > ------_=_NextPart_001_01C084F4.2B357610 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: MPLS OAM?

Hi,

New to this = list....
Yes, I am also = interested in OAM functionality for MPLS but I could find only one = draft as below, which has expired in April 2000.

"Requirements for OAM = Functionality in MPLS", = T. Theimer, J. Klink, Oct 1999
< = draft-theimer-mpls-oam-requ-00.txt>

Pls include my name = in update list

Regards,
RB

    ----------
    From:   = Eugene = Plaoude[SMTP:plaoude@nortelnetworks.com]
    Sent:   = Monday, January 22, 2001 10:17 = PM
    To: =     neil.2.harrison@bt.com
    Cc: =     rstreijl@telcordia.com; mpls@UU.NET
    Subject: =        Re: MPLS OAM?

    Could you please share that with me as = well ?

    Thanks in advance,
    Eugene.

    neil.2.harrison@bt.com wrote:

    > Robert Strenijl asked:
    > Quick question: Is there any = work going on in OAM functionality for MPLS?
    > If so, can anybody tell me = where? If not, why not?
    >
    > NH=3D> Yes there is.  I = and a couple of other peopl (eg Shahram Davari and Ben
    > Mack-Crane) are looking into = this.  I'll send you a separate/direct mail
    > with some attachments on where = things stand.

------_=_NextPart_001_01C084F4.2B357610-- From owner-mpls@UU.NET Tue Jan 23 03:13:44 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06981 for ; Tue, 23 Jan 2001 03:13:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzem06205; Tue, 23 Jan 2001 08:12:54 GMT Received: by mail-control.mail.uu.net id QQjzem25635 for mpls-outgoing; Tue, 23 Jan 2001 08:12:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzem25628 for ; Tue, 23 Jan 2001 08:12:22 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 QQjzem26774 for ; Tue, 23 Jan 2001 08:12:15 GMT Received: from net.infocom.uniroma1.it by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: net.infocom.uniroma1.it [151.100.37.12]) id QQjzem06882 for ; Tue, 23 Jan 2001 08:12:14 GMT Received: from infocom.uniroma1.it ([151.100.37.50]) by net.infocom.uniroma1.it (8.8.7/8.8.7) with ESMTP id KAA01130; Tue, 23 Jan 2001 10:00:34 +0100 Message-ID: <3A6D3D46.B8B52DED@infocom.uniroma1.it> Date: Tue, 23 Jan 2001 09:13:58 +0100 From: Fabio Ricciato X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: neil.2.harrison@bt.com, mpls@UU.NET Subject: Re: MPLS OAM? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I (silently) follow this mailing list. I'm also intersted in the MPLS OAM and would like to be included in the distribution list about that. Anyway I guess OAM is an interesting topic for most of MPLS-involved people, thus it's fine if discussion and/or reference distribution continue on the mailing list. best regards fabio ricciato From owner-mpls@UU.NET Tue Jan 23 03:33:09 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07497 for ; Tue, 23 Jan 2001 03:33:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzeo03711; Tue, 23 Jan 2001 08:32:24 GMT Received: by mail-control.mail.uu.net id QQjzeo28059 for mpls-outgoing; Tue, 23 Jan 2001 08:32:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzeo28049 for ; Tue, 23 Jan 2001 08:31: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 QQjzeo04151 for ; Tue, 23 Jan 2001 08:31:30 GMT From: neil.2.harrison@bt.com Received: from gandalf.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gandalf.axion.bt.co.uk [132.146.17.29]) id QQjzeo01545 for ; Tue, 23 Jan 2001 08:31:30 GMT Received: from cclmsent02.lon.bt.com by gandalf (local) with ESMTP; Tue, 23 Jan 2001 08:30:56 +0000 Received: by cclmsent02.lon.bt.com with Internet Mail Service (5.5.2652.35) id ; Tue, 23 Jan 2001 08:32:03 -0000 Message-ID: To: fabio@infocom.uniroma1.it, mpls@UU.NET Subject: RE: MPLS OAM? Date: Tue, 23 Jan 2001 08:32:07 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Fabio....A few people have asked why I have not posted the stuff directly back to the mailing list so I think I had better briefly answer here in case I get any further enquiries: I started this last year based on the experiences (bad ones) with OAM for ATM....so, based on that history (ie I.610 reality vs I.356 wish-list), I tried to correct the main flaws and get a *simple* OAM spec that does what we operators want, ie can detect all failures modes and measure availability. Since then Shahram Davari (PMC Sierra), Peter Willis (BT Labs) and Ben MackCrane (Tellabs) have been steadily refining the work with me (other have chipped in from time time to we are the main divers). We were going to submit an ID last year but 2 things happened: 1 The ITU started to work on this area formally....so I had to direct attention to this to make sure they saw our ideas and to try to keep the 2 fora in sync. 2 GMPLS/OTN issues have taken quite a slice of my personal time over the last few months. I presented the basic ideas to the Nov 01 SG13 mtg.....they were all accepted and a draft Rec Y.17oam produced. Since then Shahram/Ben/Peter/I have been working on the outstanding issues. However, since this is ITU focused at present and the work is in MS Word format that is why I did not send this to the list directly...and so I have been responding to requests to see this (quite a lot surprisngly) on a personal basis. I will wait another day or so to see how many other requests come in and then mail shot whoever else asks for it. Once I get ITU sorted I will re-focus on getting suitable ID together and issued. Hope that explains the situation. Regards, Neil > -----Original Message----- > From: Fabio Ricciato [mailto:fabio@infocom.uniroma1.it] > Sent: 23 January 2001 08:14 > To: neil.2.harrison@bt.com; mpls@UU.NET > Subject: Re: MPLS OAM? > > > Hi, > I (silently) follow this mailing list. > I'm also intersted in the MPLS OAM and would like to be > included in the > distribution list about that. > > Anyway I guess OAM is an interesting topic for most of MPLS-involved > people, thus it's fine if discussion and/or reference distribution > continue on the mailing list. > > best regards > > fabio ricciato > From owner-mpls@UU.NET Tue Jan 23 09:07:22 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12130 for ; Tue, 23 Jan 2001 09:07:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzfk05167; Tue, 23 Jan 2001 14:05:32 GMT Received: by mail-control.mail.uu.net id QQjzfk13462 for mpls-outgoing; Tue, 23 Jan 2001 14:05:02 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzfk13437 for ; Tue, 23 Jan 2001 14:04:46 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 QQjzfk17309 for ; Tue, 23 Jan 2001 14:03:33 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f197.law8.hotmail.com [216.33.241.197]) id QQjzfk17446 for ; Tue, 23 Jan 2001 14:03:32 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Jan 2001 06:03:32 -0800 Received: from 203.127.32.40 by lw8fd.law8.hotmail.msn.com with HTTP; Tue, 23 Jan 2001 14:03:31 GMT X-Originating-IP: [203.127.32.40] From: "Ashish Vyas" To: mpls@UU.NET Subject: label encoding in case of MPLS-ATM Date: Tue, 23 Jan 2001 14:03:31 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Jan 2001 14:03:32.0214 (UTC) FILETIME=[44EF3960:01C08545] Sender: owner-mpls@UU.NET Precedence: bulk hi all, I have some doubts regarding label encoding. In case of MPLS-ATM we use VPI/VCI fields to encode labels and in RFC 3031 (MPLS Architecture) there are three different techniques have been specified for label encoding (SVC encoding, SVP Encoding and SVP Multipoint encoding). Since the width of VPI field is 12-bits (max) and width of VCI is only 16-bits then 1. How can a label be encoded using only one field either VPI or VCI? (since the label field is of 20-bits in SHIM header) 2. How can label stack be maintained by using only 12+16=28 bits? 3. How is SVP Multipoint encoding done? and why label merging is possible only if SVP multipoint encoding is used? I might be missing something very basic.. Regards -ashish _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Tue Jan 23 10:52:47 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15749 for ; Tue, 23 Jan 2001 10:52:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzfr15856; Tue, 23 Jan 2001 15:50:56 GMT Received: by mail-control.mail.uu.net id QQjzfr08030 for mpls-outgoing; Tue, 23 Jan 2001 15:50:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzfr08006 for ; Tue, 23 Jan 2001 15:49:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzfr18865 for ; Tue, 23 Jan 2001 15:49:28 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 QQjzfr21392 for ; Tue, 23 Jan 2001 15:49:28 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 KAA25970 for ; Tue, 23 Jan 2001 10:49:25 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14771 for ; Tue, 23 Jan 2001 10:49:26 -0500 (EST) Message-ID: <3A6DA820.DE9019B9@marconi.com> Date: Tue, 23 Jan 2001 10:49:52 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: label encoding in case of MPLS-ATM References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Ashish Vyas wrote: > > I have some doubts regarding label encoding. In case of > MPLS-ATM we use VPI/VCI fields to encode labels > and in RFC 3031 (MPLS Architecture) there are three different > techniques have been specified for label encoding (SVC encoding, > SVP Encoding and SVP Multipoint encoding). > > Since the width of VPI field is 12-bits (max) and width of VCI > is only 16-bits then > > 1. How can a label be encoded using only one field either VPI or > VCI? (since the label field is of 20-bits in SHIM header) The 20-bit limit is only for the generalized label format. That is, when shim headers are used. When labels are encoded in an ATM VCID, any valid combination of VPI/VCI is valid as a label. > 2. How can label stack be maintained by using only 12+16=28 bits? SVP and SVP multipoint encodings use 12-bit labels. Since label space on ATM switches is per-interface, this has no global consequences. > 3. How is SVP Multipoint encoding done? and why label merging is > possible only if SVP multipoint encoding is used? An ATM switch can never map two different inbound VCIDs to a single outbound VCID. If it does, there is the very real possibility that cells from two different packets will get interleaved together. If this happens, then both packets will be corrupted and irrecoverable. One expensive solution to this is to have the switch perform sufficient buffering and keep track of where packets begin and end, in order to prevent cell interleaving. But this is likely to be impossible on legacy ATM hardware. Now, if you're switching based on VPI alone, and there are dont-care bits in the VCI field, you can use those bits to produce a label merging effect. Two inbound LSPs both go out on the same MPLS label (VPI field), but with different values in the unused VCI bits. Since ATM switch hardware will see these as two different VCIDs, cell interleave won't happen. If, however, all the bits in the VCI field are significant, you can't do this - there are simply no bits available for use. -- David From owner-mpls@UU.NET Tue Jan 23 13:10:11 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19837 for ; Tue, 23 Jan 2001 13:10:11 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzga27032; Tue, 23 Jan 2001 18:08:35 GMT Received: by mail-control.mail.uu.net id QQjzga01986 for mpls-outgoing; Tue, 23 Jan 2001 18:08:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzga01941 for ; Tue, 23 Jan 2001 18:07:47 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 QQjzga07364 for ; Tue, 23 Jan 2001 18:07:36 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzga22981 for ; Tue, 23 Jan 2001 18:07:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA10340 for mpls@uu.net; Tue, 23 Jan 2001 13:07:31 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzga29799 for ; Tue, 23 Jan 2001 18:06: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 QQjzga01306 for ; Tue, 23 Jan 2001 18:06:27 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 QQjzga09863 for ; Tue, 23 Jan 2001 18:06:27 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA01656; Tue, 23 Jan 2001 13:06:07 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-223.cisco.com [161.44.134.223]) by bucket.cisco.com (Mirapoint) with ESMTP id ABG04591; Tue, 23 Jan 2001 13:06:23 -0500 (EST) Message-Id: <4.3.2.7.2.20010123130518.0295b9d0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Jan 2001 13:10:38 -0500 To: cheenu Srinivasan , Arun Viswanathan , mpls@UU.NET From: "Thomas D. Nadeau" Subject: MPLS-TE-MIB additions (last call) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, In addition to the 4 agreed upon changes from Joan and Shobhan, the co-authors of the MPLS-TE-MIB have three objects that we would like added/modified in the existing MPLS-TE-MIB and thought that we would post them to the mailing list prior to adding them. I understand that last call was finished last Friday, but I was too busy to send these out, so I apologize. HopTable: Add an object called mplsTunnelHopExcludeAddr whose purpose it is to denote whether or not this hop specifies an 'included' or 'excluded' hop. The default is 'include', so the DEFVAL is false(2). mplsTunnelHopIncludeExclude OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "If this value is set to true(1), then this indicates that this hop MUST be included in the tunnel's path. If this value is set to false(2), then this hop MUST be avoided when calculating the path for this tunnel. The default value of this object is true(1), so that by default all indicated hops are included in the CSPF path computation." ::= { mplsTunnelHopEntry xxx } mplsTunnelPathOptionName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-create STATUS current DESCRIPTION "The description of this series of hops as they relate to the specified path option." ::= { mplsTunnelHopEntry xxx } I think that we incorrectly put this bit in the mplsTunnelSessionAttributes: isComputed This flag indicates whether the tunnel path is computed using a constraint-based routing algorithm based on the mplsTunnelHopTable entries. This bit should go on the HopEntry, and should be removed from the mplsTunnelSessionAttributes. If you leave the bit where it is, it means that *every* path in the hop table for a particular tunnel is either explicitly specified or dynamically computed. This is incorrect as you may want a mixture of the two. I suggest that we add an object to the tunnelHopEntry called tunnelHopEntryPathComputation and make it an enumeration like: INTEGER { dynamic(1), -- CSPF computed explicit(2) } -- strict hop DESCRIPTION "If this value is set to dynamic, then the user should only specify the source and destination of the path and expect that the CSPF will calculate the remainder of the path. If this value is set to explicit, the user should specify the entire path for the tunnel to take. This path may contain strict or loose hops." --Tom From owner-mpls@UU.NET Tue Jan 23 14:12:24 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21804 for ; Tue, 23 Jan 2001 14:12:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzge01760; Tue, 23 Jan 2001 19:11:31 GMT Received: by mail-control.mail.uu.net id QQjzge22827 for mpls-outgoing; Tue, 23 Jan 2001 19:10:51 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzge22791 for ; Tue, 23 Jan 2001 19:10:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzge00479 for ; Tue, 23 Jan 2001 19:09:23 GMT Received: from thalia.fm.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: thalia.fm.intel.com [132.233.247.11]) id QQjzge14979 for ; Tue, 23 Jan 2001 19:09:22 GMT Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id TAA00143 for ; Tue, 23 Jan 2001 19:10:45 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 23 Jan 2001 19:09:21 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 Jan 2001 11:09:20 -0800 Message-ID: <98B0F9BA93FAD211AC4D00A0C95D19F205C0D009@fmsmsx68.fm.intel.com> From: "Singh, Sukhbinder Takhar" To: mpls@UU.NET Subject: TTL field for the labels in a stack other than the TOS Date: Tue, 23 Jan 2001 11:09:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk When a pcket gets labeled first time with a label stack, does the TTL field of the rest of the labels(other than the TOS) in the stack matter and should be set TTL field of the incoming IP packet or only the TTL field in the Label on the TOS should be set as the TTL field in the IP packet.? thanks in advance sukhbinder From owner-mpls@UU.NET Tue Jan 23 15:10:48 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23340 for ; Tue, 23 Jan 2001 15:10:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzgg27913; Tue, 23 Jan 2001 19:41:29 GMT Received: by mail-control.mail.uu.net id QQjzgg26850 for mpls-outgoing; Tue, 23 Jan 2001 19:40:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzgg26842 for ; Tue, 23 Jan 2001 19:40:50 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 QQjzgg00110 for ; Tue, 23 Jan 2001 19:40:04 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzgg25831 for ; Tue, 23 Jan 2001 19:40:03 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA17451 for mpls@uu.net; Tue, 23 Jan 2001 14:40:02 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzgg26751 for ; Tue, 23 Jan 2001 19:39:38 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzgg20749 for ; Tue, 23 Jan 2001 19:37:43 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjzgg22513 for ; Tue, 23 Jan 2001 19:37:42 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id LAA25780; Tue, 23 Jan 2001 11:37:42 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14957.56709.911000.575386@gargle.gargle.HOWL> Date: Tue, 23 Jan 2001 11:37:41 -0800 To: "Singh, Sukhbinder Takhar" Cc: mpls@UU.NET Subject: TTL field for the labels in a stack other than the TOS In-Reply-To: <98B0F9BA93FAD211AC4D00A0C95D19F205C0D009@fmsmsx68.fm.intel.com> References: <98B0F9BA93FAD211AC4D00A0C95D19F205C0D009@fmsmsx68.fm.intel.com> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit This depends on the implementation, here are a few options that we support: 1) Copy the TTL after decrementing it once when you are doing a push onto a packet. This show up as a non-transparent tunnel in a traceroute. 2) Copy a TTL value of "M" (where M is usually 255, but programmable) onto to the topmost label. This shows up as a completely transparent tunnel. In this case, make sure that the packet is decremented once at the ingress of the tunnel and once at the egress of the tunnel. You may want to review Ron Bonica's draft on generic traceroute. Bora >>>>> "Singh," == Singh, Sukhbinder Takhar writes: Singh,> When a pcket gets labeled first time with a label Singh,> stack, does the TTL field of the rest of the Singh,> labels(other than the TOS) in the stack matter and Singh,> should be set TTL field of the incoming IP packet or Singh,> only the TTL field in the Label on the TOS should be Singh,> set as the TTL field in the IP packet.? Singh,> thanks in advance sukhbinder From owner-mpls@UU.NET Tue Jan 23 15:20:07 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23656 for ; Tue, 23 Jan 2001 15:20:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzgj04371; Tue, 23 Jan 2001 20:18:15 GMT Received: by mail-control.mail.uu.net id QQjzgj13309 for mpls-outgoing; Tue, 23 Jan 2001 20:17:47 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzgj13280 for ; Tue, 23 Jan 2001 20:17: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 QQjzgj07831 for ; Tue, 23 Jan 2001 20:17:28 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 QQjzgj10055 for ; Tue, 23 Jan 2001 20:17:28 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 PAA19026 for ; Tue, 23 Jan 2001 15:17:25 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16832 for ; Tue, 23 Jan 2001 15:17:27 -0500 (EST) Message-ID: <3A6DE6F1.3DF2C78A@marconi.com> Date: Tue, 23 Jan 2001 15:17:53 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: label encoding in case of MPLS-ATM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Saurabh Shrivastava wrote: > David Charlap wrote: >>> >>> 3. How is SVP Multipoint encoding done? and why label merging is >>> possible only if SVP multipoint encoding is used? >> >> An ATM switch can never map two different inbound VCIDs to a single >> outbound VCID. If it does, there is the very real possibility that >> cells from two different packets will get interleaved together. If >> this happens, then both packets will be corrupted and irrecoverable. >> >> One expensive solution to this is to have the switch perform >> sufficient buffering and keep track of where packets begin and end, >> in order to prevent cell interleaving. But this is likely to be >> impossible on legacy ATM hardware. >> >> Now, if you're switching based on VPI alone, and there are dont-care >> bits in the VCI field, you can use those bits to produce a label >> merging effect. Two inbound LSPs both go out on the same MPLS label >> (VPI field), but with different values in the unused VCI bits. Since >> ATM switch hardware will see these as two different VCIDs, cell >> interleave won't happen. > > But somebody down the line will have to make packets out of the cells > and does need to do buffering isnt it - please correct me if i am > wrong. But they'll have unique VCIDs. The hardware SAR chips will queue the cells separately, and there will be no interleaving. Even though forwarding decisions are being made with the VPI field, both fields still exist and are used by the SAR chips when reassembling cells into packets. > Also, if say 2 streams are merged based on the VPI field, (and can > be distinguished by their VCI field) - the merged stream will have > cells interleaved - so the LSR which makes packets out of this stream > cant assume that the consecutive cells belong to the same packet. > - in other words cell interleave problem still happens - please > correct me if i am wrong Cells with different VPI/VCI values are never combined when reassembling cells into packets. Remember, on the hardware level there is no difference between an MPLS signalled VC and an ATM-sigalled VC. In this case, the hardware treats labeled packets just like it would treat a bunch of ATM VCs aggregated for VP-switching. They're still separate channels, even though they are all forwarded using the same hardware cross-connect table entry. -- David From owner-mpls@UU.NET Tue Jan 23 17:27:56 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25556 for ; Tue, 23 Jan 2001 17:27:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzgr29337; Tue, 23 Jan 2001 22:27:31 GMT Received: by mail-control.mail.uu.net id QQjzgr22590 for mpls-outgoing; Tue, 23 Jan 2001 22:27:10 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzgr22583 for ; Tue, 23 Jan 2001 22:27:05 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 QQjzgr04312 for ; Tue, 23 Jan 2001 22:27:02 GMT Received: from longwood.cs.ucf.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: longwood.cs.ucf.edu [132.170.108.1]) id QQjzgr26566 for ; Tue, 23 Jan 2001 22:27:02 GMT Received: from iris.cs.ucf.edu (iris [132.170.108.55]) by longwood.cs.ucf.edu (8.11.1/8.11.1) with ESMTP id f0NMR1w06224 for ; Tue, 23 Jan 2001 17:27:01 -0500 (EST) From: Arturo Nunez Received: (from artnpp@localhost) by iris.cs.ucf.edu (8.9.3/8.9.0) id RAA04208 for mpls@uu.net; Tue, 23 Jan 2001 17:25:19 -0500 (EST) Message-Id: <200101232225.RAA04208@iris.cs.ucf.edu> Subject: QoS and Labels: A question ?? To: mpls@UU.NET Date: Tue, 23 Jan 2001 17:25:19 -0500 (EST) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi: I have a doubt about the relation between Labels and the QoS ?? For example in the follow network: PC ==== Ingress LSR ---- Core Network[LSR] ------ Egress LSR === Server + I have a 2 services that are running in the Server, with QoS different. + Now if I connect from the PC,notice its one, to the Server for the 2 services. Will I have 2 LSP ?? Hows is connected the QoS with the labels ? Regards Arturo Nunez From owner-mpls@UU.NET Tue Jan 23 17:46:17 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25779 for ; Tue, 23 Jan 2001 17:46:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzgt09279; Tue, 23 Jan 2001 22:45:27 GMT Received: by mail-control.mail.uu.net id QQjzgt24781 for mpls-outgoing; Tue, 23 Jan 2001 22:45:09 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzgt24776 for ; Tue, 23 Jan 2001 22:45: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 QQjzgs13185 for ; Tue, 23 Jan 2001 22:43:45 GMT Received: from abel.senecanetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: abel.senecanetworks.com [63.97.216.18]) id QQjzgs14572 for ; Tue, 23 Jan 2001 22:43:45 GMT Received: from vsharmapc ([10.0.1.69]) by abel.senecanetworks.com (8.9.3/8.99.99) with SMTP id MAA26495; Tue, 23 Jan 2001 12:47:31 -0600 From: "Vipul Sharma" To: "'Arturo Nunez'" , Subject: RE: QoS and Labels: A question ?? Date: Tue, 23 Jan 2001 17:43:37 -0500 Message-ID: <001c01c0858d$ed3684f0$4501000a@vsharmapc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <200101232225.RAA04208@iris.cs.ucf.edu> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Arturo, This has to do with Forward Equivalency Class (FEC). Since the 2 services in ur PC have different QoS req. you will like them to be handled diff. in the Core network (perhaps to reflect their QoS). So you may have two LSP, one for each service. Each LSP corresponds to a FEC. There is EXP bits in the MPLS Label that is there to convey the QoS info. Hope this helps and experts in this subj. pls. feel free to correct me if I am wrong. Thanx. Vip -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Arturo Nunez Sent: Tuesday, January 23, 2001 5:25 PM To: mpls@UU.NET Subject: QoS and Labels: A question ?? Hi: I have a doubt about the relation between Labels and the QoS ?? For example in the follow network: PC ==== Ingress LSR ---- Core Network[LSR] ------ Egress LSR === Server + I have a 2 services that are running in the Server, with QoS different. + Now if I connect from the PC,notice its one, to the Server for the 2 services. Will I have 2 LSP ?? Hows is connected the QoS with the labels ? Regards Arturo Nunez From owner-mpls@UU.NET Tue Jan 23 17:55:22 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25881 for ; Tue, 23 Jan 2001 17:55:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzgt07497; Tue, 23 Jan 2001 22:54:55 GMT Received: by mail-control.mail.uu.net id QQjzgt25559 for mpls-outgoing; Tue, 23 Jan 2001 22:54:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzgt25552 for ; Tue, 23 Jan 2001 22:54:21 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 QQjzgt29731 for ; Tue, 23 Jan 2001 22:54:01 GMT Received: from abel.senecanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: abel.senecanetworks.com [63.97.216.18]) id QQjzgt21299 for ; Tue, 23 Jan 2001 22:54:01 GMT Received: from vsharmapc ([10.0.1.69]) by abel.senecanetworks.com (8.9.3/8.99.99) with SMTP id MAA26628; Tue, 23 Jan 2001 12:57:47 -0600 From: "Vipul Sharma" To: "'Vipul Sharma'" , "'Arturo Nunez'" , Subject: RE: QoS and Labels: A question ?? Date: Tue, 23 Jan 2001 17:53:53 -0500 Message-ID: <001d01c0858f$5c76f010$4501000a@vsharmapc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit OOps I meant 2 services in ur server (NOT PC). Also, a couple of points, to have two LSPs you have to be able to recognize and classify traffic to each service in the server seperately at the ingress LSR (which may involve L3 or above). Thanx. Vip -----Original Message----- From: Vipul Sharma [mailto:vsharma@senecanetworks.com] Sent: Tuesday, January 23, 2001 5:44 PM To: 'Arturo Nunez'; 'mpls@UU.NET' Subject: RE: QoS and Labels: A question ?? Arturo, This has to do with Forward Equivalency Class (FEC). Since the 2 services in ur PC have different QoS req. you will like them to be handled diff. in the Core network (perhaps to reflect their QoS). So you may have two LSP, one for each service. Each LSP corresponds to a FEC. There is EXP bits in the MPLS Label that is there to convey the QoS info. Hope this helps and experts in this subj. pls. feel free to correct me if I am wrong. Thanx. Vip -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Arturo Nunez Sent: Tuesday, January 23, 2001 5:25 PM To: mpls@UU.NET Subject: QoS and Labels: A question ?? Hi: I have a doubt about the relation between Labels and the QoS ?? For example in the follow network: PC ==== Ingress LSR ---- Core Network[LSR] ------ Egress LSR === Server + I have a 2 services that are running in the Server, with QoS different. + Now if I connect from the PC,notice its one, to the Server for the 2 services. Will I have 2 LSP ?? Hows is connected the QoS with the labels ? Regards Arturo Nunez From owner-mpls@UU.NET Tue Jan 23 18:04:18 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26074 for ; Tue, 23 Jan 2001 18:04:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzgu05439; Tue, 23 Jan 2001 23:02:22 GMT Received: by mail-control.mail.uu.net id QQjzgu00335 for mpls-outgoing; Tue, 23 Jan 2001 23:01:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzgu00127 for ; Tue, 23 Jan 2001 23:01:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzgu28529 for ; Tue, 23 Jan 2001 23:00:34 GMT Received: from galileo.luminousnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.luminousnetworks.com [63.204.7.10]) id QQjzgu00540 for ; Tue, 23 Jan 2001 23:00:33 GMT Received: by galileo.luminousnetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jan 2001 15:00:28 -0800 Message-ID: <090825D1E60BD311B8390090276D5C49D2B5EE@galileo.luminousnetworks.com> From: Raghu Thirumalairajan To: "'David Charlap'" , mpls@UU.NET Subject: RE: Question about Labels Date: Tue, 23 Jan 2001 15:00:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08590.47503EC0" 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_01C08590.47503EC0 Content-Type: text/plain; charset="iso-8859-1" I am a bit confused; going through rfc3031 [MPLS-ARCH]: "If a particular LSR Rd is attached to a particular LSR Ru over two point-to-point interfaces, then Rd may distribute to Ru a binding of label L to FEC F1, as well as a binding of label L to FEC F2, F1 != F2, if and only if each binding is valid only for packets which Ru sends to Rd over a particular one of the interfaces. In all other cases, Rd MUST NOT distribute to Ru bindings of the same label value to two different FECs." Consider the following figure: +----+ +----+ ---| R1 |---------| R2 |--- +----+ +----+ R1 is connected to R2 over a single multi-access interface (like 100 Mbps ethernet). Can R2 distribute L to two FEC requests for F1 & F2 (F1 != F2) from R1? Essentially, can more than one FEC point to an NHLFE if R1 & R2 are connected over a single non-point-to-point interface? The statement "In all othercases, Rd MUST NOT distribute to Ru bindings of the same label value to two different FECs." seems confusing/contradicting to what's stated below... Thanks in advance Rgds -Raghu -----Original Message----- From: David Charlap [mailto:david.charlap@marconi.com] Sent: Monday, January 22, 2001 8:31 AM To: mpls@UU.NET Subject: Re: Question about Labels > Note that per FEC does not necessarily mean per IP prefix. Multiple > prefixes that all leave the MPLS cloud through a common router interface > and have identical traffic characteristics can be considered a single > FEC and can use a single LSP. ------_=_NextPart_001_01C08590.47503EC0 Content-Type: text/html; charset="iso-8859-1" RE: Question about Labels

I am a bit confused; going through rfc3031 [MPLS-ARCH]:

   "If a particular LSR Rd is attached to a particular LSR Ru over two
   point-to-point interfaces, then Rd may distribute to Ru a binding of
   label L to FEC F1, as well as a binding of label L to FEC F2, F1 !=
   F2, if and only if each binding is valid only for packets which Ru
   sends to Rd over a particular one of the interfaces.  In all other
   cases, Rd MUST NOT distribute to Ru bindings of the same label value
   to two different FECs."

Consider the following figure:
      +----+         +----+
   ---| R1 |---------| R2 |---
      +----+         +----+

R1 is connected to R2 over a single multi-access interface (like 100 Mbps ethernet).
Can R2 distribute L to two FEC requests for F1 & F2 (F1 != F2) from R1? Essentially,
can more than one FEC point to an NHLFE if R1 & R2 are connected over a single
non-point-to-point interface? The statement "In all othercases, Rd MUST NOT distribute
to Ru bindings of the same label value to two different FECs." seems
confusing/contradicting to what's stated below...

Thanks in advance
Rgds
-Raghu

-----Original Message-----
From: David Charlap [mailto:david.charlap@marconi.com]
Sent: Monday, January 22, 2001 8:31 AM
To: mpls@UU.NET
Subject: Re: Question about Labels

> Note that per FEC does not necessarily mean per IP prefix.  Multiple
> prefixes that all leave the MPLS cloud through a common router interface
> and have identical traffic characteristics can be considered a single
> FEC and can use a single LSP.

------_=_NextPart_001_01C08590.47503EC0-- From owner-mpls@UU.NET Tue Jan 23 18:14:09 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26184 for ; Tue, 23 Jan 2001 18:14:09 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzgu17209; Tue, 23 Jan 2001 23:13:25 GMT Received: by mail-control.mail.uu.net id QQjzgu09290 for mpls-outgoing; Tue, 23 Jan 2001 23:12:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzgu09275 for ; Tue, 23 Jan 2001 23:12: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 QQjzgu11323 for ; Tue, 23 Jan 2001 23:12:15 GMT Received: from celox-stl-ems1.celoxnetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: celox-stl-imap1.celoxnetworks.com [12.104.200.29]) id QQjzgu15813 for ; Tue, 23 Jan 2001 23:12:15 GMT Received: by celox-stl-ems1.celoxnetworks.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 Jan 2001 16:54:50 -0600 Message-ID: <17A066EECCAF2F469CA1EE773BBF25A533C95C@celox-stl-ems1.celoxnetworks.com> From: "Zhao, Xingguo" To: "'Vipul Sharma'" , "'Arturo Nunez'" , mpls@UU.NET Subject: RE: QoS and Labels: A question ?? Date: Tue, 23 Jan 2001 16:54:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk -----Original Message----- From: Vipul Sharma [mailto:vsharma@senecanetworks.com] Sent: Tuesday, January 23, 2001 4:44 PM To: 'Arturo Nunez'; mpls@UU.NET Subject: RE: QoS and Labels: A question ?? First, I guess you probably won't run MPLS from your PC to Ingress LSP. Maybe it is just access protocol such as PPPoA. But you surely may have some SLA with the Ingress LSR, so he can classify/police your packet based on the contract. Second, For scalability, I guess the MPLS network will implement MPLS Diff Serv which supports both E-LSP and L-LSP. Your packet will either go through an E-LSP or L-LSP based on the CoS of your packet. The E-LSP or L-LSP will then satisfy the QoS requirement of your packet without a hard guarantee due to the nature of DiffServ. Xingguo Arturo, This has to do with Forward Equivalency Class (FEC). Since the 2 services in ur PC have different QoS req. you will like them to be handled diff. in the Core network (perhaps to reflect their QoS). So you may have two LSP, one for each service. Each LSP corresponds to a FEC. There is EXP bits in the MPLS Label that is there to convey the QoS info. Hope this helps and experts in this subj. pls. feel free to correct me if I am wrong. Thanx. Vip -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Arturo Nunez Sent: Tuesday, January 23, 2001 5:25 PM To: mpls@UU.NET Subject: QoS and Labels: A question ?? Hi: I have a doubt about the relation between Labels and the QoS ?? For example in the follow network: PC ==== Ingress LSR ---- Core Network[LSR] ------ Egress LSR === Server + I have a 2 services that are running in the Server, with QoS different. + Now if I connect from the PC,notice its one, to the Server for the 2 services. Will I have 2 LSP ?? Hows is connected the QoS with the labels ? Regards Arturo Nunez From owner-mpls@UU.NET Tue Jan 23 19:13:17 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26862 for ; Tue, 23 Jan 2001 19:13:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzgy26046; Wed, 24 Jan 2001 00:12:50 GMT Received: by mail-control.mail.uu.net id QQjzgy28194 for mpls-outgoing; Wed, 24 Jan 2001 00:11:57 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzgy28131 for ; Wed, 24 Jan 2001 00:11: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 QQjzgy16983 for ; Wed, 24 Jan 2001 00:09:32 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQjzgy15905 for ; Wed, 24 Jan 2001 00:09:32 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA05653 for ; Tue, 23 Jan 2001 19:09:29 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA08304 for ; Tue, 23 Jan 2001 19:09:31 -0500 (EST) Message-ID: <3A6E1D56.88770CF@marconi.com> Date: Tue, 23 Jan 2001 19:09:58 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Question about Labels References: <090825D1E60BD311B8390090276D5C49D2B5EE@galileo.luminousnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Raghu Thirumalairajan wrote: > > I am a bit confused; going through rfc3031 [MPLS-ARCH]: > > "If a particular LSR Rd is attached to a particular LSR Ru over two > point-to-point interfaces, then Rd may distribute to Ru a binding > of label L to FEC F1, as well as a binding of label L to FEC F2, F1 > != F2, if and only if each binding is valid only for packets which > Ru sends to Rd over a particular one of the interfaces. In all > other cases, Rd MUST NOT distribute to Ru bindings of the same > label value to two different FECs." > > Consider the following figure: > +----+ +----+ > ---| R1 |---------| R2 |--- > +----+ +----+ > > R1 is connected to R2 over a single multi-access interface (like 100 > Mbps ethernet). > Can R2 distribute L to two FEC requests for F1 & F2 (F1 != F2) from > R1? Essentially, can more than one FEC point to an NHLFE if R1 & R2 > are connected over a single non-point-to-point interface? No. If two different FECs are given the same label, then they will be forwarded identically - which is the wrong behavior if they really are two different FECs. > The statement "In all othercases, Rd MUST NOT distribute to Ru > bindings of the same label value to two different FECs." seems > confusing/contradicting to what's stated below... Below what? Do you mean my message that you quoted? >> Note that per FEC does not necessarily mean per IP prefix. Multiple >> prefixes that all leave the MPLS cloud through a common router >> interface and have identical traffic characteristics can be >> considered a single FEC and can use a single LSP. An IP prefix is not an FEC. And an FEC is not an IP prefix. An FEC is a collection of (one or more) host addresses and prefixes that are all forwarded identically. If multiple prefixes are all to be forwarded identically (same egress router, same service level), then a router can place them all in the same FEC. Or it can choose not to. A single label can not be assigned to two FECs, but there is nothing stopping a router from placing multiple IP prefixes into a single FEC, if they all leave the MPLS cloud via the same router and are to be delivered with the same service level. Please see the discussion on aggregation granularity (section 3.20 of RFC 3031) -- David From owner-mpls@UU.NET Tue Jan 23 19:19:30 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26921 for ; Tue, 23 Jan 2001 19:19:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzgz27995; Wed, 24 Jan 2001 00:19:08 GMT Received: by mail-control.mail.uu.net id QQjzgz29313 for mpls-outgoing; Wed, 24 Jan 2001 00:18:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzgz29277 for ; Wed, 24 Jan 2001 00:18:30 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 QQjzgy00717 for ; Wed, 24 Jan 2001 00:14:36 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 QQjzgy21384 for ; Wed, 24 Jan 2001 00:14:36 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 TAA05915 for ; Tue, 23 Jan 2001 19:14:33 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA08872 for ; Tue, 23 Jan 2001 19:14:35 -0500 (EST) Message-ID: <3A6E1E85.C7D0810E@marconi.com> Date: Tue, 23 Jan 2001 19:15:01 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: QoS and Labels: A question ?? References: <001c01c0858d$ed3684f0$4501000a@vsharmapc> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Vipul Sharma wrote: > > This has to do with Forward Equivalency Class (FEC). Since the 2 > services in ur PC have different QoS req. you will like them to be > handled diff. in the Core network (perhaps to reflect their QoS). So > you may have two LSP, one for each service. Each LSP corresponds to a > FEC. Correct. If two packet flows are not supposed to be handled identically, then they do not belong to the same FEC, even if they share the same destination address. > There is EXP bits in the MPLS Label that is there to convey the QoS > info. The EXP bits are for conveying DiffServ priority levels. If you simply want to prioritize best-effort traffic, and your switches can suport E-LSPs, then this is the way to do it. If you need actual QoS guarantees, or if your switches only support L-LPSs, or if you want the two service levels to be routed independantly, then you need to create a separate LSP for each service level. CR-LDP or RSVP-TE can be used for signalling the QoS requirements for the two LSPs. -- David From owner-mpls@UU.NET Tue Jan 23 19:36:16 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27036 for ; Tue, 23 Jan 2001 19:36:16 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzha23780; Wed, 24 Jan 2001 00:35:52 GMT Received: by mail-control.mail.uu.net id QQjzha01000 for mpls-outgoing; Wed, 24 Jan 2001 00:35:22 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzha00992 for ; Wed, 24 Jan 2001 00:35: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 QQjzha09227 for ; Wed, 24 Jan 2001 00:35:03 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzha11194 for ; Wed, 24 Jan 2001 00:35:03 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA07041 for mpls@uu.net; Tue, 23 Jan 2001 19:35:02 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzha00926 for ; Wed, 24 Jan 2001 00:34:28 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 QQjzha04625 for ; Wed, 24 Jan 2001 00:33:31 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjzha09890 for ; Wed, 24 Jan 2001 00:33:31 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA22147; Tue, 23 Jan 2001 16:33:30 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14958.8922.346000.907970@gargle.gargle.HOWL> Date: Tue, 23 Jan 2001 16:33:30 -0800 To: David Charlap Cc: mpls@UU.NET Subject: Re: QoS and Labels: A question ?? In-Reply-To: <3A6E1E85.C7D0810E@marconi.com> References: <001c01c0858d$ed3684f0$4501000a@vsharmapc> <3A6E1E85.C7D0810E@marconi.com> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "David" == David Charlap writes: David> If you need actual QoS guarantees, or if your David> switches only support L-LPSs, or if you want the two David> service levels to be routed independantly, then you David> need to create a separate LSP for each service level. David> CR-LDP or RSVP-TE can be used for signalling the QoS David> requirements for the two LSPs. David You are making assumptions about a particular switch architecture when you assert that you can not do "actual" QoS guarantees with E-LSPs. If you have a policer and a shaper/scheduler that can process the EXP bits as well as the label, then doing "actual" QoS is quite possible with E-LSPs. Not only that, but you can map traffic destined to the same prefix to different EXP levels based either on Diffserv bits or on packet content. This also applies to VLAN tags. Bora From owner-mpls@UU.NET Tue Jan 23 19:43:47 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27113 for ; Tue, 23 Jan 2001 19:43:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzha19180; Wed, 24 Jan 2001 00:43:22 GMT Received: by mail-control.mail.uu.net id QQjzha01735 for mpls-outgoing; Wed, 24 Jan 2001 00:42:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzha01729 for ; Wed, 24 Jan 2001 00:42: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 QQjzha22374 for ; Wed, 24 Jan 2001 00:42:38 GMT Received: from lightera2.csd.ciena.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.96.78.12]) id QQjzha02677 for ; Wed, 24 Jan 2001 00:42:38 GMT Received: by lightera2.csd.ciena.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jan 2001 16:43:33 -0800 Message-ID: From: "Sinha, Rakesh" To: Manohar Ellanti Cc: Wushao Wen , mpls@UU.NET Subject: RE: Book on calculating two alternative shortest paths Date: Tue, 23 Jan 2001 16:43:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk A number of approximation algorithms (i.e. efficient algorithms with guaranteed performance bound) for similar problems are described in Chapter six of the book "Approximation algorithms for NP-hard problems", edited by Dorit S. Hochbaum, PWS publishing company. The book describes the problem in terms of k-connectivity which is equivalent (by something called Menger's theorem) to having k disjoint paths. regards, --------------- Rakesh K. Sinha Ciena Core Switching Division 10480 Ridgeview Court, Cupertino, CA 95014 Ph: (408) 366 4950, Fax: (408) 366 4867 email: rsinha@ciena.com > -----Original Message----- > Manohar Ellanti wrote: > > > Wushao Wen, > > > > original work on this problem is done by Sururballe that > provides not only > > 2-shortest paths but also for k-shortest paths in a mesh network. > > > > You can find , specifically for 2-shortest paths, details in here; > > J.W. Suurballe, R.E.Tarjan, "A Quick Method for Finding > Shortest Pairs of > > Disjoint Paths", Networks, Vol. 14, 1984 pp 325-336. > > > > A generalized version of this algorithm for k-shortest > paths can be found > > here though I find it difficult to understand > > J.W.Suurballe, "Disjoint Paths in a Network", Networks, > Vol. 4., 1974, > > pp125-145. > > > > Some other work is also done for k-shortest paths by Ramesh > Bhandari (He has > > published a book and provided reference in a previous mail > on this list), > > Eppstein (UC,Berkely), Prof Grover at University of Alberta > (also TRLabs). > > Marali K and T.V.Laksham work has references to the above > work as well. > > > > Hope this answers your questions. > > > > Manohar > > > > ----- Original Message ----- > > From: "Wushao Wen" > > To: > > Sent: Sunday, January 21, 2001 8:09 PM > > Subject: Book on calculating two alternative shortest paths > > > > > Hi, > > > I remember there is a book or paper on how to > calculate two shortest > > > paths from a source to a destination in a mesh network. > The author also > > > mention it in this mailing list. Can someone please tell > me the book name > > > or the author name? > > > Thank you very much! > > > > > > > > > Wushao Wen > > > > From owner-mpls@UU.NET Tue Jan 23 19:58:41 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27355 for ; Tue, 23 Jan 2001 19:58:40 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzhb21935; Wed, 24 Jan 2001 00:58:18 GMT Received: by mail-control.mail.uu.net id QQjzhb03310 for mpls-outgoing; Wed, 24 Jan 2001 00:57:47 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzhb03292 for ; Wed, 24 Jan 2001 00:57:31 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 QQjzhb15744 for ; Wed, 24 Jan 2001 00:57:08 GMT Received: from exchsrv1.cosinecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cosinecom.com [63.88.104.16]) id QQjzhb02535 for ; Wed, 24 Jan 2001 00:57:07 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Tue, 23 Jan 2001 16:54:50 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A2911D8AB95@exchsrv1.cosinecom.com> From: Jay Wang To: "'David Charlap'" , mpls@UU.NET Subject: RE: QoS and Labels: A question ?? Date: Tue, 23 Jan 2001 16:54:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C085A0.411C2900" 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_01C085A0.411C2900 Content-Type: text/plain; charset="iso-8859-1" > > The EXP bits are for conveying DiffServ priority levels. If > you simply > want to prioritize best-effort traffic, and your switches can suport > E-LSPs, then this is the way to do it. > > If you need actual QoS guarantees, or if your switches only support > L-LPSs, or if you want the two service levels to be routed > independantly, then you need to create a separate LSP for each service > level. No, I don't think this is the intention of draft-ietf-mpls-diff-ext(-07), in which it was clearly stated that: "Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the pre-configured mapping are capable of transporting the same common set of 8, or fewer, BAs. Each of those E-LSPs may actually transport this full set of BAs or any arbitrary subset of it." That is, each E-LSP allows up to 8 combinations of . With other mechanisms (in a Diffserv TCB) this would allow you to tansport flows with different "QoS quarantees" using just one LSP (and fortunately so). - Jay > CR-LDP or RSVP-TE can be used for signalling the QoS > requirements for the two LSPs. > > -- David > ------_=_NextPart_001_01C085A0.411C2900 Content-Type: text/html; charset="iso-8859-1" RE: QoS and Labels: A question ??

>
> The EXP bits are for conveying DiffServ priority levels.  If
> you simply
> want to prioritize best-effort traffic, and your switches can suport
> E-LSPs, then this is the way to do it.
>
> If you need actual QoS guarantees, or if your switches only support
> L-LPSs, or if you want the two service levels to be routed
> independantly, then you need to create a separate LSP for each service
> level. 

No, I don't think this is the intention of draft-ietf-mpls-diff-ext(-07),
in which it was clearly stated that:

   "Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the
   pre-configured mapping are capable of transporting the same common
   set of 8, or fewer, BAs. Each of those E-LSPs may actually transport
   this full set of BAs or any arbitrary subset of it."

That is, each E-LSP allows up to 8 combinations of <PSC, drop-precedence>.
With other mechanisms (in a Diffserv TCB) this would allow you to tansport
flows with different "QoS quarantees" using just one LSP (and fortunately so).

- Jay


> CR-LDP or RSVP-TE can be used for signalling the QoS
> requirements for the two LSPs.
>
> -- David
>

------_=_NextPart_001_01C085A0.411C2900-- From owner-mpls@UU.NET Tue Jan 23 21:54:37 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29481 for ; Tue, 23 Jan 2001 21:54:36 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzhj29886; Wed, 24 Jan 2001 02:54:05 GMT Received: by mail-control.mail.uu.net id QQjzhj09477 for mpls-outgoing; Wed, 24 Jan 2001 02:53:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzhj09465 for ; Wed, 24 Jan 2001 02:53: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 QQjzhj03611 for ; Wed, 24 Jan 2001 02:53:18 GMT From: James_Huang@Mitel.COM Received: from Mitel.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newgate.mitel.com [198.53.180.100]) id QQjzhj19587 for ; Wed, 24 Jan 2001 02:53:17 GMT Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id VAA10619 for ; Tue, 23 Jan 2001 21:53:08 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 852569DE.000FD605 ; Tue, 23 Jan 2001 21:52:58 -0500 X-Lotus-FromDomain: MITEL To: mpls@UU.NET Message-ID: <852569DE.000FD5ED.00@kanmta01.software.mitel.com> Date: Tue, 23 Jan 2001 18:52:58 -0800 Subject: PHP negotiation Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi all, The following paragraph is from Section 3.16. (Penultimate Hop Popping) of RFC3031. "Initial label distribution protocol negotiations MUST allow each LSR to determine whether its neighboring LSRS are capable of popping the label stack. A LSR MUST NOT request a label distribution peer to pop the label stack unless it is capable of doing so." However, I can not find any mechanism in LDP/CR-LDP or RSVP-TE to accomplish this PHP negotiation. Am I missing something here? -- James Huang From owner-mpls@UU.NET Tue Jan 23 23:26:59 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01447 for ; Tue, 23 Jan 2001 23:26:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzhp08337; Wed, 24 Jan 2001 04:26:16 GMT Received: by mail-control.mail.uu.net id QQjzhp12852 for mpls-outgoing; Wed, 24 Jan 2001 04:25:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzhp12844 for ; Wed, 24 Jan 2001 04:25:48 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 QQjzhp12791 for ; Wed, 24 Jan 2001 04:25:34 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzhp07048 for ; Wed, 24 Jan 2001 04:25:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id XAA17244 for mpls@uu.net; Tue, 23 Jan 2001 23:25:28 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzhp12782 for ; Wed, 24 Jan 2001 04:25:05 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 QQjzhp11002 for ; Wed, 24 Jan 2001 04:24:58 GMT Received: from yarilo.pluris.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjzhp06213 for ; Wed, 24 Jan 2001 04:24:57 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA10294; Tue, 23 Jan 2001 20:24:57 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14958.22797.667000.382321@gargle.gargle.HOWL> Date: Tue, 23 Jan 2001 20:24:45 -0800 To: James_Huang@Mitel.COM Cc: mpls@UU.NET Subject: PHP negotiation In-Reply-To: <852569DE.000FD5ED.00@kanmta01.software.mitel.com> References: <852569DE.000FD5ED.00@kanmta01.software.mitel.com> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit You should also read the label encapsulation RFC. What happens is that the egress LSR assigns an (...) NULL label (I think it should be Implicit Null) to the penultimate hop, if penultimate hop does not support this, then LSP setup should fail. There was a LOOONG discussion on this sometime last year. Some people think this stuff is really clear. I think that it is in about three different RFCs, and someone needs to write a BCP that explains common usage and tricks that network operators that use MPLS should use. BTW, this question comes up about once a month on the list, maybe we should have an MPLS FAQ. Bora >>>>> "James" == James Huang writes: James> Hi all, The following paragraph is from Section James> 3.16. (Penultimate Hop Popping) of RFC3031. James> "Initial label distribution protocol negotiations James> MUST allow each LSR to determine whether its James> neighboring LSRS are capable of popping the label James> stack. A LSR MUST NOT request a label distribution James> peer to pop the label stack unless it is capable of James> doing so." James> However, I can not find any mechanism in James> LDP/CR-LDP or RSVP-TE to accomplish this PHP James> negotiation. James> Am I missing something here? James> -- James Huang From owner-mpls@UU.NET Tue Jan 23 23:32:51 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01913 for ; Tue, 23 Jan 2001 23:32:50 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzhq02521; Wed, 24 Jan 2001 04:32:05 GMT Received: by mail-control.mail.uu.net id QQjzhq13681 for mpls-outgoing; Wed, 24 Jan 2001 04:31:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzhq13676 for ; Wed, 24 Jan 2001 04:31:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjzhq27187 for ; Wed, 24 Jan 2001 04:31:37 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzhq17172 for ; Wed, 24 Jan 2001 04:31:37 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id XAA17802 for mpls@uu.net; Tue, 23 Jan 2001 23:31:36 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzhq13605 for ; Wed, 24 Jan 2001 04:31: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 QQjzhq27149 for ; Wed, 24 Jan 2001 04:30:33 GMT Received: from yarilo.pluris.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjzhq15555 for ; Wed, 24 Jan 2001 04:30:32 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id UAA10632; Tue, 23 Jan 2001 20:30:31 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14958.23132.499000.343630@gargle.gargle.HOWL> Date: Tue, 23 Jan 2001 20:30:20 -0800 To: Bora Akyol Cc: curtis@avici.com, tli@procket.com, henk@procket.com, isis-wg@juniper.net, mpls@UU.NET Subject: [Isis-wg] [2] unnumberred interfaces in draft-ietf-isis-traffic-02 In-Reply-To: <14958.22077.592000.706649@gargle.gargle.HOWL> References: <200101240220.VAA18338@workhorse.fictitious.org> <14958.22077.592000.706649@gargle.gargle.HOWL> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Let me clarify myself, ifindex was "agreed" (AFAIR) to be 32 bits long to better accommodate SNMP. Our internal implementation uses 32 bits for ifindex for precisely this reason. If we have a 24 bit ifindex for MPLS, this would be yet another table/hash/hack to map between 32 bits and 24 bits. (Yes, I know there are efficient hacks that can be done, but there is some interesting properties that are associated with ifindices in SNMP like they should not repeat, strict rules for deleting them which make this somewhat more undesirable IMHO) Of course if we increase the index to 32 bits then we need to have another word to play with since we will at least need one flag to distinguish between IP addresses and ifindices. Bora >>>>> "Bora" == Bora Akyol writes: Bora> Curtis I was under the impression that ifindex was Bora> agreed to be 32 bits long based on the discussion Bora> about 2-3 months ago on the MPLS mailing list. Is Bora> there going to be an ID that clarifies this in a Bora> consistent manner for all of us? Bora> Bora >>>>> "Curtis" == Curtis Villamizar writes: Curtis> Tony, Henk, Curtis> Please change the following: Curtis> If the interface being advertised for Traffic Curtis> Engineering purposes is unnumbered, the first two Curtis> octets of the IPv4 neighbor address sub-TLV are set Curtis> to zero and the next two octets are set to the Curtis> interface ID of the unnumbered interface. In Curtis> combination with the IPv4 interface address sub-TLV Curtis> this identifies the unnumbered link over which the Curtis> advertised adjacency has been established. Curtis> Please specify that the first octet to be set to Curtis> zero and the remaining three octets contain the Curtis> ifindex. This will be consistent with the Curtis> specification and the practice in OSPF (yes, I know Curtis> its an ISIS doc) and it will also be much more Curtis> convenient for big routers with lots of interfaces Curtis> that number their pseudo-interfaces with three Curtis> significant octets of numbering (like ours). Curtis> Curtis Curtis> _______________________________________________ Curtis> Isis-wg mailing list - Isis-wg@external.juniper.net Curtis> http://external.juniper.net/mailman/listinfo/isis-wg Bora> _______________________________________________ Bora> Isis-wg mailing list - Isis-wg@external.juniper.net Bora> http://external.juniper.net/mailman/listinfo/isis-wg From owner-mpls@UU.NET Wed Jan 24 00:23:31 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02564 for ; Wed, 24 Jan 2001 00:23:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzht26739; Wed, 24 Jan 2001 05:23:09 GMT Received: by mail-control.mail.uu.net id QQjzht00652 for mpls-outgoing; Wed, 24 Jan 2001 05:22:50 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzht00643 for ; Wed, 24 Jan 2001 05:22:44 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 QQjzht27900 for ; Wed, 24 Jan 2001 05:21:20 GMT Received: from samar.sasi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQjzht29815 for ; Wed, 24 Jan 2001 05:21:17 GMT Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id KAA28044; Wed, 24 Jan 2001 10:51:04 +0530 (IST) Received: from suns3.sasi.com ([10.0.36.3]) by samar.sasi.com; Wed, 24 Jan 2001 10:51:03 +0000 (IST) Received: from localhost (soumen@localhost) by suns3.sasi.com (8.9.3/8.9.3) with ESMTP id KAA18815; Wed, 24 Jan 2001 10:51:03 +0530 (IST) Date: Wed, 24 Jan 2001 10:51:03 +0530 (IST) From: Soumen Sarkar To: "Thomas D. Nadeau" cc: cheenu Srinivasan , Arun Viswanathan , Subject: Re: MPLS-TE-MIB additions (last call) In-Reply-To: <4.3.2.7.2.20010123130518.0295b9d0@bucket.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Tue, 23 Jan 2001, Thomas D. Nadeau wrote: > > > Hi, > > In addition to the 4 agreed upon changes from Joan > and Shobhan, the co-authors of the MPLS-TE-MIB have three > objects that we would like added/modified in the existing > MPLS-TE-MIB and thought that we would post them to > the mailing list prior to adding them. I understand > that last call was finished last Friday, but I > was too busy to send these out, so I apologize. > > HopTable: > > Add an object called mplsTunnelHopExcludeAddr whose > purpose it is to denote whether or not this hop specifies > an 'included' or 'excluded' hop. The default is 'include', > so the DEFVAL is false(2). > > mplsTunnelHopIncludeExclude OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "If this value is set to true(1), then this indicates that this > hop MUST be included in the tunnel's path. If this value is set to > false(2), then this hop MUST be avoided when calculating the path for this > tunnel. The default value of this object is true(1), so that by default all > indicated hops are included in the CSPF path computation." > ::= { mplsTunnelHopEntry xxx } > > Tom, I think the name mplsTunnelHopIncludeExclude is creating confusion since its type is TruthValue. Since the default value would be true(1), I suggest the name to be : mplsTunnelHopInclude It will be aligned with its semantic. -regards, Soumen From owner-mpls@UU.NET Wed Jan 24 00:48:22 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02930 for ; Wed, 24 Jan 2001 00:48:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzhv24298; Wed, 24 Jan 2001 05:47:54 GMT Received: by mail-control.mail.uu.net id QQjzhv03362 for mpls-outgoing; Wed, 24 Jan 2001 05:47:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzhv03348 for ; Wed, 24 Jan 2001 05:47:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjzhv08350 for ; Wed, 24 Jan 2001 05:45:29 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzhv21781 for ; Wed, 24 Jan 2001 05:45:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id AAA21981 for mpls@uu.net; Wed, 24 Jan 2001 00:45:28 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzhv02936 for ; Wed, 24 Jan 2001 05:45:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjzhu18446 for ; Wed, 24 Jan 2001 05:44:02 GMT Received: from boyle.eng.level3.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu162-224-220.nc.rr.com [24.162.224.220]) id QQjzhu02180 for ; Wed, 24 Jan 2001 05:44:02 GMT Received: from localhost (jboyle@localhost) by boyle.eng.level3.com (8.9.3/8.8.7) with ESMTP id WAA09529; Tue, 23 Jan 2001 22:55:15 -0700 Date: Tue, 23 Jan 2001 22:54:00 -0700 (MST) From: Jim Boyle X-Sender: jboyle@boyle.eng.level3.com To: "Thomas D. Nadeau" cc: cheenu Srinivasan , Arun Viswanathan , mpls@UU.NET Subject: Re: MPLS-TE-MIB additions (last call) In-Reply-To: <4.3.2.7.2.20010123130518.0295b9d0@bucket.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Tue, 23 Jan 2001, Thomas D. Nadeau wrote: > > Hi, > > In addition to the 4 agreed upon changes from Joan > and Shobhan, the co-authors of the MPLS-TE-MIB have three I counted 3 folks that agreed and 0 that objected, not a preponderance of support, but I suppose it'll do. I'll just note publically that I feel that inclusion of CR-LDP specific attributes such as the "ancillary" bw characteristics are out of place in your generic mib. Making them "mandatory" (but only when certain combinations of configuration and protocol use are present!) is also objectionable. 3 to 1, hmm.. I suppose you'll keep it in there. All the same, I suppose. Jim From owner-mpls@UU.NET Wed Jan 24 01:54:37 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08963 for ; Wed, 24 Jan 2001 01:54:37 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzhz11381; Wed, 24 Jan 2001 06:54:00 GMT Received: by mail-control.mail.uu.net id QQjzhz21832 for mpls-outgoing; Wed, 24 Jan 2001 06:53:30 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzhz21815 for ; Wed, 24 Jan 2001 06:53:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjzhz00534 for ; Wed, 24 Jan 2001 06:53:00 GMT Received: from hotmail.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: f48.law12.hotmail.com [64.4.19.48]) id QQjzhz01847 for ; Wed, 24 Jan 2001 06:52:59 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Jan 2001 22:52:59 -0800 Received: from 193.2.66.79 by lw12fd.law12.hotmail.msn.com with HTTP; Wed, 24 Jan 2001 06:52:59 GMT X-Originating-IP: [193.2.66.79] From: "ben rodmanb" To: mpls@UU.NET Subject: suggestions for doctoral thesis Date: Wed, 24 Jan 2001 06:52:59 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Jan 2001 06:52:59.0278 (UTC) FILETIME=[49B7C2E0:01C085D2] Sender: owner-mpls@UU.NET Precedence: bulk Hi, I am postgraduate student and am currently looking for an interesting problem to solve in my doctoral thesis. Does anybody have a suggestion what interesting could be done in the area of MPLS/IP. Thanks Ron _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mpls@UU.NET Wed Jan 24 04:15:22 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17077 for ; Wed, 24 Jan 2001 04:15:22 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzii16983; Wed, 24 Jan 2001 09:14:43 GMT Received: by mail-control.mail.uu.net id QQjzii11668 for mpls-outgoing; Wed, 24 Jan 2001 09:14:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzii11658 for ; Wed, 24 Jan 2001 09:14:05 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 QQjzii18721 for ; Wed, 24 Jan 2001 09:13:04 GMT Received: from bbvproxy.satyam.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: [208.220.247.7]) id QQjzii14898 for ; Wed, 24 Jan 2001 09:13:01 GMT Received: from 208.220.247.3 by bbvproxy.satyam.com (InterScan E-Mail VirusWall NT) Received: by BBVNT001 with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 14:40:39 +0530 Message-ID: From: Ravindra_Joshi To: mpls@UU.NET Subject: Query on RFC3036 Date: Wed, 24 Jan 2001 14:40:34 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C085E5.84EA5D90" 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_01C085E5.84EA5D90 Content-Type: text/plain Hello, Ref. doc : Request for Comments: 3036 (LDP Specification) Discovery messages provide a mechanism whereby LSRs indicate their presence in a network by sending a Hello message periodically. This is transmitted as a UDP packet to the LDP port at the "all routers on this subnet" group multicast address. As per our understanding Multicasting is supported by only Class D networks.... If we hav a class B or C network, how do we send this message ? In other words, is "all routers on this subnet group" there on Class B or C n/w? If it's possible - pls let me know the procedure.. I might have missed something very basic - pls giv me the relevant pointer for clarifiacation.. Regards, RB ------_=_NextPart_001_01C085E5.84EA5D90 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Query on RFC3036

Hello,

Ref. doc : Request for Comments: 3036 (LDP = Specification)         &nbs= p;      =20
Discovery messages provide a = mechanism whereby LSRs indicate their presence in a network by sending = a Hello message periodically.  This is transmitted as a UDP packet = to the LDP port at the "all routers on this subnet" group = multicast address. 

As per our understanding = Multicasting is supported by only Class D networks....
If we hav a class B or C = network, how do we send this message ?
In other words, is "all = routers on this subnet group" there on Class B or C n/w?
If it's possible - pls let me = know the procedure..

I might have missed something = very basic - pls giv me the relevant pointer for = clarifiacation..

Regards,
RB

------_=_NextPart_001_01C085E5.84EA5D90-- From owner-mpls@UU.NET Wed Jan 24 05:49:05 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17781 for ; Wed, 24 Jan 2001 05:49:05 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzip13551; Wed, 24 Jan 2001 10:48:21 GMT Received: by mail-control.mail.uu.net id QQjzip03861 for mpls-outgoing; Wed, 24 Jan 2001 10:47:56 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzip03853 for ; Wed, 24 Jan 2001 10:47: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 QQjzip12277 for ; Wed, 24 Jan 2001 10:47:27 GMT Received: from web1702.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web1702.mail.yahoo.com [128.11.23.213]) id QQjzip26529 for ; Wed, 24 Jan 2001 10:47:27 GMT Message-ID: <20010124112418.25320.qmail@web1702.mail.yahoo.com> Received: from [64.103.21.120] by web1702.mail.yahoo.com; Wed, 24 Jan 2001 03:24:18 PST Date: Wed, 24 Jan 2001 03:24:18 -0800 (PST) From: Paulo Pereira Subject: Re: Query on RFC3036 To: Ravindra_Joshi@BBV.Satyam.com Cc: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQjzip13551 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA17781 Ravindra, the all routers is a well know multicast address: Reserved use: 224.0.0.0 through 224.0.0.255 224.0.0.1— all systems on subnet 224.0.0.2— all routers on subnet See "http://www.isi.edu/in-notes/iana/assignments/multicast-addresses" for more details. Paulo Hello, Ref. doc : Request for Comments: 3036 (LDP Specification) Discovery messages provide a mechanism whereby LSRs indicate their presence in a network by sending a Hello message periodically. This is transmitted as a UDP packet to the LDP port at the "all routers on this subnet" group multicast address. As per our understanding Multicasting is supported by only Class D networks.... If we hav a class B or C network, how do we send this message ? In other words, is "all routers on this subnet group" there on Class B or C n/w? If it's possible - pls let me know the procedure.. I might have missed something very basic - pls giv me the relevant pointer for clarifiacation.. Regards, RB __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ From owner-mpls@UU.NET Wed Jan 24 07:23:39 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18736 for ; Wed, 24 Jan 2001 07:23:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjziv01626; Wed, 24 Jan 2001 12:23:07 GMT Received: by mail-control.mail.uu.net id QQjziv05250 for mpls-outgoing; Wed, 24 Jan 2001 12:22:35 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjziv05241 for ; Wed, 24 Jan 2001 12:22:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjziv22399 for ; Wed, 24 Jan 2001 12:21:41 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjziv09873 for ; Wed, 24 Jan 2001 12:21:41 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA06189 for mpls@uu.net; Wed, 24 Jan 2001 07:21:40 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjziv05089 for ; Wed, 24 Jan 2001 12:21:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjziv29215 for ; Wed, 24 Jan 2001 12:20:54 GMT Received: from ietf.org by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQjziv08851 for ; Wed, 24 Jan 2001 12:20:54 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18569; Wed, 24 Jan 2001 07:20:53 -0500 (EST) Message-Id: <200101241220.HAA18569@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-05.txt Date: Wed, 24 Jan 2001 07:20:53 -0500 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Framework for IP Multicast in MPLS Author(s) : D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul, F. Ansari Filename : draft-ietf-mpls-multicast-05.txt Pages : 28 Date : 23-Jan-01 This document offers a framework for IP multicast deployment in an MPLS environment. Issues arising when MPLS techniques are applied to IP multicast are overviewed. The pros and cons of existing IP multicast routing protocols in the context of MPLS are described and the relation to the different trigger methods and label distribution modes are discussed. The consequences of various layer 2 (L2) technologies are listed. Both point-to-point and multi-access networks are considered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-multicast-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-multicast-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-multicast-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: <20010123115408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-multicast-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-multicast-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010123115408.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Wed Jan 24 07:27:31 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18802 for ; Wed, 24 Jan 2001 07:27:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjziv16939; Wed, 24 Jan 2001 12:27:08 GMT Received: by mail-control.mail.uu.net id QQjziv05578 for mpls-outgoing; Wed, 24 Jan 2001 12:26:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjziv05559 for ; Wed, 24 Jan 2001 12: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 QQjziv15170 for ; Wed, 24 Jan 2001 12:26:08 GMT Received: from wiproecmx2.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiproecmx2.wipro.com [164.164.31.6]) id QQjziv06316 for ; Wed, 24 Jan 2001 12:26:03 GMT Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id SAA08410 for ; Wed, 24 Jan 2001 18:05:32 GMT Received: from ecvwall1.wipro.com ([192.168.181.23]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA5B1E for ; Wed, 24 Jan 2001 17:55:56 +0530 Received: from wipro.com ([192.168.220.54]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA5656 for ; Wed, 24 Jan 2001 17:52:58 +0530 Message-ID: <3A6ECA89.1C45E4FE@wipro.com> Date: Wed, 24 Jan 2001 17:58:58 +0530 From: "Amarnath Honnavalli Anantharamaiah" X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Regarding LDP Specification - Next hop change trigger in Appendix A.1.7 Content-Type: multipart/alternative; boundary="------------23C8AE2181E2FE3D5E0C1DFF" Sender: owner-mpls@UU.NET Precedence: bulk --------------23C8AE2181E2FE3D5E0C1DFF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [1] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NH.10 Is there a New Next Hop for the FEC? If not, goto NH.16. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ My slim understanding is, this procedure will be called only when old next hop changes to new next hop. Then, what are we going to check here ? 1. Are we checking if this Route is deleted from the routing table ? 2. Are we checking if this has become an egresss for the FEC? [2] In convensional IP routing protocol, what will be the nexthop entry in routing table for an egress router ? how do we find that we are ingress & egress of the FEC If somethings of this is discussed, please give me a pointer to this. Thanks in advance Amar --------------23C8AE2181E2FE3D5E0C1DFF Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit [1]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      NH.10  Is there a New Next Hop for the FEC?
             If not, goto NH.16.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
My slim understanding is, this procedure will be called only when old next hop changes to new next hop.
Then, what are we going to check here ?
      1. Are we checking if this Route is deleted from the routing table ?
      2. Are we checking if this has become an egresss for the FEC?

[2] In convensional IP routing protocol, what will be the nexthop entry in routing table for an egress router ?
     how do we find that we are ingress & egress of the FEC

If somethings of this is discussed, please give me a pointer to this.
 
 

Thanks in advance
Amar
  --------------23C8AE2181E2FE3D5E0C1DFF-- From owner-mpls@UU.NET Wed Jan 24 07:36:42 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18966 for ; Wed, 24 Jan 2001 07:36:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjziw28520; Wed, 24 Jan 2001 12:36:12 GMT Received: by mail-control.mail.uu.net id QQjziw06210 for mpls-outgoing; Wed, 24 Jan 2001 12:35:41 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjziw06196 for ; Wed, 24 Jan 2001 12:35: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 QQjziw29108 for ; Wed, 24 Jan 2001 12:34:18 GMT Received: from wiproecmx2.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiproecmx2.wipro.com [164.164.31.6]) id QQjziw06296 for ; Wed, 24 Jan 2001 12:34:13 GMT Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id SAA10335 for ; Wed, 24 Jan 2001 18:13:45 GMT Received: from ecvwall1.wipro.com ([192.168.181.23]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA73C5 for ; Wed, 24 Jan 2001 18:04:10 +0530 Received: from wipro.com ([192.168.220.54]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA6172 for ; Wed, 24 Jan 2001 18:01:13 +0530 Message-ID: <3A6ECC79.D26CD7C2@wipro.com> Date: Wed, 24 Jan 2001 18:07:13 +0530 From: "Amarnath Honnavalli Anantharamaiah" X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: LDP Specification - Appendix A.1.6 ( New FEC detection) & Appendix A.1.1 (Receive Label Request) Content-Type: multipart/alternative; boundary="------------E7BF0EA3497594939451BF13" Sender: owner-mpls@UU.NET Precedence: bulk --------------E7BF0EA3497594939451BF13 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [1] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ FEC.4 Perform LSR Label Request procedure: For Request Never 1. Goto FEC.6 For Request When Needed OR For Request On Request 1. Execute procedure Prepare_Label_Request_Attributes (Next Hop, FEC, InitAttributes, SAttributes); 2. Execute procedure Send_Label_Request (Next Hop, FEC, SAttributes). Goto FEC.6. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In case of the Label Request procedure, Why do we need to make a Request for RequestOnRequest. For this procedure, we should request only when we have a request from upstream LSR. Please clarify... [2] Similarly in A.1.1 Receive Label Request... Why should we send Label Request for Request When Needed. This will be done already in FEC.4 above ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LRq.10 Perform LSR Label Request procedure: For Request Never 1. Goto LRq.13. For Request When Needed OR For Request On Request 1. Execute procedure Prepare_Label_Request_Attributes (Next Hop, FEC, RAttributes, SAttributes); 2. Execute procedure Send_Label_Request (Next Hop, FEC, SAttributes). Goto LRq.13. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Thanks in Advance --------------E7BF0EA3497594939451BF13 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit [1]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      FEC.4   Perform LSR Label Request procedure:

            For Request Never

              1. Goto FEC.6

            For Request When Needed OR
            For Request On Request

              1. Execute procedure
                 Prepare_Label_Request_Attributes
                 (Next Hop, FEC, InitAttributes, SAttributes);

              2. Execute procedure Send_Label_Request (Next
                 Hop, FEC, SAttributes).
                 Goto FEC.6.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In case of the Label Request procedure, Why do we need to make a Request for RequestOnRequest.
For this procedure, we should request only when we have a request from upstream LSR.

Please clarify...

[2] Similarly in A.1.1 Receive Label Request... Why should we send Label Request for Request When Needed. This will be done already in FEC.4 above
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      LRq.10  Perform LSR Label Request procedure:

            For Request Never

               1. Goto LRq.13.

            For Request When Needed OR
            For Request On Request

               1. Execute procedure Prepare_Label_Request_Attributes
                  (Next Hop, FEC, RAttributes, SAttributes);

               2. Execute procedure Send_Label_Request (Next Hop, FEC,
                  SAttributes).
                  Goto LRq.13.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Thanks in Advance --------------E7BF0EA3497594939451BF13-- From owner-mpls@UU.NET Wed Jan 24 09:07:24 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20911 for ; Wed, 24 Jan 2001 09:07:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzjc12356; Wed, 24 Jan 2001 14:06:32 GMT Received: by mail-control.mail.uu.net id QQjzjc06727 for mpls-outgoing; Wed, 24 Jan 2001 14:06:15 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzjc06670 for ; Wed, 24 Jan 2001 14:06:04 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 QQjzjc00451 for ; Wed, 24 Jan 2001 14:05:05 GMT Received: from bach.mail.pipex.net by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: [212.249.8.5]) id QQjzjc10296 for ; Wed, 24 Jan 2001 14:05:04 GMT Received: (qmail 6444 invoked from network); 24 Jan 2001 14:12:54 -0000 Received: from unknown (HELO zurexch1.zur.ch.internal) (212.249.31.254) by 212.249.8.5 with SMTP; 24 Jan 2001 14:12:54 -0000 Received: by zurexch1.zur.ch.internal with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 15:04:37 +0100 Message-ID: <09AA9BC0FF0DD311B4A10008C70DEF0601312A9B@zurexch1.zur.ch.internal> From: Pedro Paiva To: "'Holmes, David A.'" Cc: mpls@UU.NET, peter.lewis@upperside.fr Subject: RE: First international MPLS exhibition Date: Wed, 24 Jan 2001 15:04:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk David, # There appears to be a purist viewpoint that the mailing list be used solely # for technical exchanges, and not for notification of events of interest. # Where else can the MPLS community be notified of events of common interest? On the MPLS Forum mailing list(s) can be an idea. Pedro "Hawkeye" PAIVA Chief Technologist, EMEA - Future Technology Development UUNET - a WorldCom company 18, ch. de Trefle Blanc CH-1228 Plan-les-Ouates (Geneve) Tel +41.22.580.76.32 Mobile +41.79.310.24.08 e-mail pedrop@ch.uu.net # -----Original Message----- # From: Holmes, David A. [mailto:David.A.Holmes@disney.com] # Sent: lundi, 22. janvier 2001 20:53 # To: emildrottar@auranetinc.com; randy@psg.com; # peter.lewis@upperside.fr # Cc: mpls@UU.NET # Subject: RE: First international MPLS exhibition # # # I don't get the vitriol directed at Mr Lewis. Upon inspection # of his web # site, Mr Lewis is informing the MPLS-interested community # about an event # that could have productive value. It is not as if he is selling # get-rich-quick schemes. # # There appears to be a purist viewpoint that the mailing list # be used solely # for technical exchanges, and not for notification of events # of interest. # Where else can the MPLS community be notified of events of # common interest? # # David # # -----Original Message----- # From: emildrottar@auranetinc.com [mailto:emildrottar@auranetinc.com] # Sent: Monday, January 22, 2001 7:26 AM # To: randy@psg.com; peter.lewis@upperside.fr # Cc: mpls@UU.NET # Subject: RE: First international MPLS exhibition # # # I would like to ask that Mr Lewis either refrain from abusing this # reflector, or that he be removed from the subscription list # and all his # future EMAIL be blocked upon his next offense. # # Emil # # -----Original Message----- # From: Randy Bush [mailto:randy@psg.com] # Sent: Monday, January 22, 2001 10:10 AM # To: Peter Lewis # Cc: mpls@UU.NET # Subject: Re: First international MPLS exhibition # # # > http://www.upperside.fr/congress/exhi.htm # > First international MPLS exhibition floorplan. Paris. # # where is the drain for the slime spammers like you? # # randy # From owner-mpls@UU.NET Wed Jan 24 09:18:26 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21230 for ; Wed, 24 Jan 2001 09:18:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzjd27175; Wed, 24 Jan 2001 14:17:58 GMT Received: by mail-control.mail.uu.net id QQjzjd08412 for mpls-outgoing; Wed, 24 Jan 2001 14:16:47 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzjd08407 for ; Wed, 24 Jan 2001 14:16: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 QQjzjd01733 for ; Wed, 24 Jan 2001 14:15:32 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzjd27262 for ; Wed, 24 Jan 2001 14:15:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA12567 for mpls@uu.net; Wed, 24 Jan 2001 09:15:27 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzjb23099 for ; Wed, 24 Jan 2001 13:45:18 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 QQjzja29789 for ; Wed, 24 Jan 2001 13:44:05 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 QQjzja15753 for ; Wed, 24 Jan 2001 13:44:05 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA02881; Wed, 24 Jan 2001 08:43:45 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABG13478; Wed, 24 Jan 2001 08:44:02 -0500 (EST) Message-Id: <4.3.2.7.2.20010124084646.0293ef08@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Jan 2001 08:48:25 -0500 To: Soumen Sarkar From: "Thomas D. Nadeau" Subject: Re: MPLS-TE-MIB additions (last call) Cc: cheenu Srinivasan , Arun Viswanathan , In-Reply-To: References: <4.3.2.7.2.20010123130518.0295b9d0@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:51 AM 1/24/2001 +0530, Soumen Sarkar wrote: >On Tue, 23 Jan 2001, Thomas D. Nadeau wrote: > > > > > > > Hi, > > > > In addition to the 4 agreed upon changes from Joan > > and Shobhan, the co-authors of the MPLS-TE-MIB have three > > objects that we would like added/modified in the existing > > MPLS-TE-MIB and thought that we would post them to > > the mailing list prior to adding them. I understand > > that last call was finished last Friday, but I > > was too busy to send these out, so I apologize. > > > > HopTable: > > > > Add an object called mplsTunnelHopExcludeAddr whose > > purpose it is to denote whether or not this hop specifies > > an 'included' or 'excluded' hop. The default is 'include', > > so the DEFVAL is false(2). > > > > mplsTunnelHopIncludeExclude OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "If this value is set to true(1), then this indicates that this > > hop MUST be included in the tunnel's path. If this value is set to > > false(2), then this hop MUST be avoided when calculating the path for this > > tunnel. The default value of this object is true(1), so that by default all > > indicated hops are included in the CSPF path computation." > > ::= { mplsTunnelHopEntry xxx } > > > > > Tom, I think the name mplsTunnelHopIncludeExclude is creating > confusion since its type is TruthValue. Since the default value > would be true(1), I suggest the name to be : mplsTunnelHopInclude > It will be aligned with its semantic. Actually we rethought this after I sent out the email for that very same reason. It is now defined as follows: mplsTunnelHopIncludeExclude OBJECT-TYPE SYNTAX INTEGER { include(1), exclude(2) } Does that seem more appropriate to you? --Tom From owner-mpls@UU.NET Wed Jan 24 09:49:58 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22302 for ; Wed, 24 Jan 2001 09:49:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzjd25904; Wed, 24 Jan 2001 14:27:59 GMT Received: by mail-control.mail.uu.net id QQjzjd09553 for mpls-outgoing; Wed, 24 Jan 2001 14:27:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzjd09545 for ; Wed, 24 Jan 2001 14:27:32 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 QQjzjd06399 for ; Wed, 24 Jan 2001 14:27:11 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzjd10585 for ; Wed, 24 Jan 2001 14:27:11 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA13790 for mpls@uu.net; Wed, 24 Jan 2001 09:27:10 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzjd09486 for ; Wed, 24 Jan 2001 14:26:43 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzjd02175 for ; Wed, 24 Jan 2001 14:26:26 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 QQjzjd06751 for ; Wed, 24 Jan 2001 14:26:26 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA04884; Wed, 24 Jan 2001 09:26:06 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABG14009; Wed, 24 Jan 2001 09:26:22 -0500 (EST) Message-Id: <4.3.2.7.2.20010124091447.029ebe50@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Jan 2001 09:30:45 -0500 To: Jim Boyle From: "Thomas D. Nadeau" Subject: Re: MPLS-TE-MIB additions (last call) Cc: cheenu Srinivasan , Arun Viswanathan , "Cucchiara, Joan" , "'slakkapr@nortelnetworks.com'" , mpls@UU.NET In-Reply-To: References: <4.3.2.7.2.20010123130518.0295b9d0@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk > > In addition to the 4 agreed upon changes from Joan > > and Shobhan, the co-authors of the MPLS-TE-MIB have three > >I counted 3 folks that agreed and 0 that objected, not a preponderance of >support, but I suppose it'll do. Jim, I think that the consensus was 6 in favor and no objections to add these objects. That seems to be a consensus to add these objects to the MIB. What is unclear is whether or not we should make these objects optional if the mplsTunnelSignallingProto variable is not set to crldp(3) (or the agent does not support CR-LDP altogether) for a particular tunnel entry. Let me outline the two options for this and the associated pros and cons. 1: Add the objects as optional iff CR-LDP is not implemented. The advantage here is that if the implementation does not support CR-LDP, it can save itself some memory and effort. The advantage to the operator is that when it scans the table, the agent will simply not return these objects. The operator can also find this out through an agent capabilities statement. The disadvantage as Jim points out, is that it makes these 4 objects optional on a signaling protocol basis, so some rows in the table may support these 4 columns, and others may not. 2: Add the options, but make them mandatory for all implementations. This is certainly possible, but when an implementation does not support CR-LDP, the agent MUST ignore these values during SET operations, and MUST return 0 for the values at all times. One of the variables can under normal circumstances, contain the value of 0, which can be confusing unless we state that clearly in the fine print. In my opinion, this is more confusing for the operator, since there are now variables which return values when queried, yet are meaningless if CR-LDP is not implemented. The operator may not know this until after they have read over the documentation (or the agent capabilities statement), whereas in the first case, they will simply not be returned upon a query. My personal opinion is to use option 1, but I will leave it up to the list to decide this one. --Tom From owner-mpls@UU.NET Wed Jan 24 10:11:25 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22908 for ; Wed, 24 Jan 2001 10:11:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzjg11140; Wed, 24 Jan 2001 15:09:53 GMT Received: by mail-control.mail.uu.net id QQjzjg26084 for mpls-outgoing; Wed, 24 Jan 2001 15:09:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzjg25953 for ; Wed, 24 Jan 2001 15:09: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 QQjzjg24766 for ; Wed, 24 Jan 2001 15:08:07 GMT Received: from femail11.sdc1.sfba.home.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: femail11.sdc1.sfba.home.com [24.0.95.107]) id QQjzjg04685 for ; Wed, 24 Jan 2001 15:08:06 GMT Received: from c1052242a.frmt1.sfba.home.com ([24.19.208.28]) by femail11.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010124150806.MDGO11834.femail11.sdc1.sfba.home.com@c1052242a.frmt1.sfba.home.com>; Wed, 24 Jan 2001 07:08:06 -0800 Message-ID: <024801c0867b$f2c3ee00$1cd01318@frmt1.sfba.home.com> Reply-To: "Manohar Ellanti" From: "Manohar Ellanti" To: "cheenu Srinivasan" , "Arun Viswanathan" , , "Thomas D. Nadeau" References: <4.3.2.7.2.20010123130518.0295b9d0@bucket.cisco.com> Subject: Re: MPLS-TE-MIB additions (last call) Date: Wed, 24 Jan 2001 19:07:26 -0800 Organization: @home MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tom, How does this relate to the Traffic Engineering architecture document where a distinction is made between include/exclude and explicitInclude/explicitExclude. An explicitInclude hop list can be used to prune the graph and then run CSPF.I think explicitExclude probably should be possible to specify using the table you described. But I think it is not the case explicitInclude. I think we should have - option of suggested include option of explicit include (sub graph formed with include hops) option to exclude some hops -Manohar ----- Original Message ----- From: "Thomas D. Nadeau" To: "cheenu Srinivasan" ; "Arun Viswanathan" ; Sent: Tuesday, January 23, 2001 10:10 AM Subject: MPLS-TE-MIB additions (last call) > > Hi, > > In addition to the 4 agreed upon changes from Joan > and Shobhan, the co-authors of the MPLS-TE-MIB have three > objects that we would like added/modified in the existing > MPLS-TE-MIB and thought that we would post them to > the mailing list prior to adding them. I understand > that last call was finished last Friday, but I > was too busy to send these out, so I apologize. > > HopTable: > > Add an object called mplsTunnelHopExcludeAddr whose > purpose it is to denote whether or not this hop specifies > an 'included' or 'excluded' hop. The default is 'include', > so the DEFVAL is false(2). > > mplsTunnelHopIncludeExclude OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "If this value is set to true(1), then this indicates that this > hop MUST be included in the tunnel's path. If this value is set to > false(2), then this hop MUST be avoided when calculating the path for this > tunnel. The default value of this object is true(1), so that by default all > indicated hops are included in the CSPF path computation." > ::= { mplsTunnelHopEntry xxx } > > > mplsTunnelPathOptionName OBJECT-TYPE > SYNTAX DisplayString > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The description of this series of hops as they relate to the > specified path option." > ::= { mplsTunnelHopEntry xxx } > > > > I think that we incorrectly put this bit in the > mplsTunnelSessionAttributes: > > isComputed This flag indicates whether the tunnel > path is computed using a constraint-based routing > algorithm based on the mplsTunnelHopTable entries. > > > This bit should go on the HopEntry, and should be removed > from the mplsTunnelSessionAttributes. If you leave the bit > where it is, it means that *every* path in the hop table > for a particular tunnel is either explicitly specified > or dynamically computed. This is incorrect as you > may want a mixture of the two. > > I suggest that we add an object to the tunnelHopEntry > called tunnelHopEntryPathComputation and make it an enumeration > like: > > INTEGER { dynamic(1), -- CSPF computed > explicit(2) } -- strict hop > > DESCRIPTION "If this value is set to dynamic, then the > user should only specify the source and > destination of the path and expect that > the CSPF will calculate the remainder of > the path. If this value is set to explicit, > the user should specify the entire path > for the tunnel to take. This path may contain > strict or loose hops." > > > --Tom > From owner-mpls@UU.NET Wed Jan 24 10:15:36 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22998 for ; Wed, 24 Jan 2001 10:15:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzjg19181; Wed, 24 Jan 2001 15:14:25 GMT Received: by mail-control.mail.uu.net id QQjzjg27074 for mpls-outgoing; Wed, 24 Jan 2001 15:13:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzjg27060 for ; Wed, 24 Jan 2001 15:13: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 QQjzjg16835 for ; Wed, 24 Jan 2001 15:13:32 GMT Received: from samar.sasi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQjzjg17074 for ; Wed, 24 Jan 2001 15:13:27 GMT Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id UAA01895; Wed, 24 Jan 2001 20:41:55 +0530 (IST) Received: from suns3.sasi.com ([10.0.36.3]) by samar.sasi.com; Wed, 24 Jan 2001 20:41:54 +0000 (IST) Received: from localhost (soumen@localhost) by suns3.sasi.com (8.9.3/8.9.3) with ESMTP id UAA23998; Wed, 24 Jan 2001 20:41:54 +0530 (IST) Date: Wed, 24 Jan 2001 20:41:54 +0530 (IST) From: Soumen Sarkar To: "Thomas D. Nadeau" cc: Jim Boyle , cheenu Srinivasan , Arun Viswanathan , "Cucchiara, Joan" , "'slakkapr@nortelnetworks.com'" , Subject: Re: MPLS-TE-MIB additions (last call) In-Reply-To: <4.3.2.7.2.20010124091447.029ebe50@bucket.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Tom, I do agree with you that 1st option is more advisable than the 2nd one and if no more idea comes off from the list, I guess 1st option will have more takers. Just for the sake of it, would you think creating a separate table (only for these four objects ) could be an option ? The advantage is, when CR-LDP is not supported whole table will vanish and the operator will readily understand this on first attept. This also would avoid the problem you mentioned in your first option. -regards, Soumen On Wed, 24 Jan 2001, Thomas D. Nadeau wrote: > > > Jim, > > I think that the consensus was 6 in favor and no > objections to add these objects. That seems to be a consensus > to add these objects to the MIB. What is unclear is whether > or not we should make these objects optional if the > mplsTunnelSignallingProto variable is not set to > crldp(3) (or the agent does not support CR-LDP altogether) > for a particular tunnel entry. Let me outline the two options > for this and the associated pros and cons. > > 1: Add the objects as optional iff CR-LDP is not implemented. > > The advantage here is that if the implementation > does not support CR-LDP, it can save itself some memory > and effort. The advantage to the operator is that > when it scans the table, the agent will > simply not return these objects. The operator can also find > this out through an agent capabilities statement. > The disadvantage as Jim points out, is that it makes > these 4 objects optional on a signaling protocol basis, so > some rows in the table may support these 4 columns, and others > may not. > > 2: Add the options, but make them mandatory for all > implementations. > > This is certainly possible, but when an implementation does > not support CR-LDP, the agent MUST ignore these values > during SET operations, and MUST return 0 for the values > at all times. One of the variables can under normal > circumstances, > contain the value of 0, which can be confusing unless we state > that clearly in the fine print. In my opinion, this is more > confusing for the operator, since there are now variables > which > return values when queried, yet are meaningless if CR-LDP is > not implemented. The operator may not know this until > after they > have read over the documentation (or the agent capabilities > statement), whereas in the first case, they will simply not > be returned upon a query. > > My personal opinion is to use option 1, but I will leave it up > to the list to decide this one. > > --Tom > > From owner-mpls@UU.NET Wed Jan 24 10:38:50 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23596 for ; Wed, 24 Jan 2001 10:38:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzji05515; Wed, 24 Jan 2001 15:34:28 GMT Received: by mail-control.mail.uu.net id QQjzji29642 for mpls-outgoing; Wed, 24 Jan 2001 15:33:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzji29628 for ; Wed, 24 Jan 2001 15:33:39 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 QQjzji23162 for ; Wed, 24 Jan 2001 15:33:09 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 QQjzji02892 for ; Wed, 24 Jan 2001 15:33: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 KAA12769 for ; Wed, 24 Jan 2001 10:33:07 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04280 for ; Wed, 24 Jan 2001 10:33:08 -0500 (EST) Message-ID: <3A6EF5CF.C671BED5@marconi.com> Date: Wed, 24 Jan 2001 10:33:35 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: QoS and Labels: A question ?? References: <001c01c0858d$ed3684f0$4501000a@vsharmapc> <3A6E1E85.C7D0810E@marconi.com> <14958.8922.346000.907970@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora Akyol wrote: > > >>>>> "David" == David Charlap writes: > > David> If you need actual QoS guarantees, or if your > David> switches only support L-LPSs, or if you want the two > David> service levels to be routed independantly, then you > David> need to create a separate LSP for each service level. > David> CR-LDP or RSVP-TE can be used for signalling the QoS > David> requirements for the two LSPs. > > David > > You are making assumptions about a particular switch > architecture when you assert that you can not do "actual" QoS > guarantees with E-LSPs. If you have a policer and a > shaper/scheduler that can process the EXP bits as well as the > label, then doing "actual" QoS is quite possible with > E-LSPs. > > Not only that, but you can map traffic destined to the same > prefix to different EXP levels based either on Diffserv bits or > on packet content. This also applies to VLAN tags. The meaning of the EXP bits is not signalled. It must be preconfigured network-wide. And in order to be useful, they must be identical across the entire network. Which limits you to 8 different service levels, network-wide. If you use the EXP bits to define a priority level and two flows are both assigned that level, they will be queued in best-effort fashion relative to each other. There is no way to guarantee the individual flows any particular level of service. You can only guarantee the aggregate of one class relative to another class. Using L-LSPs, you can request a separate label, and a separate resource reservation for every flow, if needed. This is the only way to guarantee this level of service. (Unless you're willing to limit each DS code point to a single flow, which is a ridiculous concept.) E-LSPs are useful, no doubt about that. But they can not provide the level of QoS necessary to make sure that a single specific flow can be guaranteed the resources it requires. -- David From owner-mpls@UU.NET Wed Jan 24 10:44:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23808 for ; Wed, 24 Jan 2001 10:44:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzji12536; Wed, 24 Jan 2001 15:42:11 GMT Received: by mail-control.mail.uu.net id QQjzji00875 for mpls-outgoing; Wed, 24 Jan 2001 15:41:37 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzji00855 for ; Wed, 24 Jan 2001 15:41: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 QQjzji17867 for ; Wed, 24 Jan 2001 15:41:19 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzji11397 for ; Wed, 24 Jan 2001 15:41:18 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA20696 for mpls@uu.net; Wed, 24 Jan 2001 10:41:18 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzji00668 for ; Wed, 24 Jan 2001 15:40:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjzji02280 for ; Wed, 24 Jan 2001 15:40:10 GMT Received: from brixcorp2.brixnet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.91.233.5]) id QQjzji09915 for ; Wed, 24 Jan 2001 15:40:10 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 10:40:10 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B7EC0@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'Jim Boyle'" , Soumen Sarkar Cc: "Thomas D. Nadeau" , cheenu Srinivasan , Arun Viswanathan , "Cucchiara, Joan" , "'slakkapr@nortelnetworks.com'" , mpls@UU.NET Subject: RE: MPLS-TE-MIB additions (last call) Date: Wed, 24 Jan 2001 10:40:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Option 1 sounds good to me also. A separate table is probably also beneficially as Soumen points out. -Joan > -----Original Message----- > From: Jim Boyle [mailto:jboyle@Level3.net] > Sent: Wednesday, January 24, 2001 10:34 AM > To: Soumen Sarkar > Cc: Thomas D. Nadeau; cheenu Srinivasan; Arun Viswanathan; Cucchiara, > Joan; 'slakkapr@nortelnetworks.com'; mpls@UU.NET > Subject: Re: MPLS-TE-MIB additions (last call) > > > > That sounds good to me. > > On Wed, 24 Jan 2001, Soumen Sarkar wrote: > > > > > Tom, I do agree with you that 1st option is more advisable > > than the 2nd one and if no more idea comes off from the > > list, I guess 1st option will have more takers. Just for the > > sake of it, would you think creating a separate table (only > > for these four objects ) could be an option ? The advantage > > is, when CR-LDP is not supported whole table will vanish and > > the operator will readily understand this on first attept. > > This also would avoid the problem you mentioned in your > > first option. > > -regards, > > Soumen > > > > > > On Wed, 24 Jan 2001, Thomas D. Nadeau wrote: > > > > > > > > > > > Jim, > > > > > > I think that the consensus was 6 in favor and no > > > objections to add these objects. That seems to be a consensus > > > to add these objects to the MIB. What is unclear is whether > > > or not we should make these objects optional if the > > > mplsTunnelSignallingProto variable is not set to > > > crldp(3) (or the agent does not support CR-LDP altogether) > > > for a particular tunnel entry. Let me outline the two options > > > for this and the associated pros and cons. > > > > > > 1: Add the objects as optional iff CR-LDP > is not implemented. > > > > > > The advantage here is that if the implementation > > > does not support CR-LDP, it can save > itself some memory > > > and effort. The advantage to the operator is that > > > when it scans the table, the agent will > > > simply not return these objects. The > operator can also find > > > this out through an agent capabilities statement. > > > The disadvantage as Jim points out, is > that it makes > > > these 4 objects optional on a signaling > protocol basis, so > > > some rows in the table may support these > 4 columns, and others > > > may not. > > > > > > 2: Add the options, but make them mandatory for all > > > implementations. > > > > > > This is certainly possible, but when an > implementation does > > > not support CR-LDP, the agent MUST > ignore these values > > > during SET operations, and MUST return 0 > for the values > > > at all times. One of the variables can > under normal > > > circumstances, > > > contain the value of 0, which can be > confusing unless we state > > > that clearly in the fine print. In my > opinion, this is more > > > confusing for the operator, since there > are now variables > > > which > > > return values when queried, yet are > meaningless if CR-LDP is > > > not implemented. The operator may not > know this until > > > after they > > > have read over the documentation (or the > agent capabilities > > > statement), whereas in the first case, > they will simply not > > > be returned upon a query. > > > > > > My personal opinion is to use option 1, but I > will leave it up > > > to the list to decide this one. > > > > > > --Tom > > > > > > > > > From owner-mpls@UU.NET Wed Jan 24 10:46:22 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23846 for ; Wed, 24 Jan 2001 10:46:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzji15578; Wed, 24 Jan 2001 15:44:39 GMT Received: by mail-control.mail.uu.net id QQjzji01082 for mpls-outgoing; Wed, 24 Jan 2001 15:44:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzji01054 for ; Wed, 24 Jan 2001 15:44:01 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 QQjzji04856 for ; Wed, 24 Jan 2001 15:43:49 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzji24425 for ; Wed, 24 Jan 2001 15:43:48 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA20987 for mpls@uu.net; Wed, 24 Jan 2001 10:43:47 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzji01007 for ; Wed, 24 Jan 2001 15:43:14 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 QQjzji08980 for ; Wed, 24 Jan 2001 15:42:30 GMT Received: from brixcorp2.brixnet.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.91.233.5]) id QQjzji21907 for ; Wed, 24 Jan 2001 15:42:30 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 10:42:30 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B7EC1@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'manis@future.futsoft.com'" , "Cucchiara, Joan" Cc: slakkapr@nortelnetworks.com, tnadeau@cisco.com, arun@force10networks.com, cheenu@tachion.com, mpls@UU.NET Subject: RE: Last call on MPLS TE MIB Date: Wed, 24 Jan 2001 10:42:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Tom, I would like to see Manikantan's suggestions added to the MPLS-TE MIB. This is also for CR-LDP support. Is this object and description going to be added? Thanks, Joan > -----Original Message----- > From: Manikantan S [mailto:manis@future.futsoft.com] > Sent: Wednesday, January 17, 2001 11:33 PM > To: 'Cucchiara, Joan' > Cc: slakkapr@nortelnetworks.com; tnadeau@cisco.com; > arun@force10networks.com; cheenu@tachion.com; mpls@UU.NET > Subject: RE: Last call on MPLS TE MIB > > > Hello Joan > > #> Hello > #> > #> It would help, as suggested in the mail to include > #> the CRLDP-Specific MIB objects in the TE MIB. > #> > #> Currently we have them as Enterprise MIB objects > #> in our implementation and we can move to the > #> standard MIB if they are available there. > #> > #> I have the following question/doubt for Joan. > #> > #> 1) We have a field "flags" in the CRLDP Traffic > #> Parameters TLV. This helps in conveying the > #> set of negotiable parameters. The value of "Flags" > #> being added as a configurable object will provide > #> added flexibility. what do you suggest? > # > #I agree with you that an ActiveFlags object would > #be useful for CR-LDP. If possible, would you > #be able to email what this object looked like in > #your enterprise MIB? > # > #Having actual implementation feedback is very useful > #for MIB objects. > > I currently have the following definition in > the Enterprises MIB. > > fsMplsLdpCrlspTnlFlags INTEGER > > fsMplsLdpCrlspTnlFlags OBJECT-TYPE > SYNTAX INTEGER (0..63) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The value of Flags conveyed as part of the > Traffic Parameters > during the establishment of the CRLSP. The Bit value > indicates the set of Traffic parameters that are > negotiable during the CRLSP setup." > REFERENCE > "Section 4.3, Constraint-Based LSP Setup using > LDP, Jamoussi, > et. > al, , July 2000." > DEFVAL { 0 } -- Parameters not negotiable. > > #> > #> 2) Do we need to use the value of the MIB object > #> "mplsTunnelIncludeAnyAffinity" for the > #> "RsCls" field in Resource Class TLV? > # > #This seems like a reasonable approach. Are you > #suggesting that the wording of the "mplsTunnelIncludeAnyAffinity" > #object be enhanced to include CR-LDP's Resource Class TLV? > > Yes. I feel it will be clear and very helpful. > > Thanks and best regards > mani > ----------------------------------------- > S.Manikantan > Future Software Limited > 480-481, Anna Salai, > Nandanam, Chennai, India. > Zip (PIN CODE) : 600 035 > Phone : 91-44-4330550 > Fax : 91-44-4344157 > email : manis@future.futsoft.com > ----------------------------------------- > From owner-mpls@UU.NET Wed Jan 24 11:08:26 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24350 for ; Wed, 24 Jan 2001 11:08:26 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzjk09349; Wed, 24 Jan 2001 16:05:57 GMT Received: by mail-control.mail.uu.net id QQjzjk15582 for mpls-outgoing; Wed, 24 Jan 2001 16:05:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzjk15469 for ; Wed, 24 Jan 2001 16:05:25 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 QQjzjk06922 for ; Wed, 24 Jan 2001 16:04:33 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzjk06975 for ; Wed, 24 Jan 2001 16:04:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA23086 for mpls@uu.net; Wed, 24 Jan 2001 11:04:32 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzjk11078 for ; Wed, 24 Jan 2001 16:04:03 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjzjk20178 for ; Wed, 24 Jan 2001 16:01:56 GMT Received: from boyle.eng.level3.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu162-224-220.nc.rr.com [24.162.224.220]) id QQjzjk05967 for ; Wed, 24 Jan 2001 16:01:55 GMT Received: from localhost (jboyle@localhost) by boyle.eng.level3.com (8.9.3/8.8.7) with ESMTP id JAA10926; Wed, 24 Jan 2001 09:13:07 -0700 Date: Wed, 24 Jan 2001 09:13:07 -0700 (MST) From: Jim Boyle X-Sender: jboyle@boyle.eng.level3.com To: David Charlap cc: mpls@UU.NET Subject: Re: QoS and Labels: A question ?? In-Reply-To: <3A6EF5CF.C671BED5@marconi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk That is the difference between diffserv and intserv, I believe. Diffserv doesn't aim to give hard guarentees to individual flows. Diffserv, and "E-LSPs", work. Jim On Wed, 24 Jan 2001, David Charlap wrote: > Bora Akyol wrote: > > > > >>>>> "David" == David Charlap writes: > > > > David> If you need actual QoS guarantees, or if your > > David> switches only support L-LPSs, or if you want the two > > David> service levels to be routed independantly, then you > > David> need to create a separate LSP for each service level. > > David> CR-LDP or RSVP-TE can be used for signalling the QoS > > David> requirements for the two LSPs. > > > > David > > > > You are making assumptions about a particular switch > > architecture when you assert that you can not do "actual" QoS > > guarantees with E-LSPs. If you have a policer and a > > shaper/scheduler that can process the EXP bits as well as the > > label, then doing "actual" QoS is quite possible with > > E-LSPs. > > > > Not only that, but you can map traffic destined to the same > > prefix to different EXP levels based either on Diffserv bits or > > on packet content. This also applies to VLAN tags. > > The meaning of the EXP bits is not signalled. It must be preconfigured > network-wide. And in order to be useful, they must be identical across > the entire network. Which limits you to 8 different service levels, > network-wide. > > If you use the EXP bits to define a priority level and two flows are > both assigned that level, they will be queued in best-effort fashion > relative to each other. There is no way to guarantee the individual > flows any particular level of service. You can only guarantee the > aggregate of one class relative to another class. > > Using L-LSPs, you can request a separate label, and a separate resource > reservation for every flow, if needed. This is the only way to > guarantee this level of service. (Unless you're willing to limit each > DS code point to a single flow, which is a ridiculous concept.) > > E-LSPs are useful, no doubt about that. But they can not provide the > level of QoS necessary to make sure that a single specific flow can be > guaranteed the resources it requires. > > -- David > From owner-mpls@UU.NET Wed Jan 24 11:10:10 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24387 for ; Wed, 24 Jan 2001 11:10:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzjh25450; Wed, 24 Jan 2001 15:28:24 GMT Received: by mail-control.mail.uu.net id QQjzjh29030 for mpls-outgoing; Wed, 24 Jan 2001 15:27:55 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzjh29014 for ; Wed, 24 Jan 2001 15:27:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjzjh25041 for ; Wed, 24 Jan 2001 15:27:13 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzjh20697 for ; Wed, 24 Jan 2001 15:27:13 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA19016 for mpls@uu.net; Wed, 24 Jan 2001 10:27:12 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzjh28937 for ; Wed, 24 Jan 2001 15:26: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 QQjzjh24915 for ; Wed, 24 Jan 2001 15:26:34 GMT Received: from boyle.eng.level3.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu162-224-220.nc.rr.com [24.162.224.220]) id QQjzjh19319 for ; Wed, 24 Jan 2001 15:26:34 GMT Received: from localhost (jboyle@localhost) by boyle.eng.level3.com (8.9.3/8.8.7) with ESMTP id IAA10736; Wed, 24 Jan 2001 08:34:49 -0700 Date: Wed, 24 Jan 2001 08:33:34 -0700 (MST) From: Jim Boyle X-Sender: jboyle@boyle.eng.level3.com To: Soumen Sarkar cc: "Thomas D. Nadeau" , cheenu Srinivasan , Arun Viswanathan , "Cucchiara, Joan" , "'slakkapr@nortelnetworks.com'" , mpls@UU.NET Subject: Re: MPLS-TE-MIB additions (last call) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk That sounds good to me. On Wed, 24 Jan 2001, Soumen Sarkar wrote: > > Tom, I do agree with you that 1st option is more advisable > than the 2nd one and if no more idea comes off from the > list, I guess 1st option will have more takers. Just for the > sake of it, would you think creating a separate table (only > for these four objects ) could be an option ? The advantage > is, when CR-LDP is not supported whole table will vanish and > the operator will readily understand this on first attept. > This also would avoid the problem you mentioned in your > first option. > -regards, > Soumen > > > On Wed, 24 Jan 2001, Thomas D. Nadeau wrote: > > > > > > > Jim, > > > > I think that the consensus was 6 in favor and no > > objections to add these objects. That seems to be a consensus > > to add these objects to the MIB. What is unclear is whether > > or not we should make these objects optional if the > > mplsTunnelSignallingProto variable is not set to > > crldp(3) (or the agent does not support CR-LDP altogether) > > for a particular tunnel entry. Let me outline the two options > > for this and the associated pros and cons. > > > > 1: Add the objects as optional iff CR-LDP is not implemented. > > > > The advantage here is that if the implementation > > does not support CR-LDP, it can save itself some memory > > and effort. The advantage to the operator is that > > when it scans the table, the agent will > > simply not return these objects. The operator can also find > > this out through an agent capabilities statement. > > The disadvantage as Jim points out, is that it makes > > these 4 objects optional on a signaling protocol basis, so > > some rows in the table may support these 4 columns, and others > > may not. > > > > 2: Add the options, but make them mandatory for all > > implementations. > > > > This is certainly possible, but when an implementation does > > not support CR-LDP, the agent MUST ignore these values > > during SET operations, and MUST return 0 for the values > > at all times. One of the variables can under normal > > circumstances, > > contain the value of 0, which can be confusing unless we state > > that clearly in the fine print. In my opinion, this is more > > confusing for the operator, since there are now variables > > which > > return values when queried, yet are meaningless if CR-LDP is > > not implemented. The operator may not know this until > > after they > > have read over the documentation (or the agent capabilities > > statement), whereas in the first case, they will simply not > > be returned upon a query. > > > > My personal opinion is to use option 1, but I will leave it up > > to the list to decide this one. > > > > --Tom > > > > > From owner-mpls@UU.NET Wed Jan 24 11:37:24 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24897 for ; Wed, 24 Jan 2001 11:37:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzjm14365; Wed, 24 Jan 2001 16:35:24 GMT Received: by mail-control.mail.uu.net id QQjzjm19173 for mpls-outgoing; Wed, 24 Jan 2001 16:34:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzjm19165 for ; Wed, 24 Jan 2001 16:34:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjzjm24303 for ; Wed, 24 Jan 2001 16:33:38 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzjm12030 for ; Wed, 24 Jan 2001 16:33:38 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA25373 for mpls@uu.net; Wed, 24 Jan 2001 11:33:37 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzjm19036 for ; Wed, 24 Jan 2001 16: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 QQjzjm09852 for ; Wed, 24 Jan 2001 16:32:53 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 QQjzjm21504 for ; Wed, 24 Jan 2001 16:32:53 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA12599; Wed, 24 Jan 2001 11:32:33 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-223.cisco.com [161.44.134.223]) by bucket.cisco.com (Mirapoint) with ESMTP id ABH00617; Wed, 24 Jan 2001 11:32:50 -0500 (EST) Message-Id: <4.3.2.7.2.20010124113639.02ad9ea0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Jan 2001 11:37:15 -0500 To: "Cucchiara, Joan" , "'manis@future.futsoft.com'" , "Cucchiara, Joan" From: "Thomas D. Nadeau" Subject: RE: Last call on MPLS TE MIB Cc: slakkapr@nortelnetworks.com, arun@force10networks.com, cheenu@tachion.com, mpls@UU.NET In-Reply-To: <07B0D4912B83D31188F300A0C9F62EBB9B7EC1@brixcorp2.brixnet.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Yes, sorry we overlooked it during our most recent editing session. The object looks fine. Lets just blame Arun for that one. ;) --Tom >I would like to see Manikantan's suggestions >added to the MPLS-TE MIB. This is also for >CR-LDP support. Is this object and description >going to be added? > > Thanks, Joan > > > -----Original Message----- > > From: Manikantan S [mailto:manis@future.futsoft.com] > > Sent: Wednesday, January 17, 2001 11:33 PM > > To: 'Cucchiara, Joan' > > Cc: slakkapr@nortelnetworks.com; tnadeau@cisco.com; > > arun@force10networks.com; cheenu@tachion.com; mpls@UU.NET > > Subject: RE: Last call on MPLS TE MIB > > > > > > Hello Joan > > > > #> Hello > > #> > > #> It would help, as suggested in the mail to include > > #> the CRLDP-Specific MIB objects in the TE MIB. > > #> > > #> Currently we have them as Enterprise MIB objects > > #> in our implementation and we can move to the > > #> standard MIB if they are available there. > > #> > > #> I have the following question/doubt for Joan. > > #> > > #> 1) We have a field "flags" in the CRLDP Traffic > > #> Parameters TLV. This helps in conveying the > > #> set of negotiable parameters. The value of "Flags" > > #> being added as a configurable object will provide > > #> added flexibility. what do you suggest? > > # > > #I agree with you that an ActiveFlags object would > > #be useful for CR-LDP. If possible, would you > > #be able to email what this object looked like in > > #your enterprise MIB? > > # > > #Having actual implementation feedback is very useful > > #for MIB objects. > > > > I currently have the following definition in > > the Enterprises MIB. > > > > fsMplsLdpCrlspTnlFlags INTEGER > > > > fsMplsLdpCrlspTnlFlags OBJECT-TYPE > > SYNTAX INTEGER (0..63) > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The value of Flags conveyed as part of the > > Traffic Parameters > > during the establishment of the CRLSP. The Bit value > > indicates the set of Traffic parameters that are > > negotiable during the CRLSP setup." > > REFERENCE > > "Section 4.3, Constraint-Based LSP Setup using > > LDP, Jamoussi, > > et. > > al, , July 2000." > > DEFVAL { 0 } -- Parameters not negotiable. > > > > #> > > #> 2) Do we need to use the value of the MIB object > > #> "mplsTunnelIncludeAnyAffinity" for the > > #> "RsCls" field in Resource Class TLV? > > # > > #This seems like a reasonable approach. Are you > > #suggesting that the wording of the "mplsTunnelIncludeAnyAffinity" > > #object be enhanced to include CR-LDP's Resource Class TLV? > > > > Yes. I feel it will be clear and very helpful. > > > > Thanks and best regards > > mani > > ----------------------------------------- > > S.Manikantan > > Future Software Limited > > 480-481, Anna Salai, > > Nandanam, Chennai, India. > > Zip (PIN CODE) : 600 035 > > Phone : 91-44-4330550 > > Fax : 91-44-4344157 > > email : manis@future.futsoft.com > > ----------------------------------------- > > From owner-mpls@UU.NET Wed Jan 24 12:06:04 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25569 for ; Wed, 24 Jan 2001 12:06:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzjo21117; Wed, 24 Jan 2001 17:03:09 GMT Received: by mail-control.mail.uu.net id QQjzjo27905 for mpls-outgoing; Wed, 24 Jan 2001 17:02:37 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzjo27204 for ; Wed, 24 Jan 2001 17:02:25 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 QQjzjo25823 for ; Wed, 24 Jan 2001 17:01:25 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzjo19124 for ; Wed, 24 Jan 2001 17:01:24 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA27966 for mpls@uu.net; Wed, 24 Jan 2001 12:01:24 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzjo24120 for ; Wed, 24 Jan 2001 17:00:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzjo14880 for ; Wed, 24 Jan 2001 17:00:29 GMT Received: from scallop.baynetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns5.baynetworks.com [194.133.90.101]) id QQjzjo15858 for ; Wed, 24 Jan 2001 17:00:27 GMT Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by scallop.baynetworks.com (8.9.1/8.9.1) with ESMTP id SAA02724; Wed, 24 Jan 2001 18:05:53 +0100 (MET) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id LAA29641; Wed, 24 Jan 2001 11:58:14 -0500 (EST) Received: from nortelnetworks.com (dhcp235-150 [192.32.235.150]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id LAA25125; Wed, 24 Jan 2001 11:58:13 -0500 for Message-ID: <3A6F07CF.CC7D7E72@nortelnetworks.com> Date: Wed, 24 Jan 2001 11:50:24 -0500 From: Shobhan Lakkapragada Organization: Nortel Networks X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Thomas D. Nadeau" CC: Jim Boyle , cheenu Srinivasan , Arun Viswanathan , "Cucchiara, Joan" , mpls@UU.NET Subject: Re: MPLS-TE-MIB additions (last call) References: <4.3.2.7.2.20010123130518.0295b9d0@bucket.cisco.com> <4.3.2.7.2.20010124091447.029ebe50@bucket.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Tom, I agree that Option 1 below is a good way of adding them. But I feel it is more appropriate to keep the new objects in the same table. Reason being that CR-LDP implementations would use the already existing objects Max Rate, Mean Rate and Max Burst Rate for configuring CR-LDP parameters Peak Date rate, Committed rate and Peak Burst size. If the new objects are in separate table, then the required CR-LDP TE parameters will be spread across two different tables. I guess there is nothing wrong with it, but it just looks cleaner if they are all in same table. - shobhan "Thomas D. Nadeau" wrote: > > > In addition to the 4 agreed upon changes from Joan > > > and Shobhan, the co-authors of the MPLS-TE-MIB have three > > > >I counted 3 folks that agreed and 0 that objected, not a preponderance of > >support, but I suppose it'll do. > > Jim, > > I think that the consensus was 6 in favor and no > objections to add these objects. That seems to be a consensus > to add these objects to the MIB. What is unclear is whether > or not we should make these objects optional if the > mplsTunnelSignallingProto variable is not set to > crldp(3) (or the agent does not support CR-LDP altogether) > for a particular tunnel entry. Let me outline the two options > for this and the associated pros and cons. > > 1: Add the objects as optional iff CR-LDP is not implemented. > > The advantage here is that if the implementation > does not support CR-LDP, it can save itself some memory > and effort. The advantage to the operator is that > when it scans the table, the agent will > simply not return these objects. The operator can also find > this out through an agent capabilities statement. > The disadvantage as Jim points out, is that it makes > these 4 objects optional on a signaling protocol basis, so > some rows in the table may support these 4 columns, and others > may not. > > 2: Add the options, but make them mandatory for all > implementations. > > This is certainly possible, but when an implementation does > not support CR-LDP, the agent MUST ignore these values > during SET operations, and MUST return 0 for the values > at all times. One of the variables can under normal > circumstances, > contain the value of 0, which can be confusing unless we state > that clearly in the fine print. In my opinion, this is more > confusing for the operator, since there are now variables > which > return values when queried, yet are meaningless if CR-LDP is > not implemented. The operator may not know this until > after they > have read over the documentation (or the agent capabilities > statement), whereas in the first case, they will simply not > be returned upon a query. > > My personal opinion is to use option 1, but I will leave it up > to the list to decide this one. > > --Tom From owner-mpls@UU.NET Wed Jan 24 12:35:46 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26153 for ; Wed, 24 Jan 2001 12:35:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzjq07368; Wed, 24 Jan 2001 17:33:49 GMT Received: by mail-control.mail.uu.net id QQjzjq05909 for mpls-outgoing; Wed, 24 Jan 2001 17:33:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzjq05904 for ; Wed, 24 Jan 2001 17:33:22 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 QQjzjq24937 for ; Wed, 24 Jan 2001 17:31:48 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzjq02928 for ; Wed, 24 Jan 2001 17:31:47 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA00390 for mpls@uu.net; Wed, 24 Jan 2001 12:31:47 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzjq05856 for ; Wed, 24 Jan 2001 17:31: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 QQjzjq22895 for ; Wed, 24 Jan 2001 17:30:55 GMT Received: from procyon.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: procyon.pmc-sierra.bc.ca [134.87.115.1]) id QQjzjq07810 for ; Wed, 24 Jan 2001 17:30:54 GMT Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA11194; Wed, 24 Jan 2001 09:30:15 -0800 (PST) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 09:30:56 -0800 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6010C9BB2@BBY1EXM01> From: Shahram Davari To: "'Jim Boyle'" , David Charlap Cc: mpls@UU.NET Subject: RE: QoS and Labels: A question ?? Date: Wed, 24 Jan 2001 09:30:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi David, To reiterate Jim's comments, I think you may be looking at Intserv concept. Diffserv can use both E-LSP and L-LSP to guarantee an aggregate QoS (not per microflow QoS). It is true that you could use Intserv with MPLS for a finer controlled QoS (per microflow QoS), and the result probably looks very similar to L-LSP, in which the QoS is derived from the Label context. But they are totally different solutions. Yours, -Shahram P.S. you could also signal the meaning of EXP in E-LSP. This method is called Signaled E-LSP versus the Configured E-LSP. > -----Original Message----- > From: Jim Boyle [mailto:jboyle@Level3.net] > Sent: Wednesday, January 24, 2001 11:13 AM > To: David Charlap > Cc: mpls@UU.NET > Subject: Re: QoS and Labels: A question ?? > > > > > That is the difference between diffserv and intserv, I > believe. Diffserv > doesn't aim to give hard guarentees to individual flows. > Diffserv, and > "E-LSPs", work. > > Jim > > > On Wed, 24 Jan 2001, David Charlap wrote: > > > Bora Akyol wrote: > > > > > > >>>>> "David" == David Charlap writes: > > > > > > David> If you need actual QoS guarantees, or if your > > > David> switches only support L-LPSs, or if you want the two > > > David> service levels to be routed independantly, then you > > > David> need to create a separate LSP for each service level. > > > David> CR-LDP or RSVP-TE can be used for signalling the QoS > > > David> requirements for the two LSPs. > > > > > > David > > > > > > You are making assumptions about a particular switch > > > architecture when you assert that you can not do "actual" QoS > > > guarantees with E-LSPs. If you have a policer and a > > > shaper/scheduler that can process the EXP bits as well as the > > > label, then doing "actual" QoS is quite possible with > > > E-LSPs. > > > > > > Not only that, but you can map traffic destined to the same > > > prefix to different EXP levels based either on Diffserv bits or > > > on packet content. This also applies to VLAN tags. > > > > The meaning of the EXP bits is not signalled. It must be > preconfigured > > network-wide. And in order to be useful, they must be > identical across > > the entire network. Which limits you to 8 different service levels, > > network-wide. > > > > If you use the EXP bits to define a priority level and two flows are > > both assigned that level, they will be queued in best-effort fashion > > relative to each other. There is no way to guarantee the individual > > flows any particular level of service. You can only guarantee the > > aggregate of one class relative to another class. > > > > Using L-LSPs, you can request a separate label, and a > separate resource > > reservation for every flow, if needed. This is the only way to > > guarantee this level of service. (Unless you're willing to > limit each > > DS code point to a single flow, which is a ridiculous concept.) > > > > E-LSPs are useful, no doubt about that. But they can not > provide the > > level of QoS necessary to make sure that a single specific > flow can be > > guaranteed the resources it requires. > > > > -- David > > > From owner-mpls@UU.NET Wed Jan 24 12:56:47 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26582 for ; Wed, 24 Jan 2001 12:56:46 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzjr05290; Wed, 24 Jan 2001 17:54:14 GMT Received: by mail-control.mail.uu.net id QQjzjr07425 for mpls-outgoing; Wed, 24 Jan 2001 17:53:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzjr07420 for ; Wed, 24 Jan 2001 17:53:45 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 QQjzjr19958 for ; Wed, 24 Jan 2001 17:53:05 GMT Received: from EXCHANGE.kerenix.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pop04-1-ras1-p82.barak.net.il [212.150.1.82] (may be forged)) id QQjzjr15338 for ; Wed, 24 Jan 2001 17:53:04 GMT Received: by EXCHANGE.kerenix.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 19:54:25 +0200 Message-ID: <2B15221907365C468941FDFC02C87769CEAD@EXCHANGE.kerenix.com> From: Vadim Suraev To: "'mpls@UU.NET'" Subject: MPLS-OMP Date: Wed, 24 Jan 2001 19:54:24 +0200 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. Could anyone tell me about MPLS-OMP standardization & implementation (deployment) processes? How does MPLS-OMP interacts with policy-based, with forecast- and historical driven traffic patterns mapping using TE-LSPs with associated (allocated) BW ? Could anyone tell about his experience with MPLS-OMP ? Thanks. KereniX Data-Aware Optical NetworksTM ---------------------------------------------------------------------------- ------ Vadim Suraev http://www.kerenix.com Phone: +972-3-9050830 Mobile: 972-53-568711 Fax: +972-3-9347720 vadim_suraev@kerenix.com 70 Pinsker St., POB 10053, Petach-Tikva 49001 ISRAEL ---------------------------------------------------------------------------- ------ From owner-mpls@UU.NET Wed Jan 24 13:41:35 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27587 for ; Wed, 24 Jan 2001 13:41:35 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzju15119; Wed, 24 Jan 2001 18:39:42 GMT Received: by mail-control.mail.uu.net id QQjzju23809 for mpls-outgoing; Wed, 24 Jan 2001 18:39:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzju23791 for ; Wed, 24 Jan 2001 18:39: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 QQjzju06851 for ; Wed, 24 Jan 2001 18:38:35 GMT Received: from edgeflow.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.191.40.82]) id QQjzju21667 for ; Wed, 24 Jan 2001 18:38:34 GMT Received: from edgsvr01.edgeflow.edgeflow.com ([10.0.1.10]) by watchdog.edgeflow.com with ESMTP id <119041>; Wed, 24 Jan 2001 13:38:17 -0500 Received: by edgsvr01.edgeflow.edgeflow.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 13:35:24 -0500 Message-ID: <89E067900D3FA84A97495C71556140E40A1B2E@edgsvr01.edgeflow.edgeflow.com> From: Martin Dubuc To: "'mpls@UU.NET'" Subject: LMP-MIB Date: Wed, 24 Jan 2001 13:35:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I have written a MIB for the Link Management Protocol. I have submitted it earlier this week to the IETF site. You can find a copy at: http://www.ietf.org/internet-drafts/draft-dubuc-lmp-mib-00.txt Martin Dubuc edgeflow Inc. From owner-mpls@UU.NET Wed Jan 24 14:35:42 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28625 for ; Wed, 24 Jan 2001 14:35:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzjy28400; Wed, 24 Jan 2001 19:34:05 GMT Received: by mail-control.mail.uu.net id QQjzjy12189 for mpls-outgoing; Wed, 24 Jan 2001 19:33:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzjy12170 for ; Wed, 24 Jan 2001 19:33:20 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 QQjzjy03779 for ; Wed, 24 Jan 2001 19:33:04 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzjy02799 for ; Wed, 24 Jan 2001 19:33:04 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA09554 for mpls@uu.net; Wed, 24 Jan 2001 14:33:03 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzjy12115 for ; Wed, 24 Jan 2001 19:32: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 QQjzjy28497 for ; Wed, 24 Jan 2001 19:32:14 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 QQjzjy04040 for ; Wed, 24 Jan 2001 19:32:14 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA21926; Wed, 24 Jan 2001 14:31:54 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-223.cisco.com [161.44.134.223]) by bucket.cisco.com (Mirapoint) with ESMTP id ABH03758; Wed, 24 Jan 2001 14:32:12 -0500 (EST) Message-Id: <4.3.2.7.2.20010124143539.02bd3ee8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Jan 2001 14:36:37 -0500 To: "Manohar Ellanti" , "cheenu Srinivasan" , "Arun Viswanathan" , From: "Thomas D. Nadeau" Subject: Re: MPLS-TE-MIB additions (last call) In-Reply-To: <024801c0867b$f2c3ee00$1cd01318@frmt1.sfba.home.com> References: <4.3.2.7.2.20010123130518.0295b9d0@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Is anyone actually implementing the "suggested" types you note below? The MIB currently supports all of the cases you outlined below except the "suggested" ones. --Tom >How does this relate to the Traffic Engineering architecture document where >a distinction is made between include/exclude and >explicitInclude/explicitExclude. > >An explicitInclude hop list can be used to prune the graph and then run >CSPF.I think explicitExclude probably should be possible to specify using >the table you described. But I think it is not the case explicitInclude. > >I think we should have - > option of suggested include > option of explicit include (sub graph formed with include hops) > option to exclude some hops > >-Manohar > >----- Original Message ----- >From: "Thomas D. Nadeau" >To: "cheenu Srinivasan" ; "Arun Viswanathan" >; >Sent: Tuesday, January 23, 2001 10:10 AM >Subject: MPLS-TE-MIB additions (last call) > > > > > > Hi, > > > > In addition to the 4 agreed upon changes from Joan > > and Shobhan, the co-authors of the MPLS-TE-MIB have three > > objects that we would like added/modified in the existing > > MPLS-TE-MIB and thought that we would post them to > > the mailing list prior to adding them. I understand > > that last call was finished last Friday, but I > > was too busy to send these out, so I apologize. > > > > HopTable: > > > > Add an object called mplsTunnelHopExcludeAddr whose > > purpose it is to denote whether or not this hop specifies > > an 'included' or 'excluded' hop. The default is 'include', > > so the DEFVAL is false(2). > > > > mplsTunnelHopIncludeExclude OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "If this value is set to true(1), then this indicates that this > > hop MUST be included in the tunnel's path. If this value is set to > > false(2), then this hop MUST be avoided when calculating the path for this > > tunnel. The default value of this object is true(1), so that by default >all > > indicated hops are included in the CSPF path computation." > > ::= { mplsTunnelHopEntry xxx } > > > > > > mplsTunnelPathOptionName OBJECT-TYPE > > SYNTAX DisplayString > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "The description of this series of hops as they relate to the > > specified path option." > > ::= { mplsTunnelHopEntry xxx } > > > > > > > > I think that we incorrectly put this bit in the > > mplsTunnelSessionAttributes: > > > > isComputed This flag indicates whether the tunnel > > path is computed using a constraint-based routing > > algorithm based on the mplsTunnelHopTable entries. > > > > > > This bit should go on the HopEntry, and should be removed > > from the mplsTunnelSessionAttributes. If you leave the bit > > where it is, it means that *every* path in the hop table > > for a particular tunnel is either explicitly specified > > or dynamically computed. This is incorrect as you > > may want a mixture of the two. > > > > I suggest that we add an object to the tunnelHopEntry > > called tunnelHopEntryPathComputation and make it an enumeration > > like: > > > > INTEGER { dynamic(1), -- CSPF computed > > explicit(2) } -- strict hop > > > > DESCRIPTION "If this value is set to dynamic, then the > > user should only specify the source and > > destination of the path and expect that > > the CSPF will calculate the remainder of > > the path. If this value is set to explicit, > > the user should specify the entire path > > for the tunnel to take. This path may contain > > strict or loose hops." > > > > > > --Tom > > From owner-mpls@UU.NET Wed Jan 24 15:12:41 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29684 for ; Wed, 24 Jan 2001 15:12:41 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzka28529; Wed, 24 Jan 2001 20:07:09 GMT Received: by mail-control.mail.uu.net id QQjzka26732 for mpls-outgoing; Wed, 24 Jan 2001 20:06:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzka26689 for ; Wed, 24 Jan 2001 20:06: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 QQjzka26723 for ; Wed, 24 Jan 2001 20:05:45 GMT From: James_Huang@Mitel.COM Received: from Mitel.COM by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newgate.mitel.com [198.53.180.100]) id QQjzka28619 for ; Wed, 24 Jan 2001 20:05:45 GMT Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id PAA20532; Wed, 24 Jan 2001 15:03:28 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 852569DE.006E2C36 ; Wed, 24 Jan 2001 15:03:22 -0500 X-Lotus-FromDomain: MITEL To: Bora Akyol cc: mpls@UU.NET Message-ID: <852569DE.006E2AB0.00@kanmta01.software.mitel.com> Date: Wed, 24 Jan 2001 12:03:19 -0800 Subject: Re: PHP negotiation Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk From: James Huang@MITEL on 01/24/2001 12:03 PM PST Hi Bora: Maybe I did not express my concern clear enough. As you said, the LSP setup will fail when the egress LSR assigns an Implicit NULL label to the penultimate hop, if the penultinate hop does not support PHP. So there should be some negotiation mechanism in LDP or RSVP/TE such that an egress router will know not to assign an Implicit NULL label to a penultimate hop that does not support PHP. But I can not find such mechanism in the documents. -- James Huang Bora Akyol on 01/23/2001 08:24:45 PM To: James Huang/USA/Mitel@Mitel cc: mpls@UU.NET Subject: PHP negotiation You should also read the label encapsulation RFC. What happens is that the egress LSR assigns an (...) NULL label (I think it should be Implicit Null) to the penultimate hop, if penultimate hop does not support this, then LSP setup should fail. There was a LOOONG discussion on this sometime last year. Some people think this stuff is really clear. I think that it is in about three different RFCs, and someone needs to write a BCP that explains common usage and tricks that network operators that use MPLS should use. BTW, this question comes up about once a month on the list, maybe we should have an MPLS FAQ. Bora >>>>> "James" == James Huang writes: James> Hi all, The following paragraph is from Section James> 3.16. (Penultimate Hop Popping) of RFC3031. James> "Initial label distribution protocol negotiations James> MUST allow each LSR to determine whether its James> neighboring LSRS are capable of popping the label James> stack. A LSR MUST NOT request a label distribution James> peer to pop the label stack unless it is capable of James> doing so." James> However, I can not find any mechanism in James> LDP/CR-LDP or RSVP-TE to accomplish this PHP James> negotiation. James> Am I missing something here? James> -- James Huang From owner-mpls@UU.NET Wed Jan 24 15:37:06 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00200 for ; Wed, 24 Jan 2001 15:37:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzkc08529; Wed, 24 Jan 2001 20:36:13 GMT Received: by mail-control.mail.uu.net id QQjzkc29213 for mpls-outgoing; Wed, 24 Jan 2001 20:35:38 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzkc29208 for ; Wed, 24 Jan 2001 20:35:24 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 QQjzkc23524 for ; Wed, 24 Jan 2001 20:33:30 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzkc14284 for ; Wed, 24 Jan 2001 20:33:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA14888 for mpls@uu.net; Wed, 24 Jan 2001 15:33:29 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzkc29145 for ; Wed, 24 Jan 2001 20:33:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjzkc15753 for ; Wed, 24 Jan 2001 20:33:08 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjzkc04684 for ; Wed, 24 Jan 2001 20:33:08 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id MAA22915; Wed, 24 Jan 2001 12:33:03 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14959.15359.269000.802312@gargle.gargle.HOWL> Date: Wed, 24 Jan 2001 12:33:03 -0800 To: James_Huang@Mitel.COM Cc: Bora Akyol , mpls@UU.NET Subject: Re: PHP negotiation In-Reply-To: <852569DE.006E2AB0.00@kanmta01.software.mitel.com> References: <852569DE.006E2AB0.00@kanmta01.software.mitel.com> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit There is no such mechanism. The assumption is that the network operator knows how to configure their equipment and they know their network. Bora >>>>> "James" == James Huang writes: James> From: James Huang@MITEL on 01/24/2001 12:03 PM PST Hi James> Bora: Maybe I did not express my concern clear James> enough. As you said, the LSP setup will fail when James> the egress LSR assigns an Implicit NULL label to the James> penultimate hop, if the penultinate hop does not James> support PHP. So there should be some negotiation James> mechanism in LDP or RSVP/TE such that an egress James> router will know not to assign an Implicit NULL label James> to a penultimate hop that does not support PHP. But James> I can not find such mechanism in the documents. James> -- James Huang James> Bora Akyol on 01/23/2001 08:24:45 James> PM James> To: James Huang/USA/Mitel@Mitel cc: mpls@UU.NET James> Subject: PHP negotiation James> You should also read the label encapsulation James> RFC. What happens is that the egress LSR assigns an James> (...) NULL label (I think it should be Implicit Null) James> to the penultimate hop, if penultimate hop does not James> support this, then LSP setup should fail. James> There was a LOOONG discussion on this sometime last James> year. James> Some people think this stuff is really clear. I think James> that it is in about three different RFCs, and someone James> needs to write a BCP that explains common usage and James> tricks that network operators that use MPLS should James> use. James> BTW, this question comes up about once a month on the James> list, maybe we should have an MPLS FAQ. James> Bora >>>>> "James" == James Huang writes: James> Hi all, The following paragraph is from Section James> 3.16. (Penultimate Hop Popping) of RFC3031. James> "Initial label distribution protocol negotiations James> MUST allow each LSR to determine whether its James> neighboring LSRS are capable of popping the label James> stack. A LSR MUST NOT request a label distribution James> peer to pop the label stack unless it is capable of James> doing so." James> However, I can not find any mechanism in LDP/CR-LDP James> or RSVP-TE to accomplish this PHP negotiation. James> Am I missing something here? James> -- James Huang From owner-mpls@UU.NET Wed Jan 24 16:53:24 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01201 for ; Wed, 24 Jan 2001 16:53:24 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzkh25692; Wed, 24 Jan 2001 21:52:44 GMT Received: by mail-control.mail.uu.net id QQjzkh17683 for mpls-outgoing; Wed, 24 Jan 2001 21:52:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzkh17664 for ; Wed, 24 Jan 2001 21:52: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 QQjzkh01695 for ; Wed, 24 Jan 2001 21:50:56 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw01.ma.us.intelilink.net [216.57.129.34]) id QQjzkh08845 for ; Wed, 24 Jan 2001 21:50:55 GMT Received: from sandburst.com (dynamite-23.sandburst.com [172.16.5.23]) by sandmail.sandburst.com (Postfix) with ESMTP id AADD694007; Wed, 24 Jan 2001 16:50:55 -0500 (EST) Message-ID: <3A6F5C9E.F593BE8F@sandburst.com> Date: Wed, 24 Jan 2001 17:52:14 -0500 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Bora Akyol Cc: James_Huang@Mitel.COM, mpls@UU.NET Subject: Re: PHP negotiation References: <852569DE.006E2AB0.00@kanmta01.software.mitel.com> <14959.15359.269000.802312@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bora, This explanation presupposes the existence of a standard way for the knowledgeable network operator to "configure their equipment" to compensate for a mismatch in equipment models relative to PHP. To my knowledge, the only such "standard" way at present is for the knowledgeable network operator to buy compatible equipment. Did I miss something? -- Eric Gray You wrote: > There is no such mechanism. The assumption is that the network > operator knows how to configure their equipment and they know > their network. > > Bora > > >>>>> "James" == James Huang writes: > > James> From: James Huang@MITEL on 01/24/2001 12:03 PM PST Hi > James> Bora: Maybe I did not express my concern clear > James> enough. As you said, the LSP setup will fail when > James> the egress LSR assigns an Implicit NULL label to the > James> penultimate hop, if the penultinate hop does not > James> support PHP. So there should be some negotiation > James> mechanism in LDP or RSVP/TE such that an egress > James> router will know not to assign an Implicit NULL label > James> to a penultimate hop that does not support PHP. But > James> I can not find such mechanism in the documents. > > James> -- James Huang > > James> Bora Akyol on 01/23/2001 08:24:45 > James> PM > > James> To: James Huang/USA/Mitel@Mitel cc: mpls@UU.NET > > James> Subject: PHP negotiation > > James> You should also read the label encapsulation > James> RFC. What happens is that the egress LSR assigns an > James> (...) NULL label (I think it should be Implicit Null) > James> to the penultimate hop, if penultimate hop does not > James> support this, then LSP setup should fail. > > James> There was a LOOONG discussion on this sometime last > James> year. > > James> Some people think this stuff is really clear. I think > James> that it is in about three different RFCs, and someone > James> needs to write a BCP that explains common usage and > James> tricks that network operators that use MPLS should > James> use. > > James> BTW, this question comes up about once a month on the > James> list, maybe we should have an MPLS FAQ. > > James> Bora > > >>>>> "James" == James Huang writes: > > James> Hi all, The following paragraph is from Section > James> 3.16. (Penultimate Hop Popping) of RFC3031. > > James> "Initial label distribution protocol negotiations > James> MUST allow each LSR to determine whether its > James> neighboring LSRS are capable of popping the label > James> stack. A LSR MUST NOT request a label distribution > James> peer to pop the label stack unless it is capable of > James> doing so." > > James> However, I can not find any mechanism in LDP/CR-LDP > James> or RSVP-TE to accomplish this PHP negotiation. > > James> Am I missing something here? > > James> -- James Huang From owner-mpls@UU.NET Wed Jan 24 17:02:59 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01357 for ; Wed, 24 Jan 2001 17:02:59 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzki12374; Wed, 24 Jan 2001 22:02:23 GMT Received: by mail-control.mail.uu.net id QQjzki22330 for mpls-outgoing; Wed, 24 Jan 2001 22:01:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzki21940 for ; Wed, 24 Jan 2001 22:01:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzkh27860 for ; Wed, 24 Jan 2001 21:58:42 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzkh03900 for ; Wed, 24 Jan 2001 21:58:41 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA21116 for mpls@uu.net; Wed, 24 Jan 2001 16:58:41 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzkh18301 for ; Wed, 24 Jan 2001 21:57: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 QQjzkh12643 for ; Wed, 24 Jan 2001 21:55:54 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjzkh14129 for ; Wed, 24 Jan 2001 21:55:54 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA28813; Wed, 24 Jan 2001 13:55:53 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14959.20328.965000.313991@gargle.gargle.HOWL> Date: Wed, 24 Jan 2001 13:55:52 -0800 To: Eric Gray Cc: Bora Akyol , James_Huang@Mitel.COM, mpls@UU.NET Subject: Re: PHP negotiation In-Reply-To: <3A6F5C9E.F593BE8F@sandburst.com> References: <852569DE.006E2AB0.00@kanmta01.software.mitel.com> <14959.15359.269000.802312@gargle.gargle.HOWL> <3A6F5C9E.F593BE8F@sandburst.com> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit One can presume to enable or disable functionality related to PHP using CLI or MIB commands as well as centralized configuration distribution. I know of at least one ISP that uses a centralized configuration engine to control all of their routers. Bora >>>>> "Eric" == Eric Gray writes: Eric> Bora, This explanation presupposes the existence of a Eric> standard way for the knowledgeable network operator to Eric> "configure their equipment" to compensate for a Eric> mismatch in equipment models relative to PHP. To my Eric> knowledge, the only such "standard" way at present is Eric> for the knowledgeable network operator to buy Eric> compatible equipment. Did I miss something? Eric> -- Eric Gray Eric> You wrote: >> There is no such mechanism. The assumption is that the >> network operator knows how to configure their equipment >> and they know their network. >> >> Bora >> >> >>>>> "James" == James Huang >> writes: >> James> From: James Huang@MITEL on 01/24/2001 12:03 PM PST Hi James> Bora: Maybe I did not express my concern clear James> enough. As you said, the LSP setup will fail when James> the egress LSR assigns an Implicit NULL label to the James> penultimate hop, if the penultinate hop does not James> support PHP. So there should be some negotiation James> mechanism in LDP or RSVP/TE such that an egress James> router will know not to assign an Implicit NULL label James> to a penultimate hop that does not support PHP. But James> I can not find such mechanism in the documents. >> James> -- James Huang >> James> Bora Akyol on 01/23/2001 08:24:45 James> PM >> James> To: James Huang/USA/Mitel@Mitel cc: mpls@UU.NET >> James> Subject: PHP negotiation >> James> You should also read the label encapsulation James> RFC. What happens is that the egress LSR assigns an James> (...) NULL label (I think it should be Implicit Null) James> to the penultimate hop, if penultimate hop does not James> support this, then LSP setup should fail. >> James> There was a LOOONG discussion on this sometime last James> year. >> James> Some people think this stuff is really clear. I think James> that it is in about three different RFCs, and someone James> needs to write a BCP that explains common usage and James> tricks that network operators that use MPLS should James> use. >> James> BTW, this question comes up about once a month on the James> list, maybe we should have an MPLS FAQ. >> James> Bora >> >>>>> "James" == James Huang >> writes: >> James> Hi all, The following paragraph is from Section James> 3.16. (Penultimate Hop Popping) of RFC3031. >> James> "Initial label distribution protocol negotiations James> MUST allow each LSR to determine whether its James> neighboring LSRS are capable of popping the label James> stack. A LSR MUST NOT request a label distribution James> peer to pop the label stack unless it is capable of James> doing so." >> James> However, I can not find any mechanism in LDP/CR-LDP James> or RSVP-TE to accomplish this PHP negotiation. >> James> Am I missing something here? >> James> -- James Huang From owner-mpls@UU.NET Wed Jan 24 17:07:28 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01418 for ; Wed, 24 Jan 2001 17:07:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzki25620; Wed, 24 Jan 2001 22:06:35 GMT Received: by mail-control.mail.uu.net id QQjzki29173 for mpls-outgoing; Wed, 24 Jan 2001 22:06:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzki29107 for ; Wed, 24 Jan 2001 22:06: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 QQjzki25079 for ; Wed, 24 Jan 2001 22:04:59 GMT Received: from merlin.prod.itd.earthlink.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: merlin.prod.itd.earthlink.net [207.217.120.156]) id QQjzki18733 for ; Wed, 24 Jan 2001 22:04:59 GMT Received: from optic3.ipoptical.com (dialup-166.90.28.207.Washington1.Level3.net [166.90.28.207]) by merlin.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id OAA08886; Wed, 24 Jan 2001 14:04:52 -0800 (PST) Received: by optic3.ipoptical.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jan 2001 17:03:38 -0500 Message-ID: From: Alex Mondrus To: "'Vadim Suraev'" , "'mpls@UU.NET'" Subject: RE: MPLS-OMP Date: Wed, 24 Jan 2001 17:03:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I would like to know more about it too. It was a very interesting proposal. Alex Mondrus http://www.ipoptical.com -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Vadim Suraev Sent: Wednesday, January 24, 2001 12:54 PM To: 'mpls@UU.NET' Subject: MPLS-OMP Hi. Could anyone tell me about MPLS-OMP standardization & implementation (deployment) processes? How does MPLS-OMP interacts with policy-based, with forecast- and historical driven traffic patterns mapping using TE-LSPs with associated (allocated) BW ? Could anyone tell about his experience with MPLS-OMP ? Thanks. KereniX Data-Aware Optical NetworksTM ---------------------------------------------------------------------------- ------ Vadim Suraev http://www.kerenix.com Phone: +972-3-9050830 Mobile: 972-53-568711 Fax: +972-3-9347720 vadim_suraev@kerenix.com 70 Pinsker St., POB 10053, Petach-Tikva 49001 ISRAEL ---------------------------------------------------------------------------- ------ From owner-mpls@UU.NET Wed Jan 24 17:08:57 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01438 for ; Wed, 24 Jan 2001 17:08:56 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzki28152; Wed, 24 Jan 2001 22:08:33 GMT Received: by mail-control.mail.uu.net id QQjzki00915 for mpls-outgoing; Wed, 24 Jan 2001 22:07:56 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzki00599 for ; Wed, 24 Jan 2001 22:07: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 QQjzki29182 for ; Wed, 24 Jan 2001 22:06:44 GMT From: James_Huang@Mitel.COM Received: from Mitel.COM by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: newgate.mitel.com [198.53.180.100]) id QQjzki25886 for ; Wed, 24 Jan 2001 22:06:44 GMT Received: from kanmta01.software.mitel.com (kanmta01 [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id RAA04311; Wed, 24 Jan 2001 17:06:42 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 852569DE.00797540 ; Wed, 24 Jan 2001 17:06:38 -0500 X-Lotus-FromDomain: MITEL To: Bora Akyol cc: mpls@UU.NET Message-ID: <852569DE.0079738F.00@kanmta01.software.mitel.com> Date: Wed, 24 Jan 2001 14:06:34 -0800 Subject: Re: PHP negotiation Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk From: James Huang@MITEL on 01/24/2001 02:06 PM PST I found in sec 6 of RFC 3036 that PHP negotiation is an area of future study for LDP. Is it also an area of future study for RSVP-TE? Before this negotiation mechanism becomes available, I presume we can only reply on manual configuration on a per peer basis. -- James Huang Bora Akyol on 01/24/2001 12:33:03 PM To: James Huang/USA/Mitel@Mitel cc: Bora Akyol , mpls@UU.NET Subject: Re: PHP negotiation There is no such mechanism. The assumption is that the network operator knows how to configure their equipment and they know their network. Bora >>>>> "James" == James Huang writes: James> From: James Huang@MITEL on 01/24/2001 12:03 PM PST Hi James> Bora: Maybe I did not express my concern clear James> enough. As you said, the LSP setup will fail when James> the egress LSR assigns an Implicit NULL label to the James> penultimate hop, if the penultinate hop does not James> support PHP. So there should be some negotiation James> mechanism in LDP or RSVP/TE such that an egress James> router will know not to assign an Implicit NULL label James> to a penultimate hop that does not support PHP. But James> I can not find such mechanism in the documents. James> -- James Huang James> Bora Akyol on 01/23/2001 08:24:45 James> PM James> To: James Huang/USA/Mitel@Mitel cc: mpls@UU.NET James> Subject: PHP negotiation James> You should also read the label encapsulation James> RFC. What happens is that the egress LSR assigns an James> (...) NULL label (I think it should be Implicit Null) James> to the penultimate hop, if penultimate hop does not James> support this, then LSP setup should fail. James> There was a LOOONG discussion on this sometime last James> year. James> Some people think this stuff is really clear. I think James> that it is in about three different RFCs, and someone James> needs to write a BCP that explains common usage and James> tricks that network operators that use MPLS should James> use. James> BTW, this question comes up about once a month on the James> list, maybe we should have an MPLS FAQ. James> Bora >>>>> "James" == James Huang writes: James> Hi all, The following paragraph is from Section James> 3.16. (Penultimate Hop Popping) of RFC3031. James> "Initial label distribution protocol negotiations James> MUST allow each LSR to determine whether its James> neighboring LSRS are capable of popping the label James> stack. A LSR MUST NOT request a label distribution James> peer to pop the label stack unless it is capable of James> doing so." James> However, I can not find any mechanism in LDP/CR-LDP James> or RSVP-TE to accomplish this PHP negotiation. James> Am I missing something here? James> -- James Huang From owner-mpls@UU.NET Wed Jan 24 20:15:10 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03039 for ; Wed, 24 Jan 2001 20:15:10 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzku12971; Thu, 25 Jan 2001 01:14:36 GMT Received: by mail-control.mail.uu.net id QQjzku23790 for mpls-outgoing; Thu, 25 Jan 2001 01:14:04 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzku23785 for ; Thu, 25 Jan 2001 01:13:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzku09066 for ; Thu, 25 Jan 2001 01:12:12 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzku29147 for ; Thu, 25 Jan 2001 01:12:11 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA01245 for mpls@uu.net; Wed, 24 Jan 2001 20:12:11 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzku23690 for ; Thu, 25 Jan 2001 01:11: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 QQjzku14852 for ; Thu, 25 Jan 2001 01:11:26 GMT Received: from soran.bos.ascend.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: soran.bos.ascend.com [152.148.40.24]) id QQjzku06715 for ; Thu, 25 Jan 2001 01:11:26 GMT Received: from ma8117ewoo ([152.148.92.241]) by soran.bos.ascend.com (8.9.3/8.9.3) with SMTP id UAA26110; Wed, 24 Jan 2001 20:05:56 -0500 (EST) From: "Ed Woo" To: , , Subject: RE: MPLS OAM? Date: Wed, 24 Jan 2001 20:11:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Neil, I'd also like to receive a copy. Thanks. Ed Woo Lucent Technologies -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of neil.2.harrison@bt.com Sent: Tuesday, January 23, 2001 3:32 AM To: fabio@infocom.uniroma1.it; mpls@UU.NET Subject: RE: MPLS OAM? Fabio....A few people have asked why I have not posted the stuff directly back to the mailing list so I think I had better briefly answer here in case I get any further enquiries: I started this last year based on the experiences (bad ones) with OAM for ATM....so, based on that history (ie I.610 reality vs I.356 wish-list), I tried to correct the main flaws and get a *simple* OAM spec that does what we operators want, ie can detect all failures modes and measure availability. Since then Shahram Davari (PMC Sierra), Peter Willis (BT Labs) and Ben MackCrane (Tellabs) have been steadily refining the work with me (other have chipped in from time time to we are the main divers). We were going to submit an ID last year but 2 things happened: 1 The ITU started to work on this area formally....so I had to direct attention to this to make sure they saw our ideas and to try to keep the 2 fora in sync. 2 GMPLS/OTN issues have taken quite a slice of my personal time over the last few months. I presented the basic ideas to the Nov 01 SG13 mtg.....they were all accepted and a draft Rec Y.17oam produced. Since then Shahram/Ben/Peter/I have been working on the outstanding issues. However, since this is ITU focused at present and the work is in MS Word format that is why I did not send this to the list directly...and so I have been responding to requests to see this (quite a lot surprisngly) on a personal basis. I will wait another day or so to see how many other requests come in and then mail shot whoever else asks for it. Once I get ITU sorted I will re-focus on getting suitable ID together and issued. Hope that explains the situation. Regards, Neil > -----Original Message----- > From: Fabio Ricciato [mailto:fabio@infocom.uniroma1.it] > Sent: 23 January 2001 08:14 > To: neil.2.harrison@bt.com; mpls@UU.NET > Subject: Re: MPLS OAM? > > > Hi, > I (silently) follow this mailing list. > I'm also intersted in the MPLS OAM and would like to be > included in the > distribution list about that. > > Anyway I guess OAM is an interesting topic for most of MPLS-involved > people, thus it's fine if discussion and/or reference distribution > continue on the mailing list. > > best regards > > fabio ricciato > From owner-mpls@UU.NET Wed Jan 24 20:40:06 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03298 for ; Wed, 24 Jan 2001 20:40:06 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzjy03694; Wed, 24 Jan 2001 19:32:03 GMT Received: by mail-control.mail.uu.net id QQjzjy12046 for mpls-outgoing; Wed, 24 Jan 2001 19:31:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzjy12040 for ; Wed, 24 Jan 2001 19:31: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 QQjzjy24069 for ; Wed, 24 Jan 2001 19:30:39 GMT Received: from exchsrv1.cosinecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.cosinecom.com [63.88.104.16]) id QQjzjy21928 for ; Wed, 24 Jan 2001 19:30:39 GMT Received: by exchsrv1.cosinecom.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 11:28:21 -0800 Message-ID: <7EB7C6B62C4FD41196A80090279A2911D8AB9A@exchsrv1.cosinecom.com> From: Jay Wang To: "'Jim Boyle'" , David Charlap Cc: mpls@UU.NET Subject: RE: QoS and Labels: A question ?? Date: Wed, 24 Jan 2001 11:28:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0863B.CF47B730" 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_01C0863B.CF47B730 Content-Type: text/plain; charset="iso-8859-1" Jim, > -----Original Message----- > From: Jim Boyle [mailto:jboyle@Level3.net] > Sent: Wednesday, January 24, 2001 8:13 AM > To: David Charlap > Cc: mpls@UU.NET > Subject: Re: QoS and Labels: A question ?? > > > > > That is the difference between diffserv and intserv, I > believe. Diffserv doesn't aim to give hard guarentees to individual flows. > Diffserv, and "E-LSPs", work. > I would not compare Intserv and Diffserv like that. I think the idea of Diffserv is to provides the needed transport, on an aggregated basis (for better scalability of course), to achieve services that are specified by Intserv model (not exclusively of course). Even the Diffserv paradigm is built upon PHB and aggregation concepts, it is still possible (and very feasible) to achieve per-flow QoS guarantee. - Jay > Jim > > > On Wed, 24 Jan 2001, David Charlap wrote: > > > Bora Akyol wrote: > > > > > > >>>>> "David" == David Charlap writes: > > > > > > David> If you need actual QoS guarantees, or if your > > > David> switches only support L-LPSs, or if you want the two > > > David> service levels to be routed independantly, then you > > > David> need to create a separate LSP for each service level. > > > David> CR-LDP or RSVP-TE can be used for signalling the QoS > > > David> requirements for the two LSPs. > > > > > > David > > > > > > You are making assumptions about a particular switch > > > architecture when you assert that you can not do "actual" QoS > > > guarantees with E-LSPs. If you have a policer and a > > > shaper/scheduler that can process the EXP bits as well as the > > > label, then doing "actual" QoS is quite possible with > > > E-LSPs. > > > > > > Not only that, but you can map traffic destined to the same > > > prefix to different EXP levels based either on Diffserv bits or > > > on packet content. This also applies to VLAN tags. > > > > The meaning of the EXP bits is not signalled. It must be > preconfigured > > network-wide. And in order to be useful, they must be > identical across > > the entire network. Which limits you to 8 different service levels, > > network-wide. > > > > If you use the EXP bits to define a priority level and two flows are > > both assigned that level, they will be queued in best-effort fashion > > relative to each other. There is no way to guarantee the individual > > flows any particular level of service. You can only guarantee the > > aggregate of one class relative to another class. > > > > Using L-LSPs, you can request a separate label, and a > separate resource > > reservation for every flow, if needed. This is the only way to > > guarantee this level of service. (Unless you're willing to > limit each > > DS code point to a single flow, which is a ridiculous concept.) > > > > E-LSPs are useful, no doubt about that. But they can not > provide the > > level of QoS necessary to make sure that a single specific > flow can be > > guaranteed the resources it requires. > > > > -- David > > > ------_=_NextPart_001_01C0863B.CF47B730 Content-Type: text/html; charset="iso-8859-1" RE: QoS and Labels: A question ??

Jim,


> -----Original Message-----
> From: Jim Boyle [mailto:jboyle@Level3.net]
> Sent: Wednesday, January 24, 2001 8:13 AM
> To: David Charlap
> Cc: mpls@UU.NET
> Subject: Re: QoS and Labels: A question ??
>
>
>
>
> That is the difference between diffserv and intserv, I
> believe. Diffserv doesn't aim to give hard guarentees to individual flows. 
> Diffserv, and "E-LSPs", work.
>

I would not compare Intserv and Diffserv like that. I think the idea of Diffserv
is to provides the needed transport, on an aggregated basis (for better scalability
of course), to achieve services that are specified by Intserv model (not exclusively
of course). Even the Diffserv paradigm is built upon PHB and aggregation concepts,
it is still possible (and very feasible) to achieve per-flow QoS guarantee.

- Jay

> Jim
>
>
> On Wed, 24 Jan 2001, David Charlap wrote:
>
> > Bora Akyol wrote:
> > >
> > > >>>>> "David" == David Charlap <david.charlap@marconi.com> writes:
> > >
> > >     David> If you need actual QoS guarantees, or if your
> > >     David> switches only support L-LPSs, or if you want the two
> > >     David> service levels to be routed independantly, then you
> > >     David> need to create a separate LSP for each service level.
> > >     David> CR-LDP or RSVP-TE can be used for signalling the QoS
> > >     David> requirements for the two LSPs.
> > >
> > > David
> > >
> > > You are making assumptions about a particular switch
> > > architecture when you assert that you can not do "actual" QoS
> > > guarantees with E-LSPs. If you have a policer and a
> > > shaper/scheduler that can process the EXP bits as well as the
> > > label, then doing "actual" QoS is quite possible with
> > > E-LSPs.
> > >
> > > Not only that, but you can map traffic destined to the same
> > > prefix to different EXP levels based either on Diffserv bits or
> > > on packet content. This also applies to VLAN tags.
> >
> > The meaning of the EXP bits is not signalled.  It must be
> preconfigured
> > network-wide.  And in order to be useful, they must be
> identical across
> > the entire network.  Which limits you to 8 different service levels,
> > network-wide.
> >
> > If you use the EXP bits to define a priority level and two flows are
> > both assigned that level, they will be queued in best-effort fashion
> > relative to each other.  There is no way to guarantee the individual
> > flows any particular level of service.  You can only guarantee the
> > aggregate of one class relative to another class.
> >
> > Using L-LSPs, you can request a separate label, and a
> separate resource
> > reservation for every flow, if needed.  This is the only way to
> > guarantee this level of service.  (Unless you're willing to
> limit each
> > DS code point to a single flow, which is a ridiculous concept.)
> >
> > E-LSPs are useful, no doubt about that.  But they can not
> provide the
> > level of QoS necessary to make sure that a single specific
> flow can be
> > guaranteed the resources it requires.
> >
> > -- David
> >
>

------_=_NextPart_001_01C0863B.CF47B730-- From owner-mpls@UU.NET Wed Jan 24 23:23:47 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06820 for ; Wed, 24 Jan 2001 23:23:47 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzlh04596; Thu, 25 Jan 2001 04:23:18 GMT Received: by mail-control.mail.uu.net id QQjzlh11897 for mpls-outgoing; Thu, 25 Jan 2001 04:23:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzlh11888 for ; Thu, 25 Jan 2001 04:22:53 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 QQjzlh21446 for ; Thu, 25 Jan 2001 04:22:01 GMT Received: from samar.sasi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: samar.sasken.com [164.164.56.2]) id QQjzlh03231 for ; Thu, 25 Jan 2001 04:21:54 GMT Received: from samar (samar.sasi.com [164.164.56.2]) by samar.sasi.com (8.9.3/8.9.3) with SMTP id JAA23312; Thu, 25 Jan 2001 09:51:18 +0530 (IST) Received: from suns3.sasi.com ([10.0.36.3]) by samar.sasi.com; Thu, 25 Jan 2001 09:51:17 +0000 (IST) Received: from localhost (soumen@localhost) by suns3.sasi.com (8.9.3/8.9.3) with ESMTP id JAA25508; Thu, 25 Jan 2001 09:51:17 +0530 (IST) Date: Thu, 25 Jan 2001 09:51:17 +0530 (IST) From: Soumen Sarkar To: "Thomas D. Nadeau" cc: Jim Boyle , cheenu Srinivasan , Arun Viswanathan , "Cucchiara, Joan" , Subject: Re: MPLS-TE-MIB additions (last call) In-Reply-To: <3A6F07CF.CC7D7E72@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Wed, 24 Jan 2001, Shobhan Lakkapragada wrote: > Subject: Re: MPLS-TE-MIB additions (last call) > > > Tom, > > I agree that Option 1 below is a good way of adding them. > > But I feel it is more appropriate to keep the new objects in the > same table. Reason being that CR-LDP implementations would > use the already existing objects Max Rate, Mean Rate and > Max Burst Rate for configuring CR-LDP parameters Peak Date rate, > Committed rate and Peak Burst size. > > If the new objects are in separate table, then the required > CR-LDP TE parameters will be spread across two different > tables. I guess there is nothing wrong with it, but it just looks > cleaner if they are all in same table. > > - shobhan > Tom and Shobhan, We have quite a lot of instances where a second table is introduced as an extension of first table. As a matter of fact this only makes the organisation neater. -regards, Soumen > > > "Thomas D. Nadeau" wrote: > > > > > In addition to the 4 agreed upon changes from Joan > > > > and Shobhan, the co-authors of the MPLS-TE-MIB have three > > > > > >I counted 3 folks that agreed and 0 that objected, not a preponderance of > > >support, but I suppose it'll do. > > > > Jim, > > > > I think that the consensus was 6 in favor and no > > objections to add these objects. That seems to be a consensus > > to add these objects to the MIB. What is unclear is whether > > or not we should make these objects optional if the > > mplsTunnelSignallingProto variable is not set to > > crldp(3) (or the agent does not support CR-LDP altogether) > > for a particular tunnel entry. Let me outline the two options > > for this and the associated pros and cons. > > > > 1: Add the objects as optional iff CR-LDP is not implemented. > > > > The advantage here is that if the implementation > > does not support CR-LDP, it can save itself some memory > > and effort. The advantage to the operator is that > > when it scans the table, the agent will > > simply not return these objects. The operator can also find > > this out through an agent capabilities statement. > > The disadvantage as Jim points out, is that it makes > > these 4 objects optional on a signaling protocol basis, so > > some rows in the table may support these 4 columns, and others > > may not. > > > > 2: Add the options, but make them mandatory for all > > implementations. > > > > This is certainly possible, but when an implementation does > > not support CR-LDP, the agent MUST ignore these values > > during SET operations, and MUST return 0 for the values > > at all times. One of the variables can under normal > > circumstances, > > contain the value of 0, which can be confusing unless we state > > that clearly in the fine print. In my opinion, this is more > > confusing for the operator, since there are now variables > > which > > return values when queried, yet are meaningless if CR-LDP is > > not implemented. The operator may not know this until > > after they > > have read over the documentation (or the agent capabilities > > statement), whereas in the first case, they will simply not > > be returned upon a query. > > > > My personal opinion is to use option 1, but I will leave it up > > to the list to decide this one. > > > > --Tom > From owner-mpls@UU.NET Thu Jan 25 01:05:34 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08144 for ; Thu, 25 Jan 2001 01:05:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzlo24723; Thu, 25 Jan 2001 06:05:12 GMT Received: by mail-control.mail.uu.net id QQjzlo11764 for mpls-outgoing; Thu, 25 Jan 2001 06:04:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzlo11752 for ; Thu, 25 Jan 2001 06:04:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzlo18598 for ; Thu, 25 Jan 2001 06:04:20 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjzlo23273 for ; Thu, 25 Jan 2001 06:04:18 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 25 Jan 2001 11:39:20 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f0PBbDU08869; Thu, 25 Jan 2001 17:07:13 +0530 Reply-To: From: "Manikantan S" To: "'Thomas D. Nadeau'" , "'Cucchiara, Joan'" Cc: , , , Subject: RE: Last call on MPLS TE MIB Date: Thu, 25 Jan 2001 10:50:28 +0530 Message-Id: <000001c08692$c4b02800$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.3.2.7.2.20010124113639.02ad9ea0@bucket.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Joan, Thomas I have an another observation/suggestion with respect to the CRLSP support. This is with respect to the ER Hop that is configured to be of type LSPID. Currently we have support to configure the LSPID value via the MIB object "mplsTunnelHopLspId" and the have the MIB object "mplsTunnelHopAddrType" set to value "lspid". For a ER Hop Type of LSPID, the Ingress LSR Router ID value is also required. Can we add an object to facilitate this configuration? (We have added this to our enterprises MIB to support LSPID ER hop types). The SMI for the object can be as follows. mplsTunnelHopIngressRouterId MplsLsrId mplsTunnelHopIngressRouterId OBJECT-TYPE SYNTAX MplsLsrId MAX-ACCESS read-create STATUS current DESCRIPTION "If mplsTunnelHopAddrType is set to lspid(4), then this value will contain the IPv4 address of the Ingress Router ID of the Tunnel. This object is otherwise insignificant and should contain a value of 0." NOTE: The suggestion made is for IPv4 Address alone here, since the LSPID TLV currently supports IPv4 address type only. Thanks in advance with best regards mani ----------------------------------------- S.Manikantan Future Software Limited 480-481, Anna Salai, Nandanam, Chennai, India. Zip (PIN CODE) : 600 035 Phone : 91-44-4330550 Fax : 91-44-4344157 email : manis@future.futsoft.com ----------------------------------------- From owner-mpls@UU.NET Thu Jan 25 01:09:39 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08584 for ; Thu, 25 Jan 2001 01:09:39 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzlo20415; Thu, 25 Jan 2001 06:09:05 GMT Received: by mail-control.mail.uu.net id QQjzlo12216 for mpls-outgoing; Thu, 25 Jan 2001 06:08:41 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzlo12211 for ; Thu, 25 Jan 2001 06:08:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzlo23590 for ; Thu, 25 Jan 2001 06:07:56 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjzlo27137 for ; Thu, 25 Jan 2001 06:07:55 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 25 Jan 2001 11:43:05 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f0PBf0U08970; Thu, 25 Jan 2001 17:11:00 +0530 Reply-To: From: "Manikantan S" To: "'Thomas D. Nadeau'" , "'Cucchiara, Joan'" Cc: , , , Subject: RE: Last call on MPLS TE MIB Date: Thu, 25 Jan 2001 11:24:35 +0530 Message-Id: <000301c08693$4c49e6c0$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4.3.2.7.2.20010124113639.02ad9ea0@bucket.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Joan, Thomas I have an another observation/suggestion with respect to the CRLSP support. This is with respect to the ER Hop that is configured to be of type LSPID. Currently we have support to configure the LSPID value via the MIB object "mplsTunnelHopLspId" and the have the MIB object "mplsTunnelHopAddrType" set to value "lspid". For a ER Hop Type of LSPID, the Ingress LSR Router ID value is also required. Can we add an object to facilitate this configuration? (We have added this to our enterprises MIB to support LSPID ER hop types). The SMI for the object can be as follows. mplsTunnelHopIngressRouterId MplsLsrId mplsTunnelHopIngressRouterId OBJECT-TYPE SYNTAX MplsLsrId MAX-ACCESS read-create STATUS current DESCRIPTION "If mplsTunnelHopAddrType is set to lspid(4), then this value will contain the IPv4 address of the Ingress Router ID of the Tunnel. This object is otherwise insignificant and should contain a value of 0." NOTE: The suggestion made is for IPv4 Address alone here, since the LSPID TLV currently supports IPv4 address type only. Thanks in advance with best regards mani ----------------------------------------- S.Manikantan Future Software Limited 480-481, Anna Salai, Nandanam, Chennai, India. Zip (PIN CODE) : 600 035 Phone : 91-44-4330550 Fax : 91-44-4344157 email : manis@future.futsoft.com ----------------------------------------- From owner-mpls@UU.NET Thu Jan 25 02:24:32 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21587 for ; Thu, 25 Jan 2001 02:24:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzlt15262; Thu, 25 Jan 2001 07:23:52 GMT Received: by mail-control.mail.uu.net id QQjzlt28715 for mpls-outgoing; Thu, 25 Jan 2001 07:23:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzlt28710 for ; Thu, 25 Jan 2001 07:23:19 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 QQjzlt25961 for ; Thu, 25 Jan 2001 07:22:41 GMT Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQjzlt13333 for ; Thu, 25 Jan 2001 07:22:40 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f0P7LvT25898; Thu, 25 Jan 2001 08:21:57 +0100 (MET) Received: from alcatel.be ([138.203.253.215]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569DF.00286EB8; Thu, 25 Jan 2001 08:21:38 +0100 Message-ID: <3A6FD2C5.4FF1E92B@alcatel.be> Date: Thu, 25 Jan 2001 08:16:21 +0100 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.7 [nl] (Win98; U) X-Accept-Language: nl MIME-Version: 1.0 To: neil.2.harrison@bt.com CC: Ed Woo , fabio@infocom.uniroma1.it, mpls@UU.NET Subject: Re: MPLS OAM? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Neil, Could you also get me a copy? Thanks. Francis. ----------------- Ed Woo schreef: > Neil, I'd also like to receive a copy. Thanks. > > Ed Woo > Lucent Technologies > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > neil.2.harrison@bt.com > Sent: Tuesday, January 23, 2001 3:32 AM > To: fabio@infocom.uniroma1.it; mpls@UU.NET > Subject: RE: MPLS OAM? > > Fabio....A few people have asked why I have not posted the stuff directly > back to the mailing list so I think I had better briefly answer here in case > I get any further enquiries: > > I started this last year based on the experiences (bad ones) with OAM for > ATM....so, based on that history (ie I.610 reality vs I.356 > wish-list), I tried to correct the main flaws and get a *simple* OAM spec > that does what we operators want, ie can detect all failures modes and > measure availability. Since then Shahram Davari (PMC Sierra), Peter Willis > (BT Labs) and Ben MackCrane (Tellabs) have been steadily refining the work > with > me (other have chipped in from time time to we are the main divers). > > We were going to submit an ID last year but 2 things happened: > 1 The ITU started to work on this area formally....so I had to direct > attention to this to make sure they saw our ideas and to try to keep the 2 > fora in sync. > 2 GMPLS/OTN issues have taken quite a slice of my personal time over > the last few months. > > I presented the basic ideas to the Nov 01 SG13 mtg.....they were all > accepted and a draft Rec Y.17oam produced. Since then Shahram/Ben/Peter/I > have been working on the outstanding issues. However, since this is ITU > focused at present and the work is in MS Word format that is why I did not > send this to the list directly...and so I have been responding to requests > to see this (quite a lot surprisngly) on a personal basis. I will wait > another day or so to see how many other requests come in and then mail shot > whoever else asks for it. > > Once I get ITU sorted I will re-focus on getting suitable ID together and > issued. > > Hope that explains the situation. > > Regards, Neil > > > -----Original Message----- > > From: Fabio Ricciato [mailto:fabio@infocom.uniroma1.it] > > Sent: 23 January 2001 08:14 > > To: neil.2.harrison@bt.com; mpls@UU.NET > > Subject: Re: MPLS OAM? > > > > > > Hi, > > I (silently) follow this mailing list. > > I'm also intersted in the MPLS OAM and would like to be > > included in the > > distribution list about that. > > > > Anyway I guess OAM is an interesting topic for most of MPLS-involved > > people, thus it's fine if discussion and/or reference distribution > > continue on the mailing list. > > > > best regards > > > > fabio ricciato > > From owner-mpls@UU.NET Thu Jan 25 02:49:08 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21866 for ; Thu, 25 Jan 2001 02:49:03 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzlv24991; Thu, 25 Jan 2001 07:48:28 GMT Received: by mail-control.mail.uu.net id QQjzlv00512 for mpls-outgoing; Thu, 25 Jan 2001 07:47:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzlv00507 for ; Thu, 25 Jan 2001 07:47:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjzlv20597 for ; Thu, 25 Jan 2001 07:47:23 GMT Received: from relay1.alcatel.be by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQjzlv08472 for ; Thu, 25 Jan 2001 07:47:22 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f0P7lLL00321 for ; Thu, 25 Jan 2001 08:47:21 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569DF.002AC4EA; Thu, 25 Jan 2001 08:47:09 +0100 Message-ID: <3A6F0042.5CCFB14D@alcatel.be> Date: Wed, 24 Jan 2001 17:18:10 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: [Fwd: I-D ACTION:draft-ietf-mpls-multicast-05.txt] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit after the last call on version 04, following changes were made in version 05: -added RPT and SPT in list of abbreviations -removed section 3.8 on RPF -updated section 7 -updated references dirk 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-05.txt Pages : 28 Date : 23-Jan-01 This document offers a framework for IP multicast deployment in an MPLS environment. Issues arising when MPLS techniques are applied to IP multicast are overviewed. The pros and cons of existing IP multicast routing protocols in the context of MPLS are described and the relation to the different trigger methods and label distribution modes are discussed. The consequences of various layer 2 (L2) technologies are listed. Both point-to-point and multi-access networks are considered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-multicast-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-multicast-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-multicast-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: <20010123115408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-multicast-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-multicast-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010123115408.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu Jan 25 07:53:27 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24719 for ; Thu, 25 Jan 2001 07:53:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzmp28326; Thu, 25 Jan 2001 12:52:58 GMT Received: by mail-control.mail.uu.net id QQjzmp18205 for mpls-outgoing; Thu, 25 Jan 2001 12:52:27 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzmp18200 for ; Thu, 25 Jan 2001 12:52:24 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 QQjzmp11590 for ; Thu, 25 Jan 2001 12:51:54 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzmp21334 for ; Thu, 25 Jan 2001 12:51:53 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA28924 for mpls@uu.net; Thu, 25 Jan 2001 07:51:53 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzmp18157 for ; Thu, 25 Jan 2001 12:51:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzmp20801 for ; Thu, 25 Jan 2001 12:51:14 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 QQjzmp25370 for ; Thu, 25 Jan 2001 12:51:14 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA13016; Thu, 25 Jan 2001 07:50:48 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABH10883; Thu, 25 Jan 2001 07:51:06 -0500 (EST) Message-Id: <4.3.2.7.2.20010125075421.02b97008@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jan 2001 07:55:33 -0500 To: , "'Cucchiara, Joan'" From: "Thomas D. Nadeau" Subject: RE: Last call on MPLS TE MIB Cc: , , , In-Reply-To: <000001c08692$c4b02800$1006000a@future.futsoft.com> References: <4.3.2.7.2.20010124113639.02ad9ea0@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk What is wrong with just using the mplsTunnelHopIpv4Addr or mplsTunnelHopIpv6Addr which are on the Hop entry already? I would prefer not to add another object if there are others which you can reuse. --Tom >I have an another observation/suggestion with respect to the >CRLSP support. > >This is with respect to the ER Hop that is configured to be of >type LSPID. Currently we have support to configure the LSPID >value via the MIB object "mplsTunnelHopLspId" and the >have the MIB object "mplsTunnelHopAddrType" set to value "lspid". > >For a ER Hop Type of LSPID, the Ingress LSR Router ID value is >also required. > >Can we add an object to facilitate this configuration? >(We have added this to our enterprises MIB to support LSPID ER hop >types). > >The SMI for the object can be as follows. > >mplsTunnelHopIngressRouterId MplsLsrId > >mplsTunnelHopIngressRouterId OBJECT-TYPE > SYNTAX MplsLsrId > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "If mplsTunnelHopAddrType is set to lspid(4), then > this value will contain the IPv4 address of the > Ingress Router ID of the Tunnel. This object is > otherwise insignificant and should contain a > value of 0." > >NOTE: The suggestion made is for IPv4 Address alone here, since >the LSPID TLV currently supports IPv4 address type only. > >Thanks in advance >with best regards >mani >----------------------------------------- >S.Manikantan >Future Software Limited >480-481, Anna Salai, >Nandanam, Chennai, India. >Zip (PIN CODE) : 600 035 >Phone : 91-44-4330550 >Fax : 91-44-4344157 >email : manis@future.futsoft.com >----------------------------------------- From owner-mpls@UU.NET Thu Jan 25 07:58:33 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24863 for ; Thu, 25 Jan 2001 07:58:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzmp00935; Thu, 25 Jan 2001 12:58:00 GMT Received: by mail-control.mail.uu.net id QQjzmp18518 for mpls-outgoing; Thu, 25 Jan 2001 12:57:34 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzmp18512 for ; Thu, 25 Jan 2001 12:57:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjzmp08087 for ; Thu, 25 Jan 2001 12:56:55 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzmp28939 for ; Thu, 25 Jan 2001 12:56:55 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA29466 for mpls@uu.net; Thu, 25 Jan 2001 07:56:54 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzmp18428 for ; Thu, 25 Jan 2001 12:56:19 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 QQjzmp02165 for ; Thu, 25 Jan 2001 12:54:46 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 QQjzmp01579 for ; Thu, 25 Jan 2001 12:54:46 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA13105; Thu, 25 Jan 2001 07:54:24 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABH10909; Thu, 25 Jan 2001 07:54:42 -0500 (EST) Message-Id: <4.3.2.7.2.20010125075718.02a74ef8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jan 2001 07:59:10 -0500 To: , "'Cucchiara, Joan'" From: "Thomas D. Nadeau" Subject: RE: Last call on MPLS TE MIB Cc: , , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Let me be a little more precise with my last statement regarding this proposed addition. Why don't we just re-use the mplsTunnelHopIpv4Addr, and if the value is set to lspid, modify the description of the hopAddrType slightly to allow the mplsTunnelHopIpv4Addr or mplsTunnelHopIpv6Addr to be set as well in this case? --Tom >I have an another observation/suggestion with respect to the >CRLSP support. > >This is with respect to the ER Hop that is configured to be of >type LSPID. Currently we have support to configure the LSPID >value via the MIB object "mplsTunnelHopLspId" and the >have the MIB object "mplsTunnelHopAddrType" set to value "lspid". > >For a ER Hop Type of LSPID, the Ingress LSR Router ID value is >also required. > >Can we add an object to facilitate this configuration? >(We have added this to our enterprises MIB to support LSPID ER hop >types). > >The SMI for the object can be as follows. > >mplsTunnelHopIngressRouterId MplsLsrId > >mplsTunnelHopIngressRouterId OBJECT-TYPE > SYNTAX MplsLsrId > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "If mplsTunnelHopAddrType is set to lspid(4), then > this value will contain the IPv4 address of the > Ingress Router ID of the Tunnel. This object is > otherwise insignificant and should contain a > value of 0." > >NOTE: The suggestion made is for IPv4 Address alone here, since >the LSPID TLV currently supports IPv4 address type only. > >Thanks in advance >with best regards >mani >----------------------------------------- >S.Manikantan >Future Software Limited >480-481, Anna Salai, >Nandanam, Chennai, India. >Zip (PIN CODE) : 600 035 >Phone : 91-44-4330550 >Fax : 91-44-4344157 >email : manis@future.futsoft.com >----------------------------------------- From owner-mpls@UU.NET Thu Jan 25 08:08:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25046 for ; Thu, 25 Jan 2001 08:08:33 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzmq23328; Thu, 25 Jan 2001 13:07:51 GMT Received: by mail-control.mail.uu.net id QQjzmq00785 for mpls-outgoing; Thu, 25 Jan 2001 13:07:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzmq00777 for ; Thu, 25 Jan 2001 13:07:16 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 QQjzmq23555 for ; Thu, 25 Jan 2001 13:06:03 GMT From: emildrottar@auranetinc.com Received: from tardis.lancast.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tardis.lancast.com [12.25.4.9]) id QQjzmq09476 for ; Thu, 25 Jan 2001 13:06:03 GMT Received: by TARDIS with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Jan 2001 08:07:35 -0500 Message-ID: <6FBF00711D96D31193EA009027D5E5CE743ABC@TARDIS> To: neil.2.harrison@bt.com Cc: edwoo@lucent.com, francis.arts@alcatel.be, fabio@infocom.uniroma1.it, mpls@UU.NET Subject: RE: MPLS OAM? Date: Thu, 25 Jan 2001 08:07:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I, too, would greatly appreciate a copy. Emil Drottar Aura Networks -----Original Message----- From: Francis Arts [mailto:francis.arts@alcatel.be] Sent: Thursday, January 25, 2001 2:16 AM To: neil.2.harrison@bt.com Cc: Ed Woo; fabio@infocom.uniroma1.it; mpls@UU.NET Subject: Re: MPLS OAM? Neil, Could you also get me a copy? Thanks. Francis. ----------------- Ed Woo schreef: > Neil, I'd also like to receive a copy. Thanks. > > Ed Woo > Lucent Technologies > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > neil.2.harrison@bt.com > Sent: Tuesday, January 23, 2001 3:32 AM > To: fabio@infocom.uniroma1.it; mpls@UU.NET > Subject: RE: MPLS OAM? > > Fabio....A few people have asked why I have not posted the stuff directly > back to the mailing list so I think I had better briefly answer here in case > I get any further enquiries: > > I started this last year based on the experiences (bad ones) with OAM for > ATM....so, based on that history (ie I.610 reality vs I.356 > wish-list), I tried to correct the main flaws and get a *simple* OAM spec > that does what we operators want, ie can detect all failures modes and > measure availability. Since then Shahram Davari (PMC Sierra), Peter Willis > (BT Labs) and Ben MackCrane (Tellabs) have been steadily refining the work > with > me (other have chipped in from time time to we are the main divers). > > We were going to submit an ID last year but 2 things happened: > 1 The ITU started to work on this area formally....so I had to direct > attention to this to make sure they saw our ideas and to try to keep the 2 > fora in sync. > 2 GMPLS/OTN issues have taken quite a slice of my personal time over > the last few months. > > I presented the basic ideas to the Nov 01 SG13 mtg.....they were all > accepted and a draft Rec Y.17oam produced. Since then Shahram/Ben/Peter/I > have been working on the outstanding issues. However, since this is ITU > focused at present and the work is in MS Word format that is why I did not > send this to the list directly...and so I have been responding to requests > to see this (quite a lot surprisngly) on a personal basis. I will wait > another day or so to see how many other requests come in and then mail shot > whoever else asks for it. > > Once I get ITU sorted I will re-focus on getting suitable ID together and > issued. > > Hope that explains the situation. > > Regards, Neil > > > -----Original Message----- > > From: Fabio Ricciato [mailto:fabio@infocom.uniroma1.it] > > Sent: 23 January 2001 08:14 > > To: neil.2.harrison@bt.com; mpls@UU.NET > > Subject: Re: MPLS OAM? > > > > > > Hi, > > I (silently) follow this mailing list. > > I'm also intersted in the MPLS OAM and would like to be > > included in the > > distribution list about that. > > > > Anyway I guess OAM is an interesting topic for most of MPLS-involved > > people, thus it's fine if discussion and/or reference distribution > > continue on the mailing list. > > > > best regards > > > > fabio ricciato > > From owner-mpls@UU.NET Thu Jan 25 08:40:44 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25629 for ; Thu, 25 Jan 2001 08:40:44 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzms15137; Thu, 25 Jan 2001 13:39:23 GMT Received: by mail-control.mail.uu.net id QQjzms03982 for mpls-outgoing; Thu, 25 Jan 2001 13:38:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzms03974 for ; Thu, 25 Jan 2001 13:38: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 QQjzms27869 for ; Thu, 25 Jan 2001 13:36:47 GMT Received: from mx4.tellabs.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mx4.tellabs.com [204.68.180.54]) id QQjzms12773 for ; Thu, 25 Jan 2001 13:36:46 GMT Received: from mail.hq.tellabs.com (mail.bb.tellabs.com [138.111.51.100]) by mx4.tellabs.com (Mirapoint) with ESMTP id AAA87492; Thu, 25 Jan 2001 07:37:05 -0600 (CST) Received: from tellabs.com (dhcp-90-119.lisle.tellabs.com [138.111.90.119]) by mail.hq.tellabs.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id HAA25824; Thu, 25 Jan 2001 07:35:57 -0600 (CST) Message-ID: <3A702AFF.7F332CAE@tellabs.com> Date: Thu, 25 Jan 2001 07:32:47 -0600 From: Ben Mack-Crane X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: jdrake@calient.net CC: abanerjee@calient.net, fubar@labn.net, JConnell@WhiteRockNetworks.com, Jzyu@zaffire.com, schatterjee@WhiteRockNetworks.com, MPLS Working Group , TV Area Subject: Re: Resolving "Enhancements" text... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit John, I agree it is more work to support two generalized label request formats. I would like to see just one format. To achieve this goal, we must find a format that has fields which have general use, and allow them to be used as needed by different network layers (networking technologies) as is appropriate to their specific needs. The type 5 format supports this. It only includes "SONET unique stuff" when it is being used for SONET. The fields are all generally useful and appropriate codepoints can be defined for them for each networking technology. I have also suggested allowing independent codespaces for the fields by technology (as indicated by the LSP Encoding Type) so that definition of specific codepoints and semantics for different technologies can be done independently. This would allow relatively independent progress to be made in each networing technology. I think we should take this to the general mailing lists so that everyone who is interested can comment or follow the discussion. Regards, Ben jdrake@calient.net wrote: > > Ayan and Greg, > > What is the rule used by an origin node to decide whether to include a > C_Type 4 or C_Type 5 Generalized Label Request in the Path message? > > For example, suppose a router wants to set up a PSC LSP to another router > across a set of SONET switches. The link between the origin router and the > origin SONET switch will be PSC at the router end and TSC at the SONET > switch end. If that router wants an OC-48 LSP but the link between it and > the SONET switch is an OC-192, then the router is clearly going to be > getting timeslot labels from the SONET switch. So should the router use a > type 4 or type 5 label request? > > If the origin router sends a type 4, does the origin SONET switch convert it > to a type 5 to transit the set of SONET switches and then does the > destination SONET switch convert back to a type 4 before sending it to the > destination router? Conversely, why would the origin and destination > routers want to deal with a type 5, since it contains all the SONET unique > stuff that routers don't care about? > > Another way of saying this is that while it might have seemed that we were > finessing the issue by having two C_Types, it may end up being more work for > everyone if we all have to support both. Further, if the origin and > destination routers have to deal with a type 5, they may want to have a lot > more say over what's included in it. Similarly, if we're providing a > grooming function between OC-48 trails and OC-192 trunks and we're told that > we have to use a type 5, we may want to have a lot more say about what's > included in it. > > Thanks, > > John > > -----Original Message----- > From: Ayan Banerjee > Sent: Wednesday, January 24, 2001 3:06 PM > To: fubar@labn.net > Cc: Ben.Mack-Crane@tellabs.com; JConnell@WhiteRockNetworks.com; > Jzyu@zaffire.com; schatterjee@WhiteRockNetworks.com > Subject: RE: Resolving "Enhancements" text... > > All, > > Greg and I have been working on the IETF GMPLS draft to > resolve the outstanding issues. The modifications attached > below are to the appropriate sections of > draft-ietf-mpls-generalized-signaling-00.txt. > > The proposed changes harmonizes those issues and > are: > > (a) Removed RT from the SONET/SDH label > (b) Added Signal Type to the SONET/SDH label > (c) Added a new field called LSP Protection Type > (d) Reorganized the layout of some fields for label type 5. > > We are hoping that this will bring about a closure to the > various issues. Comments ? > > Thanks, > Greg and Ayan From owner-mpls@UU.NET Thu Jan 25 08:45:25 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25718 for ; Thu, 25 Jan 2001 08:45:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzms22577; Thu, 25 Jan 2001 13:44:46 GMT Received: by mail-control.mail.uu.net id QQjzms04454 for mpls-outgoing; Thu, 25 Jan 2001 13:43:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzms04445 for ; Thu, 25 Jan 2001 13:43:56 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 QQjzms16390 for ; Thu, 25 Jan 2001 13:43:33 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjzms23749 for ; Thu, 25 Jan 2001 13:43:32 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 25 Jan 2001 19:18:45 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f0PJGYU07439; Fri, 26 Jan 2001 00:46:34 +0530 Reply-To: From: "Manikantan S" To: "'Thomas D. Nadeau'" , "'Cucchiara, Joan'" Cc: , , , Subject: RE: Last call on MPLS TE MIB Date: Thu, 25 Jan 2001 19:00:05 +0530 Message-Id: <001301c086d2$ee2c2ae0$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <4.3.2.7.2.20010125075718.02a74ef8@bucket.cisco.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Thomas I accept your suggestion to use the mplsTunnelHopIpv4Addr for the required need of LSPID ER Hop with the needed modification in the description. thanks and best regards mani -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Thomas D. Nadeau Sent: Thursday, 25 January 2001 6:29 PM To: manis@future.futsoft.com; 'Cucchiara, Joan' Cc: slakkapr@nortelnetworks.com; arun@force10networks.com; cheenu@tachion.com; mpls@uu.net Subject: RE: Last call on MPLS TE MIB Let me be a little more precise with my last statement regarding this proposed addition. Why don't we just re-use the mplsTunnelHopIpv4Addr, and if the value is set to lspid, modify the description of the hopAddrType slightly to allow the mplsTunnelHopIpv4Addr or mplsTunnelHopIpv6Addr to be set as well in this case? --Tom >I have an another observation/suggestion with respect to the >CRLSP support. > >This is with respect to the ER Hop that is configured to be of >type LSPID. Currently we have support to configure the LSPID >value via the MIB object "mplsTunnelHopLspId" and the >have the MIB object "mplsTunnelHopAddrType" set to value "lspid". > >For a ER Hop Type of LSPID, the Ingress LSR Router ID value is >also required. > >Can we add an object to facilitate this configuration? >(We have added this to our enterprises MIB to support LSPID ER hop >types). > >The SMI for the object can be as follows. > >mplsTunnelHopIngressRouterId MplsLsrId > >mplsTunnelHopIngressRouterId OBJECT-TYPE > SYNTAX MplsLsrId > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "If mplsTunnelHopAddrType is set to lspid(4), then > this value will contain the IPv4 address of the > Ingress Router ID of the Tunnel. This object is > otherwise insignificant and should contain a > value of 0." > >NOTE: The suggestion made is for IPv4 Address alone here, since >the LSPID TLV currently supports IPv4 address type only. > >Thanks in advance >with best regards >mani >----------------------------------------- >S.Manikantan >Future Software Limited >480-481, Anna Salai, >Nandanam, Chennai, India. >Zip (PIN CODE) : 600 035 >Phone : 91-44-4330550 >Fax : 91-44-4344157 >email : manis@future.futsoft.com >----------------------------------------- From owner-mpls@UU.NET Thu Jan 25 08:52:02 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25802 for ; Thu, 25 Jan 2001 08:52:01 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzmt27248; Thu, 25 Jan 2001 13:47:46 GMT Received: by mail-control.mail.uu.net id QQjzmt05125 for mpls-outgoing; Thu, 25 Jan 2001 13:47:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzmt05089 for ; Thu, 25 Jan 2001 13:46: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 QQjzmt18898 for ; Thu, 25 Jan 2001 13:46:13 GMT Received: from fsnt.future.futsoft.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjzmt28034 for ; Thu, 25 Jan 2001 13:46:11 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 25 Jan 2001 19:21:22 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f0PJJHU07466; Fri, 26 Jan 2001 00:49:17 +0530 Reply-To: From: "Manikantan S" To: "'Thomas D. Nadeau'" , "'Cucchiara, Joan'" Cc: , Subject: RE: Last call on MPLS TE MIB Date: Thu, 25 Jan 2001 19:02:48 +0530 Message-Id: <001401c086d3$4f4642c0$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <4.3.2.7.2.20010124144954.02bd3dc0@bucket.cisco.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Thomas, Joan I have placed the SMI for the object in alignment with the other objects in the TE MIB. If this is fine, or please modify as required and can be added to the MIB. --------------------------------------------------------- mplsTunnelResourceFlags INTEGER mplsTunnelResourceFlags OBJECT-TYPE SYNTAX INTEGER (0..63) MAX-ACCESS read-create STATUS current DESCRIPTION "The value of Flags conveyed as part of the Traffic Parameters during the establishment of the CRLSP. The Bit value indicates the set of Traffic parameters that are negotiable during the CRLSP setup." REFERENCE "Section 4.3, Constraint-Based LSP Setup using LDP, Jamoussi, et. al, , July 2000." DEFVAL { 0 } -- Parameters not negotiable. -------------------------------------------------------------- thanks in advance with best regards mani -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Thursday, 25 January 2001 1:21 AM To: Cucchiara, Joan; manis@future.futsoft.com Cc: slakkapr@nortelnetworks.com Subject: RE: Last call on MPLS TE MIB Hi, Can someone provide us with the appropriate SMI for this object? --tom >>I would like to see Manikantan's suggestions >>added to the MPLS-TE MIB. This is also for >>CR-LDP support. Is this object and description >>going to be added? >> >> Thanks, Joan >> >> > -----Original Message----- >> > From: Manikantan S [mailto:manis@future.futsoft.com] >> > Sent: Wednesday, January 17, 2001 11:33 PM >> > To: 'Cucchiara, Joan' >> > Cc: slakkapr@nortelnetworks.com; tnadeau@cisco.com; >> > arun@force10networks.com; cheenu@tachion.com; mpls@UU.NET >> > Subject: RE: Last call on MPLS TE MIB >> > >> > >> > Hello Joan >> > >> > #> Hello >> > #> >> > #> It would help, as suggested in the mail to include >> > #> the CRLDP-Specific MIB objects in the TE MIB. >> > #> >> > #> Currently we have them as Enterprise MIB objects >> > #> in our implementation and we can move to the >> > #> standard MIB if they are available there. >> > #> >> > #> I have the following question/doubt for Joan. >> > #> >> > #> 1) We have a field "flags" in the CRLDP Traffic >> > #> Parameters TLV. This helps in conveying the >> > #> set of negotiable parameters. The value of "Flags" >> > #> being added as a configurable object will provide >> > #> added flexibility. what do you suggest? >> > # >> > #I agree with you that an ActiveFlags object would >> > #be useful for CR-LDP. If possible, would you >> > #be able to email what this object looked like in >> > #your enterprise MIB? >> > # >> > #Having actual implementation feedback is very useful >> > #for MIB objects. >> > >> > I currently have the following definition in >> > the Enterprises MIB. >> > >> > fsMplsLdpCrlspTnlFlags INTEGER >> > >> > fsMplsLdpCrlspTnlFlags OBJECT-TYPE >> > SYNTAX INTEGER (0..63) >> > MAX-ACCESS read-create >> > STATUS current >> > DESCRIPTION >> > "The value of Flags conveyed as part of the >> > Traffic Parameters >> > during the establishment of the CRLSP. The Bit value >> > indicates the set of Traffic parameters that are >> > negotiable during the CRLSP setup." >> > REFERENCE >> > "Section 4.3, Constraint-Based LSP Setup using >> > LDP, Jamoussi, >> > et. >> > al, , July 2000." >> > DEFVAL { 0 } -- Parameters not negotiable. >> > >> > #> >> > #> 2) Do we need to use the value of the MIB object >> > #> "mplsTunnelIncludeAnyAffinity" for the >> > #> "RsCls" field in Resource Class TLV? >> > # >> > #This seems like a reasonable approach. Are you >> > #suggesting that the wording of the "mplsTunnelIncludeAnyAffinity" >> > #object be enhanced to include CR-LDP's Resource Class TLV? >> > >> > Yes. I feel it will be clear and very helpful. >> > >> > Thanks and best regards >> > mani >> > ----------------------------------------- >> > S.Manikantan >> > Future Software Limited >> > 480-481, Anna Salai, >> > Nandanam, Chennai, India. >> > Zip (PIN CODE) : 600 035 >> > Phone : 91-44-4330550 >> > Fax : 91-44-4344157 >> > email : manis@future.futsoft.com >> > ----------------------------------------- >> > From owner-mpls@UU.NET Thu Jan 25 09:56:32 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27754 for ; Thu, 25 Jan 2001 09:56:32 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzmx18899; Thu, 25 Jan 2001 14:53:53 GMT Received: by mail-control.mail.uu.net id QQjzmx22186 for mpls-outgoing; Thu, 25 Jan 2001 14:53:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzmx22181 for ; Thu, 25 Jan 2001 14:53:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjzmx25092 for ; Thu, 25 Jan 2001 14:53:03 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjzmx16509 for ; Thu, 25 Jan 2001 14:53:01 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 25 Jan 2001 20:28:09 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f0PKQ3U09839; Fri, 26 Jan 2001 01:56:03 +0530 Reply-To: From: "Manikantan S" To: "'Thomas D. Nadeau'" , "'Cucchiara, Joan'" Cc: , Subject: RE: Last call on MPLS TE MIB Date: Thu, 25 Jan 2001 20:09:32 +0530 Message-Id: <001a01c086dc$a24609c0$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <4.3.2.7.2.20010125085728.02b8bbc0@bucket.cisco.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Tom #-----Original Message----- #From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] #Sent: Thursday, 25 January 2001 7:33 PM #To: manis@future.futsoft.com; 'Cucchiara, Joan' #Cc: slakkapr@nortelnetworks.com; mpls@UU.NET #Subject: RE: Last call on MPLS TE MIB # # # # I would just add to that at the end, "The #syntax and semantics of this value must coincide with #those defined in the CRLDP specification." I think that #we need this to ensure inter-operability. # # I would also change the SYNTAX to Unsigned32. #The use of "INTEGER" is appropriate for enumerations. #Will Unsigned32(0..63) satisfy the definition from #the CRLDP specification? I think that we want to just #leave this as Unsigned32 without the range. Mani> The range was specified since only 6 bits of the 1 byte Flags can be set. The 2 Most significant Bits are reserved, set to zero on transmission. (Ignored on reception). If range is not specified, in the implementation we need to take care of the value being set with the appropriate values. best regards mani # # # Traffic Parameters # # Each Traffic Parameter is encoded as a 32-bit IEEE single- # precision floating-point number. A value of positive infinity # is represented as an IEEE single-precision floating-point # number with an exponent of all ones (255) and a sign and # mantissa of all zeros. The values PDR and CDR are in units of # bytes per second. The values PBS, CBS and EBS are in units of # bytes. # # --Tom >I have placed the SMI for the object in alignment >with the other objects in the TE MIB. > >If this is fine, or please modify as required and can be >added to the MIB. > >--------------------------------------------------------- > mplsTunnelResourceFlags INTEGER > > mplsTunnelResourceFlags OBJECT-TYPE > SYNTAX INTEGER (0..63) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The value of Flags conveyed as part of the > Traffic Parameters during the establishment > of the CRLSP. The Bit value indicates the > set of Traffic parameters that are > negotiable during the CRLSP setup." > REFERENCE > "Section 4.3, Constraint-Based LSP Setup using > LDP, Jamoussi, et. al, > , July 2000." > DEFVAL { 0 } -- Parameters not negotiable. > >-------------------------------------------------------------- > >thanks in advance >with best regards >mani > > > >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Thursday, 25 January 2001 1:21 AM >To: Cucchiara, Joan; manis@future.futsoft.com >Cc: slakkapr@nortelnetworks.com >Subject: RE: Last call on MPLS TE MIB > > > > Hi, > > Can someone provide us with the appropriate >SMI for this object? > > --tom > > >>I would like to see Manikantan's suggestions > >>added to the MPLS-TE MIB. This is also for > >>CR-LDP support. Is this object and description > >>going to be added? > >> > >> Thanks, Joan > >> > >> > -----Original Message----- > >> > From: Manikantan S [mailto:manis@future.futsoft.com] > >> > Sent: Wednesday, January 17, 2001 11:33 PM > >> > To: 'Cucchiara, Joan' > >> > Cc: slakkapr@nortelnetworks.com; tnadeau@cisco.com; > >> > arun@force10networks.com; cheenu@tachion.com; mpls@UU.NET > >> > Subject: RE: Last call on MPLS TE MIB > >> > > >> > > >> > Hello Joan > >> > > >> > #> Hello > >> > #> > >> > #> It would help, as suggested in the mail to include > >> > #> the CRLDP-Specific MIB objects in the TE MIB. > >> > #> > >> > #> Currently we have them as Enterprise MIB objects > >> > #> in our implementation and we can move to the > >> > #> standard MIB if they are available there. > >> > #> > >> > #> I have the following question/doubt for Joan. > >> > #> > >> > #> 1) We have a field "flags" in the CRLDP Traffic > >> > #> Parameters TLV. This helps in conveying the > >> > #> set of negotiable parameters. The value of "Flags" > >> > #> being added as a configurable object will provide > >> > #> added flexibility. what do you suggest? > >> > # > >> > #I agree with you that an ActiveFlags object would > >> > #be useful for CR-LDP. If possible, would you > >> > #be able to email what this object looked like in > >> > #your enterprise MIB? > >> > # > >> > #Having actual implementation feedback is very useful > >> > #for MIB objects. > >> > > >> > I currently have the following definition in > >> > the Enterprises MIB. > >> > > >> > fsMplsLdpCrlspTnlFlags INTEGER > >> > > >> > fsMplsLdpCrlspTnlFlags OBJECT-TYPE > >> > SYNTAX INTEGER (0..63) > >> > MAX-ACCESS read-create > >> > STATUS current > >> > DESCRIPTION > >> > "The value of Flags conveyed as part of the > >> > Traffic Parameters > >> > during the establishment of the CRLSP. The Bit value > >> > indicates the set of Traffic parameters that are > >> > negotiable during the CRLSP setup." > >> > REFERENCE > >> > "Section 4.3, Constraint-Based LSP Setup using > >> > LDP, Jamoussi, > >> > et. > >> > al, , July 2000." > >> > DEFVAL { 0 } -- Parameters not negotiable. > >> > > >> > #> > >> > #> 2) Do we need to use the value of the MIB object > >> > #> "mplsTunnelIncludeAnyAffinity" for the > >> > #> "RsCls" field in Resource Class TLV? > >> > # > >> > #This seems like a reasonable approach. Are you > >> > #suggesting that the wording of the "mplsTunnelIncludeAnyAffinity" > >> > #object be enhanced to include CR-LDP's Resource Class TLV? > >> > > >> > Yes. I feel it will be clear and very helpful. > >> > > >> > Thanks and best regards > >> > mani > >> > ----------------------------------------- > >> > S.Manikantan > >> > Future Software Limited > >> > 480-481, Anna Salai, > >> > Nandanam, Chennai, India. > >> > Zip (PIN CODE) : 600 035 > >> > Phone : 91-44-4330550 > >> > Fax : 91-44-4344157 > >> > email : manis@future.futsoft.com > >> > ----------------------------------------- > >> > From owner-mpls@UU.NET Thu Jan 25 10:04:46 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28319 for ; Thu, 25 Jan 2001 10:04:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzmy04517; Thu, 25 Jan 2001 15:02:32 GMT Received: by mail-control.mail.uu.net id QQjzmy28386 for mpls-outgoing; Thu, 25 Jan 2001 15:02:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzmy28164 for ; Thu, 25 Jan 2001 15:02:02 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 QQjzmy00744 for ; Thu, 25 Jan 2001 15:01:24 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzmy28049 for ; Thu, 25 Jan 2001 15:01:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA08414 for mpls@uu.net; Thu, 25 Jan 2001 10:01:23 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzmy25601 for ; Thu, 25 Jan 2001 15:00:57 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 QQjzmx06540 for ; Thu, 25 Jan 2001 14:57:18 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 QQjzmx22160 for ; Thu, 25 Jan 2001 14:57:17 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA18913; Thu, 25 Jan 2001 09:56:55 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-223.cisco.com [161.44.134.223]) by bucket.cisco.com (Mirapoint) with ESMTP id ABH12413; Thu, 25 Jan 2001 09:57:16 -0500 (EST) Message-Id: <4.3.2.7.2.20010125100039.064a7738@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jan 2001 10:01:47 -0500 To: , "'Cucchiara, Joan'" From: "Thomas D. Nadeau" Subject: RE: Last call on MPLS TE MIB Cc: , In-Reply-To: <001a01c086dc$a24609c0$1006000a@future.futsoft.com> References: <4.3.2.7.2.20010125085728.02b8bbc0@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk ># I would also change the SYNTAX to Unsigned32. >#The use of "INTEGER" is appropriate for enumerations. >#Will Unsigned32(0..63) satisfy the definition from >#the CRLDP specification? I think that we want to just >#leave this as Unsigned32 without the range. > >Mani> The range was specified since only 6 bits of >the 1 byte Flags can be set. The 2 Most significant Bits >are reserved, set to zero on transmission. (Ignored on >reception). > >If range is not specified, in the implementation we >need to take care of the value being set with the >appropriate values. Okay, then we can leave it as an Unsigned32 value with the range. You should also include the above textual description in the suggested description I requested. --Tom From owner-mpls@UU.NET Thu Jan 25 10:11:48 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28902 for ; Thu, 25 Jan 2001 10:11:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzmy24042; Thu, 25 Jan 2001 15:09:43 GMT Received: by mail-control.mail.uu.net id QQjzmy05370 for mpls-outgoing; Thu, 25 Jan 2001 15:09:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzmy05351 for ; Thu, 25 Jan 2001 15:08: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 QQjzmy06736 for ; Thu, 25 Jan 2001 15:08:14 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQjzmy21844 for ; Thu, 25 Jan 2001 15:08:13 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA16968 for ; Thu, 25 Jan 2001 07:08:22 -0800 (PST) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA07718 for mpls@uu.net; Thu, 25 Jan 2001 10:08:11 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzjv26319 for ; Wed, 24 Jan 2001 18:58:39 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzjv24018 for ; Wed, 24 Jan 2001 18:58:31 GMT Received: from bgslc02.TBG.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQjzjv20851 for ; Wed, 24 Jan 2001 18:58:30 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 11:51:44 -0700 Message-ID: <0C875DC28791D21192CD00104B95BFE70146D33A@BGSLC02> From: Irwin Lazar To: "'mpls@uu.net'" Subject: RE: First international MPLS exhibition Date: Wed, 24 Jan 2001 11:51:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Folks, I run a mailing list at the MPLS resource center that is focused on MPLS operational issues. I would argue that training opportunities are in-scope for the MPLS-OPS list, so please feel free to use it as a forum for seminar notifications. subscribe: e-mail to mpls-ops-request@mplsrc.com with "subscribe" in the subject. site URL: www.mplsrc.com Irwin -----Original Message----- From: Pedro Paiva [mailto:Pedro.Paiva@ch.uu.net] Sent: Wednesday, January 24, 2001 9:04 AM To: 'Holmes, David A.' Cc: mpls@UU.NET; peter.lewis@upperside.fr Subject: RE: First international MPLS exhibition David, # There appears to be a purist viewpoint that the mailing list be used solely # for technical exchanges, and not for notification of events of interest. # Where else can the MPLS community be notified of events of common interest? On the MPLS Forum mailing list(s) can be an idea. Pedro "Hawkeye" PAIVA Chief Technologist, EMEA - Future Technology Development UUNET - a WorldCom company 18, ch. de Trefle Blanc CH-1228 Plan-les-Ouates (Geneve) Tel +41.22.580.76.32 Mobile +41.79.310.24.08 e-mail pedrop@ch.uu.net From owner-mpls@UU.NET Thu Jan 25 10:12:31 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28945 for ; Thu, 25 Jan 2001 10:12:30 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzmy10062; Thu, 25 Jan 2001 15:09:52 GMT Received: by mail-control.mail.uu.net id QQjzmy05384 for mpls-outgoing; Thu, 25 Jan 2001 15:09:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzmy05361 for ; Thu, 25 Jan 2001 15:09: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 QQjzmy03014 for ; Thu, 25 Jan 2001 15:06:51 GMT Received: from fsnt.future.futsoft.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQjzmy05737 for ; Thu, 25 Jan 2001 15:06:49 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 25 Jan 2001 20:41:55 +0530 Received: from manis (manis.future.futsoft.com [10.0.6.16]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f0PKdnU10768; Fri, 26 Jan 2001 02:09:49 +0530 Reply-To: From: "Manikantan S" To: "'Thomas D. Nadeau'" , "'Cucchiara, Joan'" Cc: , , , Subject: RE: Last call on MPLS TE MIB Date: Thu, 25 Jan 2001 20:23:19 +0530 Message-Id: <001b01c086de$8ef42300$1006000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <4.3.2.7.2.20010125075718.02a74ef8@bucket.cisco.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello Tom My suggested change to the description clause for mplsTunnelHopIpv4Addr is as follows mplsTunnelHopIpv4Addr OBJECT-TYPE SYNTAX InetAddressIPv4 MAX-ACCESS read-create STATUS current DESCRIPTION "If mplsTunnelHopAddrType is set to ipV4(1), then this value will contain the IPv4 address of this hop. If mplsTunnelHopAddrType is set to lspid(4), then this value will contain the Ingress LSR Router ID of the Tunnel. This object is otherwise insignificant and should contain a value of 0." ::= { mplsTunnelHopEntry 5 } regards mani -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Thursday, 25 January 2001 7:26 PM To: manis@future.futsoft.com Subject: RE: Last call on MPLS TE MIB Can you please provide us with a specific change to the DESCRIPTION clause for this object? We are all quite busy right now, and don't have the time to sort this out to your satisfaction, so it is probably easier if you just tell us exactly what you want. --Tom >I accept your suggestion to use the mplsTunnelHopIpv4Addr for >the required need of LSPID ER Hop with the needed modification >in the description. > >thanks and best regards >mani > > > -----Original Message----- From: owner-mpls@uu.net [mailto:owner-mpls@uu.net]On Behalf Of Thomas D. Nadeau Sent: Thursday, 25 January 2001 6:29 PM To: manis@future.futsoft.com; 'Cucchiara, Joan' Cc: slakkapr@nortelnetworks.com; arun@force10networks.com; cheenu@tachion.com; mpls@uu.net Subject: RE: Last call on MPLS TE MIB Let me be a little more precise with my last statement regarding this proposed addition. Why don't we just re-use the mplsTunnelHopIpv4Addr, and if the value is set to lspid, modify the description of the hopAddrType slightly to allow the mplsTunnelHopIpv4Addr or mplsTunnelHopIpv6Addr to be set as well in this case? --Tom >I have an another observation/suggestion with respect to the >CRLSP support. > >This is with respect to the ER Hop that is configured to be of >type LSPID. Currently we have support to configure the LSPID >value via the MIB object "mplsTunnelHopLspId" and the >have the MIB object "mplsTunnelHopAddrType" set to value "lspid". > >For a ER Hop Type of LSPID, the Ingress LSR Router ID value is >also required. > >Can we add an object to facilitate this configuration? >(We have added this to our enterprises MIB to support LSPID ER hop >types). > >The SMI for the object can be as follows. > >mplsTunnelHopIngressRouterId MplsLsrId > >mplsTunnelHopIngressRouterId OBJECT-TYPE > SYNTAX MplsLsrId > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "If mplsTunnelHopAddrType is set to lspid(4), then > this value will contain the IPv4 address of the > Ingress Router ID of the Tunnel. This object is > otherwise insignificant and should contain a > value of 0." > >NOTE: The suggestion made is for IPv4 Address alone here, since >the LSPID TLV currently supports IPv4 address type only. > >Thanks in advance >with best regards >mani >----------------------------------------- >S.Manikantan >Future Software Limited >480-481, Anna Salai, >Nandanam, Chennai, India. >Zip (PIN CODE) : 600 035 >Phone : 91-44-4330550 >Fax : 91-44-4344157 >email : manis@future.futsoft.com >----------------------------------------- From owner-mpls@UU.NET Thu Jan 25 10:23:29 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29731 for ; Thu, 25 Jan 2001 10:23:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzmz24703; Thu, 25 Jan 2001 15:19:57 GMT Received: by mail-control.mail.uu.net id QQjzmz07015 for mpls-outgoing; Thu, 25 Jan 2001 15:19:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzmz07007 for ; Thu, 25 Jan 2001 15:19: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 QQjzmz03194 for ; Thu, 25 Jan 2001 15:16:14 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzmz28473 for ; Thu, 25 Jan 2001 15:16:13 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA10846 for mpls@uu.net; Thu, 25 Jan 2001 10:16:12 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzmt06254 for ; Thu, 25 Jan 2001 13:59: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 QQjzmt17883 for ; Thu, 25 Jan 2001 13:58:32 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 QQjzmt01908 for ; Thu, 25 Jan 2001 13:58:32 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA15526; Thu, 25 Jan 2001 08:58:10 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABH11526; Thu, 25 Jan 2001 08:58:29 -0500 (EST) Message-Id: <4.3.2.7.2.20010125085728.02b8bbc0@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jan 2001 09:02:56 -0500 To: , "'Cucchiara, Joan'" From: "Thomas D. Nadeau" Subject: RE: Last call on MPLS TE MIB Cc: , In-Reply-To: <001401c086d3$4f4642c0$1006000a@future.futsoft.com> References: <4.3.2.7.2.20010124144954.02bd3dc0@bucket.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk I would just add to that at the end, "The syntax and semantics of this value must coincide with those defined in the CRLDP specification." I think that we need this to ensure inter-operability. I would also change the SYNTAX to Unsigned32. The use of "INTEGER" is appropriate for enumerations. Will Unsigned32(0..63) satisfy the definition from the CRLDP specification? I think that we want to just leave this as Unsigned32 without the range. Traffic Parameters Each Traffic Parameter is encoded as a 32-bit IEEE single- precision floating-point number. A value of positive infinity is represented as an IEEE single-precision floating-point number with an exponent of all ones (255) and a sign and mantissa of all zeros. The values PDR and CDR are in units of bytes per second. The values PBS, CBS and EBS are in units of bytes. --Tom >I have placed the SMI for the object in alignment >with the other objects in the TE MIB. > >If this is fine, or please modify as required and can be >added to the MIB. > >--------------------------------------------------------- > mplsTunnelResourceFlags INTEGER > > mplsTunnelResourceFlags OBJECT-TYPE > SYNTAX INTEGER (0..63) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The value of Flags conveyed as part of the > Traffic Parameters during the establishment > of the CRLSP. The Bit value indicates the > set of Traffic parameters that are > negotiable during the CRLSP setup." > REFERENCE > "Section 4.3, Constraint-Based LSP Setup using > LDP, Jamoussi, et. al, > , July 2000." > DEFVAL { 0 } -- Parameters not negotiable. > >-------------------------------------------------------------- > >thanks in advance >with best regards >mani > > > >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Thursday, 25 January 2001 1:21 AM >To: Cucchiara, Joan; manis@future.futsoft.com >Cc: slakkapr@nortelnetworks.com >Subject: RE: Last call on MPLS TE MIB > > > > Hi, > > Can someone provide us with the appropriate >SMI for this object? > > --tom > > >>I would like to see Manikantan's suggestions > >>added to the MPLS-TE MIB. This is also for > >>CR-LDP support. Is this object and description > >>going to be added? > >> > >> Thanks, Joan > >> > >> > -----Original Message----- > >> > From: Manikantan S [mailto:manis@future.futsoft.com] > >> > Sent: Wednesday, January 17, 2001 11:33 PM > >> > To: 'Cucchiara, Joan' > >> > Cc: slakkapr@nortelnetworks.com; tnadeau@cisco.com; > >> > arun@force10networks.com; cheenu@tachion.com; mpls@UU.NET > >> > Subject: RE: Last call on MPLS TE MIB > >> > > >> > > >> > Hello Joan > >> > > >> > #> Hello > >> > #> > >> > #> It would help, as suggested in the mail to include > >> > #> the CRLDP-Specific MIB objects in the TE MIB. > >> > #> > >> > #> Currently we have them as Enterprise MIB objects > >> > #> in our implementation and we can move to the > >> > #> standard MIB if they are available there. > >> > #> > >> > #> I have the following question/doubt for Joan. > >> > #> > >> > #> 1) We have a field "flags" in the CRLDP Traffic > >> > #> Parameters TLV. This helps in conveying the > >> > #> set of negotiable parameters. The value of "Flags" > >> > #> being added as a configurable object will provide > >> > #> added flexibility. what do you suggest? > >> > # > >> > #I agree with you that an ActiveFlags object would > >> > #be useful for CR-LDP. If possible, would you > >> > #be able to email what this object looked like in > >> > #your enterprise MIB? > >> > # > >> > #Having actual implementation feedback is very useful > >> > #for MIB objects. > >> > > >> > I currently have the following definition in > >> > the Enterprises MIB. > >> > > >> > fsMplsLdpCrlspTnlFlags INTEGER > >> > > >> > fsMplsLdpCrlspTnlFlags OBJECT-TYPE > >> > SYNTAX INTEGER (0..63) > >> > MAX-ACCESS read-create > >> > STATUS current > >> > DESCRIPTION > >> > "The value of Flags conveyed as part of the > >> > Traffic Parameters > >> > during the establishment of the CRLSP. The Bit value > >> > indicates the set of Traffic parameters that are > >> > negotiable during the CRLSP setup." > >> > REFERENCE > >> > "Section 4.3, Constraint-Based LSP Setup using > >> > LDP, Jamoussi, > >> > et. > >> > al, , July 2000." > >> > DEFVAL { 0 } -- Parameters not negotiable. > >> > > >> > #> > >> > #> 2) Do we need to use the value of the MIB object > >> > #> "mplsTunnelIncludeAnyAffinity" for the > >> > #> "RsCls" field in Resource Class TLV? > >> > # > >> > #This seems like a reasonable approach. Are you > >> > #suggesting that the wording of the "mplsTunnelIncludeAnyAffinity" > >> > #object be enhanced to include CR-LDP's Resource Class TLV? > >> > > >> > Yes. I feel it will be clear and very helpful. > >> > > >> > Thanks and best regards > >> > mani > >> > ----------------------------------------- > >> > S.Manikantan > >> > Future Software Limited > >> > 480-481, Anna Salai, > >> > Nandanam, Chennai, India. > >> > Zip (PIN CODE) : 600 035 > >> > Phone : 91-44-4330550 > >> > Fax : 91-44-4344157 > >> > email : manis@future.futsoft.com > >> > ----------------------------------------- > >> > From owner-mpls@UU.NET Thu Jan 25 10:29:35 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00186 for ; Thu, 25 Jan 2001 10:29:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzmz19274; Thu, 25 Jan 2001 15:27:55 GMT Received: by mail-control.mail.uu.net id QQjzmz07911 for mpls-outgoing; Thu, 25 Jan 2001 15:27:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzmz07903 for ; Thu, 25 Jan 2001 15:27:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQjzmz25017 for ; Thu, 25 Jan 2001 15:26:30 GMT Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQjzmz16626 for ; Thu, 25 Jan 2001 15:26:30 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f0PFQS300452; Thu, 25 Jan 2001 10:26:28 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; THU, 25 Jan 2001 10:25:31 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 Jan 2001 10:25:30 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E563A81B0@newman.tenornet.com> From: "Shah, Himanshu" To: "'Kireeti Kompella'" Cc: mpls@UU.NET Subject: question on kompell draft for L2VPN Date: Thu, 25 Jan 2001 10:25:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Kireeti, I was wondering if there was any particular reason why 2-byte Q922 header is stripped from data packet at ingress PE when encap is frame relay. I would think it might be beneficial to preserve the header (for FECN/BECN, DE info) than not. If there is any overwhelming reason to strip the header, how about adding another encapsulation type of "frame relay with q922-header"? regards, Himanshu Himanshu Shah Tenor Networks Acton, MA From owner-mpls@UU.NET Thu Jan 25 10:55:22 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02103 for ; Thu, 25 Jan 2001 10:55:21 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjznb18901; Thu, 25 Jan 2001 15:53:31 GMT Received: by mail-control.mail.uu.net id QQjznb10668 for mpls-outgoing; Thu, 25 Jan 2001 15:52:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjznb10646 for ; Thu, 25 Jan 2001 15:52:50 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 QQjznb00913 for ; Thu, 25 Jan 2001 15:51:04 GMT From: neil.2.harrison@bt.com Received: from marvin.axion.bt.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: marvin.axion.bt.co.uk [132.146.16.82]) id QQjznb20402 for ; Thu, 25 Jan 2001 15:51:02 GMT Received: from cirwm3nt01.nor.bt.com by marvin (local) with ESMTP; Thu, 25 Jan 2001 15:46:13 +0000 Received: by cirwm3nt01.nor.bt.com with Internet Mail Service (5.5.2652.35) id ; Thu, 25 Jan 2001 15:47:30 -0000 Message-ID: To: tnadeau@cisco.com, mpls@UU.NET Subject: RE: MPLS OAM? Date: Thu, 25 Jan 2001 15:47:25 -0000 X-Mailer: Internet Mail Service (5.5.2652.35) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Tom...I agree, and I wanted to avoid this....that was the purpose of my orginal note (ie only write to me not the list). If anyone else wants to discuss this issue and get the material please only contact me and not the list. thanks, neil > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: 25 January 2001 12:44 > To: neil.2.harrison@bt.com > Subject: Re: MPLS OAM? > > > > Neil, > > Can you please ask all of the "me too" folks > to just contact you directly? These messages are getting > kind of redundant, especially for those of us who receive > 300 emails per day. > > Thanks! > > --Tom > From owner-mpls@UU.NET Thu Jan 25 16:03:01 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08713 for ; Thu, 25 Jan 2001 16:03:00 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjznw04681; Thu, 25 Jan 2001 21:00:13 GMT Received: by mail-control.mail.uu.net id QQjznv06730 for mpls-outgoing; Thu, 25 Jan 2001 20:59:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjznv06723 for ; Thu, 25 Jan 2001 20:59:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjznv22839 for ; Thu, 25 Jan 2001 20:58:04 GMT Received: from relay1.alcatel.be by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alc119.alcatel.be [195.207.101.119]) id QQjznv01079 for ; Thu, 25 Jan 2001 20:58:03 GMT Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f0PKw2r08495; Thu, 25 Jan 2001 21:58:02 +0100 (MET) Received: from alcatel.be ([138.203.253.220]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569DF.007328A7; Thu, 25 Jan 2001 21:57:51 +0100 Message-ID: <3A709213.1470E652@alcatel.be> Date: Thu, 25 Jan 2001 21:52:36 +0100 From: Francis Arts Organization: Alcatel X-Mailer: Mozilla 4.7 [nl] (Win98; U) X-Accept-Language: nl MIME-Version: 1.0 To: mpls@UU.NET CC: Anand Gorti Subject: MPLS LSR MIB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Looking into the MPLS LSR MIB I have a question concerning penultimate hop popping. In the case of penultimate hop popping, an out segment is created in the mplsOutSegmentTable with its mplsOutSegmentPushTopLabel object set to FALSE. According to my understanding of the MPLS LSR MIB * the mplsOutSegmentOctets object in this case should be incremented with the number of bytes of the mpls packet payload only (e.g. IP packet length), not including any MPLS header bytes. Is this what the MIB suggests to do in this case or am I missing something? Francis. From owner-mpls@UU.NET Thu Jan 25 19:05:27 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12014 for ; Thu, 25 Jan 2001 19:05:27 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzoi11778; Fri, 26 Jan 2001 00:05:04 GMT Received: by mail-control.mail.uu.net id QQjzoi12507 for mpls-outgoing; Fri, 26 Jan 2001 00:04:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzoi09808 for ; Fri, 26 Jan 2001 00:03:54 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 QQjzoi21922 for ; Fri, 26 Jan 2001 00:02:41 GMT Received: from tenornetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQjzoi04174 for ; Fri, 26 Jan 2001 00:02:41 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f0Q02d624991; Thu, 25 Jan 2001 19:02:39 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; THU, 25 Jan 2001 19:01:43 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 Jan 2001 19:01:43 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E563A81BB@newman.tenornet.com> From: "Shah, Himanshu" To: "'Kireeti Kompella'" Cc: "'mpls@UU.NET'" Subject: more clarification on Kompell draft for L2VPN Date: Thu, 25 Jan 2001 19:01:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Kireeti, In section 4.3, PE information exchange, there is mention of CE's router ID as part of basic layer 2 VPN advertisement. However, in the signalling section, there is no mention on how this router id is distributed. Am I missing something?? regards, Himanshu Himanshu Shah Tenor Networks Acton, MA From owner-mpls@UU.NET Thu Jan 25 23:41:58 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17291 for ; Thu, 25 Jan 2001 23:41:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzpa03333; Fri, 26 Jan 2001 04:41:18 GMT Received: by mail-control.mail.uu.net id QQjzpa19020 for mpls-outgoing; Fri, 26 Jan 2001 04:40:49 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzpa19009 for ; Fri, 26 Jan 2001 04:40: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 QQjzpa06006 for ; Fri, 26 Jan 2001 04:40:03 GMT From: wesam.alanqar@mail.sprint.com Received: from kcmgwp01.corp.sprint.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker1.sprint.com [208.18.122.165]) id QQjzpa13974 for ; Fri, 26 Jan 2001 04:40:02 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by kcmgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f0Q4e2x13004 for ; Thu, 25 Jan 2001 22:40:02 -0600 (CST) Received: from kcopmp02.corp.sprint.com (kcopmp02m.corp.sprint.com [10.74.2.73]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f0Q4e2v28531 for ; Thu, 25 Jan 2001 22:40:02 -0600 (CST) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id WAA24278 for ; Thu, 25 Jan 2001 22:39:51 -0600 (CST) X-OpenMail-Hops: 1 Importance: High Date: Thu, 25 Jan 2001 22:39:51 -0600 Message-Id: Subject: P-LSPs, SP-LSP, and S-LSP (Any Idea?) MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-1a17cc60-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-1a17cc60-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Thu, 25 Jan 2001 22:39:49 -0600" X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQjzpa03333 Content-Transfer-Encoding: quoted-printable Hello, Any idea about P-LSPs, SP-LSPs, and S-LSPs?=A0 Do they have to to do with loose & strict CR-LSPs. Any relations with L-LSPs & E-LSPs? Any feedback from Marconi? This was mentioned in Marconi BXR-48000 switch router white papers. Your feedback is highly appreciated. Thanks. --Wesam ------------------------------------------------------------------------ -=20 Wesam Alanqar=20 Member of Technical Staff=20 Technology Concepts, Innovations and Evaluation (TCIE)=20 Technology Planning & Integration- Sprint TP&I=20 9300 Metcalf Avenue=20 Overland Park, KS 66212-1463=20 Phone: 913-534-5623=20 Fax: 913-534-3485=20 ------------------------------------------------------------------------ -=20 =A0 --openmail-part-1a17cc60-00000001-- From owner-mpls@UU.NET Fri Jan 26 09:16:13 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10840 for ; Fri, 26 Jan 2001 09:16:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzqn06441; Fri, 26 Jan 2001 14:15:01 GMT Received: by mail-control.mail.uu.net id QQjzqm25245 for mpls-outgoing; Fri, 26 Jan 2001 14:14:31 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQjzqm25232 for ; Fri, 26 Jan 2001 14:14:22 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 QQjzqm27397 for ; Fri, 26 Jan 2001 14:12:55 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 QQjzqm02074 for ; Fri, 26 Jan 2001 14:12: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 JAA11241; Fri, 26 Jan 2001 09:12:53 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA10482; Fri, 26 Jan 2001 09:12:56 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 26 Jan 2001 09:12:54 -0500 Message-ID: <39469E08BD83D411A3D900204840EC550FBA15@vie-msgusr-01.dc.fore.com> From: "Rosenberry, Robert" To: "'wesam.alanqar@mail.sprint.com'" , mpls@UU.NET Subject: RE: P-LSPs, SP-LSP, and S-LSP (Any Idea?) Date: Fri, 26 Jan 2001 09:12:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA10840 Wesam, These are Marconi specific terminology. I would be glad to answer offline from this mailing list. Rob Rosenberry _____ Robert D. Rosenberry, Ph.D. Principal Engineer Marconi Communications, Vienna VA email: Robert.Rosenberry@marconi.com voice: 703-245-4527 fax: 703-245-4545 _____ > -----Original Message----- > From: wesam.alanqar@mail.sprint.com > [mailto:wesam.alanqar@mail.sprint.com] > Sent: Thursday, January 25, 2001 11:40 PM > To: mpls@UU.NET > Subject: P-LSPs, SP-LSP, and S-LSP (Any Idea?) > Importance: High > > > Hello, > > Any idea about P-LSPs, SP-LSPs, and S-LSPs?  Do they have to > to do with > loose & strict CR-LSPs. Any relations with L-LSPs & E-LSPs? > > Any feedback from Marconi? This was mentioned in Marconi BXR-48000 > switch router white papers. > > Your feedback is highly appreciated. Thanks. > > --Wesam > > > -------------------------------------------------------------- > ---------- > - > Wesam Alanqar > Member of Technical Staff > Technology Concepts, Innovations and Evaluation (TCIE) > Technology Planning & Integration- Sprint TP&I > 9300 Metcalf Avenue > Overland Park, KS 66212-1463 > Phone: 913-534-5623 > Fax: 913-534-3485 > -------------------------------------------------------------- > ---------- > - > > > >   > > > From owner-mpls@UU.NET Fri Jan 26 09:19:09 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11513 for ; Fri, 26 Jan 2001 09:19:04 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzqn10170; Fri, 26 Jan 2001 14:17:03 GMT Received: by mail-control.mail.uu.net id QQjzqn25636 for mpls-outgoing; Fri, 26 Jan 2001 14:16:46 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzqn25627 for ; Fri, 26 Jan 2001 14:16:31 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 QQjzqm13943 for ; Fri, 26 Jan 2001 14:14:42 GMT Received: from mailserver.ce-air.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.96.224.129]) id QQjzqm29279 for ; Fri, 26 Jan 2001 14:14:40 GMT Received: from pc ([202.96.224.153]) by mailserver.ce-air.com (Netscape Messaging Server 3.62) with SMTP id 298; Fri, 26 Jan 2001 22:13:37 +0800 Message-ID: <003301c087a2$45f4d9a0$8dd910ac@cea> From: "zheng jiang gu" To: Cc: Date: Fri, 26 Jan 2001 22:14:13 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C087E5.50D26480" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C087E5.50D26480 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 ICBISSBBTEw6DQogICAgICBJIHdhbnQgdG8ga25vdyBpbiB0aGUgYmVsb3cgY29uZmlnICxNdXN0 IEkgY29uZmlnIHRoZSBjb21tYW5kICJyb3V0ZXIgdHJhZmZpYy1lbmdpbmVlcmluZyAiIHRvIGlu ZHVjZSB0aGUgdHJhZmZpYyB0byB0dW5uZWwuU28gaWYgSSBub3QgY29uZmlnIHRoZSBjb21tYW5k ICAsaXMgaXQgbWVhbnMgYWxsIHRyYWZmaWMgb3Igbm9uZT8NCiAgdGhhbmtzIGluIGFkdmFuY2UN Cg0KICB6amd1DQoNCg0KICBtcGxzIHRyYWZmaWMtZW5nIHR1bm5lbHMgDQogIGludGVyZmFjZSBm YXN0IDAvMCANCiAgICBpcCBhZGRyZXNzIDEwLjEuMS4xIDI1NS4yNTUuMjU1LjAgDQogICAgbXBs cyB0cmFmZmljLWVuZyB0dW5uZWxzIA0KICAgIGlwIHJzdnAgYmFuZHdpZHRoIDEwMDAwIA0KDQog IGludGVyZmFjZSB0dW5uZWwgMSANCiAgICB0dW5uZWwgZGVzdGluYXRpb24gMTAuMy4zLjMgDQog ICAgdHVubmVsIG1vZGUgbXBscyB0cmFmZmljLWVuZyANCiAgICB0dW5uZWwgbXBscyB0cmFmZmlj LWVuZyBwYXRoLW9wdGlvbiAxIGV4cGxpY2l0IG5hbWUgbXl0dW5uZWwgDQogICAgdHVubmVsIG1w bHMgdHJhZmZpYy1lbmcgYmFuZHdpZHRoIDEwMDAgDQogICAgdHVubmVsIG1wbHMgdHJhZmZpYy1l bmcgcGF0aC1vcHRpb24gMiBkeW5hbWljIA0KDQogIGlwIGV4cGxpY2l0LXBhdGggbmFtZSBteXR1 bm5lbCANCiAgICBuZXh0LWFkZHJlc3MgMTAuMS4yLjEgDQogICAgbmV4dC1hZGRyZXNzIDEwLjEu MTAuMSANCiAgICBuZXh0LWFkZHJlc3MgMTAuMy4zLjMNCg0KICBpcCByb3V0ZXIgaXNpcyANCiAg cm91dGVyIGlzaXMgDQogICAgbmV0IDQ3LjAwMDAuMDAxMi4zNDU2LjAwIA0KICAgIGlzLXR5cGUg bGV2ZWwtMSANCiAgICBtcGxzIHRyYWZmaWMtZW5nIHJvdXRlci1pZCBsb29wYmFjazAgDQogICAg bXBscyB0cmFmZmljLWVuZyBsZXZlbC0xIA0KICAgIG1ldHJpYy1zdHlsZSB3aWRlIA0KDQogIHJv dXRlciB0cmFmZmljLWVuZ2luZWVyaW5nIA0KICAgIHRyYWZmaWMtZW5naW5lZXJpbmcgZmlsdGVy IDYwIGVncmVzcyAxMC41LjUuNSAyNTUuMjU1LjI1NS4yNTUgDQogICAgdHJhZmZpYy1lbmdpbmVl cmluZyByb3V0ZSA2MCB0dW5uZWwgMQ0KDQo= ------=_NextPart_000_0030_01C087E5.50D26480 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPg0KPEJMT0NLUVVPVEU+DQogIDxESVY+PFNUUk9O Rz48Rk9OVCBzaXplPTM+PFRUPkhJIEFMTDo8L1RUPjwvRk9OVD48L1NUUk9ORz48L0RJVj4NCiAg PERJVj48U1RST05HPjxGT05UIHNpemU9Mz48VFQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgd2FudCB0 byBrbm93IGluIHRoZSBiZWxvdyANCiAgY29uZmlnICxNdXN0IEkgY29uZmlnIHRoZSBjb21tYW5k ICI8Rk9OVCBzaXplPTM+PFRUPnJvdXRlciANCiAgdHJhZmZpYy1lbmdpbmVlcmluZzwvVFQ+Jm5i c3A7PC9GT05UPjxGT05UIHNpemU9Mj4iIA0KICB0PC9GT05UPjwvVFQ+PC9GT05UPjwvU1RST05H PjxTVFJPTkc+PEZPTlQgc2l6ZT0zPjxUVD5vIGluZHVjZSB0aGUgdHJhZmZpYyB0byANCiAgdHVu bmVsLlNvIGlmIEkgbm90IGNvbmZpZyZuYnNwO3RoZSBjb21tYW5kJm5ic3A7ICxpcyBpdCBtZWFu cyBhbGwgdHJhZmZpYyANCiAgPC9UVD48L0ZPTlQ+PC9TVFJPTkc+PFNUUk9ORz48Rk9OVCBzaXpl PTM+PFRUPm9yIA0KICBub25lPzwvVFQ+PC9GT05UPjwvU1RST05HPjwvRElWPg0KICA8RElWPjxT VFJPTkc+PEZPTlQgc2l6ZT0zPjxUVD50aGFua3MgaW4gYWR2YW5jZTwvVFQ+PC9GT05UPjwvU1RS T05HPjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9Mz48VFQ+PC9UVD48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQogIDxESVY+PEZPTlQgc2l6ZT0zPjxUVD48U1RST05HPnpqZ3U8L1NUUk9ORz48L1RUPjwv Rk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTM+PFRUPjwvVFQ+PC9GT05UPiZuYnNwOzwv RElWPg0KICA8RElWPjxGT05UIHNpemU9Mz48VFQ+PC9UVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQog IDxESVY+PEZPTlQgc2l6ZT0zPjxUVD5tcGxzIHRyYWZmaWMtZW5nIHR1bm5lbHM8L1RUPjxUVD48 L1RUPiA8L0ZPTlQ+PC9ESVY+DQogIDxQPjxGT05UIHNpemU9Mz48VFQ+aW50ZXJmYWNlIGZhc3Qg MC8wPC9UVD4gPEJSPjxUVD4mbmJzcDsgaXAgYWRkcmVzcyAxMC4xLjEuMSANCiAgMjU1LjI1NS4y NTUuMDwvVFQ+IDxCUj48VFQ+Jm5ic3A7IG1wbHMgdHJhZmZpYy1lbmcgdHVubmVsczwvVFQ+IDxC Uj48VFQ+Jm5ic3A7IA0KICBpcCByc3ZwIGJhbmR3aWR0aCAxMDAwMDwvVFQ+PFRUPjwvVFQ+IDwv Rk9OVD4NCiAgPFA+PEZPTlQgc2l6ZT0zPjxUVD5pbnRlcmZhY2UgdHVubmVsIDE8L1RUPiA8QlI+ PFRUPiZuYnNwOyB0dW5uZWwgZGVzdGluYXRpb24gDQogIDEwLjMuMy4zPC9UVD4gPEJSPjxUVD4m bmJzcDsgdHVubmVsIG1vZGUgbXBscyB0cmFmZmljLWVuZzwvVFQ+IDxCUj48VFQ+Jm5ic3A7IA0K ICB0dW5uZWwgbXBscyB0cmFmZmljLWVuZyBwYXRoLW9wdGlvbiAxIGV4cGxpY2l0IG5hbWUgbXl0 dW5uZWw8L1RUPiANCiAgPEJSPjxUVD4mbmJzcDsgdHVubmVsIG1wbHMgdHJhZmZpYy1lbmcgYmFu ZHdpZHRoIDEwMDA8L1RUPiA8QlI+PFRUPiZuYnNwOyANCiAgdHVubmVsIG1wbHMgdHJhZmZpYy1l bmcgcGF0aC1vcHRpb24gMiBkeW5hbWljPC9UVD48VFQ+PC9UVD4gPC9GT05UPg0KICA8UD48Rk9O VCBzaXplPTM+PFRUPmlwIGV4cGxpY2l0LXBhdGggbmFtZSBteXR1bm5lbDwvVFQ+IDxCUj48VFQ+ Jm5ic3A7IA0KICBuZXh0LWFkZHJlc3MgMTAuMS4yLjE8L1RUPiA8QlI+PFRUPiZuYnNwOyBuZXh0 LWFkZHJlc3MgMTAuMS4xMC4xPC9UVD4gDQogIDxCUj48VFQ+Jm5ic3A7IG5leHQtYWRkcmVzcyAx MC4zLjMuMzwvVFQ+PC9GT05UPjwvUD48L0JMT0NLUVVPVEU+DQo8QkxPQ0tRVU9URT48Rk9OVCBz aXplPTM+PFRUPmlwIHJvdXRlciBpc2lzPC9UVD48VFQ+PC9UVD4gPC9GT05UPg0KICA8UD48Rk9O VCBzaXplPTM+PFRUPnJvdXRlciBpc2lzPC9UVD4gPEJSPjxUVD4mbmJzcDsgbmV0IA0KICA0Ny4w MDAwLjAwMTIuMzQ1Ni4wMDwvVFQ+IDxCUj48VFQ+Jm5ic3A7IGlzLXR5cGUgbGV2ZWwtMTwvVFQ+ IDxCUj48VFQ+Jm5ic3A7IA0KICBtcGxzIHRyYWZmaWMtZW5nIHJvdXRlci1pZCBsb29wYmFjazA8 L1RUPiA8QlI+PFRUPiZuYnNwOyBtcGxzIHRyYWZmaWMtZW5nIA0KICBsZXZlbC0xPC9UVD4gPEJS PjxUVD4mbmJzcDsgbWV0cmljLXN0eWxlIHdpZGU8L1RUPjxUVD48L1RUPiA8L0ZPTlQ+DQogIDxQ PjxGT05UIHNpemU9Mz48VFQ+cm91dGVyIHRyYWZmaWMtZW5naW5lZXJpbmc8L1RUPiA8QlI+PFRU PiZuYnNwOyANCiAgdHJhZmZpYy1lbmdpbmVlcmluZyBmaWx0ZXIgNjAgZWdyZXNzIDEwLjUuNS41 IDI1NS4yNTUuMjU1LjI1NTwvVFQ+IA0KICA8QlI+PFRUPiZuYnNwOyB0cmFmZmljLWVuZ2luZWVy aW5nIHJvdXRlIDYwIHR1bm5lbCANCjE8L1RUPjwvRk9OVD48L1A+PC9CTE9DS1FVT1RFPjwvRElW PjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0030_01C087E5.50D26480-- From owner-mpls@UU.NET Fri Jan 26 12:39:51 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15971 for ; Fri, 26 Jan 2001 12:39:51 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzra14861; Fri, 26 Jan 2001 17:36:38 GMT Received: by mail-control.mail.uu.net id QQjzra24575 for mpls-outgoing; Fri, 26 Jan 2001 17:36:15 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzra24563 for ; Fri, 26 Jan 2001 17:36:12 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 QQjzra10003 for ; Fri, 26 Jan 2001 17:35:08 GMT Received: from thalia.fm.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: thalia.fm.intel.com [132.233.247.11]) id QQjzra04343 for ; Fri, 26 Jan 2001 17:35:07 GMT Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id RAA04453 for ; Fri, 26 Jan 2001 17:36:20 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 26 Jan 2001 17:34:54 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 26 Jan 2001 09:34:53 -0800 Message-ID: <98B0F9BA93FAD211AC4D00A0C95D19F205C0D025@fmsmsx68.fm.intel.com> From: "Singh, Sukhbinder Takhar" To: "'mpls@UU.NET'" Subject: size of the label stack Date: Fri, 26 Jan 2001 09:34:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi All, In the implementation for Initial Label(MPLS 3032 label encoding) mapping in the data plane can I assume some maximum size of the label stack, that gets appended to the network layer packet. If yes whats a good value to have. thanks -sukhbinder From owner-mpls@UU.NET Fri Jan 26 13:54:49 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18080 for ; Fri, 26 Jan 2001 13:54:49 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzrf11072; Fri, 26 Jan 2001 18:52:44 GMT Received: by mail-control.mail.uu.net id QQjzrf15859 for mpls-outgoing; Fri, 26 Jan 2001 18:52:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzrf15795 for ; Fri, 26 Jan 2001 18:51:58 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 QQjzrf23935 for ; Fri, 26 Jan 2001 18:51:45 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 QQjzrf01034 for ; Fri, 26 Jan 2001 18:51:45 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 NAA06206; Fri, 26 Jan 2001 13:51:42 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA26433; Fri, 26 Jan 2001 13:51:45 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 26 Jan 2001 13:51:43 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF446BF8@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: "'Thomas D. Nadeau'" , cheenu Srinivasan , Arun Viswanathan , mpls@UU.NET Cc: "Choudhury, Sanjaya" Subject: RE: Last call on MPLS TE MIB Date: Fri, 26 Jan 2001 13:51:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi! The current version of the MPLS-TE MIB does not capture the QoS scheme (Int-Serv / DiffServ) and the associated parameters being used by a MPLS tunnel. Should the MPLS-TE be extended to handle this ? Per MPLS Tunnel information I was looking for: --------------- 1. QoS scheme being used by the tunnel (At least at the originating LER.) 2. If QoS scheme is Diff-Serv 2.1 Type of the LSP (L-LSP/E-LSP) 2.2 If L-LSP (with signaled EXP<->PHB) 2.2.1 The PSC associated with the L-LSP 2.2.2 With or without bandwidth reservation. (Assume: If mplsTunnelResourcePointer ==ZeroDotZero then no bandwidth reservation needed) 2.3 If E-LSP (with signaled EXP<->PHB) 2.3.1 The set of PSCs being carried by this E-LSP (EXP<->PHB mapping that was signaled for this LSP) 2.2.2 With or Without bandwidth reservation. (Assume: If mplsTunnelResourcePointer ==ZeroDotZero then no bandwidth reservation needed) Some specific examples: ----------------------- 1. Assume that user configured a MPLS tunnel on a Diff-Serv aware LER. How will the LSR know what kind of LSP (L-LSP / E-LSP) to setup ? 2. How can the user determine what type of PSC is being carried on a specific L-LSP ? (Alternatively, how can a user request the LSR to establish a L-LSP for a specific PSC?) 3. How can user determine the details related to signaled EXP<->PHB mapping for a specific E-LSP ? If this issues has been already addressed, I will appreciate if you can help me with the answer to the above questions. Thanks, sanjay From owner-mpls@UU.NET Fri Jan 26 16:44:53 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22906 for ; Fri, 26 Jan 2001 16:44:52 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzrq10132; Fri, 26 Jan 2001 21:42:34 GMT Received: by mail-control.mail.uu.net id QQjzrq11471 for mpls-outgoing; Fri, 26 Jan 2001 21:41:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzrq11460 for ; Fri, 26 Jan 2001 21:41:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzrq12700 for ; Fri, 26 Jan 2001 21:41:32 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 QQjzrq27638 for ; Fri, 26 Jan 2001 21:41:32 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA19398 for ; Fri, 26 Jan 2001 16:41:31 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA03697 for ; Fri, 26 Jan 2001 16:41:32 -0500 (EST) Message-ID: <3A71EF31.9823C176@marconi.com> Date: Fri, 26 Jan 2001 16:42:09 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: LDP - question about partially setup LSPs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Here's a hypothetical network: A ----- B ----- C The network is running LDP and is configured for unordered, downstream unsolicited label distribution. Assume that the IGP knows about one prefix, which is reachable through router C. Suppose now, that B sends out a label mapping for this prefix, and C has not yet sent out its label mapping. A, since it has received a label mapping, decides to start labelling traffic for this prefix, and forwards it on to B. B now receives this traffic, but does not have a label mapping for the FEC. What should it do? I would assume, based on section 3.22 of RFC 3031 that router B should discard these packets until it receives a label mapping from C. A coworker here believes that router B should pop the label stack and forward the unlabeled packet based on its routing tables. He claims that section 3.22 doesn't really apply. His rationale is that: - We can assume no routing loops, because the LSP from ingress to this point is following the same IGP shortest path that it would be forwarding along. If there's a loop in the IGP, it will still be there after receiving a label mapping. - We know we'll be able to forwrad the packet based on its IP header, because router A used that same header against the same IGP tables when it determined the initial label for the packet. - C may (for some reason) choose to never send a label mapping for the prefix. Since the network is downstream unsolicited, it may never receive a request. It wouldn't make sense for this legal scenario to result in a black hole. I counter his arguments by claiming that: - We don't know there won't be routing loops. The IGP may not yet have converged to a stable state. When the last label mapping message is sent, the loop detection features of LDP (if turned on, of course) will detect it and prevent any traffic from flowing until the IGP stabilizes. - We can't assume that B has the same routing table that A and C has. If A and C are border routers, they may be running an EGP (like BGP) and know about far more prefixes than a core router, which would only be running an IGP (like OSPF). The FEC for the LSP may be one of C's addresses, and the packet destination may be an address many hops beyond C. B does not necessarily have any clue how to get to the destination address in the absence of the LSP. - C will eventually send a label mapping for everything in its routing table. It would be a broken implementation for it to arbitrarily choose to not map a prefix without deliberate operator intervention. If an operator chooses to configure this, then he probably intends to create a black hole. If he really wants the label to be popped, he can send a NULL label mapping an explicitly request it. So, which of us is correct here? -- David From owner-mpls@UU.NET Fri Jan 26 18:26:07 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24533 for ; Fri, 26 Jan 2001 18:26:07 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzrx21611; Fri, 26 Jan 2001 23:24:23 GMT Received: by mail-control.mail.uu.net id QQjzrx17740 for mpls-outgoing; Fri, 26 Jan 2001 23:23:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzrx17735 for ; Fri, 26 Jan 2001 23:23: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 QQjzrx21309 for ; Fri, 26 Jan 2001 23:19:49 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzrx20972 for ; Fri, 26 Jan 2001 23:19:49 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA26041 for mpls@uu.net; Fri, 26 Jan 2001 18:19:43 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzrx17516 for ; Fri, 26 Jan 2001 23:19:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQjzrx22586 for ; Fri, 26 Jan 2001 23:19:03 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQjzrx20022 for ; Fri, 26 Jan 2001 23:19:03 GMT Received: from cisco.com ([171.71.37.151]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA20489; Fri, 26 Jan 2001 15:18:34 -0800 (PST) Message-ID: <3A71F985.C0F58800@cisco.com> Date: Fri, 26 Jan 2001 14:26:13 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Radha PK CC: "mpls@uu.net" , "erosen@cisco.com" Subject: Re: Internet and VPN routes References: <20010126203547.26857.qmail@mailweb20.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Today for dynamic advertisement of customer's internet routes + internal vpn routes between CE-PE you have two EBGP sessions (one to the vrf + one to the global table) or a combination of ebgp to the global table + pe-ce igp to the vrf. R. > Radha PK wrote: > > Hi, > In the case of BGP/MPLS based layer 3 VPNs: > > If the customer is provided both internet and VPN service, how will BGP in the provider differentiate between the IPV4 routes (global addresses for internet) and VPN routes learnt from the CE, so that the internet routes are added in the internet routing table? > > Should RD be added at CE itself to differentiate routes for VPN and internet (RD zero)? > > Pls suggest as to how this case is handled. > > Thank u. > > With Regards. > Radha > > _____________________________________________________ > Chat with your friends as soon as they come online. Get Rediff Bol at > http://bol.rediff.com From owner-mpls@UU.NET Sat Jan 27 08:49:28 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15925 for ; Sat, 27 Jan 2001 08:49:28 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzud21412; Sat, 27 Jan 2001 13:48:51 GMT Received: by mail-control.mail.uu.net id QQjzud15367 for mpls-outgoing; Sat, 27 Jan 2001 13:48:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQjzud15343 for ; Sat, 27 Jan 2001 13:47:58 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 QQjzud11609 for ; Sat, 27 Jan 2001 13:47:42 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzud16784 for ; Sat, 27 Jan 2001 13:47:41 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA25394 for mpls@uu.net; Sat, 27 Jan 2001 08:47:41 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzud15310 for ; Sat, 27 Jan 2001 13:47:17 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 QQjzud21610 for ; Sat, 27 Jan 2001 13:46:46 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 QQjzud18556 for ; Sat, 27 Jan 2001 13:46:45 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA28724; Sat, 27 Jan 2001 08:46:20 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (ch-janeiro-p35.cisco.com [171.69.209.239]) by bucket.cisco.com (Mirapoint) with ESMTP id ABJ12646; Sat, 27 Jan 2001 08:46:37 -0500 (EST) Message-Id: <4.3.2.7.2.20010127084210.0205c008@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 27 Jan 2001 08:51:22 -0500 To: "Choudhury, Sanjaya" , cheenu Srinivasan , Arun Viswanathan , mpls@UU.NET From: "Thomas D. Nadeau" Subject: RE: Last call on MPLS TE MIB Cc: "Choudhury, Sanjaya" In-Reply-To: <4FBEA8857476D311A03300204840E1CF446BF8@whq-msgusr-02.pit.c omms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, >Hi! The current version of the MPLS-TE MIB does > not capture the QoS scheme (Int-Serv / DiffServ) > and the associated parameters being used by a > MPLS tunnel. Should the MPLS-TE be extended to > handle this ? No. The traffic parameters which are there were agreed upon a while ago, and are appropriate for what we were chartered to do. The MPLS-TE-MIB will not directly support DiffServ-aware TE because it is so new. We have been directed to finish up the MIB now, so waiting for the D-A-TE work to be completed by the WG(s) is not an option. I am preparing an extension to the TE MIB as a companion to the other DiffServ-aware TE documents I am working on with Francois et al. I will have it ready for the next IETF meeting. --Tom From owner-mpls@UU.NET Sat Jan 27 16:24:19 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18334 for ; Sat, 27 Jan 2001 16:24:19 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzvh16879; Sat, 27 Jan 2001 21:23:44 GMT Received: by mail-control.mail.uu.net id QQjzvh28094 for mpls-outgoing; Sat, 27 Jan 2001 21:23:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzvh28085 for ; Sat, 27 Jan 2001 21:23: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 QQjzvh20957 for ; Sat, 27 Jan 2001 21:22:21 GMT Received: from web1106.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web1106.mail.yahoo.com [128.11.23.126]) id QQjzvh14859 for ; Sat, 27 Jan 2001 21:22:21 GMT Received: (qmail 6399 invoked by uid 60001); 27 Jan 2001 21:22:20 -0000 Message-ID: <20010127212220.6398.qmail@web1106.mail.yahoo.com> Received: from [128.196.147.171] by web1106.mail.yahoo.com; Sat, 27 Jan 2001 13:22:20 PST Date: Sat, 27 Jan 2001 13:22:20 -0800 (PST) From: Samantha Quadros Subject: MPLS over FDDI To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi everyone, I'm a graduate student in the ECE dept. at the University of Arizona. I'm currently working with MPLS and 802.1q as part of my Master's thesis. I have simulated MPLS and 802.1q traffic over Ethernet and now I'm trying to do the same over FDDI. I'm trying to provide some performance benchmarks over the two networks. I'm a little confused though. I'm not sure where exactly the MPLS label is inserted in the frame (on Ethernet it is inserted between layer 2 and 3). I haven't found any literature to guide me on that aspect. If someone can point me to the documentation or let me know exactly where the MPLS label is placed, I'd appreciate it. Thanks Samantha __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ From owner-mpls@UU.NET Sat Jan 27 19:28:39 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19027 for ; Sat, 27 Jan 2001 19:28:38 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQjzvt22534; Sun, 28 Jan 2001 00:28:10 GMT Received: by mail-control.mail.uu.net id QQjzvt18650 for mpls-outgoing; Sun, 28 Jan 2001 00:27:23 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQjzvt18644 for ; Sun, 28 Jan 2001 00:27: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 QQjzvt24151 for ; Sun, 28 Jan 2001 00:26:55 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQjzvt23530 for ; Sun, 28 Jan 2001 00:26:54 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA15499 for mpls@uu.net; Sat, 27 Jan 2001 19:26:54 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQjzvt18595 for ; Sun, 28 Jan 2001 00:26:24 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQjzvt28459 for ; Sun, 28 Jan 2001 00:26:00 GMT Received: from yarilo.pluris.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pluris.com [208.227.9.12]) id QQjzvt25843 for ; Sun, 28 Jan 2001 00:26:00 GMT Received: from DL100779.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA21883; Sat, 27 Jan 2001 16:25:59 -0800 (PST) From: Bora Akyol MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14963.26383.818000.227770@gargle.gargle.HOWL> Date: Sat, 27 Jan 2001 16:25:51 -0800 To: Samantha Quadros Cc: mpls@UU.NET Subject: MPLS over FDDI In-Reply-To: <20010127212220.6398.qmail@web1106.mail.yahoo.com> References: <20010127212220.6398.qmail@web1106.mail.yahoo.com> X-Mailer: VM 6.90 under Emacs 20.7.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Insert it between FDDI frame and IP header. Bora >>>>> "Samantha" == Samantha Quadros writes: Samantha> Hi everyone, I'm a graduate student in the ECE Samantha> dept. at the University of Arizona. I'm currently Samantha> working with MPLS and 802.1q as part of my Samantha> Master's thesis. I have simulated MPLS and 802.1q Samantha> traffic over Ethernet and now I'm trying to do the Samantha> same over FDDI. I'm trying to provide some Samantha> performance benchmarks over the two networks. Samantha> I'm a little confused though. I'm not sure where Samantha> exactly the MPLS label is inserted in the frame Samantha> (on Ethernet it is inserted between layer 2 and Samantha> 3). I haven't found any literature to guide me on Samantha> that aspect. If someone can point me to the Samantha> documentation or let me know exactly where the Samantha> MPLS label is placed, I'd appreciate it. Samantha> Thanks Samantha Samantha> __________________________________________________ Samantha> Do You Yahoo!? Yahoo! Auctions - Buy the things Samantha> you want at great prices. Samantha> http://auctions.yahoo.com/ From owner-mpls@UU.NET Mon Jan 29 03:18:31 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28119 for ; Mon, 29 Jan 2001 03:18:31 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkaar27580; Mon, 29 Jan 2001 08:18:10 GMT Received: by mail-control.mail.uu.net id QQkaar14750 for mpls-outgoing; Mon, 29 Jan 2001 08:17:16 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkaar14745 for ; Mon, 29 Jan 2001 08:17:15 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 QQkaaq02273 for ; Mon, 29 Jan 2001 08:14:40 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkaaq20840 for ; Mon, 29 Jan 2001 08:14:40 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id DAA09680 for mpls@uu.net; Mon, 29 Jan 2001 03:14:39 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkaaq14322 for ; Mon, 29 Jan 2001 08:14: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 QQkaaq28838 for ; Mon, 29 Jan 2001 08:13:07 GMT Received: from cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: omega.cisco.com [171.69.63.141]) id QQkaaq15786 for ; Mon, 29 Jan 2001 08:13:06 GMT Received: from cisco.com (war-jer-dhcp82.cisco.com [144.254.89.252]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA17564; Mon, 29 Jan 2001 00:12:30 -0800 (PST) Message-ID: <3A7519AC.BC978CEE@cisco.com> Date: Sun, 28 Jan 2001 23:20:12 -0800 From: Robert Raszuk Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Radha PK CC: "erosen@cisco.com" , "mpls@uu.net" Subject: Re: Labelled route across AS References: <20010128132652.10360.qmail@mailweb21.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit First let me clarify - that by the "route" you mean the customer external not your peer's AS next hops. If that is the case I would not talk about "redistribution" as this at least to me means transfer a route from one routing protocol to the other but the more appropriate term would be "propagate" as all we are talking about here is a EBGP/IBGP propagation. So to answer your question about next hop both scenarios are possible and adopted. In the small Inter-AS architectures where number of inter-as routes does not exceed the capacity of edge box setting next hop on the edge is fine. When a number of routes grow and your vpnv4 ebgp session is being extended from vpnv4 RRs then setting nhs on them would not be advisable. R. > Radha PK wrote: > > Hi, > When a labelled route is received (by an ASBR) from a peer in a different AS, the route is redistributed into the AS. > During this redistribution, the NextHop (to the address of ASBR doing the redistribution) and also the label could be changed > Or > Just redistribute the label and the route as they were received from the ASBR. > > Could anyone suggest me as to which of these are usually adopted? > Pls correct me if my interpretations are wrong. > > With Regards. > Radha > > _____________________________________________________ > Chat with your friends as soon as they come online. Get Rediff Bol at > http://bol.rediff.com From owner-mpls@UU.NET Mon Jan 29 11:32:58 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05295 for ; Mon, 29 Jan 2001 11:32:58 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkaby00420; Mon, 29 Jan 2001 16:30:43 GMT Received: by mail-control.mail.uu.net id QQkaby03485 for mpls-outgoing; Mon, 29 Jan 2001 16:30:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkaby03479 for ; Mon, 29 Jan 2001 16:30:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkabx17797 for ; Mon, 29 Jan 2001 16:29:57 GMT Received: from hotmail.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe21.law10.hotmail.com [64.4.14.125]) id QQkabx14213 for ; Mon, 29 Jan 2001 16:29:57 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Jan 2001 08:29:56 -0800 X-Originating-IP: [12.124.181.202] From: "Frank Hujber" To: "MPLS Group" Subject: SRLG Date: Mon, 29 Jan 2001 11:33:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: X-OriginalArrivalTime: 29 Jan 2001 16:29:56.0909 (UTC) FILETIME=[B77FCDD0:01C08A10] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Folks, My attention to the list and to the I-Ds of late has been sketchy, so forgive me if this has been covered... In reading "draft-rs-optical-bundling-01.txt" it seems that it is necessary to have a state indicating the SRLG is not provisioned and should be ignored in processing. So might I suggest that this state be 0x00 in the SRLG field of the Link Group Object? This is justified by the notion that SRLG is, for now at least, a user-provisioned value and will be until interoperability between WDMs and OXCs/PXCs is established. Bala? Debanjan? Do you agree? Frank Hujber fhujber@hotmail.com From owner-mpls@UU.NET Mon Jan 29 11:59:25 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05811 for ; Mon, 29 Jan 2001 11:59:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkabz22244; Mon, 29 Jan 2001 16:57:33 GMT Received: by mail-control.mail.uu.net id QQkabz05916 for mpls-outgoing; Mon, 29 Jan 2001 16:57:01 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkabz05907 for ; Mon, 29 Jan 2001 16:56: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 QQkabz22357 for ; Mon, 29 Jan 2001 16:56:37 GMT Received: from abel.senecanetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: abel.senecanetworks.com [63.97.216.18]) id QQkabz25020 for ; Mon, 29 Jan 2001 16:56:37 GMT Received: from vsharmapc ([10.0.1.69]) by abel.senecanetworks.com (8.9.3/8.99.99) with SMTP id GAA08191; Mon, 29 Jan 2001 06:57:53 -0600 From: "Vipul Sharma" To: "'mpls@uu.net'" , , , Subject: RE:draft-ietf-mpls-icmp-02.txt Date: Mon, 29 Jan 2001 11:56:32 -0500 Message-ID: <001301c08a14$6ee08200$4501000a@vsharmapc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <3A7519AC.BC978CEE@cisco.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi!, Any thoughts on draft-ietf-mpls-icmp-02.txt? Is it becoming an RFC. I guess my question is where does this draft stand? Thanx. Vip From owner-mpls@UU.NET Mon Jan 29 13:13:30 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07031 for ; Mon, 29 Jan 2001 13:13:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkace19866; Mon, 29 Jan 2001 18:11:38 GMT Received: by mail-control.mail.uu.net id QQkace09040 for mpls-outgoing; Mon, 29 Jan 2001 18:11:03 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkace08981 for ; Mon, 29 Jan 2001 18:10:56 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkace20115 for ; Mon, 29 Jan 2001 18:10:46 GMT Received: from pefw00.ivmg.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.209.84.66]) id QQkace29720 for ; Mon, 29 Jan 2001 18:10:45 GMT Received: from pimx00.ivmg.net (pimx00.ivmg.net [192.168.0.10]) by pefw00.ivmg.net (iVMG) with ESMTP id f0TIAih38245; Mon, 29 Jan 2001 18:10:44 GMT Received: (from serge@localhost) by pimx00.ivmg.net (iVMG) id f0TIAix29916; Mon, 29 Jan 2001 10:10:44 -0800 Date: Mon, 29 Jan 2001 10:10:44 -0800 From: Serge Maskalik To: James_Huang@Mitel.COM Cc: Bora Akyol , mpls@UU.NET Subject: Re: PHP negotiation Message-ID: <20010129101044.G11040@ivmg.net> References: <852569DE.0079738F.00@kanmta01.software.mitel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <852569DE.0079738F.00@kanmta01.software.mitel.com>; from James_Huang@Mitel.COM on Wed, Jan 24, 2001 at 02:06:34PM -0800 Sender: owner-mpls@UU.NET Precedence: bulk Believe it or not, this used to be a major inter-operability problem between two major vendors. One major vendor singalled implicit null for all LSPs, _unless_ it was a single hop LSP in which case the explicit null was signalled to preserve the EXP field. The fact that the other vendor treated label 0 as implicit null did not help either ;) I think most folks would agree that php is a good default behavior. If folks want to do L-LSPs and not have to look at DSCPs for the sake of keeping policies equal across the board or want to maintain the encapsulation to the last hop for other reasons, global or per-LSP configuration options could exist. I do not see a need for a negotiation mechanism. - Serge Thus spake James_Huang@Mitel.COM (James_Huang@Mitel.COM): > > > From: James Huang@MITEL on 01/24/2001 02:06 PM PST > I found in sec 6 of RFC 3036 that PHP negotiation is an area of future study for > LDP. Is it also an area of future study for RSVP-TE? Before this negotiation > mechanism becomes available, I presume we can only reply on manual > configuration on a per peer basis. > > -- James Huang > > > > > > Bora Akyol on 01/24/2001 12:33:03 PM > > To: James Huang/USA/Mitel@Mitel > cc: Bora Akyol , mpls@UU.NET > > Subject: Re: PHP negotiation > > > > There is no such mechanism. The assumption is that the network > operator knows how to configure their equipment and they know > their network. > > Bora > > > >>>>> "James" == James Huang writes: > > James> From: James Huang@MITEL on 01/24/2001 12:03 PM PST Hi > James> Bora: Maybe I did not express my concern clear > James> enough. As you said, the LSP setup will fail when > James> the egress LSR assigns an Implicit NULL label to the > James> penultimate hop, if the penultinate hop does not > James> support PHP. So there should be some negotiation > James> mechanism in LDP or RSVP/TE such that an egress > James> router will know not to assign an Implicit NULL label > James> to a penultimate hop that does not support PHP. But > James> I can not find such mechanism in the documents. > > James> -- James Huang > > > > > > James> Bora Akyol on 01/23/2001 08:24:45 > James> PM > > James> To: James Huang/USA/Mitel@Mitel cc: mpls@UU.NET > > James> Subject: PHP negotiation > > > > > James> You should also read the label encapsulation > James> RFC. What happens is that the egress LSR assigns an > James> (...) NULL label (I think it should be Implicit Null) > James> to the penultimate hop, if penultimate hop does not > James> support this, then LSP setup should fail. > > James> There was a LOOONG discussion on this sometime last > James> year. > > James> Some people think this stuff is really clear. I think > James> that it is in about three different RFCs, and someone > James> needs to write a BCP that explains common usage and > James> tricks that network operators that use MPLS should > James> use. > > James> BTW, this question comes up about once a month on the > James> list, maybe we should have an MPLS FAQ. > > James> Bora > > > >>>>> "James" == James Huang writes: > > James> Hi all, The following paragraph is from Section > James> 3.16. (Penultimate Hop Popping) of RFC3031. > > > James> "Initial label distribution protocol negotiations > James> MUST allow each LSR to determine whether its > James> neighboring LSRS are capable of popping the label > James> stack. A LSR MUST NOT request a label distribution > James> peer to pop the label stack unless it is capable of > James> doing so." > > James> However, I can not find any mechanism in LDP/CR-LDP > James> or RSVP-TE to accomplish this PHP negotiation. > > James> Am I missing something here? > > > > James> -- James Huang > > > > > > > > > > > From owner-mpls@UU.NET Mon Jan 29 17:04:53 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10602 for ; Mon, 29 Jan 2001 17:04:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkacu12433; Mon, 29 Jan 2001 22:02:54 GMT Received: by mail-control.mail.uu.net id QQkacu15502 for mpls-outgoing; Mon, 29 Jan 2001 22:02:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkacu15466 for ; Mon, 29 Jan 2001 22:02:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkacu29778 for ; Mon, 29 Jan 2001 22:01:42 GMT Received: from develop.eu.level3.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: develop.eu.level3.net [212.113.1.30]) id QQkacu26994 for ; Mon, 29 Jan 2001 22:01:42 GMT Received: from develop.eu.level3.net ([212.113.1.30] helo=level3.net) by develop.eu.level3.net with esmtp (Exim 2.05 #2) id 14NMMm-00037v-00; Mon, 29 Jan 2001 22:01:40 +0000 Message-ID: <3A75E855.7B09FE95@level3.net> Date: Mon, 29 Jan 2001 22:01:57 +0000 From: Giles Heron Organization: Level 3 Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: mpls@UU.NET Subject: Re: LDP - question about partially setup LSPs References: <3A71EF31.9823C176@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit I would agree with you on this one. Your second point is key. How can you know that the destination address in the packet is an IGP prefix? I suspect that many networks will want to run BGP edge-to-edge, but to have only IGP routes in the core. In addition to this you have the issue of MPLS VPN and Layer 2 over MPLS traffic. Either one of these will generate a label stack in which the innermost label is assigned edge-to-edge and is not visible to the intermediate devices. Giles David Charlap wrote: > > Here's a hypothetical network: > > A ----- B ----- C > > The network is running LDP and is configured for unordered, downstream > unsolicited label distribution. > > Assume that the IGP knows about one prefix, which is reachable through > router C. > > Suppose now, that B sends out a label mapping for this prefix, and C has > not yet sent out its label mapping. > > A, since it has received a label mapping, decides to start labelling > traffic for this prefix, and forwards it on to B. > > B now receives this traffic, but does not have a label mapping for the > FEC. What should it do? > > I would assume, based on section 3.22 of RFC 3031 that router B should > discard these packets until it receives a label mapping from C. > > A coworker here believes that router B should pop the label stack and > forward the unlabeled packet based on its routing tables. He claims > that section 3.22 doesn't really apply. His rationale is that: > > - We can assume no routing loops, because the LSP from ingress > to this point is following the same IGP shortest path that > it would be forwarding along. If there's a loop in the IGP, > it will still be there after receiving a label mapping. > > - We know we'll be able to forwrad the packet based on its IP > header, because router A used that same header against the > same IGP tables when it determined the initial label for the > packet. > > - C may (for some reason) choose to never send a label mapping > for the prefix. Since the network is downstream unsolicited, > it may never receive a request. It wouldn't make sense for > this legal scenario to result in a black hole. > > I counter his arguments by claiming that: > > - We don't know there won't be routing loops. The IGP may not > yet have converged to a stable state. When the last label > mapping message is sent, the loop detection features of LDP > (if turned on, of course) will detect it and prevent any > traffic from flowing until the IGP stabilizes. > > - We can't assume that B has the same routing table that A and > C has. If A and C are border routers, they may be running an > EGP (like BGP) and know about far more prefixes than a core > router, which would only be running an IGP (like OSPF). > > The FEC for the LSP may be one of C's addresses, and the > packet destination may be an address many hops beyond C. B > does not necessarily have any clue how to get to the > destination address in the absence of the LSP. > > - C will eventually send a label mapping for everything in its > routing table. It would be a broken implementation for it to > arbitrarily choose to not map a prefix without deliberate > operator intervention. If an operator chooses to configure > this, then he probably intends to create a black hole. If > he really wants the label to be popped, he can send a NULL > label mapping an explicitly request it. > > So, which of us is correct here? > > -- David -- =================================================== Giles Heron - IP Architect - Level 3 Communications phone: +44 20 7864 0719 mobile: +44 7880 506185 =================================================== From owner-mpls@UU.NET Mon Jan 29 20:41:15 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13642 for ; Mon, 29 Jan 2001 20:41:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkadi03496; Tue, 30 Jan 2001 01:40:49 GMT Received: by mail-control.mail.uu.net id QQkadi17729 for mpls-outgoing; Tue, 30 Jan 2001 01:40:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkadi17719 for ; Tue, 30 Jan 2001 01:40:00 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 QQkadi25391 for ; Tue, 30 Jan 2001 01:38:37 GMT Received: from NOD.RESTON.MCI.NET by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [166.60.6.38]) id QQkadi26241 for ; Tue, 30 Jan 2001 01:38:37 GMT Received: from rbonica ([166.60.18.132]) by shoe.reston.mci.net (PMDF V6.0-24 #47392) with SMTP id <01JZHQYS8SFA9QURDZ@shoe.reston.mci.net> for mpls@UU.NET; Mon, 29 Jan 2001 20:38:36 -0500 (EST) Date: Mon, 29 Jan 2001 20:28:21 -0500 From: Ron Bonica Subject: RE: draft-ietf-mpls-icmp-02.txt In-reply-to: <001301c08a14$6ee08200$4501000a@vsharmapc> To: Vipul Sharma , "'mpls@uu.net'" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7BIT Vipul, The IESG has rejected draft-ietf-mpls-icmp-02. Alternatively, they have initiated a design team to investigate the more generic problem of tracing through tunnels. So far, the design team has generated a requirements document (draft-bonica-tunneltrace-00). A protocol specification is forthcoming. Discussion of the requirements document and the protocol specification has moved to tv-area@ops.ietf.org. Thanks, Ron > -----Original Message----- > From: Vipul Sharma [mailto:vsharma@senecanetworks.com] > Sent: Monday, January 29, 2001 11:57 AM > To: 'mpls@uu.net'; rbonica@mci.net; tappan@cisco.com; dhg@juniper.net > Subject: RE:draft-ietf-mpls-icmp-02.txt > > > Hi!, > Any thoughts on draft-ietf-mpls-icmp-02.txt? Is it becoming > an RFC. I guess > my question is where does this draft stand? Thanx. > > Vip > From owner-mpls@UU.NET Tue Jan 30 05:12:42 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02824 for ; Tue, 30 Jan 2001 05:12:42 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkaeq25720; Tue, 30 Jan 2001 10:12:07 GMT Received: by mail-control.mail.uu.net id QQkaeq17839 for mpls-outgoing; Tue, 30 Jan 2001 10:11:36 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkaeq17834 for ; Tue, 30 Jan 2001 10:11: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 QQkaeq18775 for ; Tue, 30 Jan 2001 10:11:20 GMT Received: from malmo.trab.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: malmo.trab.se [131.115.48.10]) id QQkaeq24570 for ; Tue, 30 Jan 2001 10:11:19 GMT Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f0UABF400501; Tue, 30 Jan 2001 11:11:15 +0100 (MET) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Tue, 30 Jan 2001 11:11:13 +0100 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D01E7DFA3@trab-hermes.haninge.trab.se> From: Olle Pers To: "'Giles Heron'" Cc: mpls@UU.NET, David Charlap Subject: RE: LDP - question about partially setup LSPs Date: Tue, 30 Jan 2001 11:11:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk * * I would agree with you on this one. * Well, here is one that would not agree, without more convincing arguments. * Your second point is key. How can you know that the * destination address in the packet is an IGP prefix? * I suspect that many networks will want to run BGP * edge-to-edge, but to have only IGP routes in the core. * The IGP knew the prefix, and B had sent out a label mapping for it. That was the scenario in David's question. So the router B knows how to forward unlabeled packets with this prefix. And it did send out a label mapping for exactly the same prefix, knowing that it didn't have any corresponding downstream label yet. Why? I don't want to think B did that just in order to drop these packets. * In addition to this you have the issue of MPLS VPN and Layer * 2 over MPLS traffic. Either one of these will generate a * label stack in which the innermost label is assigned edge-to- * edge and is not visible to the intermediate devices. * These applications require that there exists an edge-to-edge LSP which can be used as a tunnel. We cannot assume them to work, before the setup of this LSP is completed. And with unordered control, the ingress will not know when this has happened. But why use unordered control at all, if it leads to problems? What's the application? * * Giles * Olle Pers Telia, Sweden From owner-mpls@UU.NET Tue Jan 30 08:22:45 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05090 for ; Tue, 30 Jan 2001 08:22:45 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkafd22617; Tue, 30 Jan 2001 13:21:52 GMT Received: by mail-control.mail.uu.net id QQkafd09180 for mpls-outgoing; Tue, 30 Jan 2001 13:21:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkafd09135 for ; Tue, 30 Jan 2001 13:21: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 QQkafd10251 for ; Tue, 30 Jan 2001 13:20:51 GMT Received: from develop.eu.level3.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: develop.eu.level3.net [212.113.1.30]) id QQkafd09774 for ; Tue, 30 Jan 2001 13:20:50 GMT Received: from develop.eu.level3.net ([212.113.1.30] helo=level3.net) by develop.eu.level3.net with esmtp (Exim 2.05 #2) id 14Nai8-0006ri-00; Tue, 30 Jan 2001 13:20:40 +0000 Message-ID: <3A76BFB9.12D9DC9@level3.net> Date: Tue, 30 Jan 2001 13:20:57 +0000 From: Giles Heron Organization: Level 3 Communications X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: Olle Pers CC: mpls@UU.NET, David Charlap Subject: Re: LDP - question about partially setup LSPs References: <778DFE9B4E3BD111A74E08002BA3DC0D01E7DFA3@trab-hermes.haninge.trab.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Olle Pers wrote: [snip] > * Your second point is key. How can you know that the > * destination address in the packet is an IGP prefix? > * I suspect that many networks will want to run BGP > * edge-to-edge, but to have only IGP routes in the core. > * > The IGP knew the prefix, and B had sent out a label mapping > for it. That was the scenario in David's question. > So the router B knows how to forward unlabeled packets with this prefix. And > it did send out a label mapping for exactly the same prefix, knowing that it > didn't have any corresponding downstream label yet. Why? I don't want to > think B did that just in order to drop these packets. Yes, that is the situation in David's question. However, as I see it the problem with allowing the router to attempt to forward the packet unlabelled is that it will work in some situations and not in others - so it is difficult to debug. I have already seen one situation where a router was forwarding traceroutes happily along a "broken" LSP (and forwarding the packet as IP from the point where the LSP broke onwards) but was unable to forward MPLS VPN traffic. A similar result would have occurred with Internet traffic being forwarded over a BGP-less MPLS core. > * In addition to this you have the issue of MPLS VPN and Layer > * 2 over MPLS traffic. Either one of these will generate a > * label stack in which the innermost label is assigned edge-to- > * edge and is not visible to the intermediate devices. > * > These applications require that there exists an edge-to-edge LSP which can > be used as a tunnel. We cannot assume them to work, before the setup of this > LSP is completed. And with unordered control, the ingress will not know when > this has happened. > > But why use unordered control at all, if it leads to problems? What's the > application? My understanding of ordered control is that it leads to longer convergence times than unordered/independent control? If the application is layer 2 circuit emulation one would hope to have convergence times which are similar to those that can be achieved with native layer 2 techniques (such as PNNI.) Giles -- =================================================== Giles Heron - IP Architect - Level 3 Communications phone: +44 20 7864 0719 mobile: +44 7880 506185 =================================================== From owner-mpls@UU.NET Tue Jan 30 08:36:20 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05462 for ; Tue, 30 Jan 2001 08:36:20 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkafe12855; Tue, 30 Jan 2001 13:35:57 GMT Received: by mail-control.mail.uu.net id QQkafe10269 for mpls-outgoing; Tue, 30 Jan 2001 13:35:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkafe10262 for ; Tue, 30 Jan 2001 13:35:10 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 QQkafe12019 for ; Tue, 30 Jan 2001 13:34:26 GMT Received: from mail.marhold.at by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail.marhold.at [194.152.126.85]) id QQkafe10666 for ; Tue, 30 Jan 2001 13:34:25 GMT Received: from amarhold ([192.168.1.33]) by mail.marhold.at (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id at; Tue, 30 Jan 2001 14:43:07 +0100 Reply-To: From: "Alexander Marhold" To: "'Olle Pers'" , "'Giles Heron'" Cc: , "'David Charlap'" Subject: RE: LDP - question about partially setup LSPs Date: Tue, 30 Jan 2001 14:34:19 +0100 Message-ID: <001901c08ac1$59bc7ca0$2101a8c0@amarhold.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <778DFE9B4E3BD111A74E08002BA3DC0D01E7DFA3@trab-hermes.haninge.trab.se> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit to add my points into the discussion: Let us assume that the middle router does aggregation ! Now the packet enters the middle router labelled and he cannot have a direct outgoing labelled path as he has not got labels for the summary but only for the specific destinations for forwarding the packet. Therefore whenever he receives a labelled packet and does not have any outgoing label for that he has to remove the label and do a normal layer-3 lookup in his routing table. If that lookup fails he drops the packet and tries sending back an ICMP destination unrechable. Assuming ordered LSP control it would be nearly impossible to detect such situation and if the path is now complete or not. Therefore in normal MPLS-frame based routing environments it is not implemented. ----------------- I agree that for MPLS/VPN where the middle routers have no knowledge about the detsinations this is not optimal, and an "ordered LSP control" could prevent that, but it is up to the implementer of the MPLS code to decide on this. with best regards Alexander Marhold Senior Consultant PRO IN > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf > Of Olle Pers > Sent: Tuesday, January 30, 2001 11:11 AM > To: 'Giles Heron' > Cc: mpls@UU.NET; David Charlap > Subject: RE: LDP - question about partially setup LSPs > > > > * > * I would agree with you on this one. > * > Well, here is one that would not agree, without more > convincing arguments. > > > * Your second point is key. How can you know that the > * destination address in the packet is an IGP prefix? > * I suspect that many networks will want to run BGP > * edge-to-edge, but to have only IGP routes in the core. > * > The IGP knew the prefix, and B had sent out a label mapping > for it. That was the scenario in David's question. > So the router B knows how to forward unlabeled packets with > this prefix. And > it did send out a label mapping for exactly the same prefix, > knowing that it > didn't have any corresponding downstream label yet. Why? I > don't want to > think B did that just in order to drop these packets. > > > * In addition to this you have the issue of MPLS VPN and Layer > * 2 over MPLS traffic. Either one of these will generate a > * label stack in which the innermost label is assigned edge-to- > * edge and is not visible to the intermediate devices. > * > These applications require that there exists an edge-to-edge > LSP which can > be used as a tunnel. We cannot assume them to work, before > the setup of this > LSP is completed. And with unordered control, the ingress > will not know when > this has happened. > > > But why use unordered control at all, if it leads to > problems? What's the > application? > > > * > * Giles > * > > Olle Pers > Telia, Sweden > From owner-mpls@UU.NET Tue Jan 30 12:54:29 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14130 for ; Tue, 30 Jan 2001 12:54:29 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkafv25063; Tue, 30 Jan 2001 17:51:49 GMT Received: by mail-control.mail.uu.net id QQkafv25444 for mpls-outgoing; Tue, 30 Jan 2001 17:51:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkafv25422 for ; Tue, 30 Jan 2001 17:51:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkafv08543 for ; Tue, 30 Jan 2001 17:50:47 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkafv20577 for ; Tue, 30 Jan 2001 17:50:46 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id MAA24411 for mpls@uu.net; Tue, 30 Jan 2001 12:50:45 -0500 (EST) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkafv25337 for ; Tue, 30 Jan 2001 17:50: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 QQkafv01239 for ; Tue, 30 Jan 2001 17:50:09 GMT Received: from pilgrim.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkafv19595 for ; Tue, 30 Jan 2001 17:50:07 GMT Received: from rbradfor-w2k.cisco.com (ch2-dhcp134-185.cisco.com [161.44.134.185]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA25026; Tue, 30 Jan 2001 12:50:03 -0500 (EST) Message-Id: <4.3.2.7.2.20010130123454.038192f8@pilgrim.cisco.com> X-Sender: rbradfor@pilgrim.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Jan 2001 12:47:20 -0500 To: Martin Dubuc From: "Bradford, Richard" Subject: Re: LMP-MIB Cc: "'mpls@UU.NET'" In-Reply-To: <89E067900D3FA84A97495C71556140E40A1B2E@edgsvr01.edgeflow.e dgeflow.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk One major issue with this MIB is the creation of link bundles in an LMP-specific MIB. Link Bundles are used by other protocols and should also be useful in scenarios without LMP. It would seem better to spin it out as a more general link bundling table (assuming work on such a table isn't already in progress elsewhere.) From owner-mpls@UU.NET Tue Jan 30 14:33:13 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16301 for ; Tue, 30 Jan 2001 14:33:13 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkagc16745; Tue, 30 Jan 2001 19:30:22 GMT Received: by mail-control.mail.uu.net id QQkagb03494 for mpls-outgoing; Tue, 30 Jan 2001 19:29:52 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkagb03479 for ; Tue, 30 Jan 2001 19:29:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkagb26324 for ; Tue, 30 Jan 2001 19:28:47 GMT Received: from edgeflow.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.191.40.82]) id QQkagb14249 for ; Tue, 30 Jan 2001 19:28:46 GMT Received: from edgsvr01.edgeflow.edgeflow.com ([10.0.1.10]) by watchdog.edgeflow.com with ESMTP id <119041>; Tue, 30 Jan 2001 14:28:40 -0500 Received: by edgsvr01.edgeflow.edgeflow.com with Internet Mail Service (5.5.2650.21) id ; Tue, 30 Jan 2001 14:25:36 -0500 Message-ID: <89E067900D3FA84A97495C71556140E40A1B56@edgsvr01.edgeflow.edgeflow.com> From: Martin Dubuc To: "'Bradford, Richard'" Cc: "'mpls@UU.NET'" , "Thomas D. Nadeau (E-mail)" Subject: RE: LMP-MIB Date: Tue, 30 Jan 2001 14:25:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Richard, I agree with you. Link bundles are not LMP specific and it does make sense to spin them off in a separate MIB. I have drafted a link bundling MIB that can also be used for OSPF and MPLS, but it is not yet ready to be published at the IETF site. I will post it to the list as soon as it is ready (within a week or two). The LMP-MIB will need to be revisited in light of the link bundling MIB. Martin -----Original Message----- From: Bradford, Richard [mailto:rbradfor@cisco.com] Sent: Tuesday, January 30, 2001 12:47 PM To: Martin Dubuc Cc: 'mpls@UU.NET' Subject: Re: LMP-MIB One major issue with this MIB is the creation of link bundles in an LMP-specific MIB. Link Bundles are used by other protocols and should also be useful in scenarios without LMP. It would seem better to spin it out as a more general link bundling table (assuming work on such a table isn't already in progress elsewhere.) From owner-mpls@UU.NET Tue Jan 30 14:47:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16505 for ; Tue, 30 Jan 2001 14:47:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkagc24930; Tue, 30 Jan 2001 19:44:47 GMT Received: by mail-control.mail.uu.net id QQkagc05507 for mpls-outgoing; Tue, 30 Jan 2001 19:44:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkagc05496 for ; Tue, 30 Jan 2001 19:44: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 QQkagc29056 for ; Tue, 30 Jan 2001 19:43:38 GMT From: wesam.alanqar@mail.sprint.com Received: from kcmgwp01.corp.sprint.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.18.122.165]) id QQkagc15605 for ; Tue, 30 Jan 2001 19:43:37 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by kcmgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f0UJhax00882 for ; Tue, 30 Jan 2001 13:43:36 -0600 (CST) Received: from kcopmp02.corp.sprint.com (kcopmp02m.corp.sprint.com [10.74.2.73]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f0UJhav26345 for ; Tue, 30 Jan 2001 13:43:36 -0600 (CST) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id NAA28957 for ; Tue, 30 Jan 2001 13:43:36 -0600 (CST) X-OpenMail-Hops: 1 Date: Tue, 30 Jan 2001 13:43:35 -0600 Message-Id: Subject: Updates on MPLS network management MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-1a5f74e0-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-1a5f74e0-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Tue, 30 Jan 2001 13:43:35 -0600" Content-Transfer-Encoding: 8bit All, What is the recent work/progress in MPLS management/service provisioning? Are the following drafts the only recent ones? draft-ietf-mpls-te-mib-05 draft-ietf-mpls-lsr-mib-07 nadeau-mpls-vpn-mib-00 Any progress about COPS? Thanks. ------------------------------------------------------------------------ ----------- Wesam Alanqar Member of Technical Staff Technology Concepts, Innovations & Evaluation Group Technology Planning & Integration Dept. (TP&I) Sprint 9300 Metcalf Avenue, KS 66212 Phone: 913-534-5623 Work, Fax: 913-534-3485 ------------------------------------------------------------------------ ----------- --openmail-part-1a5f74e0-00000001 Content-Type: application/octet-stream Content-Disposition: attachment; filename="Wesam Alanqar (E-mail).vcf" ;Creation-Date="Tue, 30 Jan 2001 13:43:35 -0600" Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkFsYW5xYXI7V2VzYW0NCkZOOldlc2FtIEFs YW5xYXIgKEUtbWFpbCkNCk9SRzpUZWNobm9sb2d5IFBsYW5uaW5nICYgSW50ZWdyYXRpb24t U3ByaW50O1RlY2hub2xvZ3kgUGxhbm5pbmcgJiBJbnRlZ3JhdGlvbg0KVElUTEU6TWVtYmVy IG9mIFRlY2huaWNhbCBTdGFmZg0KVEVMO1dPUks7Vk9JQ0U6KDkxMykgNTM0LTU2MjMNClRF TDtXT1JLO0ZBWDooOTEzKSA1MzQtMzQ4NQ0KQURSO1dPUks6Ozg1MTs5MzAwIE1ldGNhbGYg QXZlbnVlO092ZXJsYW5kIFBhcms7S1M7NjYyMTItMTQ2MztVbml0ZWQgU3RhdGVzIG9mIEFt ZXJpY2ENCkxBQkVMO1dPUks7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTo4NTE9MEQ9MEE5 MzAwIE1ldGNhbGYgQXZlbnVlPTBEPTBBT3ZlcmxhbmQgUGFyaywgS1MgNjYyMTItMTQ2Mz0w RD0wQVVuaXRlZCBTPQ0KdGF0ZXMgb2YgQW1lcmljYQ0KRU1BSUw7UFJFRjtJTlRFUk5FVDp3 ZXNhbS5hbGFucWFyQG1haWwuc3ByaW50LmNvbQ0KUkVWOjIwMDEwMTI5VDE4MjEyN1oNCkVO RDpWQ0FSRA0K --openmail-part-1a5f74e0-00000001-- From owner-mpls@UU.NET Tue Jan 30 15:23:34 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17179 for ; Tue, 30 Jan 2001 15:23:34 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkagf10750; Tue, 30 Jan 2001 20:21:30 GMT Received: by mail-control.mail.uu.net id QQkagf22543 for mpls-outgoing; Tue, 30 Jan 2001 20:21:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkagf22532 for ; Tue, 30 Jan 2001 20:20:59 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 QQkagf07180 for ; Tue, 30 Jan 2001 20:20:48 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkagf09987 for ; Tue, 30 Jan 2001 20:20:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA07123 for mpls@uu.net; Tue, 30 Jan 2001 15:20:41 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkagf22487 for ; Tue, 30 Jan 2001 20:20:17 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 QQkagf12272 for ; Tue, 30 Jan 2001 20:18:55 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 QQkagf22104 for ; Tue, 30 Jan 2001 20:18:55 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA23080; Tue, 30 Jan 2001 15:18:32 -0500 (EST) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-223.cisco.com [161.44.134.223]) by bucket.cisco.com (Mirapoint) with ESMTP id ABJ37551; Tue, 30 Jan 2001 15:18:54 -0500 (EST) Message-Id: <4.3.2.7.2.20010130152226.04b210b8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Jan 2001 15:23:57 -0500 To: wesam.alanqar@mail.sprint.com, mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: Updates on MPLS network management In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Hi, >What is the recent work/progress in MPLS management/service >provisioning? >Are the following drafts the only recent ones? >draft-ietf-mpls-te-mib-05 >draft-ietf-mpls-lsr-mib-07 >nadeau-mpls-vpn-mib-00 There is also the draft-ietf-mpls-ftn-mib-00.txt. >Any progress about COPS? This is the wrong WG to ask about COPS progress. --Tom From owner-mpls@UU.NET Tue Jan 30 18:30:48 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19199 for ; Tue, 30 Jan 2001 18:30:48 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkagr04093; Tue, 30 Jan 2001 23:27:56 GMT Received: by mail-control.mail.uu.net id QQkagr02345 for mpls-outgoing; Tue, 30 Jan 2001 23:27:25 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkagr02337 for ; Tue, 30 Jan 2001 23:27:21 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 QQkagr15314 for ; Tue, 30 Jan 2001 23:26:22 GMT Received: from pulsar.chromisys.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: 200-139.adsl6.netlojix.net [207.71.200.139] (may be forged)) id QQkagr21649 for ; Tue, 30 Jan 2001 23:26:22 GMT Received: by pulsar.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Jan 2001 15:24:41 -0800 Message-ID: From: Jonathan Lang To: "'Martin Dubuc'" , "'Bradford, Richard'" Cc: "'mpls@UU.NET'" , "Thomas D. Nadeau (E-mail)" Subject: RE: LMP-MIB Date: Tue, 30 Jan 2001 15:24:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Richard and Martin, In talking with Sudheer, we thought we remembered Kireeti saying he was going to add Link Bundling to the MPLS TE MIB. This should be verified before a separate Link Bundling MIB is written. I agree that this should not be a part of the LMP MIB. Thanks, Jonathan > -----Original Message----- > From: Martin Dubuc [mailto:martin.dubuc@edgeflow.com] > Sent: Tuesday, January 30, 2001 11:26 AM > To: 'Bradford, Richard' > Cc: 'mpls@UU.NET'; Thomas D. Nadeau (E-mail) > Subject: RE: LMP-MIB > > > Richard, > > I agree with you. Link bundles are not LMP specific and it > does make sense > to spin them off in a separate MIB. I have drafted a link > bundling MIB that > can also be used for OSPF and MPLS, but it is not yet ready > to be published > at the IETF site. I will post it to the list as soon as it is > ready (within > a week or two). > > The LMP-MIB will need to be revisited in light of the link > bundling MIB. > > Martin > > -----Original Message----- > From: Bradford, Richard [mailto:rbradfor@cisco.com] > Sent: Tuesday, January 30, 2001 12:47 PM > To: Martin Dubuc > Cc: 'mpls@UU.NET' > Subject: Re: LMP-MIB > > > One major issue with this MIB is the creation of link bundles in an > LMP-specific MIB. > Link Bundles are used by other protocols and should also be useful in > scenarios without LMP. It would seem better to spin it out as a more > general link bundling table (assuming work on such a table > isn't already in > progress elsewhere.) > From owner-mpls@UU.NET Tue Jan 30 18:55:02 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19392 for ; Tue, 30 Jan 2001 18:55:02 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkagt23474; Tue, 30 Jan 2001 23:53:02 GMT Received: by mail-control.mail.uu.net id QQkagt04857 for mpls-outgoing; Tue, 30 Jan 2001 23:52:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkagt04847 for ; Tue, 30 Jan 2001 23:52:12 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 QQkagt22846 for ; Tue, 30 Jan 2001 23:52:12 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkagt21770 for ; Tue, 30 Jan 2001 23:52:10 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA21848 for mpls@uu.net; Tue, 30 Jan 2001 18:52:10 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkagt04791 for ; Tue, 30 Jan 2001 23:51: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 QQkagt18712 for ; Tue, 30 Jan 2001 23:50:21 GMT Received: from brixcorp2.brixnet.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [216.91.233.5]) id QQkagt25210 for ; Tue, 30 Jan 2001 23:50:21 GMT Received: by brixcorp2.brixnet.com with Internet Mail Service (5.5.2650.21) id ; Tue, 30 Jan 2001 18:50:21 -0500 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB9B7F24@brixcorp2.brixnet.com> From: "Cucchiara, Joan" To: "'wesam.alanqar@mail.sprint.com'" , mpls@UU.NET Cc: "'franr@pfn.com'" Subject: RE: Updates on MPLS network management Date: Tue, 30 Jan 2001 18:50:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk > -----Original Message----- > From: wesam.alanqar@mail.sprint.com > [mailto:wesam.alanqar@mail.sprint.com] > Sent: Tuesday, January 30, 2001 2:44 PM > To: mpls@UU.NET > Subject: Updates on MPLS network management > > > All, > > What is the recent work/progress in MPLS management/service > provisioning? There are SNMP MIBs for element/device management, but to gather stats on a complete MPLS LSP (for example) there is nothing for that, except to query each device individually. > Are the following drafts the only recent ones? > draft-ietf-mpls-te-mib-05 > draft-ietf-mpls-lsr-mib-07 > nadeau-mpls-vpn-mib-00 There is also a MIB to configure and manage the MPLS LDP protocol, draft-ietf-mpls-ldp-mib-07. > > Any progress about COPS? There have been a few attempts to have COPS work adopted by the MPLS working group but to my knowledge these have not been successful. One draft you may want to check out is: draft-franr-mpls-cops-00.txt -Joan > > Thanks. > > -------------------------------------------------------------- > ---------- > ----------- > Wesam Alanqar Member of Technical Staff > Technology Concepts, Innovations & Evaluation Group > Technology Planning & Integration Dept. (TP&I) > Sprint > 9300 Metcalf Avenue, KS 66212 > Phone: 913-534-5623 Work, Fax: 913-534-3485 > -------------------------------------------------------------- > ---------- > ----------- > > From owner-mpls@UU.NET Wed Jan 31 05:03:57 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08645 for ; Wed, 31 Jan 2001 05:03:57 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkaii25293; Wed, 31 Jan 2001 10:03:15 GMT Received: by mail-control.mail.uu.net id QQkaii23670 for mpls-outgoing; Wed, 31 Jan 2001 10:02:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkaii23598 for ; Wed, 31 Jan 2001 10:02: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 QQkaii28478 for ; Wed, 31 Jan 2001 10:02:40 GMT Received: from malmo.trab.se by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: malmo.trab.se [131.115.48.10]) id QQkaii09763 for ; Wed, 31 Jan 2001 10:02:30 GMT Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f0VA2E405260; Wed, 31 Jan 2001 11:02:14 +0100 (MET) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Wed, 31 Jan 2001 11:02:13 +0100 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D01E7DFA8@trab-hermes.haninge.trab.se> From: Olle Pers To: "'alexander@marhold.at'" Cc: mpls@UU.NET, "'David Charlap'" , "'Giles Heron'" Subject: RE: LDP - question about partially setup LSPs Date: Wed, 31 Jan 2001 11:02:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk * * Let us assume that the middle router does aggregation ! * * Now the packet enters the middle router labelled * and he cannot have a direct outgoing * labelled path as he has not got labels * for the summary but only for the * specific destinations for forwarding the packet. * That is a different problem. With basic LDP, all routers should have the same IGP routing table. * Therefore whenever he receives a labelled packet * and does not have any outgoing label for that he * has to remove the label and do a normal layer-3 * lookup in his routing table. * Yes that would be a third option. (And if this layer-3 lookup identifies an outgoing interface, should the packet be sent out on that interface, or should it be dropped anyway?) But back to the original question: Section 3.22 of RFC 3031 applies when the incoming label does not map to an NHLFE. This is not necessarily the same as having no outgoing label. In David's example, the incoming label would map to an NHLFE containing the next hop "router C" and the operation "pop the label stack". When B later receives the label mapping from C, that NHLFE will be changed to contain a "replace label" operation. Olle From owner-mpls@UU.NET Wed Jan 31 05:20:15 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08757 for ; Wed, 31 Jan 2001 05:20:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkaij27267; Wed, 31 Jan 2001 10:19:45 GMT Received: by mail-control.mail.uu.net id QQkaij01998 for mpls-outgoing; Wed, 31 Jan 2001 10:19:14 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkaij01984 for ; Wed, 31 Jan 2001 10:19:02 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 QQkaij13670 for ; Wed, 31 Jan 2001 10:16:41 GMT Received: from wiproecmx2.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiproecmx2.wipro.com [164.164.31.6]) id QQkaij28558 for ; Wed, 31 Jan 2001 10:16:33 GMT Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id PAA14413 for ; Wed, 31 Jan 2001 15:56:09 GMT Received: from ecvwall1.wipro.com ([192.168.181.23]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA5611 for ; Wed, 31 Jan 2001 15:44:55 +0530 Received: from wipro.com ([192.168.220.54]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA1F84; Wed, 31 Jan 2001 15:41:45 +0530 Message-ID: <3A77E640.F582DC3A@wipro.com> Date: Wed, 31 Jan 2001 15:47:37 +0530 From: "Amarnath Honnavalli Anantharamaiah" X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET CC: Bob Thomas Subject: LDP Specification draft - Loop detection. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A.1.11. Receive Notification / Loop Detected Summary: When an LSR receives a Loop Detected Status Code from an LDP peer in response to a Label Request message or a Label Mapping message, it behaves as if it had received a No Route notification. Context: See "Receive Notification / No Route". Algorithm: See "Receive Notification / No Route" Notes: 1. When the Loop Detected notification is in response to a Label Request message, it arrives in a Status Code TLV in a Notification message. When it is in response to a Label Mapping message, it arrives in a Status Code TLV in a Label Release message. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1] In the above section, Notes 1., It is told that When it is in response to a Label mapping message, it arrives in Status Code TLV of Label Release message, But Label Release message does not have Status Code TLV -not even as optional parameter ????? Regards Amar From owner-mpls@UU.NET Wed Jan 31 09:11:25 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14142 for ; Wed, 31 Jan 2001 09:11:25 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkaiy04847; Wed, 31 Jan 2001 14:08:54 GMT Received: by mail-control.mail.uu.net id QQkaiy09208 for mpls-outgoing; Wed, 31 Jan 2001 14:08:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkaiy09196 for ; Wed, 31 Jan 2001 14:08:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkaiy28708 for ; Wed, 31 Jan 2001 14:07:46 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkaiy24736 for ; Wed, 31 Jan 2001 14:07:45 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id JAA27022 for mpls@uu.net; Wed, 31 Jan 2001 09:07:44 -0500 (EST) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkaiy09124 for ; Wed, 31 Jan 2001 14:07: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 QQkaiy14022 for ; Wed, 31 Jan 2001 14:07:06 GMT Received: from sj-msg-core-2.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkaiy01623 for ; Wed, 31 Jan 2001 14:07:05 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id GAA29516; Wed, 31 Jan 2001 06:07:17 -0800 (PST) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id JAA16628; Wed, 31 Jan 2001 09:07:04 -0500 (EST) Message-Id: <200101311407.JAA16628@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: "Amarnath Honnavalli Anantharamaiah" cc: mpls@UU.NET Subject: Re: LDP Specification draft - Loop detection. In-reply-to: Your message of "Wed, 31 Jan 2001 15:47:37 +0530." <3A77E640.F582DC3A@wipro.com> Date: Wed, 31 Jan 2001 09:07:04 -0500 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk Amar, Please review Section 3.4.6, especially the last paragraph, and Section 3.4.5, especially 3.4.5.1.2. Thanks, Bob > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > A.1.11. Receive Notification / Loop Detected > > Summary: > > When an LSR receives a Loop Detected Status Code from an LDP peer > in response to a Label Request message or a Label Mapping message, > > it behaves as if it had received a No Route notification. > > Context: > > See "Receive Notification / No Route". > > Algorithm: > > See "Receive Notification / No Route" > > Notes: > > 1. When the Loop Detected notification is in response to a Label > Request message, it arrives in a Status Code TLV in a > Notification message. When it is in response to a Label > Mapping message, it arrives in a Status Code TLV in a Label > Release message. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > [1] In the above section, Notes 1., It is told that When it is in > response to a Label mapping message, it arrives in Status Code TLV of > Label Release message, But Label Release message does not have Status > Code TLV -not even as optional parameter ????? > > Regards > Amar > From owner-mpls@UU.NET Wed Jan 31 10:15:53 2001 Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17010 for ; Wed, 31 Jan 2001 10:15:53 -0500 (EST) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkajc11433; Wed, 31 Jan 2001 15:13:20 GMT Received: by mail-control.mail.uu.net id QQkajc27684 for mpls-outgoing; Wed, 31 Jan 2001 15:12:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkajc27676 for ; Wed, 31 Jan 2001 15:12:53 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 QQkajc06892 for ; Wed, 31 Jan 2001 15:12:06 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkajc28171 for ; Wed, 31 Jan 2001 15:12:05 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id KAA01557 for mpls@uu.net; Wed, 31 Jan 2001 10:12:05 -0500 (EST) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkajc27618 for ; Wed, 31 Jan 2001 15:11:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkajc02147 for ; Wed, 31 Jan 2001 15:10:14 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 QQkajc25476 for ; Wed, 31 Jan 2001 15:10:14 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA17764; Wed, 31 Jan 2001 10:09:49 -0500 (EST) Received: from TNADEAU-PC02.cisco.com ([161.44.204.102]) by bucket.cisco.com (Mirapoint) with ESMTP id ABJ46025; Wed, 31 Jan 2001 10:10:11 -0500 (EST) Message-Id: <4.3.2.7.2.20010131101058.04bc8130@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 Jan 2001 10:15:23 -0500 To: Jonathan Lang , "'Martin Dubuc'" , "'Bradford, Richard'" From: "Thomas D. Nadeau" Subject: RE: LMP-MIB Cc: "'mpls@UU.NET'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk >In talking with Sudheer, we thought we remembered Kireeti >saying he was going to add Link Bundling to the MPLS TE MIB. That would be the TE-MIB not the MPLS-TE-MIB; there is a difference. The latter is in WG last call, so the addition of new stuff like link bundling is not an option at this point. I have heard that the TE-MIB was requested to go into last call shortly as well. Therefore, I would recommend doing link bundling in a separate document which can augment the MPLS-TE-MIB's interface table and can be tracked separately as the work progresses. --Tom >Thanks, >Jonathan > > > -----Original Message----- > > From: Martin Dubuc [mailto:martin.dubuc@edgeflow.com] > > Sent: Tuesday, January 30, 2001 11:26 AM > > To: 'Bradford, Richard' > > Cc: 'mpls@UU.NET'; Thomas D. Nadeau (E-mail) > > Subject: RE: LMP-MIB > > > > > > Richard, > > > > I agree with you. Link bundles are not LMP specific and it > > does make sense > > to spin them off in a separate MIB. I have drafted a link > > bundling MIB that > > can also be used for OSPF and MPLS, but it is not yet ready > > to be published > > at the IETF site. I will post it to the list as soon as it is > > ready (within > > a week or two). > > > > The LMP-MIB will need to be revisited in light of the link > > bundling MIB. > > > > Martin > > > > -----Original Message----- > > From: Bradford, Richard [mailto:rbradfor@cisco.com] > > Sent: Tuesday, January 30, 2001 12:47 PM > > To: Martin Dubuc > > Cc: 'mpls@UU.NET' > > Subject: Re: LMP-MIB > > > > > > One major issue with this MIB is the creation of link bundles in an > > LMP-specific MIB. > > Link Bundles are used by other protocols and should also be useful in > > scenarios without LMP. It would seem better to spin it out as a more > > general link bundling table (assuming work on such a table > > isn't already in > > progress elsewhere.) > > From owner-mpls@UU.NET Wed Jan 31 10:38:16 2001 Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17779 for ; Wed, 31 Jan 2001 10:38:15 -0500 (EST) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkaje23184; Wed, 31 Jan 2001 15:36:13 GMT Received: by mail-control.mail.uu.net id QQkaje29800 for mpls-outgoing; Wed, 31 Jan 2001 15:35:54 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkaje29788 for ; Wed, 31 Jan 2001 15:35:47 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 QQkaje04079 for ; Wed, 31 Jan 2001 15:35:31 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 QQkaje21622 for ; Wed, 31 Jan 2001 15:35:30 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 KAA18838 for ; Wed, 31 Jan 2001 10:35:28 -0500 (EST) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21159 for ; Wed, 31 Jan 2001 10:35:30 -0500 (EST) Message-ID: <3A7830BD.B1BC2A13@marconi.com> Date: Wed, 31 Jan 2001 10:35:25 -0500 From: David Charlap X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: LDP - question about partially setup LSPs References: <778DFE9B4E3BD111A74E08002BA3DC0D01E7DFA8@trab-hermes.haninge.trab.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Olle Pers wrote: >> >> Let us assume that the middle router does aggregation ! >> >> Now the packet enters the middle router labelled and he cannot have >> a direct outgoing labelled path as he has not got labels for the >> summary but only for the specific destinations for forwarding the >> packet. > > That is a different problem. With basic LDP, all routers should have > the same IGP routing table. They should all have the same IGP routing table. But they may not all have the same EGP routing table. Router B will always know how to get to C. But it may not know all of the (potentially millions) of prefixes that are reachable through C. >> Therefore whenever he receives a labelled packet and does not have >> any outgoing label for that he has to remove the label and do a >> normal layer-3 lookup in his routing table. > > Yes that would be a third option. (And if this layer-3 lookup > identifies an outgoing interface, should the packet be sent out on > that interface, or should it be dropped anyway?) Well, that is the entire question. If the layer-3 lookup doesn't identify an outgoing interface (the L3 address may be exterior to the MPLS network and unknown to router B), then it has no choice but to drop the packet. Similarly if the packet is not using an L3 protocol that router B understands. > But back to the original question: > > Section 3.22 of RFC 3031 applies when the incoming label does not > map to an NHLFE. This is not necessarily the same as having no > outgoing label. > > In David's example, the incoming label would map to an NHLFE > containing the next hop "router C" and the operation "pop the label > stack". Is this a given? Does the RFC state that a router independantly sending out a label mapping without having received one yet should allocate an NHLFE for popping the label? > When B later receives the label mapping from C, that NHLFE will > be changed to contain a "replace label" operation. This much is certain. To ignore a received label mapping would be broken (in the absence of some kind of local policy, of course.) -- David From owner-mpls@UU.NET Wed Jan 31 11:22:17 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19101 for ; Wed, 31 Jan 2001 11:22:17 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkajh19392; Wed, 31 Jan 2001 16:20:06 GMT Received: by mail-control.mail.uu.net id QQkajh17678 for mpls-outgoing; Wed, 31 Jan 2001 16:19:47 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkajh17670 for ; Wed, 31 Jan 2001 16:19:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkajh02823 for ; Wed, 31 Jan 2001 16:15:24 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkajh09942 for ; Wed, 31 Jan 2001 16:15:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA06952 for mpls@uu.net; Wed, 31 Jan 2001 11:15:22 -0500 (EST) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkajg16995 for ; Wed, 31 Jan 2001 16:14: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 QQkajg29613 for ; Wed, 31 Jan 2001 16:14:46 GMT Received: from zcars04e.ca.nortel.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) id QQkajg08685 for ; Wed, 31 Jan 2001 16:14:46 GMT Received: from zcard00n.ca.nortel.com by zcars04e.ca.nortel.com; Wed, 31 Jan 2001 10:50:32 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DYBWBVAY; Wed, 31 Jan 2001 10:48:42 -0500 Received: from americasm01.nt.com (wcars0fa.ca.nortel.com [47.129.149.140]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id Y6C63D01; Wed, 31 Jan 2001 10:48:39 -0500 Message-ID: <3A7833D5.CDE718A5@americasm01.nt.com> Date: Wed, 31 Jan 2001 10:48:37 -0500 From: "Patrick Lee" Reply-To: "Patrick Lee" Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: [Fwd: Comment for rfc3032 on TTL process] Content-Type: multipart/mixed; boundary="------------9368A35F7A65CBF52BE9EEE0" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------9368A35F7A65CBF52BE9EEE0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit --------------9368A35F7A65CBF52BE9EEE0 Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3A771342.F9ECD2F8@americasm01.nt.com> Date: Tue, 30 Jan 2001 14:17:22 -0500 From: "Lee, Patrick [CAR:9Q17:EXCH]" Reply-To: patlee@nortelnetworks.com Organization: Nortel Networks X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-web@ietf.org Subject: Comment for rfc3032 on TTL process Content-Type: multipart/alternative; boundary="------------CF2B7C50FBE881BF76C7AB71" --------------CF2B7C50FBE881BF76C7AB71 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit To whom it may concern, On the draft for MPLS label stack encoding, section 2.4.3 has mentioned about the processing of MPLS TTL field. The last paragraph state that: It is recognized that there may be situations where a network administration prefers to decrement the IPv4 TTL by one as it traverses an MPLS domain, instead of decrementing the IPv4 TTL by the number of LSP hops within the domain. That means IP packet with small TTL value can also go through the MPLS domain since the MPLS domain is treated as 1 hop for IP forwarding. But for the second paragraph on section 2.4.3 state that: When an IP packet is first labeled, the TTL field of the label stack entry MUST BE set to the value of the IP TTL field. (If the IP TTL field needs to be decremented, as part of the IP processing, it is assumed that this has already been done.) That means the first label stack entry's TTL value MUST be initialized to the IP header's TTL value. Imagine that an IP packet with TTL value 3 go into a LSP with 6 LSP hops. Although the network can view the MPLS domain as 1 IP forwarding hop, the packet can not go through that 1 hop. It seems to be NOT CONSISTENT for both paragraph. Regards, Patrick Lee -- Passport Software Development (9Q17) Multimedia Enterprise Division ESN: 39-51213 P.O. Box 3511, Station C, PHONE: (613)765-1213 Ottawa, Ontario, Canada, K1Y 4H7 E-MAIL: patlee@nortelnetworks.com --------------CF2B7C50FBE881BF76C7AB71 Content-Type: text/html; charset=big5 Content-Transfer-Encoding: 7bit To whom it may concern,

On the draft for MPLS label stack encoding, section 2.4.3 has mentioned about the processing of MPLS TTL field.

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

That means IP packet with small TTL value can also go through the MPLS domain since the MPLS domain is treated as 1 hop for IP forwarding.

But for the second paragraph on section 2.4.3 state that:
   When an IP packet is first labeled, the TTL field of the label stack
   entry MUST BE set to the value of the IP TTL field.  (If the IP TTL
   field needs to be decremented, as part of the IP processing, it is
   assumed that this has already been done.)

That means the first label stack entry's TTL value MUST be initialized to the IP header's TTL value.

Imagine that an IP packet with TTL value 3 go into a LSP with 6 LSP hops.
Although the network can view the MPLS domain as 1 IP forwarding hop, the packet can not go through that 1 hop.

It seems to be NOT CONSISTENT for both paragraph.

Regards,
Patrick Lee
  

-- 
Passport Software Development (9Q17) 
Multimedia Enterprise Division       ESN: 39-51213
P.O. Box 3511, Station C,          PHONE: (613)765-1213
Ottawa, Ontario, Canada, K1Y 4H7  E-MAIL: patlee@nortelnetworks.com
  --------------CF2B7C50FBE881BF76C7AB71-- --------------9368A35F7A65CBF52BE9EEE0-- From owner-mpls@UU.NET Wed Jan 31 12:23:14 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20565 for ; Wed, 31 Jan 2001 12:23:14 -0500 (EST) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkajl14231; Wed, 31 Jan 2001 17:21:41 GMT Received: by mail-control.mail.uu.net id QQkajl06865 for mpls-outgoing; Wed, 31 Jan 2001 17:21:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkajl06798 for ; Wed, 31 Jan 2001 17:20:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkajl15631 for ; Wed, 31 Jan 2001 17:17:31 GMT Received: from mailhost.foundrynet.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.foundrynet.com [63.251.244.20]) id QQkajl14033 for ; Wed, 31 Jan 2001 17:17:30 GMT Received: from andrewlaptop (localhost [127.0.0.1]) by mailhost.foundrynet.com (8.9.3/8.8.7) with SMTP id IAA01999; Wed, 31 Jan 2001 08:51:53 -0800 From: "Andrew R Frame" To: "Patrick Lee" , Subject: RE: [Fwd: Comment for rfc3032 on TTL process] Date: Wed, 31 Jan 2001 08:53:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: <3A7833D5.CDE718A5@americasm01.nt.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The spec is not contradicting itself, the last paragraph is defining an alternative behavior. If you would prefer for the make the LSP look like one hop to tools like traceroute, or if you are trying to solve the situation given by your example below, implementing the alternative behavior might be a good idea. -andrew -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Patrick Lee Sent: Wednesday, January 31, 2001 7:49 AM To: mpls@UU.NET Subject: [Fwd: Comment for rfc3032 on TTL process] To whom it may concern, On the draft for MPLS label stack encoding, section 2.4.3 has mentioned about the processing of MPLS TTL field. The last paragraph state that: It is recognized that there may be situations where a network administration prefers to decrement the IPv4 TTL by one as it traverses an MPLS domain, instead of decrementing the IPv4 TTL by the number of LSP hops within the domain. That means IP packet with small TTL value can also go through the MPLS domain since the MPLS domain is treated as 1 hop for IP forwarding. But for the second paragraph on section 2.4.3 state that: When an IP packet is first labeled, the TTL field of the label stack b entry MUST BE set to the value of the IP TTL field. (If the IP TTL field needs to be decremented, as part of the IP processing, it is assumed that this has already been done.) That means the first label stack entry's TTL value MUST be initialized to the IP header's TTL value. Imagine that an IP packet with TTL value 3 go into a LSP with 6 LSP hops. Although the network can view the MPLS domain as 1 IP forwarding hop, the packet can not go through that 1 hop. It seems to be NOT CONSISTENT for both paragraph. Regards, Patrick Lee -- Passport Software Development (9Q17) Multimedia Enterprise Division ESN: 39-51213 P.O. Box 3511, Station C, PHONE: (613)765-1213 Ottawa, Ontario, Canada, K1Y 4H7 E-MAIL: patlee@nortelnetworks.com