From owner-ccamp@ops.ietf.org Mon Feb 2 00:52:03 2009 Return-Path: X-Original-To: ietfarch-ccamp-archive@core3.amsl.com Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7E63A6847 for ; Mon, 2 Feb 2009 00:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.333 X-Spam-Level: ** X-Spam-Status: No, score=2.333 tagged_above=-999 required=5 tests=[AWL=0.937, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGbqQFD10ZFs for ; Mon, 2 Feb 2009 00:52:03 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B1C6A3A6403 for ; Mon, 2 Feb 2009 00:51:59 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LTuPL-000KT1-HL for ccamp-data0@psg.com; Mon, 02 Feb 2009 08:43:55 +0000 Received: from [192.218.140.145] (helo=mx05.melco.co.jp) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LTuPH-000KSS-MU for ccamp@ops.ietf.org; Mon, 02 Feb 2009 08:43:53 +0000 Received: from mr05.melco.co.jp (mr05 [133.141.98.165]) by mx05.melco.co.jp (Postfix) with ESMTP id EAD0C5D1C9 for ; Mon, 2 Feb 2009 17:43:49 +0900 (JST) Received: from mr05.melco.co.jp (localhost [127.0.0.1]) by mr05.imss (Postfix) with ESMTP id C5C5AB101 for ; Mon, 2 Feb 2009 17:43:49 +0900 (JST) Received: from elgw.isl.melco.co.jp (unknown [133.141.13.130]) by mr05.melco.co.jp (Postfix) with ESMTP id AD5CAAB86 for ; Mon, 2 Feb 2009 17:43:49 +0900 (JST) Received: from eliswall.isl.melco.co.jp (eliswall.isl.melco.co.jp [10.74.245.38]) by elgw.isl.melco.co.jp (Postfix) with ESMTP id 95DFC31F3EB for ; Mon, 2 Feb 2009 17:43:49 +0900 (JST) Received: from eliswall.isl.melco.co.jp (localhost.localdomain [127.0.0.1]) by localhost.isl.melco.co.jp (Postfix) with ESMTP id 5A71422CB9C for ; Mon, 2 Feb 2009 17:43:49 +0900 (JST) Received: from LeakStopper182 (stopper2.isl.melco.co.jp [10.74.245.36]) by eliswall.isl.melco.co.jp (Postfix) with SMTP id 3F10922C039 for ; Mon, 2 Feb 2009 17:43:49 +0900 (JST) Received: (qmail 25327 invoked by uid 507); 2 Feb 2009 17:43:47 +0900 Received: from unknown (HELO ELL2SENO) (10.74.8.54) by 0 with SMTP; 2 Feb 2009 17:39:10 +0900 From: "Shoichiro Seno" To: , , , , Subject: iPOP 2009 Call for Presentations Date: Mon, 2 Feb 2009 17:39:11 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-index: Acl83napCLZqADbiT0CXLGI2JmotcQH+EUEg Sender: owner-ccamp@ops.ietf.org Precedence: bulk List-ID: Dear CAMP, PCE, L1VPN, MPLS and MPLS-TP subscribers, (Apologies for multiple copies, appreciated if you can forward to potentially interested people. Following the successful events of iPOP, the 5th Conference on IP + Optical Network (iPOP 2009) will be held at NICT Headquarters, Koganei, Tokyo, Japan, June 11-12, 2009. The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. See Call for presentation details at http://www.pilab.jp/ipop2009/ Important Dates: Submission deadline of one page summary: February 20, 2009 Notification of acceptance: April 3, 2009 Submission deadline of final presentation slides: April 24, 2009 The Technical Program Committee for iPOP 2009 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not limited to the following: * GMPLS/ASON technologies * GMPLS Network management, OA&M * Multi-layer network (MLN) / Multi-region network (MRN) * Path Computation Element (PCE), Traffic engineering * Inter-area/Inter-AS network * L1VPN, Bandwidth on Demand, and Photonic Grid * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Carrier Ethernet and MPLS-TP * Photonic Network for NxGN and NwGN * Application with high-bandwidth demand * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstract of 400 words and a maximum of 1 page, including figures and diagrams, speaker's name, affiliation, and contact information to the Technical Program Committee at ipop2009-CFP@pilab.jp. Kind regards, Sho Seno Exhibition Committee Vice-chair, iPOP 2009 -- Shoichiro Seno (E-mail) Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Information Technology R&D Center, Mitsubishi Electric Corporation From cfrg-bounces@irtf.org Mon Feb 2 05:27:27 2009 Return-Path: X-Original-To: ccamp-archive@ietf.org Delivered-To: ietfarch-ccamp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8CF928C210 for ; Mon, 2 Feb 2009 05:27:27 -0800 (PST) Subject: The results of your email commands From: cfrg-bounces@irtf.org To: ccamp-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0739177913==" Message-ID: Date: Mon, 02 Feb 2009 05:27:26 -0800 Precedence: bulk X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 List-Id: Crypto Forum Research Group X-List-Administrivia: yes Sender: cfrg-bounces@irtf.org Errors-To: cfrg-bounces@irtf.org --===============0739177913== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The results of your email command are provided below. Attached is your original message. - Unprocessed: It's the perfect time to get that dream watch you've fantasized about. But there's no need to empty your bank account while doing it! http://search.yahoo.com/search?y=Search&p=divehart%2ecom&fr=sfp&ei=UTF-8 At Prest1ge R3ps you will find exactly the watch you're looking for, at prices that will make you blink twice. That's right! Here you can get a Rolex, a Breitling, a Tag or pretty much every fine brand timepiece for less than ten percent their original price! http://search.yahoo.com/search?y=Search&p=divehart%2ecom&fr=sfp&ei=UTF-8 Don't delay your pleasure: our incredible watch collection awaits you at Prest1ge R3ps, so come vi it us n w! Sincerely, Mr Simons - Done. --===============0739177913== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: cfrg-request@core3.amsl.com Delivered-To: cfrg-request@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ABF228C1FE; Mon, 2 Feb 2009 05:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -37.233 X-Spam-Level: X-Spam-Status: No, score=-37.233 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_PRESTIGE=50, GB_ROLEX=5, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc3xh7lL9PFc; Mon, 2 Feb 2009 05:27:25 -0800 (PST) Received: from CUSTOMER.VPLS.NET (unknown [189.71.28.171]) by core3.amsl.com (Postfix) with SMTP id 7224628C1F9; Mon, 2 Feb 2009 05:27:11 -0800 (PST) X-Originating-IP: 12.112.200.140 by smtp.thejaywalker.com; Mon, 02 Feb 2009 15:20:49 +0200 Message-ID: <006M1118.10175344ccamp-archive@ietf.org> Date: Mon, 02 Feb 2009 08:26:49 -0500 From: "Bianca Bower" To: "Bettye Simons" Subject: Classic timepieces reps Content-Type: text/plain; Content-Transfer-Encoding: 7bit Dear Bettye, It's the perfect time to get that dream watch you've fantasized about. But there's no need to empty your bank account while doing it! http://search.yahoo.com/search?y=Search&p=divehart%2ecom&fr=sfp&ei=UTF-8 At Prest1ge R3ps you will find exactly the watch you're looking for, at prices that will make you blink twice. That's right! Here you can get a Rolex, a Breitling, a Tag or pretty much every fine brand timepiece for less than ten percent their original price! http://search.yahoo.com/search?y=Search&p=divehart%2ecom&fr=sfp&ei=UTF-8 Don't delay your pleasure: our incredible watch collection awaits you at Prest1ge R3ps, so come vi it us n w! Sincerely, Mr Simons --===============0739177913==-- Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 27 Feb 2009 17:19:33 +0000 To: IETF-Announce From: The IESG Subject: Last Call: draft-ietf-ccamp-gmpls-ason-routing-ospf (OSPFv2 Routing Protocols Extensions for ASON Routing) to Experimental RFC Reply-to: ietf@ietf.org CC: Message-Id: <20090227171654.605F228C330@core3.amsl.com> Date: Fri, 27 Feb 2009 09:16:54 -0800 (PST) The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'OSPFv2 Routing Protocols Extensions for ASON Routing ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-03-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ospf-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15037&rfc_flag=0 The following IPR Declarations may be related to this I-D: Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 26 Feb 2009 23:08:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Segment protection failure when recovery LSPs overlap Date: Fri, 27 Feb 2009 00:07:20 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801D467B6@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Segment protection failure when recovery LSPs overlap Thread-Index: AcmXt8WbYPpPQya6TEiMBGLmF0nCtQAagpiwAA1GTeA= From: "PAPADIMITRIOU Dimitri" To: "Nic Neate" , "Fatai Zhang" , Cc: "labn - Lou Berger" , , "Aria - Adrian Farrel Personal" Nic, > -----Original Message----- > From: Nic Neate [mailto:Nic.Neate@dataconnection.com]=20 > Sent: Thursday, February 26, 2009 4:34 PM > To: Fatai Zhang; PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel Personal > Subject: RE: Segment protection failure when recovery LSPs overlap >=20 > I think we're converging on this.=20 I don't think so. See below: > I'm happy to work on=20 > protocol extensions for choosing the master and ensuring that=20 > traffic is switched onto just one recovery LSP. Please let=20 > me know if you have any suggestions for how that should work. As stated in a previous e-mail changing the below procedure is not the issue at all. > The particular text in RFCs 4872 and 4873 that I think=20 > requires this is as follows. >=20 > RFC 4872 section 7.2 defines the procedures for initiating=20 > switchover in 1:1 protection: >=20 > 1. If an end-node ... detects the failure of the working LSP > ... it disconnects the extra-traffic from the protecting=20 > LSP... >=20 > This node MUST reliably send a Notify message ... to the=20 > other end-node ... indicating the failure of the working=20 > LSP ... >=20 > 2. Upon receipt of the (switchover request) Notify message, the > end-node ... MUST disconnect the extra-traffic from the=20 > protecting LSP and begin sending/receiving normal traffic=20 > out/from the protecting LSP... >=20 > Those MUST statements don't leave room for the end-node to=20 > decide, based on configuration, whether to act as master or slave. This is not what the text says. The mis-interpretation comes initially from the fact Notify themselves can be configured so as trigger the nodes from which recovery initiation is expected. In the below case typically B,C pair or F,G pair or any composition that does not result into contradicting decisions and actions. So if decision is taken to Notify only upstream there is no issue. In brief, the notion of master/slave can be configured (via head-end) and triggered via Notify - what is not present today is an election based on working/protecting segment setup. More specifically there is no BCP today for selecting Notify addresses for corner cases like you depicted. The other possibility once protecting segment are setup is an additional exchange to be executed in order to determine under which condition the recovery procedure is triggered - and these may be negotiated instead of being pre-configured. Thanks, -dimitri. > The same procedures are also used for segment protection, as=20 > specified in RFC 4873 section 2.1: >=20 > The switch-over processing for segment 1+1 Bidirectional protection > and 1:1 Protection With Extra-Traffic follows the same=20 > procedures as > end-to-end protection forms; see Sections 6.2 and 7.2 of [RFC4872] > for details. >=20 > Nic >=20 > ________________________________ >=20 > From: Fatai Zhang [mailto:zhangfatai@huawei.com]=20 > Sent: 26 February 2009 02:13 > To: ALU - Dimitri Papadimitriou; Nic Neate; ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel Personal > Subject: Re: Segment protection failure when recovery LSPs overlap >=20 >=20 > Hi all, > =20 > I think Nic caught the important issues for implementation. > =20 > There should be a mechanism for node C/D/E/F to know that=20 > there are two recovery LSPs for the faults (link faults:=20 > C-D,D-E,E-F and also node faults: D and E). And when any=20 > fault occurs, I think only one recovery LSP should take over=20 > the traffic. > =20 > RFC 4426 just focuses on " Functional Specification" , and=20 > there is no standard solution. > =20 > As a solution for RFC 4873, I think we need patch it if there=20 > is any issue to be solved. > =20 > =20 >=20 > Thanks > =20 > Fatai Zhang > =20 > Advanced Technology Department > Wireline Networking Business Unit > Huawei Technologies Co., LTD. > Huawei Base, Bantian, Longgang, > Shenzhen 518129 P.R.China > Tel: +86-755-28972912 > Fax: +86-755-28972935 >=20 > ----- Original Message -----=20 > From: PAPADIMITRIOU Dimitri=20 > =20 > To: Nic Neate ;=20 > ccamp@ops.ietf.org=20 > Cc: labn - Lou Berger ;=20 > IBryskin@advaoptical.com ; Aria - Adrian Farrel Personal=20 > =20 > Sent: Wednesday, February 25, 2009 11:40 PM > Subject: RE: Segment protection failure when recovery=20 > LSPs overlap >=20 > Hi Nic:=20 > =09 > > -----Original Message----- > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com]=20 > > Sent: Wednesday, February 25, 2009 3:58 PM > > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > > Adrian Farrel Personal > > Subject: RE: Segment protection failure when recovery=20 > LSPs overlap > >=20 > > Hi Dimitri, > >=20 > > I don't think that solves this issue. Let me restate the=20 > > problem with more detail on the master/slave behaviour. > >=20 > > We have the following topology, where the LSP A-B-C-D-E-F-G-H=20 > > has 1:1 segment protection with extra traffic, and=20 > the link D-E fails: > >=20 > > > > K-----------L > > > > / \ > > > > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD x = E=3D=3D=3DF=3D=3D=3DG=3D=3D=3DH > > > > \ / > > > > I-----------J > >=20 > > RFC 4426 defines a master/slave relationship for the=20 > > endpoints of the recovery LSPs. > > - For the recovery LSP B-K-L-F, either B or F will be the=20 > > master, controlling switchover onto that recovery LSP. > > - For the recovery LSP C-I-J-G, either C or G will be the=20 > > master, controlling switchover onto that recovery LSP. > >=20 > > However, there is no mechanism defined for electing the=20 > > masters. Rather, RFC 4872 defines the switchover procedures=20 > > for 1:1 protection, and states that the first endpoint of the=20 > > recovery LSP to detect the failure is the one that initiates=20 > > switchover (http://tools.ietf.org/html/rfc4872#section-7.2). > =09 > Where is it stated in section 7.2 that "the first=20 > endpoint of the > recovery LSP to detect the failure is the one that=20 > initiates switchover" > can you point me the sentence ? > =09 > > In this example, C and F are closest to the failure, and have=20 > > their NOTIFY_REQUEST objects at the top of the stack at D and=20 > > E respectively. It is therefore likely that C and F will=20 > > detect the failure before B and G, and so C and F=20 > will be the masters. > >=20 > > That presents the problem that C and F will both attempt to=20 > > initiate a switchover using their respective recovery LSPs,=20 > > leading to the data loss described in my original mail. > >=20 > > If there was a way to force B and C to be masters then your=20 > > suggestion that B should avoid triggering protection=20 > > switching before C may work. However, that is explicitly not=20 > > considered in 1:1 protection switching. See Note 1 in=20 > > http://tools.ietf.org/html/rfc4872#section-7.2: > >=20 > > Note 1: a 2-phase protection-switching signaling=20 > is used in the > > present context; a 3-phase signaling (see [RFC4426]) that=20 > > would imply > > a notification message, a switchover request, and=20 > a switchover > > response messages is not considered here. > =09 > Per 4426: "The determination of the master and the=20 > slave may be based on > configured information or protocol specific=20 > requirements." ... so > basically you may extend the protocol messaging=20 > detailed in 4872 to > trigger this election but you can also perform it via=20 > other means. The > fundamental issue is that it does not modify the=20 > protocol procedures > specified in 4872 or 4873 i.e. dynamic election would=20 > just be an add-on. > =09 > The same applies to the WTR where we stated specified=20 > by configuration > and then Attila came with a dynamic mechanism to set it up, etc. > =09 > Thanks, > -dimitri. > > Nic > >=20 > >=20 > >=20 > > -----Original Message----- > > From: ALU - Dimitri Papadimitriou=20 > > Sent: 24 February 2009 09:27 > > To: Nic Neate; ccamp@ops.ietf.org > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > > Adrian Farrel Personal > > Subject: RE: Segment protection failure when recovery=20 > LSPs overlap > >=20 > > Nic, > >=20 > > I will restate, in all protection scheme there is a master=20 > > slave mechanism. Now concerning the SRRO: C (and B) and F=20 > > (and G) are generators in the upstream and downstream=20 > > direction. So the SRRO are known to B and it is what we are=20 > > interested in that B does not trigger recovery before C and=20 > > the same for F and G i.e that G does not trigger=20 > recovery before F. > >=20 > > Thanks, > > -dimitri. > >=20 > > > -----Original Message----- > > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > > Sent: Monday, February 23, 2009 4:13 PM > > > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > > Adrian Farrel=20 > > > Personal > > > Subject: RE: Segment protection failure when=20 > recovery LSPs overlap > > >=20 > > > Hi Dimitri, > > >=20 > > > We had wondered about the SRRO as a possible solution to=20 > > this problem=20 > > > as well. However, there are a couple of issues as=20 > the protocol=20 > > > currently stands. > > >=20 > > > - SRROs can only be present in Path messages between the=20 > > merge node=20 > > > and the egress, and in Resv messages between the branch=20 > > node and the=20 > > > ingress. See > > > http://tools.ietf.org/html/rfc4873#section-2 and=20 > > > http://tools.ietf.org/html/rfc4873#section-5.2. Therefore,=20 > > C does not=20 > > > have the SRRO for recovery LSP B-K-L-F, and F does not have=20 > > the SRRO=20 > > > for recovery LSP C-I-J-G. > > >=20 > > > - The inclusion of the SRRO is optional,=20 > controlled via the=20 > > > segment-recording-desired flag in the=20 > SESSION_ATTRIBUTE object=20 > > > (http://tools.ietf.org/html/rfc4873#section-5.2). =20 > If the SRRO is=20 > > > required in order to avoid data loss then it needs=20 > to be mandatory. > > >=20 > > > So I think we need a protocol extension in order to=20 > provide a=20 > > > signaling-based solution. > > >=20 > > > Nic > > >=20 > > >=20 > > > -----Original Message----- > > > From: ALU - Dimitri Papadimitriou > > > Sent: 21 February 2009 23:51 > > > To: Nic Neate; ccamp@ops.ietf.org > > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > > Adrian Farrel=20 > > > Personal > > > Subject: RE: Segment protection failure when=20 > recovery LSPs overlap > > >=20 > > > Nic, > > >=20 > > > RFC4873 by means of SRRO allows nodes to determine=20 > existence of=20 > > > upstream/downstream recovery segments as carried in=20 > > Path/Resv message. > > > Combined with RFC4426 and RFC4428 that refers to=20 > master/slave it=20 > > > results that either C (or F) trigger a recovery=20 > action by means of=20 > > > disjoint recovery segments. > > >=20 > > > Thanks, > > > -d. > > >=20 > > > > -----Original Message----- > > > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > > > Sent: Friday, February 20, 2009 4:05 PM > > > > To: ccamp@ops.ietf.org > > > > Cc: labn - Lou Berger; IBryskin@advaoptical.com;=20 > PAPADIMITRIOU=20 > > > > Dimitri; Aria - Adrian Farrel Personal > > > > Subject: Segment protection failure when recovery=20 > LSPs overlap > > > >=20 > > > > Hi CCAMP, > > > >=20 > > > > I'd like to raise one more issue with RFC4873 segment > > > recovery, which > > > > I believe will lead to data loss when overlapping segment=20 > > recovery=20 > > > > LSPs are used. > > > >=20 > > > > RFC4873 allows topologies like this one: > > > >=20 > > > > K-----------L > > > > / \ > > > > = A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE=3D=3D=3DF=3D=3D=3DG=3D=3D=3DH > > > > \ / > > > > I-----------J > > > >=20 > > > > A working LSP A-B-C-D-E-F-G-H is protected by two > > > overlapping segment > > > > recovery LSPs: B-K-L-F and C-I-J-G. The recovery=20 > scheme is 1:1=20 > > > > protection with extra traffic. > > > >=20 > > > > Suppose the link D-E fails: > > > >=20 > > > > K-----------L > > > > / \ > > > > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD x = E=3D=3D=3DF=3D=3D=3DG=3D=3D=3DH > > > > \ / > > > > I-----------J > > > >=20 > > > > My understanding is that the failure will be=20 > handled as follows. > > > >=20 > > > > - D detects the link failure, and sends Notify to C=20 > > (first Notify=20 > > > > object > > > > in the received Path). C and G exchanged Notify > > > messages to remove > > > > extra traffic from the C-I-J-G repair, and then send=20 > > and receive=20 > > > > traffic from the working LSP on C-I and G-J. > > > >=20 > > > > - Meanwhile, E also detects the failure, and sends Notify > > > to F (first > > > > Notify object in the received Resv). F likewise=20 > > exchanges Notify > > > > messages with B to remove extra traffic from the=20 > > B-K-L-F repair,=20 > > > > and > > > > and then send and receive working LSP traffic=20 > on B-K and F-L. > > > >=20 > > > > That results in the following data flow: > > > >=20 > > > > K----->-----L > > > > / \ > > > > A->-B <-C D E F-> G<--H > > > > \ / > > > > I-----<-----J > > > >=20 > > > > Forward traffic reaches G on the link F-G. However, G has > > > switched to > > > > send and receive on G-J, and so drops traffic=20 > received from F. > > > >=20 > > > > Reverse traffic reaches B on C-B. However, B has switched > > > to send and > > > > receive on B-K, and so drops traffic received from C. > > > >=20 > > > > Thus traffic is lost in both directions. > > > >=20 > > > > Can anyone point out an error in this analysis? Is this=20 > > a topology=20 > > > > that there is interest in supporting? > > > >=20 > > > > Thanks, > > > >=20 > > > > Nic > > > >=20 > > >=20 > >=20 > =09 >=20 >=20 Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 26 Feb 2009 22:31:59 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Initial Version I-D Submission Deadline Extended to March 4, 2009 Date: Thu, 26 Feb 2009 22:29:59 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Alexa Morris" To: ; ; Sent: Thursday, February 26, 2009 7:27 PM Subject: Initial Version I-D Submission Deadline Extended to March 4, 2009 > The IESG has extended the deadline for initial version (00) > submissions of Internet Drafts by 2 days (48 hours). The new deadline > is March 4, 2009 at 1700 Pacific (March 5, 2009 at 0100 UTC / GMT) > and the extension is for IETF 74 only. The deadline has been extended > due to the copyright legend text alternative being recently finalized, > approved and implemented. > > Please note that the date for updated I-D versions has NOT been > extended, and is still March 9, 2009. > > Regards, > Alexa > > ----------- > Alexa Morris / Executive Director / IETF > 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 > Phone: +1.510.492.4089 / Fax: +1.510.492.4001 > Email: amorris@amsl.com > > Managed by Association Management Solutions (AMS) > Forum Management, Meeting and Event Planning > www.amsl.com Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 26 Feb 2009 18:27:40 +0000 Message-ID: <49A6DEC5.1010403@pi.nu> Date: Thu, 26 Feb 2009 19:26:13 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, ITU-T ad hoc team on MPLS-TP , ccamp@ops.ietf.org, pwe3@ietf.org Subject: poll on making draft-sprecher-mpls-tp-survive-fwk-01.txt a working group document? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, we have received a request from the editors/authors of draft-sprecher-mpls-tp-survive-fwk-01.txt to make the document an mpls working group document. Please send your comments to the mpls-tp mailing list. This poll ends eob Thu Mar 12, 2009. /Loa -- Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 8 632 77 14 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 26 Feb 2009 15:36:29 +0000 From: Nic Neate To: Fatai Zhang , ALU - Dimitri Papadimitriou , "ccamp@ops.ietf.org" CC: labn - Lou Berger , "IBryskin@advaoptical.com" , Aria - Adrian Farrel Personal Date: Thu, 26 Feb 2009 15:33:30 +0000 Subject: RE: Segment protection failure when recovery LSPs overlap Thread-Topic: Segment protection failure when recovery LSPs overlap Thread-Index: AcmXt8WbYPpPQya6TEiMBGLmF0nCtQAagpiw Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C7B63E531@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 I think we're converging on this. I'm happy to work on protocol extensions= for choosing the master and ensuring that traffic is switched onto just on= e recovery LSP. Please let me know if you have any suggestions for how tha= t should work. The particular text in RFCs 4872 and 4873 that I think requires this is as = follows. RFC 4872 section 7.2 defines the procedures for initiating switchover in 1:= 1 protection: 1. If an end-node ... detects the failure of the working LSP ... it disconnects the extra-traffic from the protecting=20 LSP... This node MUST reliably send a Notify message ... to the=20 other end-node ... indicating the failure of the working=20 LSP ... 2. Upon receipt of the (switchover request) Notify message, the end-node ... MUST disconnect the extra-traffic from the=20 protecting LSP and begin sending/receiving normal traffic=20 out/from the protecting LSP... Those MUST statements don't leave room for the end-node to decide, based on= configuration, whether to act as master or slave. The same procedures are also used for segment protection, as specified in R= FC 4873 section 2.1: The switch-over processing for segment 1+1 Bidirectional protection and 1:1 Protection With Extra-Traffic follows the same procedures as end-to-end protection forms; see Sections 6.2 and 7.2 of [RFC4872] for details. Nic ________________________________ From: Fatai Zhang [mailto:zhangfatai@huawei.com]=20 Sent: 26 February 2009 02:13 To: ALU - Dimitri Papadimitriou; Nic Neate; ccamp@ops.ietf.org Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian Farrel Perso= nal Subject: Re: Segment protection failure when recovery LSPs overlap Hi all, =20 I think Nic caught the important issues for implementation. =20 There should be a mechanism for node C/D/E/F to know that there are two rec= overy LSPs for the faults (link faults: C-D,D-E,E-F and also node faults: D= and E). And when any fault occurs, I think only one recovery LSP should t= ake over the traffic. =20 RFC 4426 just focuses on " Functional Specification" , and there is no stan= dard solution. =20 As a solution for RFC 4873, I think we need patch it if there is any issue = to be solved. =20 =20 Thanks =20 Fatai Zhang =20 Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message -----=20 From: PAPADIMITRIOU Dimitri =20 To: Nic Neate ; ccamp@ops.ietf.org= =20 Cc: labn - Lou Berger ; IBryskin@advaoptical.co= m ; Aria - Adrian Farrel Personal =20 Sent: Wednesday, February 25, 2009 11:40 PM Subject: RE: Segment protection failure when recovery LSPs overlap Hi Nic:=20 =09 > -----Original Message----- > From: Nic Neate [mailto:Nic.Neate@dataconnection.com]=20 > Sent: Wednesday, February 25, 2009 3:58 PM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel Personal > Subject: RE: Segment protection failure when recovery LSPs overlap >=20 > Hi Dimitri, >=20 > I don't think that solves this issue. Let me restate the=20 > problem with more detail on the master/slave behaviour. >=20 > We have the following topology, where the LSP A-B-C-D-E-F-G-H=20 > has 1:1 segment protection with extra traffic, and the link D-E fails: >=20 > > > K-----------L > > > / \ > > > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD x E=3D=3D=3DF=3D= =3D=3DG=3D=3D=3DH > > > \ / > > > I-----------J >=20 > RFC 4426 defines a master/slave relationship for the=20 > endpoints of the recovery LSPs. > - For the recovery LSP B-K-L-F, either B or F will be the=20 > master, controlling switchover onto that recovery LSP. > - For the recovery LSP C-I-J-G, either C or G will be the=20 > master, controlling switchover onto that recovery LSP. >=20 > However, there is no mechanism defined for electing the=20 > masters. Rather, RFC 4872 defines the switchover procedures=20 > for 1:1 protection, and states that the first endpoint of the=20 > recovery LSP to detect the failure is the one that initiates=20 > switchover (http://tools.ietf.org/html/rfc4872#section-7.2). =09 Where is it stated in section 7.2 that "the first endpoint of the recovery LSP to detect the failure is the one that initiates switchover" can you point me the sentence ? =09 > In this example, C and F are closest to the failure, and have=20 > their NOTIFY_REQUEST objects at the top of the stack at D and=20 > E respectively. It is therefore likely that C and F will=20 > detect the failure before B and G, and so C and F will be the masters. >=20 > That presents the problem that C and F will both attempt to=20 > initiate a switchover using their respective recovery LSPs,=20 > leading to the data loss described in my original mail. >=20 > If there was a way to force B and C to be masters then your=20 > suggestion that B should avoid triggering protection=20 > switching before C may work. However, that is explicitly not=20 > considered in 1:1 protection switching. See Note 1 in=20 > http://tools.ietf.org/html/rfc4872#section-7.2: >=20 > Note 1: a 2-phase protection-switching signaling is used in the > present context; a 3-phase signaling (see [RFC4426]) that=20 > would imply > a notification message, a switchover request, and a switchover > response messages is not considered here. =09 Per 4426: "The determination of the master and the slave may be based on configured information or protocol specific requirements." ... so basically you may extend the protocol messaging detailed in 4872 to trigger this election but you can also perform it via other means. The fundamental issue is that it does not modify the protocol procedures specified in 4872 or 4873 i.e. dynamic election would just be an add-on. =09 The same applies to the WTR where we stated specified by configuration and then Attila came with a dynamic mechanism to set it up, etc. =09 Thanks, -dimitri. > Nic >=20 >=20 >=20 > -----Original Message----- > From: ALU - Dimitri Papadimitriou=20 > Sent: 24 February 2009 09:27 > To: Nic Neate; ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel Personal > Subject: RE: Segment protection failure when recovery LSPs overlap >=20 > Nic, >=20 > I will restate, in all protection scheme there is a master=20 > slave mechanism. Now concerning the SRRO: C (and B) and F=20 > (and G) are generators in the upstream and downstream=20 > direction. So the SRRO are known to B and it is what we are=20 > interested in that B does not trigger recovery before C and=20 > the same for F and G i.e that G does not trigger recovery before F. >=20 > Thanks, > -dimitri. >=20 > > -----Original Message----- > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > Sent: Monday, February 23, 2009 4:13 PM > > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel=20 > > Personal > > Subject: RE: Segment protection failure when recovery LSPs overlap > >=20 > > Hi Dimitri, > >=20 > > We had wondered about the SRRO as a possible solution to=20 > this problem=20 > > as well. However, there are a couple of issues as the protocol=20 > > currently stands. > >=20 > > - SRROs can only be present in Path messages between the=20 > merge node=20 > > and the egress, and in Resv messages between the branch=20 > node and the=20 > > ingress. See > > http://tools.ietf.org/html/rfc4873#section-2 and=20 > > http://tools.ietf.org/html/rfc4873#section-5.2. Therefore,=20 > C does not=20 > > have the SRRO for recovery LSP B-K-L-F, and F does not have=20 > the SRRO=20 > > for recovery LSP C-I-J-G. > >=20 > > - The inclusion of the SRRO is optional, controlled via the=20 > > segment-recording-desired flag in the SESSION_ATTRIBUTE object=20 > > (http://tools.ietf.org/html/rfc4873#section-5.2). If the SRRO is=20 > > required in order to avoid data loss then it needs to be mandatory. > >=20 > > So I think we need a protocol extension in order to provide a=20 > > signaling-based solution. > >=20 > > Nic > >=20 > >=20 > > -----Original Message----- > > From: ALU - Dimitri Papadimitriou > > Sent: 21 February 2009 23:51 > > To: Nic Neate; ccamp@ops.ietf.org > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel=20 > > Personal > > Subject: RE: Segment protection failure when recovery LSPs overlap > >=20 > > Nic, > >=20 > > RFC4873 by means of SRRO allows nodes to determine existence of=20 > > upstream/downstream recovery segments as carried in=20 > Path/Resv message. > > Combined with RFC4426 and RFC4428 that refers to master/slave it=20 > > results that either C (or F) trigger a recovery action by means of=20 > > disjoint recovery segments. > >=20 > > Thanks, > > -d. > >=20 > > > -----Original Message----- > > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > > Sent: Friday, February 20, 2009 4:05 PM > > > To: ccamp@ops.ietf.org > > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU=20 > > > Dimitri; Aria - Adrian Farrel Personal > > > Subject: Segment protection failure when recovery LSPs overlap > > >=20 > > > Hi CCAMP, > > >=20 > > > I'd like to raise one more issue with RFC4873 segment > > recovery, which > > > I believe will lead to data loss when overlapping segment=20 > recovery=20 > > > LSPs are used. > > >=20 > > > RFC4873 allows topologies like this one: > > >=20 > > > K-----------L > > > / \ > > > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE=3D=3D= =3DF=3D=3D=3DG=3D=3D=3DH > > > \ / > > > I-----------J > > >=20 > > > A working LSP A-B-C-D-E-F-G-H is protected by two > > overlapping segment > > > recovery LSPs: B-K-L-F and C-I-J-G. The recovery scheme is 1:1=20 > > > protection with extra traffic. > > >=20 > > > Suppose the link D-E fails: > > >=20 > > > K-----------L > > > / \ > > > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD x E=3D=3D=3DF=3D= =3D=3DG=3D=3D=3DH > > > \ / > > > I-----------J > > >=20 > > > My understanding is that the failure will be handled as follows. > > >=20 > > > - D detects the link failure, and sends Notify to C=20 > (first Notify=20 > > > object > > > in the received Path). C and G exchanged Notify > > messages to remove > > > extra traffic from the C-I-J-G repair, and then send=20 > and receive=20 > > > traffic from the working LSP on C-I and G-J. > > >=20 > > > - Meanwhile, E also detects the failure, and sends Notify > > to F (first > > > Notify object in the received Resv). F likewise=20 > exchanges Notify > > > messages with B to remove extra traffic from the=20 > B-K-L-F repair,=20 > > > and > > > and then send and receive working LSP traffic on B-K and F-L. > > >=20 > > > That results in the following data flow: > > >=20 > > > K----->-----L > > > / \ > > > A->-B <-C D E F-> G<--H > > > \ / > > > I-----<-----J > > >=20 > > > Forward traffic reaches G on the link F-G. However, G has > > switched to > > > send and receive on G-J, and so drops traffic received from F. > > >=20 > > > Reverse traffic reaches B on C-B. However, B has switched > > to send and > > > receive on B-K, and so drops traffic received from C. > > >=20 > > > Thus traffic is lost in both directions. > > >=20 > > > Can anyone point out an error in this analysis? Is this=20 > a topology=20 > > > that there is interest in supporting? > > >=20 > > > Thanks, > > >=20 > > > Nic > > >=20 > >=20 >=20 =09 Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 26 Feb 2009 11:51:09 +0000 Message-ID: <49A681B5.6020501@pi.nu> Date: Thu, 26 Feb 2009 12:49:09 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, ccamp@ops.ietf.org, pwe3@ietf.org, ITU-T ad hoc team on MPLS-TP , l2vpn@ietf.org, IAB IAB , "Iesg (E-mail)" Subject: RFC 5462 the second MPLS-TP RFC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, we have just seen our second mpls-tp RFC being published: RFC5462 'Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field'. /Loa -- Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 8 632 77 14 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 26 Feb 2009 03:16:52 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090226031501.7D83F3A6BB8@core3.amsl.com> Date: Wed, 25 Feb 2009 19:15:01 -0800 (PST) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet PBB-TE Author(s) : D. Fedyk, et al. Filename : draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt Pages : 18 Date : 2009-02-25 This specification is complementary to the GMPLS controlled Ethernet architecture document [ARCH] and describes the technology specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point to point (P2P) and point to multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-25191323.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 26 Feb 2009 02:15:52 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-mef-uni-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090226021501.91C6A3A6BC2@core3.amsl.com> Date: Wed, 25 Feb 2009 18:15:01 -0800 (PST) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-mef-uni-02.txt Pages : 10 Date : 2009-02-25 This document describes a method for controlling two specific types of Ethernet switching via a Generalized Multi-Protocol Label Switching (GMPLS) based User-Network Interface (UNI). This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-mef-uni-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-25180526.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 26 Feb 2009 02:15:42 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-dcsc-channel-ext-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090226021501.8E2053A6BC4@core3.amsl.com> Date: Wed, 25 Feb 2009 18:15:01 -0800 (PST) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-dcsc-channel-ext-01.txt Pages : 11 Date : 2009-02-25 This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching. The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of an LSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-dcsc-channel-ext-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-dcsc-channel-ext-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-25180459.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 26 Feb 2009 02:15:37 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090226021501.870703A6BC3@core3.amsl.com> Date: Wed, 25 Feb 2009 18:15:01 -0800 (PST) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-ether-svcs-03.txt Pages : 16 Date : 2009-02-25 This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching implied by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line and Ethernet virtual private line services. Support for MEF and ITU defined parameters are also covered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-ether-svcs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-25180454.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 26 Feb 2009 02:15:24 +0000 Date: Thu, 26 Feb 2009 10:13:06 +0800 From: Fatai Zhang Subject: Re: Segment protection failure when recovery LSPs overlap To: PAPADIMITRIOU Dimitri , Nic Neate , ccamp@ops.ietf.org Cc: labn - Lou Berger , IBryskin@advaoptical.com, Aria - Adrian Farrel Personal Message-id: <007101c997b7$c32f0de0$674c460a@china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ytIDcpn38YZO7jJIwDXhRA)" This is a multi-part message in MIME format. --Boundary_(ID_ytIDcpn38YZO7jJIwDXhRA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi all, I think Nic caught the important issues for implementation. There should be a mechanism for node C/D/E/F to know that there are two recovery LSPs for the faults (link faults: C-D,D-E,E-F and also node faults: D and E). And when any fault occurs, I think only one recovery LSP should take over the traffic. RFC 4426 just focuses on " Functional Specification" , and there is no standard solution. As a solution for RFC 4873, I think we need patch it if there is any issue to be solved. Thanks Fatai Zhang Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: PAPADIMITRIOU Dimitri To: Nic Neate ; ccamp@ops.ietf.org Cc: labn - Lou Berger ; IBryskin@advaoptical.com ; Aria - Adrian Farrel Personal Sent: Wednesday, February 25, 2009 11:40 PM Subject: RE: Segment protection failure when recovery LSPs overlap Hi Nic: > -----Original Message----- > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > Sent: Wednesday, February 25, 2009 3:58 PM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - > Adrian Farrel Personal > Subject: RE: Segment protection failure when recovery LSPs overlap > > Hi Dimitri, > > I don't think that solves this issue. Let me restate the > problem with more detail on the master/slave behaviour. > > We have the following topology, where the LSP A-B-C-D-E-F-G-H > has 1:1 segment protection with extra traffic, and the link D-E fails: > > > > K-----------L > > > / \ > > > A===B===C===D x E===F===G===H > > > \ / > > > I-----------J > > RFC 4426 defines a master/slave relationship for the > endpoints of the recovery LSPs. > - For the recovery LSP B-K-L-F, either B or F will be the > master, controlling switchover onto that recovery LSP. > - For the recovery LSP C-I-J-G, either C or G will be the > master, controlling switchover onto that recovery LSP. > > However, there is no mechanism defined for electing the > masters. Rather, RFC 4872 defines the switchover procedures > for 1:1 protection, and states that the first endpoint of the > recovery LSP to detect the failure is the one that initiates > switchover (http://tools.ietf.org/html/rfc4872#section-7.2). Where is it stated in section 7.2 that "the first endpoint of the recovery LSP to detect the failure is the one that initiates switchover" can you point me the sentence ? > In this example, C and F are closest to the failure, and have > their NOTIFY_REQUEST objects at the top of the stack at D and > E respectively. It is therefore likely that C and F will > detect the failure before B and G, and so C and F will be the masters. > > That presents the problem that C and F will both attempt to > initiate a switchover using their respective recovery LSPs, > leading to the data loss described in my original mail. > > If there was a way to force B and C to be masters then your > suggestion that B should avoid triggering protection > switching before C may work. However, that is explicitly not > considered in 1:1 protection switching. See Note 1 in > http://tools.ietf.org/html/rfc4872#section-7.2: > > Note 1: a 2-phase protection-switching signaling is used in the > present context; a 3-phase signaling (see [RFC4426]) that > would imply > a notification message, a switchover request, and a switchover > response messages is not considered here. Per 4426: "The determination of the master and the slave may be based on configured information or protocol specific requirements." ... so basically you may extend the protocol messaging detailed in 4872 to trigger this election but you can also perform it via other means. The fundamental issue is that it does not modify the protocol procedures specified in 4872 or 4873 i.e. dynamic election would just be an add-on. The same applies to the WTR where we stated specified by configuration and then Attila came with a dynamic mechanism to set it up, etc. Thanks, -dimitri. > Nic > > > > -----Original Message----- > From: ALU - Dimitri Papadimitriou > Sent: 24 February 2009 09:27 > To: Nic Neate; ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - > Adrian Farrel Personal > Subject: RE: Segment protection failure when recovery LSPs overlap > > Nic, > > I will restate, in all protection scheme there is a master > slave mechanism. Now concerning the SRRO: C (and B) and F > (and G) are generators in the upstream and downstream > direction. So the SRRO are known to B and it is what we are > interested in that B does not trigger recovery before C and > the same for F and G i.e that G does not trigger recovery before F. > > Thanks, > -dimitri. > > > -----Original Message----- > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > Sent: Monday, February 23, 2009 4:13 PM > > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - > Adrian Farrel > > Personal > > Subject: RE: Segment protection failure when recovery LSPs overlap > > > > Hi Dimitri, > > > > We had wondered about the SRRO as a possible solution to > this problem > > as well. However, there are a couple of issues as the protocol > > currently stands. > > > > - SRROs can only be present in Path messages between the > merge node > > and the egress, and in Resv messages between the branch > node and the > > ingress. See > > http://tools.ietf.org/html/rfc4873#section-2 and > > http://tools.ietf.org/html/rfc4873#section-5.2. Therefore, > C does not > > have the SRRO for recovery LSP B-K-L-F, and F does not have > the SRRO > > for recovery LSP C-I-J-G. > > > > - The inclusion of the SRRO is optional, controlled via the > > segment-recording-desired flag in the SESSION_ATTRIBUTE object > > (http://tools.ietf.org/html/rfc4873#section-5.2). If the SRRO is > > required in order to avoid data loss then it needs to be mandatory. > > > > So I think we need a protocol extension in order to provide a > > signaling-based solution. > > > > Nic > > > > > > -----Original Message----- > > From: ALU - Dimitri Papadimitriou > > Sent: 21 February 2009 23:51 > > To: Nic Neate; ccamp@ops.ietf.org > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - > Adrian Farrel > > Personal > > Subject: RE: Segment protection failure when recovery LSPs overlap > > > > Nic, > > > > RFC4873 by means of SRRO allows nodes to determine existence of > > upstream/downstream recovery segments as carried in > Path/Resv message. > > Combined with RFC4426 and RFC4428 that refers to master/slave it > > results that either C (or F) trigger a recovery action by means of > > disjoint recovery segments. > > > > Thanks, > > -d. > > > > > -----Original Message----- > > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > > Sent: Friday, February 20, 2009 4:05 PM > > > To: ccamp@ops.ietf.org > > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU > > > Dimitri; Aria - Adrian Farrel Personal > > > Subject: Segment protection failure when recovery LSPs overlap > > > > > > Hi CCAMP, > > > > > > I'd like to raise one more issue with RFC4873 segment > > recovery, which > > > I believe will lead to data loss when overlapping segment > recovery > > > LSPs are used. > > > > > > RFC4873 allows topologies like this one: > > > > > > K-----------L > > > / \ > > > A===B===C===D===E===F===G===H > > > \ / > > > I-----------J > > > > > > A working LSP A-B-C-D-E-F-G-H is protected by two > > overlapping segment > > > recovery LSPs: B-K-L-F and C-I-J-G. The recovery scheme is 1:1 > > > protection with extra traffic. > > > > > > Suppose the link D-E fails: > > > > > > K-----------L > > > / \ > > > A===B===C===D x E===F===G===H > > > \ / > > > I-----------J > > > > > > My understanding is that the failure will be handled as follows. > > > > > > - D detects the link failure, and sends Notify to C > (first Notify > > > object > > > in the received Path). C and G exchanged Notify > > messages to remove > > > extra traffic from the C-I-J-G repair, and then send > and receive > > > traffic from the working LSP on C-I and G-J. > > > > > > - Meanwhile, E also detects the failure, and sends Notify > > to F (first > > > Notify object in the received Resv). F likewise > exchanges Notify > > > messages with B to remove extra traffic from the > B-K-L-F repair, > > > and > > > and then send and receive working LSP traffic on B-K and F-L. > > > > > > That results in the following data flow: > > > > > > K----->-----L > > > / \ > > > A->-B <-C D E F-> G<--H > > > \ / > > > I-----<-----J > > > > > > Forward traffic reaches G on the link F-G. However, G has > > switched to > > > send and receive on G-J, and so drops traffic received from F. > > > > > > Reverse traffic reaches B on C-B. However, B has switched > > to send and > > > receive on B-K, and so drops traffic received from C. > > > > > > Thus traffic is lost in both directions. > > > > > > Can anyone point out an error in this analysis? Is this > a topology > > > that there is interest in supporting? > > > > > > Thanks, > > > > > > Nic > > > > > > --Boundary_(ID_ytIDcpn38YZO7jJIwDXhRA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi all,
 
I think Nic caught the important issues for implementation.
 
There should be a mechanism for node C/D/E/F to know that there are two recovery LSPs for the faults (link faults: C-D,D-E,E-F and also node faults: D and E). And when any fault occurs, I think  only one recovery LSP should take over the traffic.
 
RFC 4426 just focuses on " Functional Specification" , and there is no standard solution.
 
As a solution for RFC 4873, I think we need patch it if there is any issue to be solved.
 
 

Thanks
 
Fatai Zhang
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
----- Original Message -----
Sent: Wednesday, February 25, 2009 11:40 PM
Subject: RE: Segment protection failure when recovery LSPs overlap

Hi Nic:

> -----Original Message-----
> From: Nic Neate [mailto:Nic.Neate@dataconnection.com]
> Sent: Wednesday, February 25, 2009 3:58 PM
> To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org
> Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -
> Adrian Farrel Personal
> Subject: RE: Segment protection failure when recovery LSPs overlap
>
> Hi Dimitri,
>
> I don't think that solves this issue.  Let me restate the
> problem with more detail on the master/slave behaviour.
>
> We have the following topology, where the LSP A-B-C-D-E-F-G-H
> has 1:1 segment protection with extra traffic, and the link D-E fails:
>
> > >                           K-----------L
> > >                          /             \
> > >                     A===B===C===D x E===F===G===H
> > >                              \             /
> > >                               I-----------J
>
> RFC 4426 defines a master/slave relationship for the
> endpoints of the recovery LSPs.
> -  For the recovery LSP B-K-L-F, either B or F will be the
> master, controlling switchover onto that recovery LSP.
> -  For the recovery LSP C-I-J-G, either C or G will be the
> master, controlling switchover onto that recovery LSP.
>
> However, there is no mechanism defined for electing the
> masters.  Rather, RFC 4872 defines the switchover procedures
> for 1:1 protection, and states that the first endpoint of the
> recovery LSP to detect the failure is the one that initiates
> switchover (http://tools.ietf.org/html/rfc4872#section-7.2).

Where is it stated in section 7.2 that "the first endpoint of the
recovery LSP to detect the failure is the one that initiates switchover"
can you point me the sentence ?

> In this example, C and F are closest to the failure, and have
> their NOTIFY_REQUEST objects at the top of the stack at D and
> E respectively.  It is therefore likely that C and F will
> detect the failure before B and G, and so C and F will be the masters.
>
> That presents the problem that C and F will both attempt to
> initiate a switchover using their respective recovery LSPs,
> leading to the data loss described in my original mail.
>
> If there was a way to force B and C to be masters then your
> suggestion that B should avoid triggering protection
> switching before C may work.  However, that is explicitly not
> considered in 1:1 protection switching.  See Note 1 in
> http://tools.ietf.org/html/rfc4872#section-7.2:
>
>    Note 1: a 2-phase protection-switching signaling is used in the
>    present context; a 3-phase signaling (see [RFC4426]) that
> would imply
>    a notification message, a switchover request, and a switchover
>    response messages is not considered here.

Per 4426: "The determination of the master and the slave may be based on
configured information or protocol specific requirements." ... so
basically you may extend the protocol messaging detailed in 4872 to
trigger this election but you can also perform it via other means. The
fundamental issue is that it does not modify the protocol procedures
specified in 4872 or 4873 i.e. dynamic election would just be an add-on.

The same applies to the WTR where we stated specified by configuration
and then Attila came with a dynamic mechanism to set it up, etc.

Thanks,
-dimitri.
> Nic
>
>
>
> -----Original Message-----
> From: ALU - Dimitri Papadimitriou
> Sent: 24 February 2009 09:27
> To: Nic Neate; ccamp@ops.ietf.org
> Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -
> Adrian Farrel Personal
> Subject: RE: Segment protection failure when recovery LSPs overlap
>
> Nic,
>
> I will restate, in all protection scheme there is a master
> slave mechanism. Now concerning the SRRO: C (and B) and F
> (and G) are generators in the upstream and downstream
> direction. So the SRRO are known to B and it is what we are
> interested in that B does not trigger recovery before C and
> the same for F and G i.e that G does not trigger recovery before F.
>
> Thanks,
> -dimitri.
>
> > -----Original Message-----
> > From: Nic Neate [mailto:Nic.Neate@dataconnection.com]
> > Sent: Monday, February 23, 2009 4:13 PM
> > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org
> > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -
> Adrian Farrel
> > Personal
> > Subject: RE: Segment protection failure when recovery LSPs overlap
> >
> > Hi Dimitri,
> >
> > We had wondered about the SRRO as a possible solution to
> this problem
> > as well.  However, there are a couple of issues as the protocol
> > currently stands.
> >
> > -  SRROs can only be present in Path messages between the
> merge node
> > and the egress, and in Resv messages between the branch
> node and the
> > ingress.  See
> > http://tools.ietf.org/html/rfc4873#section-2 and
> > http://tools.ietf.org/html/rfc4873#section-5.2.  Therefore,
> C does not
> > have the SRRO for recovery LSP B-K-L-F, and F does not have
> the SRRO
> > for recovery LSP C-I-J-G.
> >
> > -  The inclusion of the SRRO is optional, controlled via the
> > segment-recording-desired flag in the SESSION_ATTRIBUTE object
> > (http://tools.ietf.org/html/rfc4873#section-5.2).  If the SRRO is
> > required in order to avoid data loss then it needs to be mandatory.
> >
> > So I think we need a protocol extension in order to provide a
> > signaling-based solution.
> >
> > Nic
> >
> >
> > -----Original Message-----
> > From: ALU - Dimitri Papadimitriou
> > Sent: 21 February 2009 23:51
> > To: Nic Neate; ccamp@ops.ietf.org
> > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -
> Adrian Farrel
> > Personal
> > Subject: RE: Segment protection failure when recovery LSPs overlap
> >
> > Nic,
> >
> > RFC4873 by means of SRRO allows nodes to determine existence of
> > upstream/downstream recovery segments as carried in
> Path/Resv message.
> > Combined with RFC4426 and RFC4428 that refers to master/slave it
> > results that either C (or F) trigger a recovery action by means of
> > disjoint recovery segments.
> >
> > Thanks,
> > -d.
> >
> > > -----Original Message-----
> > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com]
> > > Sent: Friday, February 20, 2009 4:05 PM
> > > To: ccamp@ops.ietf.org
> > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU
> > > Dimitri; Aria - Adrian Farrel Personal
> > > Subject: Segment protection failure when recovery LSPs overlap
> > >
> > > Hi CCAMP,
> > >
> > > I'd like to raise one more issue with RFC4873 segment
> > recovery, which
> > > I believe will lead to data loss when overlapping segment
> recovery
> > > LSPs are used.
> > >
> > > RFC4873 allows topologies like this one:
> > >
> > >                           K-----------L
> > >                          /             \
> > >                     A===B===C===D===E===F===G===H
> > >                              \             /
> > >                               I-----------J
> > >
> > > A working LSP A-B-C-D-E-F-G-H is protected by two
> > overlapping segment
> > > recovery LSPs: B-K-L-F and C-I-J-G.  The recovery scheme is 1:1
> > > protection with extra traffic.
> > >
> > > Suppose the link D-E fails:
> > >
> > >                           K-----------L
> > >                          /             \
> > >                     A===B===C===D x E===F===G===H
> > >                              \             /
> > >                               I-----------J
> > >
> > > My understanding is that the failure will be handled as follows.
> > >
> > > -  D detects the link failure, and sends Notify to C
> (first Notify
> > > object
> > >    in the received Path).  C and G exchanged Notify
> > messages to remove
> > >    extra traffic from the C-I-J-G repair, and then send
> and receive
> > >    traffic from the working LSP on C-I and G-J.
> > >
> > > -  Meanwhile, E also detects the failure, and sends Notify
> > to F (first
> > >    Notify object in the received Resv).  F likewise
> exchanges Notify
> > >    messages with B to remove extra traffic from the
> B-K-L-F repair,
> > > and
> > >    and then send and receive working LSP traffic on B-K and F-L.
> > >
> > > That results in the following data flow:
> > >
> > >                           K----->-----L
> > >                          /             \
> > >                     A->-B <-C   D   E   F-> G<--H
> > >                              \             /
> > >                               I-----<-----J
> > >
> > > Forward traffic reaches G on the link F-G.  However, G has
> > switched to
> > > send and receive on G-J, and so drops traffic received from F.
> > >
> > > Reverse traffic reaches B on C-B.  However, B has switched
> > to send and
> > > receive on B-K, and so drops traffic received from C.
> > >
> > > Thus traffic is lost in both directions.
> > >
> > > Can anyone point out an error in this analysis?  Is this
> a topology
> > > that there is interest in supporting?
> > >
> > > Thanks,
> > >
> > > Nic
> > >
> >
>
--Boundary_(ID_ytIDcpn38YZO7jJIwDXhRA)-- Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 26 Feb 2009 00:50:33 +0000 Message-ID: <49A5E659.20606@lab.ntt.co.jp> Date: Thu, 26 Feb 2009 09:46:17 +0900 From: Kohei Shiomoto User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Ccamp (E-mail)" Subject: [Fwd: I-D Action:draft-shiomoto-ccamp-switch-programming-00.txt] Content-Type: multipart/mixed; boundary="------------070901060503070300060606" This is a multi-part message in MIME format. --------------070901060503070300060606 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Dear all, We posted a new informational draft on when it is safe to send data when signaling is done in control plane. It will also be used to interpret the signaling performance. Comments are welcome. Best regards, Kohei --------------070901060503070300060606 Content-Type: message/rfc822; name="I-D Action:draft-shiomoto-ccamp-switch-programming-00.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="I-D Action:draft-shiomoto-ccamp-switch-programming-00.txt.em"; filename*1="l" X-Account-Key: account2 X-Mozilla-Keys: Return-Path: Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by imc.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id n1P0UxUu016667 for ; Wed, 25 Feb 2009 09:30:59 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id n1P0UxW5000257 for ; Wed, 25 Feb 2009 09:30:59 +0900 (JST) Received: from idmb.m.ecl.ntt.co.jp. (idmb.m.ecl.ntt.co.jp [129.60.5.3]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id n1P0Uw6P000242; Wed, 25 Feb 2009 09:30:58 +0900 (JST) Received: from mfs1.rdh.ecl.ntt.co.jp (mfs1.rdh.ecl.ntt.co.jp [129.60.57.94]) by idmb.m.ecl.ntt.co.jp. (8.13.8/8.13.8) with ESMTP id n1P0Uw9O017866; Wed, 25 Feb 2009 09:30:58 +0900 (JST) Received: from mfs1.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs1.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 914C0570EF; Wed, 25 Feb 2009 09:30:58 +0900 (JST) Received: from sfs11.tas.ntt.co.jp (sfs11 [192.68.248.59]) by mfs1.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 85D81570EE; Wed, 25 Feb 2009 09:30:58 +0900 (JST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by sfs11.tas.ntt.co.jp (MOS 3.8.7a) with ESMTP id ATN26912; Wed, 25 Feb 2009 09:30:57 +0900 (JST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59A328C26E; Tue, 24 Feb 2009 16:30:04 -0800 (PST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EB69328C267; Tue, 24 Feb 2009 16:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-shiomoto-ccamp-switch-programming-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090225003001.EB69328C267@core3.amsl.com> Date: Tue, 24 Feb 2009 16:30:01 -0800 (PST) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-Junkmail: UCE(10) X-Junkmail-Status: score=10/10, host=sfs11.tas.ntt.co.jp X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A150205.49A49142.0027:SCFSTAT3674418,ss=1,fgs=0, ip=64.170.98.32, so=2008-05-01 23:44:25, dmn=5.7.1/2008-09-02 X-Junkmail-IWF: false --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Advice on When It is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE Author(s) : K. Shiomoto, A. Farrel Filename : draft-shiomoto-ccamp-switch-programming-00.txt Pages : 12 Date : 2009-02-24 The Resource Reservation Protocol (RSVP) has been extended to support Traffic Engineering (TE) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and links to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives. End points of the LSP need to know when it is safe to start sending data so that it is not misdelivered and so that safety issues specific to the data plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to programme their data planes relative to sending control plane messages. This document clarifies and summarises the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidireciotnal and bidirecitonal LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-switch-programming-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-shiomoto-ccamp-switch-programming-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-24161855.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --------------070901060503070300060606-- Envelope-to: ccamp-data0@psg.com Delivery-date: Wed, 25 Feb 2009 15:41:37 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Segment protection failure when recovery LSPs overlap Date: Wed, 25 Feb 2009 16:40:42 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801CF8D4F@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Segment protection failure when recovery LSPs overlap Thread-Index: AcmTbJqCpUPEN1zcQXekkfeOOEhwqgBDqa7wAEvKy4AALag1kAADOWFAADsPvOA= From: "PAPADIMITRIOU Dimitri" To: "Nic Neate" , Cc: "labn - Lou Berger" , , "Aria - Adrian Farrel Personal" Hi Nic:=20 > -----Original Message----- > From: Nic Neate [mailto:Nic.Neate@dataconnection.com]=20 > Sent: Wednesday, February 25, 2009 3:58 PM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel Personal > Subject: RE: Segment protection failure when recovery LSPs overlap >=20 > Hi Dimitri, >=20 > I don't think that solves this issue. Let me restate the=20 > problem with more detail on the master/slave behaviour. >=20 > We have the following topology, where the LSP A-B-C-D-E-F-G-H=20 > has 1:1 segment protection with extra traffic, and the link D-E fails: >=20 > > > K-----------L > > > / \ > > > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD x = E=3D=3D=3DF=3D=3D=3DG=3D=3D=3DH > > > \ / > > > I-----------J >=20 > RFC 4426 defines a master/slave relationship for the=20 > endpoints of the recovery LSPs. > - For the recovery LSP B-K-L-F, either B or F will be the=20 > master, controlling switchover onto that recovery LSP. > - For the recovery LSP C-I-J-G, either C or G will be the=20 > master, controlling switchover onto that recovery LSP. >=20 > However, there is no mechanism defined for electing the=20 > masters. Rather, RFC 4872 defines the switchover procedures=20 > for 1:1 protection, and states that the first endpoint of the=20 > recovery LSP to detect the failure is the one that initiates=20 > switchover (http://tools.ietf.org/html/rfc4872#section-7.2). Where is it stated in section 7.2 that "the first endpoint of the recovery LSP to detect the failure is the one that initiates switchover" can you point me the sentence ? > In this example, C and F are closest to the failure, and have=20 > their NOTIFY_REQUEST objects at the top of the stack at D and=20 > E respectively. It is therefore likely that C and F will=20 > detect the failure before B and G, and so C and F will be the masters. >=20 > That presents the problem that C and F will both attempt to=20 > initiate a switchover using their respective recovery LSPs,=20 > leading to the data loss described in my original mail. >=20 > If there was a way to force B and C to be masters then your=20 > suggestion that B should avoid triggering protection=20 > switching before C may work. However, that is explicitly not=20 > considered in 1:1 protection switching. See Note 1 in=20 > http://tools.ietf.org/html/rfc4872#section-7.2: >=20 > Note 1: a 2-phase protection-switching signaling is used in the > present context; a 3-phase signaling (see [RFC4426]) that=20 > would imply > a notification message, a switchover request, and a switchover > response messages is not considered here. Per 4426: "The determination of the master and the slave may be based on configured information or protocol specific requirements." ... so basically you may extend the protocol messaging detailed in 4872 to trigger this election but you can also perform it via other means. The fundamental issue is that it does not modify the protocol procedures specified in 4872 or 4873 i.e. dynamic election would just be an add-on. The same applies to the WTR where we stated specified by configuration and then Attila came with a dynamic mechanism to set it up, etc. Thanks, -dimitri. > Nic >=20 >=20 >=20 > -----Original Message----- > From: ALU - Dimitri Papadimitriou=20 > Sent: 24 February 2009 09:27 > To: Nic Neate; ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel Personal > Subject: RE: Segment protection failure when recovery LSPs overlap >=20 > Nic, >=20 > I will restate, in all protection scheme there is a master=20 > slave mechanism. Now concerning the SRRO: C (and B) and F=20 > (and G) are generators in the upstream and downstream=20 > direction. So the SRRO are known to B and it is what we are=20 > interested in that B does not trigger recovery before C and=20 > the same for F and G i.e that G does not trigger recovery before F. >=20 > Thanks, > -dimitri. >=20 > > -----Original Message----- > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > Sent: Monday, February 23, 2009 4:13 PM > > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel=20 > > Personal > > Subject: RE: Segment protection failure when recovery LSPs overlap > >=20 > > Hi Dimitri, > >=20 > > We had wondered about the SRRO as a possible solution to=20 > this problem=20 > > as well. However, there are a couple of issues as the protocol=20 > > currently stands. > >=20 > > - SRROs can only be present in Path messages between the=20 > merge node=20 > > and the egress, and in Resv messages between the branch=20 > node and the=20 > > ingress. See > > http://tools.ietf.org/html/rfc4873#section-2 and=20 > > http://tools.ietf.org/html/rfc4873#section-5.2. Therefore,=20 > C does not=20 > > have the SRRO for recovery LSP B-K-L-F, and F does not have=20 > the SRRO=20 > > for recovery LSP C-I-J-G. > >=20 > > - The inclusion of the SRRO is optional, controlled via the=20 > > segment-recording-desired flag in the SESSION_ATTRIBUTE object=20 > > (http://tools.ietf.org/html/rfc4873#section-5.2). If the SRRO is=20 > > required in order to avoid data loss then it needs to be mandatory. > >=20 > > So I think we need a protocol extension in order to provide a=20 > > signaling-based solution. > >=20 > > Nic > >=20 > >=20 > > -----Original Message----- > > From: ALU - Dimitri Papadimitriou > > Sent: 21 February 2009 23:51 > > To: Nic Neate; ccamp@ops.ietf.org > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel=20 > > Personal > > Subject: RE: Segment protection failure when recovery LSPs overlap > >=20 > > Nic, > >=20 > > RFC4873 by means of SRRO allows nodes to determine existence of=20 > > upstream/downstream recovery segments as carried in=20 > Path/Resv message. > > Combined with RFC4426 and RFC4428 that refers to master/slave it=20 > > results that either C (or F) trigger a recovery action by means of=20 > > disjoint recovery segments. > >=20 > > Thanks, > > -d. > >=20 > > > -----Original Message----- > > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > > Sent: Friday, February 20, 2009 4:05 PM > > > To: ccamp@ops.ietf.org > > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU=20 > > > Dimitri; Aria - Adrian Farrel Personal > > > Subject: Segment protection failure when recovery LSPs overlap > > >=20 > > > Hi CCAMP, > > >=20 > > > I'd like to raise one more issue with RFC4873 segment > > recovery, which > > > I believe will lead to data loss when overlapping segment=20 > recovery=20 > > > LSPs are used. > > >=20 > > > RFC4873 allows topologies like this one: > > >=20 > > > K-----------L > > > / \ > > > = A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE=3D=3D=3DF=3D=3D=3DG=3D=3D=3DH > > > \ / > > > I-----------J > > >=20 > > > A working LSP A-B-C-D-E-F-G-H is protected by two > > overlapping segment > > > recovery LSPs: B-K-L-F and C-I-J-G. The recovery scheme is 1:1=20 > > > protection with extra traffic. > > >=20 > > > Suppose the link D-E fails: > > >=20 > > > K-----------L > > > / \ > > > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD x = E=3D=3D=3DF=3D=3D=3DG=3D=3D=3DH > > > \ / > > > I-----------J > > >=20 > > > My understanding is that the failure will be handled as follows. > > >=20 > > > - D detects the link failure, and sends Notify to C=20 > (first Notify=20 > > > object > > > in the received Path). C and G exchanged Notify > > messages to remove > > > extra traffic from the C-I-J-G repair, and then send=20 > and receive=20 > > > traffic from the working LSP on C-I and G-J. > > >=20 > > > - Meanwhile, E also detects the failure, and sends Notify > > to F (first > > > Notify object in the received Resv). F likewise=20 > exchanges Notify > > > messages with B to remove extra traffic from the=20 > B-K-L-F repair,=20 > > > and > > > and then send and receive working LSP traffic on B-K and F-L. > > >=20 > > > That results in the following data flow: > > >=20 > > > K----->-----L > > > / \ > > > A->-B <-C D E F-> G<--H > > > \ / > > > I-----<-----J > > >=20 > > > Forward traffic reaches G on the link F-G. However, G has > > switched to > > > send and receive on G-J, and so drops traffic received from F. > > >=20 > > > Reverse traffic reaches B on C-B. However, B has switched > > to send and > > > receive on B-K, and so drops traffic received from C. > > >=20 > > > Thus traffic is lost in both directions. > > >=20 > > > Can anyone point out an error in this analysis? Is this=20 > a topology=20 > > > that there is interest in supporting? > > >=20 > > > Thanks, > > >=20 > > > Nic > > >=20 > >=20 >=20 Envelope-to: ccamp-data0@psg.com Delivery-date: Wed, 25 Feb 2009 15:00:07 +0000 From: Nic Neate To: ALU - Dimitri Papadimitriou , "ccamp@ops.ietf.org" CC: labn - Lou Berger , "IBryskin@advaoptical.com" , Aria - Adrian Farrel Personal Date: Wed, 25 Feb 2009 14:57:57 +0000 Subject: RE: Segment protection failure when recovery LSPs overlap Thread-Topic: Segment protection failure when recovery LSPs overlap Thread-Index: AcmTbJqCpUPEN1zcQXekkfeOOEhwqgBDqa7wAEvKy4AALag1kAADOWFA Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C7B63DBF1@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi Dimitri, I don't think that solves this issue. Let me restate the problem with more= detail on the master/slave behaviour. We have the following topology, where the LSP A-B-C-D-E-F-G-H has 1:1 segme= nt protection with extra traffic, and the link D-E fails: > > K-----------L > > / \ > > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD x E=3D=3D=3DF=3D=3D= =3DG=3D=3D=3DH > > \ / > > I-----------J RFC 4426 defines a master/slave relationship for the endpoints of the recov= ery LSPs. - For the recovery LSP B-K-L-F, either B or F will be the master, controll= ing switchover onto that recovery LSP. - For the recovery LSP C-I-J-G, either C or G will be the master, controll= ing switchover onto that recovery LSP. However, there is no mechanism defined for electing the masters. Rather, R= FC 4872 defines the switchover procedures for 1:1 protection, and states th= at the first endpoint of the recovery LSP to detect the failure is the one = that initiates switchover (http://tools.ietf.org/html/rfc4872#section-7.2). In this example, C and F are closest to the failure, and have their NOTIFY_= REQUEST objects at the top of the stack at D and E respectively. It is the= refore likely that C and F will detect the failure before B and G, and so C= and F will be the masters. That presents the problem that C and F will both attempt to initiate a swit= chover using their respective recovery LSPs, leading to the data loss descr= ibed in my original mail. If there was a way to force B and C to be masters then your suggestion that= B should avoid triggering protection switching before C may work. However= , that is explicitly not considered in 1:1 protection switching. See Note = 1 in http://tools.ietf.org/html/rfc4872#section-7.2: Note 1: a 2-phase protection-switching signaling is used in the present context; a 3-phase signaling (see [RFC4426]) that would imply a notification message, a switchover request, and a switchover response messages is not considered here. Nic -----Original Message----- From: ALU - Dimitri Papadimitriou=20 Sent: 24 February 2009 09:27 To: Nic Neate; ccamp@ops.ietf.org Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian Farrel Perso= nal Subject: RE: Segment protection failure when recovery LSPs overlap Nic, I will restate, in all protection scheme there is a master slave mechanism.= Now concerning the SRRO: C (and B) and F (and G) are generators in the ups= tream and downstream direction. So the SRRO are known to B and it is what w= e are interested in that B does not trigger recovery before C and the same = for F and G i.e that G does not trigger recovery before F. Thanks, -dimitri. > -----Original Message----- > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > Sent: Monday, February 23, 2009 4:13 PM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian Farrel=20 > Personal > Subject: RE: Segment protection failure when recovery LSPs overlap >=20 > Hi Dimitri, >=20 > We had wondered about the SRRO as a possible solution to this problem=20 > as well. However, there are a couple of issues as the protocol=20 > currently stands. >=20 > - SRROs can only be present in Path messages between the merge node=20 > and the egress, and in Resv messages between the branch node and the=20 > ingress. See > http://tools.ietf.org/html/rfc4873#section-2 and=20 > http://tools.ietf.org/html/rfc4873#section-5.2. Therefore, C does not=20 > have the SRRO for recovery LSP B-K-L-F, and F does not have the SRRO=20 > for recovery LSP C-I-J-G. >=20 > - The inclusion of the SRRO is optional, controlled via the=20 > segment-recording-desired flag in the SESSION_ATTRIBUTE object=20 > (http://tools.ietf.org/html/rfc4873#section-5.2). If the SRRO is=20 > required in order to avoid data loss then it needs to be mandatory. >=20 > So I think we need a protocol extension in order to provide a=20 > signaling-based solution. >=20 > Nic >=20 >=20 > -----Original Message----- > From: ALU - Dimitri Papadimitriou > Sent: 21 February 2009 23:51 > To: Nic Neate; ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian Farrel=20 > Personal > Subject: RE: Segment protection failure when recovery LSPs overlap >=20 > Nic, >=20 > RFC4873 by means of SRRO allows nodes to determine existence of=20 > upstream/downstream recovery segments as carried in Path/Resv message. > Combined with RFC4426 and RFC4428 that refers to master/slave it=20 > results that either C (or F) trigger a recovery action by means of=20 > disjoint recovery segments. >=20 > Thanks, > -d. >=20 > > -----Original Message----- > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > Sent: Friday, February 20, 2009 4:05 PM > > To: ccamp@ops.ietf.org > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU=20 > > Dimitri; Aria - Adrian Farrel Personal > > Subject: Segment protection failure when recovery LSPs overlap > >=20 > > Hi CCAMP, > >=20 > > I'd like to raise one more issue with RFC4873 segment > recovery, which > > I believe will lead to data loss when overlapping segment recovery=20 > > LSPs are used. > >=20 > > RFC4873 allows topologies like this one: > >=20 > > K-----------L > > / \ > > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE=3D=3D=3DF= =3D=3D=3DG=3D=3D=3DH > > \ / > > I-----------J > >=20 > > A working LSP A-B-C-D-E-F-G-H is protected by two > overlapping segment > > recovery LSPs: B-K-L-F and C-I-J-G. The recovery scheme is 1:1=20 > > protection with extra traffic. > >=20 > > Suppose the link D-E fails: > >=20 > > K-----------L > > / \ > > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD x E=3D=3D=3DF=3D=3D= =3DG=3D=3D=3DH > > \ / > > I-----------J > >=20 > > My understanding is that the failure will be handled as follows. > >=20 > > - D detects the link failure, and sends Notify to C (first Notify=20 > > object > > in the received Path). C and G exchanged Notify > messages to remove > > extra traffic from the C-I-J-G repair, and then send and receive=20 > > traffic from the working LSP on C-I and G-J. > >=20 > > - Meanwhile, E also detects the failure, and sends Notify > to F (first > > Notify object in the received Resv). F likewise exchanges Notify > > messages with B to remove extra traffic from the B-K-L-F repair,=20 > > and > > and then send and receive working LSP traffic on B-K and F-L. > >=20 > > That results in the following data flow: > >=20 > > K----->-----L > > / \ > > A->-B <-C D E F-> G<--H > > \ / > > I-----<-----J > >=20 > > Forward traffic reaches G on the link F-G. However, G has > switched to > > send and receive on G-J, and so drops traffic received from F. > >=20 > > Reverse traffic reaches B on C-B. However, B has switched > to send and > > receive on B-K, and so drops traffic received from C. > >=20 > > Thus traffic is lost in both directions. > >=20 > > Can anyone point out an error in this analysis? Is this a topology=20 > > that there is interest in supporting? > >=20 > > Thanks, > >=20 > > Nic > >=20 >=20 Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 24 Feb 2009 23:04:48 +0000 Message-ID: <752F55EE82A64521B39F171077F033A3@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "PAPADIMITRIOU Dimitri" Cc: Subject: Re: One last comment on draft-ietf-ccamp-ethernet-traffic-parameters-06 Date: Tue, 24 Feb 2009 23:03:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit >> Dimitri, can you confirm please that you are happy to have >> the new IPR boilerplate attached to the work. > > Which IPR do you refer to ? Is there yet a new one (I have > sometimes the impression that the IPR boilerplates move > faster than our own drafts) ? idnits is your friend :-) Or find a very recently submitted I-D and copy. XML template is supposedly up-to-date. >> Also, in Section 1 you have... >> >> These traffic parameters MUST be used when the L2SC value is >> specified in the LSP Switching Type field of a Generalized Label >> Request (see [RFC3471]) and the LSP encoding type is Ethernet. For >> example: >> >> o For Ethernet Private Line (EPL) services [MEF6], these traffic >> parameters are applicable non-discriminately to all EVCs >> crossing a given port. >> >> Does "all EVCs" mean "each EVC" or "shared amongst the group >> of EVCs"? > > The former, I will correct in the next release. Thanks. I think you had a couple of other minor comment. The sooner you can respin, the sooner I can pass the I-D on to Ross. Cheers, Adrian Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 24 Feb 2009 22:40:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: One last comment on draft-ietf-ccamp-ethernet-traffic-parameters-06 Date: Tue, 24 Feb 2009 23:39:12 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801CF87EE@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: One last comment on draft-ietf-ccamp-ethernet-traffic-parameters-06 Thread-Index: AcmWy8aQ8fkYUBI/TfeJnsbhquvGtwABGIJg From: "PAPADIMITRIOU Dimitri" To: "Adrian Farrel" Cc: =20 Hi Adrian, > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Tuesday, February 24, 2009 11:04 PM > To: PAPADIMITRIOU Dimitri > Cc: ccamp@ops.ietf.org > Subject: One last comment on=20 > draft-ietf-ccamp-ethernet-traffic-parameters-06 >=20 > Hi, >=20 > I did a re-review as last call completed. >=20 > There are some formatting issues with the current I-D, but=20 > those are easy to=20 > sort out. >=20 > Dimitri, can you confirm please that you are happy to have=20 > the new IPR boilerplate attached to the work. Which IPR do you refer to ? Is there yet a new one (I have sometimes the impression that the IPR boilerplates move faster than our own drafts) ? > Also, in Section 1 you have... >=20 > These traffic parameters MUST be used when the L2SC value is > specified in the LSP Switching Type field of a Generalized Label > Request (see [RFC3471]) and the LSP encoding type is Ethernet. For > example: >=20 > o For Ethernet Private Line (EPL) services [MEF6], these traffic > parameters are applicable non-discriminately to all EVCs=20 > crossing a > given port. >=20 > Does "all EVCs" mean "each EVC" or "shared amongst the group of EVCs"? The former, I will correct in the next release. > If you can clarify, we will advance the draft. Thanks, -dimitri. > Thanks, > Adrian=20 >=20 >=20 Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 24 Feb 2009 22:05:23 +0000 Message-ID: <5562FA1F4F4A4B2C8ED4FD2A69BBB1D8@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Dimitri Papadimitriou" Cc: Subject: One last comment on draft-ietf-ccamp-ethernet-traffic-parameters-06 Date: Tue, 24 Feb 2009 22:03:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, I did a re-review as last call completed. There are some formatting issues with the current I-D, but those are easy to sort out. Dimitri, can you confirm please that you are happy to have the new IPR boilerplate attached to the work. Also, in Section 1 you have... These traffic parameters MUST be used when the L2SC value is specified in the LSP Switching Type field of a Generalized Label Request (see [RFC3471]) and the LSP encoding type is Ethernet. For example: o For Ethernet Private Line (EPL) services [MEF6], these traffic parameters are applicable non-discriminately to all EVCs crossing a given port. Does "all EVCs" mean "each EVC" or "shared amongst the group of EVCs"? If you can clarify, we will advance the draft. Thanks, Adrian Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 24 Feb 2009 18:36:40 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [mpls-tp] 2nd wg last call on draft-ietf-mpls-tp-gach-gal Date: Tue, 24 Feb 2009 13:34:07 -0500 Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE193A7FD2@zcarhxm2.corp.nortel.com> Thread-Topic: [mpls-tp] 2nd wg last call on draft-ietf-mpls-tp-gach-gal Thread-Index: AcmWn8Efk5GurTo4ShOXgqKXjG6w5gAA52mw From: "David Allan" To: "Loa Andersson" , , , , , "ITU-T ad hoc team on MPLS-TP" , "George Swallow" , "Ross Callon" , "David Ward" , "Malcolm Betts" , "VIGOUREUX MARTIN" Well I'll make the same comment again.... In section 4.3 it states... o Unlike the mechanisms described and referenced in RFC 3429 [18], MPLS-TP maintenance messages will not reside immediately after the GAL but instead behind the ACH, which itself resides after the bottom of the label stack. This ensures that OAM, using the G-ACh, complies with RFC 4928 [11]. While RFC 4928 says It must also be noted that LSRs that correctly identify a payload as not being IP most often will load-share traffic across multiple equal-cost paths based on the label stack. Any reserved label, no matter where it is located in the stack, may be included in the computation for load balancing. Modification of the label stack between packets of a single flow could result in re-ordering that flow. That is, were an explicit null or a router-alert label to be added to a packet, that packet could take a different path through the network. So the mere presence of the GAL will violate RFC 4928....the presence of the GACH cannot fix this...and claiming the GACH does provide compliance is misleading....the paragraph in section 4.3 should be deleted... Cheers Dave =20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, February 24, 2009 5:25 AM To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ops.ietf.org; pwe3@ietf.org; ITU-T ad hoc team on MPLS-TP; George Swallow; Ross Callon; David Ward; Betts, Malcolm (CAR:X632); VIGOUREUX MARTIN Subject: [mpls-tp] 2nd wg last call on draft-ietf-mpls-tp-gach-gal All, an updated version (-02) of the draft-ietf-mpls-tp-gach-gal has been published. The draft is found at: http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02 Since the updates are significant this is to initiate a 2 week working group last call on the new version. Please send your comments to the mpls-tp@ietf.org mailing list. The working group last call will end on March 11. /Loa --=20 Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 8 632 77 14 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 24 Feb 2009 10:25:48 +0000 Message-ID: <49A3CAFD.9060806@pi.nu> Date: Tue, 24 Feb 2009 11:25:01 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, ccamp@ops.ietf.org, pwe3@ietf.org, ITU-T ad hoc team on MPLS-TP , George Swallow , Ross Callon , David Ward , Malcolm Betts , VIGOUREUX MARTIN Subject: 2nd wg last call on draft-ietf-mpls-tp-gach-gal Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, an updated version (-02) of the draft-ietf-mpls-tp-gach-gal has been published. The draft is found at: http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02 Since the updates are significant this is to initiate a 2 week working group last call on the new version. Please send your comments to the mpls-tp@ietf.org mailing list. The working group last call will end on March 11. /Loa -- Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 8 632 77 14 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 24 Feb 2009 09:32:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Segment protection failure when recovery LSPs overlap Date: Tue, 24 Feb 2009 10:26:31 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801CF8342@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Segment protection failure when recovery LSPs overlap Thread-Index: AcmTbJqCpUPEN1zcQXekkfeOOEhwqgBDqa7wAEvKy4AALag1kA== From: "PAPADIMITRIOU Dimitri" To: "Nic Neate" , Cc: "labn - Lou Berger" , , "Aria - Adrian Farrel Personal" Nic, I will restate, in all protection scheme there is a master slave mechanism. Now concerning the SRRO: C (and B) and F (and G) are generators in the upstream and downstream direction. So the SRRO are known to B and it is what we are interested in that B does not trigger recovery before C and the same for F and G i.e that G does not trigger recovery before F. Thanks, -dimitri. > -----Original Message----- > From: Nic Neate [mailto:Nic.Neate@dataconnection.com]=20 > Sent: Monday, February 23, 2009 4:13 PM > To: PAPADIMITRIOU Dimitri; ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel Personal > Subject: RE: Segment protection failure when recovery LSPs overlap >=20 > Hi Dimitri, >=20 > We had wondered about the SRRO as a possible solution to this=20 > problem as well. However, there are a couple of issues as=20 > the protocol currently stands. >=20 > - SRROs can only be present in Path messages between the=20 > merge node and the egress, and in Resv messages between the=20 > branch node and the ingress. See=20 > http://tools.ietf.org/html/rfc4873#section-2 and=20 > http://tools.ietf.org/html/rfc4873#section-5.2. Therefore, C=20 > does not have the SRRO for recovery LSP B-K-L-F, and F does=20 > not have the SRRO for recovery LSP C-I-J-G. >=20 > - The inclusion of the SRRO is optional, controlled via the=20 > segment-recording-desired flag in the SESSION_ATTRIBUTE=20 > object (http://tools.ietf.org/html/rfc4873#section-5.2). If=20 > the SRRO is required in order to avoid data loss then it=20 > needs to be mandatory. >=20 > So I think we need a protocol extension in order to provide a=20 > signaling-based solution. >=20 > Nic >=20 >=20 > -----Original Message----- > From: ALU - Dimitri Papadimitriou=20 > Sent: 21 February 2009 23:51 > To: Nic Neate; ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria -=20 > Adrian Farrel Personal > Subject: RE: Segment protection failure when recovery LSPs overlap >=20 > Nic,=20 >=20 > RFC4873 by means of SRRO allows nodes to determine existence=20 > of upstream/downstream recovery segments as carried in=20 > Path/Resv message. > Combined with RFC4426 and RFC4428 that refers to master/slave=20 > it results that either C (or F) trigger a recovery action by=20 > means of disjoint recovery segments.=20 >=20 > Thanks, > -d. >=20 > > -----Original Message----- > > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > > Sent: Friday, February 20, 2009 4:05 PM > > To: ccamp@ops.ietf.org > > Cc: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU=20 > > Dimitri; Aria - Adrian Farrel Personal > > Subject: Segment protection failure when recovery LSPs overlap > >=20 > > Hi CCAMP, > >=20 > > I'd like to raise one more issue with RFC4873 segment=20 > recovery, which=20 > > I believe will lead to data loss when overlapping segment recovery=20 > > LSPs are used. > >=20 > > RFC4873 allows topologies like this one: > >=20 > > K-----------L > > / \ > > = A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE=3D=3D=3DF=3D=3D=3DG=3D=3D=3DH > > \ / > > I-----------J > >=20 > > A working LSP A-B-C-D-E-F-G-H is protected by two=20 > overlapping segment=20 > > recovery LSPs: B-K-L-F and C-I-J-G. The recovery scheme is 1:1=20 > > protection with extra traffic. > >=20 > > Suppose the link D-E fails: > >=20 > > K-----------L > > / \ > > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD x = E=3D=3D=3DF=3D=3D=3DG=3D=3D=3DH > > \ / > > I-----------J > >=20 > > My understanding is that the failure will be handled as follows. > >=20 > > - D detects the link failure, and sends Notify to C (first Notify=20 > > object > > in the received Path). C and G exchanged Notify=20 > messages to remove > > extra traffic from the C-I-J-G repair, and then send and receive=20 > > traffic from the working LSP on C-I and G-J. > >=20 > > - Meanwhile, E also detects the failure, and sends Notify=20 > to F (first > > Notify object in the received Resv). F likewise exchanges Notify > > messages with B to remove extra traffic from the B-K-L-F repair,=20 > > and > > and then send and receive working LSP traffic on B-K and F-L. > >=20 > > That results in the following data flow: > >=20 > > K----->-----L > > / \ > > A->-B <-C D E F-> G<--H > > \ / > > I-----<-----J > >=20 > > Forward traffic reaches G on the link F-G. However, G has=20 > switched to=20 > > send and receive on G-J, and so drops traffic received from F. > >=20 > > Reverse traffic reaches B on C-B. However, B has switched=20 > to send and=20 > > receive on B-K, and so drops traffic received from C. > >=20 > > Thus traffic is lost in both directions. > >=20 > > Can anyone point out an error in this analysis? Is this a topology=20 > > that there is interest in supporting? > >=20 > > Thanks, > >=20 > > Nic > >=20 >=20 Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 23 Feb 2009 15:13:36 +0000 From: Nic Neate To: ALU - Dimitri Papadimitriou , "ccamp@ops.ietf.org" CC: labn - Lou Berger , "IBryskin@advaoptical.com" , Aria - Adrian Farrel Personal Date: Mon, 23 Feb 2009 15:12:41 +0000 Subject: RE: Segment protection failure when recovery LSPs overlap Thread-Topic: Segment protection failure when recovery LSPs overlap Thread-Index: AcmTbJqCpUPEN1zcQXekkfeOOEhwqgBDqa7wAEvKy4A= Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C7B2885DB@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi Dimitri, We had wondered about the SRRO as a possible solution to this problem as we= ll. However, there are a couple of issues as the protocol currently stands= . - SRROs can only be present in Path messages between the merge node and th= e egress, and in Resv messages between the branch node and the ingress. Se= e http://tools.ietf.org/html/rfc4873#section-2 and http://tools.ietf.org/ht= ml/rfc4873#section-5.2. Therefore, C does not have the SRRO for recovery L= SP B-K-L-F, and F does not have the SRRO for recovery LSP C-I-J-G. - The inclusion of the SRRO is optional, controlled via the segment-record= ing-desired flag in the SESSION_ATTRIBUTE object (http://tools.ietf.org/htm= l/rfc4873#section-5.2). If the SRRO is required in order to avoid data los= s then it needs to be mandatory. So I think we need a protocol extension in order to provide a signaling-bas= ed solution. Nic -----Original Message----- From: ALU - Dimitri Papadimitriou=20 Sent: 21 February 2009 23:51 To: Nic Neate; ccamp@ops.ietf.org Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian Farrel Perso= nal Subject: RE: Segment protection failure when recovery LSPs overlap Nic,=20 RFC4873 by means of SRRO allows nodes to determine existence of upstream/do= wnstream recovery segments as carried in Path/Resv message. Combined with RFC4426 and RFC4428 that refers to master/slave it results th= at either C (or F) trigger a recovery action by means of disjoint recovery = segments.=20 Thanks, -d. > -----Original Message----- > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > Sent: Friday, February 20, 2009 4:05 PM > To: ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com; PAPADIMITRIOU=20 > Dimitri; Aria - Adrian Farrel Personal > Subject: Segment protection failure when recovery LSPs overlap >=20 > Hi CCAMP, >=20 > I'd like to raise one more issue with RFC4873 segment recovery, which=20 > I believe will lead to data loss when overlapping segment recovery=20 > LSPs are used. >=20 > RFC4873 allows topologies like this one: >=20 > K-----------L > / \ > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE=3D=3D=3DF= =3D=3D=3DG=3D=3D=3DH > \ / > I-----------J >=20 > A working LSP A-B-C-D-E-F-G-H is protected by two overlapping segment=20 > recovery LSPs: B-K-L-F and C-I-J-G. The recovery scheme is 1:1=20 > protection with extra traffic. >=20 > Suppose the link D-E fails: >=20 > K-----------L > / \ > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD x E=3D=3D=3DF=3D=3D= =3DG=3D=3D=3DH > \ / > I-----------J >=20 > My understanding is that the failure will be handled as follows. >=20 > - D detects the link failure, and sends Notify to C (first Notify=20 > object > in the received Path). C and G exchanged Notify messages to remove > extra traffic from the C-I-J-G repair, and then send and receive=20 > traffic from the working LSP on C-I and G-J. >=20 > - Meanwhile, E also detects the failure, and sends Notify to F (first > Notify object in the received Resv). F likewise exchanges Notify > messages with B to remove extra traffic from the B-K-L-F repair,=20 > and > and then send and receive working LSP traffic on B-K and F-L. >=20 > That results in the following data flow: >=20 > K----->-----L > / \ > A->-B <-C D E F-> G<--H > \ / > I-----<-----J >=20 > Forward traffic reaches G on the link F-G. However, G has switched to=20 > send and receive on G-J, and so drops traffic received from F. >=20 > Reverse traffic reaches B on C-B. However, B has switched to send and=20 > receive on B-K, and so drops traffic received from C. >=20 > Thus traffic is lost in both directions. >=20 > Can anyone point out an error in this analysis? Is this a topology=20 > that there is interest in supporting? >=20 > Thanks, >=20 > Nic >=20 Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 23 Feb 2009 14:27:56 +0000 Message-ID: <49A2B201.8050603@pi.nu> Date: Mon, 23 Feb 2009 15:26:09 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, pwe3@ietf.org, ccamp@ops.ietf.org, l2vpn@ietf.org, Ross Callon , David Ward , ITU-T ad hoc team on MPLS-TP Subject: new mpls(-tp) working group document Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, the poll for draft-gray-mpls-tp-nm-req to become MPLS WG document has ended with full support. Authors, please republish as: draft-ietf-mpls-tp-nm-req-00 /Loa -- Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 8 632 77 14 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 23 Feb 2009 03:07:55 +0000 From: "Shoichiro Seno" To: , , , , Subject: iPOP 2009 CFP Deadline Extended to March 2nd Date: Mon, 23 Feb 2009 12:02:51 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: Acl83napCLZqADbiT0CXLGI2JmotcQH+EUEgBCKnbYA= Dear CAMP, PCE, L1VPN, MPLS and MPLS-TP subscribers, (Apologies for disturbing MLs with multiple copies; appreciated if you can forward this to potentially interested people.) Submission deadline to iPOP 2009, the 5th Conference on IP + Optical Network, has been extended to March 2nd. See details below. ---- Following the successful events of iPOP, the 5th Conference on IP + Optical Network (iPOP 2009) will be held at NICT Headquarters, Koganei, Tokyo, Japan, June 11-12, 2009. The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. See Call for presentation details at http://www.pilab.jp/ipop2009/ Important Dates: Submission deadline of one page summary: March 2, 2009 Notification of acceptance: April 3, 2009 Submission deadline of final presentation slides: April 24, 2009 The Technical Program Committee for iPOP 2009 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not limited to the following: * GMPLS/ASON technologies * GMPLS Network management, OA&M * Multi-layer network (MLN) / Multi-region network (MRN) * Path Computation Element (PCE), Traffic engineering * Inter-area/Inter-AS network * L1VPN, Bandwidth on Demand, and Photonic Grid * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Carrier Ethernet and MPLS-TP * Photonic Network for NxGN and NwGN * Application with high-bandwidth demand * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstract of 400 words and a maximum of 1 page, including figures and diagrams, speaker's name, affiliation, and contact information to the Technical Program Committee at ipop2009-CFP@pilab.jp. Kind regards, Sho Seno Exhibition Committee Vice-chair, iPOP 2009 -- Shoichiro Seno (E-mail) Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Information Technology R&D Center, Mitsubishi Electric Corporation Envelope-to: ccamp-data0@psg.com Delivery-date: Sat, 21 Feb 2009 23:53:38 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Segment protection failure when recovery LSPs overlap Date: Sun, 22 Feb 2009 00:51:12 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801CA5044@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: Segment protection failure when recovery LSPs overlap Thread-Index: AcmTbJqCpUPEN1zcQXekkfeOOEhwqgBDqa7w From: "PAPADIMITRIOU Dimitri" To: "Nic Neate" , Cc: "labn - Lou Berger" , , "Aria - Adrian Farrel Personal" Nic,=20 RFC4873 by means of SRRO allows nodes to determine existence of upstream/downstream recovery segments as carried in Path/Resv message. Combined with RFC4426 and RFC4428 that refers to master/slave it results that either C (or F) trigger a recovery action by means of disjoint recovery segments.=20 Thanks, -d. > -----Original Message----- > From: Nic Neate [mailto:Nic.Neate@dataconnection.com]=20 > Sent: Friday, February 20, 2009 4:05 PM > To: ccamp@ops.ietf.org > Cc: labn - Lou Berger; IBryskin@advaoptical.com;=20 > PAPADIMITRIOU Dimitri; Aria - Adrian Farrel Personal > Subject: Segment protection failure when recovery LSPs overlap >=20 > Hi CCAMP, >=20 > I'd like to raise one more issue with RFC4873 segment=20 > recovery, which I believe will lead to data loss when=20 > overlapping segment recovery LSPs are used. >=20 > RFC4873 allows topologies like this one: >=20 > K-----------L > / \ > = A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE=3D=3D=3DF=3D=3D=3DG=3D=3D=3DH > \ / > I-----------J >=20 > A working LSP A-B-C-D-E-F-G-H is protected by two overlapping=20 > segment recovery LSPs: B-K-L-F and C-I-J-G. The recovery=20 > scheme is 1:1 protection with extra traffic. >=20 > Suppose the link D-E fails: >=20 > K-----------L > / \ > A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD x = E=3D=3D=3DF=3D=3D=3DG=3D=3D=3DH > \ / > I-----------J >=20 > My understanding is that the failure will be handled as follows. >=20 > - D detects the link failure, and sends Notify to C (first=20 > Notify object > in the received Path). C and G exchanged Notify messages=20 > to remove=20 > extra traffic from the C-I-J-G repair, and then send and receive=20 > traffic from the working LSP on C-I and G-J. >=20 > - Meanwhile, E also detects the failure, and sends Notify to=20 > F (first=20 > Notify object in the received Resv). F likewise exchanges Notify > messages with B to remove extra traffic from the B-K-L-F=20 > repair, and > and then send and receive working LSP traffic on B-K and F-L. >=20 > That results in the following data flow: >=20 > K----->-----L > / \ > A->-B <-C D E F-> G<--H > \ / > I-----<-----J >=20 > Forward traffic reaches G on the link F-G. However, G has=20 > switched to send and receive on G-J, and so drops traffic=20 > received from F. >=20 > Reverse traffic reaches B on C-B. However, B has switched to=20 > send and receive on B-K, and so drops traffic received from C. >=20 > Thus traffic is lost in both directions. >=20 > Can anyone point out an error in this analysis? Is this a=20 > topology that there is interest in supporting? >=20 > Thanks, >=20 > Nic >=20 Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 20 Feb 2009 20:41:08 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Tj+wvpbGN6szVaYx4+f5tJR6ugSGtB+uhTyeVot69yPKWVXExE2NUK/r4Y/RAUU0ezgf/G68m2ikfpcFL7Y0LXSqmQNppGflKd7ZD1jJ6yR5nFW3dPxwUSaRiTq89vFM; Message-ID: <499F150B.1030202@labn.net> Date: Fri, 20 Feb 2009 15:39:39 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Adrian Farrel CC: Don Fedyk , ccamp@ops.ietf.org, Lou Berger Subject: Re: Chair review of draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit See in-line for responses... On 2/19/2009 9:27 AM, Adrian Farrel wrote: > > And another draft... > which is much appreciated! > Adrian > > === > IPR boilerplate, blah blah > > === > > Abstract and Section 1 > > s/technology independent/technology-independent/ > sure, whatever... > === > > Section 1 > > s/Both of extensions/Both of these extensions/ > > === > > In general, I think the definition of DCSC in this document is missing > some clarity. > > For example, in section 2 we have > One type of > switching that is not well represented in this current set switching > that takes all data received on an ingress port and switches it > through a network to an egress port. > which implies that you are describing a service request signaling type. > > But you also have > DCSC interfaces are able to > support switching of the whole digital channel presented on single > channel interfaces. > > Perhaps a picture would help? > It might also be helpful to say in the document why FSC is not suitable. > done. > I'm wondering if the D in DCSC actually stands for Digital. > > === > > IANA section > > Along with the allocation from the Switching Type registry, you should > remind IANA to make an entry in IANAGmplsSwitchingTypeTC at > http://www.iana.org/assignments/ianagmplstc-mib > okay. > === > > Sections 2 and 3 > > Port labels, as defined in [RFC3471], SHOULD be used for LSPs > signaled using the DCSC Switching Type. > 3. Generalized Channel_Set Label Related Formats > This section defines a new type of generalized label and updates > related objects. > > This text is not immediately obvious. > The Port label in 3471 is 32 bits. > The label defined in section 3 seems to have variable length depending > on what it contains. > > Perhaps the paragraph you need in section 2 is: > Port labels, as defined in [RFC3471], SHOULD be used for LSPs > signaled using the DCSC Switching Type in the Generalized Label > Request object. > how about: Port labels, as defined in [RFC3471], SHOULD be used for LSPs signaled using the DCSC Switching Type. The DCSC Switching Type may be used with wither the in the Generalized Label Request object, [RFC3473], or the Generalized Channel_Set LABEL_REQUEST Object defined below. keep in mind that Generalized Channel_Set and DCSC are orthogonal extensions... > === > > Section 3.1 (slightly ties in with the previous point) > > It isn't clear from the text why you need a new type of label request > object. > The reader might assume that it would be enough to set the switching > type as is done for all other generalized labels. > In fact, it has been the operational assumption of GMPLS that the > parameters of the Generalized Label Request were enough to set the > context for the label type that would be used. It is a shame to reverse > this. > the new request object is used to indicate that a channel_set label is to be used vs a generalized (or MPLS) label. I don't see how switching type can be used to request/indicate label type... > === > > Section 3.2 > > I would like you to make direct reference to RFC 4606. Why is label > concatenation as described in section 3 not appropriate in this case? > Why is it necessary to invent a new mechanism? (Yes, I know why, but you > haven't explained the limitations of simple concatenation.) > added: Simple concatenation of labels as is done in [RFC4606] was deemed impractical given the large number of VLAN IDs (up to 4096) that may need to be communicated. > What do you mean by: > The format of the Generalized > Channel_Set LABEL Object is based on the LABEL_SET object defined in > [RFC3473]. > I don't think it is. I think it is the format of the Channel_Set > subobject that is based on the LABEL_SET object. yes. the subobject is part of the object so the statement is correct. the next sentence explains the difference. > > === > > Section 3.2 > > Subchannel: Variable > > See [RFC3471] for a description of this field. Note that this > field may not be 32 bit aligned. > > s/may/might/ > sure. > I think it is worth highlighting the context for the meaning and the > length of the subchannel ID > can you be more specific? I don't understand what you are asking for. > === > > Section 3.3 > > Don't you think it is a layer of complexity too far to have a Label Set > made up of a set of Channel_Set Labels each made up of a series of > Channel_Set subobjects each made up of a set of channels? yes, this is a tad excessive. I'm not sure why anyone would construct such an object though... > > What on earth is the meaning of the Label Set if the action is set to > "inclusive range" or "exclusive range" and the label entries are > Channel_Set labels? What if the Label Set says "inclusive list" and one > of the Channel_Set subobjects says "exclusive list", or the other way > around. > nothing that can't be represented with some nice logical expressions. > Perhaps you can set some limits on the action field in the Label Set etc? > Do you have a suggestions? > === > > Section 3.3 > > What happens with the use of this new label format in ERO and RRO label > subobjects? Isn't there serious risk of this making RSVP-TE completely > unworkable? actually, this is the whole reason to have the complete set defined in a single object (rather than the multiple objects used in LABEL_SET). The defined approach is better than the concatenated object approach where you have say, 1K concatenated labels, or the separate LSP approach where you have 1K LSPs each with a single label! > > === > > Section 5. > You should probably reference > draft-ietf-mpls-mpls-and-gmpls-security-framework-04.txt okay > > Doesn't a mechanism that allows a Path or Resv message to be > legitimately grown to be extremely large cause concern for security? Growth of RSVP messages has been raised numerous times before, but I've never heard anyone suggest that there was a security consideration to such growth. What issue are you referring to? > > === > > Would it be possible to add a short section of backward compatibility? > will do. Thanks again for the feedback, Lou > === > > > Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 20 Feb 2009 19:49:35 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=CAktRbc5ySkJ8uUUwRdFoWzHnQHBwtWUfvxoIHsLcDDqtn6rZMFg2Fvs1j4cgmAER2BlQgy33oulxkbwjPUrtbqvDzn74WizIiuCw3yY7HwUq87Kb5s5m77nBlKUbzGV; Message-ID: <499F0922.5010107@labn.net> Date: Fri, 20 Feb 2009 14:48:50 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Adrian Farrel CC: Don Fedyk , ccamp@ops.ietf.org, Lou Berger Subject: Re: Chair review of draft-ietf-ccamp-gmpls-ether-svcs-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit See in-line response below. On 2/18/2009 4:50 PM, Adrian Farrel wrote: > > Hi, > > A few comments. I think some of these qualify as issues. > > Thanks, > Adrian > > === > > IPR boilerplate > > === > > Abstract > OLD > Specifically, switching in support of Ethernet private > line service and Ethernet virtual private line service. > NEW-EITHER > Specifically, switching in support of the Ethernet private > line service and the Ethernet virtual private line service. > NEW-OR > Specifically, switching in support of Ethernet private > line services and Ethernet virtual private line services. > sure - definitely a major issue ;-) > === > > Abstract > Some of the > extensions defined in this document are generic in nature and not > specific to Ethernet. > > It is good that you have this statement. > I think you should split it to a separate paragraph and include a hint > as to which extensions you are referring to. That is, which > functions/features. Or have they all moved out to > draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt they've moved already, the line should have been dropped when [GMPLS-EXT] was split out. > > === > > Section 1.1 > s/Support for P2P and MP2MP service is/Support for P2P and MP2MP > services is/ > > === > > Section 2 para 2 > > s/is not modified/are not modified/ > > === > > Section 2.1 para 2 > > long identifiers > are carried in the attributes object > > Please clarify. The CALL_ATTRIBUTES object. yes on the above. > > === > > Section 2.1 para 2 > > As with the long call ID, the > Ethernet endpoint identifier is typically only relevant at the > ingress and egress nodes. > > === > > Section 2.1.1.1 > > A CALL_ATTRIBUTES object containing an Endpoint ID TLV MAY be > included in the signaling messages of an LSP (connection) associated > with an established call. Such objects are processed according to > [4420BIS]. > > As per our (elongated) discussion for the MLN extensions. I don't see > the value of including this object in a connection signaling message, > and I see some significant dangers (including a breach in the "need to > know" policy for the distribution of information within the Internet). > > But I have two issues with this paragraph. > > 1. You say "MAY be included", but nowhere in the spec do you > say why or what it might be used for. We are not in the habit of > defining mechanisms on the chance that they will be valuable at > some time in the future. If you have a specific use in mind, please > state it. Otherwise, we should delete this paragraph and let new > documents vary the rules when/if a use is found. > I think the primary value is providing the operator/carrier with additional OAM information on the LSP. > 2. Draft 4420-bis (now RFC 5420) does not mention this object > and it is not appropriate to reference it for processing rules. Looks like a broken reference to me, (wrong attributes object) should be [GMPLS-MRN]. > > === > > Section 2.1.1.1 > > Transit nodes supporting this document MUST propagate the Endpoint ID > TLV without modification. > > Are you sure this is what you want? > Isn't it the case that endpoint identifiers could be mapped at UNI and > E-NNI reference points? > the line will be removed - someone else commented on this too. > === > > Section 2.2 > > Signaling for Ethernet connections follows the procedures defined in > [RFC4974]. > > I wouldn't say that RFC 4974 was the normative reference for setting up > LSPs of any sort. > > === > > Section 2.2 > > In the context of Ethernet > connections, a call only exists when one or more LSPs (connections in > [RFC4974] terms) are present. An LSP will always be established > within the context of a call and, typically, only one LSP will be > used per call. > > This seems to be contradictory. > How can the LSP be "established within the context of a call" if the > call "can only exist when one or more LSPs are present"? > > But RFC 4974 explicitly states (section 6.1)... > Note that a Call MUST NOT be imposed upon a Connection that is > already established. > > In fact, 2.2.1 says: > When establishing an Ethernet connection the initiator MUST first > establish a Call per the procedures defined in [RFC4974]. > > So what is section 2.2 trying to say? sigh. how about: OLD: In the context of Ethernet connections, a call only exists when one or more LSPs (connections in [RFC4974] terms) are present. NEW: In the context of Ethernet connections, a call only is only established when one or more LSPs (connections in [RFC4974] terms) are needed. > > Would it be helpful to show the formal relationship between: > - Ethernet (virtual) connection > - GMPLS call > - GMPLS LSP == connection == Ethernet LSP > - EVPL connection > I think there is some real confusion because the LSP is switching > Ethernet and is a connection. But it is not your "Ethernet (virtual) > connection". > > For example, in section 2.3... > Ethernet connections established according to this document MUST use > the traffic parameters defined in [ETH-TRAFFIC] in the FLOWSPEC and > TSPEC objects. > But this should be "Ethernet LSPs" I think. > > === > > Section 2.3.1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type=3 | Length=8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IL2CP | EL2CP | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > See [ETH-TRAFFIC] for a description of the Type and Length fields. > Per [ETH-TRAFFIC], the Type field MUST be set to two (2) > > Hmmm. Presumably 3 == 2 for the purpose of this document? great catch, it should be 3. > > === > > Section 2.3.1 > > Don't you think IL2CP and EL2CP need to be under IANA's control? not at this point as current usage is per [MEF10.1] and 8011 and is unlikely to change. We can always revisit this if/when there ever is a need for more code point assignments. > > === > > Section 2.3.1 > Ethernet connections established according to this document MUST > include the L2CP TLV in the [ETH-TRAFFIC] traffic parameters carried > in the FLOWSPEC and TSPEC objects. > > What do I do if the TLV is not there in each case? what you always do you in RSVP when there's a malformed message. > > === > > Section 3 > s/services./service./ > > === > > Section 3.1 > > Would it be possible to change > OLD > EPL Service LSP Encoding Type > ----------- ----------------- > Type 1/MEF Ethernet (2) [RFC3471] > Type 2 Line (e.g., 8B/10B) (TBA by IANA) > NEW > EPL Service LSP Encoding Type Value Reference > ----------- ------------------- ---------------- --------------- > Type 1/MEF Ethernet 2 [RFC3471] > Type 2 Line (e.g., 8B/10B) 14 (TBA by IANA) [This document] > done. > === > > Section 4 > > Parameter Value > -------------- ----- > Switching Type TBD [NOTE: under discussion] > > Time to complete that discussion? > ;-) now says: Switching Type EVPL [This document] (TBA by IANA) (suggest value of 45) > === > > Section 4.1 para 1 > s/requires/require/ thanks. > > === > > Section 4.2 > Per [MEF6], the mapping of the single VLAN ID used at the incoming > interface of the ingress to a different VLAN ID at the outgoing > interface at the egress UNI is allowed for EVPL services that do not > support either bundling and VLAN ID preservation. > > Stack hit heap trying to parse this! > > How about... > > If an EVPL service supports neither bundling nor VLAN ID > preservation, then [MEF6] allows mapping of VLAN IDs. The VLAN ID > used at the incoming interface of the ingress UNI-C may be different > from the VLAN ID at the outgoing interface of the egress UNI-C. > > (Although I wonder if UNI-N is actually what is meant.) I'll take a pass at it. > === > > References will need updating. > idnits will help you identify what needs doing. > yup. Thanks again for the detailed review! Lou Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 20 Feb 2009 19:01:03 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=sfDiFmg6P9R8BuGeqY+To0dmqSZekpMJ6RA1baLp2Prvwl36ttW0Eg6WVyqEM6LzKjyPQ3HehKxPTJDIrqF4b7rDlb4U2X4nGZnXuEmml4LnR6ee46zq5ls7VRojIks9; Message-ID: <499EFD8A.6020809@labn.net> Date: Fri, 20 Feb 2009 13:59:22 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org, Lou Berger Subject: Re: Chair review of draft-ietf-ccamp-gmpls-mef-uni-01.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit See in-line responses below. On 2/18/2009 7:36 AM, Adrian Farrel wrote: > > Hi, > > Just a few thoughts. > > Cheers, > Adrian > > === > > Obviously, you'll need to use the new IPR boilerplate. yes, but which! > > === > > Abstract > > This document > supports the types of switching required to implied by the Ethernet > services > > Too many words? thanks. > > === > > Abstract > > in the context of the Metro Ethernet > Forum (MEF) and International Telecommunication Union (ITU) G.8011. > > This reads like the MEF wrote G.8011 together with the ITU. > Do you mean this? > > Perhaps the Abstract should mention MEF6 > The scope of MEF is a bit less than ITU, so I think it's not needed... > === > > Section 1 > > Paragraph 1 doesn't seem sure how many frameworks there are. > Perhaps > OLD > [MEF6] and [G.8011] provide parallel frameworks > NEW > [MEF6] and [G.8011] provide parallel views of a framework humm, I think the original phrasing is more accurate. > > === > > Figure 1 > > Are the arrows at the bottom of the figure (<----->) supposed to be > associated with the text "UNI" at the top of the figure? Maybe put them > together? sure. > > === > > Section 1.2 > Capitalise section heading, please. > > === > > Section 2 > I think you should add RFC4974 to your list of procedures that must be > followed unless specifically modified. okay > > === > > Section 2.2.1 > If the object or TLV > are not present, the node MUST discard the message. In this case, a > Message ID Acknowledgment MUST NOT be sent for the Notify message. > > I'm worried about this. > Most implementations handle the Message ID Ack before checking the > validity of the message. > > Further, simply discarding the message may result in the sender using a > rapid retry. > > Why can't you do the Ack and then send a Call Failed response? > just trying to conform to RFC2961: Note that MESSAGE_ID objects received in messages containing errors, i.e., are not syntactically valid, MUST NOT be acknowledged. > === > > Section 2.2.1 > > It looks to me that your solution only works with a single domain if the > source UNI-C does not know the destination UNI-C IP address. Why do you say this? The scope is only limited by the scope of a call. > > When the Endpoint ID TLV is located, the node MUST map the Endpoint > ID into an IP address associated with the egress edge-node. > > Does "egress edge-node" mean UNI-N? no as mentioned earlier in the document, an edge-node = the UNI-C. Not that it says an address address associated with the egress edge-node, which may not be the node itself. (consider the case of Call Segments per RFC 4974. > I think so, and given that you have been talking about UNI-C, it may > help to put... > > When the Endpoint ID TLV is located, the node MUST map the Endpoint > ID into an IP address associated with the egress edge-node (destination > UNI-N). > > In fact, however, in a multi-domain situation, the source UNI-N needs > only map to an E-NNI address, and so on across the network until the > final E-NNI maps to the UNI-N. Would you also allow a zero destination > address within the core network? Just trying to be consistent with Section 7 of RFC 4974 in this section. > > === > > Section 6 > > I think you have copied this from somewhere else! > I don't see any "new message object formats" in the document. > > Do you need to say why the use of a zero destination address is not a > security problem? You might also observe that a certain element of > access control is devolved to the UNI-N, and that this is consistent > with the operation of GMPLS calls. > > > > How about: This document makes use of the mechanisms defined in [GMPLS-ESVCS] and [RFC4974]. It does not in itself change the security models offered in each. (Note that the address resolution discussed in Section 2.2 above, parallels the replacement of information that takes occurs per Section 7.2 of [RFC4974].) See [GMPLS-ESVCS] and [RFC4974] for the security considerations that are relevant to and introduced by the base mechanisms used by this document. Much thanks for the comments. Lou Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 20 Feb 2009 15:05:52 +0000 From: Nic Neate To: "ccamp@ops.ietf.org" CC: labn - Lou Berger , "IBryskin@advaoptical.com" , ALU - Dimitri Papadimitriou , Aria - Adrian Farrel Personal Date: Fri, 20 Feb 2009 15:05:01 +0000 Subject: Segment protection failure when recovery LSPs overlap Thread-Topic: Segment protection failure when recovery LSPs overlap Thread-Index: AcmTbJqCpUPEN1zcQXekkfeOOEhwqg== Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD72075C7B287D8A@ENFIMBOX1.ad.datcon.co.uk> Accept-Language: en-US Content-Language: en-US acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi CCAMP, I'd like to raise one more issue with RFC4873 segment recovery, which I bel= ieve will lead to data loss when overlapping segment recovery LSPs are used= . RFC4873 allows topologies like this one: K-----------L / \ A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD=3D=3D=3DE=3D=3D=3DF=3D= =3D=3DG=3D=3D=3DH \ / I-----------J A working LSP A-B-C-D-E-F-G-H is protected by two overlapping segment recov= ery LSPs: B-K-L-F and C-I-J-G. The recovery scheme is 1:1 protection with = extra traffic. Suppose the link D-E fails: K-----------L / \ A=3D=3D=3DB=3D=3D=3DC=3D=3D=3DD x E=3D=3D=3DF=3D=3D=3DG= =3D=3D=3DH \ / I-----------J My understanding is that the failure will be handled as follows. - D detects the link failure, and sends Notify to C (first Notify object in the received Path). C and G exchanged Notify messages to remove=20 extra traffic from the C-I-J-G repair, and then send and receive=20 traffic from the working LSP on C-I and G-J. - Meanwhile, E also detects the failure, and sends Notify to F (first=20 Notify object in the received Resv). F likewise exchanges Notify messages with B to remove extra traffic from the B-K-L-F repair, and and then send and receive working LSP traffic on B-K and F-L. That results in the following data flow: K----->-----L / \ A->-B <-C D E F-> G<--H \ / I-----<-----J Forward traffic reaches G on the link F-G. However, G has switched to send= and receive on G-J, and so drops traffic received from F. Reverse traffic reaches B on C-B. However, B has switched to send and rece= ive on B-K, and so drops traffic received from C. Thus traffic is lost in both directions. Can anyone point out an error in this analysis? Is this a topology that th= ere is interest in supporting? Thanks, Nic= Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 20 Feb 2009 14:14:04 +0000 Message-ID: <499EBA4A.5020506@pi.nu> Date: Fri, 20 Feb 2009 15:12:26 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: the first MPLS-TP RFC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, we have our first MPLS-TP TFC: RFC 5317 Title: Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile Author: S. Bryant, Ed., L. Andersson, Ed. Status: Informational Date: February 2009 Mailbox: stbryant@cisco.com, loa@pi.nu Pages: 10, 68 Characters: 18367, 1411313 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-bryant-mpls-tp-jwt-report-00.txt URL: http://www.rfc-editor.org/rfc/rfc5317.txt /Loa -- Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 8 632 77 14 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 20 Feb 2009 12:36:47 +0000 Date: Fri, 20 Feb 2009 04:34:33 -0800 (PST) Message-Id: <200902201234.n1KCYXR9000231@boreas.isi.edu> To: adrian@olddog.co.uk, dimitri.papadimitriou@alcatel.be, jpv@cisco.com, arthi@juniper.net, rcallon@juniper.net, dward@cisco.com, adrian@olddog.co.uk, dbrungard@att.com Subject: [Editorial Errata Reported] RFC5420 (1689) From: RFC Errata System Cc: ah@TR-Sys.de, ccamp@ops.ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC5420, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5420&eid=1689 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 11.3, pg.19 Original Text ------------- a) The IANA has created a new registry and will manage the space of | attributes bit flags, numbering them in the usual IETF notation: ^ starting at zero and continuing at least through 31. b) Each bit should be tracked with the following qualities: - Bit number - Defining RFC - Name of bit | - Whether there is meaning in the Attribute Flags TLV on a Path | - Whether there is meaning in the Attribute Flags TLV on a Resv - Whether there is meaning in the RRO Attributes subobject Corrected Text -------------- a) The IANA has created a new registry and will manage the space of attribute bit flags, numbering them in the usual IETF notation: starting at zero and continuing at least through 31. b) Each bit should be tracked with the following qualities: - Bit number - Defining RFC - Name of bit | - Whether there is meaning in the Attribute Flags TLV on a Path message | - Whether there is meaning in the Attribute Flags TLV on a Resv message - Whether there is meaning in the RRO Attributes subobject Notes ----- Rationale: a) grammar fix in the body of RFC 5420 vs. RFC 4420 should also be reflected in the IANA Considerations (and in the IANA registry -- subject to independent report to IANA); b) language improvement applied in the body of the RFC should also be reflected in the IANA Considerations. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5420 (draft-ietf-ccamp-rfc4420bis-03) -------------------------------------- Title : Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) Publication Date : February 2009 Author(s) : A. Farrel, Ed., D. Papadimitriou, JP. Vasseur, A. Ayyangarps Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 20 Feb 2009 12:09:39 +0000 Date: Fri, 20 Feb 2009 04:05:51 -0800 (PST) Message-Id: <200902201205.n1KC5p9j018901@boreas.isi.edu> To: adrian@olddog.co.uk, dimitri.papadimitriou@alcatel.be, jpv@cisco.com, arthi@juniper.net, rcallon@juniper.net, dward@cisco.com, adrian@olddog.co.uk, dbrungard@att.com Subject: [Technical Errata Reported] RFC5420 (1688) From: RFC Errata System Cc: ah@TR-Sys.de, ccamp@ops.ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC5420, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5420&eid=1688 -------------------------------------- Type: Technical Reported by: Alfred Hoenes Section: 11.2,11.3 Original Text ------------- ... allocated only by IETF Consensus. ^^^^^^^^^ Corrected Text -------------- ... allocated only by IETF Review. ^^^^^^ Notes ----- Location: a) last paragraph of section 11.2 b) third paragraph of section 11.3 Rationale: Adaptation to updated IANA policy terminology as per RFC 5226 has been missed. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5420 (draft-ietf-ccamp-rfc4420bis-03) -------------------------------------- Title : Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) Publication Date : February 2009 Author(s) : A. Farrel, Ed., D. Papadimitriou, JP. Vasseur, A. Ayyangarps Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 19 Feb 2009 14:29:58 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lou Berger" , "Don Fedyk" Cc: Subject: Chair review of draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt Date: Thu, 19 Feb 2009 14:27:07 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit And another draft... Adrian === IPR boilerplate, blah blah === Abstract and Section 1 s/technology independent/technology-independent/ === Section 1 s/Both of extensions/Both of these extensions/ === In general, I think the definition of DCSC in this document is missing some clarity. For example, in section 2 we have One type of switching that is not well represented in this current set switching that takes all data received on an ingress port and switches it through a network to an egress port. which implies that you are describing a service request signaling type. But you also have DCSC interfaces are able to support switching of the whole digital channel presented on single channel interfaces. Perhaps a picture would help? It might also be helpful to say in the document why FSC is not suitable. I'm wondering if the D in DCSC actually stands for Digital. === IANA section Along with the allocation from the Switching Type registry, you should remind IANA to make an entry in IANAGmplsSwitchingTypeTC at http://www.iana.org/assignments/ianagmplstc-mib === Sections 2 and 3 Port labels, as defined in [RFC3471], SHOULD be used for LSPs signaled using the DCSC Switching Type. 3. Generalized Channel_Set Label Related Formats This section defines a new type of generalized label and updates related objects. This text is not immediately obvious. The Port label in 3471 is 32 bits. The label defined in section 3 seems to have variable length depending on what it contains. Perhaps the paragraph you need in section 2 is: Port labels, as defined in [RFC3471], SHOULD be used for LSPs signaled using the DCSC Switching Type in the Generalized Label Request object. === Section 3.1 (slightly ties in with the previous point) It isn't clear from the text why you need a new type of label request object. The reader might assume that it would be enough to set the switching type as is done for all other generalized labels. In fact, it has been the operational assumption of GMPLS that the parameters of the Generalized Label Request were enough to set the context for the label type that would be used. It is a shame to reverse this. === Section 3.2 I would like you to make direct reference to RFC 4606. Why is label concatenation as described in section 3 not appropriate in this case? Why is it necessary to invent a new mechanism? (Yes, I know why, but you haven't explained the limitations of simple concatenation.) What do you mean by: The format of the Generalized Channel_Set LABEL Object is based on the LABEL_SET object defined in [RFC3473]. I don't think it is. I think it is the format of the Channel_Set subobject that is based on the LABEL_SET object. === Section 3.2 Subchannel: Variable See [RFC3471] for a description of this field. Note that this field may not be 32 bit aligned. s/may/might/ I think it is worth highlighting the context for the meaning and the length of the subchannel ID === Section 3.3 Don't you think it is a layer of complexity too far to have a Label Set made up of a set of Channel_Set Labels each made up of a series of Channel_Set subobjects each made up of a set of channels? What on earth is the meaning of the Label Set if the action is set to "inclusive range" or "exclusive range" and the label entries are Channel_Set labels? What if the Label Set says "inclusive list" and one of the Channel_Set subobjects says "exclusive list", or the other way around. Perhaps you can set some limits on the action field in the Label Set etc? === Section 3.3 What happens with the use of this new label format in ERO and RRO label subobjects? Isn't there serious risk of this making RSVP-TE completely unworkable? === Section 5. You should probably reference draft-ietf-mpls-mpls-and-gmpls-security-framework-04.txt Doesn't a mechanism that allows a Path or Resv message to be legitimately grown to be extremely large cause concern for security? === Would it be possible to add a short section of backward compatibility? === Envelope-to: ccamp-data0@psg.com Delivery-date: Wed, 18 Feb 2009 23:21:07 +0000 Message-ID: <1E4857D2FEEA445195C4509212D0B444@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Chair review of draft-ietf-ccamp-gmpls-mef-uni-01.txt Date: Wed, 18 Feb 2009 23:19:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Seems to have failed to reach the list. A ----- Original Message ----- From: "Adrian Farrel" To: "Lou Berger" Cc: Sent: Wednesday, February 18, 2009 12:36 PM Subject: Chair review of draft-ietf-ccamp-gmpls-mef-uni-01.txt > Hi, > > Just a few thoughts. > > Cheers, > Adrian > > === > > Obviously, you'll need to use the new IPR boilerplate. > > === > > Abstract > > This document > supports the types of switching required to implied by the Ethernet > services > > Too many words? > > === > > Abstract > > in the context of the Metro Ethernet > Forum (MEF) and International Telecommunication Union (ITU) G.8011. > > This reads like the MEF wrote G.8011 together with the ITU. > Do you mean this? > > Perhaps the Abstract should mention MEF6 > > === > > Section 1 > > Paragraph 1 doesn't seem sure how many frameworks there are. > Perhaps > OLD > [MEF6] and [G.8011] provide parallel frameworks > NEW > [MEF6] and [G.8011] provide parallel views of a framework > > === > > Figure 1 > > Are the arrows at the bottom of the figure (<----->) supposed to be > associated with the text "UNI" at the top of the figure? Maybe put them > together? > > === > > Section 1.2 > Capitalise section heading, please. > > === > > Section 2 > I think you should add RFC4974 to your list of procedures that must be > followed unless specifically modified. > > === > > Section 2.2.1 > If the object or TLV > are not present, the node MUST discard the message. In this case, a > Message ID Acknowledgment MUST NOT be sent for the Notify message. > > I'm worried about this. > Most implementations handle the Message ID Ack before checking the > validity of the message. > > Further, simply discarding the message may result in the sender using a > rapid retry. > > Why can't you do the Ack and then send a Call Failed response? > > === > > Section 2.2.1 > > It looks to me that your solution only works with a single domain if the > source UNI-C does not know the destination UNI-C IP address. > > When the Endpoint ID TLV is located, the node MUST map the Endpoint > ID into an IP address associated with the egress edge-node. > > Does "egress edge-node" mean UNI-N? > I think so, and given that you have been talking about UNI-C, it may help > to put... > > When the Endpoint ID TLV is located, the node MUST map the Endpoint > ID into an IP address associated with the egress edge-node (destination > UNI-N). > > In fact, however, in a multi-domain situation, the source UNI-N needs only > map to an E-NNI address, and so on across the network until the final > E-NNI maps to the UNI-N. Would you also allow a zero destination address > within the core network? > > === > > Section 6 > > I think you have copied this from somewhere else! > I don't see any "new message object formats" in the document. > > Do you need to say why the use of a zero destination address is not a > security problem? You might also observe that a certain element of access > control is devolved to the UNI-N, and that this is consistent with the > operation of GMPLS calls. > Envelope-to: ccamp-data0@psg.com Delivery-date: Wed, 18 Feb 2009 21:53:22 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lou Berger" , "Don Fedyk" Cc: Subject: Chair review of draft-ietf-ccamp-gmpls-ether-svcs-02.txt Date: Wed, 18 Feb 2009 21:50:56 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, A few comments. I think some of these qualify as issues. Thanks, Adrian === IPR boilerplate === Abstract OLD Specifically, switching in support of Ethernet private line service and Ethernet virtual private line service. NEW-EITHER Specifically, switching in support of the Ethernet private line service and the Ethernet virtual private line service. NEW-OR Specifically, switching in support of Ethernet private line services and Ethernet virtual private line services. === Abstract Some of the extensions defined in this document are generic in nature and not specific to Ethernet. It is good that you have this statement. I think you should split it to a separate paragraph and include a hint as to which extensions you are referring to. That is, which functions/features. Or have they all moved out to draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt === Section 1.1 s/Support for P2P and MP2MP service is/Support for P2P and MP2MP services is/ === Section 2 para 2 s/is not modified/are not modified/ === Section 2.1 para 2 long identifiers are carried in the attributes object Please clarify. The CALL_ATTRIBUTES object. === Section 2.1 para 2 As with the long call ID, the Ethernet endpoint identifier is typically only relevant at the ingress and egress nodes. === Section 2.1.1.1 A CALL_ATTRIBUTES object containing an Endpoint ID TLV MAY be included in the signaling messages of an LSP (connection) associated with an established call. Such objects are processed according to [4420BIS]. As per our (elongated) discussion for the MLN extensions. I don't see the value of including this object in a connection signaling message, and I see some significant dangers (including a breach in the "need to know" policy for the distribution of information within the Internet). But I have two issues with this paragraph. 1. You say "MAY be included", but nowhere in the spec do you say why or what it might be used for. We are not in the habit of defining mechanisms on the chance that they will be valuable at some time in the future. If you have a specific use in mind, please state it. Otherwise, we should delete this paragraph and let new documents vary the rules when/if a use is found. 2. Draft 4420-bis (now RFC 5420) does not mention this object and it is not appropriate to reference it for processing rules. === Section 2.1.1.1 Transit nodes supporting this document MUST propagate the Endpoint ID TLV without modification. Are you sure this is what you want? Isn't it the case that endpoint identifiers could be mapped at UNI and E-NNI reference points? === Section 2.2 Signaling for Ethernet connections follows the procedures defined in [RFC4974]. I wouldn't say that RFC 4974 was the normative reference for setting up LSPs of any sort. === Section 2.2 In the context of Ethernet connections, a call only exists when one or more LSPs (connections in [RFC4974] terms) are present. An LSP will always be established within the context of a call and, typically, only one LSP will be used per call. This seems to be contradictory. How can the LSP be "established within the context of a call" if the call "can only exist when one or more LSPs are present"? But RFC 4974 explicitly states (section 6.1)... Note that a Call MUST NOT be imposed upon a Connection that is already established. In fact, 2.2.1 says: When establishing an Ethernet connection the initiator MUST first establish a Call per the procedures defined in [RFC4974]. So what is section 2.2 trying to say? Would it be helpful to show the formal relationship between: - Ethernet (virtual) connection - GMPLS call - GMPLS LSP == connection == Ethernet LSP - EVPL connection I think there is some real confusion because the LSP is switching Ethernet and is a connection. But it is not your "Ethernet (virtual) connection". For example, in section 2.3... Ethernet connections established according to this document MUST use the traffic parameters defined in [ETH-TRAFFIC] in the FLOWSPEC and TSPEC objects. But this should be "Ethernet LSPs" I think. === Section 2.3.1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3 | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IL2CP | EL2CP | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ See [ETH-TRAFFIC] for a description of the Type and Length fields. Per [ETH-TRAFFIC], the Type field MUST be set to two (2) Hmmm. Presumably 3 == 2 for the purpose of this document? === Section 2.3.1 Don't you think IL2CP and EL2CP need to be under IANA's control? === Section 2.3.1 Ethernet connections established according to this document MUST include the L2CP TLV in the [ETH-TRAFFIC] traffic parameters carried in the FLOWSPEC and TSPEC objects. What do I do if the TLV is not there in each case? === Section 3 s/services./service./ === Section 3.1 Would it be possible to change OLD EPL Service LSP Encoding Type ----------- ----------------- Type 1/MEF Ethernet (2) [RFC3471] Type 2 Line (e.g., 8B/10B) (TBA by IANA) NEW EPL Service LSP Encoding Type Value Reference ----------- ------------------- ---------------- --------------- Type 1/MEF Ethernet 2 [RFC3471] Type 2 Line (e.g., 8B/10B) 14 (TBA by IANA) [This document] === Section 4 Parameter Value -------------- ----- Switching Type TBD [NOTE: under discussion] Time to complete that discussion? === Section 4.1 para 1 s/requires/require/ === Section 4.2 Per [MEF6], the mapping of the single VLAN ID used at the incoming interface of the ingress to a different VLAN ID at the outgoing interface at the egress UNI is allowed for EVPL services that do not support either bundling and VLAN ID preservation. Stack hit heap trying to parse this! How about... If an EVPL service supports neither bundling nor VLAN ID preservation, then [MEF6] allows mapping of VLAN IDs. The VLAN ID used at the incoming interface of the ingress UNI-C may be different from the VLAN ID at the outgoing interface of the egress UNI-C. (Although I wonder if UNI-N is actually what is meant.) === References will need updating. idnits will help you identify what needs doing. === Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 17 Feb 2009 16:58:48 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Document Action: 'Description of the RSVP-TE Graceful Restart Procedures' to Informational RFC Message-Id: <20090217165811.E576928C187@core3.amsl.com> Date: Tue, 17 Feb 2009 08:58:11 -0800 (PST) The IESG has approved the following document: - 'Description of the RSVP-TE Graceful Restart Procedures ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-04.txt Technical Summary This document provides an informational clarification of the control plane procedures for a Generalized MPLS (GMPLS) network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different. Working Group Summary There were no problems with consensus for this document (see PROTO writeup by Deborah Brungard). There was some debate about the need for this work. It was suggested that all of the necessary explanation of the operation of graceful restart was included in RFC 5063. However, repeated questions about how to use the protocol extensions in corner cases and double faliure scenarios makes this work valuable. Document Quality This document has been reviewed by the CCAMP working group and received some comments at IETF meetings and on the mailing list. Most importantly it has had input from the authors of RFC 5063 that documents the protocol procedures. It has also been updated in response to Gen-Art review. There are several implementations of the graceful restart processes described in RFC 5063. Experience from these implementations has provided valuable input to this document. Personnel Deborah Brungard is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. There are no IANA actions. Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 17 Feb 2009 16:52:49 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair Subject: Document Action: 'Requirements for the Conversion Between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network' to Informational RFC Message-Id: <20090217165013.73B763A6C43@core3.amsl.com> Date: Tue, 17 Feb 2009 08:50:13 -0800 (PST) The IESG has approved the following document: - 'Requirements for the Conversion Between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-06.txt Technical Summary From a Carrier perspective, the possibility of turning a Permanent Connection (PC) into a Soft Permanent Connection (SPC) and vice versa, without actually affecting Data Plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use Data Plane connection between the Management Plane and the Control Plane, leaving its Data Plane state untouched. This informational document sets out the requirements for such procedures within a Generalized Multiprotocol Label Switching (GMPLS) network. Working Group Summary There were no problems with consensus for this document. In the early stages there were some very strong opinions about the value of this work. Some vendors and operators did not believe that the function would be useful in the networks they build. However, over time, other vendors and operators strongly supported the function, and since it is described as an optional function in equipment and deployment, the working group did not object to this work proceeding. See proto writeup by Deborah Brungard. Document Quality This is a requirements specification, and cannot be implemented. Note that work is already in progress within the CCAMP working group to develop protocol solutions. Personnel Deborah Brungard is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. There are no IANA actions for this document. RFC Editor Note Please move the "Conventions used in this document" to be at the end of section 1 (introduction), as section 1.1, and please replace its text with the following text: NEW Although this requirements document is an informational document not a protocol specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] for clarity of requirement specification. In section 6, please make the following substitution: OLD If SNMP MIBs are used for configuration, then the Management Plane should support authentication for PC-SC configuration changes as specified in [RFC3414]. NEW The Management Plane interactions MUST be supported through protocols that can offer adequate security mechanisms to secure the configuration and protect the operation of the devices that are managed. These mechanisms MUST include at least cryptographic security and the ability to ensure that the entity giving access to configuration parameters is properly configured to give access only to those principals (users) that have legitimate rights to read/create/change/delete the parameters. IETF standard management protocols (Netconf [RFC4741] and SNMPv3 [RFC3410]) offer these mechanisms. Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 16 Feb 2009 16:41:44 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lyndon Ong" Cc: "Lucille Goldiner" , Subject: Communication to the OIF on RFC 5420 Date: Mon, 16 Feb 2009 16:40:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Dear Lyndon, The IETF's CCAMP working group would like to draw your attention to the publication of RFC 5420, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)". This document replaces RFC 4420 and fixes the inconsistency in the Length encoding for TLVs. We are grateful to the OIF for drawing this issue to our attention. Regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 16 Feb 2009 16:32:57 +0000 Message-ID: <235DE40DF4384FCC811848EA9D52458B@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Agenda slot requests for San Francisco Date: Mon, 16 Feb 2009 16:29:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Please let Deborah and me know if you would like time on the agenda for CCAMP in San Francisco. Thanks, Adrian Envelope-to: ccamp-data0@psg.com Delivery-date: Sat, 14 Feb 2009 08:49:20 +0000 Message-ID: <99E02B846FFF4E3FA2872A6900B0B381@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: CCAMP - Requested sessions have been scheduled for IETF 74 Date: Sat, 14 Feb 2009 08:46:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit Hi, *DRAFT* schedule is at https://datatracker.ietf.org/meeting/74/agenda.html Thursday is CCAMP day at the IETF. Adrian ----- Original Message ----- From: "IETF Secretariat" To: Cc: ; ; ; Sent: Friday, February 13, 2009 11:34 PM Subject: CCAMP - Requested sessions have been scheduled for IETF 74 > Dear Deborah Brungard, > > The sessions that you have requested have been scheduled. > Below is the scheduled session information followed by > the information of sessions that you have requested. > > CCAMP Session 1 (2.5 hours) > Thursday, Morning Session I 0900-1130 > Room Name: Breakout 7 > ---------------------------------------------- > CCAMP Session 2 (1 hour) > Thursday, Afternoon Session II 1510-1610 > Room Name: Breakout 7 > ---------------------------------------------- > > > > Requested Information: > > > --------------------------------------------------------- > Working Group Name: ccamp > Area Name: Routing Area > Session Requester: Deborah Brungard > > Number of Sessions: 2 > Length of Session(s): 2.5 hours > 1 hour > > Number of Attendees: 150 > Conflicts to Avoid: > First Priority: mpls l1vpn pce rtgarea > Second Priority: rtgwg idr ospf pwe3 l3vpn l2vpn > Third Priority: bfd forces pim trill isis softwire tictoc > BOF or IRTF Session: IRTF RRG > > Special Requests: > Candy bars for the WG chairs > --------------------------------------------------------- > > > Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 13 Feb 2009 19:01:54 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-04.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090213190001.72D2C28C0D8@core3.amsl.com> Date: Fri, 13 Feb 2009 11:00:01 -0800 (PST) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework Author(s) : D. Fedyk, et al. Filename : draft-ietf-ccamp-gmpls-ethernet-arch-04.txt Pages : 21 Date : 2009-02-13 There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized GMPLS based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed and this document provides a framework for these extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-gmpls-ethernet-arch-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-13104525.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 13 Feb 2009 17:20:16 +0000 Message-ID: <347BC9729D5F4438BD00408DEE22AAAC@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Cut-off dates for San Francisco Date: Fri, 13 Feb 2009 17:17:55 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Please be aware... March 2, 2009 Monday - Internet Draft Cut-off for initial document (-00) submission by 17:00 PST (01:00 Tuesday, March 3 UTC/GMT), upload using IETF ID Submission Tool. March 9, 2009 Monday - Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC/GMT), upload using IETF ID Submission Tool. Adrian Envelope-to: ccamp-data0@psg.com Delivery-date: Wed, 11 Feb 2009 08:56:33 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: A New Swathe of IPR Disclosures Date: Wed, 11 Feb 2009 08:53:47 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Please be aware that there has been another harvest of IPR disclosures delivered to the IETF. These can all be seen at https://datatracker.ietf.org/public/ipr_list.cgi The ones that are specifically of interest to us are... RFC 3473 (base GMPLS RSVP-TE specification) https://datatracker.ietf.org/ipr/1080/ Note that the previous IPR disclosure from the same company (1046, dated 2008-12-23) has been removed at the request of the submitter. RFC 4875 (P2MP RSVP-TE) https://datatracker.ietf.org/ipr/1077/ (So there are now several disclosures against this RFC) Please also note that the IPR disclosure against RFC 4726 (Framework for inter-domain MPLS-TE) that was 1057, dated 2008-12-23 has been removed at the request of the submitter. No other IPR disclosure has been made for this RFC. Thanks Adrian Envelope-to: ccamp-data0@psg.com Delivery-date: Tue, 10 Feb 2009 08:40:54 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft communication to the OIF Date: Tue, 10 Feb 2009 08:38:19 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi CCAMP, Just a polite note to OIF. Any comments? Thanks, Adrian === Dear Lyndon, The IETF's CCAMP working group would like to draw your attention to the publication of RFC 5420, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)". This document replaces RFC 4420 and fixes the inconsistency in the Length encoding for TLVs. We are grateful to the OIF for drawing this issue to our attention. Regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 09 Feb 2009 17:32:38 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D Action:draft-ietf-ccamp-rwa-wson-framework-01.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090209173001.C6FA23A6AB3@core3.amsl.com> Date: Mon, 9 Feb 2009 09:30:01 -0800 (PST) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-wson-framework-01.txt Pages : 47 Date : 2009-02-09 This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation scenarios that could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. This memo does NOT address optical impairments in any depth and focuses on topological elements and path selection constraints that are common across different WSON environments. It is expected that a variety of different techniques will be applied to optical impairments depending on the type of WSON, such as access, metro or long haul. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ccamp-rwa-wson-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-09091534.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data0@psg.com Delivery-date: Sun, 08 Feb 2009 10:38:40 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Further communication received from OIF Date: Sun, 8 Feb 2009 10:36:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We have received a further communication from the OIF, this time on routing. The text of the communication is shown below, and (as always) the original can be found at www.olddog.co.uk/ccamp.htm I think this one will need a response. Suggested text is always welcome. Adrian === Subject: Liaison from OIF to IETF CCAMP WG on Routing Dear Adrian and Deborah, OIF would like to thank CCAMP WG for its response to our liaison on Multi-layer ASON routing support. We appreciate CCAMP's information regarding the use of the ISCD and IACD defined in CCAMP's documents. We would like to first clarify our use of terminology, as this may be leading to some confusion: - We have used the term multi-level to refer to the use of multiple levels of routing areas, hierarchically related, to support multiple administrative domains of equipment. - We have used the term multi-layer to refer to the use of protocols to support signaling and routing in layers of switching technology that have a client/server relationship and are involved in a single service request, e.g., set up of an Ethernet Private Line (EPL) over STS-12c. We believe that ITU-T Recommendations G.8080, G.7715 and G.7715.1 allow for the use of the same routing information for path computation at multiple layers, and did not intend to mandate that separate routing protocol instances were required for each layer. An example of this would be the use of the same link bandwidth availability information for path computation for multiple signal types, e.g., STS-1 and STS-3c, keeping in mind that each signal type is a separate transport layer in ITU-T terminology. We appreciate CCAMP's continued interest in support of ASON routing requirements. Best regards, Lyndon Ong OIF Technical Committee Chair Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 06 Feb 2009 16:17:35 +0000 Message-ID: <498C626D.2020108@grotto-networking.com> Date: Fri, 06 Feb 2009 08:16:45 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ccamp Subject: Framework for Optical Impairments update... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPers, for those interested in WSON and the recent work on optical impairments we have updated our impairment framework draft: http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wson-impairments-02.txt In this update we have described further the requirement that may occur in some situations to keep a vendors impairment information private and given architectural options leveraging PCE to realize this goal. This allows us to accommodate ITU-T G.680 "situation 1" in a flexible and effective manner. The requirements section has been reorganized as well as the architectural alternatives. Figures have been furnished for architecture alternatives and example PCE configuration. Note that this document focuses on impairment aware path computation (IA-RWA) and does not address optical measurement in any way. Comments welcome Greg B. & Young L. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 06 Feb 2009 15:21:58 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 06 Feb 2009 15:20:00 +0000 Subject: Re: [PWE3] working group last call on draft-ietf-mpls-tp-requirements-04 From: Ben Niven-Jenkins To: Loa Andersson , , , , , , Message-ID: Thread-Topic: [PWE3] working group last call on draft-ietf-mpls-tp-requirements-04 Thread-Index: AcmIbmBJQHo6yZksOEqy4kWTRLayXQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Colleagues, In my rush to get this ready for last call I made an editing mistake, requirement 30 currently reads 30 MPLS-TP MUST support unidirectional, bidirectional and co-routed bidirectional point-to-point transport paths. But it should read 30 MPLS-TP MUST support unidirectional, bidirectional and associated bidirectional point-to-point transport paths. This has no impact in terms of the meaning of the requirement, just an editing error where I updated the terminology section to reflect discussion on the MPLS-TP mailing list but forgot to subsequently update the requirement to use the agreed term. Ben On 06/02/2009 10:11, "Loa Andersson" wrote: > All, > > this is to initiate a working group last call for > draft-ietf-mpls-tp-requirements-04. > > This document is one of the key documents for the mpls-tp work, > in particular it is important that the ITU-T mpls-tp ad hoc team > verifies the completeness of the requirements and that we have a > good review form all parties. > > Please review and send your comments to the mpls-tp list, > i.e. try to avoid doing a "reply all on this message" ! > > The working group last call will end on Feb 28, 2009. > > /Loa Envelope-to: ccamp-data0@psg.com Delivery-date: Fri, 06 Feb 2009 10:13:52 +0000 Message-ID: <498C0CBC.6050400@pi.nu> Date: Fri, 06 Feb 2009 11:11:08 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mpls-tp@ietf.org, ahmpls-tp@lists.itu.int, ccamp@ops.ietf.org, mpls@ietf.org, pwe3@ietf.org, l2vpn@ietf.org Subject: working group last call on draft-ietf-mpls-tp-requirements-04 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, this is to initiate a working group last call for draft-ietf-mpls-tp-requirements-04. This document is one of the key documents for the mpls-tp work, in particular it is important that the ITU-T mpls-tp ad hoc team verifies the completeness of the requirements and that we have a good review form all parties. Please review and send your comments to the mpls-tp list, i.e. try to avoid doing a "reply all on this message" ! The working group last call will end on Feb 28, 2009. /Loa -- Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 8 632 77 14 email: loa.andersson@ericsson.com loa.andersson@redback.com loa@pi.nu Envelope-to: ccamp-data0@psg.com Delivery-date: Thu, 05 Feb 2009 00:08:18 +0000 Message-ID: Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Commnuication from OIF on VCAT Date: Thu, 5 Feb 2009 00:06:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, We have received a communication from the OIF on VCAT. As always you can see a copy at the CCAMP alternative web site: www.olddog.co.uk/ccamp.htm The text of the communication is supplied below. Thanks, Adrian === Subject: Liaison from OIF to IETF CCAMP WG on VCAT Dear Adrian and Deborah, OIF would like to thank IETF CCAMP WG for its response to our liaison on VCAT/LCAS work. We will continue to review CCAMP's VCAT/LCAS work and how it might be used. We continue to be interested in scenarios such as creation of VCAT/LCAS groups with preestablished server connections and control of VCAT/LCAS in cases of multiple RSVP sessions with session shuffling, due to the use of multiple domains with differing I-NNI protocols. We are disappointed that this is not currently addressed by IETF CCAMP work and request CCAMP to keep us informed if it decides to investigate these scenarios. OIF would also like to thank IETF CCAMP for their liaisons on the usage of the RESV during make-before-break and CCAMP's current work on Ethernet. We appreciate CCAMP's quick response regarding the Length computation concern we raised in our previous liaison, and would appreciate future updates on the progress of CCAMP's Ethernet-related control plane work. We look forward to continued cooperation and discussion between our groups. Best regards, Lyndon Ong Envelope-to: ccamp-data0@psg.com Delivery-date: Wed, 04 Feb 2009 23:37:26 +0000 To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5420 on Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org Message-Id: <20090204233507.D276B20ADC2@bosco.isi.edu> Date: Wed, 4 Feb 2009 15:35:07 -0800 (PST) A new Request for Comments is now available in online RFC libraries. RFC 5420 Title: Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) Author: A. Farrel, Ed., D. Papadimitriou, JP. Vasseur, A. Ayyangarps Status: Standards Track Date: February 2009 Mailbox: adrian@olddog.co.uk, dimitri.papadimitriou@alcatel.be, jpv@cisco.com, arthi@juniper.net Pages: 22 Characters: 47668 Obsoletes: RFC4420 Updates: RFC3209, RFC3473 I-D Tag: draft-ietf-ccamp-rfc4420bis-03.txt URL: http://www.rfc-editor.org/rfc/rfc5420.txt Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs. This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. [STANDARDS TRACK] This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute Envelope-to: ccamp-data0@psg.com Delivery-date: Mon, 02 Feb 2009 08:46:33 +0000 From: "Shoichiro Seno" To: , , , , Subject: iPOP 2009 Call for Presentations Date: Mon, 2 Feb 2009 17:39:11 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-index: Acl83napCLZqADbiT0CXLGI2JmotcQH+EUEg Dear CAMP, PCE, L1VPN, MPLS and MPLS-TP subscribers, (Apologies for multiple copies, appreciated if you can forward to potentially interested people. Following the successful events of iPOP, the 5th Conference on IP + Optical Network (iPOP 2009) will be held at NICT Headquarters, Koganei, Tokyo, Japan, June 11-12, 2009. The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. See Call for presentation details at http://www.pilab.jp/ipop2009/ Important Dates: Submission deadline of one page summary: February 20, 2009 Notification of acceptance: April 3, 2009 Submission deadline of final presentation slides: April 24, 2009 The Technical Program Committee for iPOP 2009 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not limited to the following: * GMPLS/ASON technologies * GMPLS Network management, OA&M * Multi-layer network (MLN) / Multi-region network (MRN) * Path Computation Element (PCE), Traffic engineering * Inter-area/Inter-AS network * L1VPN, Bandwidth on Demand, and Photonic Grid * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Carrier Ethernet and MPLS-TP * Photonic Network for NxGN and NwGN * Application with high-bandwidth demand * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstract of 400 words and a maximum of 1 page, including figures and diagrams, speaker's name, affiliation, and contact information to the Technical Program Committee at ipop2009-CFP@pilab.jp. Kind regards, Sho Seno Exhibition Committee Vice-chair, iPOP 2009 -- Shoichiro Seno (E-mail) Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Information Technology R&D Center, Mitsubishi Electric Corporation