From mpls-bounces@lists.ietf.org Mon May 01 15:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaePJ-0002lP-61; Mon, 01 May 2006 15:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaePC-0002d1-AV; Mon, 01 May 2006 15:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaePB-0001RD-Tk; Mon, 01 May 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k41Jo10e020187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FaePB-0000f0-Fx; Mon, 01 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 01 May 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-te-p2mp-04.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Extensions to RSVP-TE for Point to Multipoint TE LSPs Author(s) : R. Aggarwal, et al. Filename : draft-ietf-mpls-rsvp-te-p2mp-04.txt Pages : 53 Date : 2006-5-1 This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the setup of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rsvp-te-p2mp-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-1142353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-te-p2mp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-1142353.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Wed May 03 13:31:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbL99-000865-RF; Wed, 03 May 2006 13:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbL98-00084S-HY for mpls@ietf.org; Wed, 03 May 2006 13:28:18 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbL97-0001SI-3c for mpls@ietf.org; Wed, 03 May 2006 13:28:18 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k43HHEpI032598 for ; Wed, 3 May 2006 19:17:14 +0200 Received: from [127.0.0.1] ([172.16.2.197]) by mail1.imc.kth.se; Wed, 03 May 2006 19:26:21 +0200 Message-ID: <4458E7BA.6080503@pi.se> Date: Wed, 03 May 2006 19:26:18 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org, George Swallow Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [mpls] wg last call on draft-ietf-mpls-explicit-resource-control-bundle-01 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org All, this mail initiates a working group last call om draft-ietf-mpls-explicit-resource-control-bundle-01.txt Plese send your comments to the working group mailing list or to the working group co-chairs. This last call ends eob May 17th. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu May 04 10:49:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbf6G-0000jD-3A; Thu, 04 May 2006 10:46:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbf6E-0000j8-LF for mpls@ietf.org; Thu, 04 May 2006 10:46:38 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbf6D-00075a-7F for mpls@ietf.org; Thu, 04 May 2006 10:46:38 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k44EZXku022252 for ; Thu, 4 May 2006 16:35:34 +0200 Received: from [127.0.0.1] ([172.16.2.197]) by mail1.imc.kth.se; Thu, 04 May 2006 16:45:01 +0200 Message-ID: <445A134E.6030004@pi.se> Date: Thu, 04 May 2006 16:44:30 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [mpls] imolementations of draft-ietf-mpls-over-l2tpv3-01 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org All, we are about to request the draft-ietf-mpls-over-l2tpv3-01 is published as an RFC, and we would need to know if there are implementations based on the draft. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri May 05 06:06:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbxAW-0002gQ-TO; Fri, 05 May 2006 06:04:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbxAU-0002gJ-Sn for mpls@ietf.org; Fri, 05 May 2006 06:04:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbvnw-0000Ym-Oz for mpls@ietf.org; Fri, 05 May 2006 04:36:52 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FbvZD-0000CE-9T for mpls@ietf.org; Fri, 05 May 2006 04:21:41 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k458AUpv025470 for ; Fri, 5 May 2006 10:10:32 +0200 Received: from [127.0.0.1] ([172.16.2.197]) by mail1.imc.kth.se; Fri, 05 May 2006 10:19:38 +0200 Message-ID: <445B0A98.9020603@pi.se> Date: Fri, 05 May 2006 10:19:36 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [mpls] [Fwd: IETF Meeting Survey] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org All, for those who have not seen it. To really have an impact on how future meetings is setup and organized take time to complete the survey. Loa and George -------- Original Message -------- Subject: IETF Meeting Survey Date: Mon, 01 May 2006 11:24:42 -0400 From: Ray Pelletier To: wgchairs@ietf.org All; It has been suggested that if I really wanted to get feedback on the Meeting Survey (and I do) I should have it forwarded by the WG Chairs to the working groups - so this is a request that you ask members of the working groups to complete a short survey that focuses primarily, but not exclusively, on their meeting experience in Dallas. I truly want the info to make the changes members of the community want, if possible and greatly appreciate your assistance in this regard. Those interested in taking the survey can find it at: http://www.surveymonkey.com/s.asp?u=649182049947 Thanks Ray Pelletier IETF Admininstrative Director -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri May 05 07:47:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbyk9-0004Ol-CD; Fri, 05 May 2006 07:45:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbgPC-0003Yy-3I; Thu, 04 May 2006 12:10:18 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbgPB-0001uX-LF; Thu, 04 May 2006 12:10:18 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:52716) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1FbgPB-0000Hx-9C; Thu, 04 May 2006 17:10:17 +0100 Mime-Version: 1.0 (Apple Message framework v749.3) References: <28A58523-F3F5-483E-9763-9E2D5329914F@csperkins.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88B272E0-B615-46C9-B608-6AC19B11189A@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Thu, 4 May 2006 17:10:14 +0100 To: rohc@ietf.org, mpls@ietf.org, pwe3@ietf.org X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-Mailman-Approved-At: Fri, 05 May 2006 07:45:08 -0400 Cc: Subject: [mpls] Fwd: Working group last call: draft-ietf-avt-hc-over-mpls-protocol-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: IETF AVT WG List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Folks, The following working group last call has just been issued in AVT, but overlaps with the MPLS, ROHC, and PWE3 working groups. We would be grateful for review from those working groups: please send any comments on the draft to the mailing list. Thanks, Colin (AVT co-chair) Begin forwarded message: > From: Colin Perkins > Date: 4 May 2006 17:06:19 BDT > To: IETF AVT WG > Subject: Working group last call: draft-ietf-avt-hc-over-mpls- > protocol-05.txt > > This is to announce a working group last call on the Protocol > Extensions for Header Compression over MPLS mpls-protocol-05.txt>. Please send any final comments on this draft > to the avt@ietf.org mailing list by 22nd May 2006. If no issues are > raised by that time, we will request the IESG consider this for > publication as a proposed standard RFC. > > Colin > > > > On 3 May 2006, at 20:50, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Audio/Video Transport Working >> Group of the IETF. >> >> Title : Protocol Extensions for Header Compression over MPLS >> Author(s) : J. Ash, et al. >> Filename : draft-ietf-avt-hc-over-mpls-protocol-05.txt >> Pages : 30 >> Date : 2006-5-3 >> >> VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS >> labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an >> MPLS VPN, the packet header is typically 48 bytes, while the voice >> payload is often no more than 30 bytes, for example. Header >> compression can significantly reduce the overhead through various >> compression mechanisms. MPLS is used to route header-compressed (HC) >> packets over an MPLS LSP without compression/decompression cycles at >> each router. Such an HC over MPLS capability increases the bandwidth >> efficiency as well as processing scalability of the maximum number of >> simultaneous compressed flows that use HC at each router. MPLS >> pseudowires are used to transport the HC context and other control >> messages between the ingress and egress MPLS label switched router >> (LSR). Standard HC methods (e.g., ECRTP, ROHC, etc.) are re-used to >> determine the context. Each HC scheme operates over a single >> pseudowire instance very much like it would over a single >> point-to-point link. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-over-mpls- >> protocol-05.txt _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon May 08 19:25:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdF20-000600-VW; Mon, 08 May 2006 19:20:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdF20-0005zv-4j for mpls@lists.ietf.org; Mon, 08 May 2006 19:20:48 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdF1z-00084n-Mp for mpls@lists.ietf.org; Mon, 08 May 2006 19:20:48 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FdF2O-0003AJ-00 for mpls@lists.ietf.org; Tue, 09 May 2006 00:21:12 +0100 Received: from your029b8cecfe ([217.158.132.104] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 00:21:24 +0100 Message-ID: <003601c672f5$f7fe7400$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: Date: Tue, 9 May 2006 00:18:23 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 08 May 2006 23:21:24.0562 (UTC) FILETIME=[1FAD7320:01C672F6] X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ccamp@ops.ietf.org Subject: [mpls] draft-farrel-mpls-iana-rsvp-session-flags-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, During IESG review of draft-ietf-mpls-rsvpte-attributes we removed the "suggestion" that IANA should track the flags bits in the Session-Attributes object, because there was no explicit requirement in that draft to create a new registry for those bits. During IESG review of draft-ietf-ccamp-loose-path-reopt we noticed that yet another bit from that flags field is being assigned, and that draft asked IANA to assign the bit from the registry (that has not been created). So... I have written draft-farrel-mpls-iana-rsvp-session-flags-00.txt to request IANA to create a registry. I would welcome review from the MPLS and CCAMP working groups. If the MPLS WG chairs want to adopt this I-D as a working group document and move it to immediate WG last call, that would be great. Otherwise I will take it to the ADs as a personal draft and ask for it to be made into an RFC. Thanks, Adrian ----- Original Message ----- From: To: Sent: Monday, May 08, 2006 11:50 PM Subject: I-D ACTION:draft-farrel-mpls-iana-rsvp-session-flags-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Codepoint Registry for The Flags Field in the Resource Reservation > Protocol Traffic Engineering (RSVP-TE) Session Attribute Object > Author(s) : A. Farrel > Filename : draft-farrel-mpls-iana-rsvp-session-flags-00.txt > Pages : 5 > Date : 2006-5-8 > > This document provides instructions to IANA for the creation of a new > codepoint registry for the flags field in the Session Attribute > object of the Resource Reservation Protocol Traffic Engineeging > (RSVP-TE) signaling messages used in Multiprotocol Label Switching > (MPLS) and Generalized MPLS (GMPLS) signaling. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-farrel-mpls-iana-rsvp-session-flags-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-farrel-mpls-iana-rsvp-session-flags-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-farrel-mpls-iana-rsvp-session-flags-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue May 09 07:16:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdQ7a-0002fA-CN; Tue, 09 May 2006 07:11:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdQ7Y-0002eE-T6 for mpls@lists.ietf.org; Tue, 09 May 2006 07:11:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdOuG-0006gT-4q for mpls@lists.ietf.org; Tue, 09 May 2006 05:53:28 -0400 Received: from smtp2.clb.oleane.net ([213.56.31.18]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdOYK-0004If-B2 for mpls@lists.ietf.org; Tue, 09 May 2006 05:30:51 -0400 Received: from Pavillonquatre ([194.3.133.88]) by smtp2.clb.oleane.net with ESMTP id k499UhAH019269 for ; Tue, 9 May 2006 11:30:44 +0200 Message-Id: <200605090930.k499UhAH019269@smtp2.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 9 May 2006 11:29:29 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZzSxHTq1WTjOCqSIaLw3IeF2ENoA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Subject: [mpls] MPLS World Congress 2007 - Call for proposals X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1965425871==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1965425871== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01C6735B.D5F502A0" This is a multi-part message in MIME format. ------=_NextPart_000_0059_01C6735B.D5F502A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 9th edition of the MPLS World Congress will take place in Paris February 6 to 9, 2007. A special attention will be paid on Carrier Ethernet. The 2007 edition will attract 800 people and 40 exhibitors. The conference call for proposals is online at: http://www.upperside.fr/mpls2007/mplsworld2007cfp.htm ------=_NextPart_000_0059_01C6735B.D5F502A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 9th edition of the MPLS World = Congress will take place in = Paris February = 6 to 9, 2007.

A special attention will be paid on Carrier = Ethernet.

The 2007 edition will attract 800 people and = 40 exhibitors.

 

The conference call for = proposals is online at:

http://www.upperside.fr/mpls2007/mplsworld2007cfp.htm=

 

------=_NextPart_000_0059_01C6735B.D5F502A0-- --===============1965425871== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1965425871==-- From mpls-bounces@lists.ietf.org Tue May 09 15:54:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYDs-0000Re-Bq; Tue, 09 May 2006 15:50:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdYDc-0008V5-8R; Tue, 09 May 2006 15:50:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdYDZ-0001DT-OR; Tue, 09 May 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k49Jo167015520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FdYDZ-0005QQ-Al; Tue, 09 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 09 May 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Extensions to RSVP-TE for Point to Multipoint TE LSPs Author(s) : R. Aggarwal, et al. Filename : draft-ietf-mpls-rsvp-te-p2mp-05.txt Pages : 53 Date : 2006-5-9 This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the setup of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-rsvp-te-p2mp-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-rsvp-te-p2mp-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: <2006-5-9124533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-rsvp-te-p2mp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-9124533.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Wed May 10 08:39:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdnsz-0004np-3t; Wed, 10 May 2006 08:33:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdnsx-0004nk-N1 for mpls@ietf.org; Wed, 10 May 2006 08:33:47 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdnsw-0003BV-Vx for mpls@ietf.org; Wed, 10 May 2006 08:33:47 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k4ACMO6T020007 for ; Wed, 10 May 2006 14:22:24 +0200 Received: from [127.0.0.1] ([172.16.2.197]) by mail1.imc.kth.se; Wed, 10 May 2006 14:31:50 +0200 Message-ID: <4461DD30.2060305@pi.se> Date: Wed, 10 May 2006 14:31:44 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by oberon.imc.kth.se id k4ACMO6T020007 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: Subject: [mpls] [Fwd: New Liaison Statement, "Clarification on the intended scope of T-MPLS"] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org All, we have received the included liaison from ITU-T SG 15. Note that we've two slightly mixed discussion, one on MPLS and another on pseudo wires. Try to direct comments to the appropriate working group list. we plan to give a formal response on May 17th, comments, both on the content of this liaison and on the T-MPLS documentation, are welcome. Loa and George -------- Original Message -------- Subject: New Liaison Statement, "Clarification on the intended scope of=20 T-MPLS" Date: Thu, 04 May 2006 14:09:26 -0400 From: Greg Jones(ITU-T SG 15) Reply-To: tsbsg15@itu.int To: George Swallow , Loa Andersson ,=20 Stewart Bryant , Danny McPherson CC: Scott Bradner , Yoichi Maeda=20 , sjtrowbridge@lucent.com,=20 ghani.abbas@marconi.com, betts01@nortel.com, tsbsg15@itu.int,=20 greg.jones@itu.int, ghani.abbas@marconi.com, betts01@nortel.com Title: Clarification on the intended scope of T-MPLS Submission Date: 2006-05-04 URL of the IETF Web page:=20 https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D218 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG, PWE3 WG(George Swallow , Loa=20 Andersson , Stewart Bryant , Danny=20 McPherson ) Cc: Scott Bradner Yoichi Maeda sjtrowbridge@lucent.com ghani.abbas@marconi.com betts01@nortel.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int Technical Contact: ghani.abbas@marconi.com betts01@nortel.com Purpose: For information Body: Thank you for your informal feedback that has been provided on our=20 previous liaison statement on T-MPLS Consented Recommendations, we also=20 understand that you are in the process of developing a formal response.=20 To assist you in providing your formal response we would like to=20 provide some additional clarifications on the intended application of=20 T-MPLS. Our intention in developing the suite of T-MPLS Recommendations was to=20 define a packet based transport network technology. The design=20 objectives of T-MPLS were: a) Follow the principles of the transport network used in other ITU-T=20 defined transport technologies (e.g SDH, ATM, OTN). b) To use the PDU and data plane processes defined by the IETF for MPLS. T-MPLS is not intended to duplicate the functionality already provided=20 by IP/MPLS. The only client fully described in the current version of G.8110.1 is=20 point to point Ethernet Virtual Connection (EVC). It was agreed to=20 revise the scope of the Recommendation and provide an appendix II=20 (attached) to reflect this. Some other key points identified were: =E2=80=A2 The current version of G.8110.1 only defines the bearer plane a= nd only=20 point to point trails are currently supported. It should be noted that=20 version 2 of G.8110.1 will add point to multipoint trails. =E2=80=A2 Any interworking with client signals (e.g. MPLS, Ethernet) will= be=20 client server i.e. any client OAM or control protocols will be tunneled=20 transparently across the T-MPLS layer network. =E2=80=A2 Interworking between a client control plane and a (yet to be de= fined)=20 T-MPLS control plane will be addressed as a part of the control plane=20 architecture work. =E2=80=A2 The T-MPLS network provides a single hop link to the client, it= is=20 intended to offer a packet switched connection that has similar=20 operational characteristics to a SDH network providing a PDH link=20 connection, e.g. these connections must support the ability to activate=20 performance monitoring and fault management. Any PM data or failures=20 will be reported to the transport operations center. We also note your comments on the usage of the label space terminology.=20 We will work to clarify and if necessary correct this in a future=20 revision. We have also agreed to initiate work on the architecture of a control=20 plane for T-MPLS. We will use the ASON architecture to provide a=20 framework to describe the problem that is to be addressed. This does=20 not imply that we will specify an ASON control plane. Once we have=20 refined our requirements we will communicate them to you for advice on=20 how they may be addressed. If the requirements cannot be met by an=20 existing protocol suite we would like to work with you to develop the=20 appropriate enhancements. We will be continuing our work on T-MPLS in particular the support of=20 other clients (e.g. IP/MPLS) at an interim meeting that is planned to be=20 held 19-23 June in Ottawa Canada. We will also address any comments=20 that you provide in your planned liaison statement. Any urgent changes=20 may be included in an amendment or corrigendum that could be consented=20 in October 2006. IETF experts are welcome to participate at this=20 meeting. Please contact betts01@nortel.com by May 31st 2006 if you=20 should wish to participate. G.8110.1 draft Appendix II Support of IP/MPLS LSR based networks by T-MPLS networks supporting point-to-point EVC services When two IP/MPLS LSRs are connected via e.g. 802.3 interfaces to a=20 T-MPLS network, the T-MPLS network can provide an EVC service between=20 these two LSRs (nodes LSR A and LSR B in Figure II-1) to establish an=20 IP/MPLS link between these LSRs. The IP/MPLS LSRs encapsulate their IP/MPLS packets into Ethernet frames=20 with or without VLAN Tag. These Ethernet frames are then transported via=20 802.3 interfaces to the T-MPLS network edge (nodes X and Y). At the=20 T-MPLS network edge the Ethernet signal is treated either as an=20 all-to-one EVC service or as one or more EVC and/or bundled EVC services=20 of which the frames are mapped into one or more T-MPLS (PW) trails and=20 then transported through the T-MPLS network. In this network scenario the IP/MPLS routing and control plane adjacency=20 is between LSR A and LSR B. The T-MPLS network elements do not=20 participate in the IP/MPLS routing and control plane. A signalling=20 session that requests PHP is between LSR A and LSR B (T-MPLS nodes X and=20 Y are not involved). Figure II-1/G.8110.1 =E2=80=93 IP/MPLS via EVC over T-MPLS network The functional model for this scenario is described in Figure II-2. The=20 atomic functions in the figure are specified in Recommendations G.8021=20 and G.8121.The IP/MPLS signals are carried through an IP/MPLS link=20 between LSR A and LSR B supported by an ETH trail between LSR A and LSR=20 B. The ETH trail is carried through a serial-compound ETH link supported=20 by an ETY trail interconnecting LSR A with T-MPLS PE X, a T-MPLS (PW)=20 trail interconnecting T-MPLS PE X with T-MPLS PE Y and an ETY trail=20 interconnecting T-MPLS PE Y with LSR B. <
> - see attachment Attachment(s): Clarification on the intended scope of T-MPLS (see this WinWord=20 file for the diagrams)=20 (https://datatracker.ietf.org/documents/LIAISON/file311.doc) --=20 Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sat May 13 06:57:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Feri0-0007rD-Iz; Sat, 13 May 2006 06:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ferhz-0007r8-43 for mpls@ietf.org; Sat, 13 May 2006 06:50:51 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ferhw-0003tn-LP for mpls@ietf.org; Sat, 13 May 2006 06:50:51 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k4DAcsOA012208 for ; Sat, 13 May 2006 12:38:58 +0200 Received: from [127.0.0.1] ([172.16.2.197]) by mail1.imc.kth.se; Sat, 13 May 2006 12:48:19 +0200 Message-ID: <4465B972.4090305@pi.se> Date: Sat, 13 May 2006 12:48:18 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mpls@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Bill Fenner , ccamp , Ross Callon Subject: [mpls] working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Working Group, this initiates a two week working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt please send comments to the MPLS working group mailling list and/or working co-chairs. The last call ends eob May 28th. The ccamp mailing list copied as this is a work that has an overlap between the working groups. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sat May 13 11:29:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fevz3-0008VX-Cu; Sat, 13 May 2006 11:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fevz1-0008VR-HB for mpls@ietf.org; Sat, 13 May 2006 11:24:43 -0400 Received: from mx4.equant.com ([199.184.38.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fevz0-0001id-A3 for mpls@ietf.org; Sat, 13 May 2006 11:24:43 -0400 Received: from us-res-dms1.domino.globalone.net (mail.internal.equant.com [199.184.38.65]) by mx4.equant.com with ESMTP id k4DFOdJ1001580 for ; Sat, 13 May 2006 11:24:39 -0400 (EDT) Subject: Re: TR: [mpls] working group document candidates To: mpls@ietf.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: zubair.ahmad@equant.com Date: Sat, 13 May 2006 11:24:48 -0400 X-MIMETrack: Serialize by Router on US-Res-DMS1/Servers/GlobalOne(5012HF429 | October 14, 2003) at 05/13/2006 11:24:39 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi all, I support the adoption of both of these drafts as WG docs. > draft-vasseur-mpls-number-0-bw-te-lsps-00 > draft-leroux-mpls-mp-ldp-reqs-03.txt Thanks, Zubair > -----Message d'origine----- > De : Loa Andersson [mailto:loa@pi.se] > Envoy=E9 : vendredi 21 avril 2006 18:35 > =C0 : mpls@ietf.org > Objet : [mpls] working group document candidates > > All, > > the authors of the two following drafts has requested that > they are adopted as working group documents: > > draft-vasseur-mpls-number-0-bw-te-lsps-00 > draft-leroux-mpls-mp-ldp-reqs-03.txt > > draft-vasseur-... was discussed at the mpls wg meeting in > Dallas. We had a good support for the general idea, but were > uncertain how this should be handled document-wise. > The normal work flow would be that the mpls wg write a > requirement draft to the ospf and is-is working groups, who > each produce one spec for the extension for their protocols. > It has however been argued that this could be addres in a > single draft of less than a handful pages. > The (is-is, ospf and mpls) working group chairs and the > routing area ADs have there fore agreed that we can do it in > a single mpls working group document, which will be sent to > the other two working groups for review. > > draft-leroux-... was discussed at the same meeting, and there > were a good support in the room for adopting it as a working > group document. > > Please respond to the mailing list whether you think they > should become wg docs or not. > > Loa and George > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > = _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sat May 13 11:37:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Few9D-00045M-7O; Sat, 13 May 2006 11:35:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Few9C-00045H-F6 for mpls@ietf.org; Sat, 13 May 2006 11:35:14 -0400 Received: from mailao.ntcif.telstra.com.au ([202.12.233.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Few99-0002Rv-On for mpls@ietf.org; Sat, 13 May 2006 11:35:14 -0400 Received: from mailai.ntcif.telstra.com.au (mailai.ntcif.telstra.com.au [202.12.162.17]) by mailao.ntcif.telstra.com.au (Postfix) with ESMTP id 976F412C8C; Sun, 14 May 2006 01:34:59 +1000 (EST) Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 341DFFF82; Sun, 14 May 2006 01:34:59 +1000 (EST) Received: from wsmsg2952.srv.dir.telstra.com (wsmsg2952.srv.dir.telstra.com [192.74.195.51]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id BAA23864; Sun, 14 May 2006 01:34:58 +1000 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: TR: [mpls] working group document candidates X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 14 May 2006 01:34:57 +1000 Message-ID: Thread-Topic: TR: [mpls] working group document candidates Thread-Index: AcZ2ompRYQAyqw6+Rc2dtMdjd1VFoQAAF/C7 From: "Stanley, Ian B" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1523175106==" Errors-To: mpls-bounces@lists.ietf.org --===============1523175106== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIHN1cHBvcnQgYm90aGUgdGhlc2UgZHJhZnRzIGFzIFdHIGRvY3MNCg0KUmVnYXJkcw0K SWFuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU2VudCBmcm9tIG15IEJsYWNrQmVycnkg V2lyZWxlc3MgSGFuZGhlbGQNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog enViYWlyLmFobWFkQGVxdWFudC5jb20gPHp1YmFpci5haG1hZEBlcXVhbnQuY29tPg0KVG86IG1w bHNAaWV0Zi5vcmcgPG1wbHNAaWV0Zi5vcmc+DQpTZW50OiBTdW4gTWF5IDE0IDAxOjI0OjQ4IDIw MDYNClN1YmplY3Q6IFJlOiBUUjogW21wbHNdIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgY2FuZGlk YXRlcw0KDQoNCkhpIGFsbCwNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgYm90aCBvZiB0aGVz ZSBkcmFmdHMgYXMgV0cgZG9jcy4NCg0KPiBkcmFmdC12YXNzZXVyLW1wbHMtbnVtYmVyLTAtYnct dGUtbHNwcy0wMA0KPiBkcmFmdC1sZXJvdXgtbXBscy1tcC1sZHAtcmVxcy0wMy50eHQNCg0KVGhh bmtzLA0KWnViYWlyDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlIDogTG9h IEFuZGVyc3NvbiBbbWFpbHRvOmxvYUBwaS5zZV0NCj4gRW52b3nDqSA6IHZlbmRyZWRpIDIxIGF2 cmlsIDIwMDYgMTg6MzUNCj4gw4AgOiBtcGxzQGlldGYub3JnDQo+IE9iamV0IDogW21wbHNdIHdv cmtpbmcgZ3JvdXAgZG9jdW1lbnQgY2FuZGlkYXRlcw0KPg0KPiBBbGwsDQo+DQo+IHRoZSBhdXRo b3JzIG9mIHRoZSB0d28gZm9sbG93aW5nIGRyYWZ0cyBoYXMgcmVxdWVzdGVkIHRoYXQNCj4gdGhl eSBhcmUgYWRvcHRlZCBhcyB3b3JraW5nIGdyb3VwIGRvY3VtZW50czoNCj4NCj4gZHJhZnQtdmFz c2V1ci1tcGxzLW51bWJlci0wLWJ3LXRlLWxzcHMtMDANCj4gZHJhZnQtbGVyb3V4LW1wbHMtbXAt bGRwLXJlcXMtMDMudHh0DQo+DQo+IGRyYWZ0LXZhc3NldXItLi4uIHdhcyBkaXNjdXNzZWQgYXQg dGhlIG1wbHMgd2cgbWVldGluZyBpbg0KPiBEYWxsYXMuIFdlIGhhZCBhIGdvb2Qgc3VwcG9ydCBm b3IgdGhlIGdlbmVyYWwgaWRlYSwgYnV0IHdlcmUNCj4gdW5jZXJ0YWluIGhvdyB0aGlzIHNob3Vs ZCBiZSBoYW5kbGVkIGRvY3VtZW50LXdpc2UuDQo+IFRoZSBub3JtYWwgd29yayBmbG93IHdvdWxk IGJlIHRoYXQgdGhlIG1wbHMgd2cgd3JpdGUgYQ0KPiByZXF1aXJlbWVudCBkcmFmdCB0byB0aGUg b3NwZiBhbmQgaXMtaXMgd29ya2luZyBncm91cHMsIHdobw0KPiBlYWNoIHByb2R1Y2Ugb25lIHNw ZWMgZm9yIHRoZSBleHRlbnNpb24gZm9yIHRoZWlyIHByb3RvY29scy4NCj4gSXQgaGFzIGhvd2V2 ZXIgYmVlbiBhcmd1ZWQgdGhhdCB0aGlzIGNvdWxkIGJlIGFkZHJlcyBpbiBhDQo+IHNpbmdsZSBk cmFmdCBvZiBsZXNzIHRoYW4gYSBoYW5kZnVsIHBhZ2VzLg0KPiBUaGUgKGlzLWlzLCBvc3BmIGFu ZCBtcGxzKSB3b3JraW5nIGdyb3VwIGNoYWlycyBhbmQgdGhlDQo+IHJvdXRpbmcgYXJlYSBBRHMg aGF2ZSB0aGVyZSBmb3JlIGFncmVlZCB0aGF0IHdlIGNhbiBkbyBpdCBpbg0KPiBhIHNpbmdsZSBt cGxzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQsIHdoaWNoIHdpbGwgYmUgc2VudCB0bw0KPiB0aGUg b3RoZXIgdHdvIHdvcmtpbmcgZ3JvdXBzIGZvciByZXZpZXcuDQo+DQo+IGRyYWZ0LWxlcm91eC0u Li4gd2FzIGRpc2N1c3NlZCBhdCB0aGUgc2FtZSBtZWV0aW5nLCBhbmQgdGhlcmUNCj4gd2VyZSBh IGdvb2Qgc3VwcG9ydCBpbiB0aGUgcm9vbSBmb3IgYWRvcHRpbmcgaXQgYXMgYSB3b3JraW5nDQo+ IGdyb3VwIGRvY3VtZW50Lg0KPg0KPiBQbGVhc2UgcmVzcG9uZCB0byB0aGUgbWFpbGluZyBsaXN0 IHdoZXRoZXIgeW91IHRoaW5rIHRoZXkNCj4gc2hvdWxkIGJlY29tZSB3ZyBkb2NzIG9yIG5vdC4N Cj4NCj4gTG9hIGFuZCBHZW9yZ2UNCj4NCj4gLS0NCj4gTG9hIEFuZGVyc3Nvbg0KPg0KPiBQcmlu Y2lwYWwgTmV0d29ya2luZyBBcmNoaXRlY3QNCj4gQWNyZW8gQUIgICAgICAgICAgICAgICAgICAg ICAgICAgICBwaG9uZTogICs0NiA4IDYzMiA3NyAxNA0KPiBJc2Fmam9yZHNnYXRhbiAyMiAgICAg ICAgICAgICAgICAgIG1vYmlsZTogKzQ2IDczOSA4MSAyMSA2NA0KPiBLaXN0YSwgU3dlZGVuICAg ICAgICAgICAgICAgICAgICAgIGVtYWlsOiAgbG9hLmFuZGVyc3NvbkBhY3Jlby5zZQ0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5zZQ0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1h aWxpbmcgbGlzdA0KPiBtcGxzQGxpc3RzLmlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAbGlz dHMuaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMN Cg== --===============1523175106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1523175106==-- From mpls-bounces@lists.ietf.org Sun May 14 10:48:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfHnW-00036j-Cn; Sun, 14 May 2006 10:42:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfHnB-0002nS-Vv for mpls@ietf.org; Sun, 14 May 2006 10:41:57 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfHRh-0002Cf-Vo for mpls@ietf.org; Sun, 14 May 2006 10:19:47 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k4EE7q69026838 for ; Sun, 14 May 2006 16:07:52 +0200 Received: from [127.0.0.1] ([172.16.2.197]) by mail1.imc.kth.se; Sun, 14 May 2006 16:17:11 +0200 Message-ID: <44673BE1.4090603@pi.se> Date: Sun, 14 May 2006 16:17:05 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mpls@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [mpls] working group document candidates - accepted X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org All, we have a good support to make draft-vasseur-mpls-number-0-bw-te-lsps-00 and draft-leroux-mpls-mp-ldp-reqs-03.txt working group documents. Could the authors please republish the documents as draft-ietf-mpls-number-0-bw-te-lsps-00.txt and draft-ietf-mpls-mp-ldp-reqs-00.txt Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon May 15 09:40:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfdDs-00063A-KR; Mon, 15 May 2006 09:34:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfdDq-000630-PY for mpls@ietf.org; Mon, 15 May 2006 09:34:54 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfdDp-0003xw-AK for mpls@ietf.org; Mon, 15 May 2006 09:34:54 -0400 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 14:34:52 +0100 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 May 2006 14:34:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 May 2006 14:36:21 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcZ2e1powyNpiR5aTI23+4rohWlX8wBpnppw From: To: X-OriginalArrivalTime: 15 May 2006 13:34:47.0427 (UTC) FILETIME=[55711D30:01C67824] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ccamp@ops.ietf.org Subject: [mpls] RE: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org owner-ccamp@ops.ietf.org <> wrote: > Working Group, >=20 > this initiates a two week working group last call on > draft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 > please send comments to the MPLS working group mailling list and/or > working co-chairs.=20 Section 4.3, paragraph 1 states "The two most notable differences are that a P2MP LSP comprises multiple S2L Sub-LSPs and that, as a result of this, it may not be possible to represent full state in a single IP packet and even more likely that it can't fit into a single IP packet." Which appears to repeat itself. Section 5.2.4, paragraph 2 states "The ingress LSP may request 'LSP integrity' by setting bit (TBA) of the Attributes Flags TLV. The bit is set if LSP integrity is required." Should the bit that needs setting be defined here (rather than TBA) or is that down to IANA? Section 18, paragraph 1 "This section is currently under discussion between the authors and will be updated in the next revision." Is this paragraph appropriate? Ben _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Mon May 15 15:55:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffj5Z-0006O9-CL; Mon, 15 May 2006 15:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffj4y-0005ZY-TH; Mon, 15 May 2006 15:50:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffj4y-00054r-R2; Mon, 15 May 2006 15:50:08 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ffj4t-00034l-30; Mon, 15 May 2006 15:50:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k4FJo21I002876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 May 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ffj4s-0007W2-LM; Mon, 15 May 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 15 May 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-mp-ldp-reqs-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org --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 : Requirements for point-to-multipoint extensions to the Label Distribution Protocol Author(s) : J. Le Roux, et al. Filename : draft-ietf-mpls-mp-ldp-reqs-00.txt Pages : 16 Date : 2006-5-15 This document lists a set of functional requirements for Label Distribution Protocol (LDP) extensions for setting up point-to- multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. It is intended that solutions that specify LDP procedures for setting up P2MP LSP satisfy these requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mp-ldp-reqs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mp-ldp-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-mp-ldp-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-15114106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-mp-ldp-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-mp-ldp-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-15114106.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Mon May 15 18:59:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fflxm-0000XS-Hd; Mon, 15 May 2006 18:54:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fflxm-0000XN-3W for mpls@ietf.org; Mon, 15 May 2006 18:54:54 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fflxj-0001su-QB for mpls@ietf.org; Mon, 15 May 2006 18:54:54 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 15 May 2006 15:54:51 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,131,1146466800"; d="scan'208"; a="550920308:sNHT22569488" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 15:54:50 -0700 Date: Mon, 15 May 2006 15:54:50 -0700 (PDT) From: Rahul Aggarwal To: benjamin.niven-jenkins@bt.com In-Reply-To: Message-ID: <20060515154948.G93718@sapphire.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 15 May 2006 22:54:50.0475 (UTC) FILETIME=[926B53B0:01C67872] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ccamp@ops.ietf.org, mpls@ietf.org Subject: [mpls] RE: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Ben, Thanks for the comments. Please see inline: On Mon, 15 May 2006 benjamin.niven-jenkins@bt.com wrote: > owner-ccamp@ops.ietf.org <> wrote: > > Working Group, > > > > this initiates a two week working group last call on > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > please send comments to the MPLS working group mailling list and/or > > working co-chairs. > > Section 4.3, paragraph 1 states "The two most notable differences are > that a P2MP LSP comprises multiple S2L Sub-LSPs and that, as a result of > this, it may not be possible to represent full state in a single IP > packet and even more likely that it can't fit into a single IP packet." > > Which appears to repeat itself. > Will reword the following: "As with all other RSVP controlled LSPs, P2MP LSP state is managed using RSVP messages. While use of RSVP messages is the same, P2MP LSP state differs from P2P LSP state in a number of ways. The two most notable differences are that a P2MP LSP comprises multiple S2L Sub- LSPs and that, as a result of this, it may not be possible to represent full state in a single IP packet and even more likely that it can't fit into a single IP packet. It must also be possible to efficiently add and remove endpoints to and from P2MP TE LSPs. An additional issue is that the P2MP LSP must also handle the state "remerge" problem, see [RFC4461]." to "As with all other RSVP controlled LSPs, P2MP LSP state is managed using RSVP messages. While use of RSVP messages is the same, P2MP LSP state differs from P2P LSP state in a number of ways. A P2MP LSP comprises multiple S2L Sub-LSPs and as a result of this it may not be possible to represent full state in a single IP packet. It must also be possible to efficiently add and remove endpoints to and from P2MP TE LSPs. An additional issue is that the P2MP LSP must also handle the state "remerge" problem, see [RFC4461]." > Section 5.2.4, paragraph 2 states "The ingress LSP may request 'LSP > integrity' by setting bit (TBA) of the Attributes Flags TLV. The bit is > set if LSP integrity is required." > > Should the bit that needs setting be defined here (rather than TBA) or > is that down to IANA? > The editors will request a specific bit. > Section 18, paragraph 1 "This section is currently under discussion > between the authors and will be updated in the next revision." > > Is this paragraph appropriate? > No. Thanks for catching it. Will remove it. Thanks, rahul > Ben > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue May 16 07:45:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfxvG-0001Pm-Fz; Tue, 16 May 2006 07:41:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfxvE-0001Lq-EK for mpls@ietf.org; Tue, 16 May 2006 07:41:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffx10-0006PQ-Be for mpls@ietf.org; Tue, 16 May 2006 06:42:58 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ffwpj-0003m1-MK for mpls@ietf.org; Tue, 16 May 2006 06:31:23 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 11:31:17 +0100 Received: from i2km86-ukdy.domain1.systemhost.net ([193.113.30.79]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 May 2006 11:31:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 May 2006 11:31:15 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions for clarification on draft-ietf-mpls-mp-ldp-reqs-00 Thread-Index: AcZ409wRPXNR5aqCR/uSWa+hAYsKtA== From: To: X-OriginalArrivalTime: 16 May 2006 10:31:16.0468 (UTC) FILETIME=[DCCFDB40:01C678D3] X-Spam-Score: -2.6 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [mpls] Questions for clarification on draft-ietf-mpls-mp-ldp-reqs-00 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Authors and colleagues, Having just read draft-ietf-mpls-mp-ldp-reqs-00 I have a couple of questions for clarification. Section 3.2 - Requirements overview "The P2MP LDP mechanism MUST allow the arbitrary addition or removal of leaves associated with a P2MP LSP." What do you mean by arbitrary? I assume you mean that once a P2MP LSP is setup it must be possible to add additional leaves and prunes leaves as required? "The P2MP LDP mechanism MUST interoperate seamlessly with existing P2P and MP2P LDP mechanisms." What do you mean by interoperate? I assume you mean that P2P, MP2P and P2MP LDP mechanisms must be able to co-exist in the same network but the P2MP LDP mechanism doesn't actually interoperate with P2P/MP2P LDP? Or do you mean that it should be possible for an LSR that doesn't 'speak' P2MP LDP to be able to process and participate in P2MP LDP LSP setup (obviously if it doesn't support P2MP LDP it won't be able to replicate/branch traffic)? Thanks Ben --=20 Ben Niven-Jenkins Network Architect, BT Exact =20 E-mail: benjamin.niven-jenkins@bt.com=20 Office: +44 (0)1473 648225 Mobile: +44 (0)7918 077205 Fax: +44 (0)1332 578827 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue May 16 08:17:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfyRW-0002Dx-6I; Tue, 16 May 2006 08:14:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfyRU-0002Ds-8O for mpls@ietf.org; Tue, 16 May 2006 08:14:24 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfyRS-0003Cn-TL for mpls@ietf.org; Tue, 16 May 2006 08:14:24 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 14:14:13 +0200 Received: from l-at8613.rd.francetelecom.fr ([10.193.15.22]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 14:14:12 +0200 Subject: Re: [mpls] Questions for clarification on draft-ietf-mpls-mp-ldp-reqs-00 From: Thomas Morin To: benjamin.niven-jenkins@bt.com In-Reply-To: References: Content-Type: text/plain Organization: France Telecom R&D Date: Tue, 16 May 2006 14:14:21 +0200 Message-Id: <1147781662.5278.40.camel@wintermute> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 12:14:12.0579 (UTC) FILETIME=[3E0F9B30:01C678E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Benjamin, For both point your assumptions on the intended meaning are correct: - "arbitrary" => in the sense of "free" / "without restriction" - "interoperate" => coexist We probably need to reformulate to avoid any confusion. Cheers, -Thomas benjamin.niven-jenkins@bt.com : > Authors and colleagues, > > Having just read draft-ietf-mpls-mp-ldp-reqs-00 I have a couple of > questions for clarification. > > Section 3.2 - Requirements overview > "The P2MP LDP mechanism MUST allow the arbitrary addition or removal of > leaves associated with a P2MP LSP." > > What do you mean by arbitrary? I assume you mean that once a P2MP LSP > is setup it must be possible to add additional leaves and prunes leaves > as required? > > "The P2MP LDP mechanism MUST interoperate seamlessly with existing P2P > and MP2P LDP mechanisms." > > What do you mean by interoperate? I assume you mean that P2P, MP2P and > P2MP LDP mechanisms must be able to co-exist in the same network but the > P2MP LDP mechanism doesn't actually interoperate with P2P/MP2P LDP? Or > do you mean that it should be possible for an LSR that doesn't 'speak' > P2MP LDP to be able to process and participate in P2MP LDP LSP setup > (obviously if it doesn't support P2MP LDP it won't be able to > replicate/branch traffic)? > > > Thanks > Ben > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue May 16 09:50:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzpq-0001EU-EU; Tue, 16 May 2006 09:43:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzpo-0001EM-T9 for mpls@ietf.org; Tue, 16 May 2006 09:43:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzFI-0005LL-Mh for mpls@ietf.org; Tue, 16 May 2006 09:05:52 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FfykQ-0005Ld-Oe for mpls@ietf.org; Tue, 16 May 2006 08:34:00 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 14:33:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls] Questions for clarification on draft-ietf-mpls-mp-ldp-reqs-00 Date: Tue, 16 May 2006 14:34:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Questions for clarification on draft-ietf-mpls-mp-ldp-reqs-00 Thread-Index: AcZ409wRPXNR5aqCR/uSWa+hAYsKtAADu3Ww From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 16 May 2006 12:33:57.0314 (UTC) FILETIME=[0037D220:01C678E5] X-Spam-Score: -2.6 (--) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Ben, Please see inline,=20 > -----Message d'origine----- > De : benjamin.niven-jenkins@bt.com=20 > [mailto:benjamin.niven-jenkins@bt.com]=20 > Envoy=E9 : mardi 16 mai 2006 12:31 > =C0 : mpls@ietf.org > Objet : [mpls] Questions for clarification on=20 > draft-ietf-mpls-mp-ldp-reqs-00 >=20 > Authors and colleagues, >=20 > Having just read draft-ietf-mpls-mp-ldp-reqs-00 I have a=20 > couple of questions for clarification. >=20 > Section 3.2 - Requirements overview > "The P2MP LDP mechanism MUST allow the arbitrary addition or=20 > removal of leaves associated with a P2MP LSP." >=20 > What do you mean by arbitrary? I assume you mean that once a=20 > P2MP LSP is setup it must be possible to add additional=20 > leaves and prunes leaves as required? Yes, here "arbitrary" means without any constraints (e.g. location of = leaves , arrival/departure orders...) We will reformulate. >=20 > "The P2MP LDP mechanism MUST interoperate seamlessly with=20 > existing P2P and MP2P LDP mechanisms." >=20 > What do you mean by interoperate? I assume you mean that=20 > P2P, MP2P and P2MP LDP mechanisms must be able to co-exist in=20 > the same network but the P2MP LDP mechanism doesn't actually=20 > interoperate with P2P/MP2P LDP? =20 You are right "co-exist" is actually the goog term >Or do you mean that it=20 > should be possible for an LSR that doesn't 'speak' > P2MP LDP to be able to process and participate in P2MP LDP=20 > LSP setup (obviously if it doesn't support P2MP LDP it won't=20 > be able to replicate/branch traffic)? This is not the meaning.=20 In return, note that it should be possible to signal a P2MP LSP through = a non-branch legacy LSR (that doesn't speak P2MP LDP), but we don't = enter the solution specturm here (there are actually various options to = meet this requirement: interop (with backward compatible protocol = extensions), tunneling...). Thanks a lot for your comments, which help clarifying the requirements. Regards, JL >=20 >=20 > Thanks > Ben >=20 >=20 > -- > Ben Niven-Jenkins > Network Architect, BT Exact > =20 > E-mail: benjamin.niven-jenkins@bt.com > Office: +44 (0)1473 648225 > Mobile: +44 (0)7918 077205 > Fax: +44 (0)1332 578827 >=20 > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue May 16 15:54:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg5YT-0007pq-88; Tue, 16 May 2006 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg5YQ-0007oL-6O; Tue, 16 May 2006 15:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg5YP-0002R4-Oc; Tue, 16 May 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k4GJo1XO032587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fg5YP-0007jd-B1; Tue, 16 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 16 May 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-number-0-bw-te-lsps-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org --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 : A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switch Paths signalled across a link Author(s) : J. Vasseur Filename : draft-ietf-mpls-number-0-bw-te-lsps-00.txt Pages : 7 Date : 2006-5-16 Several Link-type sub-TLVs have been defined for OSPF and ISIS in the context of MPLS Traffic Engineering in order to convery some link characteristics such as the available bandwidth, traffic enginering metric, adminstrative group and so on. There are various circumstances where it would be useful to also know the number of unconstrained Traffic Engineering Label Switched Path(s) (TE LSP). This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSP(s) signalled across a specific link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-number-0-bw-te-lsps-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-16125949.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-number-0-bw-te-lsps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-16125949.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Wed May 17 04:44:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgHZ4-0002qr-Td; Wed, 17 May 2006 04:39:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgHZ2-0002pi-SI for mpls@ietf.org; Wed, 17 May 2006 04:39:28 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgHZ1-0000i4-4k for mpls@ietf.org; Wed, 17 May 2006 04:39:28 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 86CE66B7; Wed, 17 May 2006 10:39:26 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 10:39:24 +0200 Received: from [147.214.30.119] ([147.214.30.119]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 10:39:24 +0200 Message-ID: <446AE13C.4010709@ericsson.com> Date: Wed, 17 May 2006 10:39:24 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mpls@ietf.org Subject: Re: [mpls] Fwd: Working group last call: draft-ietf-avt-hc-over-mpls-protocol-05.txt References: <28A58523-F3F5-483E-9763-9E2D5329914F@csperkins.org> <88B272E0-B615-46C9-B608-6AC19B11189A@csperkins.org> In-Reply-To: <88B272E0-B615-46C9-B608-6AC19B11189A@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 08:39:24.0678 (UTC) FILETIME=[66AFBA60:01C6798D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Colin Perkins X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, We would really appreciate if we got some review from you in the MPLS WG that this is fit to publish. So please review the document and provide comments, or simply an endorsement. Thanks Magnus Colin Perkins wrote: > Folks, > > The following working group last call has just been issued in AVT, but > overlaps with the MPLS, ROHC, and PWE3 working groups. We would be > grateful for review from those working groups: please send any comments > on the draft to the mailing list. > > Thanks, > Colin (AVT co-chair) > > > > > Begin forwarded message: >> From: Colin Perkins >> Date: 4 May 2006 17:06:19 BDT >> To: IETF AVT WG >> Subject: Working group last call: >> draft-ietf-avt-hc-over-mpls-protocol-05.txt >> >> This is to announce a working group last call on the Protocol >> Extensions for Header Compression over MPLS >> . Please send any final >> comments on this draft to the avt@ietf.org mailing list by 22nd May >> 2006. If no issues are raised by that time, we will request the IESG >> consider this for publication as a proposed standard RFC. >> >> Colin >> >> >> >> On 3 May 2006, at 20:50, Internet-Drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Audio/Video Transport Working Group >>> of the IETF. >>> >>> Title : Protocol Extensions for Header Compression over MPLS >>> Author(s) : J. Ash, et al. >>> Filename : draft-ietf-avt-hc-over-mpls-protocol-05.txt >>> Pages : 30 >>> Date : 2006-5-3 >>> >>> VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS >>> labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an >>> MPLS VPN, the packet header is typically 48 bytes, while the voice >>> payload is often no more than 30 bytes, for example. Header >>> compression can significantly reduce the overhead through various >>> compression mechanisms. MPLS is used to route header-compressed (HC) >>> packets over an MPLS LSP without compression/decompression cycles at >>> each router. Such an HC over MPLS capability increases the bandwidth >>> efficiency as well as processing scalability of the maximum number of >>> simultaneous compressed flows that use HC at each router. MPLS >>> pseudowires are used to transport the HC context and other control >>> messages between the ingress and egress MPLS label switched router >>> (LSR). Standard HC methods (e.g., ECRTP, ROHC, etc.) are re-used to >>> determine the context. Each HC scheme operates over a single >>> pseudowire instance very much like it would over a single >>> point-to-point link. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-avt-hc-over-mpls-protocol-05.txt >>> > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 17 11:29:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNto-00011E-Qo; Wed, 17 May 2006 11:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNtm-00010G-J0 for mpls@lists.ietf.org; Wed, 17 May 2006 11:25:18 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNtl-00077k-Aq for mpls@lists.ietf.org; Wed, 17 May 2006 11:25:18 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZF00GA41CSYI@usaga01-in.huawei.com> for mpls@lists.ietf.org; Wed, 17 May 2006 08:22:04 -0700 (PDT) Received: from huawei.com (usams01-in [172.18.4.10]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZF00IVK1CSDL@usaga01-in.huawei.com> for mpls@lists.ietf.org; Wed, 17 May 2006 08:22:04 -0700 (PDT) Received: from [172.18.4.6] (Forwarded-For: [68.0.102.87]) by usams01-in.huawei.com (mshttpd); Wed, 17 May 2006 10:27:50 -0500 Date: Wed, 17 May 2006 10:27:50 -0500 From: YongLucy 73674 To: mpls@lists.ietf.org, yasukawa.seisho@lab.ntt.co.jp Message-id: <5e3a345e22d4.5e22d45e3a34@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [mpls] Signaling Requirement for P2MP X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Seisho, This (4461) is good and comprehensive document. It covers a lot of information. Since P2MP LSP is unidirectional paths with many end points, this brings a lot of specialties for the signaling and transmission. If this is only for unidirectional, should we specify if signaling initiates from a source point or a sink point, or both. What restriction applies. Failure discovery becomes an issue for unidirectional transmission, should signaling assists on the failure discovery? Adding/removing a branch, should only allows sink point to initiate the request or the transit point could do it so? Any commont on these? Thanks, Lucy ******************************************************************************************* This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ******************************************************************************************* _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu May 18 11:24:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgkHx-0003da-W9; Thu, 18 May 2006 11:19:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgR86-0001Ru-5t for mpls@lists.ietf.org; Wed, 17 May 2006 14:52:18 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgR82-0001TD-44 for mpls@lists.ietf.org; Wed, 17 May 2006 14:52:18 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k4HIeTB2006337 for ; Wed, 17 May 2006 20:40:29 +0200 Received: from [127.0.0.1] ([172.16.2.197]) by mail1.imc.kth.se; Wed, 17 May 2006 20:50:01 +0200 Message-ID: <446B7056.3010000@pi.se> Date: Wed, 17 May 2006 20:49:58 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Greg Jones greg.jones"@itu.int X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-Mailman-Approved-At: Thu, 18 May 2006 11:19:44 -0400 Cc: mpls@lists.ietf.org, mark.jones@sprint.com, maeda@ansl.ntt.co.jp, fenner@research.att.com, statements@ietf.org, ccamp@ops.ietf.org, pwe3 , Ghani.Abbas@marconi.com, Ross Callon , betts01@nortel.com Subject: [mpls] Response to your liaison on T-MPLS of May 4 and April 2 2006 X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org To: ITU-T Study Group 15 Greg Jones greg.jones@itu.int Cc: IETF statements@ietf.org Stephen Trowbridge sjtrowbridge@lucent.com Ghani Abbas Ghani.Abbas@marconi.com Mark Jones mark.jones@sprint.com Malcolm Betts betts01@nortel.com Yoichi Maeda maeda@ansl.ntt.co.jp Ross Callon rcallon@juniper.net Bill Fenner fenner@research.att.com Scott Bradner sob@harvard.edu George Swallow swallow@cisco.com MPLS mailing list mpls@lists.ietf.org CCAMP mailing list ccamp@ops.ietf.org From: IETF MPLS Working Group Response contact: Loa Andersson loa@pi.se Technical contact: Loa Andersson loa@pi.se Purpose: Information Subject: Response to your liaison on T-MPLS of May 4 and April 2 2006 Thanks for your liaisons of May 4 and April 2 and for the kind invitation to the interim meeting that 19-23 June in Ottawa. We have studied the consented documents from the April liaison and the further clarifications in the May liaisons. We have ensured that IETF technical experts will participate in the Ottawa meeting. This response represents the consensus of the MPLS Working Group at the IETF. Other working groups, such as the PWE3 Working Group may also send responses. We do not consider that the comments we sent in our preliminary response have been addressed satisfactorily. We also understand that at least one new parameter has been introduced late in the discussion - the design decision that T-MPLS will be initially scoped to 802.3 clients (Ethernet interfaces), with future consideration for MPLS LSR clients. There are three major issues that we need to understand: 1. The requirements We have not seen any documentation of the problem that T-MPLS solves. 2. The reserved labels As this is a compatibility issue, we are very concerned. We request that you document any requirements for reserved labels and bring those requirements to the MPLS Working Group in the IETF. There is a (G)MPLS change process that can be used for this "draft-andersson-rtg-gmpls-change-02.txt" 3. MPLS functionality equipment T-MPLS networks. Since we still incompatibilities between the MPLS and T-MPLS specifications we are concerned that existing MPLS equipment, even though T-MPLS is said to to be a true subset of MPLS, won't be possible to use in T-MPLS networks. The recently introduced design with Ethernet EVCs will help to get around some of the issues we pointed out. Equipment in the T-MPLS network will not have to negotiate labels with equipment in MPLS enabled IP networks. However, we are still concerned about what "future consideration for IP/MPLS clients" might entail. Loa Andersson and George Swallow IETF MPLS Working Group Co-Chairs -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu May 18 11:35:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgkU5-00085y-2b; Thu, 18 May 2006 11:32:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgXjL-0003jY-PT for mpls@lists.ietf.org; Wed, 17 May 2006 21:55:11 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgXjK-00088E-Qa for mpls@lists.ietf.org; Wed, 17 May 2006 21:55:11 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZF00KQ9USFXA@szxga03-in.huawei.com> for mpls@lists.ietf.org; Thu, 18 May 2006 09:57:51 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IZF005ZUUSE5F@szxga03-in.huawei.com> for mpls@lists.ietf.org; Thu, 18 May 2006 09:57:51 +0800 (CST) Received: from h46673 ([10.110.100.41]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IZF005N2V8Y82@szxml01-in.huawei.com> for mpls@lists.ietf.org; Thu, 18 May 2006 10:07:47 +0800 (CST) Date: Thu, 18 May 2006 09:49:14 +0800 From: "Roby (Hu Ruoheng)" To: mpls@lists.ietf.org Message-id: <001a01c67a1d$4475d110$29646e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 X-Mailman-Approved-At: Thu, 18 May 2006 11:32:15 -0400 Subject: [mpls] About "MplsIndexType" X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1627202683==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1627202683== Content-type: multipart/alternative; boundary="Boundary_(ID_lXPYZRYgRv+T0COIPIZzeA)" This is a multi-part message in MIME format. --Boundary_(ID_lXPYZRYgRv+T0COIPIZzeA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hello everyone: Here comes a question about mpls mib. Please give me some advice. Now we are using a MIB named MPLS-LSR-STD-MIB (from rfc3813).In this MIB, there is a TC defined as follow: MplsIndexType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is an octet string that can be used as a table index in cases where a large addressable space is required such as on an LSR where many applications may be provisioning labels. Note that the string containing the single octet with the value 0x00 is a reserved value used to represent special cases. When this TEXTUAL-CONVENTION is used as the SYNTAX of an object, the DESCRIPTION clause MUST specify if this special value is valid and if so what the special meaning is. In systems that provide write access to the MPLS-LSR-STD MIB, mplsIndexType SHOULD be used as a simple multi-digit <==== What is "multi-digit integer" ? integer encoded as an octet string. No further overloading of the meaning of an index SHOULD be made. In systems that do not offer write access to the MPLS-LSR-STD MIB, the mplsIndexType may contain implicit formatting that is specific to the implementation to convey additional information such as interface index, physical card or device, or application id. The interpretation of this additional formatting is implementation dependent and not covered in this document. Such formatting MUST NOT impact the basic functionality of read-only access to the MPLS-LSR-STD MIB by management applications that are not aware of the formatting rules." SYNTAX OCTET STRING (SIZE(1..24)) We don't know how to display a table index in this type . This TC is to describe an mpls label, and it should be follow the objects in the table. We think there are two ways: For example, to respond the mplsInSegmentInterface node in the mplsInSegmentTable with mplsInSegmentIndex as index, and the index value is 1025. 1 mplsInSegmentInterface.4.1.0.2.5 = InterFaceNo1 The value 1025 is separated into four number and add index's length para before them. 2 mplsInSegmentInterface.3.4.0.1 = InterFaceNo1 Convert the number 1025 into hex and each byte correspond to an oid space , then also add index's length para before them. (decimalist 1025 = hex 401) I'm inclined to the first solution. What is your opinion ? Both wrong or one of them is correct ? Waiting for your respond. Thank you very much. --Boundary_(ID_lXPYZRYgRv+T0COIPIZzeA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hello everyone:
 
    Here comes a question about mpls mib. Please give me some advice.
    Now we are using a MIB named MPLS-LSR-STD-MIB (from rfc3813).In this MIB, there is a TC defined as follow:
 
 
 
    MplsIndexType ::= TEXTUAL-CONVENTION
        STATUS              current
        DESCRIPTION
            "This is an octet string that can be used as a table
             index in cases where a large addressable space is
             required such as on an LSR where many applications
             may be provisioning labels.
   
             Note that the string containing the single octet with
             the value 0x00 is a reserved value used to represent
             special cases. When this TEXTUAL-CONVENTION is used
             as the SYNTAX of an object, the DESCRIPTION clause
             MUST specify if this special value is valid and if so
             what the special meaning is.
   
             In systems that provide write access to the MPLS-LSR-STD
             MIB, mplsIndexType SHOULD be used as a simple multi-digit           <====  What is "multi-digit integer" ?
             integer encoded as an octet string.
             No further overloading of the meaning of an index SHOULD
             be made.
   
             In systems that do not offer write access to the MPLS-LSR-STD
             MIB, the mplsIndexType may contain implicit formatting that is
             specific to the implementation to convey additional
             information such as interface index, physical card or
             device, or application id. The interpretation of this
             additional formatting is implementation dependent and
             not covered in this document. Such formatting MUST
   
             NOT impact the basic functionality of read-only access
             to the MPLS-LSR-STD MIB by management applications that are
             not aware of the formatting rules."
        SYNTAX                OCTET STRING (SIZE(1..24))
 
 
 
 
    We don't know how to display a table index in this type . This TC is to describe an mpls label, and it should be follow the objects in the table.
We think there are two ways:
 
For example, to respond the mplsInSegmentInterface node in the mplsInSegmentTable with mplsInSegmentIndex as index, and the index value is 1025.
 
1   mplsInSegmentInterface.4.1.0.2.5 = InterFaceNo1         The value 1025 is separated into four number and add index's length para before them.
 
2   mplsInSegmentInterface.3.4.0.1 = InterFaceNo1           Convert the number 1025 into hex and each byte correspond to an oid space , then also add index's length para before them.
                                                            (decimalist 1025 = hex 401)
 
 
I'm inclined to the first solution. What is your opinion ? Both wrong or one of them is correct ?
 
Waiting for your respond. Thank you very much.
 
 
--Boundary_(ID_lXPYZRYgRv+T0COIPIZzeA)-- --===============1627202683== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1627202683==-- From mpls-bounces@lists.ietf.org Fri May 19 03:54:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgzjH-0002pT-Fv; Fri, 19 May 2006 03:48:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgzjF-0002pO-Ee for mpls@ietf.org; Fri, 19 May 2006 03:48:57 -0400 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgzjE-00036c-Uy for mpls@ietf.org; Fri, 19 May 2006 03:48:57 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=[172.16.2.197]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1Fgzix-0007tV-UE for mpls@ietf.org; Fri, 19 May 2006 09:48:42 +0200 Message-ID: <446D77DE.6020209@pi.se> Date: Fri, 19 May 2006 09:46:38 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: mpls@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Subject: [mpls] [Fwd: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada] X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Working group, please find the draft cutoff dates for the Montreal meeting included. /Loa -------- Original Message -------- Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada Date: Fri, 19 May 2006 00:00:01 -0400 From: ietf-secretariat@ietf.org To: ietf-announce@ietf.org There are two (2) Internet-Draft cutoff dates for the 66th IETF Meeting in Montreal, Quebec, Canada: June 19th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, June 19th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, June 12th at 9:00 AM ET. June 26th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, June 26th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, July 10th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_66.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri May 19 09:50:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh5J3-0004A4-La; Fri, 19 May 2006 09:46:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh5J2-00049y-AG for mpls@ietf.org; Fri, 19 May 2006 09:46:16 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh5Iz-00013f-Of for mpls@ietf.org; Fri, 19 May 2006 09:46:16 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1Fh5Ir-0001KY-00 for mpls@ietf.org; Fri, 19 May 2006 14:46:05 +0100 Received: from your029b8cecfe ([217.158.132.227] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 14:46:00 +0100 Message-ID: <09fc01c67b4a$8cea27b0$36849ed9@your029b8cecfe> From: "Adrian Farrel" To: References: <4465B972.4090305@pi.se> Date: Fri, 19 May 2006 14:11:27 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 19 May 2006 13:46:01.0799 (UTC) FILETIME=[910D1D70:01C67B4A] X-Spam-Score: 0.1 (/) X-Scan-Signature: e49d56f78a2637b8182dc0162b2e0346 Cc: Subject: [mpls] Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, Thanks to the editors. Good job. Here are some comments... Adrian == Title Here you say "Point to Multipoint", but in the rest of the document it is hyphenated. == Abstract s/setup/set up/ (setup is a noun not a verb) == Abstract Looks like you want a paragraph break before... "There can be various applications..." == Section 3. Acronyms must be spelt out the first time they are encountered. The Abstract (regrettably) is stand-alone and doesn't count, so the Introduction has to do it all again :-( Anyway, P2P and S2L are new. == Section 3 para 3 One Path message may signal one or multiple S2L sub-LSPs. Hence the S2L sub-LSPs belonging to a P2MP LSP can be signaled using one Path message or split across multiple Path messages. The conjunction of these two sentences implies that a single Path message may also contain the S2L sub-LSPs from different P2MP LSPs. I don't believe this is the case, and we should correct this text accordingly. For example: One Path message may signal one or multiple S2L sub-LSPs for a single P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP LSP can be signaled using one Path message or split across multiple Path messages. == Section 3 para 4 s/application specific/application-specific/ == Section 4 para 1 A branch node is an LSR that is capable of replicating the incoming data on two or more outgoing interfaces. Technically, it only replicates it on one or more outgoing interfaces, because the first interface is not a replication. == Section 4.1 para 1 The specific aspect related to a P2MP TE LSP is the action required at a branch node, where data replication occurs. Incoming MPLS labeled data is appropriately replicated to several outgoing interfaces which may have different labels. Not sure if this is trying to say something more, or is just poorly worded. How about... The defining feature of a P2MP TE LSP is the action required at branch nodes where data replication occurs. Incoming MPLS labeled data is appropriately replicated to several outgoing interfaces which may use different labels for the data. == Section 4.1 para 2 A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is identified by a P2MP SESSION object. This object contains the identifier of the P2MP Session which includes the P2MP ID, a tunnel ID and an extended tunnel ID. Need to turn this paragraph around a bit. A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is identified the P2MP ID, a tunnel ID, and an extended tunnel ID. These objects are carried in RSVP-TE in a P2MP SESSION object. == Section 4.1 para 3 The fields of a P2MP SESSION object are identical to those of the SESSION object defined in [RFC3209] except that the Tunnel Endpoint Address field is replaced by the P2MP Identifier (P2MP ID) field. The comparison is not quite so simple in the IPv6 case because the 16 byte IPv6 tunnel endpoint address is replaced by a 4 byte P2MP ID. We should bring this out in this paragraph as follows. The fields of a P2MP SESSION object are identical to those of the SESSION object defined in [RFC3209] except that the Tunnel Endpoint Address field (IPv4 or IPv6) is replaced by the 4-byte P2MP Identifier (P2MP ID) field. == Section 4.1 Add a forwards reference at the end of the section as follows. The new P2MP SESSION object is defined in section 19.1. == Section 4.2 s/20.2/19.2/ == Section 4.3 para 3 s/subgroup/sub-group/ Please do global search and replace in the document == Section 4.3 para 3 s/an egress and semantic/an egress, and semantic/ == Section 4.4.1 para 1 s/20.3/19.3/ == Section 4.4.1 para 2 s/20.5/19.5/ s/20.6/19.6 == Section 4.4.1 and onwards The S2L_SUB_LSP object is consistently referred to in angle brackets, but no other object is given this treatment. Please remove the brackets everywhere except in BNF. == Section 4.4.1 It seems to me that the S2L_SUB_LSP object contains a leaf identifier and an SERO. The SERO provides the path from the last branch to the leaf. This means that it is not an S2L_SUB_LSP object at all, but really a S2L_SUB_LSP object. But that sounds clumsy. Can we call this a LEAF object? We would also rename the descriptor lists in section 5.1, 6.1, 7.1, and 11.1. We could change the names of the IPv4/IPv6 S2L Sub-LSP destination address, but that isn't necessary. == Section 4.4.2 para 1 s/setup/set up/ == Section 4.5 para 1 When a Path message signals a single S2L sub-LSP (that is, the Path message is only targeting a single leaf in the P2MP tree), the EXPLICIT_ROUTE object encodes the path from the ingress LSR to the egress LSR. Strike the words "from the ingress LSR" as this situation may also occur within the network (for example, downstream of a branch node, or just anywhere if the original Path message only included one S2L sub-LSP). == Section 4.5 para 2 When a Path message signals multiple S2L sub-LSPs the path of the first S2L sub-LSP, from the ingress LSR to the egress LSR, is encoded in the ERO. As above, strike "from the ingress LSR" == Section 4.5 para 3 s/(as defined in [RFC3209])/(as defined in [RFC3209] and [RFC3473])/ == Section 4.5 para 3 Each subsequent S2L sub-LSP is represented by tuples of the form < [] >. Should read... Each subsequent S2L sub-LSP is represented by tuples of the form < , [] >. ...since this is the order used in the encoding. == Section 4.5 para 3 An SERO for a particular S2L sub-LSP includes only the path from a certain branch LSR to the egress LSR if the path to that branch LSR can be derived from the ERO or other SEROs. Strike "certain" as this applies to any branch LSR in any network. == Section 4.5 para 3 s/20/19/ == Section 4.5 para 6 s/Following/The following/ Also near the top of page 10. == Section 4.5 s/exercise to the reader./exercise for the reader./ == Section 4.5 page 10 s/A LSR/An LSR/ s/a S2L/an S2L/ s/a SERO/an SERO/ Probably worth checking the whole document. == Section 5.1 layout of is messed up == Section 5.1 A SERO corresponds to the following object. s/A/An/ Oh no it doesn't! Say... An SERO corresponds to the preceding object. == Section 5.1 The RRO in the sender descriptor contains the hops traversed by the Path message and applies to all the S2L sub-LSPs signaled in the Path message. That is rather an MPLS-centric view of the world. Better to say... The RRO in the sender descriptor contains the upstream hops traversed by the LSP up to this point and applies to all the S2L sub-LSPs signaled in the Path message. == Section 5.2 para 1 s/ingress-LSR/ingress LSR/ s/egress-LSR/egress LSR/ s/that is the destination/that is a destination/ == Section 5.2 para 1 Another S2L sub-LSP belonging to the same instance of this S2L sub-LSP (i.e. the same P2MP LSP) shares resources with this S2L sub-LSP. In previous versions of the draft we had "can share" in place of "shares", and this was with good reason. It is perfectly acceptable for replication to take place at an upstream node and for two copies of the data to flow on the same link before being fanned out down stream. This might happen in an optical network where the split node is not capable of the appropriate lambda conversions, but might also happen in a packet network where the downstream node cannot perform sufficient replication in a timely manner (or at all) and so some of the replication must be done upstream regardless of the 'waste' of resources in the network. Since we are in 2119-land (these are protocol procedures) please replace "shares" with "MAY share". However (!) note that in 5.2.1 para 4 we have "SHOULD". I can accept "SHOULD" in this paragraph, too. == Section 5.2 para 1 s/identified using the object/identified using the objects/ == Section 5.2 para 2 s/20/19/ == Section 5.2.1 para 1 You have changed your notation for tuples == Section 5.2.1 para 3 An ingress LSR may use multiple Path messages for signaling a P2MP LSP. s/may/MAY/ == Section 5.2.1 para 3 This implies that each Path message that is used to signal a P2MP LSP is signaled using the same signaling attributes with the exception of the S2L sub-LSP information and Sub-Group identifiers. s/information/descriptor/ s/identifiers/identifier/ == Section 5.2.1 para 5 In this case the message can be decomposed into multiple Path messages such that each of the messages carry a subset of the X2L sub-tree carried by the incoming message. s/carry/carries/ == Section 5.2.1 para 6 In order to disambiguate these Path messages a tuple is introduced (also referred to as the Sub-Group field) and encoded in the SENDER_TEMPLATE object. s/field/fields/ == Section 5.2.1 para 6 This is either the ingress LSR or a LSR which re-originates the Path message with its own Sub- Group Originator ID. This sentence doesn't add anything. Strike it. == Section 5.2.1 para 6 The tuple is globally unique. I'm not sure what this means. The same LSR can use the same sub-Group ID on different LSPs since the LSPs are distinguished by session/sender template. Further, there is some conflict with the sentences immediately afterwards... The sub-Group ID space is specific to the Sub-Group Originator ID. Therefore the combination is network-wide unique. Since no conclusion appears to be drawn from this uniqueness, I would say that the sub-Group ID is unique within the context of a P2MP LSP and that the sub-Group Originator ID is network-wide unique. == Section 5.2.1 para 6 Also, a router that changes the Sub-Group originator ID of an incoming Path message MUST use the same value of the Sub-Group Originator ID for all outgoing Path messages, for a particular P2MP LSP, and SHOULD not vary it during the life of the P2MP LSP. This may be confusing in the light of the fact (a few lines earlier) that... The Sub-Group Originator ID MUST be set to the TE Router ID of the LSR that originates the Path message. Certainly the "MUST"s are complementary, but what is with the "SHOULD"? == Section 5.2.2 para 1 The S2L sub-LSP descriptor list allows the signaling of one or more S2L sub-LSPs in one Path message. It is possible to signal multiple object and ERO/SERO combinations in a single Path message. Note that these two objects differentiate a S2L sub-LSP. The first two sentence are largely duplicates. The third sentence says two objects, three have been mentioned. How about... The S2L sub-LSP descriptor list allows the signaling of one or more S2L sub-LSPs in one Path message. Each S2L sub-LSP descriptor describes a single S2L sub-LSP. == Section 5.2.2 3rd bullet - If the first hop of the SERO is not a local address of the LSR the S2L sub-LSP descriptor MUST be included in the Path message sent to LSR that is the next hop to reach the first hop in the SERO. This next hop is determined by using the ERO or other SEROs that encode the path to the SERO's first hop. s/sent to LSR/sent to the LSR/ == Section 5.2.2 Hence a branch LSR MUST only propagate the relevant S2L sub-LSP descriptors on each downstream link. A S2L sub-LSP descriptor list that is propagated on a downstream link MUST only contain those S2L sub-LSPs that are routed using that link. This processing MAY result in a subsequent S2L sub-LSP in an incoming Path message to become the first S2L sub-LSP in an outgoing Path message. I'm not sure if this is what I wrote, but anyway, it is wrong! Path messages are not propagated on downstream links, but are sent to the next hop towards the egress. This finesse of words is important when out-of-channel signaling is considered. So reword as follows... Hence a branch LSR MUST only propagate the relevant S2L sub-LSP descriptors to each next downstream hop. An S2L sub-LSP descriptor list that is propagated to a downstream hop MUST only contain those S2L sub-LSPs that are routed using that hop. This processing MAY result in a subsequent S2L sub-LSP in an incoming Path message to become the first S2L sub-LSP in an outgoing Path message. == Section 5.2.2 Note that if one or more SEROs contain loose hops, expansion of such loose hops MAY result in overflowing the Path message size. Section 5.2.3 describes how signaling of the set of S2L sub-LSPs can be split in more than one Path message. s/split in more/split across more/ == Section 5.2.2 The RECORD_ROUTE Object (RRO) contains the hops traversed by the Path message and applies to all the S2L sub-LSPs signaled in the Path message. A transit LSR MUST append its address in an incoming RRO and propagate it downstream. A branch LSR MUST form a new RRO for each of the outgoing Path messages by copying the RRO from the incoming Path message and appending its address. Each such updated RRO MUST be formed using the rules in [RFC3209]. s/in [RFC3209]./in [RFC3209] updated by [RFC3473] as appropriate./ == Section 5.2.2 If a LSR is unable to support a S2L sub-LSP in a Path message, a PathErr message MUST be sent for the impacted S2L sub-LSP, and normal processing of the rest of the P2MP LSP SHOULD continue. Suggest the addition of an example... If a LSR is unable to support a S2L sub-LSP in a Path message (for example, it is unable to route towards the destination using the SERO), a PathErr message MUST be sent for the impacted S2L sub-LSP, and normal processing of the rest of the P2MP LSP SHOULD continue. == Section 5.2.2 s/section 12./sections 5.2.4 and 11./ == Section 5.2.3 Title The title of this section is ambiguous. Does the transit get fragmented? Suggest 5.2.3. Transit Fragmentation of Path State Information == Section 5.2.3 It is desirable not to rely on IP fragmentation in this case. This bald statement needs qualification and should not be left as an exercise for the reader. Presumably the reason is that IP fragmentation of RSVP messages is explicitly disallowed in section 3.3 of RFC2205. In which case "desirable" does not come into it, and this is a stronger requirement. However, in practice, IP fragment loss and the consequent message loss, is no different from IP packet loss and the consequent message loss. Or is it? == Section 5.2.3 para 2 When multiple Path messages are used by an ingress or transit node, each Path message SHOULD be identical with the exception of the S2L sub-LSP related information (e.g., SERO), s/related information/descriptor/ == Section 5.2.3 para 3 As described above one case in which the Sub-Group Originator ID of a received Path message is changed is that of transit fragmentation. s/transit fragmentation/fragmentation of the Path message at a transit node/ == Section 6.1 The format of the definition has been messed up == Section 6.1 I don't think we should use the same name for the as is used for the Path message as it leads to exactly the same confusion and error as we have here. Viz. ::= [ ] Should read... ::= [ ] (and obviously the format needs to be sorted out) So I suggest changing the name to be different from that used in a Path message as the descriptor is a different entity. == Section 6.1 final para However different upstream labels are allocated if the of the FILTER_SPEC object is different as that implies different P2MP LSP. s/are/MUST be/ == Section 6.2 para 1 The egress LSR MUST follow normal RSVP procedures while originating a Resv message. The Resv message carries the label allocated by the egress LSR. Is this the case, or does the Resv message from the egress contain an S2L_SUB_LSP object? If it is the case that the S2L_SUB_LSP MUST be included then please say so in this paragraph. If this paragraph is correct as it stands, please add a note to say that the S2L_SUB_LSP object MUST NOT be included. == Section 6.2 Each branch node can potentially send one Resv message upstream for each of the downstream receivers. This MAY result in overflowing the Resv message, particularly when considering that the number of messages increases the closer the branch node is to the ingress of the P2MP LSP. As currently written, this says that one Resv message is sent for each downstream receiver (i.e. n messages when there are n receivers). I don't think you means this because the next sentence talks about overflowing which would not arise in this case. At the same time, the increase in the number of messages closer to the ingress is not relevant, it is the increase in the number of receivers. If you are *also* trying to talk about the potential of a single message per receiver and the impact of the consequent number of messages as you get closer to the ingress, with the implied desirability of combining messages into a single Resv, then this needs to be said separately. So... Each branch node MAY forward a single Resv message upstream for each received Resv from a downstream receiver. Note that there may be a large number of Resv messages at and close to the ingress LSR for an LSP with many receivers. To avoid issues of congestion, a branch LSR SHOULD combine Resv state from multiple receivers into a single Resv message to be sent upstream (see section 6.2.1), but note that this may result in overflowing the Resv message particularly as the number of receivers downstream of any branch LSR increases as the LSR is closer to the ingress LSR. Thus, a branch LSR MAY choose to send more than one Resv message upstream and partition the Resv state between the messages. == Section 6.2 final paragraph Transit nodes MUST replace the Sub-Group ID fields received in the FILTER_SPEC objects with the value that was received in the Sub-Group ID field of the Path message from the upstream neighbor, when the node set the Sub-Group Originator field in the associated Path message. ResvErr messages generation is unmodified. Nodes propagating a received ResvErr message MUST use the Sub-Group field values carried in the corresponding Resv message. Split the ResvErr text into a second paragraph == Section 6.2.1 para 1 A branch node may have to send the Resv message being sent upstream whenever there is a change in a Resv message for a S2L sub-LSP received from one of the downstream neighbors. Some problems with tense. Try... A branch node may have to send a revised Resv message upstream whenever there is a change in a Resv message received from one of its downstream neighbors for a S2L sub-LSP. == Section 6.2.1 para 1 s/upstream,particularly/upstream, particularly/ == Section 6.2.1 para 1 s/established for the first time./first established/ == Section 6.2.1 recommends the use of a timer. IETF protocol specification rules require that we suggest a value for all protocol timers. Please suggest a value here - it could be a function of some other timer, a function of the number of downstream destinations, or just a raw number. == Section 6.3 Title "Record Routing" doesn't do it for me! What "Route Recording"? == Section 6.3.1 para 1 A Resv message contains a record route per S2L sub-LSP that is being signaled by the Resv message if the sender node requests route recording by including a RRO in the Path message. The same rule is used during signaling of P2MP LSP i.e. insertion of the RRO in the Path message used to signal one or more S2L sub-LSP triggers the inclusion of an RRO for each sub-LSP. Say either "recorded route" or "route record". I think this paragraph is trying to contract P2P (first sentence) with P2MP (subsequent sentence), but actually describes P2MP in both with the result that "The same rule is used..." is confusing. How about... A Resv message for a P2P LSP contains a recorded route if the ingress LSR requested route recording by including an RRO in the original Path message. The same rule is used during signaling of P2MP LSPs. That is, inclusion of an RRO in the Path message used to signal one or more S2L sub-LSPs triggers the inclusion of a recorded route for each sub-LSP in the Resv. == Section 6.3.1 para 2 The record route of the first S2L sub-LSP is encoded in the RRO. s/record route/recorded route/ == Section 6.3.1 para 2 Additional RROs for the subsequent S2L sub-LSPs are referred to as P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). s/RROs/recorded routes/ s/referred to as/encoded in/ == Section 6.3.1 para 2 s/20.5/19.5/ == Section 6.3.1 para 2 The ingress node then receives the RRO and possibly the SRRO corresponding to each subsequent S2L sub-LSP. Each object is followed by the RRO/SRRO. The ingress node can then determine the record route corresponding to a particular S2L sub-LSP. The RRO and SRROs can be used to construct the end to end Path for each S2L sub-LSP. First sentence is duplicated later and should be removed as confusing. But the text is wrong anyway. Rewrite as... Each S2L_SUB_LSP object in a Resv is associated with an RRO or SRRO. The first S2L_SUB_LSP object (for the first S2L sub-LSP) is associated with the RRO. Subsequent S2L_SUB_LSP objects (for subsequent S2L sub-LSPs) are each followed by an SRRO that contains the recorded route for that S2L sub-LSP from the leaf up to a branch. The ingress node can then determine use the RRO and SRROs to determine the end-to-end path for each S2L sub-LSP. == Section 6.4 para 1 s/can either be FF or SE./can be either FF or SE./ == Section 6.4 para 1 The S2L sub-LSPs that belong to different P2MP LSP MUST NOT share labels. If the reservation style is FF then S2L sub-LSPs that belong to different P2MP LSP MUST NOT share resources. If the reservation style is SE than S2L sub-LSPs that belong to different P2MP LSP and the same P2MP Tunnel SHOULD share resources where they share hops, but MUST not share labels. s/different P2MP LSP/different P2MP LSPs/ (thrice) s/than/then/ This text gives GMPLS a problem because SE sharing of resources in non-packet networks requires sharing of labels (and this is how make-before-break is usually performed in resource-constrained non-packet environments). I would suggest that the first sentence is superfluous as it is covered by either FF or SE. Can we rewrite as... If the reservation style is FF then S2L sub-LSPs that belong to different P2MP LSPs MUST NOT share resources or labels. If the reservation style is SE then S2L sub-LSPs that belong to different P2MP LSPs and the same P2MP Tunnel SHOULD share resources where they share hops, but MUST not share labels in packet environments. == Section 7.2.2 para 2 A transit LSR that propagates the PathTear message downstream MUST ensure that it sets the tuple in the PathTear message to the values used to generate the previous Path message that corresponds to the S2L sub-LSPs being deleted by it in the PathTear message. This is a bit clumsy. How about... A transit LSR that propagates the PathTear message downstream MUST ensure that it sets the tuple in the PathTear message to the values used in the Path message used to set up the S2L sub-LSPs being torn down. == Section 8.1 para 1 s/and Notify messages/and Notify message/ s/Both object and messages/Both object and message/ == Section 8.1 point 2. para 1 s/to the value, that was/to the value that was/ == Section 8.1 point 2. para 1 If the incoming Resv message carries a Notify Request object then the LSR MUST set the Notify node address in the Notify Request object to the value, that was received in the corresponding Path message, in the Resv message that it sends upstream. Too many sub-clauses. Try... If the incoming Resv message carries a Notify Request object then the LSR MUST set the Notify node address in the Notify Request object in the Resv message that it sends upstream to the value that was received in the corresponding Path message, == Section 8.1 Missing final period. == Section 8.2 para 2 s/to the value, that was/to the value that was/ == Section 8.2 para 2 s/carry/carries/ == Section 8.2 final para All downstream branches that do requested ResvConf messages MUST be sent such a message. s/that do/that/ == Section 9 s/LSP/LSPs/ (twice) == Section 10 para 1 Not sure what this is trying to say by "managed". Perhaps "indexed" or "identified" or "located"? == section 10 para 2 s/object/objects/ == Section 10.1 para 3 s/4.2/5.2/ == Section 10 Suddenly the definition of TE Router ID is given a reference to [RFC3477] which wasn't present in earlier uses of the term (section 5.2.1, 5.2.3). Firstly, we need to be consistent, but more important (to me) is that 3477 does NOT define TE Router ID: it defines Router ID. You are faced, therefore with: - drop the reference - define the term yourself - find another reference. The best other reference I can find is draft-ietf-ccamp-gmpls-addressing-03.txt == Section 11 s/requests the maintenance of the 'LSP integrity'/requests the maintenance of 'LSP integrity'/ == Section 11 Therefore, reception of an error message for a particular S2L sub-LSP MAY change the state of any other S2L sub- LSP of the same P2MP TE LSP. I think this is a lowercase "may". There is no element of choice for an implementation here. == Section 11.1 Need a reference to the definition of in section 5.1 == Section 11.2 Would benefit from a reference to the revised defined in section 6.1 == Section 11.2 Note the receiver of a ResvErr message is able to identify the errored outgoing Path message, and outgoing interface, based on the Sub-Group fields received in the ResvErr message. This should either say "*incoming* Path" or "outgoing *Resv*" == Section 11.3 A branch LSR that receives a PathErr message with the Path_State_Removed flag clear MUST act according to the wishes of the ingress LSR. The default behavior is that the branch LSR forwards the PathErr upstream and takes no further action. However, if the LSP integrity flag is set on the Path message, the branch LSR MUST send PathTear on all downstream branches and send the PathErr upstream with the Path_State_Removed flag set (per [RFC3473]). This only applied during LSP setup. That is, the LSP integrity flag does not impact on any LSP state once the LSP has been set up and if the PathErr does not have the Path_State_Removed flag set. (Compare with the first paragraph of this section.) So this paragraph should read... A branch LSR that receives a PathErr message during LSP setup with the Path_State_Removed flag clear MUST act according to the wishes of the ingress LSR. The default behavior is that the branch LSR forwards the PathErr upstream and takes no further action. However, if the LSP integrity flag is set on the Path message, the branch LSR MUST send PathTear on all downstream branches and send the PathErr upstream with the Path_State_Removed flag set (per [RFC3473]). == Section 14.2 para 1 s/the incremental/incremental/ == Section 15 Please change [RFC4090] extensions can be used to perform fast reroute for the mechanism described in this document. to [RFC4090] extensions can be used to perform fast reroute for the mechanism described in this document when applied within packet networks. == Section 15.1 .1 This text is particularly dense and would benefit from re-writing and paragraph breaks. Some non-exhaustive comments follow. == Section 15.1.1 The two uses of "MUST" seem to be overkill. RFC 4090 only uses "SHOULD" for P2P LSPs. == Section 15.1.1 Note that all such S2L sub-LSPs belonging to a particular instance of a P2MP tunnel will share the same outgoing label on the link between the PLR and the next-hop. This is only a "SHOULD share labels" in section 5.2.1. Not a big deal. Just delete this and the subsequent sentence. == Section 15.1.1 Paragraph break before During failure Path messages for each S2L sub-LSP, that are effected, MUST be sent to the MP, by the PLR. which should be rewritten as During failure, Path messages for each S2L sub-LSP that is affected MUST be sent to the MP by the PLR. == Section 15.1.1 s/It is recommended that/It is RECOMMENDED that/ == Section 15.1.1 s/the PLR use/the PLR uses/ == Section 15.1.1 s/sender template specific/sender template-specific/ == Section 15.1.1 Paragraph break before The MP MUST use == Section 15.1.1 Change The MP MUST use the LSP-ID to identify the corresponding S2L sub-LSPs. The MP MUST not use the while identifying the corresponding S2L sub-LSPs. In order to further process a S2L sub-LSP the MP MUST determine the protected S2L sub-LSP using the LSP-id and the object. to The MP MUST use the LSP-ID and the object to identify the corresponding S2L sub-LSPs. The MP MUST not use the to identify the corresponding S2L sub-LSPs because the sub-group originator ID might be changed by some LSR that is bypassed by the bypass tunnel. == Section 15.1.1 Please add the following. Note that these procedures may require that the PLR replicate data for a P2MP LSP into more than one bypass tunnel where the LSR was not previously responsible for replicating this data. This can arise if there are several MPs that are not one hop downstream of the PLR. Further, in this case, the replicated data may be required to be labeled with a two-label label stack where both labels are different in each copy of the data. == Section 15.1.2 Again, the use of "MUST" is stronger than RFC 4090 == Section 15.1.2 The MP MUST allocate the same label to all such S2L sub-LSPs belonging to a particular P2MP LSP. I think you cannot make this constraint. The MP doesn't necessarily know that it is going to be an MP when it allocates the label for the S2L sub-LSP. Besides, 5.2.1 has already allowed separate labels. But this isn't an issue is it? If there are two labels there are already two copies of the data. == Section 15.1.2 para 2 After detecting failure of the protected node the PLR MUST send a Path message for each protected S2L sub-LSP to the MP of the protected S2L sub-LSP. This implies one Path message for each S2L sub-LSP is that really the case? Since we have a mechanism for placing more than one S2L sub-LSP in a Path message, we could certainly use this here. == Section 15.1.2 para 2 s/recommended/RECOMMENDED/ == Section 15.1.2 para 2 s/MUST not/MUST NOT/ == Section 15.1.2 para 2 Similar changes as in 15.1.1 wrt "while identifying" == Section 15.2 para 2 Unlike the bypass stuff, the detour work seems a bit rocky. Perhaps no-one has implemented it yet? One to one backup as described in [RFC4090] can be used to protect a particular S2L sub-LSP against link and next-hop failure. Protection may be used for one or more S2L sub-LSPs between the PLR and the next-hop. All the S2L sub-LSPs corresponding to the same instance of the P2MP tunnel, between the PLR and the next-hop share the same P2MP LSP label. This leaves me uneasy. Firstly, the statement about using the same label is in contradiction with section 5.2.1. But also, it seems to me odd that you are talking about protecting S2L sub-LSPs rather than about protecting the P2MP LSP. True, you may achieve the protection of the P2MP LSP by protecting each constituent S2L sub-LSP, but if you start with the discussion of S2L sub-LSPs it implies that you could protect sub S2L sub-LSPs within one P2MP LSP and not others. This would appear to be a contradiction of the statement that all leaves of the tree have the same LSP attributes. So I think it would be helpful to spend some time reworking this text in terms of the P2MP LSP. == Section 15.2 para 2 All or some of these S2L sub-LSPs may be protected. This seems to confirm my worst fears, but it is also damnably strange. Consider: you have said that all of the S2L sub-LSPs use the same label. Notwithstanding that I disagree with you, let us assume that they do. How then would you protect only a subset of them? There is only one copy of the data. == Section 15.2 para 2 The detour S2L sub-LSPs may or may not share labels, depending on the detour path. Thus the set of outgoing labels and next-hops for a P2MP LSP that was using a single next-hop and label between the PLR and next-hop before protection, may change once protection is triggerred. Why would the label sharing for the detour LSPs (please don't call them "detour S2L sub-LSPs" because they really don't go from the S or to the L) behave differently from the protected LSPs? I *think* you are setting yourself up for different MPs depending on the leaves. But you didn't describe this process for bypass tunnels where it is surely equally applicable. == Section 15.2 para 4 s/recommended/RECOMMENDED/ == Section 16 para 7 The ingress can use IGP extensions to determine non P2MP capable LSRs [TE-NODE-CAP]. Well, strictly it uses the extensions to determine P2MP-capable LSRs and can then make assumptions that the other LSRs are either shy or not capable of P2MP function. == Section 16 para 7 The P2MP capable LSR that initiates the non-adjacent signaling message to the next P2MP capable LSR may have to employ a fast detection mechanism such as [BFD] [BFD-MPLS] to the next P2MP capable LSR. Please break this into the subsequent paragraph that contains the explanation. == Section 17 para 1 s/up P2MP LSP/up a P2MP LSP/ s/Infact/In fact/ == Section 17 para 2 s/P2P LSPs be dynamically setup/P2P LSPs can be dynamically set up/ == Section 17 para 2 Not sure that a reference to a figure in the Appendix is appropriate. I think Appendixes are normally non-normative. == Section 18 para 1 Strike it == Section 18 para 4 Normally, a P2MP LSP has a single incoming interface on which all of the Path messages associated with that P2MP LSP are received. Mustn't describe the interfaces in terms of how the Path messages are received (see the very next sentence!). Let's keep to the data plane to avoid the issue. Normally, a P2MP LSP has a single incoming interface on which all of the data for the P2MP LSP is received. == Section 18 para 5 Similarly, in both the re-merge case and cross-over cases, a node will receive a Path message for a given P2MP LSP on a different incoming interface, and the node needs to be able to distinguish between dynamic LSP re-routing and the re-merge/cross-over cases. Same issue... Similarly, in both the re-merge case and cross-over cases, a node will receive a Path message for a given P2MP LSP identifying a different incoming interface for the data, and the node needs to be able to distinguish between dynamic LSP re-routing and the re-merge/cross-over cases. == Section 18.1 para 2 s/SUB-LSP objects/S2L_SUB_LSP objects/ (three times) s/ set of SUB-LSPs/ set of S2L sub-LSPs/ == Section 18.1.1 para 2 s/objects included the/objects included in the/ == Section 18.1.1 para 3 s/followed for both/followed for all/ == Section 18.1.1 para 4 When configured to allow a re-merge case to persist, the re-merge node receives data associated with the P2MP LSP on multiple incoming interfaces, but it may only send the data from one of these interfaces to its outgoing interfaces, s/may/MUST/ == Section 18.1.1 paras 5, 6 and 7 s/SUB-LSP objects/S2L_SUB_LSP objects/ (six times) == Section 19.1.1 Extended Tunnel ID s/ingress-PID/ingress-P2MP ID/ == Section 19.2 para 1 s/ingress-LSR/ingress LSR/ s/LSP ID can be can be/LSP ID can be/ == Section 19.2 para 1 The instances can share resources with each other, but use different labels. Either strike ", but use different labels" or change to ", but may use different labels." == Section 19.2.1 and 19.2.2 This is a bit hairy, but... The Sub-Group Originator and the source do not necessarily come from the same IPv4/6 spaces. So you might need to add an IPv6 Sub-Group Originator to a Sender_Template that has an IPv4 sender address. I don't like the sound of this, because it creates four flavours instead of the two listed, and it doesn't seem very likely to occur in the field. What do we do? Leave it as it is and wait until someone encounters the issue? == Section 19.2.2 I think you can use the same short-form text as used in 19.1.2 and save some trees. == Section 19.3.1 and 19.3.2 s/SUB_LSP Class = 50/S2L_SUB_LSP Class = 50/ == Section 19.4.2 Title s/4/6/ == Section 20 The whole of this section needs to give IANA a better reference for where the new code points are to be allocated. This can be done by naming the registries (with the IANA pages). == Section 20.1 s/50 Class Name = SUB_LSP/50 Class Name = S2L_SUB_LSP == Section 20.2 s/P2MP LSP/P2MP_LSP/ (thrice) == Section 20.3 For reference I have tracked these values in the interim registry of Routing Problem error values at http://www.olddog.co.uk/ccamp.htm == Section 20.4 Referenced Section of this Doc: 10 s/10/5.2.4/ For reference I have tracked these values in the interim registry of LSP_ATTRIBUTE flags at http://www.olddog.co.uk/ccamp.htm == Section 21 Absolutely no way we will get away with a 3 line security section! The security ADs are positively mauling all I-Ds at the moment. There are a couple of things we can say: - more destinations for an LSP increases the risk - there is potential for a listener to get themselves added to a P2MP tree - there is description in the I-D about using tunnels to form remote adjacencies - DoS impact when one leaf is nobbled and the tree has LSP integrity applied Probably lots more. == Section 23 Usual to put the appendix later in the document == Section 23.1 point a) We assume that PE1 learns of the egress-LSRs at different points. "points in time" ? == Section 24.2 Suspect that some of the I-D versions listed have moved on == Section 25.2 Lou and Markus's coordinates have changed _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri May 19 12:53:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh88p-0000cz-Gu; Fri, 19 May 2006 12:47:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh88o-0000ct-6t for mpls@lists.ietf.org; Fri, 19 May 2006 12:47:54 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh88n-0003ou-Ot for mpls@lists.ietf.org; Fri, 19 May 2006 12:47:54 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1Fh88y-0008W6-00 for mpls@lists.ietf.org; Fri, 19 May 2006 17:48:04 +0100 Received: from your029b8cecfe ([217.158.132.191] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 17:47:46 +0100 Message-ID: <0b1401c67b63$ea1aee10$36849ed9@your029b8cecfe> From: "Adrian Farrel" To: "YongLucy 73674" , , References: <5e3a345e22d4.5e22d45e3a34@huawei.com> Subject: Re: [mpls] Signaling Requirement for P2MP Date: Fri, 19 May 2006 17:45:27 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 19 May 2006 16:47:47.0388 (UTC) FILETIME=[F549EFC0:01C67B63] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Lucy, > This (4461) is good and comprehensive document. It covers a lot of > information. > Since P2MP LSP is unidirectional paths with many end points, this brings a > lot > of specialties for the signaling and transmission. > > If this is only for unidirectional, should we specify if signaling > initiates from a > source point or a sink point, or both. What restriction applies. The requirements RFC deliberately does not specify an answer to this question because it does not tie the solution to any one existing signaling protocol. But you should note that draft-ietf-mpls-rsvp-te-p2mp-05.txt defines extensions to RSVP-TE which is a source-to-destination signaling procedure. That is, the signaling initiates from the source point. Mechanisms for the source point to discover the leaves are out of scope. And so (in particular) leaf-initiated-join is out of scope. > Failure discovery becomes an issue for unidirectional transmission, Failure is always an issue! You can see some "interesting" discussion of this in draft-ietf-mpls-p2mp-oam-reqs-01.txt > should signaling assists on the failure discovery? Potentially. But it is not always possible for signaling to discover failure, especially if the data and control channels are disjoint. It can, however, isolate them and report them. > Adding/removing a branch, should only allows sink point to > initiate the request or the transit point could do it so? The requirements have nothing to say about this, as described above. The current solution assumes that the ingress is responsible for all additions and can control removals. But just like in P2P, any LSR along the path (and particulalry the egress) can initiate a removal (but the ingress might try to add it back in again). > Any commont on these? Hope this helps. Regards, Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 24 11:40:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FivNz-00073O-Jd; Wed, 24 May 2006 11:34:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FivNx-00073I-Jm for mpls@ietf.org; Wed, 24 May 2006 11:34:57 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FivNw-00056n-7g for mpls@ietf.org; Wed, 24 May 2006 11:34:57 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k4OFYr1Z015836; Wed, 24 May 2006 08:34:53 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k4OFYq531939; Wed, 24 May 2006 08:34:52 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200605241534.k4OFYq531939@merlot.juniper.net> To: Loa Andersson In-Reply-To: Your message of "Sat, 13 May 2006 12:48:18 +0200." <4465B972.4090305@pi.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <38544.1148484892.1@juniper.net> Date: Wed, 24 May 2006 08:34:52 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: mpls@ietf.org, Bill Fenner , ccamp , Ross Callon Subject: [mpls] Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Loa and George, > Working Group, > > this initiates a two week working group last call on > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > please send comments to the MPLS working group mailling > list and/or working co-chairs. > > The last call ends eob May 28th. > > The ccamp mailing list copied as this is a work that has > an overlap between the working groups. > > Loa and George Few observations and suggestions... (a) tuple is both necessary and sufficient to unambiguously identify a P2MP Tunnel. (b) Further is both necessary and sufficient to identify a P2MP LSP. Therefore I would suggest that draft-ietf-mpls-rsvp-te-p2mp-05.txt should say the following: 1. A P2MP tunnel is identified by a tuple , where the index value is unique within the scope of the IP address of the root node. The P2MP tunnel identifier is unique within the same scope as the root node IP address. 2. Both the Extended Tunnel ID and the Tunnel Sender Address fields carry the root node IP address (both fields carry the same value). The index is carried in the P2MP ID. 3. Tunnel ID field should be set to all zeros, and be ignored on receipt. 4. A P2MP LSP is identified by a combination of tunnel identifier (), and LSP ID. With this in mind sections 4.1, 4.2, 19.1 and 19.2 should be modified to clarify the following: (a) SESSION identifier; (b) semantics of Extended Tunnel ID; semantics of the P2MP ID; (c) semantics of the Tunnel ID IP address in the SENDER_TEMPLATE. Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 24 12:40:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiwJa-00069O-Ru; Wed, 24 May 2006 12:34:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiwJZ-00069J-OR for mpls@ietf.org; Wed, 24 May 2006 12:34:29 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiwJY-0008OM-7w for mpls@ietf.org; Wed, 24 May 2006 12:34:29 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 24 May 2006 09:34:27 -0700 X-IronPort-AV: i="4.05,167,1146466800"; d="scan'208"; a="548966705:sNHT35375564" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 09:34:26 -0700 Date: Wed, 24 May 2006 09:34:26 -0700 (PDT) From: Rahul Aggarwal To: Yakov Rekhter In-Reply-To: <200605241534.k4OFYq531939@merlot.juniper.net> Message-ID: <20060524092915.D26008@sapphire.juniper.net> References: <200605241534.k4OFYq531939@merlot.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 24 May 2006 16:34:26.0459 (UTC) FILETIME=[EBF69EB0:01C67F4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: mpls@ietf.org, Bill Fenner , ccamp , Ross Callon Subject: [mpls] Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Yakov, Thanks for the comments. Please see below: On Wed, 24 May 2006, Yakov Rekhter wrote: > Loa and George, > > > Working Group, > > > > this initiates a two week working group last call on > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > please send comments to the MPLS working group mailling > > list and/or working co-chairs. > > > > The last call ends eob May 28th. > > > > The ccamp mailing list copied as this is a work that has > > an overlap between the working groups. > > > > Loa and George > > Few observations and suggestions... > > (a) tuple is both necessary and > sufficient to unambiguously identify a P2MP Tunnel. > > (b) Further is both > necessary and sufficient to identify a P2MP LSP. > Agreed. > Therefore I would suggest that draft-ietf-mpls-rsvp-te-p2mp-05.txt > should say the following: > > 1. A P2MP tunnel is identified by a tuple index>, where the index value is unique within the scope of the IP > address of the root node. The P2MP tunnel identifier IP address, index> is unique within the same scope as the root node > IP address. > Ok. > 2. Both the Extended Tunnel ID and the Tunnel Sender Address fields > carry the root node IP address (both fields carry the same value). > The index is carried in the P2MP ID. > Ok. > 3. Tunnel ID field should be set to all zeros, and be ignored on > receipt. > Ok. > 4. A P2MP LSP is identified by a combination of tunnel identifier > (), and LSP ID. > Ok. > With this in mind sections 4.1, 4.2, 19.1 and 19.2 should be modified > to clarify the following: > > (a) SESSION identifier; > (b) semantics of Extended Tunnel ID; semantics of the P2MP ID; > (c) semantics of the Tunnel ID IP address in the SENDER_TEMPLATE. > How about the following rephrasing: 1. Section 4.1: " A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is identified by a P2MP SESSION object. This object contains the identifier of the P2MP Session which includes the P2MP ID, a tunnel ID and an extended tunnel ID. The fields of a P2MP SESSION object are identical to those of the SESSION object defined in [RFC3209] except that the Tunnel Endpoint Address field is replaced by the P2MP Identifier (P2MP ID) field. The P2MP ID provides an identifier for the set of destinations of the P2MP TE Tunnel." to " A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is identified by a P2MP SESSION object. This object contains the identifier of the P2MP Session which includes a tuple , where the P2MP Identifier (P2MP ID) is unique within the scope of the IP address of the ingress LSR. The Ingress LSR IP address is encoded in the Extended Tunnel ID. Th P2MP Tunnel identifier, carried in the P2MP SESSION object, is unique within the same scope as the ingress LSR IP address. The fields of the P2MP SESSION object are identical to those of the SESSION object defined in [RFC3209] except that the Tunnel Endpoint Address field is replaced by the P2MP ID field." 2. Section 4.2. " A P2MP LSP is identified by the combination of the P2MP ID, Tunnel ID, and Extended Tunnel ID that are part of the P2MP SESSION object, and the tunnel sender address and LSP ID fields of the P2MP SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is defined in section 20.2." to " A P2MP LSP is identified by the combination of the P2MP ID, Extended Tunnel ID that are part of the P2MP SESSION object, and the tunnel sender address and LSP ID fields of the P2MP SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is defined in section 20.2." 3. 19.1.1 "P2MP ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. It encodes the P2MP ID and identifies the set of destinations of the P2MP Tunnel." to "P2MP ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. It encodes the P2MP Identifier that is unique within the scope of the Ingress LSR IP address carried in the Extended Tunnel ID. 4. 19.1.1 "Tunnel ID A 16-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel." to "Tunnel ID A 16-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. It SHOULD be set to 0 by the ingress LSR and be ignored on receipt." 5. "Extended Tunnel ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-PID pair may place their IPv4 address here as a globally unique identifier [RFC3209]." to "Extended Tunnel ID A 32-bit identifier used in the SESSION object that remains constant over the life of the P2MP tunnel. This identifier MUST be set to the ingress LSR's IPv4 address." 6. 19.1.2 "This is same as the P2MP IPv4 LSP SESSION Object with the difference that the extended tunnel ID may be set to a 16 byte identifier [RFC3209]." to "This is same as the P2MP IPv4 LSP SESSION Object with the difference that the extended tunnel ID MUST be set to a 16 byte identifier that is the ingress LSR's IPv6 address." 7. 19.2.1 " IPv4 tunnel sender address See [RFC3209]" to" "IPv4 tunnel sender address. This address MUST be the same as the address in the Extended Tunnel ID field of the SESSION object." 8. 19.2.2 "IPv6 tunnel sender address See [RFC3209]" to "IPv6 tunnel sender address. This address MUST be the same as the address in the Extended Tunnel ID field of the SESSION object." Thanks, rahul > Yakov. > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 24 16:36:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj02K-00054r-26; Wed, 24 May 2006 16:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj02I-00054h-MT; Wed, 24 May 2006 16:32:54 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fizt9-0005YV-32; Wed, 24 May 2006 16:23:27 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FizNl-0006Ev-UH; Wed, 24 May 2006 15:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k4OJo167012887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FizMn-0004Lv-I4; Wed, 24 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 24 May 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-number-0-bw-te-lsps-01.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org --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 : A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switch Paths signalled across a link Author(s) : J. Vasseur, et al. Filename : draft-ietf-mpls-number-0-bw-te-lsps-01.txt Pages : 8 Date : 2006-5-24 Several Link-type sub-TLVs have been defined for OSPF and ISIS in the context of MPLS Traffic Engineering in order to convery some link characteristics such as the available bandwidth, traffic enginering metric, adminstrative group and so on. There are various circumstances where it would be useful to also advertise the number of unconstrained Traffic Engineering Label Switched Path(s) (TE LSP) signalled across a link. This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSP(s) signalled across a link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-number-0-bw-te-lsps-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-24112441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-number-0-bw-te-lsps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-24112441.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@lists.ietf.org Wed May 24 17:01:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0RF-0004pR-6h; Wed, 24 May 2006 16:58:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0RE-0004pL-B1 for mpls@ietf.org; Wed, 24 May 2006 16:58:40 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj0RC-0008TR-PS for mpls@ietf.org; Wed, 24 May 2006 16:58:40 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1Fj0Qt-0002WX-00 for mpls@ietf.org; Wed, 24 May 2006 21:58:19 +0100 Received: from your029b8cecfe ([217.158.132.122] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 21:58:22 +0100 Message-ID: <034501c67f74$c42e2450$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Loa Andersson" , "Yakov Rekhter" References: <200605241534.k4OFYq531939@merlot.juniper.net> Date: Wed, 24 May 2006 18:47:19 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 24 May 2006 20:58:22.0621 (UTC) FILETIME=[CB0D2CD0:01C67F74] X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: mpls@ietf.org, Bill Fenner , ccamp , Ross Callon Subject: [mpls] Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Yakov, > Few observations and suggestions... > > (a) tuple is both necessary and > sufficient to unambiguously identify a P2MP Tunnel. > > (b) Further is both > necessary and sufficient to identify a P2MP LSP. Clearly these two statements depend on the definition of "P2MP ID" as you pointed out below. As the I-D says... The P2MP ID provides an identifier for the set of destinations of the P2MP TE Tunnel. And this means that there is not a one-to-one relationship between P2MP ID and P2MP Tunnel even within the scope of a single ingress. Although this was debated (the ingress could uniquely assign one ID per tunnel) we recognized: i. The Tunnel ID field already performs this function ii. It may be desirable to identify common sets of destinations The best example of ii. that was discussed would allow you to place a multicast IP address in the P2MP ID field. This is not mandatory (and some people think it is a bad idea :-), but the specification was designed to allow it. If an implementation chose to set P2MP ID = Tunnel ID, I guess that would be very fine with everyone. > Therefore I would suggest that draft-ietf-mpls-rsvp-te-p2mp-05.txt > should say the following: > > 1. A P2MP tunnel is identified by a tuple index>, where the index value is unique within the scope of the IP > address of the root node. The P2MP tunnel identifier IP address, index> is unique within the same scope as the root node > IP address. > > 2. Both the Extended Tunnel ID and the Tunnel Sender Address fields > carry the root node IP address (both fields carry the same value). > The index is carried in the P2MP ID. I don't believe we should force the Extended Tunnel ID like this when an existing RFC defines another use albeit in the P2P context. > 3. Tunnel ID field should be set to all zeros, and be ignored on > receipt. > > 4. A P2MP LSP is identified by a combination of tunnel identifier > (), and LSP ID. > > With this in mind sections 4.1, 4.2, 19.1 and 19.2 should be modified > to clarify the following: > > (a) SESSION identifier; > (b) semantics of Extended Tunnel ID; semantics of the P2MP ID; > (c) semantics of the Tunnel ID IP address in the SENDER_TEMPLATE. Cheers, Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 24 17:33:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0tz-0007o6-Q4; Wed, 24 May 2006 17:28:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj0ty-0007nY-6L for mpls@ietf.org; Wed, 24 May 2006 17:28:22 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj0tw-00020q-PM for mpls@ietf.org; Wed, 24 May 2006 17:28:22 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k4OLSHX09285; Wed, 24 May 2006 14:28:17 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k4OLSB506950; Wed, 24 May 2006 14:28:11 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200605242128.k4OLSB506950@merlot.juniper.net> To: "Adrian Farrel" In-Reply-To: Your message of "Wed, 24 May 2006 18:47:19 BST." <034501c67f74$c42e2450$0a23fea9@your029b8cecfe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83398.1148506091.1@juniper.net> Date: Wed, 24 May 2006 14:28:11 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: mpls@ietf.org, Bill Fenner , ccamp , Ross Callon Subject: [mpls] Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Adrian, > > Few observations and suggestions... > > > > (a) tuple is both necessary and > > sufficient to unambiguously identify a P2MP Tunnel. > > > > (b) Further is both > > necessary and sufficient to identify a P2MP LSP. > > Clearly these two statements depend on the definition of "P2MP ID" as you > pointed out below. > > As the I-D says... > The P2MP ID provides an identifier for the set of destinations of the > P2MP TE Tunnel. Does this identifier have a globally unique scope, or only the scope of the root ? If the former, then what are the procedures for assigning such identifiers ? > And this means that there is not a one-to-one relationship between P2MP ID > and P2MP Tunnel even within the scope of a single ingress. > > Although this was debated (the ingress could uniquely assign one ID per > tunnel) we recognized: > > i. The Tunnel ID field already performs this function > ii. It may be desirable to identify common sets of destinations > > The best example of ii. that was discussed would allow you to place a > multicast IP address in the P2MP ID field. This is not mandatory (and some > people think it is a bad idea :-), but the specification was designed to > allow it. > > If an implementation chose to set P2MP ID = Tunnel ID, I guess that would be > very fine with everyone. For one thing, this would limit the number of tunnels that could be originated by a particular root node to 2^16. It would also rule out the ability to place a multicast IP address in the P2MP ID field. > > Therefore I would suggest that draft-ietf-mpls-rsvp-te-p2mp-05.txt > > should say the following: > > > > 1. A P2MP tunnel is identified by a tuple > index>, where the index value is unique within the scope of the IP > > address of the root node. The P2MP tunnel identifier > IP address, index> is unique within the same scope as the root node > > IP address. > > > > 2. Both the Extended Tunnel ID and the Tunnel Sender Address fields > > carry the root node IP address (both fields carry the same value). > > The index is carried in the P2MP ID. > > I don't believe we should force the Extended Tunnel ID like this when an > existing RFC defines another use albeit in the P2P context. What are exactly the (practical) problems with carrying the root node IP address both in the Extended Tunnel ID and in the Tunnel Sender Address fields ? Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 24 18:43:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj20t-0000ej-1b; Wed, 24 May 2006 18:39:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiwLZ-0006xf-Ti for mpls@ietf.org; Wed, 24 May 2006 12:36:33 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiwLY-00009s-BU for mpls@ietf.org; Wed, 24 May 2006 12:36:33 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by borg.juniper.net with ESMTP; 24 May 2006 09:36:32 -0700 X-IronPort-AV: i="4.05,167,1146466800"; d="scan'208"; a="553230500:sNHT76972916" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 09:36:31 -0700 Date: Wed, 24 May 2006 09:36:31 -0700 (PDT) From: Rahul Aggarwal To: Adrian Farrel Subject: Re: [mpls] Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt In-Reply-To: <09fc01c67b4a$8cea27b0$36849ed9@your029b8cecfe> Message-ID: <20060524093534.B26008@sapphire.juniper.net> References: <4465B972.4090305@pi.se> <09fc01c67b4a$8cea27b0$36849ed9@your029b8cecfe> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 24 May 2006 16:36:31.0318 (UTC) FILETIME=[36629760:01C67F50] X-Spam-Score: 0.0 (/) X-Scan-Signature: 33fc46667f70a87403df4cb21ee8343c X-Mailman-Approved-At: Wed, 24 May 2006 18:39:33 -0400 Cc: mpls@ietf.org X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Adrian, Thanks for the detailed comments. I am still looking at all your comments and will respond in a few days.. rahul On Fri, 19 May 2006, Adrian Farrel wrote: > Hi, > > Thanks to the editors. Good job. > > Here are some comments... > > Adrian > > == > Title > Here you say "Point to Multipoint", but in the rest of the document it is > hyphenated. > == > Abstract > s/setup/set up/ > (setup is a noun not a verb) > == > Abstract > Looks like you want a paragraph break before... > "There can be various applications..." > == > Section 3. > Acronyms must be spelt out the first time they are encountered. > The Abstract (regrettably) is stand-alone and doesn't count, so the > Introduction has to do it all again :-( > Anyway, P2P and S2L are new. > == > Section 3 para 3 > One Path message may signal one > or multiple S2L sub-LSPs. Hence the S2L sub-LSPs belonging to a P2MP > LSP can be signaled using one Path message or split across multiple > Path messages. > The conjunction of these two sentences implies that a single Path message > may also contain the S2L sub-LSPs from different P2MP LSPs. I don't believe > this is the case, and we should correct this text accordingly. For example: > One Path message may signal one or multiple S2L sub-LSPs > for a single P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP > LSP can be signaled using one Path message or split across multiple > Path messages. > == > Section 3 para 4 > s/application specific/application-specific/ > == > Section 4 para 1 > A branch node is an LSR that is capable of replicating the > incoming data on two or more outgoing interfaces. > Technically, it only replicates it on one or more outgoing interfaces, > because the first interface is not a replication. > == > Section 4.1 para 1 > The specific aspect related to a P2MP TE LSP is the action required > at a branch node, where data replication occurs. Incoming MPLS > labeled data is appropriately replicated to several outgoing > interfaces which may have different labels. > Not sure if this is trying to say something more, or is just poorly worded. > How about... > The defining feature of a P2MP TE LSP is the action required > at branch nodes where data replication occurs. Incoming MPLS > labeled data is appropriately replicated to several outgoing > interfaces which may use different labels for the data. > == > Section 4.1 para 2 > A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is > identified by a P2MP SESSION object. This object contains the > identifier of the P2MP Session which includes the P2MP ID, a tunnel > ID and an extended tunnel ID. > Need to turn this paragraph around a bit. > A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is > identified the P2MP ID, a tunnel ID, and an extended tunnel ID. These > objects > are carried in RSVP-TE in a P2MP SESSION object. > == > Section 4.1 para 3 > The fields of a P2MP SESSION object are identical to those of the > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > Address field is replaced by the P2MP Identifier (P2MP ID) field. > The comparison is not quite so simple in the IPv6 case because the 16 byte > IPv6 tunnel endpoint address is replaced by a 4 byte P2MP ID. We should > bring this out in this paragraph as follows. > The fields of a P2MP SESSION object are identical to those of the > SESSION object defined in [RFC3209] except that the Tunnel Endpoint > Address field (IPv4 or IPv6) is replaced by the 4-byte P2MP Identifier > (P2MP ID) field. > == > Section 4.1 > Add a forwards reference at the end of the section as follows. > The new P2MP SESSION object is defined in section 19.1. > == > Section 4.2 > s/20.2/19.2/ > == > Section 4.3 para 3 > s/subgroup/sub-group/ > Please do global search and replace in the document > == > Section 4.3 para 3 > s/an egress and semantic/an egress, and semantic/ > == > Section 4.4.1 para 1 > s/20.3/19.3/ > == > Section 4.4.1 para 2 > s/20.5/19.5/ > s/20.6/19.6 > == > Section 4.4.1 and onwards > The S2L_SUB_LSP object is consistently referred to in angle brackets, but no > other object is given this treatment. Please remove the brackets everywhere > except in BNF. > == > Section 4.4.1 > It seems to me that the S2L_SUB_LSP object contains a leaf identifier and an > SERO. > The SERO provides the path from the last branch to the leaf. > This means that it is not an S2L_SUB_LSP object at all, but really a > S2L_SUB_LSP object. But that sounds clumsy. > Can we call this a LEAF object? > We would also rename the descriptor lists in section 5.1, 6.1, 7.1, and > 11.1. > We could change the names of the IPv4/IPv6 S2L Sub-LSP destination address, > but that isn't necessary. > == > Section 4.4.2 para 1 > s/setup/set up/ > == > Section 4.5 para 1 > When a Path message signals a single S2L sub-LSP (that is, the Path > message is only targeting a single leaf in the P2MP tree), the > EXPLICIT_ROUTE object encodes the path from the ingress LSR to the > egress LSR. > Strike the words "from the ingress LSR" as this situation may also occur > within the network (for example, downstream of a branch node, or just > anywhere if the original Path message only included one S2L sub-LSP). > == > Section 4.5 para 2 > When a Path message signals multiple S2L sub-LSPs the path of the > first S2L sub-LSP, from the ingress LSR to the egress LSR, is encoded > in the ERO. > As above, strike "from the ingress LSR" > == > Section 4.5 para 3 > s/(as defined in [RFC3209])/(as defined in [RFC3209] and [RFC3473])/ > == > Section 4.5 para 3 > Each subsequent S2L sub-LSP > is represented by tuples of the form < [ SECONDARY_EXPLICIT_ROUTE>] >. > Should read... > Each subsequent S2L sub-LSP > is represented by tuples of the form < , > [] >. > ...since this is the order used in the encoding. > == > Section 4.5 para 3 > An SERO for a particular > S2L sub-LSP includes only the path from a certain branch LSR to the > egress LSR if the path to that branch LSR can be derived from the ERO > or other SEROs. > Strike "certain" as this applies to any branch LSR in any network. > == > Section 4.5 para 3 > s/20/19/ > == > Section 4.5 para 6 > s/Following/The following/ > Also near the top of page 10. > == > Section 4.5 > s/exercise to the reader./exercise for the reader./ > == > Section 4.5 page 10 > s/A LSR/An LSR/ > s/a S2L/an S2L/ > s/a SERO/an SERO/ > Probably worth checking the whole document. > == > Section 5.1 > layout of is messed up > == > Section 5.1 > A SERO corresponds to the following > object. > s/A/An/ > Oh no it doesn't! Say... > An SERO corresponds to the preceding > object. > == > Section 5.1 > The RRO in the sender descriptor contains the hops traversed by the > Path message and applies to all the S2L sub-LSPs signaled in the Path > message. > That is rather an MPLS-centric view of the world. Better to say... > The RRO in the sender descriptor contains the upstream hops traversed > by the LSP up to this point and applies to all the S2L sub-LSPs signaled > in the Path message. > == > Section 5.2 para 1 > s/ingress-LSR/ingress LSR/ > s/egress-LSR/egress LSR/ > s/that is the destination/that is a destination/ > == > Section 5.2 para 1 > Another S2L sub-LSP belonging to the same instance of this > S2L sub-LSP (i.e. the same P2MP LSP) shares resources with this S2L > sub-LSP. > In previous versions of the draft we had "can share" in place of "shares", > and this was with good reason. It is perfectly acceptable for replication to > take place at an upstream node and for two copies of the data to flow on the > same link before being fanned out down stream. This might happen in an > optical network where the split node is not capable of the appropriate > lambda conversions, but might also happen in a packet network where the > downstream node cannot perform sufficient replication in a timely manner (or > at all) and so some of the replication must be done upstream regardless of > the 'waste' of resources in the network. > Since we are in 2119-land (these are protocol procedures) please replace > "shares" with "MAY share". > However (!) note that in 5.2.1 para 4 we have "SHOULD". > I can accept "SHOULD" in this paragraph, too. > == > Section 5.2 para 1 > s/identified using the object/identified using the > objects/ > == > Section 5.2 para 2 > s/20/19/ > == > Section 5.2.1 para 1 > You have changed your notation for tuples > == > Section 5.2.1 para 3 > An ingress LSR may use multiple Path messages for signaling a P2MP > LSP. > s/may/MAY/ > == > Section 5.2.1 para 3 > This implies that each Path message that is used > to signal a P2MP LSP is signaled using the same signaling attributes > with the exception of the S2L sub-LSP information and Sub-Group > identifiers. > s/information/descriptor/ > s/identifiers/identifier/ > == > Section 5.2.1 para 5 > In this case the message can be decomposed > into multiple Path messages such that each of the messages carry a > subset of the X2L sub-tree carried by the incoming message. > s/carry/carries/ > == > Section 5.2.1 para 6 > In order > to disambiguate these Path messages a Group ID> tuple is introduced (also referred to as the Sub-Group > field) and encoded in the SENDER_TEMPLATE object. > s/field/fields/ > == > Section 5.2.1 para 6 > This is either the ingress > LSR or a LSR which re-originates the Path message with its own Sub- > Group Originator ID. > This sentence doesn't add anything. Strike it. > == > Section 5.2.1 para 6 > The tuple is globally unique. > I'm not sure what this means. > The same LSR can use the same sub-Group ID on different LSPs since the LSPs > are distinguished by session/sender template. > Further, there is some conflict with the sentences immediately afterwards... > The sub-Group ID space is specific to the Sub-Group Originator ID. > Therefore the combination is > network-wide unique. > Since no conclusion appears to be drawn from this uniqueness, I would say > that the sub-Group ID is unique within the context of a P2MP LSP and that > the sub-Group Originator ID is network-wide unique. > == > Section 5.2.1 para 6 > Also, a router that changes the Sub-Group > originator ID of an incoming Path message MUST use the same value of > the Sub-Group Originator ID for all outgoing Path messages, for a > particular P2MP LSP, and SHOULD not vary it during the life of the > P2MP LSP. > This may be confusing in the light of the fact (a few lines earlier) that... > The Sub-Group Originator ID MUST be set to the TE Router ID of > the LSR that originates the Path message. > Certainly the "MUST"s are complementary, but what is with the "SHOULD"? > == > Section 5.2.2 para 1 > The S2L sub-LSP descriptor list allows the signaling of one or more > S2L sub-LSPs in one Path message. It is possible to signal multiple > object and ERO/SERO combinations in a single Path > message. Note that these two objects differentiate a S2L sub-LSP. > The first two sentence are largely duplicates. > The third sentence says two objects, three have been mentioned. > How about... > The S2L sub-LSP descriptor list allows the signaling of one or more > S2L sub-LSPs in one Path message. Each S2L sub-LSP descriptor > describes a single S2L sub-LSP. > == > Section 5.2.2 3rd bullet > - If the first hop of the SERO is not a local address of the LSR > the S2L sub-LSP descriptor MUST be included in the Path message > sent to LSR that is the next hop to reach the first hop in the > SERO. This next hop is determined by using the ERO or other > SEROs that encode the path to the SERO's first hop. > s/sent to LSR/sent to the LSR/ > == > Section 5.2.2 > Hence a branch LSR MUST only propagate the relevant S2L sub-LSP > descriptors on each downstream link. A S2L sub-LSP descriptor list > that is propagated on a downstream link MUST only contain those S2L > sub-LSPs that are routed using that link. This processing MAY result > in a subsequent S2L sub-LSP in an incoming Path message to become the > first S2L sub-LSP in an outgoing Path message. > I'm not sure if this is what I wrote, but anyway, it is wrong! > Path messages are not propagated on downstream links, but are sent to the > next hop towards the egress. This finesse of words is important when > out-of-channel signaling is considered. So reword as follows... > Hence a branch LSR MUST only propagate the relevant S2L sub-LSP > descriptors to each next downstream hop. An S2L sub-LSP descriptor list > that is propagated to a downstream hop MUST only contain those S2L > sub-LSPs that are routed using that hop. This processing MAY result > in a subsequent S2L sub-LSP in an incoming Path message to become the > first S2L sub-LSP in an outgoing Path message. > == > Section 5.2.2 > Note that if one or more SEROs contain loose hops, expansion of such > loose hops MAY result in overflowing the Path message size. Section > 5.2.3 describes how signaling of the set of S2L sub-LSPs can be split > in more than one Path message. > s/split in more/split across more/ > == > Section 5.2.2 > The RECORD_ROUTE Object (RRO) contains the hops traversed by the Path > message and applies to all the S2L sub-LSPs signaled in the Path > message. A transit LSR MUST append its address in an incoming RRO and > propagate it downstream. A branch LSR MUST form a new RRO for each of > the outgoing Path messages by copying the RRO from the incoming Path > message and appending its address. Each such updated RRO MUST be > formed using the rules in [RFC3209]. > s/in [RFC3209]./in [RFC3209] updated by [RFC3473] as appropriate./ > == > Section 5.2.2 > If a LSR is unable to support a S2L sub-LSP in a Path message, a > PathErr message MUST be sent for the impacted S2L sub-LSP, and normal > processing of the rest of the P2MP LSP SHOULD continue. > Suggest the addition of an example... > If a LSR is unable to support a S2L sub-LSP in a Path message (for > example, it is unable to route towards the destination using the SERO), a > PathErr message MUST be sent for the impacted S2L sub-LSP, and normal > processing of the rest of the P2MP LSP SHOULD continue. > == > Section 5.2.2 > s/section 12./sections 5.2.4 and 11./ > == > Section 5.2.3 Title > The title of this section is ambiguous. Does the transit get fragmented? > Suggest > 5.2.3. Transit Fragmentation of Path State Information > == > Section 5.2.3 > It is desirable not to rely on IP > fragmentation in this case. > This bald statement needs qualification and should not be left as an > exercise for the reader. > Presumably the reason is that IP fragmentation of RSVP messages is > explicitly disallowed in section 3.3 of RFC2205. In which case "desirable" > does not come into it, and this is a stronger requirement. > However, in practice, IP fragment loss and the consequent message loss, is > no different from IP packet loss and the consequent message loss. Or is it? > == > Section 5.2.3 para 2 > When multiple Path messages are used by an ingress or transit node, > each Path message SHOULD be identical with the exception of the S2L > sub-LSP related information (e.g., SERO), > s/related information/descriptor/ > == > Section 5.2.3 para 3 > As described above one case in which the Sub-Group Originator ID of a > received Path message is changed is that of transit fragmentation. > s/transit fragmentation/fragmentation of the Path message at a transit node/ > == > Section 6.1 > The format of the definition has been messed up > == > Section 6.1 > I don't think we should use the same name for the list> as is used for the Path message as it leads to exactly the same > confusion and error as we have here. Viz. > ::= [ SECONDARY_EXPLICIT_ROUTE> ] > Should read... > ::= [ SECONDARY_RECORD_ROUTE> ] > (and obviously the format needs to be sorted out) > So I suggest changing the name to be different from that used in a Path > message as the descriptor is a different entity. > == > Section 6.1 final para > However different upstream labels are allocated if the Address, LSP-ID> of the FILTER_SPEC object is different as that > implies different P2MP LSP. > s/are/MUST be/ > == > Section 6.2 para 1 > The egress LSR MUST follow normal RSVP procedures while originating a > Resv message. The Resv message carries the label allocated by the > egress LSR. > Is this the case, or does the Resv message from the egress contain an > S2L_SUB_LSP object? > If it is the case that the S2L_SUB_LSP MUST be included then please say so > in this paragraph. > If this paragraph is correct as it stands, please add a note to say that the > S2L_SUB_LSP object MUST NOT be included. > == > Section 6.2 > Each branch node can potentially send one Resv message upstream for > each of the downstream receivers. This MAY result in overflowing the > Resv message, particularly when considering that the number of > messages increases the closer the branch node is to the ingress of > the P2MP LSP. > As currently written, this says that one Resv message is sent for each > downstream receiver (i.e. n messages when there are n receivers). I don't > think you means this because the next sentence talks about overflowing which > would not arise in this case. > > At the same time, the increase in the number of messages closer to the > ingress is not relevant, it is the increase in the number of receivers. > > If you are *also* trying to talk about the potential of a single message per > receiver and the impact of the consequent number of messages as you get > closer to the ingress, with the implied desirability of combining messages > into a single Resv, then this needs to be said separately. > > So... > Each branch node MAY forward a single Resv message upstream for > each received Resv from a downstream receiver. Note that there may be > a large number of Resv messages at and close to the ingress LSR for an > LSP with many receivers. To avoid issues of congestion, a branch LSR > SHOULD combine Resv state from multiple receivers into a single Resv > message to be sent upstream (see section 6.2.1), but note that this may > result in overflowing the Resv message particularly as the number of > receivers downstream of any branch LSR increases as the LSR is closer > to the ingress LSR. Thus, a branch LSR MAY choose to send more than > one Resv message upstream and partition the Resv state between the > messages. > == > Section 6.2 final paragraph > Transit nodes MUST replace the Sub-Group ID fields received in the > FILTER_SPEC objects with the value that was received in the Sub-Group > ID field of the Path message from the upstream neighbor, when the > node set the Sub-Group Originator field in the associated Path > message. ResvErr messages generation is unmodified. Nodes > propagating a received ResvErr message MUST use the Sub-Group field > values carried in the corresponding Resv message. > Split the ResvErr text into a second paragraph > == > Section 6.2.1 para 1 > A branch node may have to send the Resv message being sent upstream > whenever there is a change in a Resv message for a S2L sub-LSP > received from one of the downstream neighbors. > Some problems with tense. Try... > A branch node may have to send a revised Resv message upstream > whenever there is a change in a Resv message received from one of > its downstream neighbors for a S2L sub-LSP. > == > Section 6.2.1 para 1 > s/upstream,particularly/upstream, particularly/ > == > Section 6.2.1 para 1 > s/established for the first time./first established/ > == > Section 6.2.1 recommends the use of a timer. IETF protocol specification > rules require that we suggest a value for all protocol timers. Please > suggest a value here - it could be a function of some other timer, a > function of the number of downstream destinations, or just a raw number. > == > Section 6.3 Title > "Record Routing" doesn't do it for me! What "Route Recording"? > == > Section 6.3.1 para 1 > A Resv message contains a record route per S2L sub-LSP that is being > signaled by the Resv message if the sender node requests route > recording by including a RRO in the Path message. The same rule is > used during signaling of P2MP LSP i.e. insertion of the RRO in the > Path message used to signal one or more S2L sub-LSP triggers the > inclusion of an RRO for each sub-LSP. > Say either "recorded route" or "route record". > I think this paragraph is trying to contract P2P (first sentence) with P2MP > (subsequent sentence), but actually describes P2MP in both with the result > that "The same rule is used..." is confusing. How about... > A Resv message for a P2P LSP contains a recorded route if the > ingress LSR requested route recording by including an RRO in > the original Path message. The same rule is used during signaling > of P2MP LSPs. That is, inclusion of an RRO in the Path message > used to signal one or more S2L sub-LSPs triggers the inclusion > of a recorded route for each sub-LSP in the Resv. > == > Section 6.3.1 para 2 > The record route of the first S2L sub-LSP is encoded in the RRO. > s/record route/recorded route/ > == > Section 6.3.1 para 2 > Additional RROs for the subsequent S2L sub-LSPs are referred to as > P2MP_SECONDARY_RECORD_ROUTE objects (SRROs). > s/RROs/recorded routes/ > s/referred to as/encoded in/ > == > Section 6.3.1 para 2 > s/20.5/19.5/ > == > Section 6.3.1 para 2 > The ingress node then receives the RRO and > possibly the SRRO corresponding to each subsequent S2L sub-LSP. Each > object is followed by the RRO/SRRO. The ingress node > can then determine the record route corresponding to a particular S2L > sub-LSP. The RRO and SRROs can be used to construct the end to end > Path for each S2L sub-LSP. > First sentence is duplicated later and should be removed as confusing. But > the text is wrong anyway. Rewrite as... > Each S2L_SUB_LSP object in a Resv is associated with an RRO or > SRRO. The first S2L_SUB_LSP object (for the first S2L sub-LSP) is > associated with the RRO. Subsequent S2L_SUB_LSP objects (for > subsequent S2L sub-LSPs) are each followed by an SRRO that > contains the recorded route for that S2L sub-LSP from the leaf up to > a branch. The ingress node can then determine use the RRO and > SRROs to determine the end-to-end path for each S2L sub-LSP. > == > Section 6.4 para 1 > s/can either be FF or SE./can be either FF or SE./ > == > Section 6.4 para 1 > The S2L sub-LSPs that belong > to different P2MP LSP MUST NOT share labels. If the reservation style > is FF then S2L sub-LSPs that belong to different P2MP LSP MUST NOT > share resources. If the reservation style is SE than S2L sub-LSPs > that belong to different P2MP LSP and the same P2MP Tunnel SHOULD > share resources where they share hops, but MUST not share labels. > s/different P2MP LSP/different P2MP LSPs/ (thrice) > s/than/then/ > This text gives GMPLS a problem because SE sharing of resources in > non-packet networks requires sharing of labels (and this is how > make-before-break is usually performed in resource-constrained non-packet > environments). I would suggest that the first sentence is superfluous as it > is covered by either FF or SE. Can we rewrite as... > If the reservation style is FF then S2L sub-LSPs that belong to > different P2MP LSPs MUST NOT share resources or labels. If the > reservation style is SE then S2L sub-LSPs that belong to different > P2MP LSPs and the same P2MP Tunnel SHOULD share resources > where they share hops, but MUST not share labels in packet > environments. > == > Section 7.2.2 para 2 > A transit LSR that propagates the PathTear message downstream MUST > ensure that it sets the tuple > in the PathTear message to the values used to generate the previous > Path message that corresponds to the S2L sub-LSPs being deleted by it > in the PathTear message. > This is a bit clumsy. How about... > A transit LSR that propagates the PathTear message downstream MUST > ensure that it sets the tuple > in the PathTear message to the values used in the Path message used to > set up the S2L sub-LSPs being torn down. > == > Section 8.1 para 1 > s/and Notify messages/and Notify message/ > s/Both object and messages/Both object and message/ > == > Section 8.1 point 2. para 1 > s/to the value, that was/to the value that was/ > == > Section 8.1 point 2. para 1 > If the incoming Resv message carries a > Notify Request object then the LSR MUST set the Notify node address > in the Notify Request object to the value, that was received in the > corresponding Path message, in the Resv message that it sends > upstream. > Too many sub-clauses. Try... > If the incoming Resv message carries a > Notify Request object then the LSR MUST set the Notify node address > in the Notify Request object in the Resv message that it sends > upstream to the value that was received in the corresponding Path > message, > == > Section 8.1 > Missing final period. > == > Section 8.2 para 2 > s/to the value, that was/to the value that was/ > == > Section 8.2 para 2 > s/carry/carries/ > == > Section 8.2 final para > All downstream branches that do > requested ResvConf messages MUST be sent such a message. > s/that do/that/ > == > Section 9 > s/LSP/LSPs/ (twice) > == > Section 10 para 1 > Not sure what this is trying to say by "managed". Perhaps "indexed" or > "identified" or "located"? > == > section 10 para 2 > s/object/objects/ > == > Section 10.1 para 3 > s/4.2/5.2/ > == > Section 10 > Suddenly the definition of TE Router ID is given a reference to [RFC3477] > which wasn't present in earlier uses of the term (section 5.2.1, 5.2.3). > Firstly, we need to be consistent, but more important (to me) is that 3477 > does NOT define TE Router ID: it defines Router ID. > You are faced, therefore with: > - drop the reference > - define the term yourself > - find another reference. > The best other reference I can find is > draft-ietf-ccamp-gmpls-addressing-03.txt > == > Section 11 > s/requests the maintenance of the 'LSP integrity'/requests the maintenance > of 'LSP integrity'/ > == > Section 11 > Therefore, reception of an > error message for a particular S2L sub-LSP MAY change the state of > any other S2L sub- LSP of the same P2MP TE LSP. > I think this is a lowercase "may". There is no element of choice for an > implementation here. > == > Section 11.1 > Need a reference to the definition of in > section 5.1 > == > Section 11.2 > Would benefit from a reference to the revised defined > in section 6.1 > == > Section 11.2 > Note the receiver of a > ResvErr message is able to identify the errored outgoing Path > message, and outgoing interface, based on the Sub-Group fields > received in the ResvErr message. > This should either say "*incoming* Path" or "outgoing *Resv*" > == > Section 11.3 > A branch LSR that receives a PathErr message with the > Path_State_Removed flag clear MUST act according to the wishes of the > ingress LSR. The default behavior is that the branch LSR forwards the > PathErr upstream and takes no further action. However, if the LSP > integrity flag is set on the Path message, the branch LSR MUST send > PathTear on all downstream branches and send the PathErr upstream > with the Path_State_Removed flag set (per [RFC3473]). > This only applied during LSP setup. That is, the LSP integrity flag does not > impact on any LSP state once the LSP has been set up and if the PathErr does > not have the Path_State_Removed flag set. (Compare with the first paragraph > of this section.) So this paragraph should read... > A branch LSR that receives a PathErr message during LSP setup with the > Path_State_Removed flag clear MUST act according to the wishes of the > ingress LSR. The default behavior is that the branch LSR forwards the > PathErr upstream and takes no further action. However, if the LSP > integrity flag is set on the Path message, the branch LSR MUST send > PathTear on all downstream branches and send the PathErr upstream > with the Path_State_Removed flag set (per [RFC3473]). > == > Section 14.2 para 1 > s/the incremental/incremental/ > == > Section 15 > Please change > [RFC4090] extensions can be used to perform fast reroute for the > mechanism described in this document. > to > [RFC4090] extensions can be used to perform fast reroute for the > mechanism described in this document when applied within packet > networks. > == > Section 15.1 .1 > This text is particularly dense and would benefit from re-writing and > paragraph breaks. > Some non-exhaustive comments follow. > == > Section 15.1.1 > The two uses of "MUST" seem to be overkill. > RFC 4090 only uses "SHOULD" for P2P LSPs. > == > Section 15.1.1 > Note that all such S2L sub-LSPs belonging to a particular instance of > a P2MP tunnel will share the same outgoing label on the link between > the PLR and the next-hop. > This is only a "SHOULD share labels" in section 5.2.1. > Not a big deal. Just delete this and the subsequent sentence. > == > Section 15.1.1 > Paragraph break before > During failure Path messages for each S2L sub-LSP, that are > effected, MUST be sent to the MP, by the PLR. > which should be rewritten as > During failure, Path messages for each S2L sub-LSP that is > affected MUST be sent to the MP by the PLR. > == > Section 15.1.1 > s/It is recommended that/It is RECOMMENDED that/ > == > Section 15.1.1 > s/the PLR use/the PLR uses/ > == > Section 15.1.1 > s/sender template specific/sender template-specific/ > == > Section 15.1.1 > Paragraph break before > The MP MUST use > == > Section 15.1.1 > Change > The MP MUST use the LSP-ID to > identify the corresponding S2L sub-LSPs. The MP MUST not use the > while identifying the > corresponding S2L sub-LSPs. In order to further process a S2L sub-LSP > the MP MUST determine the protected S2L sub-LSP using the LSP-id and > the object. > to > The MP MUST use the LSP-ID and the object to > identify the corresponding S2L sub-LSPs. The MP MUST not use the > to identify the > corresponding S2L sub-LSPs because the sub-group > originator ID might be changed by some LSR that is bypassed > by the bypass tunnel. > == > Section 15.1.1 > Please add the following. > Note that these procedures may require that the PLR replicate > data for a P2MP LSP into more than one bypass tunnel where > the LSR was not previously responsible for replicating this > data. This can arise if there are several MPs that are not one > hop downstream of the PLR. Further, in this case, the > replicated data may be required to be labeled with a > two-label label stack where both labels are different in each > copy of the data. > == > Section 15.1.2 > Again, the use of "MUST" is stronger than RFC 4090 > == > Section 15.1.2 > The MP MUST allocate the same label to all such S2L sub-LSPs > belonging to a particular P2MP LSP. > I think you cannot make this constraint. The MP doesn't necessarily know > that it is going to be an MP when it allocates the label for the S2L > sub-LSP. Besides, 5.2.1 has already allowed separate labels. > But this isn't an issue is it? If there are two labels there are already two > copies of the data. > == > Section 15.1.2 para 2 > After detecting failure of the protected node the PLR MUST send a > Path message for each protected S2L sub-LSP to the MP of the > protected S2L sub-LSP. > This implies one Path message for each S2L sub-LSP is that really the case? > Since we have a mechanism for placing more than one S2L sub-LSP in a Path > message, we could certainly use this here. > == > Section 15.1.2 para 2 > s/recommended/RECOMMENDED/ > == > Section 15.1.2 para 2 > s/MUST not/MUST NOT/ > == > Section 15.1.2 para 2 > Similar changes as in 15.1.1 wrt "while identifying" > == > Section 15.2 para 2 > Unlike the bypass stuff, the detour work seems a bit rocky. Perhaps no-one > has implemented it yet? > One to one backup as described in [RFC4090] can be used to protect a > particular S2L sub-LSP against link and next-hop failure. Protection > may be used for one or more S2L sub-LSPs between the PLR and the > next-hop. All the S2L sub-LSPs corresponding to the same instance of > the P2MP tunnel, between the PLR and the next-hop share the same P2MP > LSP label. > This leaves me uneasy. > Firstly, the statement about using the same label is in contradiction with > section 5.2.1. > But also, it seems to me odd that you are talking about protecting S2L > sub-LSPs rather than about protecting the P2MP LSP. True, you may achieve > the protection of the P2MP LSP by protecting each constituent S2L sub-LSP, > but if you start with the discussion of S2L sub-LSPs it implies that you > could protect sub S2L sub-LSPs within one P2MP LSP and not others. This > would appear to be a contradiction of the statement that all leaves of the > tree have the same LSP attributes. > So I think it would be helpful to spend some time reworking this text in > terms of the P2MP LSP. > == > Section 15.2 para 2 > All or some of these S2L sub-LSPs may be protected. > This seems to confirm my worst fears, but it is also damnably strange. > Consider: you have said that all of the S2L sub-LSPs use the same label. > Notwithstanding that I disagree with you, let us assume that they do. How > then would you protect only a subset of them? There is only one copy of the > data. > == > Section 15.2 para 2 > The detour S2L sub-LSPs may or may not share labels, depending on the > detour path. Thus the set of outgoing labels and next-hops for a P2MP > LSP that was using a single next-hop and label between the PLR and > next-hop before protection, may change once protection is triggerred. > Why would the label sharing for the detour LSPs (please don't call them > "detour S2L sub-LSPs" because they really don't go from the S or to the L) > behave differently from the protected LSPs? > I *think* you are setting yourself up for different MPs depending on the > leaves. But you didn't describe this process for bypass tunnels where it is > surely equally applicable. > == > Section 15.2 para 4 > s/recommended/RECOMMENDED/ > == > Section 16 para 7 > The ingress can use IGP > extensions to determine non P2MP capable LSRs [TE-NODE-CAP]. > Well, strictly it uses the extensions to determine P2MP-capable LSRs and can > then make assumptions that the other LSRs are either shy or not capable of > P2MP function. > == > Section 16 para 7 > The P2MP > capable LSR that initiates the non-adjacent signaling message to the > next P2MP capable LSR may have to employ a fast detection mechanism > such as [BFD] [BFD-MPLS] to the next P2MP capable LSR. > Please break this into the subsequent paragraph that contains the > explanation. > == > Section 17 para 1 > s/up P2MP LSP/up a P2MP LSP/ > s/Infact/In fact/ > == > Section 17 para 2 > s/P2P LSPs be dynamically setup/P2P LSPs can be dynamically set up/ > == > Section 17 para 2 > Not sure that a reference to a figure in the Appendix is appropriate. I > think Appendixes are normally non-normative. > == > Section 18 para 1 > Strike it > == > Section 18 para 4 > Normally, a P2MP LSP has a single incoming interface on which all of > the Path messages associated with that P2MP LSP are received. > Mustn't describe the interfaces in terms of how the Path messages are > received (see the very next sentence!). Let's keep to the data plane to > avoid the issue. > Normally, a P2MP LSP has a single incoming interface on which all of > the data for the P2MP LSP is received. > == > Section 18 para 5 > Similarly, in both the re-merge case and cross-over cases, a node > will receive a Path message for a given P2MP LSP on a different > incoming interface, and the node needs to be able to distinguish > between dynamic LSP re-routing and the re-merge/cross-over cases. > Same issue... > Similarly, in both the re-merge case and cross-over cases, a node > will receive a Path message for a given P2MP LSP identifying a > different incoming interface for the data, and the node needs to be > able to distinguish between dynamic LSP re-routing and the > re-merge/cross-over cases. > == > Section 18.1 para 2 > s/SUB-LSP objects/S2L_SUB_LSP objects/ (three times) > s/ set of SUB-LSPs/ set of S2L sub-LSPs/ > == > Section 18.1.1 para 2 > s/objects included the/objects included in the/ > == > Section 18.1.1 para 3 > s/followed for both/followed for all/ > == > Section 18.1.1 para 4 > When configured to allow a re-merge case to persist, the re-merge > node receives data associated with the P2MP LSP on multiple incoming > interfaces, but it may only send the data from one of these > interfaces to its outgoing interfaces, > s/may/MUST/ > == > Section 18.1.1 paras 5, 6 and 7 > s/SUB-LSP objects/S2L_SUB_LSP objects/ (six times) > == > Section 19.1.1 Extended Tunnel ID > s/ingress-PID/ingress-P2MP ID/ > == > Section 19.2 para 1 > s/ingress-LSR/ingress LSR/ > s/LSP ID can be can be/LSP ID can be/ > == > Section 19.2 para 1 > The instances can share > resources with each other, but use different labels. > Either strike ", but use different labels" or change to ", but may use > different labels." > == > Section 19.2.1 and 19.2.2 > This is a bit hairy, but... > The Sub-Group Originator and the source do not necessarily come from the > same IPv4/6 spaces. So you might need to add an IPv6 Sub-Group Originator to > a Sender_Template that has an IPv4 sender address. > I don't like the sound of this, because it creates four flavours instead of > the two listed, and it doesn't seem very likely to occur in the field. > What do we do? Leave it as it is and wait until someone encounters the > issue? > == > Section 19.2.2 > I think you can use the same short-form text as used in 19.1.2 and save some > trees. > == > Section 19.3.1 and 19.3.2 > s/SUB_LSP Class = 50/S2L_SUB_LSP Class = 50/ > == > Section 19.4.2 Title > s/4/6/ > == > Section 20 > The whole of this section needs to give IANA a better reference for where > the new code points are to be allocated. This can be done by naming the > registries (with the IANA pages). > == > Section 20.1 > s/50 Class Name = SUB_LSP/50 Class Name = S2L_SUB_LSP > == > Section 20.2 > s/P2MP LSP/P2MP_LSP/ (thrice) > == > Section 20.3 > For reference I have tracked these values in the interim registry of Routing > Problem error values at http://www.olddog.co.uk/ccamp.htm > == > Section 20.4 > Referenced Section of this Doc: 10 > s/10/5.2.4/ > For reference I have tracked these values in the interim registry of > LSP_ATTRIBUTE flags at http://www.olddog.co.uk/ccamp.htm > == > Section 21 > Absolutely no way we will get away with a 3 line security section! The > security ADs are positively mauling all I-Ds at the moment. > There are a couple of things we can say: > - more destinations for an LSP increases the risk > - there is potential for a listener to get themselves added to a P2MP tree > - there is description in the I-D about using tunnels to form remote > adjacencies > - DoS impact when one leaf is nobbled and the tree has LSP integrity applied > Probably lots more. > == > Section 23 > Usual to put the appendix later in the document > == > Section 23.1 point a) > We assume that PE1 learns of the > egress-LSRs at different points. > "points in time" ? > == > Section 24.2 > Suspect that some of the I-D versions listed have moved on > == > Section 25.2 > Lou and Markus's coordinates have changed > > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Thu May 25 07:13:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjDie-0002n4-HF; Thu, 25 May 2006 07:09:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjDid-0002mz-3a for mpls@ietf.org; Thu, 25 May 2006 07:09:31 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjDiY-0006P9-ER for mpls@ietf.org; Thu, 25 May 2006 07:09:31 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FjDiZ-0005lX-00 for mpls@ietf.org; Thu, 25 May 2006 12:09:27 +0100 Received: from your029b8cecfe ([217.158.132.94] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 12:09:12 +0100 Message-ID: <049901c67feb$a21c8ce0$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Yakov Rekhter" References: <200605242128.k4OLSB506950@merlot.juniper.net> Date: Thu, 25 May 2006 12:08:50 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 25 May 2006 11:09:13.0454 (UTC) FILETIME=[A7B818E0:01C67FEB] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: mpls@ietf.org, Bill Fenner , ccamp , Ross Callon Subject: [mpls] Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Yakov, >> > Few observations and suggestions... >> > >> > (a) tuple is both necessary and >> > sufficient to unambiguously identify a P2MP Tunnel. >> > >> > (b) Further is both >> > necessary and sufficient to identify a P2MP LSP. >> >> Clearly these two statements depend on the definition of "P2MP ID" as you >> pointed out below. >> >> As the I-D says... >> The P2MP ID provides an identifier for the set of destinations of the >> P2MP TE Tunnel. > > Does this identifier have a globally unique scope, or only the scope > of the root ? If the former, then what are the procedures for > assigning such identifiers ? Good questions. Presumably, if we want to retain the concept of Session (which appeared to be the case in discussion amongst the authors) then the P2MP ID has to have global scope. Not sure whether the procedures for assigning the identifiers has to be in scope of this document. The procedure for assigning IP addresses to P2P tunnel destinations does not appear to be in scope for RFC3209. It is worth looking at RFC4461 for more information on the P2MP ID. This gives us: A unique identifier of a P2MP TE LSP, which is constant for the whole LSP regardless of the number of branches and/or leaves. which is not as hepful as it could have been :-( I think you are right to try to flush this sort of thing out now rather than let us get into the ambiguity mess that we got to with RFC3209. >> And this means that there is not a one-to-one relationship between P2MP >> ID >> and P2MP Tunnel even within the scope of a single ingress. >> >> Although this was debated (the ingress could uniquely assign one ID per >> tunnel) we recognized: >> >> i. The Tunnel ID field already performs this function >> ii. It may be desirable to identify common sets of destinations >> >> The best example of ii. that was discussed would allow you to place a >> multicast IP address in the P2MP ID field. This is not mandatory (and >> some >> people think it is a bad idea :-), but the specification was designed to >> allow it. >> >> If an implementation chose to set P2MP ID = Tunnel ID, I guess that would >> be >> very fine with everyone. > > For one thing, this would limit the number of tunnels that could be > originated by a particular root node to 2^16. > > It would also rule out the ability to place a multicast IP address in > the P2MP ID field. Well, we already have the 2^16 limit for P2P tunnels. Are people running up against this limit? This can easily be seen as a separate set of 2^16 tunnels because a different object is used to encode the information, but this is a point that should definitely be clarified in the I-D: what is the relationship between the Tunnel IDs in P2P and P2MP Sessions? You're right that an implementation that sets P2MP ID = Tunnel ID cannot also set P2MP ID = multicast IP address. Whether this discussion is even meaningful depends on whether the scope of the P2MP ID uniqueness is global (can't use Tunnel ID) or ingress (can use Tunnel ID, or multicast address, or timestamp, or anything). >> > Therefore I would suggest that draft-ietf-mpls-rsvp-te-p2mp-05.txt >> > should say the following: >> > >> > 1. A P2MP tunnel is identified by a tuple > > index>, where the index value is unique within the scope of the IP >> > address of the root node. The P2MP tunnel identifier > > IP address, index> is unique within the same scope as the root node >> > IP address. >> > >> > 2. Both the Extended Tunnel ID and the Tunnel Sender Address fields >> > carry the root node IP address (both fields carry the same value). >> > The index is carried in the P2MP ID. >> >> I don't believe we should force the Extended Tunnel ID like this when an >> existing RFC defines another use albeit in the P2P context. > > What are exactly the (practical) problems with carrying the root > node IP address both in the Extended Tunnel ID and in the Tunnel > Sender Address fields ? You cannot do Session-based resource sharing across multiple sources. If you recall, RFC3209 says: To uniquely identify a TE tunnel, we use the combination of the destination IP address (an address of the node which is the egress of the tunnel), a Tunnel ID, and the tunnel ingress node's IP address, which is placed in the Extended Tunnel ID field. which supports what you say, but also: Extended Tunnel ID A 32-bit identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPv4 address here as a globally unique identifier. Is there any *practical* impact? Well, *if* the two fields are always going to carry the same information, clearly the second field is redundant. If the field is redundant, it can be used for other purposes if and when they are found. If that is the case, don't force it to be set to an irrelevant value in this I-D. Cheers, Adrian _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Fri May 26 12:17:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjevI-0001wJ-Lc; Fri, 26 May 2006 12:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjevG-0001vj-Oc for mpls@ietf.org; Fri, 26 May 2006 12:12:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjdLW-0006lI-AD for mpls@ietf.org; Fri, 26 May 2006 10:31:22 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fjcqn-0008RX-IQ for mpls@ietf.org; Fri, 26 May 2006 09:59:38 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 15:59:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 May 2006 15:59:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcZ2e8kdZHt94DGbSIS8D3qeup+F5AJeNGnAADXfNbA= From: "LE ROUX Jean-Louis RD-CORE-LAN" To: X-OriginalArrivalTime: 26 May 2006 13:59:36.0307 (UTC) FILETIME=[9F6D6C30:01C680CC] X-Spam-Score: -2.6 (--) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: Subject: [mpls] TR: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi all, I transfer the below comments on this list,=20 as it should be discussed as part of last call comments. Regards, JL > -----Message d'origine----- > De : LE ROUX Jean-Louis RD-CORE-LAN=20 > Envoy=E9 : jeudi 25 mai 2006 14:19 > =C0:=20 > Objet : RE: working group last call on=20 > draft-ietf-mpls-rsvp-te-p2mp-05.txt >=20 > Hi Rahul, Dimitri, Seisho >=20 > Thanks for the great edit job, >=20 > Find below a set of comments on this revision 05 >=20 > Four technical points: >=20 > 1: Section 8.1.2 Downstream notification >=20 > The text in 8.1.2 is a bit unclear =20 >=20 > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > object(s) of a Resv message to the value, that was received in the > corresponding Path message. If the incoming Resv message carries a > Notify Request object then, the LSR MUST set the Notify=20 > node address > in the Notify Request object to the value, that was received in the > corresponding Path message", >=20 > Which value? The sub-group originator? the notify address?=20 > This is unclear. The processing needs to be clarified. > We could update as follows: >=20 > "If the incoming Resv message carries a Notify Request object then, > -If the sub-group originator ID is its own=20 > address, the LSR MUST set the Notify node address in the=20 > Notify Request object to its own address, in the Resv message=20 > that it sends upstream. > -If the sub group originator ID is not its own=20 > address, the LSR MUST propagate the Notify Request object=20 > unchanged, in the Resv message that it sends upstream." >=20 > 2: Section 8.2 ResvConf >=20 > Similar comment >=20 > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > object(s) of a Resv message to the value, that was received in the > corresponding Path message. If any of the incoming Resv messages > corresponding to a single Path message carry a RESV_CONFIRM object > then the LSR MUST include a RESV_CONFIRM object in the=20 > corresponding > Resv message that it sends upstream and MUST set the=20 > receiver address > in the RESV_CONFIRM object to the value that was received in the > corresponding Resv message." >=20 > Change to >=20 > " > A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > object(s) of a Resv message to the value, that was received in the > corresponding Path message. If any of the incoming Resv messages > corresponding to a single Path message carry a RESV_CONFIRM object > then the LSR MUST include a RESV_CONFIRM object in the=20 > corresponding > Resv message that it sends upstream. If the sub-group=20 > originator ID is its own address then =20 > it MUST set the receiver address in the RESV_CONFIRM=20 > object to this addresse, else it MUST =20 > propagate the object unchanged" >=20 >=20 > 3: Section 14.2 Sub-group based reoptimization >=20 > The new path may intersect the old path, this is a case of=20 > rerouting and this is not covered by remerge procedures as=20 > described in section 18. Hence Transient Data duplication may=20 > occur during the time between the Resv is received and the=20 > PathTear is sent. To avoid data duplication the branch node=20 > must not start transmitting on the new path before the old=20 > path has been torn down, but this will lead to transient packet loss.=20 > This should be clearly mentionned here IMO. > Actually the only way to avoid both transient duplication and=20 > transient packet loss is to rely on the global mb4b procedure=20 > with a new LSP id... >=20 > 4: Section 18.1.1 Remerge Procedure >=20 > The text says > "The PathErr message MUST include all of the objects > normally included in a PathErr message, as well as one or more SUB- > LSP objects from the set of sub-LSPs associated with the matching > P2MP LSP Path state. A minimum of three SUB-LSP objects is > RECOMMENDED. This will allow the node that caused the re-merge to > identify the outgoing Path state associated with the valid=20 > portion of > the P2MP LSP. The set of SUB-LSP objects in the received=20 > Path message > MUST also be included" >=20 > And then: >=20 > "A node that receives a PathErr message that contains the=20 > Error Value > "Routing Problem/P2MP Remerge Detected" MUST determine if it is the > node that created the re-merge case. This is done by checking > whether there is any intersection between the set of=20 > SUB-LSP objects > associated with the matching P2MP LSP Path state and the=20 > set of SUB- > LSP objects in the received PathErr message. If there is, then the > node created the re-merge case." > =20 > There is an issue here. Actually there will always be an=20 > intersection, because the PathErr includes the set of sub-lsp=20 > objects in the received Path... IMO for this procedure to work=20 > the PathErr MUST only include sub-LSP objects associated with=20 > the matching P2MP LSP state on the rermerge LSR and must not=20 > include the set of SUB-LSP objects in the received Path message.=20 > By the way why are three objects recommended? >=20 >=20 > Also find below some minor edits: >=20 > Section 6.1 >=20 > ::=3D ; [ SECONDARY_EXPLICIT_ROUTE> ] > Change to: > ::=3D ; [ SECONDARY_RECORD_ROUTE> ] >=20 > Section 7.1 > change to >=20 > Section 8.1.2 >=20 > "If this LSR subsequently receives a corresponding Notify=20 > message from > an upstream LSR than it MUST: > - send a Notify message downstream toward the Notify > node address that the LSR received in the Resv message.=20 > - process the sub-group fields of the FILTER_SPEC object in the > received Notify message, and modify their values in the Notify > message that is forwarded to match the sub-group field values > in the original Path message sent downstream by this LSR." >=20 > Invert these two bullets >=20 > Section 8.2 >=20 > "If this LSR subsequently receives a corresponding ResvConf message > from an upstream LSR then it MUST: > - send a ResvConf message downstream toward the receiver=20 > address that > the LSR received in the RESV_CONFIRM object in the Resv message.=20 > - process the sub-group fields of the FILTER_SPEC object in the > received ResvConf message, and modify their values in=20 > the ResvConf > message that is forwarded to match the sub-group field values > in the original Path message sent downstream by this LSR." >=20 > Invert these two bullets >=20 > Section 11.2 last sentence >=20 > "Note the receiver of a ResvErr message is able to=20 > identify the errored outgoing Path [Change to: Resv] > message, and outgoing interface, based on the Sub-Group fields > received in the ResvErr message. >=20 > Section 13 >=20 > "A sender on a LAN uses a different label for sending traffic to each > node on the LAN that belongs to the P2MP LSP" >=20 > This is not always the case, I would rather say >=20 > "Downstream nodes for a given P2MP LSP on a LAN are likely to=20 > allocate a different label, in which case the sender has to=20 > perform replication"... >=20 > Section 16 >=20 > "Stitching and nesting > considerations and procedures are described further in [INT-REG]." >=20 > Change to "Stitching and nesting > considerations and procedures are described further in=20 > [LSP-STITCH] and [RFC4206]." >=20 > Section 17 >=20 > Infact =3D> In fact >=20 > Section 19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object =3D> P2MP=20 > LSP_IPv6 FILTER_SPEC object >=20 > Also some references need to be updated... >=20 > Best Regards, >=20 > JL >=20 > > -----Message d'origine----- > > De : owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] De la part de Loa=20 > Andersson Envoy=E9 :=20 > > samedi 13 mai 2006 12:48 =C0 : mpls@ietf.org Cc : ccamp;=20 > George Swallow;=20 > > zzx-adrian@olddog.co.uk; Deborah Brungard; Ross Callon; Bill Fenner=20 > > Objet : working group last call on=20 > draft-ietf-mpls-rsvp-te-p2mp-05.txt > >=20 > > Working Group, > >=20 > > this initiates a two week working group last call on=20 > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > >=20 > > please send comments to the MPLS working group mailling list and/or=20 > > working co-chairs. > >=20 > > The last call ends eob May 28th. > >=20 > > The ccamp mailing list copied as this is a work that has an overlap=20 > > between the working groups. > >=20 > > Loa and George > >=20 > >=20 > >=20 > > -- > > Loa Andersson > >=20 > > Principal Networking Architect > > Acreo AB phone: +46 8 632 77 14 > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > Kista, Sweden email: loa.andersson@acreo.se > > loa@pi.se > >=20 > >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sat May 27 13:15:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk2IF-0005GH-3T; Sat, 27 May 2006 13:09:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk2ID-0005G7-0R for mpls@ietf.org; Sat, 27 May 2006 13:09:37 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk2IB-000502-O3 for mpls@ietf.org; Sat, 27 May 2006 13:09:36 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 27 May 2006 10:09:36 -0700 X-IronPort-AV: i="4.05,180,1146466800"; d="scan'208"; a="549719864:sNHT28592052" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 May 2006 10:09:34 -0700 Date: Sat, 27 May 2006 10:09:34 -0700 (PDT) From: Rahul Aggarwal To: mpls@ietf.org In-Reply-To: <09fc01c67b4a$8cea27b0$36849ed9@your029b8cecfe> Message-ID: <20060527093817.G85896@sapphire.juniper.net> References: <4465B972.4090305@pi.se> <09fc01c67b4a$8cea27b0$36849ed9@your029b8cecfe> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 27 May 2006 17:09:35.0006 (UTC) FILETIME=[53FE9BE0:01C681B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [mpls] [LC comments] Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Two comments as part of the last call: 1. The spec should clarify which HOP object is used when. Suggest adding at the end of 5.1: "IF_ID RSVP_HOP object MUST be used on links where there is not a one-to-one association of a control channel to a data channel [RFC3471]. RSVP_HOP object defined in [RFC2205] SHOULD be used otherwise." 2. Section 18.1.1 "There are two approaches to dealing with re-merge case. In the first, the node detecting the re-merge case, i.e., the re-merge node, allows the re-merge case to persist but data from all but one incoming interface is dropped at the re-merge node. In the second, the re-merge node initiates the removal of the re-merge branch(es) via signaling. Which approach is used is a matter of local policy. A node MUST support both approaches and MUST allow user configuration of which approach is to be used." I don't think it is necessary for a node to support both approaches. What is required is that a node that detects remerge MUST be able to support at least one of the approaches. Further for the second approach to work a node MUST be able to receive and process the PathError with "P2MP Remerge Detected" value. This is already implied by the text that follows in this section. With this in mind I propose changing the above paragraph to: "There are two approaches to dealing with re-merge case. In the first, the node detecting the re-merge case, i.e., the re-merge node, allows the re-merge case to persist but data from all but one incoming interface is dropped at the re-merge node. In the second, the re-merge node initiates the removal of the re-merge branch(es) via signaling. A node that detects the re-merge case MUST support at least one of the approaches. If a node that detects the re-merge case supports both the approaches it MUST allow user configuration of which approach is to be used." rahul _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sun May 28 04:28:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkGYj-0005fD-Vc; Sun, 28 May 2006 04:23:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkGYi-0005W9-3m for mpls@ietf.org; Sun, 28 May 2006 04:23:36 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkGYe-0000Jj-3j for mpls@ietf.org; Sun, 28 May 2006 04:23:36 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 May 2006 01:23:31 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4S8NVEp009060 for ; Sun, 28 May 2006 01:23:31 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4S8NUku020417 for ; Sun, 28 May 2006 04:23:30 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 28 May 2006 04:23:30 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 28 May 2006 04:23:29 -0400 Mime-Version: 1.0 (Apple Message framework v750) To: mpls@ietf.org Message-Id: <61938AE7-6A93-43F3-B057-F0EE1D64CE94@cisco.com> References: From: JP Vasseur Date: Sun, 28 May 2006 04:23:28 -0400 X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 28 May 2006 08:23:29.0981 (UTC) FILETIME=[002FC6D0:01C68230] DKIM-Signature: a=rsa-sha1; q=dns; l=19678; t=1148804611; x=1149668611; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:JP=20Vasseur=20 |Subject:Fwd=3A=20I-D=20ACTION=3Adraft-ietf-mpls-number-0-bw-te-lsps-01.txt=20; X=v=3Dcisco.com=3B=20h=3DWVuRLxhjG7aFZWwn63+8qhut/s8=3D; b=DoW60sryw4oGmIsjQbHJ4WGLMoN6k1toSXZCuVYfXO2ZqBeJZvUZ8k/7aLumg5DB2t1vS6Sw fylJWxbedh1ri63JUsQvjMRgRDa4emfpoQD3QX3fJrxVKqdRaw5sfBTZ; Authentication-Results: sj-dkim-3.cisco.com; header.From=jvasseur@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: Subject: [mpls] Fwd: I-D ACTION:draft-ietf-mpls-number-0-bw-te-lsps-01.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1392152054==" Errors-To: mpls-bounces@lists.ietf.org --===============1392152054== Content-Type: multipart/alternative; boundary=Apple-Mail-85-846200648 --Apple-Mail-85-846200648 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI: Most changes are editorial. Comments are of course very welcome. Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: May 24, 2006 3:50:01 PM EDT > To: i-d-announce@ietf.org > Cc: mpls@lists.ietf.org > Subject: I-D ACTION:draft-ietf-mpls-number-0-bw-te-lsps-01.txt > Reply-To: internet-drafts@ietf.org > > 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 : A Link-Type sub-TLV to convey the number of Traffic > Engineering Label Switch Paths signalled across a link > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-mpls-number-0-bw-te-lsps-01.txt > Pages : 8 > Date : 2006-5-24 > > Several Link-type sub-TLVs have been defined for OSPF and ISIS in the > context of MPLS Traffic Engineering in order to convery some link > characteristics such as the available bandwidth, traffic enginering > metric, adminstrative group and so on. There are various > circumstances where it would be useful to also advertise the number > of unconstrained Traffic Engineering Label Switched Path(s) (TE LSP) > signalled across a link. This document specifies a new Link-type > Traffic Engineering sub-TLV used to advertise the number of > unconstrained TE LSP(s) signalled across a link. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-number-0-bw-te- > lsps-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-number-0-bw-te-lsps-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-5-24112441.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce --Apple-Mail-85-846200648 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI: Most changes are = editorial.

Comments are of course very = welcome.

Thanks.

JP.

Begin = forwarded message:

Date: May 24, 2006 3:50:01 PM = EDT
To: i-d-announce@ietf.orgSubject: = I-D ACTION:draft-ietf-mpls-number-0-bw-te-lsps-01.txt=A0

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 : A Link-Type sub-TLV to convey = the number of Traffic Engineering Label Switch Paths signalled across a = link
Author(s) : J. = Vasseur, et al.
Filename : = draft-ietf-mpls-number-0-bw-te-lsps-01.txt
= Pages = = : 8
Date : 2006-5-24

Several = Link-type sub-TLVs have been defined for OSPF and ISIS in the
context of MPLS Traffic Engineering in order to = convery some link
characteristics such as the = available bandwidth, traffic enginering
metric, = adminstrative group and so on.=A0 = There are various
circumstances = where it would be useful to also advertise the number
of unconstrained Traffic Engineering Label Switched = Path(s) (TE LSP)
signalled across a link.=A0 This document specifies a new = Link-type
Traffic Engineering sub-TLV used = to advertise the number of
unconstrained = TE LSP(s) signalled across a link.

A URL for this Internet-Draft = is:
To remove yourself from the I-D = Announcement list, send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of the message. =A0
to = change your subscription settings.


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-number-0-bw-te-lsps-01.txt".

A list = of Internet-Drafts directories can be found in

Internet-Drafts can also be obtained by = e-mail.

Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-mpls-number-0-bw-te-lsps-01.txt".

NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 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
Content-Type: = text/plain

=

= --Apple-Mail-85-846200648-- --===============1392152054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1392152054==-- From mpls-bounces@lists.ietf.org Sun May 28 12:51:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkOQB-0001U5-3k; Sun, 28 May 2006 12:47:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkOQ9-0001U0-WB for mpls@ietf.org; Sun, 28 May 2006 12:47:18 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkOQ8-0006Up-JE for mpls@ietf.org; Sun, 28 May 2006 12:47:17 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k4SGlCX52363; Sun, 28 May 2006 09:47:12 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k4SGkn536645; Sun, 28 May 2006 09:46:49 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200605281646.k4SGkn536645@merlot.juniper.net> To: "Adrian Farrel" In-Reply-To: Your message of "Thu, 25 May 2006 12:08:50 BST." <049901c67feb$a21c8ce0$0a23fea9@your029b8cecfe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12977.1148834809.1@juniper.net> Date: Sun, 28 May 2006 09:46:49 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: mpls@ietf.org, Bill Fenner , ccamp , Ross Callon Subject: [mpls] Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Adrian, > >> > Few observations and suggestions... > >> > > >> > (a) tuple is both necessary and > >> > sufficient to unambiguously identify a P2MP Tunnel. > >> > > >> > (b) Further is both > >> > necessary and sufficient to identify a P2MP LSP. > >> > >> Clearly these two statements depend on the definition of "P2MP ID" as you > >> pointed out below. > >> > >> As the I-D says... > >> The P2MP ID provides an identifier for the set of destinations of the > >> P2MP TE Tunnel. > > > > Does this identifier have a globally unique scope, or only the scope > > of the root ? If the former, then what are the procedures for > > assigning such identifiers ? > > Good questions. > > Presumably, if we want to retain the concept of Session (which appeared to > be the case in discussion amongst the authors) then the P2MP ID has to have > global scope. > > Not sure whether the procedures for assigning the identifiers has to be in > scope of this document. The procedure for assigning IP addresses to P2P > tunnel destinations does not appear to be in scope for RFC3209. > > It is worth looking at RFC4461 for more information on the P2MP ID. This > gives us: > A unique identifier of a P2MP TE LSP, which is constant for the > whole LSP regardless of the number of branches and/or leaves. > which is not as hepful as it could have been :-( > > I think you are right to try to flush this sort of thing out now rather than > let us get into the ambiguity mess that we got to with RFC3209. There is a difference between IP addresses used for P2P tunnel destinations, and identifiers used for P2MP ID. The former are unicast addresses (each address identifies a *single* node/interface). The latter are *group* addresses (each address identifies a *group* of nodes). There are well-established procedures for assigining unicast IP addresses, but not for group addresses. If some folks would like to retain the ability of the P2MP ID to have global scope, then at the minimum the spec (a) should have this as *an option*, with P2MP ID having the scope of the root node being another option documented in the spec, and (b) spell out the procedures for assigining such globally unique P2MP IDs. Yakov. _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Sun May 28 16:48:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkS61-0004hO-Od; Sun, 28 May 2006 16:42:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkS60-0004db-Lj for mpls@lists.ietf.org; Sun, 28 May 2006 16:42:44 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkS5w-0004x7-Ju for mpls@lists.ietf.org; Sun, 28 May 2006 16:42:44 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 May 2006 22:42:41 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 28 May 2006 22:42:37 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260379B4C0@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [MPLS2006 INTERNATIONAL CONFERENCE] Update of the CFP Thread-Index: AcZMwb4AKzPvaPWxThKRbiKvrV7lrweGQVzwBe7c1qA= From: "MOIGNARD Renaud RD-CORE-LAN" To: X-OriginalArrivalTime: 28 May 2006 20:42:41.0161 (UTC) FILETIME=[438CC790:01C68297] X-Spam-Score: 0.2 (/) X-Scan-Signature: 320ddee61cb2d39f489e9191ae3fdc8c Subject: [mpls] [MPLS2006 INTERNATIONAL CONFERENCE] Update of the CFP X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1241181122==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1241181122== Content-class: urn:content-classes:message Content-Type: multipart/signed; boundary="----=_NextPart_000_0014_01C682A8.044A90B0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C682A8.044A90B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0015_01C682A8.044A90B0" ------=_NextPart_001_0015_01C682A8.044A90B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Call for Presentations at MPLS 2006 MPLS 2006, the 9th Annual International Conference on MPLS and Related Technologies, will be held on October 15 through 18, 2006, in Washington, DC. The Program Committee of MPLS2006 is soliciting presentation proposals for the conference. The program committee seeks original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations addressing new technologies and operational experience are solicited from network equipment vendors, service providers, the research community, government agencies, and enterprise users. The deadline for submission of presentation proposals is June 7, 2006. Submit your presentation : http://www.isocore.com/mpls2006/cfpupload.php Technical Program Committee Co-Chairs Daniel Awduche [Verizon Business] Renaud Moignard [France Telecom] Technical Program Committee Zubair Ahmad [Equant] David McDysan [Verizon] Loa Andersson [Acreo] Monique Morrow [Cisco Systems] Peter Arberg [Redback] Eiji Oki [NTT] Alia Atlas [Google] Lyndon Ong [Ciena] Jerry Ash [ATT] Tomohiro Otani [KDDI Labs] Deborah Brungard [ATT] Dimitri Papadimitriou [Alcatel] Marco Carugi [Nortel Networks] Rajiv Papneja [Isocore] Bruce Davie [Cisco Systems] Richard Rabbat [Fujitsu] Luyuan Fang [ATT] Yakov Rekhter [Juniper Networks] Adrian Farrel [Old Dog Consulting] George Swallow [Cisco Systems] Don Fedyk [Nortel Networks] Kohei Shiomoto [NTT] Bur Goode [ATT] JP Vasseur [Cisco Systems] Joao Gomes [Orange] Anwar Walid [Lucent] Bijan Jabbari [Isocore] Lei Wang [Telenor] Kireeti Kompella [Juniper Networks] Bert Wijnen [Lucent] Vach Kompella [Alcatel] Rajesh Yadav [Verizon] Francois Le Faucheur [Cisco Systems] Naoaki Yamanaka [Keio] Jean Louis Le Roux [France Telecom] Ferit Yegenoglu [Lockheed Martin] Bill Li [Huawei] Ali Zadeh [Isocore] Tove Madsen [Acreo] Yong Zhou [Redback] Andy Mallis [Tellabs] James Zhu [Huawei] Alex Zinin [Alcatel] This year's conference will include, but will not be limited to, the following topics: - MPLS in multi-area and multi-AS networks - Point-to-multipoint MPLS and applications - Multicast in MPLS L3 VPNs and for VPLS - Single and Multi-hop Pseudowire placement, setup, and management - Providing QoS in MPLS networks - MPLS network management - OAM for MPLS networks - MPLS in Next Generation Networks - Voice over IP/MPLS - IMS and IPTv over MPLS - Triple-play applications on MPLS - MPLS-enabled Advanced services and converged networks - Interworking and migration for MPLS and GMPLS - Multi-layer networks and integration with non-packet technologies - Deploying, interworking, and operating L2 and L3 MPLS VPNs - MPLS deployment experience: scaling, performance, and security - Testing: MPLS test tools and certification experience - Protection, restoration, and reliability - Network processors for MPLS and GMPLS - MPLS/GMPLS control plane resilience, scaling and robustness - MPLS TE applications of the Path Computation Element (PCE) - MPLS to the access network - MPLS and IPv6 - MPLS in the Enterprise Arena - Carrier Ethernet Services - GMPLS Applications (L1 VPNs, ASON, Optical Internetworking, NNI/UNI) - Fast Routing Convergence - High Availability (Graceful Restart, Non-Stop Routing, In-Service Software Upgrades, etc) - MPLS in the Mobile Trunking Space - MPLS Applications for Mobile Access Optimization For additional information please see www.mpls2006.com. ------=_NextPart_001_0015_01C682A8.044A90B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [MPLS2006 INTERNATIONAL CONFERENCE] CFP

Call for=20 Presentations at MPLS 2006

 

MPLS 2006, = the 9th=20 Annual International Conference on MPLS and Related Technologies, will = be held=20 on October 15 through 18, 2006, in Washington, DC. The Program Committee of = MPLS2006 is=20 soliciting presentation proposals for the conference.  The program=20 committee seeks original and unpublished work to continue the tradition=20 initiated by this conference in 1998 of covering cutting-edge = topics. =20 Presentations addressing new technologies and operational experience are = solicited from network equipment vendors, service providers, the = research=20 community, government agencies, and enterprise users. =20

 

The=20 deadline for submission of presentation proposals is=20 June = 7,=20 2006.

Submit your presentation  : http://www.isocore= .com/mpls2006/cfpupload.php  

 

Technical = Program=20 Committee Co-Chairs

Daniel = Awduche=20 [Verizon Business]     Renaud Moignard [France=20 Telecom]

 

Technical = Program=20 Committee

Zubair = Ahmad=20 [Equant]           &nbs= p;            = ;            =         =20 David McDysan [Verizon]

Loa = Andersson=20 [Acreo]           &nbs= p;            = ;            =         =20 Monique Morrow [Cisco Systems]

Peter = Arberg=20 [Redback]           &nbs= p;            = ;            =        =20 Eiji Oki [NTT]

Alia Atlas = [Google]           &nbs= p;            = ;            =             &= nbsp; =20 Lyndon Ong [Ciena]

Jerry Ash = [ATT]           &nbs= p;            = ;            =             &= nbsp;    =20 Tomohiro Otani [KDDI Labs]

Deborah = Brungard=20 [ATT]           &nbs= p;            = ;            =       =20 Dimitri=20 Papadimitriou [Alcatel]

Marco = Carugi [Nortel=20 Networks]           &nbs= p;            = ;         =20 Rajiv Papneja=20 [Isocore]

Bruce = Davie [Cisco=20 Systems]            &nbs= p;            = ;           =20 Richard Rabbat [Fujitsu]

Luyuan = Fang=20 [ATT]           &nbs= p;            = ;            =             &= nbsp;=20 Yakov Rekhter [Juniper Networks]

Adrian = Farrel [Old=20 Dog Consulting]           &nbs= p;            = ;     =20 George Swallow [Cisco Systems]

Don Fedyk = [Nortel=20 Networks]           &nbs= p;            = ;            = =20 Kohei Shiomoto [NTT]

Bur Goode = [ATT]           &nbs= p;            = ;            =             &= nbsp;   =20 JP Vasseur [Cisco Systems]

Joao Gomes = [Orange]           &nbs= p;            = ;            =           =20 Anwar Walid [Lucent]

Bijan=20 Jabbari = [Isocore]           &nbs= p;            = ;            =          =20 Lei Wang [Telenor]

Kireeti = Kompella=20 [Juniper Networks]           &nbs= p;      =20 Bert Wijnen [Lucent]

Vach = Kompella=20 [Alcatel]           &nbs= p;            = ;            =        =20 Rajesh Yadav [Verizon]

Francois = Le Faucheur=20 [Cisco Systems]           &nbs= p;           =20 Naoaki=20 Yamanaka [Keio]

Jean=20 Louis Le Roux [France Telecom]           &nbs= p;            = ; =20 Ferit = Yegenoglu=20 [Lockheed Martin]

Bill Li=20 [Huawei]           &nbs= p;            = ;            =             &= nbsp;      =20 Ali Zadeh [Isocore]

Tove = Madsen=20 [Acreo]           &nbs= p;            = ;            =             &= nbsp;      =20 Yong Zhou [Redback]

Andy = Mallis=20 [Tellabs]           &nbs= p;            = ;            =            =20 James Zhu [Huawei]

           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;        =20 Alex Zinin = [Alcatel]

 

This year's = conference will include, but will not be limited to, the following=20 topics:

- MPLS in = multi-area=20 and multi-AS networks
- Point-to-multipoint MPLS and = applications
-=20 Multicast in MPLS L3 VPNs and for VPLS
- Single and Multi-hop = Pseudowire=20 placement, setup, and management
- Providing QoS in MPLS = networks
- MPLS=20 network management
- OAM for MPLS networks
- MPLS in Next = Generation=20 Networks
- Voice over IP/MPLS
- IMS and IPTv over MPLS
- = Triple-play=20 applications on MPLS
- MPLS-enabled Advanced services and converged=20 networks
- Interworking and migration for MPLS and GMPLS
- = Multi-layer=20 networks and integration with non-packet technologies
- Deploying,=20 interworking, and operating L2 and L3 MPLS VPNs
- MPLS deployment = experience:=20 scaling, performance, and security
- Testing: MPLS test tools and=20 certification experience
- Protection, restoration, and = reliability
-=20 Network processors for MPLS and GMPLS
- MPLS/GMPLS control plane = resilience,=20 scaling and robustness
- MPLS TE applications of the Path Computation = Element=20 (PCE)
- MPLS to the access network

- MPLS and = IPv6=20  

-=20 MPLS in the Enterprise Arena =

-=20 Carrier Ethernet Services

-=20 GMPLS Applications (L1 VPNs, ASON, Optical Internetworking, NNI/UNI)=20

-=20 Fast Routing Convergence

-=20 High Availability (Graceful Restart, Non-Stop Routing, In-Service = Software=20 Upgrades, etc) =20

-=20 MPLS in the Mobile Trunking = Space 

-=20 MPLS Applications for Mobile Access=20 Optimization

 

 

For = additional=20 information please see www.mpls2006.com. =

    

 

 

 

------=_NextPart_001_0015_01C682A8.044A90B0-- ------=_NextPart_000_0014_01C682A8.044A90B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISRjCCBHYw ggNeoAMCAQICAh1yMA0GCSqGSIb3DQEBBQUAMFwxCzAJBgNVBAYTAkZSMRcwFQYDVQQKEw5GcmFu Y2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRSRCBBQyBvcGVyYXRp b25uZWxsZTAeFw0wNDA3MjYxMzM4MDhaFw0wNzA3MjYxMzM4MDhaMIGhMQswCQYDVQQGEwJGUjEX MBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQVNQSUMxGDAWBgNVBAMTD1Jl bmF1ZCBNT0lHTkFSRDEYMBYGCgmSJomT8ixkAQETCFJJRU02NTExMTAwLgYJKoZIhvcNAQkBFiFy ZW5hdWQubW9pZ25hcmRAZnJhbmNldGVsZWNvbS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBANwKgWWbcF4ydr3artBnnPCZZvyQeQMOCr4prBQxdmfE6L0eXZFerJZ1OfljPDu6zzUxWwZ1 mxm0UJeduoV4APyYSy1P7ur1VKIProV10CLRFrfD5P8JKYN/voknWGkk5k02wvFVYX503wlUruq1 RoiBKPOXRWh5aXhtPbSYMaLHAgMBAAGjggF+MIIBejAdBgNVHQ4EFgQUyZmjipbYDUl8ssXnh1Po jgugJRcwHwYDVR0jBBgwFoAUp4e40Iv0b+PBwNrtjrTgpxAp/NgwgZIGA1UdHwSBijCBhzBHoEWg Q4ZBaHR0cDovL2x1Y2lmZXIucmQuZnJhbmNldGVsZWNvbS5mci9yZXZvcXVlcy9jcmxvcGVyYXRp b25uZWxsZS5jcmwwPKA6oDiGNmh0dHA6Ly9wa2ktbC5yZC5mcmFuY2V0ZWxlY29tLmZyL2NybG9w ZXJhdGlvbm5lbGxlLmNybDAOBgNVHQ8BAf8EBAMCBDAwEwYDVR0lBAwwCgYIKwYBBQUHAwQwEQYJ YIZIAYb4QgEBBAQDAgUgMCwGA1UdEQQlMCOBIXJlbmF1ZC5tb2lnbmFyZEBmcmFuY2V0ZWxlY29t LmNvbTA9BglghkgBhvhCAQ0EMBYuQ2VydGlmaWNhdCBkZSBDaGlmZnJlbWVudCBwb3VyIFJlbmF1 ZCBNT0lHTkFSRDANBgkqhkiG9w0BAQUFAAOCAQEAh34Ot/bDb9UPOivDtJ+8X7MChib5OX76CPfD dtO9iMl2/Zqu9pOh2dniPnlU8k3tFAcnrt+cF1SDm9fA/57rf5yPiR3RFx/KWfWD/vf92GlkRaWg 04zSCqLrhkfgJXGRuRyl4NNwghEdwzhwPYJYjcz3WowsfRX2dKZgImYuWcXzZLPEyqYu/0sXUhUy PvHuSwMNyeXTs9Dsg2gUbUWFUeLCdQ+vFXv9a+k6G/OlmLKka0nAYULytyH5/5+wboprmPF6go9K JuU4oKdLtDcevXhXBRZh3rhAG6Ogc+YxalM7TP2sUq1UsXTlj8766byySyxx9ZZlkOFKerqFgGRD BTCCBIAwggNooAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCRlIxFzAVBgNVBAoT DkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFzcGljMRcwFQYDVQQDEw5GVFJEIEFDIFJh Y2luZTAeFw0wMjEwMDMwNzA3NThaFw0xMjEwMDIwNzA3NThaMFQxCzAJBgNVBAYTAkZSMRcwFQYD VQQKEw5GcmFuY2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEXMBUGA1UEAxMORlRSRCBB QyBSYWNpbmUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDfNb9DTp38mMZszg1TJwHe ONcylQu+PXC7oOjphIYne0HQQHUSXjKDKJ7vblnTkArsr3Ruu1QrAOvOmkmwz8k06M03hcGZ0Y92 8oWa3KG6idksdKwNj40JqWbpIEkt5fAsNDp2TuZaUGUgXzieBdDkY3uyFq0G/EG6T7f3Gwj4nu2Y 4VIpa947Nk0ljwFK4WSSqdDTUh8ZOVfpaAfsUi6laynWFpaIquEa4xKVy/O/djTMEelEZva8ADib tC8GFNO6uoiyjiNdOqk7ynoy1cQC+frE+WFiv7m4vIXS4VvLvQsTk5knyfaWPANRYqj8lnCd4B0s 9iLUbx9piatXPyLjAgMBAAGjggFbMIIBVzASBgNVHRMBAf8ECDAGAQH/AgEBMB0GA1UdDgQWBBS3 Se6TQSJ/2aiXlSc+ZGaerhg/AzB8BgNVHSMEdTBzgBS3Se6TQSJ/2aiXlSc+ZGaerhg/A6FYpFYw VDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFz cGljMRcwFQYDVQQDEw5GVFJEIEFDIFJhY2luZYIBADAOBgNVHQ8BAf8EBAMCAQYwgYAGA1UdHwR5 MHcwP6A9oDuGOWh0dHA6Ly9sdWNpZmVyLnJkLmZyYW5jZXRlbGVjb20uZnIvcmV2b3F1ZXMvY3Js cmFjaW5lLmNybDA0oDKgMIYuaHR0cDovL3BraS1sLnJkLmZyYW5jZXRlbGVjb20uZnIvY3JscmFj aW5lLmNybDARBglghkgBhvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAGi8vbslCQ47x0nr 1vZXWmbBvs5e0NSfj5zDzgn32B3ShyOv67c6dEvq1BjFhHRfNhcRpxmiE9P4HOqftoD7/v92MRlo G9GgSucRI8SHn5oQO6xisabqxquD5hI+G+mHv2fYUwRZRSNiMbudc5OIRLx6JMvKBXUHc29vaueN aRQbD+6m4ncYuts5asRO0uGcftys5HoAySCepOF1yt9O41GCQW5wu2gaHUk+j9iPKk13JRu6k5Cn /8M8tcvA0skajQAaF+ly3kMjPaJhqygEYXQoLDFC6DzUQDCNTdZ9w5Qwin1oyZe1lWmssMihlZok iiJ22LTOVwdoaGhKydWRJN0wggSIMIIDcKADAgECAgEBMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV BAYTAkZSMRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEXMBUG A1UEAxMORlRSRCBBQyBSYWNpbmUwHhcNMDIxMDAzMDcxNTIwWhcNMTIxMDAyMDcxNTIwWjBcMQsw CQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQXNwaWMx HzAdBgNVBAMTFkZUUkQgQUMgb3BlcmF0aW9ubmVsbGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDyhK63MkH/rYERgbIgUChhp74XjBfhO+FwEZJA6zZy/6AOcOnvejY+Xhe03aIhOwCE EbzlKyZCPcT++LMw1D/wjwT1ccS9POeacqB/6gXIHVQlVgQyhhq6HPQOTnl7CgonrW9cuPj1eSXk FcN3uNb6idOlLfNUGD5GfOLiUiIkTaGmRvnQWATnz/KS9xo9o51+d3rJX3Yl47JTJO4nG73LwLgZ cx1Py5CzR2Vf4hCRhn491/JDjBdHt79TpQF/k1xGJbwOOsJ336lTCIIohWwBzzgTCKjjDlUF8dkn aJEXKQLB7W/C3Gi60rHg3/25s74ZLn6eqmKFKDQvbOIOPCfRAgMBAAGjggFbMIIBVzASBgNVHRMB Af8ECDAGAQH/AgEAMB0GA1UdDgQWBBSnh7jQi/Rv48HA2u2OtOCnECn82DB8BgNVHSMEdTBzgBS3 Se6TQSJ/2aiXlSc+ZGaerhg/A6FYpFYwVDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBU ZWxlY29tMRMwEQYDVQQLEwpGVFJELUFzcGljMRcwFQYDVQQDEw5GVFJEIEFDIFJhY2luZYIBADAO BgNVHQ8BAf8EBAMCAQYwgYAGA1UdHwR5MHcwP6A9oDuGOWh0dHA6Ly9sdWNpZmVyLnJkLmZyYW5j ZXRlbGVjb20uZnIvcmV2b3F1ZXMvY3JscmFjaW5lLmNybDA0oDKgMIYuaHR0cDovL3BraS1sLnJk LmZyYW5jZXRlbGVjb20uZnIvY3JscmFjaW5lLmNybDARBglghkgBhvhCAQEEBAMCAAcwDQYJKoZI hvcNAQEFBQADggEBALaNFmEzT8zTf163U9ueSMDym2C2Q/2EX0MMHGweBX+hfSpvievSi6WWWcdG f/K07I1RXNwNkB0zMuDgdrydajzFDviZWoaoR27p+Bh8TNMZfasxgGr3qOcbyDKh2FJ50WerPC2n UFW5HB8YMOKD5MERmyqBsk+lhHRYVpp+ATgbsFETfyS+C8p05MBxJJQ24XhMgFUzqySG2fPK1gCj qEsw4Q/lrv2Vb23GLmDXr6mnyXHg9YOq0IWs+zuB5xnZomrt/2sle2TQ6sZ5tEn5YuK+JbU4uhpM ZhKE+19SXSrh9J2tGXWEaKsUaKTPLi7BTDh3OOhk+x8LDXKl3LUaTkQwggS4MIIDoKADAgECAgId cTANBgkqhkiG9w0BAQUFADBcMQswCQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20x EzARBgNVBAsTCkZUUkQtQXNwaWMxHzAdBgNVBAMTFkZUUkQgQUMgb3BlcmF0aW9ubmVsbGUwHhcN MDQwNzI2MTMzODA3WhcNMDcwNzI2MTMzODA3WjCBoTELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZy YW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFTUElDMRgwFgYDVQQDEw9SZW5hdWQgTU9JR05B UkQxGDAWBgoJkiaJk/IsZAEBEwhSSUVNNjUxMTEwMC4GCSqGSIb3DQEJARYhcmVuYXVkLm1vaWdu YXJkQGZyYW5jZXRlbGVjb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQClchLywuea Vw1yziql8mDBZun+5SNe/X+fpNV267k9viFGhGLRTl2MALs2O2jw4+qN3q2UCFlWSbuUjs/g31RR lsZHC2yhJphwejKCJ4GpwEvcLh9F/Hg0w8XxPCanW2cH15ktuGv7CbI2rMXTPH0P6IO1zbaMhYgT pxAkK7ysxwIDAQABo4IBwDCCAbwwHQYDVR0OBBYEFMlbTWyq4IAj1uDG142eefcX9awqMB8GA1Ud IwQYMBaAFKeHuNCL9G/jwcDa7Y604KcQKfzYMIGSBgNVHR8EgYowgYcwR6BFoEOGQWh0dHA6Ly9s dWNpZmVyLnJkLmZyYW5jZXRlbGVjb20uZnIvcmV2b3F1ZXMvY3Jsb3BlcmF0aW9ubmVsbGUuY3Js MDygOqA4hjZodHRwOi8vcGtpLWwucmQuZnJhbmNldGVsZWNvbS5mci9jcmxvcGVyYXRpb25uZWxs ZS5jcmwwDgYDVR0PAQH/BAQDAgbAMCkGA1UdJQQiMCAGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYB BAGCNxQCAjARBglghkgBhvhCAQEEBAMCBaAwWgYDVR0RBFMwUaAsBgorBgEEAYI3FAIDoB4MHG1v aWduYXJlQHJkLmZyYW5jZXRlbGVjb20uZnKBIXJlbmF1ZC5tb2lnbmFyZEBmcmFuY2V0ZWxlY29t LmNvbTA7BglghkgBhvhCAQ0ELhYsQ2VydGlmaWNhdCBkZSBTaWduYXR1cmUgcG91ciBSZW5hdWQg TU9JR05BUkQwDQYJKoZIhvcNAQEFBQADggEBAKbsVcoteE6rKkIFuZUmlIu/E9Nh7s7Hy9ncjDLb VSi/W+XbpPdI4PxGCcgiUFI8wCNfVf8RnqX8pfeT/1fJubWC4uYLfWWHJLF5i98TYntFLM+oFEfY uIV20+Q26vbjbLkqXJf5ZRAjexfbjk6X3JiPjZn2x4e60Kn2c8QQGpnQsmfxnPUL3lTUcWlJ5rQu Uu0W8bv6IY7SnZJU6aTxoiTFFoJZze/8JtP7m+DDpyN5ozBTQPS8uyWUh0aNwl9v/GW7PT3bDX+u nSM/rN2vT7NqrKcw+o1EaEEpPGFg3BpqCBDgNnomgJXgUsEIgUxEKuWleTEu8LCQXeAUecSLGYUx ggK6MIICtgIBATBiMFwxCzAJBgNVBAYTAkZSMRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTETMBEG A1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRSRCBBQyBvcGVyYXRpb25uZWxsZQICHXEwCQYF Kw4DAhoFAKCCAa4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYw NTI4MjA0MjM2WjAjBgkqhkiG9w0BCQQxFgQUHVolnvtNdMoSN+BIyxBU4ctOZ4IwZwYJKoZIhvcN AQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwcQYJKwYBBAGCNxAEMWQwYjBc MQswCQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQXNw aWMxHzAdBgNVBAMTFkZUUkQgQUMgb3BlcmF0aW9ubmVsbGUCAh1yMHMGCyqGSIb3DQEJEAILMWSg YjBcMQswCQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQt QXNwaWMxHzAdBgNVBAMTFkZUUkQgQUMgb3BlcmF0aW9ubmVsbGUCAh1yMA0GCSqGSIb3DQEBAQUA BIGAcwVBDoMbtJk2ZnUflDcfrmT5H8625m4Zhlb/lcMurvkh8arJp9nxi+pjMq68yvG6V0CsPITK hqSFc/QYejF6pJblN0laAf9uZiplXpYeKCZ1DQz/KKy7DiozdbC3J9UtP77Hizv08/ZelMnUAQex DU+LQP5keoOZmJYaa8pFw+EAAAAAAAA= ------=_NextPart_000_0014_01C682A8.044A90B0-- --===============1241181122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1241181122==-- From mpls-bounces@lists.ietf.org Mon May 29 17:29:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkpCk-0003SB-PG; Mon, 29 May 2006 17:23:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkpCj-0003Py-7w for mpls@ietf.org; Mon, 29 May 2006 17:23:13 -0400 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkpCg-0003MQ-UK for mpls@ietf.org; Mon, 29 May 2006 17:23:13 -0400 Received: from c-68-83-214-31.hsd1.va.comcast.net ([68.83.214.31] helo=[192.168.2.104]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1FkpCJ-0003Sp-IX; Mon, 29 May 2006 23:22:52 +0200 Message-ID: <447B6624.9010307@pi.se> Date: Mon, 29 May 2006 23:22:44 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Loa Andersson References: <4465B972.4090305@pi.se> In-Reply-To: <4465B972.4090305@pi.se> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mpls@ietf.org, Bill Fenner , ccamp , Ross Callon Subject: [mpls] Closed: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org All, this closes the working group Last Call on draft-ietf-mpls-rsvp-te-p2mp-05.txt Could the authors/editors please summarize the comments and document how they will be addressed. Loa and George Loa Andersson wrote: > Working Group, > > this initiates a two week working group last call on > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > please send comments to the MPLS working group mailling > list and/or working co-chairs. > > The last call ends eob May 28th. > > The ccamp mailing list copied as this is a work that has > an overlap between the working groups. > > Loa and George > > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue May 30 11:52:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl6Ru-0006u6-6z; Tue, 30 May 2006 11:48:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl6Rs-0006sC-BJ for mpls@ietf.org; Tue, 30 May 2006 11:48:00 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl6Rr-0007dp-22 for mpls@ietf.org; Tue, 30 May 2006 11:48:00 -0400 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 30 May 2006 08:47:59 -0700 X-IronPort-AV: i="4.05,190,1146466800"; d="scan'208"; a="550363080:sNHT27982372" Received: from sapphire.juniper.net ([172.17.28.108]) by beta.jnpr.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 08:47:58 -0700 Date: Tue, 30 May 2006 08:47:58 -0700 (PDT) From: Rahul Aggarwal To: Loa Andersson Subject: Re: [mpls] Closed: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt In-Reply-To: <447B6624.9010307@pi.se> Message-ID: <20060530084714.G76632@sapphire.juniper.net> References: <4465B972.4090305@pi.se> <447B6624.9010307@pi.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 30 May 2006 15:47:58.0084 (UTC) FILETIME=[6C70DC40:01C68400] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Bill Fenner , mpls@ietf.org, Ross Callon , ccamp X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi Loa, On Mon, 29 May 2006, Loa Andersson wrote: > All, > > this closes the working group Last Call on > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > Could the authors/editors please summarize the comments and > document how they will be addressed. > We will plan to do this by end of the week. Thanks, Editors > Loa and George > > > > Loa Andersson wrote: > > Working Group, > > > > this initiates a two week working group last call on > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > please send comments to the MPLS working group mailling > > list and/or working co-chairs. > > > > The last call ends eob May 28th. > > > > The ccamp mailing list copied as this is a work that has > > an overlap between the working groups. > > > > Loa and George > > > > > > > > > -- > Loa Andersson > > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue May 30 15:59:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAIR-00082i-2k; Tue, 30 May 2006 15:54:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlAIE-0007xN-5k for mpls@ietf.org; Tue, 30 May 2006 15:54:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlAIE-0007b9-4N for mpls@ietf.org; Tue, 30 May 2006 15:54:18 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlA4K-0001Jc-7G for mpls@ietf.org; Tue, 30 May 2006 15:39:58 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 30 May 2006 12:39:55 -0700 X-IronPort-AV: i="4.05,190,1146466800"; d="scan'208"; a="285446527:sNHT32848850" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k4UJdti2024522; Tue, 30 May 2006 12:39:55 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4UJdZcp014285; Tue, 30 May 2006 12:39:55 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 May 2006 15:39:54 -0400 Received: from SwallowPB.local ([161.44.74.167]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 May 2006 15:39:53 -0400 Received: from cisco.com (localhost [127.0.0.1]) by SwallowPB.local (Postfix) with ESMTP id 8C2331FAB15; Tue, 30 May 2006 15:40:49 -0400 (EDT) To: Yakov Rekhter In-reply-to: Your message of "Wed, 24 May 2006 14:28:11 PDT." <200605242128.k4OLSB506950@merlot.juniper.net> From: George Swallow X-Mailer: MH-E 7.4.3; nmh 1.1-RC3; GNU Emacs 21.2.1 Date: Tue, 30 May 2006 15:40:49 -0400 Message-Id: <20060530194049.8C2331FAB15@SwallowPB.local> X-OriginalArrivalTime: 30 May 2006 19:39:54.0029 (UTC) FILETIME=[D2FD8DD0:01C68420] DKIM-Signature: a=rsa-sha1; q=dns; l=1292; t=1149017995; x=1149881995; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:George=20Swallow=20 |Subject:Re=3A=20working=20group=20last=20call=20on=20draft-ietf-mpls-rsvp-te-p2m p-05.txt=20; X=v=3Dcisco.com=3B=20h=3DwFMJg3I82ycME///RDDbDBO07Mc=3D; b=awGqbJ0mEWD20IRdiItzOpbP9l3g5COBKIP8VmmR5V+gZncbEhkw3JVCBpn8vokRV8D/TCrL A7vHg9SNbousbSh/eEvDw5UajHiyA62N3+u0Ap+7LMYsAmDb/IfFiRAh; Authentication-Results: sj-dkim-7.cisco.com; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mpls@ietf.org, Bill Fenner , ccamp , Ross Callon Subject: [mpls] Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > What are exactly the (practical) problems with carrying the root > node IP address both in the Extended Tunnel ID and in the Tunnel > Sender Address fields ? If you wish to use bypass FRR, you will do exactly this. The Extended Tunnel ID is meant to provide a means of making the Session globally unique. An intermediate node that wishes to merge back into an existing tunnel over a bypass tunnel uses it's own IP address in the sender field and the existant Session Object. If the session object were not unique then this would be very hit or miss! Personally I would like to see the text with ^^^^ removed from the draft. It was carried over from 3209 which was written prior to the FRR draft. > A 32-bit identifier used in the SESSION that remains constant > over the life of the tunnel. Normally set to all zeros. ^^^^^^^^^^^^^^^^^^^^^^^^^ If we ever get around to pushing 3209 to Draft Standard I'll take it out of there as well. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Tue May 30 22:29:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlGMi-0001CV-DQ; Tue, 30 May 2006 22:23:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlGMg-0001CQ-Ej for mpls@ietf.org; Tue, 30 May 2006 22:23:18 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlGMe-0001PB-38 for mpls@ietf.org; Tue, 30 May 2006 22:23:18 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0300F75Z2GKF@szxga02-in.huawei.com> for mpls@ietf.org; Wed, 31 May 2006 10:32:40 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0300EHOZ2FLR@szxga02-in.huawei.com> for mpls@ietf.org; Wed, 31 May 2006 10:32:39 +0800 (CST) Received: from l48253 ([10.110.114.116]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J03009FAYTVMJ@szxml04-in.huawei.com> for mpls@ietf.org; Wed, 31 May 2006 10:27:33 +0800 (CST) Date: Wed, 31 May 2006 10:17:15 +0800 From: liushuying To: ice@cisco.com, ina@juniper.net, jeanlouis.leroux@francetelecom.com Message-id: <003b01c68458$55dd6900$74726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: mpls@ietf.org Subject: [mpls] about upstream LSR change and load-balance in P2MP LSP X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1248941554==" Errors-To: mpls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1248941554== Content-type: multipart/alternative; boundary="Boundary_(ID_cF5pX85KIxRd1njEwK2XnA)" This is a multi-part message in MIME format. --Boundary_(ID_cF5pX85KIxRd1njEwK2XnA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgYWxsLA0KICAgQXQgSUVURiA2NSBpbiBkYWxsYXMsIHdlIGFsbCBtYWRlIHByZXNlbnRhdGlv bnMuIEkgcHJvcG9zZWQgYSBtZWNoYW5pc20gdG8gbWluaW1pemUgcGFja2V0IGxvc3MgZHVyaW5n IHVwc3RyZWFtIExTUiBjaGFuZ2UgaW4gUDJNUC4gSW4gY2FzZSBvZiBuZXR3b3JrIGZhaWx1cmUs IEkgd291bGQgc2ltcGxpZnkgdGhlIHByb2Nlc3Mgb2YgcmVjb25uZWN0aW5nIHRoZSBQMk1QIExT UCB0byBtaW5pbWl6ZSBwYWNrZXQgbG9zcy4gSW4gY2FzZSBvZiByb3V0ZSBjaGFuZ2luZywgdGhl IG1haW4gaWRlYSBvZiB0aGUgbWVjaGFuaXNtIGlzICdtYWtlIGJlZm9yZSBicmVhaycuIEluIHlv dXIgcHJlc2VudGF0aW9uLCB5b3UgbWVudGlvbmVkIHRoYXQgeW91IHdvdWxkIGRvIHNvbWUgd29y ayB0byBtaW5pbWl6ZSBwYWNrZXQgbG9zcyBkdXJpbmcgdXBzdHJlYW0gTFNSIGNoYW5nZS4NCiAg IEluIG15IG9waW5pb24sIGluIGNhc2Ugb2Ygcm91dGUgY2hhbmdpbmcsICdtYWtlIGJlZm9yIGJy ZWFrJyBtYXkgYmUgYSBwcmVmZXJhYmxlIG1lY2hhbmlzbSwgYnV0IGl0IHNob3VsZCBiZSBzaW1w bGUuIEluIGNhc2Ugb2YgbmV0d29yayBmYWlsdXJlLCB0aGVyZSBtYXkgYmUgdHdvIHdheXMgdG8g bWluaW1pemUgcGFja2V0IGxvc3MuIE9uZSB3YXkgaXMgdG8gZG8gc29tZSB3b3JrIGJlZm9yZSB0 aGUgbmV0d29yayBmYWlsdXJlLCBsaWtlICdmcnInLCBzbyB3ZSBjb3VsZCBsZWFybiBzb21lIG1l dGhvZHMgZnJvbSBJUGZyciBhbmQgcmZjNDA5MC4gdGhlIG90aGVyIHdheSBpcyB0byBkbyBzb21l IHdvcmsgYWZ0ZXIgZmFpbHVyZSwgbGlrZSB0aGUgbWV0aG9kcyBpbiBvdXIgZHJhZnRzLCBidXQg aXQgc2hvdWxkIGJlIHNpbXBsZSBhbmQgbWluaW1pemUgdGhlIHRpbWUgb2YgdGFmZmljIGRpc3J1 cHRpb24uDQogICBJIGV4cGVjdCBzb21lIGNvbW1lbnRzIG9uIG15IGRyYWZ0KGRyYWZ0LWxpdS1t cGxzLWxkcC1wMm1wLXJlcm91dGUtMDAudHh0KSBmcm9tIHlvdS4gSSBhbHNvIGV4cGVjdCB0byBk aXNjdXNzIHRoaXMgd29yayB3aXRoIHlvdS4gDQogIA0KICAgVGhlcmUgaXMgYW5vdGhlciBhdHRl bnRpb24gb24gbG9hZC1iYWxhbmNlIGFtb25nIGEgc2V0IG9mIGNhbmRpZGF0ZSB1cHNydGVhbSBM U1IuIHdlIGNhbiBtYWtlIHNvbWUgZXh0ZW5zaW9ucyB0byB1cHN0cmVhbSBsYWJlbCBhc3NpZ25l ZCBtZWNoYW5pc20sIHdlIGNhbiBidWlsZCBhIFAyTVAgTFNQIHdoaWNoIHRyYXZlcnNlcyBldmVy eSBjYW5kaWRhdGUgdXBzdHJlYW0gTFNSLCBldmVyeSBzdWItTFNQIHdoaWNoIHRyYXZlcnNlcyBv bmUgTFNSIG9mIHRob3NlIGNhbmRpZGF0ZSB1cHN0cmVhbSBMU1JzIHdpbGwgdGVybWluYXRlIGF0 IHRoZSBSZW5kZXp2b3VzIFBvaW50IExTUi4gVGhlIFJlbmRlenZvdXMgUG9pbnQgTFNSIGlzIGlu IGNoYXJnZSBvZiBzZWxlY3RpbmcgdGhlIGxvYWQtYmFsYW5jZSBtZXRob2RzLCBzdWNoIGFzIHBl ci1mbG93L3Blci1wYWNrZXQsIEVDTVAvV0NNUC4NCiAgIGV4cGVjdGluZyBjb21tZW50cyBmcm9t IHlvdS4NCiAgIA0KVGhhbmtzIA0KU2h1eWluZyBMaXUNCkh1YVdlaSBCbGQuLCBOby4zIFhpbnhp IFJkLiwgICANClNoYW5nLURpIEluZm9ybWF0aW9uIEluZHVzdHJ5IEJhc2UsICAgICAgICAgICAg IA0KSGFpLURpYW4gRGlzdHJpY3QgQmVpamluZyBQLlIuIENoaW5hDQpaSVCjujEwMDA4NSANCiA= --Boundary_(ID_cF5pX85KIxRd1njEwK2XnA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI4NzMiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IaSBhbGwsPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7QXQmbmJzcDtJRVRGIDY1 IGluIGRhbGxhcywgd2UgYWxsIG1hZGUgDQpwcmVzZW50YXRpb25zLiBJIHByb3Bvc2VkIGEgbWVj aGFuaXNtIHRvIG1pbmltaXplIHBhY2tldCBsb3NzIGR1cmluZyB1cHN0cmVhbSANCkxTUiBjaGFu Z2UgaW4gUDJNUC4gSW4gY2FzZSBvZiBuZXR3b3JrIGZhaWx1cmUsJm5ic3A7SSZuYnNwO3dvdWxk IHNpbXBsaWZ5IHRoZSANCnByb2Nlc3MmbmJzcDtvZiByZWNvbm5lY3RpbmcgdGhlIFAyTVAgTFNQ IHRvIG1pbmltaXplIHBhY2tldCBsb3NzLiBJbiBjYXNlIG9mIA0Kcm91dGUgY2hhbmdpbmcsIHRo ZSBtYWluIGlkZWEgb2YgdGhlIG1lY2hhbmlzbSZuYnNwO2lzICdtYWtlIGJlZm9yZSANCmJyZWFr Jy4mbmJzcDtJbiB5b3VyIHByZXNlbnRhdGlvbiwgeW91Jm5ic3A7bWVudGlvbmVkIHRoYXQgeW91 IHdvdWxkIGRvIHNvbWUgDQp3b3JrIHRvJm5ic3A7bWluaW1pemUgcGFja2V0IGxvc3MgZHVyaW5n IHVwc3RyZWFtIExTUiBjaGFuZ2UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5i c3A7Jm5ic3A7Jm5ic3A7SW4gbXkgb3BpbmlvbiwgaW4gY2FzZSBvZiByb3V0ZSBjaGFuZ2luZywg DQonbWFrZSBiZWZvciBicmVhaycgbWF5IGJlJm5ic3A7YSBwcmVmZXJhYmxlIG1lY2hhbmlzbSwg YnV0IGl0Jm5ic3A7c2hvdWxkIGJlIA0Kc2ltcGxlLiBJbiBjYXNlIG9mIG5ldHdvcmsgZmFpbHVy ZSwgdGhlcmUgbWF5IGJlIHR3byB3YXlzIHRvIG1pbmltaXplIHBhY2tldCANCmxvc3MuIE9uZSB3 YXkgaXMgdG8mbmJzcDtkbyBzb21lIHdvcmsmbmJzcDtiZWZvcmUgdGhlJm5ic3A7bmV0d29yayBm YWlsdXJlLCANCmxpa2UmbmJzcDsnZnJyJywgc28gd2UmbmJzcDtjb3VsZCBsZWFybiBzb21lIG1l dGhvZHMgZnJvbSBJUGZyciBhbmQgcmZjNDA5MC4gdGhlIA0Kb3RoZXIgd2F5IGlzIHRvIGRvIHNv bWUgd29yayBhZnRlciBmYWlsdXJlLCBsaWtlIHRoZSBtZXRob2RzIGluIG91ciBkcmFmdHMsIGJ1 dCANCml0IHNob3VsZCBiZSBzaW1wbGUgYW5kIG1pbmltaXplIHRoZSB0aW1lIG9mIHRhZmZpYyBk aXNydXB0aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyBJ IGV4cGVjdCBzb21lIGNvbW1lbnRzJm5ic3A7b24gbXkgDQpkcmFmdChkcmFmdC1saXUtbXBscy1s ZHAtcDJtcC1yZXJvdXRlLTAwLnR4dCkgZnJvbSB5b3UuIEkgYWxzbyBleHBlY3QgdG8gZGlzY3Vz cyANCnRoaXMgd29yayB3aXRoIHlvdS48L0ZPTlQ+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj4mbmJzcDsmbmJzcDsgVGhlcmUgaXMgYW5vdGhlciBhdHRlbnRpb24gb24gbG9hZC1i YWxhbmNlIGFtb25nIA0KYSBzZXQgb2YgY2FuZGlkYXRlIHVwc3J0ZWFtIExTUi4gd2UgY2FuIG1h a2Ugc29tZSBleHRlbnNpb25zIHRvJm5ic3A7dXBzdHJlYW0gDQpsYWJlbCBhc3NpZ25lZCZuYnNw O21lY2hhbmlzbSwgd2UgY2FuIGJ1aWxkIGEmbmJzcDtQMk1QIExTUCZuYnNwO3doaWNoIA0KdHJh dmVyc2VzJm5ic3A7ZXZlcnkgY2FuZGlkYXRlIHVwc3RyZWFtIExTUiwgZXZlcnkgc3ViLUxTUCB3 aGljaCB0cmF2ZXJzZXMgb25lIA0KTFNSIG9mIHRob3NlIGNhbmRpZGF0ZSB1cHN0cmVhbSBMU1Jz IHdpbGwgdGVybWluYXRlIGF0IDxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAx MC41cHQ7IExJTkUtSEVJR0hUOiAxNTAlOyBGT05ULUZBTUlMWTogy87M5TsgbXNvLWJpZGktZm9u dC1zaXplOiAxMC4wcHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsg bXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1z by1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+dGhlIA0KUmVuZGV6dm91cyBQb2ludCBMU1IuIDxTUEFO IGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMC41cHQ7IExJTkUtSEVJR0hUOiAxNTAl OyBGT05ULUZBTUlMWTogy87M5TsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQ7IG1zby1iaWRp LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVT OyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+ VGhlIA0KUmVuZGV6dm91cyBQb2ludCBMU1IgaXMgaW4gY2hhcmdlIG9mIHNlbGVjdGluZyB0aGUg bG9hZC1iYWxhbmNlIG1ldGhvZHMsIHN1Y2ggYXMgDQpwZXItZmxvdy9wZXItcGFja2V0LCBFQ01Q L1dDTVAuPC9TUEFOPjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48U1BB TiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTogMTAuNXB0OyBMSU5FLUhFSUdIVDogMTUw JTsgRk9OVC1GQU1JTFk6IMvOzOU7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0OyBtc28tYmlk aS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1V UzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0Ei PjxTUEFOIA0KbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULVNJWkU6IDEwLjVwdDsgTElORS1IRUlH SFQ6IDE1MCU7IEZPTlQtRkFNSUxZOiDLzszlOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdDsg bXNvLWJpZGktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYW5zaS1sYW5ndWFn ZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6 IEFSLVNBIj4mbmJzcDsmbmJzcDsgDQpleHBlY3RpbmcgY29tbWVudHMgZnJvbSB5b3UuPC9TUEFO PjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsgPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmtzJm5ic3A7PEJSPlNodXlpbmcgTGl1 PC9GT05UPjwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkh1YVdlaSBCbGQuLCBOby4z IFhpbnhpIFJkLiwmbmJzcDsmbmJzcDsgPEJSPlNoYW5nLURpIA0KSW5mb3JtYXRpb24gSW5kdXN0 cnkgDQpCYXNlLCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjxCUj5IYWktRGlhbiBEaXN0cmljdCBCZWlqaW5n IFAuUi4gQ2hpbmE8QlI+WklQo7oxMDAwODUmbmJzcDs8L0ZPTlQ+PC9ESVY+PEZPTlQgDQpzaXpl PTM+Jm5ic3A7PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_cF5pX85KIxRd1njEwK2XnA)-- --===============1248941554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls --===============1248941554==-- From mpls-bounces@lists.ietf.org Wed May 31 11:11:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSHK-0005vU-NA; Wed, 31 May 2006 11:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSAw-0004RB-Gd for mpls@ietf.org; Wed, 31 May 2006 10:59:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRwX-0001s1-PX for mpls@ietf.org; Wed, 31 May 2006 10:45:08 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 07:44:39 -0700 X-IronPort-AV: i="4.05,193,1146466800"; d="scan'208"; a="286120687:sNHT4722811518" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4VEidQV031705; Wed, 31 May 2006 07:44:39 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4VEidku025745; Wed, 31 May 2006 10:44:39 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 May 2006 10:44:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 May 2006 10:44:38 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcZ/R9v0YpaSjq2CSj6YNicpNTtUbwFb2knA From: "Zafar Ali \(zali\)" To: "Yakov Rekhter" , "Loa Andersson" X-OriginalArrivalTime: 31 May 2006 14:44:39.0271 (UTC) FILETIME=[BE95BF70:01C684C0] DKIM-Signature: a=rsa-sha1; q=dns; l=2644; t=1149086679; x=1149950679; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20\(zali\)=22=20 |Subject:RE=3A=20working=20group=20last=20call=20on=20draft-ietf-mpls-rsvp-te-p2m p-05.txt=20; X=v=3Dcisco.com=3B=20h=3Ds2QdIjLYxjuMwjYE13iS3QN8AeY=3D; b=OvWUVFPHo4d3vBy7Ihd/pYGvkC5+0fcO8DMzhf7ZgtAXWFtc2d0O939jk324kN61S79ZDKtz NxjpWCkNj7dwt7TP1EkQ2hEwLvxGoO1ZpHaUGzBUIaYyIwYTxa9jw2WF; Authentication-Results: sj-dkim-1.cisco.com; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: mpls@ietf.org, Bill Fenner , ccamp , Ross Callon Subject: [mpls] RE: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Yakov Rekhter > Sent: Wednesday, May 24, 2006 11:35 AM > To: Loa Andersson > Cc: mpls@ietf.org; ccamp; George Swallow (swallow); Adrian=20 > Farrel; Deborah Brungard; Ross Callon; Bill Fenner > Subject: Re: working group last call on=20 > draft-ietf-mpls-rsvp-te-p2mp-05.txt=20 >=20 > Loa and George, >=20 > > Working Group, > >=20 > > this initiates a two week working group last call on=20 > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > >=20 > > please send comments to the MPLS working group mailling list and/or=20 > > working co-chairs. > >=20 > > The last call ends eob May 28th. > >=20 > > The ccamp mailing list copied as this is a work that has an overlap=20 > > between the working groups. > >=20 > > Loa and George >=20 > Few observations and suggestions... >=20 > (a) tuple is both necessary=20 > and sufficient to unambiguously identify a P2MP Tunnel. >=20 Yakov, et al I would ask to add extended tunnel ID as part of this, unless we force is to be equal to the Ingress LSR IP address (at least in P2MP draft), as suggested by George.=20 > (b) Further is both=20 > necessary and sufficient to identify a P2MP LSP. Following the above comment, a FEC for P2MP is identified by .=20 Thanks Regards... Zafar=20 >=20 > Therefore I would suggest that draft-ietf-mpls-rsvp-te-p2mp-05.txt > should say the following: >=20 > 1. A P2MP tunnel is identified by a tuple index>, where the index value is unique within the scope of the IP > address of the root node. The P2MP tunnel identifier node IP address, index> is unique within the same scope as=20 > the root node IP address. >=20 > 2. Both the Extended Tunnel ID and the Tunnel Sender Address=20 > fields carry the root node IP address (both fields carry the=20 > same value). > The index is carried in the P2MP ID. >=20 > 3. Tunnel ID field should be set to all zeros, and be ignored=20 > on receipt. >=20 > 4. A P2MP LSP is identified by a combination of tunnel=20 > identifier (), and LSP ID. >=20 > With this in mind sections 4.1, 4.2, 19.1 and 19.2 should be=20 > modified to clarify the following: >=20 > (a) SESSION identifier; > (b) semantics of Extended Tunnel ID; semantics of the P2MP ID; > (c) semantics of the Tunnel ID IP address in the SENDER_TEMPLATE. >=20 > Yakov. >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 31 11:11:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSHL-0005vg-Fx; Wed, 31 May 2006 11:06:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSAw-0004RB-Kd for mpls@ietf.org; Wed, 31 May 2006 10:59:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlRwQ-0001s1-Jo for mpls@ietf.org; Wed, 31 May 2006 10:45:01 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 31 May 2006 07:44:35 -0700 X-IronPort-AV: i="4.05,193,1146466800"; d="scan'208"; a="286120623:sNHT7905866668" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k4VEiYfT020751; Wed, 31 May 2006 07:44:34 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4VEiXku025711; Wed, 31 May 2006 10:44:33 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 May 2006 10:44:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 May 2006 10:44:33 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt Thread-Index: AcaCdrAJDW5rhHgmRqe9wJN4uwqxQgCPwGEg From: "Zafar Ali \(zali\)" To: "Yakov Rekhter" , "Adrian Farrel" X-OriginalArrivalTime: 31 May 2006 14:44:33.0834 (UTC) FILETIME=[BB5820A0:01C684C0] DKIM-Signature: a=rsa-sha1; q=dns; l=3534; t=1149086674; x=1149950674; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=22Zafar=20Ali=20\(zali\)=22=20 |Subject:RE=3A=20working=20group=20last=20call=20on=20draft-ietf-mpls-rsvp-te-p2m p-05.txt=20; X=v=3Dcisco.com=3B=20h=3Dz4HV9KCTBmcbjG78hTn1772rpGI=3D; b=lv9/7NPEJ8zlf8JfH4i5L9n5v4je6xklQqf3ebhH+UhL/RKLs3WGpdZGkLTEnrT1rtqvsjim ck61ChFC4FScbqJECpkHNX4rT/aLGb9ChbhFqoo43OD0MbbBNycfeIhS; Authentication-Results: sj-dkim-2.cisco.com; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: mpls@ietf.org, Bill Fenner , ccamp , Ross Callon Subject: [mpls] RE: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Yakov Rekhter > Sent: Sunday, May 28, 2006 12:47 PM > To: Adrian Farrel > Cc: Loa Andersson; mpls@ietf.org; ccamp; George Swallow=20 > (swallow); Deborah Brungard; Ross Callon; Bill Fenner > Subject: Re: working group last call on=20 > draft-ietf-mpls-rsvp-te-p2mp-05.txt=20 >=20 > Adrian, >=20 > > >> > Few observations and suggestions... > > >> > > > >> > (a) tuple is both=20 > necessary and=20 > > >> > sufficient to unambiguously identify a P2MP Tunnel. > > >> > > > >> > (b) Further is both=20 > > >> > necessary and sufficient to identify a P2MP LSP. > > >> > > >> Clearly these two statements depend on the definition of=20 > "P2MP ID"=20 > > >> as you pointed out below. > > >> > > >> As the I-D says... > > >> The P2MP ID provides an identifier for the set of=20 > destinations of the > > >> P2MP TE Tunnel. > > > > > > Does this identifier have a globally unique scope, or=20 > only the scope=20 > > > of the root ? If the former, then what are the procedures for=20 > > > assigning such identifiers ? > >=20 > > Good questions. > >=20 > > Presumably, if we want to retain the concept of Session (which=20 > > appeared to be the case in discussion amongst the authors) then the=20 > > P2MP ID has to have global scope. > >=20 > > Not sure whether the procedures for assigning the=20 > identifiers has to=20 > > be in scope of this document. The procedure for assigning=20 > IP addresses=20 > > to P2P tunnel destinations does not appear to be in scope=20 > for RFC3209. > >=20 > > It is worth looking at RFC4461 for more information on the P2MP ID.=20 > > This gives us: > > A unique identifier of a P2MP TE LSP, which is=20 > constant for the > > whole LSP regardless of the number of branches and/or leaves. > > which is not as hepful as it could have been :-( > >=20 > > I think you are right to try to flush this sort of thing out now=20 > > rather than let us get into the ambiguity mess that we got=20 > to with RFC3209. >=20 > There is a difference between IP addresses used for P2P=20 > tunnel destinations, and identifiers used for P2MP ID. The=20 > former are unicast addresses (each address identifies a=20 > *single* node/interface). > The latter are *group* addresses (each address identifies a=20 > *group* of nodes). There are well-established procedures for=20 > assigining unicast IP addresses, but not for group addresses. >=20 > If some folks would like to retain the ability of the P2MP ID=20 > to have global scope, then at the minimum the spec (a) should=20 > have this as *an option*, with P2MP ID having the scope of=20 > the root node being another option documented in the spec,=20 > and (b) spell out the procedures for assigining such globally=20 > unique P2MP IDs. Yakov, Adrian, et al I think global scoping will be a bad idea. Furthermore, we cannot force it to come from multicast IP address space. So Ingress node scoping is quite obvious and IMHO suffices.=20 I also don't see an issue in sharing 2^16 space for both P2MP and P2P tunnels. Does anyone see an issue here? I think having said that P2MP ID has Ingress node scope, an implementation MAY choose to make P2MP ID =3D tunnel ID, or has flexibility otherwise.=20 My $0.02.=20 Thanks Regards... Zafar =20 >=20 > Yakov. >=20 _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 31 16:31:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlXGU-0001KD-0X; Wed, 31 May 2006 16:26:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlXGR-0001BC-Qz for mpls@lists.ietf.org; Wed, 31 May 2006 16:25:59 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlXGO-0003wU-FO for mpls@lists.ietf.org; Wed, 31 May 2006 16:25:59 -0400 X-VirusChecked: Checked X-Env-Sender: luyuanfang@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1149106741!10593772!10 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 28203 invoked from network); 31 May 2006 20:19:15 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-9.tower-121.messagelabs.com with SMTP; 31 May 2006 20:19:15 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 4479CA7F000550D7; Wed, 31 May 2006 16:19:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 May 2006 15:19:15 -0500 Message-ID: In-Reply-To: <200605301117.k4UBHNlO000737@flph015.enaf.ffdc.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "Advances in VPNs": Special Issue IEEE Comm. Mag. Thread-Index: AcaD2rHGbCXJ3wbhSHWr4x6nYvE8ewBE+OiA From: "Fang, Luyuan, ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Nasir Ghani Subject: [mpls] "Advances in VPNs": Special Issue IEEE Comm. Mag. X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Dear Colleagues, The IEEE Communications Magazine has just approved the publication of a Feature Topic=20 issue on "Advances in Virtual Private Networks (VPNs)." The CFP is attached below, We invite those working in this area to consider sending in their contributions.=20 And, we appreciate your forwarding this CFP on to your colleagues and associates. If you intend to submit a paper for this special issue, please do drop one of the=20 Guest Editors a note, so that we can plan the special issue. We look forward to your participation! Best regards, - Vishal, Nasir, and Luyuan ***************************************************************** *************************** IEEE Communications Magazine Feature Topic on "Advances in Virtual Private Networks? VPN's have become one of the biggest success stories of the recent years and related service offerings represent a key area of expansion and revenue generation for new and incumbent service providers worldwide. This is particularly important given the ongoing decline in legacy service revenues, such as long distance voice, private line, etc. Whether it be AT&T in the US, France Telecom in Europe, BSNL in India, or NTT in Japan, each one of these network providers is now offering managed VPN services to both large and small and medium enterprise (SME) customers. As this market continues to expand, VPN paradigms are evolving to deliver new levels of capability and attracting wider interest from the academic research community. Along these lines, the purpose of this special issue is to present the IEEE Communications Magazine readership with the latest advances in the overall VPN area, i.e., Layers 1-3. Broadly, this will include issues pertaining to standards and architectures, resource allocation/traffic engineering algorithms, real-world deployment experiences, and emerging challenges. Indeed, these contemporary issues are of interest to many in the networking community, including carriers providing VPN services, standards organizations (IETF, ITU-T), and academic researchers. =20 In particular, some of the main topics include (but are not necessarily limited to) the following: * VPN standards for architectures and service models as developed in the IETF and ITU-T. Commensurate evolutions in networking protocol and equipment requirements. * Resource provisioning and QoS support schemes for Layers 1-3 VPN. =20 Current state-of-the-art in QoS provisioning in IP/MPLS-based carrier VPN services. * VPN topology overlay design and traffic engineering considerations. =20 Multi-area/domain VPN design and issues. * Routing and signalling protocols considerations for VPN. =20 Related implementations in distributed, centralized, and hybrid control environments along with scalability issues. * VPN service survivability and reliability schemes for Layers 1, 2, and 3.=20 Feasibility of dedicated and/or shared resource models. * Security and operations management for Layer 1/2/3 VPN services. =20 Including topics such as authentication, encryption, key management, control plane security. * Infrastructure virtualization via Layer 1 VPN (circuit-switched), comparisons with capabilities and scope of Layer 2 and 3 VPN (packet switched) services. * Business models for deploying VPN services and the experience of enterprise customers and carriers in deploying the different types of VPN services. Comparisons versus traditional private line services. * Migration strategies between legacy Layer 2 VPN and IP/MPLS Layer 3 VPN, including impacts and requirements for carriers and end-user clients.=20 * Current research developments in various aspects of VPN development, analysis, and deployment. Submission Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for clarity and grammatical accuracy, and will be copyedited according to the Magazine's style. Mathematical equations should not be used (in justified cases up to three=20 simple equations could be allowed, provided there is consent of the Guest=20 Editor; more than three equations require permission from the Editor-in-Chief).=20 Articles should have no more than 4,500 words, no more than 6 tables/figures,=20 and no more than 15 references. Guidelines for prospective authors can be found=20 on-line at http://www.comsoc.org/pubs/commag/sub_guidelines.html. Please submit no=20 later than 15 September 2006. Accepted papers will also be included in=20 Communications Interactive (CI), the online version of Communications=20 Magazine. Manuscript Due: 15 September 2006 Acceptance Notification: 15 December 2006 Final Manuscript Due: 31 January 2007 Publication Date: April 2007 Guest Editors Vishal Sharma, Metanoia, Inc. (v.sharma@ieee.org) Nasir Ghani, Tennesse Tech. University (nghani@tntech.edu) Luyuan Fang, AT&T Labs. (luyuanfang@att.com) On-line version of this CFP: http://www.metanoia-inc.com/AdvancesinVPNs_IEEECommMag_FT_CFP.htm _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls From mpls-bounces@lists.ietf.org Wed May 31 19:06:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZjN-0001xw-NR; Wed, 31 May 2006 19:04:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlZjM-0001xn-CR for mpls@lists.ietf.org; Wed, 31 May 2006 19:04:00 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlZjJ-0007TU-QC for mpls@lists.ietf.org; Wed, 31 May 2006 19:04:00 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FlZjE-0005rI-00 for mpls@lists.ietf.org; Thu, 01 Jun 2006 00:03:52 +0100 Received: from your029b8cecfe ([217.158.132.146] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 00:03:55 +0100 Message-ID: <0eda01c68506$7b0ebfe0$08849ed9@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 31 May 2006 23:59:09 +0100 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 31 May 2006 23:03:55.0693 (UTC) FILETIME=[7E00FDD0:01C68506] X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: "Thomas D. Nadeau" Subject: [mpls] Fw: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt X-BeenThere: mpls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mpls-bounces@lists.ietf.org Hi, We have put together a first (somewhat rough) stab at defining a MIB module for P2MP MPLS-TE and for describing how the existing MPLS-TE MIB modules are used in support of P2MP MPLS-TE. Hopefully the existence of this I-D will help the P2MP MPLS-TE solutions work along its path to becoming an RFC. Please review, comment, implement (!) and tell us what we have done wrong. Cheers, Adrian ----- Original Message ----- From: To: Sent: Wednesday, May 31, 2006 8:50 PM Subject: I-D ACTION:draft-farrel-mpls-p2mp-te-mib-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Point-to-Multipoint Multiprotocol Label > Switching (MPLS) Traffic Engineering (TE) > Management Information Base (MIB) module > Author(s) : A. Farrel, et al. > Filename : draft-farrel-mpls-p2mp-te-mib-00.txt > Pages : 36 > Date : 2006-5-31 > > This memo defines a portion of the Management Information Base > for use with network management protocols in the Internet community. > In particular, it describes managed objects for point-to-multipoint > Multiprotocol Label Switching-based traffic engineering. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-farrel-mpls-p2mp-te-mib-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-farrel-mpls-p2mp-te-mib-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-farrel-mpls-p2mp-te-mib-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls