From owner-ccamp@ops.ietf.org Thu Apr 3 04:47:36 2008 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 289893A6C7C for ; Thu, 3 Apr 2008 04:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 0-t0KBwU0zB3 for ; Thu, 3 Apr 2008 04:47:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D5D7F28C643 for ; Thu, 3 Apr 2008 04:47:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhNmD-0009iI-Nq for ccamp-data@psg.com; Thu, 03 Apr 2008 11:38:41 +0000 Received: from [147.234.242.117] (helo=eci-iron1.ecitele.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhNm5-0009eI-Mu for ccamp@ops.ietf.org; Thu, 03 Apr 2008 11:38:35 +0000 Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by eci-iron1.ecitele.com with ESMTP; 03 Apr 2008 15:17:37 +0300 Received: from ILPTEXCH02.ecitele.com ([147.234.245.181]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Apr 2008 14:38:31 +0300 Received: from ILPTMAIL01.ecitele.com (147.234.245.211) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server id 8.1.263.0; Thu, 3 Apr 2008 14:38:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Question on the status of Y.1711 and RFC3429 Date: Thu, 3 Apr 2008 14:38:30 +0300 Message-ID: <64122293A6365B4A9794DC5636F9ACFD02D3D118@ILPTEX02.ecitele.com> In-Reply-To: <47ECB132.7090200@pi.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on the status of Y.1711 and RFC3429 Thread-Index: AciQsMzOn/guAnfHTHCRQvl2K2wxvAEzhEzw References: <47ECB132.7090200@pi.se> From: Alexander Vainshtein To: "Loa Andersson" , , CC: "Ross Callon" , "David Ward" , "pwe3" , , "L2VPN" , "ccamp" X-OriginalArrivalTime: 03 Apr 2008 11:38:31.0350 (UTC) FILETIME=[3DFDFD60:01C8957F] Sender: owner-ccamp@ops.ietf.org Precedence: bulk Loa, George and all, ECI Telecom has implemented ITU-T recommendation Y.1711 using=20 Label 14 as defined in RFC 3429 in its XDM (TM) products family.=20 The corresponding products have been deployed in live=20 networks, and their Y.1711-related functionality is now in=20 operational use. Based on this, we (ECI) object to deprecation of the Label 14=20 allocation that is currently defined in RFC 3429 and suggests using a different reserved label value for T-MPLS needs. Regards, Sasha=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Loa Andersson > Sent: Friday, March 28, 2008 11:50 AM > To: mpls@ietf.org; pwe3; l3vpn@ietf.org; L2VPN; ccamp > Cc: Ross Callon; David Ward > Subject: Question on the status of Y.1711 and RFC3429 >=20 > All, >=20 > In the discussions the IETF and the ITU-T have had on T-MPLS we have > discussed the intended use for label 14 and the different documents > where this has been specified. >=20 > As a side effect we've also started to ask ourselves if there are any > implementations and/or deployments that uses label 14. >=20 > A quick survey among known implementers of MPLS has not shown any > implementations/deployments. >=20 > Since one of the approaches discussed in the Joint Working Team > context is a solution that requires the allocation of a reserved > label and reserved labels are a scarce resource we'd like to know > if it possible to redefine label 14 for that particular use. >=20 > There are still technical issues to be sorted out with the suggested > approach, but in the mean time we would like to know if it is possible > to deprecate RFC3429 and redefine the OAM Alert Label. >=20 > The questions is: "Are there any implementations/deployments of Y.1711 > or the OAM Alert label as it is allocated in RFC3429; and is there > objection to deprecating the protocol as it stands today?" >=20 > ITU-T has sent out a question along the same lines, see the included > mail below. >=20 > Please respond to the mpls working group mailing list or to the mpls > working chairs directly. As usual non-responses will be counted as > that there is no implementation/deployment. >=20 > Loa and George >=20 >=20 > ------------------- included mail ------------------------------------ >=20 > All users/implementers of recommendation Y.1711, >=20 > Currently the Joint Working Team of ITU-T and IETF experts is > considering the options of using IETF mechanisms to provide > OAM for T-MPLS. >=20 > One possibility is the following mechanism: > ------------------------------------------- > Push/pop a label at the MEP/domain boundary. >=20 > This makes the OAM alert label directly visible at the > sink MEP. >=20 > To make the OAM label visible to a MIP the TTL in the server > (lower) layer is set by the MEP to expire when the OAM frame > reaches the intended MIP. >=20 > The OAM alert label will point to an "opcode" at the bottom > of the stack. > ------------------------------------------ >=20 > This behaviour (when the OAM alert label is received) is not > consistent with the behaviour currently defined in Y.1711 when > label 14 is received. >=20 > *QUESTION* are there any users/implementers of the current Y.1711 > concerned with this change in behaviour? >=20 > If there are no concerns then recommendation Y.1711 can be > withdrawn or revised to describe the desired behaviour (described > above). >=20 > Please send me (or this list) your response ASAP. >=20 > Kind regards, Huub van Helvoort, your rapporteur. >=20 > --=20 > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 From owner-ccamp@ops.ietf.org Fri Apr 4 02:51:53 2008 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 235E528C746 for ; Fri, 4 Apr 2008 02:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, 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 XawXWtsOm9lZ for ; Fri, 4 Apr 2008 02:51:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ECED828C736 for ; Fri, 4 Apr 2008 02:51:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhiRd-0005HX-Fa for ccamp-data@psg.com; Fri, 04 Apr 2008 09:42:49 +0000 Received: from [80.86.78.228] (helo=fw.testbed.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhiRa-0005Gv-SC for ccamp@ops.ietf.org; Fri, 04 Apr 2008 09:42:48 +0000 Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1JhiRX-0001gw-16 for ccamp@ops.ietf.org; Fri, 04 Apr 2008 11:42:43 +0200 Received: from h4n2fls31o874.telia.com ([213.66.236.4]:60737 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1JhiRV-0001gi-Od; Fri, 04 Apr 2008 11:42:41 +0200 Message-ID: <47F5F7EF.5030906@pi.se> Date: Fri, 04 Apr 2008 11:42:07 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mpls@ietf.org, ccamp , l1vpn@ietf.org, pwe3 , L2VPN CC: David Ward , Ross Callon , George Swallow Subject: conclusion on the status of Y.1711 and RFC3429 X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk All, on March 28 the MPLS WG chairs polled the several working group mailing lists about the state of Y.1711 and RFC3429 implementations and deployments. Our conclusion is that there is enough implementations and deployments of Y.1711 and hence it is not possible to, for time being, deprecate label 14 or obsolete RFC3429. This conclusion however leaves with the issue of investigating if Y.1711, other ITU-T documents and RFC3429 is well enough aligned or if updates is needed. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From owner-ccamp@ops.ietf.org Fri Apr 4 07:54:20 2008 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 001303A6E04 for ; Fri, 4 Apr 2008 07:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.284 X-Spam-Level: X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 q6cKQBmYZnmF for ; Fri, 4 Apr 2008 07:54:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 098863A6DF5 for ; Fri, 4 Apr 2008 07:54:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhnBV-0001lf-Tt for ccamp-data@psg.com; Fri, 04 Apr 2008 14:46:29 +0000 Received: from [155.53.12.9] (helo=prattle.redback.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JhnBK-0001gb-Un for ccamp@ops.ietf.org; Fri, 04 Apr 2008 14:46:24 +0000 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 29368C4F897; Fri, 4 Apr 2008 07:46:18 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25104-02; Fri, 4 Apr 2008 07:46:17 -0700 (PDT) Received: from [?6???g??p???y??$IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 16CEBC4F89A; Fri, 4 Apr 2008 07:46:16 -0700 (PDT) In-Reply-To: <079701c889ec$22702080$0200a8c0@your029b8cecfe> References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v753) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: OSPF List , CCAMP List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [OSPF] CCAMP last call on advertisement of inter-AS TE links Date: Fri, 4 Apr 2008 10:46:16 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Sender: owner-ccamp@ops.ietf.org Precedence: bulk I can't speak for the OSPF WG as a whole, but I have reviewed the subject document and am very happy to see that the suggestion to use separate inter-AS LSA types has been incorporated. I have no further technical comments on the document and trust that the ccamp WG has verified that this information encoding meets the TE requirements. The usage described in sections 2.2 and 2.3 seem reasonable to me. I have the following editorial comments: 1. Sections 3.3.2 and 3.3.2 - Both of these say "Use of the TE Router ID is RECOMMENDED." I believe these should be respectively replaced by "Use of the TE Router Address as specified in the Router Address TLV [OSPF-TE] is RECOMMENDED." and "Use of the TE Router IPv6 Address as specified in the IPv6 Router Address as specified in the IPv6 Router Address TLV [OSPF-V3-TE] is RECOMMENDED." 2. Section 3.2.1 states "This is because... that may operate in a different address space;". If they are using a different address space on the link between the ASes, then I'd expect there to be problems with BGP as well :^) I'd suggest: "Given that OSPF is an IGP and should only be utilized between routers in the same routing domain, the OSPF specific Link ID and Neighbor ID sub-TLVs are not applicable to inter-AS links.". 3. You may want to expand some acronyms on their first use. For example, "AS Boundary Router (ASBR)", "Link State Advertisement (LSA)" and "Path Computation Element (PCE)". 4. [OSPFV3] is listed to as both a Normative and Informative reference. Thanks, Acee On Mar 19, 2008, at 2:06 PM, Adrian Farrel wrote: > Hi, > > You may recall providing useful review and feedback on > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- > te-extension-02.txt > > The authors believe that they have taken on board all the comments > received > from the OSPF working group and have updated the draft accordingly. > > > CCAMP is holding a three week working group last call on this I-D > along with > its IS-IS partner document: > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas- > te-extension-00.txt > > These documents describe how to advertise the TE links that connect > an AS to > the outside world within the AS's IGP. As the drafts are at pains > to point > out, there is no proposal to advertise the TE information more > widely (such > as to other ASes). > > The last call will end at 12 noon BST on April 9th 2008. > > Please send your comments to the CCAMP list or direct to the CCAMP > chairs. > > Thanks, > Adrian and Deborah > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From owner-ccamp@ops.ietf.org Fri Apr 4 13:10:15 2008 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 D53F23A6CEB for ; Fri, 4 Apr 2008 13:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 5BAPgrztF9TH for ; Fri, 4 Apr 2008 13:10:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C85223A6988 for ; Fri, 4 Apr 2008 13:09:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jhs1J-000POm-Ai for ccamp-data@psg.com; Fri, 04 Apr 2008 19:56:17 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jhs1G-000PON-Jd for ccamp@ops.ietf.org; Fri, 04 Apr 2008 19:56:16 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m34Ju85Q002706; Fri, 4 Apr 2008 20:56:08 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m34Ju6Iv002672; Fri, 4 Apr 2008 20:56:07 +0100 Message-ID: <003001c8968d$ea0217e0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "OSPF List" Cc: "CCAMP List" References: Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions to OSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt Date: Fri, 4 Apr 2008 20:56:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, Just a couple of comments... === Section 1 s/proposes the addition of/defines/ === Section 4 Forgive me for not remembering this discussion... The draft says that we cannot use the Link ID sub-TLV "due to the protocol differences." It then says that the Link ID sub-TLV SHOULD NOT be included (implying that it MAY be included under certain circumstances) but MUST be ignored. 1. Does ignored mean "continue to be flooded" or "stripped from the LSA"? 2. Is it not possible to consider operating a GMPLS control plane in an IPv6 network where the routers use IPv6 addresses to communicate (so all control plane messages will be addressed using IPv6, and the router address will be IPv6 as described in Section 3) but where the data channel identifiers are assigned from an IPv4 address space? Recall that in GMPLS the interfaces used for OSPF exchange are not those used for data exchange. Whatever the answers, I think it would help if the reasons were clarified beyond "protocol differences." === Cheers, Adrian PS I wouldn't mind if you spelled my name right in the acks section :-) From ferit-kiristvt@F9bos.apple.com Sat Apr 5 07:34:09 2008 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 D9E623A6C11 for ; Sat, 5 Apr 2008 07:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.33 X-Spam-Level: X-Spam-Status: No, score=-35.33 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, 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 PtfOtiWyiVpL for ; Sat, 5 Apr 2008 07:34:09 -0700 (PDT) Received: from host86-130-105-4.range86-130.btcentralplus.com (host86-130-105-4.range86-130.btcentralplus.com [86.130.105.4]) by core3.amsl.com (Postfix) with ESMTP id C418B3A699D for ; Sat, 5 Apr 2008 07:34:08 -0700 (PDT) User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Sat, 5 Apr 2008 15:34:15 +0100 Subject: Gifts for your love From: ferit To: "ccamp-archive@ietf.org" Message-ID: <46F69286.0%ferit-kiristvt@F9bos.apple.com> Thread-Topic: Gifts for your love Thread-Index: AciXMoEbfuNtMRxbSuSjNjoue3nlDw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_5478508080_51803" --B_5478508080_51803 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Gold, silver, rubies and diamonds. You name it, we have it. http://www.polaernat.com/ --B_5478508080_51803 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Gifts for your love Gold, silver, rubies = and diamonds. You name it, we have it. http://www.polaernat.com/
 --B_5478508080_51803-- From Mie-kinsenba@F9bos.apple.com Sat Apr 5 07:34:22 2008 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 37BFF3A699D for ; Sat, 5 Apr 2008 07:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.33 X-Spam-Level: X-Spam-Status: No, score=-45.33 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, 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 Y7OLGIq0VgiV for ; Sat, 5 Apr 2008 07:34:21 -0700 (PDT) Received: from host86-130-105-4.range86-130.btcentralplus.com (host86-130-105-4.range86-130.btcentralplus.com [86.130.105.4]) by core3.amsl.com (Postfix) with ESMTP id 103223A6BBD for ; Sat, 5 Apr 2008 07:34:20 -0700 (PDT) User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Sat, 5 Apr 2008 15:34:27 +0100 Subject: Get all your branded needs here From: Mie To: "ccamp-archive@megatron.ietf.org" Message-ID: Thread-Topic: Get all your branded needs here Thread-Index: AciXMoiwDlkwrZrsRIms0ftNE6wx2w== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_5166300544_72772" --B_5166300544_72772 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Get a brand new watch that befits your new job. http://www.Varaence.com/ --B_5166300544_72772 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Get all your branded needs here Get a brand new watch = that befits your new job. http://www.Varaence.com/
 --B_5166300544_72772-- From owner-ccamp@ops.ietf.org Sat Apr 5 08:58:38 2008 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 2EC8928C2E3 for ; Sat, 5 Apr 2008 08:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 eyawTX49q13N for ; Sat, 5 Apr 2008 08:58:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 911B428C2EB for ; Sat, 5 Apr 2008 08:58:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JiAf1-000IES-0U for ccamp-data@psg.com; Sat, 05 Apr 2008 15:50:31 +0000 Received: from [155.53.12.9] (helo=prattle.redback.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JiAey-000IE2-3I for ccamp@ops.ietf.org; Sat, 05 Apr 2008 15:50:29 +0000 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B4537289F0D; Sat, 5 Apr 2008 08:50:27 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32451-08; Sat, 5 Apr 2008 08:50:27 -0700 (PDT) Received: from [?*???n?IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id EE10A289F09; Sat, 5 Apr 2008 08:50:26 -0700 (PDT) In-Reply-To: <003001c8968d$ea0217e0$0300a8c0@your029b8cecfe> References: <003001c8968d$ea0217e0$0300a8c0@your029b8cecfe> Mime-Version: 1.0 (Apple Message framework v753) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <90CE7EEE-1F2F-44DD-8B58-A5F9C6A49C4B@redback.com> Cc: "OSPF List" , CCAMP List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions to OSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt Date: Sat, 5 Apr 2008 11:50:25 -0400 To: Adrian Farrel X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Adrian, Thanks for the review. On Apr 4, 2008, at 3:56 PM, Adrian Farrel wrote: > Hi, > > Just a couple of comments... > > === > Section 1 > s/proposes the addition of/defines/ Changed. > === > Section 4 > Forgive me for not remembering this discussion... > The draft says that we cannot use the Link ID sub-TLV "due to the > protocol > differences." The link-ID is cannot be used since, in the case of multi-access network, it contains the IPv4 address of the Designated Router (DR). OSPFv3 doesn't have this information. > It then says that the Link ID sub-TLV SHOULD NOT be included > (implying that > it MAY be included under certain circumstances) but MUST be ignored. This is the spirit of being conservative in what one sends and liberal in what one excepts. > 1. Does ignored mean "continue to be flooded" or "stripped from the > LSA"? In OSPF, only the originator should modify an LSA. So, it means neither. > 2. Is it not possible to consider operating a GMPLS control plane > in an IPv6 > network where the routers use IPv6 addresses to communicate (so all > control > plane messages will be addressed using IPv6, and the router address > will be > IPv6 as described in Section 3) but where the data channel > identifiers are > assigned from an IPv4 address space? Recall that in GMPLS the > interfaces > used for OSPF exchange are not those used for data exchange. I believe it is probable that IPv4 and IPv6 will coexist. However, OSPFv3 doesn't know the IPv4 address of the DR (at least it is not standardized). Hence, this isn't the right sub-TLV to reflect this topology. > > Whatever the answers, I think it would help if the reasons were > clarified > beyond "protocol differences." I'll expand this to describe the multi-access network case. Sound good? Thanks, Acee > === > > Cheers, > Adrian > > PS I wouldn't mind if you spelled my name right in the acks > section :-) > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From owner-ccamp@ops.ietf.org Sat Apr 5 09:57:40 2008 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 00B7E3A6B7C for ; Sat, 5 Apr 2008 09:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[AWL=-1.253, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MISSING_HEADERS=1.292, 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 2AWXLPUZVAFd for ; Sat, 5 Apr 2008 09:57:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EB4323A6B30 for ; Sat, 5 Apr 2008 09:57:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JiBbg-0001e6-Rn for ccamp-data@psg.com; Sat, 05 Apr 2008 16:51:08 +0000 Received: from [155.53.12.9] (helo=prattle.redback.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JiBba-0001dK-MD for ccamp@ops.ietf.org; Sat, 05 Apr 2008 16:51:07 +0000 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 59C1B2ED463; Sat, 5 Apr 2008 09:51:02 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07385-02; Sat, 5 Apr 2008 09:51:02 -0700 (PDT) Received: from [?????n?IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id C3F342ED462; Sat, 5 Apr 2008 09:51:01 -0700 (PDT) In-Reply-To: <90CE7EEE-1F2F-44DD-8B58-A5F9C6A49C4B@redback.com> References: <003001c8968d$ea0217e0$0300a8c0@your029b8cecfe> <90CE7EEE-1F2F-44DD-8B58-A5F9C6A49C4B@redback.com> Mime-Version: 1.0 (Apple Message framework v753) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <02388B0D-3AB4-4954-B459-4FD88AB04440@redback.com> Cc: Adrian Farrel , CCAMP List , OSPF List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions to OSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt Date: Sat, 5 Apr 2008 12:51:00 -0400 X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Sender: owner-ccamp@ops.ietf.org Precedence: bulk Adrian, How's this: *************** *** 342,348 **** The Link TLV describes a single link and consists of a set of sub- TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID sub- TLV are applicable to OSPFv3. The Link ID sub-TLV can't be used in ! OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3. Three new sub-TLVs for the Link TLV are defined: --- 342,351 ---- The Link TLV describes a single link and consists of a set of sub- TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID sub- TLV are applicable to OSPFv3. The Link ID sub-TLV can't be used in ! OSPFv3 since it defined to contain the IPv4 address of the Designated ! Router (DR) for multi-access interfaces. In contrast to OSPFv2, ! OSPFv3 always identifies a neighboring router by the Router ID (Refer ! to section 2.11 in [OSPFV3]). Three new sub-TLVs for the Link TLV are defined: *************** I plan to wait until the WG last call has completed to submit the update. Thanks, Acee On Apr 5, 2008, at 11:50 AM, Acee Lindem wrote: > Hi Adrian, > > Thanks for the review. > > On Apr 4, 2008, at 3:56 PM, Adrian Farrel wrote: > >> Hi, >> >> Just a couple of comments... >> >> === >> Section 1 >> s/proposes the addition of/defines/ > > Changed. > > >> === >> Section 4 >> Forgive me for not remembering this discussion... >> The draft says that we cannot use the Link ID sub-TLV "due to the >> protocol >> differences." > > The link-ID is cannot be used since, in the case of multi-access > network, it contains the IPv4 address of the Designated Router (DR). > OSPFv3 doesn't have this information. > > >> It then says that the Link ID sub-TLV SHOULD NOT be included >> (implying that >> it MAY be included under certain circumstances) but MUST be ignored. > > This is the spirit of being conservative in what one sends and > liberal in what one excepts. > > > >> 1. Does ignored mean "continue to be flooded" or "stripped from the >> LSA"? > > In OSPF, only the originator should modify an LSA. So, it means > neither. > > > >> 2. Is it not possible to consider operating a GMPLS control plane >> in an IPv6 >> network where the routers use IPv6 addresses to communicate (so all >> control >> plane messages will be addressed using IPv6, and the router address >> will be >> IPv6 as described in Section 3) but where the data channel >> identifiers are >> assigned from an IPv4 address space? Recall that in GMPLS the >> interfaces >> used for OSPF exchange are not those used for data exchange. > > I believe it is probable that IPv4 and IPv6 will coexist. However, > OSPFv3 doesn't know the IPv4 address of the DR (at least it is not > standardized). Hence, this isn't the right sub-TLV to reflect this > topology. > > > >> >> Whatever the answers, I think it would help if the reasons were >> clarified >> beyond "protocol differences." > > I'll expand this to describe the multi-access network case. Sound > good? > > Thanks, > Acee > > > >> === >> >> Cheers, >> Adrian >> >> PS I wouldn't mind if you spelled my name right in the acks >> section :-) >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From owner-ccamp@ops.ietf.org Sun Apr 6 04:23:25 2008 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 0430C3A6D2E for ; Sun, 6 Apr 2008 04:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.335 X-Spam-Level: X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MISSING_HEADERS=1.292, 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 U3VovkXeoq1b for ; Sun, 6 Apr 2008 04:23:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AAABC3A6D38 for ; Sun, 6 Apr 2008 04:23:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JiSqS-0009lJ-56 for ccamp-data@psg.com; Sun, 06 Apr 2008 11:15:32 +0000 Received: from [155.53.12.9] (helo=prattle.redback.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JiSqP-0009kz-Bj for ccamp@ops.ietf.org; Sun, 06 Apr 2008 11:15:30 +0000 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8A7EE1EBF5F; Sun, 6 Apr 2008 04:15:25 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18137-02; Sun, 6 Apr 2008 04:15:25 -0700 (PDT) Received: from [*????n?IPv6???1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 24AD5A4AF87; Sun, 6 Apr 2008 04:15:19 -0700 (PDT) In-Reply-To: <02388B0D-3AB4-4954-B459-4FD88AB04440@redback.com> References: <003001c8968d$ea0217e0$0300a8c0@your029b8cecfe> <90CE7EEE-1F2F-44DD-8B58-A5F9C6A49C4B@redback.com> <02388B0D-3AB4-4954-B459-4FD88AB04440@redback.com> Mime-Version: 1.0 (Apple Message framework v753) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: CCAMP List , OSPF List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions to OSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt Date: Sun, 6 Apr 2008 07:15:18 -0400 X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Sender: owner-ccamp@ops.ietf.org Precedence: bulk Alan Davey pointed out that I was missing the word "is" in my text. I went ahead with a more verbose explanation of the protocol differences. *************** *** 342,348 **** The Link TLV describes a single link and consists of a set of sub- TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID sub- TLV are applicable to OSPFv3. The Link ID sub-TLV can't be used in ! OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3. Three new sub-TLVs for the Link TLV are defined: --- 342,356 ---- The Link TLV describes a single link and consists of a set of sub- TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID sub- TLV are applicable to OSPFv3. The Link ID sub-TLV can't be used in ! OSPFv3 since it is defined to use the OSPFv2 identification for the ! Designated Router (DR) on multi-access networks. In OSPFv2, ! neighbors on point-to-point networks and virtual links are identified ! by their Router IDs while neighbors on broadcast, Non-Broadcast ! Multi-Access (NBMA), and Point-to-Multipoint links are identified by ! their IPv4 interface addresses (Refer to section 8.2 in [OSPFV2]). ! The IPv4 interface address is not known to OSPFv3. In contrast to ! OSPFv2, OSPFv3 always identifies neighboring routers by their Router ! IDs (Refer to section 2.11 in [OSPFV3]). Three new sub-TLVs for the Link TLV are defined: *************** On Apr 5, 2008, at 12:51 PM, Acee Lindem wrote: > Adrian, > > How's this: > > *************** > *** 342,348 **** > The Link TLV describes a single link and consists of a set of > sub- > TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID > sub- > TLV are applicable to OSPFv3. The Link ID sub-TLV can't be > used in > ! OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3. > > Three new sub-TLVs for the Link TLV are defined: > > --- 342,351 ---- > The Link TLV describes a single link and consists of a set of > sub- > TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID > sub- > TLV are applicable to OSPFv3. The Link ID sub-TLV can't be > used in > ! OSPFv3 since it defined to contain the IPv4 address of the > Designated > ! Router (DR) for multi-access interfaces. In contrast to OSPFv2, > ! OSPFv3 always identifies a neighboring router by the Router ID > (Refer > ! to section 2.11 in [OSPFV3]). > > Three new sub-TLVs for the Link TLV are defined: > > *************** > > I plan to wait until the WG last call has completed to submit the > update. > Thanks, > Acee > > On Apr 5, 2008, at 11:50 AM, Acee Lindem wrote: > >> Hi Adrian, >> >> Thanks for the review. >> >> On Apr 4, 2008, at 3:56 PM, Adrian Farrel wrote: >> >>> Hi, >>> >>> Just a couple of comments... >>> >>> === >>> Section 1 >>> s/proposes the addition of/defines/ >> >> Changed. >> >> >>> === >>> Section 4 >>> Forgive me for not remembering this discussion... >>> The draft says that we cannot use the Link ID sub-TLV "due to the >>> protocol >>> differences." >> >> The link-ID is cannot be used since, in the case of multi-access >> network, it contains the IPv4 address of the Designated Router (DR). >> OSPFv3 doesn't have this information. >> >> >>> It then says that the Link ID sub-TLV SHOULD NOT be included >>> (implying that >>> it MAY be included under certain circumstances) but MUST be ignored. >> >> This is the spirit of being conservative in what one sends and >> liberal in what one excepts. >> >> >> >>> 1. Does ignored mean "continue to be flooded" or "stripped from the >>> LSA"? >> >> In OSPF, only the originator should modify an LSA. So, it means >> neither. >> >> >> >>> 2. Is it not possible to consider operating a GMPLS control plane >>> in an IPv6 >>> network where the routers use IPv6 addresses to communicate (so all >>> control >>> plane messages will be addressed using IPv6, and the router address >>> will be >>> IPv6 as described in Section 3) but where the data channel >>> identifiers are >>> assigned from an IPv4 address space? Recall that in GMPLS the >>> interfaces >>> used for OSPF exchange are not those used for data exchange. >> >> I believe it is probable that IPv4 and IPv6 will coexist. However, >> OSPFv3 doesn't know the IPv4 address of the DR (at least it is not >> standardized). Hence, this isn't the right sub-TLV to reflect this >> topology. >> >> >> >>> >>> Whatever the answers, I think it would help if the reasons were >>> clarified >>> beyond "protocol differences." >> >> I'll expand this to describe the multi-access network case. Sound >> good? >> >> Thanks, >> Acee >> >> >> >>> === >>> >>> Cheers, >>> Adrian >>> >>> PS I wouldn't mind if you spelled my name right in the acks >>> section :-) >>> >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From owner-ccamp@ops.ietf.org Sun Apr 6 19:19:00 2008 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 6952E3A6B66 for ; Sun, 6 Apr 2008 19:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 tHvNM0JosDTs for ; Sun, 6 Apr 2008 19:18:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 661143A6C30 for ; Sun, 6 Apr 2008 19:18:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JigpC-0007Rl-VY for ccamp-data@psg.com; Mon, 07 Apr 2008 02:11:10 +0000 Received: from [61.144.161.7] (helo=szxga04-in.huawei.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jigp8-0007RF-TD for ccamp@ops.ietf.org; Mon, 07 Apr 2008 02:11:09 +0000 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JYX006LCNEGFG@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Mon, 07 Apr 2008 10:11:04 +0800 (CST) Received: from M55527 ([10.111.12.186]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JYX00ESGNECP8@szxga04-in.huawei.com> for ccamp@ops.ietf.org; Mon, 07 Apr 2008 10:11:04 +0800 (CST) Date: Mon, 07 Apr 2008 10:11:00 +0800 From: Mach Chen Subject: Re: Re: [OSPF] CCAMP last call on advertisement of inter-AS TE links To: Acee Lindem , Adrian Farrel Cc: OSPF List , CCAMP List Message-id: <200804071010599657422@huawei.com> Organization: Huawei MIME-version: 1.0 X-Mailer: Foxmail 6, 10, 201, 20 [cn] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Acee, Thanks for your review and comments! Since there are no technical issues, I will update the I-D until the end of the WG last call. On 2008-04-04, at 22:49:13 Acee Lindem wrote: >I can't speak for the OSPF WG as a whole, but I have reviewed the >subject document and am very happy to see that the suggestion to use >separate inter-AS LSA types has been incorporated. I have no further >technical comments on the document and trust that the ccamp WG has >verified that this information encoding meets the TE requirements. >The usage described in sections 2.2 and 2.3 seem reasonable to me. > >I have the following editorial comments: > > 1. Sections 3.3.2 and 3.3.2 - Both of these say "Use of the TE >Router ID is RECOMMENDED." I believe these should be respectively >replaced by "Use of the TE Router Address as specified in the Router >Address TLV [OSPF-TE] is RECOMMENDED." and "Use of the TE Router IPv6 >Address as specified in the IPv6 Router Address as specified in the >IPv6 Router Address TLV [OSPF-V3-TE] is RECOMMENDED." > 2. Section 3.2.1 states "This is because... that may operate in a >different address space;". If they are using a different address >space on the link between the ASes, then I'd expect there to be >problems with BGP as well :^) I'd suggest: > "Given that OSPF is an IGP and should only be utilized between >routers in the same routing domain, the OSPF specific Link ID and >Neighbor ID sub-TLVs are not applicable to inter-AS links.". > 3. You may want to expand some acronyms on their first use. For >example, "AS Boundary Router (ASBR)", "Link State Advertisement >(LSA)" and > "Path Computation Element (PCE)". > 4. [OSPFV3] is listed to as both a Normative and Informative >reference. > >Thanks, >Acee > >On Mar 19, 2008, at 2:06 PM, Adrian Farrel wrote: > >> Hi, >> >> You may recall providing useful review and feedback on >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- >> te-extension-02.txt >> >> The authors believe that they have taken on board all the comments >> received >> from the OSPF working group and have updated the draft accordingly. >> >> >> CCAMP is holding a three week working group last call on this I-D >> along with >> its IS-IS partner document: >> >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas- >> te-extension-00.txt >> >> These documents describe how to advertise the TE links that connect >> an AS to >> the outside world within the AS's IGP. As the drafts are at pains >> to point >> out, there is no proposal to advertise the TE information more >> widely (such >> as to other ASes). >> >> The last call will end at 12 noon BST on April 9th 2008. >> >> Please send your comments to the CCAMP list or direct to the CCAMP >> chairs. >> >> Thanks, >> Adrian and Deborah >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > Best regards, Mach Chen From owner-ccamp@ops.ietf.org Mon Apr 7 06:17:12 2008 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 4340C3A6B1F for ; Mon, 7 Apr 2008 06:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.004 X-Spam-Level: X-Spam-Status: No, score=-1.004 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 4eL1IzXYJF9e for ; Mon, 7 Apr 2008 06:17:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 475A53A6B16 for ; Mon, 7 Apr 2008 06:17:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jiqty-000FBb-DH for ccamp-data@psg.com; Mon, 07 Apr 2008 12:56:46 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jiqtf-000F92-Iu for ccamp@ops.ietf.org; Mon, 07 Apr 2008 12:56:33 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m37CuL8Q030834; Mon, 7 Apr 2008 13:56:22 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m37CuINV030788; Mon, 7 Apr 2008 13:56:20 +0100 Message-ID: <02b201c898ae$c3a103e0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Acee Lindem" Cc: "CCAMP List" , "OSPF List" References: <003001c8968d$ea0217e0$0300a8c0@your029b8cecfe><90CE7EEE-1F2F-44DD-8B58-A5F9C6A49C4B@redback.com><02388B0D-3AB4-4954-B459-4FD88AB04440@redback.com> Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions toOSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt Date: Mon, 7 Apr 2008 13:56:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Thanks Acee, That does the job. Adrian ----- Original Message ----- From: "Acee Lindem" Cc: "CCAMP List" ; "OSPF List" Sent: Sunday, April 06, 2008 12:15 PM Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions toOSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt > Alan Davey pointed out that I was missing the word "is" in my text. I > went ahead with a more verbose explanation of the protocol differences. > > *************** > *** 342,348 **** > The Link TLV describes a single link and consists of a set of sub- > TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID > sub- > TLV are applicable to OSPFv3. The Link ID sub-TLV can't be > used in > ! OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3. > > Three new sub-TLVs for the Link TLV are defined: > > --- 342,356 ---- > The Link TLV describes a single link and consists of a set of sub- > TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID > sub- > TLV are applicable to OSPFv3. The Link ID sub-TLV can't be > used in > ! OSPFv3 since it is defined to use the OSPFv2 identification for the > ! Designated Router (DR) on multi-access networks. In OSPFv2, > ! neighbors on point-to-point networks and virtual links are > identified > ! by their Router IDs while neighbors on broadcast, Non-Broadcast > ! Multi-Access (NBMA), and Point-to-Multipoint links are > identified by > ! their IPv4 interface addresses (Refer to section 8.2 in [OSPFV2]). > ! The IPv4 interface address is not known to OSPFv3. In contrast to > ! OSPFv2, OSPFv3 always identifies neighboring routers by their > Router > ! IDs (Refer to section 2.11 in [OSPFV3]). > > Three new sub-TLVs for the Link TLV are defined: > > *************** > > > On Apr 5, 2008, at 12:51 PM, Acee Lindem wrote: > >> Adrian, >> >> How's this: >> >> *************** >> *** 342,348 **** >> The Link TLV describes a single link and consists of a set of >> sub- >> TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID >> sub- >> TLV are applicable to OSPFv3. The Link ID sub-TLV can't be >> used in >> ! OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3. >> >> Three new sub-TLVs for the Link TLV are defined: >> >> --- 342,351 ---- >> The Link TLV describes a single link and consists of a set of >> sub- >> TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID >> sub- >> TLV are applicable to OSPFv3. The Link ID sub-TLV can't be >> used in >> ! OSPFv3 since it defined to contain the IPv4 address of the >> Designated >> ! Router (DR) for multi-access interfaces. In contrast to OSPFv2, >> ! OSPFv3 always identifies a neighboring router by the Router ID >> (Refer >> ! to section 2.11 in [OSPFV3]). >> >> Three new sub-TLVs for the Link TLV are defined: >> >> *************** >> >> I plan to wait until the WG last call has completed to submit the >> update. >> Thanks, >> Acee >> >> On Apr 5, 2008, at 11:50 AM, Acee Lindem wrote: >> >>> Hi Adrian, >>> >>> Thanks for the review. >>> >>> On Apr 4, 2008, at 3:56 PM, Adrian Farrel wrote: >>> >>>> Hi, >>>> >>>> Just a couple of comments... >>>> >>>> === >>>> Section 1 >>>> s/proposes the addition of/defines/ >>> >>> Changed. >>> >>> >>>> === >>>> Section 4 >>>> Forgive me for not remembering this discussion... >>>> The draft says that we cannot use the Link ID sub-TLV "due to the >>>> protocol >>>> differences." >>> >>> The link-ID is cannot be used since, in the case of multi-access >>> network, it contains the IPv4 address of the Designated Router (DR). >>> OSPFv3 doesn't have this information. >>> >>> >>>> It then says that the Link ID sub-TLV SHOULD NOT be included >>>> (implying that >>>> it MAY be included under certain circumstances) but MUST be ignored. >>> >>> This is the spirit of being conservative in what one sends and >>> liberal in what one excepts. >>> >>> >>> >>>> 1. Does ignored mean "continue to be flooded" or "stripped from the >>>> LSA"? >>> >>> In OSPF, only the originator should modify an LSA. So, it means >>> neither. >>> >>> >>> >>>> 2. Is it not possible to consider operating a GMPLS control plane >>>> in an IPv6 >>>> network where the routers use IPv6 addresses to communicate (so all >>>> control >>>> plane messages will be addressed using IPv6, and the router address >>>> will be >>>> IPv6 as described in Section 3) but where the data channel >>>> identifiers are >>>> assigned from an IPv4 address space? Recall that in GMPLS the >>>> interfaces >>>> used for OSPF exchange are not those used for data exchange. >>> >>> I believe it is probable that IPv4 and IPv6 will coexist. However, >>> OSPFv3 doesn't know the IPv4 address of the DR (at least it is not >>> standardized). Hence, this isn't the right sub-TLV to reflect this >>> topology. >>> >>> >>> >>>> >>>> Whatever the answers, I think it would help if the reasons were >>>> clarified >>>> beyond "protocol differences." >>> >>> I'll expand this to describe the multi-access network case. Sound >>> good? >>> >>> Thanks, >>> Acee >>> >>> >>> >>>> === >>>> >>>> Cheers, >>>> Adrian >>>> >>>> PS I wouldn't mind if you spelled my name right in the acks >>>> section :-) >>>> >>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From owner-ccamp@ops.ietf.org Mon Apr 7 10:01:03 2008 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 6C79C3A6816 for ; Mon, 7 Apr 2008 10:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 xJwjG6YsWVN9 for ; Mon, 7 Apr 2008 10:00:58 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 622923A6C73 for ; Mon, 7 Apr 2008 10:00:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JiubP-000JSV-SB for ccamp-data@psg.com; Mon, 07 Apr 2008 16:53:51 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JiubM-000JRZ-RG for ccamp@ops.ietf.org; Mon, 07 Apr 2008 16:53:50 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m37Griah019936 for ; Mon, 7 Apr 2008 17:53:44 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m37GrgHb019918 for ; Mon, 7 Apr 2008 17:53:44 +0100 Message-ID: <033b01c898cf$ee650830$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <03cc01c89048$6717b0b0$0300a8c0@your029b8cecfe> Subject: Continued Poll for Adoption of Ethernet I-Ds Date: Mon, 7 Apr 2008 17:53:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, We have seen some good support for these I-Ds and no objections, but I don't think we have seen anything like the level of support that was evident in the room in Philadelphia. We haven't seen support from more than half of the authors of the documents. So, please, if you haven't already done so, give an indication of whether or not you support each of these four documents becoming working group drafts. Remember, you can be in favor of some and not other if you like. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, March 27, 2008 9:23 PM Subject: Polling for Adoption of Ethernet I-Ds > Hi, > > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP > working group documents. > > Please express your opinions. > > Note that acceptance of these I-Ds does not mean that the discussion about > the architecture is done. I think we made some progress on that topic in > Philadelphia, and I think the authors took on the task of making some > updates of semantics and for clarity, but I expect the discussion may go > on for a while. > > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > draft-berger-ccamp-gmpls-mef-uni-02.txt > draft-berger-ccamp-gmpls-ether-svcs-01.txt > > Thanks, > Adrian > > > From owner-ccamp@ops.ietf.org Mon Apr 7 12:03:29 2008 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 DA96A28C2BD for ; Mon, 7 Apr 2008 12:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 o-J4whYVlzh5 for ; Mon, 7 Apr 2008 12:03:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC99928C262 for ; Mon, 7 Apr 2008 12:02:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JiwQE-000B3f-Ih for ccamp-data@psg.com; Mon, 07 Apr 2008 18:50:26 +0000 Received: from [47.140.192.56] (helo=zrtps0kp.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JiwQB-000B2j-NX for ccamp@ops.ietf.org; Mon, 07 Apr 2008 18:50:25 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m37InpR00126; Mon, 7 Apr 2008 18:49:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Polling for Adoption of Ethernet I-Ds Date: Mon, 7 Apr 2008 14:49:49 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1468B0AA@zcarhxm0.corp.nortel.com> In-Reply-To: <03cc01c89048$6717b0b0$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Polling for Adoption of Ethernet I-Ds Thread-Index: AciQSzi1US4kTWcKRlOB8mr6QZczRQIlN0aQ References: <03cc01c89048$6717b0b0$0300a8c0@your029b8cecfe> From: "Hamid Ould-Brahim" To: "Adrian Farrel" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk Yes to all. Hamid. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, March 27, 2008 4:23 PM > To: ccamp@ops.ietf.org > Subject: Polling for Adoption of Ethernet I-Ds >=20 > Hi, >=20 > From Philadelphia, we have four candidate I-Ds for adoption=20 > as CCAMP working group documents. >=20 > Please express your opinions. >=20 > Note that acceptance of these I-Ds does not mean that the=20 > discussion about the architecture is done. I think we made=20 > some progress on that topic in Philadelphia, and I think the=20 > authors took on the task of making some updates of semantics=20 > and for clarity, but I expect the discussion may go on for a while. >=20 > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > draft-berger-ccamp-gmpls-mef-uni-02.txt > draft-berger-ccamp-gmpls-ether-svcs-01.txt >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Mon Apr 7 14:04:29 2008 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 C9BD63A6959 for ; Mon, 7 Apr 2008 14:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, 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 ZwlBiDEE5bzB for ; Mon, 7 Apr 2008 14:04:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CA35E3A6822 for ; Mon, 7 Apr 2008 14:04:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JiyQ1-0008bJ-LI for ccamp-data@psg.com; Mon, 07 Apr 2008 20:58:21 +0000 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JiyPx-0008Yk-Cl for ccamp@ops.ietf.org; Mon, 07 Apr 2008 20:58:19 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Apr 2008 21:58:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Mon, 7 Apr 2008 21:57:57 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0233D547@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <033b01c898cf$ee650830$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciY0DOIvMkBKwaUQCSYbnfEelfIHwADFARw From: To: , X-OriginalArrivalTime: 07 Apr 2008 20:58:16.0428 (UTC) FILETIME=[19E932C0:01C898F2] Sender: owner-ccamp@ops.ietf.org Precedence: bulk Adrian, Here is my view (with some brief rationale): > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt Notionally support. One concern I have revolves around the implications of this para: "4.1.3 Hybrid operation with legacy Ethernet The solution should take into consideration the operational scenario that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet hybrid networks. This morphs of network architecture is possible considering evolution scenario of Ethernet. In such networks, legacy Ethernet functionality such as Spanning Tree Protocol (SPT), Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE functionality. The solution must not prevent the simultaneous existence of GMPLS controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with native Ethernet Layer2 control protocols on same node and interface." We must avoid the mistake that different network modes (ie cl-ps or co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and also have the same CP). More specifically, native Ethernet is cl-ps and PBB-TE is co-ps....so even though the base DP traffic unit of these 2 different network modes looks the same they MUST exist in their own layer network space. This requires that some (lower) server layer network should create *different resource partitions* (in either space, freq or time dimensions) for each client layer network mode type. Aside=3D> For the case of private network services (which also includes 'network builder' transport services, ie how one creates client layer network topology) we are ultimately dealing with a time varying aggregate of message/file/stream applications.....these may not even be supported in the immediate client layer network, but there will ultimately be a 'very top' layer network that does support these. So in the server layer network what we have to deal with are (latent) abstractions of such time varying application aggregates. In such cases the key behaviour that the server network must provide to the client network is one of transparency, ie a client/server layer network relationship must provide full functional decoupling of the client and server layer networks. This is not simply a technically driven requirement but it also has commercial and (in some cases) regulatory drivers. Although this is a necessary condition (at least for reachability isolation of different client service instances) it is not generally sufficient for client service cases which require resource isolation (ie the traffic behaviour of client service instance X cannot impact the traffic behaviour experienced by client service instance Y). To satisfy the latter requirement the server layer network (i) must provide connections (ie only p2p or p2mp constructs allowed - which is also a necessary condition) and (ii) the server layer resources should not be overbooked (for a full sufficiency condition). Although not all client cases need this (strong resource isolation) service from the server layer network, the server layer network must nevertheless have the capability of providing it. All these requirements are forced to be met when the server layer technology belongs to the co-cs mode. However, care is required when the server layer network belongs to the co-ps mode (eg PBB-TE), eg don't violate the rules of a connection. And of course these requirements cannot be assured in the cl-ps mode as this does not, by definition, provide connections. > draft-fedyk-gmpls-ethernet-pbb-te-02.txt Support. Couple of small points: - OAM activation/deactivation (ie CV flow) needs to be synchronised to whatever CP or MP mechanism sets-up/tears-down ESPs for obvious operational reasons. Further, the CP (if ESP signalled) or MP (if ESP provisioned) needs to tell ESP DP sink trail termination point of the expected B-MAC SA. - Although IDs major on security from the perspective of malicious attacks (on the DP/CP/MP) there is also an aspect of security related to defects, ie customer traffic leaking from one connection into another connection under misconnectivity defects. A major advantage for operators and their customers of using domain-unique (non-swapped) labels is that misconnectivity defects are very unlikely to propagate, and in any case are always detectable at a connection trail termination point due to the B-MAC SA in each traffic unit. This benefit exists without running any OAM at all.....indeed, one only requires a CV OAM flow in PBB-TE to detect simple breaks such that they can be distinguished from a quiescent traffic case. This results in a significant opex benefit since it means operators only need to run OAM on important connections and not all connections (which is the case for label-swapping if misconnectivity defects must be detected). Maybe this 'security benefit' should be mentioned in the security section? > draft-berger-ccamp-gmpls-mef-uni-02.txt > draft-berger-ccamp-gmpls-ether-svcs-01.txt No problems with the IDs themselves, as they are only attempting to satisfy externally perceived requirements....but I do have a concern with the external requirements. When we talk about UNIs (and E-NNIs) we should be clear that we are actually dealing with public network services and the horizontal peer-partitioning of a single layer network between different operator and customer parties, ie this is NOT the same as the private 'network builder' case (briefly discussed previously) since that is based on a vertical client/server relationship between different layer networks. A critical issue (usually overlooked in my experience) here is the importance in being clear about the 'end-system message/file/stream application to first layer network adaptation functions'. Ethernet does not currently define such adaptation functions for message/file/stream applications (IP does of course with UDP, TCP and RTP respectively). I don't really want to go into all the detail here, but I simply want to make the point that before folks get too carried away defining UNIs/NNIs (for any network technology) they should be clear that this signifies a clear intention to develop public network services and requires careful attention to the end-system to first layer network adaptation functions.....so it's not simply about defining interworking between CP signalling or routing functions, or even DP OAM functions say. Therefore, as you might guess, whilst we in IETF/CCAMPs may quite easily define UNIs/E-NNIs for the DP (OAM) and CP say, we should also be cognizant of the ultimate implications of the direction MEF and ITU are taking here. Aside=3D> A slight twist on the above is where folks have considered = E-NNI peer interworking between *different* technologies. This recently came up in the ITU wrt T-MPLS OAM in draft G.8114 which was undergoing AAP. G.8114 contained a proposal to peer interwork T-MPLS and Ethernet networks simply because they had both been 'bestowed' with similar, and IMO far too complex, DP OAM. It should be self-evident that it is not sensible to try and interwork 2 technologies that belong to different network modes (simply because there will be significant functional component mismatch across the DP and CP), but in any case there are no end-system application to first layer network adaptations functions defined for either of these technologies (noting that if these were defined they would be required to either (i) pass transparently between the 2 network peer partitions at the interworking point if common or (ii) there would have to be interworking cases defined if not common). It was quite evident that no thought had been given to these matters whatsoever in G.8114 and so we requested that the interworking proposal was removed. Later, and as most folks probably know by now, the AAP progress of G.8114 was stopped anyway due to larger concerns that IETF had on T-MPLS in general.=20 regards, Neil=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: 07 April 2008 17:54 > To: ccamp@ops.ietf.org > Subject: Continued Poll for Adoption of Ethernet I-Ds >=20 >=20 > Hi, >=20 > We have seen some good support for these I-Ds and no > objections, but I don't=20 > think we have seen anything like the level of support that=20 > was evident in=20 > the room in Philadelphia. We haven't seen support from more=20 > than half of the=20 > authors of the documents. >=20 > So, please, if you haven't already done so, give an > indication of whether or=20 > not you support each of these four documents becoming working=20 > group drafts.=20 > Remember, you can be in favor of some and not other if you like. >=20 > Thanks, > Adrian >=20 > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Thursday, March 27, 2008 9:23 PM > Subject: Polling for Adoption of Ethernet I-Ds >=20 >=20 > > Hi, > > > > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP > > working group documents. > > > > Please express your opinions. > > > > Note that acceptance of these I-Ds does not mean that the > discussion > > about > > the architecture is done. I think we made some progress on > that topic in > > Philadelphia, and I think the authors took on the task of > making some > > updates of semantics and for clarity, but I expect the > discussion may go > > on for a while. > > > > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > > draft-berger-ccamp-gmpls-mef-uni-02.txt > > draft-berger-ccamp-gmpls-ether-svcs-01.txt > > > > Thanks, > > Adrian > > > > > >=20 >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Tue Apr 8 02:20:27 2008 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 04B4428C292 for ; Tue, 8 Apr 2008 02:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 5e7wXLyTPvxt for ; Tue, 8 Apr 2008 02:20:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5A6203A6C2F for ; Tue, 8 Apr 2008 02:19:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jj9ra-0004ST-Td for ccamp-data@psg.com; Tue, 08 Apr 2008 09:11:34 +0000 Received: from [64.233.184.235] (helo=wr-out-0506.google.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jj9rY-0004SC-A0 for ccamp@ops.ietf.org; Tue, 08 Apr 2008 09:11:33 +0000 Received: by wr-out-0506.google.com with SMTP id 58so1731559wri.8 for ; Tue, 08 Apr 2008 02:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=nGCzeV916RSKe0EfyUSg767MWnF39auoNj+xKG/tU3I=; b=SSSi3vE8W8chTK+5hUwB3bZSgvxx5PEWrFTuhe4E+A9UetjjhYJmStLamAw0dr6ikDZ3EYmhYbnh0KScsz33LmOIXzIwzgojD7jeqAwEnrshR/Zt5rHm6JnFEANxRhZMgQNyYu+i2NU/Xy3Y/aEuwf9JpYB6lJCz5JKZf+W8Rfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h+Ej6tnRFg6Wo6TwRukXR/UHFnEf/xau/27e8iLgF6BjsRDTdusDchIn5MOzFlrZmRe3mQS/a44PXlGZ5uNnZjInTFaasVSdHPpTZe4IaQ4Qs86w14+PbgFjsWS4AjqvlUumdjrIswpWo23pFW2R9hXh7GkOlPlsZfXHwGR+W+4= Received: by 10.151.145.5 with SMTP id x5mr3327583ybn.12.1207645889732; Tue, 08 Apr 2008 02:11:29 -0700 (PDT) Received: by 10.150.151.21 with HTTP; Tue, 8 Apr 2008 02:11:29 -0700 (PDT) Message-ID: <8c99930d0804080211w311159a8gceaebebbcbdf1334@mail.gmail.com> Date: Tue, 8 Apr 2008 05:11:29 -0400 From: "Andrew G. Malis" To: "Adrian Farrel" Subject: Re: Continued Poll for Adoption of Ethernet I-Ds Cc: ccamp@ops.ietf.org In-Reply-To: <033b01c898cf$ee650830$0300a8c0@your029b8cecfe> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <03cc01c89048$6717b0b0$0300a8c0@your029b8cecfe> <033b01c898cf$ee650830$0300a8c0@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk Adrian, Yes to all. Cheers, Andy On Mon, Apr 7, 2008 at 12:53 PM, Adrian Farrel wrote: > Hi, > > We have seen some good support for these I-Ds and no objections, but I don't > think we have seen anything like the level of support that was evident in > the room in Philadelphia. We haven't seen support from more than half of the > authors of the documents. > > So, please, if you haven't already done so, give an indication of whether or > not you support each of these four documents becoming working group drafts. > Remember, you can be in favor of some and not other if you like. > > Thanks, > Adrian > > ----- Original Message ----- From: "Adrian Farrel" > To: > Sent: Thursday, March 27, 2008 9:23 PM > Subject: Polling for Adoption of Ethernet I-Ds > > > > Hi, > > > > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP > working group documents. > > > > Please express your opinions. > > > > Note that acceptance of these I-Ds does not mean that the discussion about > the architecture is done. I think we made some progress on that topic in > Philadelphia, and I think the authors took on the task of making some > updates of semantics and for clarity, but I expect the discussion may go on > for a while. > > > > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > > draft-berger-ccamp-gmpls-mef-uni-02.txt > > draft-berger-ccamp-gmpls-ether-svcs-01.txt > > > > Thanks, > > Adrian > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Tue Apr 8 06:04:56 2008 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 84E393A6C8D for ; Tue, 8 Apr 2008 06:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, 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 lDA+VnSta0zK for ; Tue, 8 Apr 2008 06:04:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 526CB3A6879 for ; Tue, 8 Apr 2008 06:04:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjDKK-000PNR-9i for ccamp-data@psg.com; Tue, 08 Apr 2008 12:53:28 +0000 Received: from [217.32.164.151] (helo=smtp4.smtp.bt.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjDKH-000PMp-KH for ccamp@ops.ietf.org; Tue, 08 Apr 2008 12:53:26 +0000 Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Apr 2008 13:53:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Tue, 8 Apr 2008 13:53:22 +0100 Message-ID: <346DD76A8C47FD4A87FA57FD1DEBCC9C028A8144@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <033b01c898cf$ee650830$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciY0DOZ4hoiUpdsSWSqXbCAbNToMAAp0yoA From: To: , X-OriginalArrivalTime: 08 Apr 2008 12:53:23.0335 (UTC) FILETIME=[877D4170:01C89977] Sender: owner-ccamp@ops.ietf.org Precedence: bulk Yes to all Alan=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: 07 April 2008 17:54 To: ccamp@ops.ietf.org Subject: Continued Poll for Adoption of Ethernet I-Ds Hi, We have seen some good support for these I-Ds and no objections, but I don't think we have seen anything like the level of support that was evident in the room in Philadelphia. We haven't seen support from more than half of the authors of the documents. So, please, if you haven't already done so, give an indication of whether or not you support each of these four documents becoming working group drafts.=20 Remember, you can be in favor of some and not other if you like. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, March 27, 2008 9:23 PM Subject: Polling for Adoption of Ethernet I-Ds > Hi, > > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP=20 > working group documents. > > Please express your opinions. > > Note that acceptance of these I-Ds does not mean that the discussion about=20 > the architecture is done. I think we made some progress on that topic in=20 > Philadelphia, and I think the authors took on the task of making some=20 > updates of semantics and for clarity, but I expect the discussion may go=20 > on for a while. > > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > draft-berger-ccamp-gmpls-mef-uni-02.txt > draft-berger-ccamp-gmpls-ether-svcs-01.txt > > Thanks, > Adrian > > >=20 From owner-ccamp@ops.ietf.org Tue Apr 8 06:17:41 2008 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 7CC1D3A6983 for ; Tue, 8 Apr 2008 06:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 v16t7H2ljPjY for ; Tue, 8 Apr 2008 06:17:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7BD413A68E2 for ; Tue, 8 Apr 2008 06:17:40 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjDcq-0001KO-6R for ccamp-data@psg.com; Tue, 08 Apr 2008 13:12:36 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjDcj-0001JX-45 for ccamp@ops.ietf.org; Tue, 08 Apr 2008 13:12:30 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m38DCQWQ012829 for ; Tue, 8 Apr 2008 14:12:27 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m38DCKj9012685 for ; Tue, 8 Apr 2008 14:12:25 +0100 Message-ID: <002d01c8997a$2e23b110$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: draft-dasgupta-ccamp-path-comp-analysis-01 Date: Tue, 8 Apr 2008 14:12:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Forwarded on behalf of Sukrit who has some posting problems... ----- Original Message ----- From: "Sukrit Dasgupta" To: ; Sent: Monday, April 07, 2008 6:43 PM Subject: [Pce] draft-dasgupta-ccamp-path-comp-analysis-01 > Hi CCAMP and PCE > > We have an ID: draft-dasgupta-ccamp-path-comp-analysis-01.txt that > was presented in IETF 69 at Chicago. This draft captures a > performance comparison of the per-domain path computation technique > and PCE based path computation for computing inter-domain paths. The > goal of this document is not to pick a winner but to shed some light > on a few performance metrics with simulations carried out on two > representative scenarios. > > During the presentation at IETF69, we had positive comments and > support for this draft. A few comments made on the CCAMP list have > been incorporated. > > ------------------------------------------------------------------------ > ----------------------------------------------------------------------- > Abstract: > This document presents a performance comparison between the per- > domain path computation method and the Path Computation Element > (PCE) > Architecture based Backward Recursive Path Computation (BRPC) > procedure. Metrics to capture the significant performance aspects > are identified and detailed simulations are carried out on realistic > scenarios. A performance analysis for each of the path computation > methods is then undertaken. > ------------------------------------------------------------------------ > ----------------------------------------------------------------------- > > ASCII version: http://www.ietf.org/internet-drafts/draft-dasgupta- > ccamp-path-comp-analysis-01.txt > PDF version: http://www.ietf.org/internet-drafts/draft-dasgupta-ccamp- > path-comp-analysis-01.pdf > > > It would be great if we could get some input/comments/suggestions on > this work from the lists so we could proceed. > > Thanks and Regards, > Sukrit From owner-ccamp@ops.ietf.org Tue Apr 8 07:00:58 2008 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 D5B393A6ECA for ; Tue, 8 Apr 2008 07:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 ag+WLjlSCxdl for ; Tue, 8 Apr 2008 07:00:52 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE03428C3A6 for ; Tue, 8 Apr 2008 07:00:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjEEx-0005Vi-Rh for ccamp-data@psg.com; Tue, 08 Apr 2008 13:51:59 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjEEv-0005Ug-54 for ccamp@ops.ietf.org; Tue, 08 Apr 2008 13:51:58 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m38DprtS031815 for ; Tue, 8 Apr 2008 14:51:53 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m38DpoLw031739 for ; Tue, 8 Apr 2008 14:51:52 +0100 Message-ID: <006f01c8997f$b227aca0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Last Call: draft-ietf-tsvwg-rsvp-user-error-spec (User-Defined Errors for RSVP) to Proposed Standard Date: Tue, 8 Apr 2008 14:51:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Note well. Adrian ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Cc: Sent: Monday, April 07, 2008 2:41 PM Subject: Last Call: draft-ietf-tsvwg-rsvp-user-error-spec (User-Defined Errors for RSVP) to Proposed Standard > The IESG has received a request from the Transport Area Working Group WG > (tsvwg) to consider the following document: > > - 'User-Defined Errors for RSVP ' > as a Proposed Standard > > 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 2008-04-21. 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-tsvwg-rsvp-user-error-spec-06.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15932&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From owner-ccamp@ops.ietf.org Tue Apr 8 07:42:07 2008 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 041CE28C289 for ; Tue, 8 Apr 2008 07:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 zglwXKuFjqyf for ; Tue, 8 Apr 2008 07:42:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 234B828C253 for ; Tue, 8 Apr 2008 07:42:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjEvO-0009oK-Eh for ccamp-data@psg.com; Tue, 08 Apr 2008 14:35:50 +0000 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjEvE-0009nX-7E for ccamp@ops.ietf.org; Tue, 08 Apr 2008 14:35:45 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 3E85DEC8F8 for ; Tue, 8 Apr 2008 23:35:39 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id D35D4EC8F3 for ; Tue, 8 Apr 2008 23:35:38 +0900 (JST) Received: from [127.0.0.1] (c013.vpn.kddilabs.jp [172.19.87.13]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 73B62578111 for ; Tue, 8 Apr 2008 23:35:35 +0900 (JST) Message-ID: <47FB82A5.8040309@cn.kddilabs.jp> Date: Tue, 08 Apr 2008 23:35:17 +0900 From: "Ogaki, Kenichi" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Continued Poll for Adoption of Ethernet I-Ds References: <03cc01c89048$6717b0b0$0300a8c0@your029b8cecfe> <033b01c898cf$ee650830$0300a8c0@your029b8cecfe> In-Reply-To: <033b01c898cf$ee650830$0300a8c0@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, Yes to all. Best regards, Kenichi Adrian Farrel wrote: > Hi, > > We have seen some good support for these I-Ds and no objections, but I > don't think we have seen anything like the level of support that was > evident in the room in Philadelphia. We haven't seen support from more > than half of the authors of the documents. > > So, please, if you haven't already done so, give an indication of > whether or not you support each of these four documents becoming > working group drafts. Remember, you can be in favor of some and not > other if you like. > > Thanks, > Adrian > > ----- Original Message ----- From: "Adrian Farrel" > To: > Sent: Thursday, March 27, 2008 9:23 PM > Subject: Polling for Adoption of Ethernet I-Ds > > >> Hi, >> >> >From Philadelphia, we have four candidate I-Ds for adoption as CCAMP >> working group documents. >> >> Please express your opinions. >> >> Note that acceptance of these I-Ds does not mean that the discussion >> about the architecture is done. I think we made some progress on that >> topic in Philadelphia, and I think the authors took on the task of >> making some updates of semantics and for clarity, but I expect the >> discussion may go on for a while. >> >> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt >> draft-fedyk-gmpls-ethernet-pbb-te-02.txt >> draft-berger-ccamp-gmpls-mef-uni-02.txt >> draft-berger-ccamp-gmpls-ether-svcs-01.txt >> >> Thanks, >> Adrian >> >> >> > > > > > From owner-ccamp@ops.ietf.org Tue Apr 8 13:16:16 2008 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 CA59828C41A for ; Tue, 8 Apr 2008 13:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.008 X-Spam-Level: X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 lC6jLpA99452 for ; Tue, 8 Apr 2008 13:16:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 13DF828C43B for ; Tue, 8 Apr 2008 13:15:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjK7D-000OWQ-Ki for ccamp-data@psg.com; Tue, 08 Apr 2008 20:08:23 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjK7A-000OVP-Iv for ccamp@ops.ietf.org; Tue, 08 Apr 2008 20:08:22 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m38K8FCM012134; Tue, 8 Apr 2008 21:08:16 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m38K8E2B012125; Tue, 8 Apr 2008 21:08:15 +0100 Message-ID: <012601c899b4$46ac0220$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: References: <043e01c888f6$628ab910$0200a8c0@your029b8cecfe> <53CCFDD6E346CB43994852666C210E91026247E0@esealmw116.eemea.ericsson.se> <073c01c889dd$aa511f40$0200a8c0@your029b8cecfe> <000d01c88a52$d1b5e7d0$7521b770$@edu.cn> Subject: Editorial comment about draft-ietf-ccamp-lsp-dppm-00.txt Date: Tue, 8 Apr 2008 21:08:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, Here are some editorial comments for your draft. These changes will help your draft through the IETF process and will make it easier to review for others. Cheers, Adrian === Document header s/ccamp/Network Working Group/ (This is for obscure historic reasons :-) === Author list You need to reduce to a list of no more than four authors listed on the front page. Others can continue to be listed in the section at the end of the draft. There are two ways to handle this: 1. If some of the authros are doing most of the work, keep them on the front page, but remove the others. 2. If one or two people are editing the work done by the rest of the team, leave them on the frint page and mark them as "(Editor)". === Document title s/Dynamical/Dynamic/ === Abstract s/for the future data transmission/for future data transmission/ s/The GMPLS/GMPLS/ s/cooperate/operate/ s/in metro area/in metro areas/ === 1. Introduction s/cooperate/operate/ s/This draft intends to define/This document defines/ s/The metrics defined in this draft/The metrics defined in this document/ === 1. Introduction For example, an new object can be added to the GMPLS TE STD MIB [RFC4802] such that the current and past control plane performance can be monitored through network management systems. The extension of TE-MIB to support the metrics defined is out the scope of this document. I think that technically you cannot add objects to a defined MIB module, but you can define extensions to a MIB module to contain new objects. === 2. Conventions Used in This Document I don't think you need this text as you do not use any of the formal language. === 3. Overview of Performance Metrics I would like to see a little more introduction to what we are going to get in sections 4 to 8, and then 9 through 12. in other words, an overview of what is coming later so that I can navigate the rest of the document a little more easily. === 4. A Singleton Definition for single unidirectional LSP Setup Delay Can you make all section headings use captials. For example, 4. A Singleton Definition for Single Unidirectional LSP Setup Delay === 14. Discussion s/But in the draft/But in this document/ === 15. Security Considerations This section is a little thin! Could the information you propose to collect be used to facilitate attacks? For example by identifying weak spots in the network. Could the collection of information impact the operation of the network? If this is the case, requesting that performance behavior is monitored and reported could be used to attack the network. === You are missing an IANA section. This can simply say... X. IANA Considerations This document makes no requests for IANA action. === 17. Normative References [RFC2119] You might not need this any more if you delete Section 2. [RFC2330] This is an Informational RFC. If you can, you should make it an Informative Reference. This is not absolutely required - if you believe it really is normative (i.e., your document cannot be read without reference to this RFC) then it is OK to keep it as a Normative Reference. From owner-ccamp@ops.ietf.org Tue Apr 8 14:23:28 2008 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 6060D3A6AC2 for ; Tue, 8 Apr 2008 14:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 uWk76aRQLu1Z for ; Tue, 8 Apr 2008 14:23:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DA79D3A6969 for ; Tue, 8 Apr 2008 14:23:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjLBI-0004yU-Vc for ccamp-data@psg.com; Tue, 08 Apr 2008 21:16:40 +0000 Received: from [209.191.85.52] (helo=web36801.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjLBE-0004y1-Nl for ccamp@ops.ietf.org; Tue, 08 Apr 2008 21:16:38 +0000 Received: (qmail 29586 invoked by uid 60001); 8 Apr 2008 21:16:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=F/d6SkNfUDna2wwd/Ngj5niv0R1YPM9GkfP3xsc+0wKeb/GuHlhqiFdKb2sIevMZAuxie8UzVqtq/D0B3yHV9lxPQugl6RcVzx7NvH993VMVqLLfgGqD91jSP3b84fdUgGAcFeIUDi4lIQh1YRX/8nYuWuIiQePoGoG/E3dLx1U=; X-YMail-OSG: IAgf4YUVM1llKl2hsiK_jbj66x7kR5o7Hct_PMeIBFUF9VwHdKQa2fiZDdb_3CQzaCafh3UJkKgaofq91q3YEVZQV2TyGp05mcZjPPOzCuZm358- Received: from [67.102.145.11] by web36801.mail.mud.yahoo.com via HTTP; Tue, 08 Apr 2008 14:16:35 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Tue, 8 Apr 2008 14:16:35 -0700 (PDT) From: Igor Bryskin Subject: Re: Continued Poll for Adoption of Ethernet I-Ds To: neil.2.harrison@bt.com, adrian@olddog.co.uk, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1744815800-1207689395=:29318" Message-ID: <957328.29318.qm@web36801.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk --0-1744815800-1207689395=:29318 Content-Type: text/plain; charset=us-ascii Hi Neil. Please, see my question in-line. Regards, Igor ----- Original Message ---- From: "neil.2.harrison@bt.com" To: adrian@olddog.co.uk; ccamp@ops.ietf.org Sent: Monday, April 7, 2008 4:57:57 PM Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Adrian, Here is my view (with some brief rationale): > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt Notionally support. One concern I have revolves around the implications of this para: "4.1.3 Hybrid operation with legacy Ethernet The solution should take into consideration the operational scenario that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet hybrid networks. This morphs of network architecture is possible considering evolution scenario of Ethernet. In such networks, legacy Ethernet functionality such as Spanning Tree Protocol (SPT), Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE functionality. The solution must not prevent the simultaneous existence of GMPLS controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with native Ethernet Layer2 control protocols on same node and interface." We must avoid the mistake that different network modes (ie cl-ps or co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and also have the same CP). More specifically, native Ethernet is cl-ps and PBB-TE is co-ps....so even though the base DP traffic unit of these 2 different network modes looks the same they MUST exist in their own layer network space. This requires that some (lower) server layer network should create *different resource partitions* (in either space, freq or time dimensions) for each client layer network mode type. IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two. What am I missing here? Thanks, Igor Aside=> For the case of private network services (which also includes 'network builder' transport services, ie how one creates client layer network topology) we are ultimately dealing with a time varying aggregate of message/file/stream applications.....these may not even be supported in the immediate client layer network, but there will ultimately be a 'very top' layer network that does support these. So in the server layer network what we have to deal with are (latent) abstractions of such time varying application aggregates. In such cases the key behaviour that the server network must provide to the client network is one of transparency, ie a client/server layer network relationship must provide full functional decoupling of the client and server layer networks. This is not simply a technically driven requirement but it also has commercial and (in some cases) regulatory drivers. Although this is a necessary condition (at least for reachability isolation of different client service instances) it is not generally sufficient for client service cases which require resource isolation (ie the traffic behaviour of client service instance X cannot impact the traffic behaviour experienced by client service instance Y). To satisfy the latter requirement the server layer network (i) must provide connections (ie only p2p or p2mp constructs allowed - which is also a necessary condition) and (ii) the server layer resources should not be overbooked (for a full sufficiency condition). Although not all client cases need this (strong resource isolation) service from the server layer network, the server layer network must nevertheless have the capability of providing it. All these requirements are forced to be met when the server layer technology belongs to the co-cs mode. However, care is required when the server layer network belongs to the co-ps mode (eg PBB-TE), eg don't violate the rules of a connection. And of course these requirements cannot be assured in the cl-ps mode as this does not, by definition, provide connections. > draft-fedyk-gmpls-ethernet-pbb-te-02.txt Support. Couple of small points: - OAM activation/deactivation (ie CV flow) needs to be synchronised to whatever CP or MP mechanism sets-up/tears-down ESPs for obvious operational reasons. Further, the CP (if ESP signalled) or MP (if ESP provisioned) needs to tell ESP DP sink trail termination point of the expected B-MAC SA. - Although IDs major on security from the perspective of malicious attacks (on the DP/CP/MP) there is also an aspect of security related to defects, ie customer traffic leaking from one connection into another connection under misconnectivity defects. A major advantage for operators and their customers of using domain-unique (non-swapped) labels is that misconnectivity defects are very unlikely to propagate, and in any case are always detectable at a connection trail termination point due to the B-MAC SA in each traffic unit. This benefit exists without running any OAM at all.....indeed, one only requires a CV OAM flow in PBB-TE to detect simple breaks such that they can be distinguished from a quiescent traffic case. This results in a significant opex benefit since it means operators only need to run OAM on important connections and not all connections (which is the case for label-swapping if misconnectivity defects must be detected). Maybe this 'security benefit' should be mentioned in the security section? > draft-berger-ccamp-gmpls-mef-uni-02.txt > draft-berger-ccamp-gmpls-ether-svcs-01.txt No problems with the IDs themselves, as they are only attempting to satisfy externally perceived requirements....but I do have a concern with the external requirements. When we talk about UNIs (and E-NNIs) we should be clear that we are actually dealing with public network services and the horizontal peer-partitioning of a single layer network between different operator and customer parties, ie this is NOT the same as the private 'network builder' case (briefly discussed previously) since that is based on a vertical client/server relationship between different layer networks. A critical issue (usually overlooked in my experience) here is the importance in being clear about the 'end-system message/file/stream application to first layer network adaptation functions'. Ethernet does not currently define such adaptation functions for message/file/stream applications (IP does of course with UDP, TCP and RTP respectively). I don't really want to go into all the detail here, but I simply want to make the point that before folks get too carried away defining UNIs/NNIs (for any network technology) they should be clear that this signifies a clear intention to develop public network services and requires careful attention to the end-system to first layer network adaptation functions.....so it's not simply about defining interworking between CP signalling or routing functions, or even DP OAM functions say. Therefore, as you might guess, whilst we in IETF/CCAMPs may quite easily define UNIs/E-NNIs for the DP (OAM) and CP say, we should also be cognizant of the ultimate implications of the direction MEF and ITU are taking here. Aside=> A slight twist on the above is where folks have considered E-NNI peer interworking between *different* technologies. This recently came up in the ITU wrt T-MPLS OAM in draft G.8114 which was undergoing AAP. G.8114 contained a proposal to peer interwork T-MPLS and Ethernet networks simply because they had both been 'bestowed' with similar, and IMO far too complex, DP OAM. It should be self-evident that it is not sensible to try and interwork 2 technologies that belong to different network modes (simply because there will be significant functional component mismatch across the DP and CP), but in any case there are no end-system application to first layer network adaptations functions defined for either of these technologies (noting that if these were defined they would be required to either (i) pass transparently between the 2 network peer partitions at the interworking point if common or (ii) there would have to be interworking cases defined if not common). It was quite evident that no thought had been given to these matters whatsoever in G.8114 and so we requested that the interworking proposal was removed. Later, and as most folks probably know by now, the AAP progress of G.8114 was stopped anyway due to larger concerns that IETF had on T-MPLS in general. regards, Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: 07 April 2008 17:54 > To: ccamp@ops.ietf.org > Subject: Continued Poll for Adoption of Ethernet I-Ds > > > Hi, > > We have seen some good support for these I-Ds and no > objections, but I don't > think we have seen anything like the level of support that > was evident in > the room in Philadelphia. We haven't seen support from more > than half of the > authors of the documents. > > So, please, if you haven't already done so, give an > indication of whether or > not you support each of these four documents becoming working > group drafts. > Remember, you can be in favor of some and not other if you like. > > Thanks, > Adrian > > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Thursday, March 27, 2008 9:23 PM > Subject: Polling for Adoption of Ethernet I-Ds > > > > Hi, > > > > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP > > working group documents. > > > > Please express your opinions. > > > > Note that acceptance of these I-Ds does not mean that the > discussion > > about > > the architecture is done. I think we made some progress on > that topic in > > Philadelphia, and I think the authors took on the task of > making some > > updates of semantics and for clarity, but I expect the > discussion may go > > on for a while. > > > > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > > draft-berger-ccamp-gmpls-mef-uni-02.txt > > draft-berger-ccamp-gmpls-ether-svcs-01.txt > > > > Thanks, > > Adrian > > > > > > > > > > ____________________________________________________________________________________ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com --0-1744815800-1207689395=:29318 Content-Type: text/html; charset=us-ascii
Hi Neil. Please, see my question in-line.
Regards,
Igor

----- Original Message ----
From: "neil.2.harrison@bt.com" <neil.2.harrison@bt.com>
To: adrian@olddog.co.uk; ccamp@ops.ietf.org
Sent: Monday, April 7, 2008 4:57:57 PM
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

Adrian,  Here is my view (with some brief rationale):

> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt

Notionally support.  One concern I have revolves around the implications
of this para:

"4.1.3 Hybrid operation with legacy Ethernet

  The solution should take into consideration the operational scenario
  that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet
  hybrid networks. This morphs of network architecture is possible
  considering evolution scenario of Ethernet. In such networks, legacy
  Ethernet functionality such as Spanning Tree Protocol (SPT),
  Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE
  functionality.

  The solution must not prevent the simultaneous existence of GMPLS
  controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with
  native Ethernet Layer2 control protocols on same node and interface."

We must avoid the mistake that different network modes (ie cl-ps or
co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and
also have the same CP).  More specifically, native Ethernet is cl-ps and
PBB-TE is co-ps....so even though the base DP traffic unit of these 2
different network modes looks the same they MUST exist in their own
layer network space.  This requires that some (lower) server layer
network should create *different resource partitions* (in either space,
freq or time dimensions) for each client layer network mode type.

IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.

What am I missing here?

Thanks,
Igor

Aside=> For the case of private network services (which also includes
'network builder' transport services, ie how one creates client layer
network topology) we are ultimately dealing with a time varying
aggregate of message/file/stream applications.....these may not even be
supported in the immediate client layer network, but there will
ultimately be a 'very top' layer network that does support these.  So in
the server layer network what we have to deal with are (latent)
abstractions of such time varying application aggregates.  In such cases
the key behaviour that the server network must provide to the client
network is one of transparency, ie a client/server layer network
relationship must provide full functional decoupling of the client and
server layer networks.  This is not simply a technically driven
requirement but it also has commercial and (in some cases) regulatory
drivers.  Although this is a necessary condition (at least for
reachability isolation of different client service instances) it is not
generally sufficient for client service cases which require resource
isolation (ie the traffic behaviour of client service instance X cannot
impact the traffic behaviour experienced by client service instance Y).
To satisfy the latter requirement the server layer network (i) must
provide connections (ie only p2p or p2mp constructs allowed - which is
also a necessary condition) and (ii) the server layer resources should
not be overbooked (for a full sufficiency condition).  Although not all
client cases need this (strong resource isolation) service from the
server layer network, the server layer network must nevertheless have
the capability of providing it.

All these requirements are forced to be met when the server layer
technology belongs to the co-cs mode.  However, care is required when
the server layer network belongs to the co-ps mode (eg PBB-TE), eg don't
violate the rules of a connection.  And of course these requirements
cannot be assured in the cl-ps mode as this does not, by definition,
provide connections.


> draft-fedyk-gmpls-ethernet-pbb-te-02.txt

Support.  Couple of small points:
-    OAM activation/deactivation (ie CV flow) needs to be
synchronised to whatever CP or MP mechanism sets-up/tears-down ESPs for
obvious operational reasons.  Further, the CP (if ESP signalled) or MP
(if ESP provisioned) needs to tell ESP DP sink trail termination point
of the expected B-MAC SA.
-    Although IDs major on security from the perspective of malicious
attacks (on the DP/CP/MP) there is also an aspect of security related to
defects, ie customer traffic leaking from one connection into another
connection under misconnectivity defects.  A major advantage for
operators and their customers of using domain-unique (non-swapped)
labels is that misconnectivity defects are very unlikely to propagate,
and in any case are always detectable at a connection trail termination
point due to the B-MAC SA in each traffic unit. This benefit exists
without running any OAM at all.....indeed, one only requires a CV OAM
flow in PBB-TE to detect simple breaks such that they can be
distinguished from a quiescent traffic case.  This results in a
significant opex benefit since it means operators only need to run OAM
on important connections and not all connections (which is the case for
label-swapping if misconnectivity defects must be detected).  Maybe this
'security benefit' should be mentioned in the security section?


> draft-berger-ccamp-gmpls-mef-uni-02.txt
> draft-berger-ccamp-gmpls-ether-svcs-01.txt

No problems with the IDs themselves, as they are only attempting to
satisfy externally perceived requirements....but I do have a concern
with the external requirements.

When we talk about UNIs (and E-NNIs) we should be clear that we are
actually dealing with public network services and the horizontal
peer-partitioning of a single layer network between different operator
and customer parties, ie this is NOT the same as the private 'network
builder' case (briefly discussed previously) since that is based on a
vertical client/server relationship between different layer networks.  A
critical issue (usually overlooked in my experience) here is the
importance in being clear about the 'end-system message/file/stream
application to first layer network adaptation functions'.  Ethernet does
not currently define such adaptation functions for message/file/stream
applications (IP does of course with UDP, TCP and RTP respectively).  I
don't really want to go into all the detail here, but I simply want to
make the point that before folks get too carried away defining UNIs/NNIs
(for any network technology) they should be clear that this signifies a
clear intention to develop public network services and requires careful
attention to the end-system to first layer network adaptation
functions.....so it's not simply about defining interworking between CP
signalling or routing functions, or even DP OAM functions say.
Therefore, as you might guess, whilst we in IETF/CCAMPs may quite easily
define UNIs/E-NNIs for the DP (OAM) and CP say, we should also be
cognizant of the ultimate implications of the direction MEF and ITU are
taking here.

Aside=> A slight twist on the above is where folks have considered E-NNI
peer interworking between *different* technologies.  This recently came
up in the ITU wrt T-MPLS OAM in draft G.8114 which was undergoing AAP.
G.8114 contained a proposal to peer interwork T-MPLS and Ethernet
networks simply because they had both been 'bestowed' with similar, and
IMO far too complex, DP OAM.  It should be self-evident that it is not
sensible to try and interwork 2 technologies that belong to different
network modes (simply because there will be significant functional
component mismatch across the DP and CP), but in any case there are no
end-system application to first layer network adaptations functions
defined for either of these technologies (noting that if these were
defined they would be required to either (i) pass transparently between
the 2 network peer partitions at the interworking point if common or
(ii) there would have to be interworking cases defined if not common).
It was quite evident that no thought had been given to these matters
whatsoever in G.8114 and so we requested that the interworking proposal
was removed.  Later, and as most folks probably know by now, the AAP
progress of G.8114 was stopped anyway due to larger concerns that IETF
had on T-MPLS in general.

regards, Neil



> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> Sent: 07 April 2008 17:54
> To: ccamp@ops.ietf.org
> Subject: Continued Poll for Adoption of Ethernet I-Ds
>
>
> Hi,
>
> We have seen some good support for these I-Ds and no
> objections, but I don't
> think we have seen anything like the level of support that
> was evident in
> the room in Philadelphia. We haven't seen support from more
> than half of the
> authors of the documents.
>
> So, please, if you haven't already done so, give an
> indication of whether or
> not you support each of these four documents becoming working
> group drafts.
> Remember, you can be in favor of some and not other if you like.
>
> Thanks,
> Adrian
>
> ----- Original Message -----
> From: "Adrian Farrel" <adrian@olddog.co.uk>
> To: <ccamp@ops.ietf.org>
> Sent: Thursday, March 27, 2008 9:23 PM
> Subject: Polling for Adoption of Ethernet I-Ds
>
>
> > Hi,
> >
> > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP

> > working group documents.
> >
> > Please express your opinions.
> >
> > Note that acceptance of these I-Ds does not mean that the
> discussion
> > about
> > the architecture is done. I think we made some progress on
> that topic in
> > Philadelphia, and I think the authors took on the task of
> making some
> > updates of semantics and for clarity, but I expect the
> discussion may go
> > on for a while.
> >
> > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
> > draft-fedyk-gmpls-ethernet-pbb-te-02.txt
> > draft-berger-ccamp-gmpls-mef-uni-02.txt
> > draft-berger-ccamp-gmpls-ether-svcs-01.txt
> >
> > Thanks,
> > Adrian
> >
> >
> >
>
>
>
>



You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. --0-1744815800-1207689395=:29318-- From owner-ccamp@ops.ietf.org Tue Apr 8 14:23:29 2008 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 1BCE33A6969 for ; Tue, 8 Apr 2008 14:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 GcbqpIc+AuVv for ; Tue, 8 Apr 2008 14:23:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1041A3A6840 for ; Tue, 8 Apr 2008 14:23:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjLEZ-0005E0-0J for ccamp-data@psg.com; Tue, 08 Apr 2008 21:20:03 +0000 Received: from [12.146.0.153] (helo=edsel.sycamorenet.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjLEW-0005D9-3j for ccamp@ops.ietf.org; Tue, 08 Apr 2008 21:20:01 +0000 Received: from intrepid.sycamorenet.com ([10.5.1.108]) by edsel.sycamorenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Apr 2008 17:19:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Tue, 8 Apr 2008 17:19:54 -0400 Message-ID: In-Reply-To: <033b01c898cf$ee650830$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciY0KHD+nKzi8VGTxyjIAwTHRMYUAA7Z7ww From: "Pandian, Vijay" To: "Adrian Farrel" , X-OriginalArrivalTime: 08 Apr 2008 21:19:55.0188 (UTC) FILETIME=[4A71FF40:01C899BE] Sender: owner-ccamp@ops.ietf.org Precedence: bulk Yes to all. Vijay=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Monday, April 07, 2008 12:54 PM To: ccamp@ops.ietf.org Subject: Continued Poll for Adoption of Ethernet I-Ds Hi, We have seen some good support for these I-Ds and no objections, but I don't think we have seen anything like the level of support that was evident in the room in Philadelphia. We haven't seen support from more than half of the authors of the documents. So, please, if you haven't already done so, give an indication of whether or not you support each of these four documents becoming working group drafts.=20 Remember, you can be in favor of some and not other if you like. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, March 27, 2008 9:23 PM Subject: Polling for Adoption of Ethernet I-Ds > Hi, > > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP=20 > working group documents. > > Please express your opinions. > > Note that acceptance of these I-Ds does not mean that the discussion about=20 > the architecture is done. I think we made some progress on that topic in=20 > Philadelphia, and I think the authors took on the task of making some=20 > updates of semantics and for clarity, but I expect the discussion may go=20 > on for a while. > > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > draft-berger-ccamp-gmpls-mef-uni-02.txt > draft-berger-ccamp-gmpls-ether-svcs-01.txt > > Thanks, > Adrian > > >=20 From owner-ccamp@ops.ietf.org Tue Apr 8 17:52:23 2008 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 23C2428C39D for ; Tue, 8 Apr 2008 17:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 eT2VOt2PZWEN for ; Tue, 8 Apr 2008 17:52:22 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 53A0828C385 for ; Tue, 8 Apr 2008 17:52:22 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjOOL-000J7G-Hr for ccamp-data@psg.com; Wed, 09 Apr 2008 00:42:21 +0000 Received: from [129.60.39.147] (helo=tama50.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjOOI-000J6o-EI for ccamp@ops.ietf.org; Wed, 09 Apr 2008 00:42:20 +0000 Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m390gFXK019682 for ; Wed, 9 Apr 2008 09:42:15 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id C2F886BFB for ; Wed, 9 Apr 2008 09:42:15 +0900 (JST) Received: from dmailsv1.y.ecl.ntt.co.jp (dmailsv1.y.ecl.ntt.co.jp [129.60.53.14]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id BA6006B9E for ; Wed, 9 Apr 2008 09:42:15 +0900 (JST) Received: from mailsv14.y.ecl.ntt.co.jp by dmailsv1.y.ecl.ntt.co.jp (8.14.2/dmailsv1-2.0) with ESMTP id m390gF5I009600 for ; Wed, 9 Apr 2008 09:42:15 +0900 (JST) Received: from localhost by mailsv14.y.ecl.ntt.co.jp (8.14.1/Lab-1.7) with ESMTP id m390gE6U028177 for ; Wed, 9 Apr 2008 09:42:15 +0900 (JST) Message-Id: <6.0.0.20.2.20080409001807.06c43b50@mailsv4.y.ecl.ntt.co.jp> X-Sender: wi002@mailsv4.y.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Wed, 09 Apr 2008 09:47:31 +0900 To: From: Wataru Imajuku Subject: Re: Polling for Adoption of Ethernet I-Ds In-Reply-To: <03cc01c89048$6717b0b0$0300a8c0@your029b8cecfe> References: <03cc01c89048$6717b0b0$0300a8c0@your029b8cecfe> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, Yes to all. Best Regards Wataru At 05:23 08/03/28, Adrian Farrel wrote: >Hi, > >From Philadelphia, we have four candidate I-Ds for adoption as CCAMP working group documents. > >Please express your opinions. > >Note that acceptance of these I-Ds does not mean that the discussion about the architecture is done. I think we made some progress on that topic in Philadelphia, and I think the authors took on the task of making some updates of semantics and for clarity, but I expect the discussion may go on for a while. > >draft-imajuku-ccamp-ethernet-gmpls-req-01.txt >draft-fedyk-gmpls-ethernet-pbb-te-02.txt >draft-berger-ccamp-gmpls-mef-uni-02.txt >draft-berger-ccamp-gmpls-ether-svcs-01.txt > >Thanks, >Adrian > > ------------------------------------- Wataru Imajuku@NTT Network Innovation Labs TEL: +81-46-859-4315 FAX: +81-46-859-5541 From owner-ccamp@ops.ietf.org Tue Apr 8 19:52:51 2008 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 6EBAF28C25E for ; Tue, 8 Apr 2008 19:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 iAIqwijv0KRo for ; Tue, 8 Apr 2008 19:52:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D1FF73A6895 for ; Tue, 8 Apr 2008 19:52:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjQGa-000PoA-H9 for ccamp-data@psg.com; Wed, 09 Apr 2008 02:42:28 +0000 Received: from [202.112.26.52] (helo=mx2.sjtu.edu.cn) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjQGW-000Pnr-M8 for ccamp@ops.ietf.org; Wed, 09 Apr 2008 02:42:26 +0000 Received: from localhost (localhost [127.0.0.1]) by mx2.sjtu.edu.cn (Postfix) with ESMTP id 30EA92C232; Wed, 9 Apr 2008 10:42:19 +0800 (CST) X-Virus-Scanned: Debian amavisd-new at sjtu.edu.cn Received: from mx2.sjtu.edu.cn ([127.0.0.1]) by localhost (mx2.sjtu.edu.cn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5O+T57hdperC; Wed, 9 Apr 2008 10:42:18 +0800 (CST) Received: from msc07ad750c26b (unknown [202.120.39.240]) (Authenticated sender: sunwq) by mx2.sjtu.edu.cn (Postfix) with ESMTP id 0D5B92C23A; Wed, 9 Apr 2008 10:42:18 +0800 (CST) Reply-To: From: "Weiqiang Sun" To: "'Adrian Farrel'" Cc: References: <043e01c888f6$628ab910$0200a8c0@your029b8cecfe> <53CCFDD6E346CB43994852666C210E91026247E0@esealmw116.eemea.ericsson.se> <073c01c889dd$aa511f40$0200a8c0@your029b8cecfe> <000d01c88a52$d1b5e7d0$7521b770$@edu.cn> <012601c899b4$46ac0220$0300a8c0@your029b8cecfe> In-Reply-To: <012601c899b4$46ac0220$0300a8c0@your029b8cecfe> Subject: RE: Editorial comment about draft-ietf-ccamp-lsp-dppm-00.txt Date: Wed, 9 Apr 2008 10:41:56 +0800 Organization: Shanghai Jiao Tong University Message-ID: <002701c899eb$48776e50$d9664af0$@edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciZtFY8IND/XzYcRPidD5/Dxrt/zwANhn2Q Content-Language: zh-cn Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Adrian, Many thanks for the thorough comments. We will get them fixed one by one and post it again. Best regards, Weiqiang -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, April 09, 2008 4:08 AM To: sunwq@sjtu.edu.cn Cc: ccamp@ops.ietf.org Subject: Editorial comment about draft-ietf-ccamp-lsp-dppm-00.txt Hi, Here are some editorial comments for your draft. These changes will help your draft through the IETF process and will make it easier to review for others. Cheers, Adrian === Document header s/ccamp/Network Working Group/ (This is for obscure historic reasons :-) === Author list You need to reduce to a list of no more than four authors listed on the front page. Others can continue to be listed in the section at the end of the draft. There are two ways to handle this: 1. If some of the authros are doing most of the work, keep them on the front page, but remove the others. 2. If one or two people are editing the work done by the rest of the team, leave them on the frint page and mark them as "(Editor)". === Document title s/Dynamical/Dynamic/ === Abstract s/for the future data transmission/for future data transmission/ s/The GMPLS/GMPLS/ s/cooperate/operate/ s/in metro area/in metro areas/ === 1. Introduction s/cooperate/operate/ s/This draft intends to define/This document defines/ s/The metrics defined in this draft/The metrics defined in this document/ === 1. Introduction For example, an new object can be added to the GMPLS TE STD MIB [RFC4802] such that the current and past control plane performance can be monitored through network management systems. The extension of TE-MIB to support the metrics defined is out the scope of this document. I think that technically you cannot add objects to a defined MIB module, but you can define extensions to a MIB module to contain new objects. === 2. Conventions Used in This Document I don't think you need this text as you do not use any of the formal language. === 3. Overview of Performance Metrics I would like to see a little more introduction to what we are going to get in sections 4 to 8, and then 9 through 12. in other words, an overview of what is coming later so that I can navigate the rest of the document a little more easily. === 4. A Singleton Definition for single unidirectional LSP Setup Delay Can you make all section headings use captials. For example, 4. A Singleton Definition for Single Unidirectional LSP Setup Delay === 14. Discussion s/But in the draft/But in this document/ === 15. Security Considerations This section is a little thin! Could the information you propose to collect be used to facilitate attacks? For example by identifying weak spots in the network. Could the collection of information impact the operation of the network? If this is the case, requesting that performance behavior is monitored and reported could be used to attack the network. === You are missing an IANA section. This can simply say... X. IANA Considerations This document makes no requests for IANA action. === 17. Normative References [RFC2119] You might not need this any more if you delete Section 2. [RFC2330] This is an Informational RFC. If you can, you should make it an Informative Reference. This is not absolutely required - if you believe it really is normative (i.e., your document cannot be read without reference to this RFC) then it is OK to keep it as a Normative Reference. From owner-ccamp@ops.ietf.org Wed Apr 9 01:03:37 2008 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 6C7F73A6AD4 for ; Wed, 9 Apr 2008 01:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 HFzSY70tI+jB for ; Wed, 9 Apr 2008 01:03:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E0B223A6BCC for ; Wed, 9 Apr 2008 01:03:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjV4v-000PGJ-WA for ccamp-data@psg.com; Wed, 09 Apr 2008 07:50:46 +0000 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjV4s-000PFT-MH for ccamp@ops.ietf.org; Wed, 09 Apr 2008 07:50:44 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 08:50:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89A16.66948A36" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Wed, 9 Apr 2008 08:48:29 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0239EC2C@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <957328.29318.qm@web36801.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciZvdU00p78wmPjQTmVUbI9h7E4/wAUo6cg From: To: , , X-OriginalArrivalTime: 09 Apr 2008 07:50:38.0654 (UTC) FILETIME=[66E8A5E0:01C89A16] Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C89A16.66948A36 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor....please see in-line (have snipped mail to your question only) =20 Igor Bryskin wrote 08 April 2008 22:17 > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt Notionally support. One concern I have revolves around the implications of this para: "4.1.3 Hybrid operation with legacy Ethernet The solution should take into consideration the operational scenario that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet hybrid networks. This morphs of network architecture is possible considering evolution scenario of Ethernet. In such networks, legacy Ethernet functionality such as Spanning Tree Protocol (SPT), Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE functionality. The solution must not prevent the simultaneous existence of GMPLS controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with native Ethernet Layer2 control protocols on same node and interface." We must avoid the mistake that different network modes (ie cl-ps or co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and also have the same CP). More specifically, native Ethernet is cl-ps and PBB-TE is co-ps....so even though the base DP traffic unit of these 2 different network modes looks the same they MUST exist in their own layer network space. This requires that some (lower) server layer network should create *different resource partitions* (in either space, freq or time dimensions) for each client layer network mode type. IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.=20 What am I missing here? Thanks, Igor=20 =20 NH=3D> Excellent question. I have made exactly this same observation in the past. In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks. I think there are 2 reasons for this: =20 - Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks. So this issue may not be so obvious to many folks in IEEE. Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling. However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks. So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true. =20 - Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware. Maybe some of the Ethernet hardware experts can provide further clarification here. =20 =20 One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to. =20 regards, Neil ------_=_NextPart_001_01C89A16.66948A36 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi Igor....please see in-line (have snipped mail to your = question=20 only)
 
Igor Bryskin  wrote=20 08 April 2008 22:17

>=20 draft-imajuku-ccamp-ethernet-gmpls-req-01.txt

Notionally = support. =20 One concern I have revolves around the implications
of this=20 para:

"4.1.3 Hybrid operation with legacy Ethernet

  = The=20 solution should take into consideration the operational = scenario
  that=20 GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet
  = hybrid=20 networks. This morphs of network architecture is possible
  = considering=20 evolution scenario of Ethernet. In such networks, legacy
  = Ethernet=20 functionality such as Spanning Tree Protocol (SPT),
  Link = Aggregation=20 [IEEE802.3], and so on must co-exist with PBB-TE
 =20 functionality.

  The solution must not prevent the = simultaneous=20 existence of GMPLS
  controlled Eth-LSPs and PBB[IEE802.1ah] or=20 PB[IEE802.1ad] with
  native Ethernet Layer2 control protocols = on same=20 node and interface."

We must avoid the mistake that different = network=20 modes (ie cl-ps or
co-ps or co-cs) can somehow 'co-exist' in the same = DP=20 layer network (and
also have the same CP).  More specifically, = native=20 Ethernet is cl-ps and
PBB-TE is co-ps....so even though the base DP = traffic=20 unit of these 2
different network modes looks the same they MUST = exist in=20 their own
layer network space.  This requires that some (lower) = server=20 layer
network should create *different resource partitions* (in = either=20 space,
freq or time dimensions) for each client layer network mode=20 type.

IB>> I agree with what you are saying. What confuses = me,=20 though, is that 802.1ay prescribes allocating of certain range(s) of = VLANIDs for=20 the PBB-TE use, while allowing use of other VLANIDs for their native = Ethernet=20 purposes. I wonder why is that? Why not to say that all VLANIDs are = available=20 for the PBB-TE use. If what you are saying is correct (which, again, I = believe=20 you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely = separate=20 layer network, than VLANIDs are not shared between the two.

What = am I=20 missing here?

Thanks,
Igor 
 
NH=3D> Excellent question.  I have made exactly this = same=20 observation in the past.  In principle there is no reason why you = cannot=20 re-use all the codepoints of each/every field in the traffic unit = because, as=20 stated, although the traffic units look identical they do belong to = quite=20 different layer networks.  I think there are 2 reasons for=20 this:
 
-    Firstly, most IEEE folks are not familiar = with, and=20 therefore do not use, functional architecture techniques to describe = layer=20 networks.  So this issue may not be so obvious to many folks in = IEEE. =20 Further, when we have QinQ techniques these are a form of sublayering = (like we=20 find in nested LSPs in MPLS) and so we don't have distinct layer = networks=20 here......and although folks may not describe it as such they do = recognise that=20 one of the consequences of this (ie still a single layer network) is = that it=20 affects scaling.  However, once we have the .1ah stuff and MACinMAC = (ie=20 true client/server) then everyone intuitively recognises we have quite = disjoint=20 layer networks.  So what I am saying here is that for folks who = don't have=20 a strong background in functional architecture, the observation you have = made=20 may not be so obvious even though it is architecturally=20 true.
 
-    Secondly, there could be = practical/implementation=20 reasons for doing this (ie creating a split in VID codepoints) when = dealing with=20 COTS Ethernet hardware.  Maybe some of the Ethernet hardware = experts can=20 provide further clarification here. 
 
One thing this does provide however is a clear way to 'know' = when looking=20 at a traffic unit in isolation exactly which layer network it belongs=20 to.
 
regards, Neil
------_=_NextPart_001_01C89A16.66948A36-- From owner-ccamp@ops.ietf.org Wed Apr 9 07:58:14 2008 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 373643A6B74 for ; Wed, 9 Apr 2008 07:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 NwWj7O4o0jGr for ; Wed, 9 Apr 2008 07:58:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 223EF3A6ACC for ; Wed, 9 Apr 2008 07:58:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jjbbl-0008w0-FJ for ccamp-data@psg.com; Wed, 09 Apr 2008 14:49:05 +0000 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jjbbe-0008v9-Vj for ccamp@ops.ietf.org; Wed, 09 Apr 2008 14:49:03 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m39Ebaq24798; Wed, 9 Apr 2008 14:37:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89A4F.58ECE102" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Wed, 9 Apr 2008 10:38:15 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA41471C58A@zrtphxm2.corp.nortel.com> In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C0239EC2C@E03MVB2-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciZvdU00p78wmPjQTmVUbI9h7E4/wAUo6cgAA2egTA= References: <957328.29318.qm@web36801.mail.mud.yahoo.com> <2ECAA42C79676B42AEBAC11229CA7D0C0239EC2C@E03MVB2-UKBR.domain1.systemhost.net> From: "Don Fedyk" To: , , , Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C89A4F.58ECE102 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor and Neil =20 See below, =09 IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.=20 =09 What am I missing here? =09 Thanks, Igor=20 =20 NH=3D> Excellent question. I have made exactly this same observation in the past. In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks. I think there are 2 reasons for this: =20 - Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks. So this issue may not be so obvious to many folks in IEEE. Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling. However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks. So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true. =20 - Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware. Maybe some of the Ethernet hardware experts can provide further clarification here. =20 =20 Disclaimer I'm not a hardware expert but Neil is correct there is currently no "context" within an Ethernet Frame that could separate the PBB B-VID space and the PBB-TE B-VID space. If these spaces used overlapping B-VID values there would be know way to know by looking at the Frame. In fact one of the attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA). A result is a switch cannot tell the context implicitly.=20 One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to.=20 =20 Between the PBB B-MAC (server) and the PBB C-MAC (client) it is clear looking at a frame. Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing that separates the behavior. =20 =20 Regards, Don=20 =20 regards, Neil ------_=_NextPart_001_01C89A4F.58ECE102 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi Igor and Neil
 
See below,

IB>> I agree with what you = are saying.=20 What confuses me, though, is that 802.1ay prescribes allocating of = certain=20 range(s) of VLANIDs for the PBB-TE use, while allowing use of other = VLANIDs=20 for their native Ethernet purposes. I wonder why is that? Why not to = say that=20 all VLANIDs are available for the PBB-TE use. If what you are saying = is=20 correct (which, again, I believe you are), that is, PBB-TE and = non-PBB-TE=20 (say, PBB) are completely separate layer network, than VLANIDs are not = shared=20 between the two.

What am I missing = here?

Thanks,
Igor 
 
NH=3D> Excellent question.  I have made exactly this = same=20 observation in the past.  In principle there is no reason why you = cannot=20 re-use all the codepoints of each/every field in the traffic unit = because, as=20 stated, although the traffic units look identical they do belong to = quite=20 different layer networks.  I think there are 2 reasons for=20 this:
 
-    Firstly, most IEEE folks are not familiar = with, and=20 therefore do not use, functional architecture techniques to describe = layer=20 networks.  So this issue may not be so obvious to many folks in=20 IEEE.  Further, when we have QinQ techniques these are a form of=20 sublayering (like we find in nested LSPs in MPLS) and so we don't have = distinct layer networks here......and although folks may not describe = it as=20 such they do recognise that one of the consequences of this (ie still = a single=20 layer network) is that it affects scaling.  However, once we have = the=20 .1ah stuff and MACinMAC (ie true client/server) then everyone = intuitively=20 recognises we have quite disjoint layer networks.  So what I am = saying=20 here is that for folks who don't have a strong background in = functional=20 architecture, the observation you have made may not be so obvious even = though=20 it is architecturally true.
 
-    Secondly, there = could be=20 practical/implementation reasons for doing this (ie creating a split = in VID=20 codepoints) when dealing with COTS Ethernet hardware.  Maybe some = of the=20 Ethernet hardware experts can provide further clarification=20 here.   
 
Disclaimer I'm not a hardware expert but Neil is correct = there is=20 currently no "context" within an Ethernet Frame that could separate the = PBB=20 B-VID space and the PBB-TE B-VID space. If  these spaces used = overlapping=20 B-VID values there would be know way to know by looking at the = Frame.  In=20 fact one of the attractions of PBB-TE is that it can reuse the existing=20 forwarding HW because it essentially forwards on (B-VID+MAC = DA).  A=20 result is a switch cannot tell the context implicitly.=20
One thing this does provide however is = a clear way=20 to 'know' when looking at a traffic unit in isolation exactly which = layer=20 network it belongs to. 
 
Between the PBB B-MAC (server) and the PBB C-MAC=20  (client) it is clear = looking at a=20 frame.   Between PBB and PBB-TE the B-VID space partitioning = in the=20 management (and control plane) is the only thing that separates the=20 behavior. 
 
Regards,
Don
 
regards, Neil
------_=_NextPart_001_01C89A4F.58ECE102-- From owner-ccamp@ops.ietf.org Wed Apr 9 08:38:13 2008 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 1F42428C4D8 for ; Wed, 9 Apr 2008 08:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 7xF45wHq41fc for ; Wed, 9 Apr 2008 08:38:10 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3E81828C4F0 for ; Wed, 9 Apr 2008 08:36:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjcGb-000DH8-4X for ccamp-data@psg.com; Wed, 09 Apr 2008 15:31:17 +0000 Received: from [209.191.85.59] (helo=web36808.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjcGN-000DFb-U0 for ccamp@ops.ietf.org; Wed, 09 Apr 2008 15:31:12 +0000 Received: (qmail 65487 invoked by uid 60001); 9 Apr 2008 15:31:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=MMs2AMEbvos8bkQtHLeJ/nSbtFNpme4gwtA+gtx0RTEmA/WlqAdlJ++gVqH8I9SphgSCVMRxV4whPzw2c27i7g1XIVgLameUeW0NYCzQr79dImULEtagsx5NckiBVA11tqP+4aRVnfLSN8xtHt8v1kJsxeBLnTrBIExSECMDakU=; X-YMail-OSG: Q3Q_M1oVM1nvsL7lOoylj1WyarhH78XSarMmzymZRzpnqpnkA1EAcNn7FyGip83A5Q-- Received: from [67.102.145.11] by web36808.mail.mud.yahoo.com via HTTP; Wed, 09 Apr 2008 08:31:03 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Wed, 9 Apr 2008 08:31:03 -0700 (PDT) From: Igor Bryskin Subject: Re: Continued Poll for Adoption of Ethernet I-Ds To: Don Fedyk , neil.2.harrison@bt.com, adrian@olddog.co.uk, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1949939702-1207755063=:64983" Message-ID: <285306.64983.qm@web36808.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk --0-1949939702-1207755063=:64983 Content-Type: text/plain; charset=us-ascii Hi Don, IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two. What am I missing here? Thanks, Igor NH=> Excellent question. I have made exactly this same observation in the past. In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks. I think there are 2 reasons for this: - Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks. So this issue may not be so obvious to many folks in IEEE. Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling. However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks. So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true. - Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware. Maybe some of the Ethernet hardware experts can provide further clarification here. Disclaimer I'm not a hardware expert but Neil is correct there is currently no "context" within an Ethernet Frame that could separate the PBB B-VID space and the PBB-TE B-VID space. If these spaces used overlapping B-VID values there would be know way to know by looking at the Frame. In fact one of the attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA). A result is a switch cannot tell the context implicitly. One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to. Between the PBB B-MAC (server) and the PBB C-MAC (client) it is clear looking at a frame. Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing that separates the behavior. IB>> I think you are missing the point here. When it is said that PBB-TE and PBB (or any other native Ethernet) are different layer networks it means that what happens in one layer is transparent/irrelevant for the other even when the two layers have identical LI overhead. In other words this means that one layer does not get to analyze the LI (MAC header in this case) of the other layer unless there is some kind of misconfiguration and packets from one layer are leaking into another. But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain. Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation. Cheers, Igor __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-1949939702-1207755063=:64983 Content-Type: text/html; charset=us-ascii
Hi Don,


IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.

What am I missing here?

Thanks,
Igor 
 
NH=> Excellent question.  I have made exactly this same observation in the past.  In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks.  I think there are 2 reasons for this:
 
-    Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks.  So this issue may not be so obvious to many folks in IEEE.  Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling.  However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks.  So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true.
 
-    Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware.  Maybe some of the Ethernet hardware experts can provide further clarification here.   
 
Disclaimer I'm not a hardware expert but Neil is correct there is currently no "context" within an Ethernet Frame that could separate the PBB B-VID space and the PBB-TE B-VID space. If  these spaces used overlapping B-VID values there would be know way to know by looking at the Frame.  In fact one of the attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA).  A result is a switch cannot tell the context implicitly.
One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to. 
 
Between the PBB B-MAC (server) and the PBB C-MAC  (client) it is clear looking at a frame.   Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing that separates the behavior. 
 
IB>> I think you are missing the point here. When it is said that PBB-TE and PBB (or any other native Ethernet) are different layer networks it means that what happens in one layer is transparent/irrelevant for the other  even when the two layers have identical LI overhead. In other words this means that one layer does not get to analyze the LI (MAC header in this case) of the other layer unless there is some kind of misconfiguration and packets from one layer are leaking into another. But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain. Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation.

Cheers,
Igor

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-1949939702-1207755063=:64983-- From owner-ccamp@ops.ietf.org Wed Apr 9 09:09:02 2008 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 3071D3A6D48 for ; Wed, 9 Apr 2008 09:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 HgDWQL5cHeGn for ; Wed, 9 Apr 2008 09:09:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 054C93A6D32 for ; Wed, 9 Apr 2008 09:09:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjclR-000GpJ-Gt for ccamp-data@psg.com; Wed, 09 Apr 2008 16:03:09 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjclO-000Gog-JY for ccamp@ops.ietf.org; Wed, 09 Apr 2008 16:03:08 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m39G344X008934 for ; Wed, 9 Apr 2008 17:03:04 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m39G32RK008924 for ; Wed, 9 Apr 2008 17:03:03 +0100 Message-ID: <029d01c89a5b$304133a0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "CCAMP List" References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> Subject: Last call complete on Advertisement of inter-AS TE links Date: Wed, 9 Apr 2008 16:57:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, The last call completed. Given the high level of review and discussion in the past and the relatively small size of the I-Ds, I'm not surprised that we only got a couple of comments during last call. Mach, can you make the changes to the I-D to satisfy Acee's comments on the OSPF draft, and check to see if there is any similar language in the IS-IS draft? One point... Where he suggests alternative text for "TE Router ID", I think this is fine, but it would be helpful if you retained "TE Router ID" in brackets to give the extra information. Thanks, Adrian ----- Original Message ----- From: "Acee Lindem" To: "Adrian Farrel" Cc: "OSPF List" ; "CCAMP List" Sent: Friday, April 04, 2008 3:46 PM Subject: Re: [OSPF] CCAMP last call on advertisement of inter-AS TE links >I can't speak for the OSPF WG as a whole, but I have reviewed the subject >document and am very happy to see that the suggestion to use separate >inter-AS LSA types has been incorporated. I have no further technical >comments on the document and trust that the ccamp WG has verified that >this information encoding meets the TE requirements. The usage described >in sections 2.2 and 2.3 seem reasonable to me. > > I have the following editorial comments: > > 1. Sections 3.3.2 and 3.3.2 - Both of these say "Use of the TE Router > ID is RECOMMENDED." I believe these should be respectively replaced by > "Use of the TE Router Address as specified in the Router Address TLV > [OSPF-TE] is RECOMMENDED." and "Use of the TE Router IPv6 Address as > specified in the IPv6 Router Address as specified in the IPv6 Router > Address TLV [OSPF-V3-TE] is RECOMMENDED." > 2. Section 3.2.1 states "This is because... that may operate in a > different address space;". If they are using a different address space on > the link between the ASes, then I'd expect there to be problems with BGP > as well :^) I'd suggest: > "Given that OSPF is an IGP and should only be utilized between > routers in the same routing domain, the OSPF specific Link ID and > Neighbor ID sub-TLVs are not applicable to inter-AS links.". > 3. You may want to expand some acronyms on their first use. For > example, "AS Boundary Router (ASBR)", "Link State Advertisement (LSA)" > and > "Path Computation Element (PCE)". > 4. [OSPFV3] is listed to as both a Normative and Informative reference. > > Thanks, > Acee > > On Mar 19, 2008, at 2:06 PM, Adrian Farrel wrote: > >> Hi, >> >> You may recall providing useful review and feedback on >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- >> te-extension-02.txt >> >> The authors believe that they have taken on board all the comments >> received >> from the OSPF working group and have updated the draft accordingly. >> >> >> CCAMP is holding a three week working group last call on this I-D along >> with >> its IS-IS partner document: >> >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas- >> te-extension-00.txt >> >> These documents describe how to advertise the TE links that connect an >> AS to >> the outside world within the AS's IGP. As the drafts are at pains to >> point >> out, there is no proposal to advertise the TE information more widely >> (such >> as to other ASes). >> >> The last call will end at 12 noon BST on April 9th 2008. >> >> Please send your comments to the CCAMP list or direct to the CCAMP >> chairs. >> >> Thanks, >> Adrian and Deborah >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > From owner-ccamp@ops.ietf.org Wed Apr 9 13:16:08 2008 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 78EF93A6B8E for ; Wed, 9 Apr 2008 13:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, 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 C8DsQS0gUYED for ; Wed, 9 Apr 2008 13:16:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8F91D3A6BE1 for ; Wed, 9 Apr 2008 13:15:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjgZZ-000Gjb-DF for ccamp-data@psg.com; Wed, 09 Apr 2008 20:07:09 +0000 Received: from [212.25.127.231] (helo=gfi-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjgZT-000Git-4i for ccamp@ops.ietf.org; Wed, 09 Apr 2008 20:07:06 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 23:06:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89A7D.440F47C9" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Wed, 9 Apr 2008 23:02:01 +0300 Message-ID: In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA41471C58A@zrtphxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciZvdU00p78wmPjQTmVUbI9h7E4/wAUo6cgAA2egTAADV+mQA== From: "Nurit Sprecher" To: "ext Don Fedyk" , , , , X-OriginalArrivalTime: 09 Apr 2008 20:06:58.0574 (UTC) FILETIME=[443172E0:01C89A7D] Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C89A7D.440F47C9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, So maybe this is something to be commented to the IEEE........they operate hybrid PBB/PBB-TE networks.=20 In this draft we provide a control plane to the dataplane that is defined by the IEEE, and specifically we define a control plane for PBB-TE as defined by the IEEE 802.1Qay.=20 Nurit =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Don Fedyk Sent: Wednesday, April 09, 2008 17:38 To: neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: RE: Continued Poll for Adoption of Ethernet I-Ds =20 Hi Igor and Neil =20 See below, =09 IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.=20 =09 What am I missing here? =09 Thanks, Igor=20 =20 NH=3D> Excellent question. I have made exactly this same observation in the past. In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks. I think there are 2 reasons for this: =20 - Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks. So this issue may not be so obvious to many folks in IEEE. Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling. However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks. So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true. =20 - Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware. Maybe some of the Ethernet hardware experts can provide further clarification here. =20 =20 Disclaimer I'm not a hardware expert but Neil is correct there is currently no "context" within an Ethernet Frame that could separate the PBB B-VID space and the PBB-TE B-VID space. If these spaces used overlapping B-VID values there would be know way to know by looking at the Frame. In fact one of the attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA). A result is a switch cannot tell the context implicitly.=20 One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to.=20 =20 Between the PBB B-MAC (server) and the PBB C-MAC (client) it is clear looking at a frame. Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing that separates the behavior. =20 =20 Regards, Don=20 =20 regards, Neil ------_=_NextPart_001_01C89A7D.440F47C9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi = all,

So maybe this is something to be commented to the IEEE……..they operate hybrid = PBB/PBB-TE networks.

In this draft we = provide a control plane to the dataplane that is defined by the IEEE, and = specifically we define a control plane for PBB-TE as defined by the IEEE 802.1Qay. =

Nurit<= /span>

 =

From: owner-ccamp@ops.ietf.org = [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Don Fedyk
Sent: Wednesday, April = 09, 2008 17:38
To: = neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org
Subject: RE: Continued = Poll for Adoption of Ethernet I-Ds

 

Hi Igor and = Neil

 

See = below,


IB>> I agree with what you are saying. What confuses me, though, = is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the = PBB-TE use, while allowing use of other VLANIDs for their native Ethernet = purposes. I wonder why is that? Why not to say that all VLANIDs are available for = the PBB-TE use. If what you are saying is correct (which, again, I believe = you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate = layer network, than VLANIDs are not shared between the two.

What am I missing here?

Thanks,
Igor 

 

NH=3D> Excellent question.  I have made exactly this same observation in = the past.  In principle there is no reason why you cannot re-use all = the codepoints of each/every field in the traffic unit because, as stated, = although the traffic units look identical they do belong to quite different layer networks.  I think there are 2 reasons for = this:

 

-    Firstly, most IEEE folks are not familiar with, and therefore do not = use, functional architecture techniques to describe layer networks.  So = this issue may not be so obvious to many folks in IEEE.  Further, when = we have QinQ techniques these are a form of sublayering (like we find in nested = LSPs in MPLS) and so we don't have distinct layer networks here......and = although folks may not describe it as such they do recognise that one of the = consequences of this (ie still a single layer network) is that it affects scaling.  However, once we have the .1ah stuff and MACinMAC (ie true = client/server) then everyone intuitively recognises we have quite disjoint layer = networks.  So what I am saying here is that for folks who don't have a strong = background in functional architecture, the observation you have made may not be so = obvious even though it is architecturally true.

 

-    Secondly, there could be practical/implementation reasons for doing this = (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware.  Maybe some of the Ethernet hardware experts can provide = further clarification here.   

 

Disclaimer I'm = not a hardware expert but Neil is correct there is currently no = "context" within an Ethernet Frame that could separate the PBB B-VID space and the = PBB-TE B-VID space. If  these spaces used overlapping B-VID values there = would be know way to know by looking at the Frame.  In fact one of the = attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA).  A result is a = switch cannot tell the context implicitly.

One = thing this does provide however is a clear way to 'know' when looking at a = traffic unit in isolation exactly which layer network it belongs = to. 

 

Between the PBB = B-MAC (server) and the PBB C-MAC  (client) it is = clear looking at a frame.   Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing = that separates the behavior. 

 

Regards,

Don =

 

regards, Neil

------_=_NextPart_001_01C89A7D.440F47C9-- From cabralda@xenz.com Wed Apr 9 13:21:08 2008 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 1846828C1E9; Wed, 9 Apr 2008 13:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.242 X-Spam-Level: X-Spam-Status: No, score=-11.242 tagged_above=-999 required=5 tests=[BANG_GUAR=0.939, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 70hSCDFrgt4y; Wed, 9 Apr 2008 13:21:08 -0700 (PDT) Received: from 190-49-154-218.speedy.com.ar (unknown [190.49.154.218]) by core3.amsl.com (Postfix) with SMTP id CDB6A28C211; Wed, 9 Apr 2008 13:20:56 -0700 (PDT) X-Originating-IP: 64.165.16.142 by smtp.190.49.154.218; Wed, 09 Apr 2008 16:21:23 -0500 Message-ID: From: "Kristina Charles" Reply-To: "Kristina Charles" To: call-home-bounces@ietf.org Subject: The safest and most secure Online casino in the world....... Date: Wed, 09 Apr 2008 16:21:23 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Amazing $2400 bonuses..... Amazing Customer Support...... Amazing games..... Play at the world's most prestigious online casino..... Come and get your MASSIVE $2400 BONUS NOW! Fair Gaming, Fast Payouts unrivalled customer support: GUARANTEED!!! Join the superstars and some of the world’s BIGGEST winners........ ENTER HERE http://luxgamingnetwork.com/ TO DOWNLOAD NOW! From owner-ccamp@ops.ietf.org Wed Apr 9 18:40:58 2008 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 CE70F3A6BA3 for ; Wed, 9 Apr 2008 18:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.295 X-Spam-Level: X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 isN11XR832eV for ; Wed, 9 Apr 2008 18:40:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B24D3A6807 for ; Wed, 9 Apr 2008 18:40:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjldH-000F21-RQ for ccamp-data@psg.com; Thu, 10 Apr 2008 01:31:19 +0000 Received: from [61.144.161.53] (helo=szxga01-in.huawei.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjldD-000F11-QM for ccamp@ops.ietf.org; Thu, 10 Apr 2008 01:31:18 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZ300HPE5JV9V@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Thu, 10 Apr 2008 09:31:07 +0800 (CST) Received: from M55527 ([10.111.12.186]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JZ300EGX5JUOX@szxga01-in.huawei.com> for ccamp@ops.ietf.org; Thu, 10 Apr 2008 09:31:07 +0800 (CST) Date: Thu, 10 Apr 2008 09:31:06 +0800 From: Mach Chen Subject: Re: Last call complete on Advertisement of inter-AS TE links To: Adrian Farrel Cc: CCAMP List Message-id: <200804100931061910652@huawei.com> Organization: Huawei MIME-version: 1.0 X-Mailer: Foxmail 6, 10, 201, 20 [cn] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT References: <079701c889ec$22702080$0200a8c0@your029b8cecfe> <029d01c89a5b$304133a0$0300a8c0@your029b8cecfe> Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Adrian and all, Thanks for the review and comment. I will update and resubmit the I-Ds ASAP. Best regards, Mach Chen On 2008-04-10, at 00:06:32 Adrian Farrel wrote: >Hi, > >The last call completed. Given the high level of review and discussion in >the past and the relatively small size of the I-Ds, I'm not surprised that >we only got a couple of comments during last call. > >Mach, can you make the changes to the I-D to satisfy Acee's comments on the >OSPF draft, and check to see if there is any similar language in the IS-IS >draft? One point... > >Where he suggests alternative text for "TE Router ID", I think this is fine, >but it would be helpful if you retained "TE Router ID" in brackets to give >the extra information. > >Thanks, >Adrian >----- Original Message ----- >From: "Acee Lindem" >To: "Adrian Farrel" >Cc: "OSPF List" ; "CCAMP List" >Sent: Friday, April 04, 2008 3:46 PM >Subject: Re: [OSPF] CCAMP last call on advertisement of inter-AS TE links > > >>I can't speak for the OSPF WG as a whole, but I have reviewed the subject >>document and am very happy to see that the suggestion to use separate >>inter-AS LSA types has been incorporated. I have no further technical >>comments on the document and trust that the ccamp WG has verified that >>this information encoding meets the TE requirements. The usage described >>in sections 2.2 and 2.3 seem reasonable to me. >> >> I have the following editorial comments: >> >> 1. Sections 3.3.2 and 3.3.2 - Both of these say "Use of the TE Router >> ID is RECOMMENDED." I believe these should be respectively replaced by >> "Use of the TE Router Address as specified in the Router Address TLV >> [OSPF-TE] is RECOMMENDED." and "Use of the TE Router IPv6 Address as >> specified in the IPv6 Router Address as specified in the IPv6 Router >> Address TLV [OSPF-V3-TE] is RECOMMENDED." >> 2. Section 3.2.1 states "This is because... that may operate in a >> different address space;". If they are using a different address space on >> the link between the ASes, then I'd expect there to be problems with BGP >> as well :^) I'd suggest: >> "Given that OSPF is an IGP and should only be utilized between >> routers in the same routing domain, the OSPF specific Link ID and >> Neighbor ID sub-TLVs are not applicable to inter-AS links.". >> 3. You may want to expand some acronyms on their first use. For >> example, "AS Boundary Router (ASBR)", "Link State Advertisement (LSA)" >> and >> "Path Computation Element (PCE)". >> 4. [OSPFV3] is listed to as both a Normative and Informative reference. >> >> Thanks, >> Acee >> >> On Mar 19, 2008, at 2:06 PM, Adrian Farrel wrote: >> >>> Hi, >>> >>> You may recall providing useful review and feedback on >>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- >>> te-extension-02.txt >>> >>> The authors believe that they have taken on board all the comments >>> received >>> from the OSPF working group and have updated the draft accordingly. >>> >>> >>> CCAMP is holding a three week working group last call on this I-D along >>> with >>> its IS-IS partner document: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas- >>> te-extension-00.txt >>> >>> These documents describe how to advertise the TE links that connect an >>> AS to >>> the outside world within the AS's IGP. As the drafts are at pains to >>> point >>> out, there is no proposal to advertise the TE information more widely >>> (such >>> as to other ASes). >>> >>> The last call will end at 12 noon BST on April 9th 2008. >>> >>> Please send your comments to the CCAMP list or direct to the CCAMP >>> chairs. >>> >>> Thanks, >>> Adrian and Deborah >>> >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> >> > > > From primmis@gmx.com Wed Apr 9 20:34:38 2008 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 4BB3828C252 for ; Wed, 9 Apr 2008 20:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.806 X-Spam-Level: **** X-Spam-Status: No, score=4.806 tagged_above=-999 required=5 tests=[AWL=1.882, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RAZOR2_CHECK=0.5] 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 KVYDZe8gYqbg for ; Wed, 9 Apr 2008 20:34:37 -0700 (PDT) Received: from avas-mr03.fibertel.com.ar (avas-mr03.fibertel.com.ar [24.232.0.216]) by core3.amsl.com (Postfix) with ESMTP id 054E528C19D for ; Wed, 9 Apr 2008 20:34:36 -0700 (PDT) Received: from 217-184-19-190.fibertel.com.ar ([190.19.184.217]:61763 "EHLO desktop" smtp-auth: "zoolander" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr03.fibertel.com.ar with ESMTPA id S595379AbYDJDew; Thu, 10 Apr 2008 00:34:52 -0300 Reply-To: primmis@gmx.com Message-ID: <9196b65ef16c4da26896045800171a15@gmx.com> From: "Primmis" To: "primmis" Subject: LLEVATE TU MOTO o CUATRICICLO SIN ANTICIPO PCP Date: Thu, 10 Apr 2008 00:25:53 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=SPLITOR00A_001_52679984D" X-Fib-Al-Info: Al X-Fib-Al-MRId: 8e355d84fa00e0b6be7f72e239c9937e X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: primmis@gmx.com This is a multi-part message in MIME format. ------=SPLITOR00A_001_52679984D Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable LLEVATE YA MISMO TU MOTO CON CREDITO PERSONAL! MINIMOS REQUISITOS con RECIBO DE SUELDO o MONOTRIBUTO! ENTREGA EN LOCAL EN LA ZONA DE FLORES A POCAS CUADRAS DE Av. Nazca y Av. = Avellaneda CONSULTA YA MISMO a primmis@gmx.com MOTO DE CALLE JIANSHE by YAMAHA MODELO: JS125-6BJS Motor: 1 Cilindro, 4 Tiempos Refrigerado por Aire=20 Cilindrada: 124 CC=20 Potencia: 7.1Kw(7500r/min)=20 Velocidad m=E1xima: 90 km/h=20 Encendido: C.D.I.=20 Arranque el=E9ctrico y a patada=20 Freno delantero a disco=20 Freno trasero a tambor=20 Transmisi=F3n: Embrague automatico 5 velocidades=20 Capacidad de carga: 150 kg=20 Peso neto: 138 kg=20 Colores: rojo, negro, gris=20 Opcional llantas de rayos y freno delantero de disco=20 Motor con tecnolog=EDa japonesa=20 36 cuotas de $290,99 PRIMMIS Email: primmis@gmx.com MSN: primmis@gmx.com MOTO DE CALLE JIANSHE by YAMAHA MODELO: JS125-F Motor: 1 Cilindro, 4 Tiempos Refrigerado por Aire=20 Cilindrada: 123 CC=20 Potencia: 6.5Kw(7500r/min)=20 Velocidad m=E1xima: 80 km/h=20 Encendido: C.D.I.=20 Arranque el=E9ctrico y a patada=20 Freno delantero a disco=20 Freno trasero a tambor=20 Transmisi=F3n: Automatica 4 velocidades=20 Capacidad de carga: 150 kg=20 Peso neto: 95 kg=20 Colores: rojo, gris, azul, negro=20 Motor con tecnolog=EDa japonesa=20 36 cuotas de $219,99 PRIMMIS Email: primmis@gmx.com MSN: primmis@gmx.com CUATRICICLO ZANELLA FX-50 Motor:Monocil=EDndrico 4 Tiempos Cilindrada:50cc=2E Capacidad de Tanque de Nafta: 2.5 Litros Arranque:El=E9ctrico Encendido:CDI (Inducci=F3n por Descarga Capasitiva) Bater=EDa:12v Freno Delantero: A disco en ambas ruedas, hidr=E1ulico Freno Trasero: Monodisco en eje trasero, hidr=E1ulico Suspensi=F3n Delantera: Doble amortiguador hidr=E1ulico con resorte Suspensi=F3n Trasera: Doble amortiguador hidr=E1ulico con resorte Llantas: Estampadas en chapa de Acero 36 cuotas de $219,99 PRIMMIS Email: primmis@gmx.com MSN: primmis@gmx.com =A0 ------=SPLITOR00A_001_52679984D Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable

LLEVATE YA MISMO TU MOTO CON CREDITO=20 PERSONAL!
MINIMOS REQUISITOS con RECIBO DE=20 SUELDO o MONOTRIBUTO!

ENTREGA EN LOCAL EN LA ZONA=20 DE FLORES A POCAS CUADRAS DE Av. Nazca y Av. Avellaneda =

CONSULTA YA MISMO a primmis@gmx.com =

MOTO DE CALLE JIANSHE by YAMAHA
MODELO: JS125-6BJS
Motor: 1 = Cilindro, 4=20 Tiempos Refrigerado por Aire
Cilindrada: 124 CC
Potencia:=20 7.1Kw(7500r/min)
Velocidad m=E1xima: 90 km/h
Encendido: C.D.I.=20
Arranque el=E9ctrico y a patada
Freno delantero a disco
Freno = trasero=20 a tambor
Transmisi=F3n: Embrague automatico 5 velocidades =
Capacidad de=20 carga: 150 kg
Peso neto: 138 kg
Colores: rojo, negro, gris =
Opcional=20 llantas de rayos y freno delantero de disco
Motor con tecnolog=EDa = japonesa=20
36 cuotas de=20 $290,99

PRIMMIS
Email: primmis@gmx.com
MSN: primmis@gmx.com

MOTO DE CALLE JIANSHE by YAMAHA
MODELO: JS125-F
Motor: 1 = Cilindro, 4=20 Tiempos Refrigerado por Aire
Cilindrada: 123 CC
Potencia:=20 6.5Kw(7500r/min)
Velocidad m=E1xima: 80 km/h
Encendido: C.D.I.=20
Arranque el=E9ctrico y a patada
Freno delantero a disco
Freno = trasero=20 a tambor
Transmisi=F3n: Automatica 4 velocidades
Capacidad de = carga: 150=20 kg
Peso neto: 95 kg
Colores: rojo, gris, azul, negro
Motor = con=20 tecnolog=EDa japonesa
36 cuotas de=20 $219,99

PRIMMIS
Email: primmis@gmx.com
MSN: primmis@gmx.com

CUATRICICLO ZANELLA FX-50
Motor:Monocil=EDndrico 4=20 Tiempos
Cilindrada:50cc.
Capacidad de Tanque de Nafta: 2.5=20 Litros
Arranque:El=E9ctrico
Encendido:CDI (Inducci=F3n por Descarga=20 Capasitiva)
Bater=EDa:12v
Freno Delantero: A disco en ambas ruedas,=20 hidr=E1ulico
Freno Trasero: Monodisco en eje trasero, = hidr=E1ulico
Suspensi=F3n=20 Delantera: Doble amortiguador hidr=E1ulico con resorte
Suspensi=F3n = Trasera:=20 Doble amortiguador hidr=E1ulico con resorte
Llantas: Estampadas en = chapa de=20 Acero
36 cuotas de=20 $219,99

PRIMMIS
Email: primmis@gmx.com
MSN: primmis@gmx.com


 

------=SPLITOR00A_001_52679984D-- From owner-ccamp@ops.ietf.org Thu Apr 10 00:07:43 2008 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 C5AEC3A6F0D for ; Thu, 10 Apr 2008 00:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 ZlLABQvKHq6b for ; Thu, 10 Apr 2008 00:07:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A8A628C3B8 for ; Thu, 10 Apr 2008 00:05:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjqiP-000CwU-LS for ccamp-data@psg.com; Thu, 10 Apr 2008 06:56:57 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjqiM-000Cvr-Ec for ccamp@ops.ietf.org; Thu, 10 Apr 2008 06:56:56 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 317ED21274; Thu, 10 Apr 2008 08:54:22 +0200 (CEST) X-AuditID: c1b4fb3e-ab192bb000004ec0-7d-47fdb99eab77 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 099B92126C; Thu, 10 Apr 2008 08:54:22 +0200 (CEST) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 08:54:21 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89AD7.B41BBF70" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Thu, 10 Apr 2008 08:54:21 +0200 Message-ID: <53CCFDD6E346CB43994852666C210E9102624856@esealmw116.eemea.ericsson.se> In-Reply-To: <285306.64983.qm@web36808.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciaV3+R0AYEnRkpSBSudo939mSy7QAfHkaw References: <285306.64983.qm@web36808.mail.mud.yahoo.com> From: "Attila Takacs" To: "Igor Bryskin" , "Don Fedyk" , , , X-OriginalArrivalTime: 10 Apr 2008 06:54:21.0574 (UTC) FILETIME=[B46CE260:01C89AD7] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C89AD7.B41BBF70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor, =20 But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain. =20 =20 Unfortunately, leaking from PBB to PBB-TE does not necessarily means immediate discarding of PBB frames. Due to the VLAN separation between PBB and PBB-TE, there is no clear layering here. Hence leaking can essentially mean that the VID of a bridged (PBB) frame is changed to a VID used for explicitly routed connections (PBB-TE). This does not necessarily means that the frame will be dropped. It is a valid assumption that the MAC address of the PBB frame is configured in the PBB-TE region as well and as such leakig PBB traffic will be forwarded as if it would belong to an explicitly routed connection.=20 Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation. =20 I think this is not necessary true, if one allocates the whole VLAN space to PBB-TE then there will be no bridged traffic in the network. As a consequence no leaking and no other cross effects is to be expected. =20 Best regards, Attila ------_=_NextPart_001_01C89AD7.B41BBF70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Igor,
 
But=20 how the separation of VLAN ID space would help in this case? If PBB = packets=20 are leaked into PBB-TE they will be immediately dropped because there = will be=20 no PBB-TE connections configured for such packets. If PBB-TE packets = are=20 leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway = the=20 packets will be flooded across the PBB domain.    
Unfortunately,=20 leaking from PBB to PBB-TE does not necessarily means immediate = discarding of=20 PBB frames. Due to the VLAN separation between PBB and PBB-TE, = there is no=20 clear layering here. Hence leaking can essentially mean that the VID = of a=20 bridged (PBB) frame is changed to a VID used for explicitly=20 routed connections (PBB-TE). This does not necessarily means that = the frame=20 will be dropped. It is a valid assumption that the MAC address of the = PBB frame=20 is configured in the PBB-TE region as well and as such leakig PBB = traffic will=20 be forwarded as if it would belong to an explicitly routed = connection.=20 Note=20 that what I just wrote is true regardless whether PBB-TE uses = specially=20 allocated ranges of VLANIDs or all VLANIDs. Hence there is no = architectural=20 need for the VLANID space separation.
  
I = think this is=20 not necessary true, if one allocates the whole VLAN space to PBB-TE then = there=20 will be no bridged traffic in the network. As a consequence no leaking = and no=20 other cross effects is to be expected.   Best=20 regards, Attila ------_=_NextPart_001_01C89AD7.B41BBF70-- From owner-ccamp@ops.ietf.org Thu Apr 10 00:09:23 2008 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 9ECD33A67CE for ; Thu, 10 Apr 2008 00:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 JPVpXQRWdq+6 for ; Thu, 10 Apr 2008 00:09:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CC33328C3FD for ; Thu, 10 Apr 2008 00:08:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjqgV-000Ckx-OM for ccamp-data@psg.com; Thu, 10 Apr 2008 06:54:59 +0000 Received: from [193.180.251.60] (helo=mailgw3.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjqgN-000Ck5-6X for ccamp@ops.ietf.org; Thu, 10 Apr 2008 06:54:56 +0000 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ABB0320ABA; Thu, 10 Apr 2008 08:54:48 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-d3-47fdb9b8870a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6F87020AB8; Thu, 10 Apr 2008 08:54:48 +0200 (CEST) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 08:54:48 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89AD7.C4196512" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Thu, 10 Apr 2008 08:54:47 +0200 Message-ID: <53CCFDD6E346CB43994852666C210E9102624857@esealmw116.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciZvdU00p78wmPjQTmVUbI9h7E4/wAUo6cgAA2egTAADV+mQAAWX7cw References: <34B3EAA5B3066A42914D28C5ECF5FEA41471C58A@zrtphxm2.corp.nortel.com> From: "Attila Takacs" To: "Nurit Sprecher" , "ext Don Fedyk" , , , , X-OriginalArrivalTime: 10 Apr 2008 06:54:48.0261 (UTC) FILETIME=[C454FF50:01C89AD7] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C89AD7.C4196512 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I do agree that a clear/single network operation mode is desirable in practice, however, as Nurit pointed out, IEEE 802.1Qay is more permissive in this regard.=20 However, if every VLAN is allocated for PBB-TE, which is a valid configuration in 802.1Qay, then the network will operate in a clear co-ps mode without side effects due to parallel PBB operation. =20 On the other hand, I can imagine that in some cases having a PBB bridged VLAN used, e.g.,to create connectivity for control traffic, would be desirable and I do not see a problem with this until it does not carry customer traffic. =20 I think we do not need to do anything in here; the level of permitted coexistence of PBB and PBB-TE is a network operational issue, and it does not really affect the GMPLS extensions much more than probably adding support to ensure that the VLANs configured for PBB-TE are the same throughout the network. =20 Best regards, Attila =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit Sprecher Sent: Wednesday, April 09, 2008 10:02 PM To: ext Don Fedyk; neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: RE: Continued Poll for Adoption of Ethernet I-Ds =09 =09 Hi all, So maybe this is something to be commented to the IEEE........they operate hybrid PBB/PBB-TE networks.=20 In this draft we provide a control plane to the dataplane that is defined by the IEEE, and specifically we define a control plane for PBB-TE as defined by the IEEE 802.1Qay.=20 Nurit =20 =09 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Don Fedyk Sent: Wednesday, April 09, 2008 17:38 To: neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: RE: Continued Poll for Adoption of Ethernet I-Ds =20 Hi Igor and Neil =20 See below, =09 IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.=20 =09 What am I missing here? =09 Thanks, Igor=20 =20 NH=3D> Excellent question. I have made exactly this same observation in the past. In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks. I think there are 2 reasons for this: =20 - Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks. So this issue may not be so obvious to many folks in IEEE. Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling. However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks. So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true. =20 - Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware. Maybe some of the Ethernet hardware experts can provide further clarification here. =20 =20 Disclaimer I'm not a hardware expert but Neil is correct there is currently no "context" within an Ethernet Frame that could separate the PBB B-VID space and the PBB-TE B-VID space. If these spaces used overlapping B-VID values there would be know way to know by looking at the Frame. In fact one of the attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA). A result is a switch cannot tell the context implicitly.=20 One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to.=20 =20 Between the PBB B-MAC (server) and the PBB C-MAC (client) it is clear looking at a frame. Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing that separates the behavior. =20 =20 Regards, Don=20 =20 regards, Neil ------_=_NextPart_001_01C89AD7.C4196512 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message=
Hi=20 all,
 
I do=20 agree that a clear/single network operation mode is desirable in = practice,=20 however, as Nurit pointed out, IEEE 802.1Qay is more = permissive in this regard.
However, if every VLAN is = allocated for=20 PBB-TE, which is a valid configuration in 802.1Qay, then the = network will=20 operate in a clear co-ps mode without side effects due to parallel PBB=20 operation.
 
On the other hand, I can = imagine that in=20 some cases having a PBB bridged VLAN used, e.g.,to create connectivity = for=20 control traffic, would be desirable and I do not see a problem with = this=20 until it does not carry customer=20 traffic.
 
I think we do not need to do = anything in=20 here; the level of permitted coexistence of PBB and PBB-TE is a network=20 operational issue, and it does not really affect the GMPLS extensions = much more=20 than probably adding support to ensure that the VLANs configured for = PBB-TE are=20 the same throughout the = network.
 
Best=20 regards,
Attila
 
From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit=20 Sprecher
Sent: Wednesday, April 09, 2008 10:02 = PM
To: ext=20 Don Fedyk; neil.2.harrison@bt.com; i_bryskin@yahoo.com; = adrian@olddog.co.uk;=20 ccamp@ops.ietf.org
Subject: RE: Continued Poll for Adoption = of=20 Ethernet I-Ds

Hi=20 all,

So maybe = this is=20 something to be commented to the IEEE……..they operate = hybrid PBB/PBB-TE=20 networks.

In this = draft we=20 provide a control plane to the dataplane that is defined by the IEEE, = and=20 specifically we define a control plane for PBB-TE as defined by the = IEEE=20 802.1Qay.

Nurit

 

From:=20 owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Don = Fedyk
Sent: Wednesday, April 09, 2008 = 17:38
To:=20 neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk;=20 ccamp@ops.ietf.org
Subject: RE: Continued Poll for = Adoption=20 of Ethernet I-Ds

 

Hi Igor and = Neil

 

See=20 below,


IB>> I agree with what you are = saying.=20 What confuses me, though, is that 802.1ay prescribes allocating of = certain=20 range(s) of VLANIDs for the PBB-TE use, while allowing use of other = VLANIDs=20 for their native Ethernet purposes. I wonder why is that? Why not to = say=20 that all VLANIDs are available for the PBB-TE use. If what you are = saying is=20 correct (which, again, I believe you are), that is, PBB-TE and = non-PBB-TE=20 (say, PBB) are completely separate layer network, than VLANIDs are = not=20 shared between the two.

What am I missing=20 here?

Thanks,
Igor 

 

NH=3D>=20 Excellent question.  I have made exactly this same observation = in the=20 past.  In principle there is no reason why you cannot re-use = all the=20 codepoints of each/every field in the traffic unit because, as = stated,=20 although the traffic units look identical they do belong to quite = different=20 layer networks.  I think there are 2 reasons for=20 this:

 

-   =20 Firstly, most IEEE folks are not familiar with, and therefore do not = use,=20 functional architecture techniques to describe layer networks.  = So this=20 issue may not be so obvious to many folks in IEEE.  Further, = when we=20 have QinQ techniques these are a form of sublayering (like we find = in nested=20 LSPs in MPLS) and so we don't have distinct layer networks = here......and=20 although folks may not describe it as such they do recognise that = one of the=20 consequences of this (ie still a single layer network) is that it = affects=20 scaling.  However, once we have the .1ah stuff and MACinMAC (ie = true=20 client/server) then everyone intuitively recognises we have quite = disjoint=20 layer networks.  So what I am saying here is that for folks who = don't=20 have a strong background in functional architecture, the observation = you=20 have made may not be so obvious even though it is architecturally=20 true.

 

-   =20 Secondly, there could be practical/implementation reasons for doing = this (ie=20 creating a split in VID codepoints) when dealing with COTS Ethernet=20 hardware.  Maybe some of the Ethernet hardware experts can = provide=20 further clarification here.   

 

Disclaimer = I'm not a=20 hardware expert but Neil is correct there is currently no "context" = within an=20 Ethernet Frame that could separate the PBB B-VID space and the PBB-TE = B-VID=20 space. If  these spaces used overlapping B-VID values there would = be know=20 way to know by looking at the Frame.  In fact one of the = attractions of=20 PBB-TE is that it can reuse the existing forwarding HW because it = essentially=20 forwards on (B-VID+MAC DA).  A result is a switch = cannot tell=20 the context implicitly.

One=20 thing this does provide however is a clear way to 'know' when = looking at a=20 traffic unit in isolation exactly which layer network it belongs=20 to. 

 

Between the = PBB B-MAC=20 (server) and the PBB C-MAC  (client) it = is clear=20 looking at a frame.   Between PBB and PBB-TE the B-VID space = partitioning in the management (and control plane) is the only thing = that=20 separates the behavior. 

 

Regards,

Don=20

 

regards,=20 = Neil

------_=_NextPart_001_01C89AD7.C4196512-- From owner-ccamp@ops.ietf.org Thu Apr 10 00:12:42 2008 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 CC06B3A68E5 for ; Thu, 10 Apr 2008 00:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 6-Y5ds5ZanEa for ; Thu, 10 Apr 2008 00:12:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DFFBD3A685E for ; Thu, 10 Apr 2008 00:12:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjqmY-000DNr-Nj for ccamp-data@psg.com; Thu, 10 Apr 2008 07:01:14 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjqmM-000DMk-Fc for ccamp@ops.ietf.org; Thu, 10 Apr 2008 07:01:09 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 385533A6C1A; Thu, 10 Apr 2008 00:00:02 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-isis-interas-te-extension-01.txt Message-Id: <20080410070002.385533A6C1A@core3.amsl.com> Date: Thu, 10 Apr 2008 00:00:02 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, R. Zhang Filename : draft-ietf-ccamp-isis-interas-te-extension-01.txt Pages : 19 Date : 2008-04-09 This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter- AS TE path computation. No support for flooding TE information from outside the AS is proposed or defined in this document. Conventions used in this document 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-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-isis-interas-te-extension-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-09235228.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Thu Apr 10 00:15:27 2008 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 1F9D128C3B3 for ; Thu, 10 Apr 2008 00:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 xJYtZJ-hAoKZ for ; Thu, 10 Apr 2008 00:15:26 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 026AB3A68BA for ; Thu, 10 Apr 2008 00:14:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jjqmg-000DOW-Dg for ccamp-data@psg.com; Thu, 10 Apr 2008 07:01:22 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjqmK-000DMY-JT for ccamp@ops.ietf.org; Thu, 10 Apr 2008 07:01:08 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 2FAC33A6D2A; Thu, 10 Apr 2008 00:00:02 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-03.txt Message-Id: <20080410070002.2FAC33A6D2A@core3.amsl.com> Date: Thu, 10 Apr 2008 00:00:02 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, R. Zhang Filename : draft-ietf-ccamp-ospf-interas-te-extension-03.txt Pages : 18 Date : 2008-04-09 This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links which can be used to perform inter-AS TE path computation. No support for flooding TE information from outside the AS is proposed or defined in this document. Conventions used in this document 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-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-ospf-interas-te-extension-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-09234919.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Thu Apr 10 01:51:47 2008 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 3E5163A68DD for ; Thu, 10 Apr 2008 01:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.545 X-Spam-Level: X-Spam-Status: No, score=-1.545 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-1, 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 YEhOE0PfXvrl for ; Thu, 10 Apr 2008 01:51:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CFC143A6888 for ; Thu, 10 Apr 2008 01:51:37 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjsOA-000MuY-Uf for ccamp-data@psg.com; Thu, 10 Apr 2008 08:44:10 +0000 Received: from [217.32.164.137] (helo=smtp1.smtp.bt.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjsNy-000Msn-Rc for ccamp@ops.ietf.org; Thu, 10 Apr 2008 08:44:06 +0000 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 09:43:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89AE7.032223C2" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Thu, 10 Apr 2008 09:43:02 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0239F1C3@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <53CCFDD6E346CB43994852666C210E9102624857@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciZvdU00p78wmPjQTmVUbI9h7E4/wAUo6cgAA2egTAADV+mQAAWX7cwAAQmeFA= From: To: , , , , , X-OriginalArrivalTime: 10 Apr 2008 08:43:57.0161 (UTC) FILETIME=[03C7D590:01C89AE7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C89AE7.032223C2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed Attila.....let's not get this out of proportion......the key thing is to understand that we are dealing with different layer networks in PBB (cl-ps) and PBB-TE (co-ps) networks and getting this right is then largely a matter of good design and implementation. If we want to throw stones at the underlying arch issue I can think of another technology close to home that provides a far richer set of problems in this respect ;-) =20 regards, Neil -----Original Message----- From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]=20 Sent: 10 April 2008 07:55 To: Nurit Sprecher; ext Don Fedyk; Harrison,N,Neil,DMF R; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Hi all, =20 I do agree that a clear/single network operation mode is desirable in practice, however, as Nurit pointed out, IEEE 802.1Qay is more permissive in this regard.=20 However, if every VLAN is allocated for PBB-TE, which is a valid configuration in 802.1Qay, then the network will operate in a clear co-ps mode without side effects due to parallel PBB operation. =20 On the other hand, I can imagine that in some cases having a PBB bridged VLAN used, e.g.,to create connectivity for control traffic, would be desirable and I do not see a problem with this until it does not carry customer traffic. =20 I think we do not need to do anything in here; the level of permitted coexistence of PBB and PBB-TE is a network operational issue, and it does not really affect the GMPLS extensions much more than probably adding support to ensure that the VLANs configured for PBB-TE are the same throughout the network. =20 Best regards, Attila =20 _____ =20 From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit Sprecher Sent: Wednesday, April 09, 2008 10:02 PM To: ext Don Fedyk; neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Hi all, So maybe this is something to be commented to the IEEE........they operate hybrid PBB/PBB-TE networks.=20 In this draft we provide a control plane to the dataplane that is defined by the IEEE, and specifically we define a control plane for PBB-TE as defined by the IEEE 802.1Qay.=20 Nurit =20 _____ =20 From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Don Fedyk Sent: Wednesday, April 09, 2008 17:38 To: neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: RE: Continued Poll for Adoption of Ethernet I-Ds =20 Hi Igor and Neil =20 See below, IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.=20 What am I missing here? Thanks, Igor=20 =20 NH=3D> Excellent question. I have made exactly this same observation in the past. In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks. I think there are 2 reasons for this: =20 - Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks. So this issue may not be so obvious to many folks in IEEE. Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling. However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks. So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true. =20 - Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware. Maybe some of the Ethernet hardware experts can provide further clarification here. =20 =20 Disclaimer I'm not a hardware expert but Neil is correct there is currently no "context" within an Ethernet Frame that could separate the PBB B-VID space and the PBB-TE B-VID space. If these spaces used overlapping B-VID values there would be know way to know by looking at the Frame. In fact one of the attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA). A result is a switch cannot tell the context implicitly.=20 One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to.=20 =20 Between the PBB B-MAC (server) and the PBB C-MAC (client) it is clear looking at a frame. Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing that separates the behavior. =20 =20 Regards, Don=20 =20 regards, Neil ------_=_NextPart_001_01C89AE7.032223C2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Agreed=20 Attila.....let's not get this out of proportion......the key = thing is to=20 understand that we are dealing with different layer networks in PBB = (cl-ps) and=20 PBB-TE (co-ps) networks and getting this right is then largely a matter = of good=20 design and implementation.  If we want to throw stones at the underlying arch issue I can think of = another=20 technology close to home that provides a far=20 richer set of problems in this respect=20 ;-)
 
regards, Neil
-----Original Message-----
From: = Attila Takacs=20 [mailto:Attila.Takacs@ericsson.com]
Sent: 10 April 2008=20 07:55
To: Nurit Sprecher; ext Don Fedyk; Harrison,N,Neil,DMF = R;=20 i_bryskin@yahoo.com; adrian@olddog.co.uk;=20 ccamp@ops.ietf.org
Subject: RE: Continued Poll for Adoption = of=20 Ethernet I-Ds

Hi=20 all,
 
I do=20 agree that a clear/single network operation mode is desirable in = practice,=20 however, as Nurit pointed out, IEEE 802.1Qay is more = permissive in this regard.
However, if every VLAN is = allocated for=20 PBB-TE, which is a valid configuration in 802.1Qay, then the = network will=20 operate in a clear co-ps mode without side effects due to parallel PBB = operation.
 
On the other hand, I can = imagine that in=20 some cases having a PBB bridged VLAN used, e.g.,to create connectivity = for=20 control traffic, would be desirable and I do not see a = problem with this=20 until it does not carry customer=20 traffic.
 
I think we do not need to do = anything in=20 here; the level of permitted coexistence of PBB and PBB-TE is a = network=20 operational issue, and it does not really affect the GMPLS extensions = much=20 more than probably adding support to ensure that the VLANs configured = for=20 PBB-TE are the same throughout the=20 network.
 
Best=20 regards,
Attila
 
From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit=20 Sprecher
Sent: Wednesday, April 09, 2008 10:02 = PM
To:=20 ext Don Fedyk; neil.2.harrison@bt.com; i_bryskin@yahoo.com;=20 adrian@olddog.co.uk; ccamp@ops.ietf.org
Subject: RE: = Continued=20 Poll for Adoption of Ethernet I-Ds

Hi=20 all,

So maybe = this is=20 something to be commented to the IEEE……..they operate = hybrid PBB/PBB-TE=20 networks.

In this = draft we=20 provide a control plane to the dataplane that is defined by the = IEEE, and=20 specifically we define a control plane for PBB-TE as defined by the = IEEE=20 802.1Qay.

Nurit

 

From:=20 owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] = On Behalf Of ext Don = Fedyk
Sent: Wednesday, April 09, = 2008=20 17:38
To:=20 neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk;=20 ccamp@ops.ietf.org
Subject: RE: Continued Poll = for=20 Adoption of Ethernet I-Ds

 

Hi Igor = and=20 Neil

 

See=20 below,


IB>> I agree with what you are = saying.=20 What confuses me, though, is that 802.1ay prescribes allocating of = certain=20 range(s) of VLANIDs for the PBB-TE use, while allowing use of = other=20 VLANIDs for their native Ethernet purposes. I wonder why is that? = Why not=20 to say that all VLANIDs are available for the PBB-TE use. If what = you are=20 saying is correct (which, again, I believe you are), that is, = PBB-TE and=20 non-PBB-TE (say, PBB) are completely separate layer network, than = VLANIDs=20 are not shared between the two.

What am I missing=20 here?

Thanks,
Igor 

 

NH=3D>=20 Excellent question.  I have made exactly this same = observation in the=20 past.  In principle there is no reason why you cannot re-use = all the=20 codepoints of each/every field in the traffic unit because, as = stated,=20 although the traffic units look identical they do belong to quite=20 different layer networks.  I think there are 2 reasons for=20 this:

 

-   =20 Firstly, most IEEE folks are not familiar with, and therefore do = not use,=20 functional architecture techniques to describe layer = networks.  So=20 this issue may not be so obvious to many folks in IEEE.  = Further,=20 when we have QinQ techniques these are a form of sublayering (like = we find=20 in nested LSPs in MPLS) and so we don't have distinct layer = networks=20 here......and although folks may not describe it as such they do = recognise=20 that one of the consequences of this (ie still a single layer = network) is=20 that it affects scaling.  However, once we have the .1ah = stuff and=20 MACinMAC (ie true client/server) then everyone intuitively = recognises we=20 have quite disjoint layer networks.  So what I am saying here = is that=20 for folks who don't have a strong background in functional = architecture,=20 the observation you have made may not be so obvious even though it = is=20 architecturally true.

 

-   =20 Secondly, there could be practical/implementation reasons for = doing this=20 (ie creating a split in VID codepoints) when dealing with COTS = Ethernet=20 hardware.  Maybe some of the Ethernet hardware experts can = provide=20 further clarification here.   

 

Disclaimer I'm not=20 a hardware expert but Neil is correct there is currently no = "context" within=20 an Ethernet Frame that could separate the PBB B-VID space and the = PBB-TE=20 B-VID space. If  these spaces used overlapping B-VID values = there would=20 be know way to know by looking at the Frame.  In fact one of = the=20 attractions of PBB-TE is that it can reuse the existing forwarding = HW=20 because it essentially forwards on (B-VID+MAC DA).  A = result=20 is a switch cannot tell the context implicitly.=20

One=20 thing this does provide however is a clear way to 'know' when = looking at a=20 traffic unit in isolation exactly which layer network it belongs=20 to. 

 

Between = the PBB=20 B-MAC (server) and the PBB C-MAC  (client) = it is=20 clear looking at a frame.   Between PBB and PBB-TE the = B-VID space=20 partitioning in the management (and control plane) is the only thing = that=20 separates the behavior. 

 

Regards,

Don=20

 

regards,=20 = Neil

------_=_NextPart_001_01C89AE7.032223C2-- From owner-ccamp@ops.ietf.org Thu Apr 10 08:23:15 2008 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 8F2C73A6B2A for ; Thu, 10 Apr 2008 08:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 9XMLg+8nREbA for ; Thu, 10 Apr 2008 08:23:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 37F5D28C503 for ; Thu, 10 Apr 2008 08:23:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjySi-0004v1-0a for ccamp-data@psg.com; Thu, 10 Apr 2008 15:13:16 +0000 Received: from [209.191.85.58] (helo=web36807.mail.mud.yahoo.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JjySb-0004uU-QS for ccamp@ops.ietf.org; Thu, 10 Apr 2008 15:13:14 +0000 Received: (qmail 47029 invoked by uid 60001); 10 Apr 2008 15:13:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=T/RTyi/GBZCETeVADDBL7DHnkspF3uBM0fKrZGpSs3zxSA3qpL3bJwpf2wg7uSTgLz8wChhlJ4SARr4fxzbcBC8VnAykOITaxHQ/g1hYXLSM4tvhafUTL30+tzN4CC7poe555oCx1EY7LpgKf19Wis3n3+Zr+0jDl7razALG6I4=; X-YMail-OSG: Vy90R7sVM1nxG036KBk56FBRnRqIirxc517x07gk19laDio4HM1iJulFtXNUSV9QAODZhLG8Qxh2.lY19EDO5wC2uPpIZClSkt0p5j02hUPx2pKeDJt2.hN5eQ-- Received: from [67.102.145.11] by web36807.mail.mud.yahoo.com via HTTP; Thu, 10 Apr 2008 08:13:09 PDT X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 Date: Thu, 10 Apr 2008 08:13:09 -0700 (PDT) From: Igor Bryskin Subject: Re: Continued Poll for Adoption of Ethernet I-Ds To: Attila Takacs , Don Fedyk , neil.2.harrison@bt.com, adrian@olddog.co.uk, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-608773676-1207840389=:46599" Message-ID: <143200.46599.qm@web36807.mail.mud.yahoo.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk --0-608773676-1207840389=:46599 Content-Type: text/plain; charset=us-ascii Hi Attila, Please, see in line. ----- Original Message ---- From: Attila Takacs To: Igor Bryskin ; Don Fedyk ; neil.2.harrison@bt.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Sent: Thursday, April 10, 2008 2:54:21 AM Subject: RE: Continued Poll for Adoption of Ethernet I-Ds DIV { MARGIN:0px;} Hi Igor, But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain. Unfortunately, leaking from PBB to PBB-TE does not necessarily means immediate discarding of PBB frames. Due to the VLAN separation between PBB and PBB-TE, there is no clear layering here. Hence leaking can essentially mean that the VID of a bridged (PBB) frame is changed to a VID used for explicitly routed connections (PBB-TE). This does not necessarily means that the frame will be dropped. It is a valid assumption that the MAC address of the PBB frame is configured in the PBB-TE region as well and as such leakig PBB traffic will be forwarded as if it would belong to an explicitly routed connection. IB>> In order for a packet, leaking from PBB to PBB_TE not be dropped, it is necessary for the triplet from PBB MAC header (SA-DA-VID) to match one of configured on the node PBB-TE connections. Even if one assumes that this is possible, it is highly unlikely to be the case on the next along the connection PBB-TE node. Hence the packet will be dropped either immediately or on the next PBB-TE node. Cheers, Igor Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation. I think this is not necessary true, if one allocates the whole VLAN space to PBB-TE then there will be no bridged traffic in the network. As a consequence no leaking and no other cross effects is to be expected. Best regards, Attila __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-608773676-1207840389=:46599 Content-Type: text/html; charset=us-ascii
Hi Attila,

Please, see in line.

----- Original Message ----
From: Attila Takacs <Attila.Takacs@ericsson.com>
To: Igor Bryskin <i_bryskin@yahoo.com>; Don Fedyk <dwfedyk@nortel.com>; neil.2.harrison@bt.com; adrian@olddog.co.uk; ccamp@ops.ietf.org
Sent: Thursday, April 10, 2008 2:54:21 AM
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

Hi Igor,
 
But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain.  
 
Unfortunately, leaking from PBB to PBB-TE does not necessarily means immediate discarding of PBB frames. Due to the VLAN separation between PBB and PBB-TE, there is no clear layering here. Hence leaking can essentially mean that the VID of a bridged (PBB) frame is changed to a VID used for explicitly routed connections (PBB-TE). This does not necessarily means that the frame will be dropped. It is a valid assumption that the MAC address of the PBB frame is configured in the PBB-TE region as well and as such leakig PBB traffic will be forwarded as if it would belong to an explicitly routed connection.

IB>> In order for a packet, leaking from PBB to PBB_TE not be dropped, it is necessary for the triplet from PBB MAC header (SA-DA-VID) to match one of configured on the node PBB-TE connections. Even if one assumes that this is possible, it is highly unlikely to be the case on the next along the connection PBB-TE node. Hence the packet will be dropped either immediately or on the next PBB-TE node.

Cheers,
Igor
Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation.
  
I think this is not necessary true, if one allocates the whole VLAN space to PBB-TE then there will be no bridged traffic in the network. As a consequence no leaking and no other cross effects is to be expected.
 
Best regards,
Attila


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-608773676-1207840389=:46599-- From owner-ccamp@ops.ietf.org Thu Apr 10 12:51:44 2008 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 729953A6941 for ; Thu, 10 Apr 2008 12:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.039 X-Spam-Level: X-Spam-Status: No, score=-1.039 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 K07xFrFV9rt2 for ; Thu, 10 Apr 2008 12:51:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8550D3A6991 for ; Thu, 10 Apr 2008 12:51:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jk2ey-0002ph-Fe for ccamp-data@psg.com; Thu, 10 Apr 2008 19:42:12 +0000 Received: from [155.53.12.9] (helo=prattle.redback.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jk2ev-0002pH-S9 for ccamp@ops.ietf.org; Thu, 10 Apr 2008 19:42:11 +0000 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 7CD683192B; Thu, 10 Apr 2008 12:42:09 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24698-09; Thu, 10 Apr 2008 12:42:09 -0700 (PDT) Received: from [*3???n?IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id E33043192A; Thu, 10 Apr 2008 12:42:06 -0700 (PDT) In-Reply-To: <20080410070002.2FAC33A6D2A@core3.amsl.com> References: <20080410070002.2FAC33A6D2A@core3.amsl.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6CFC2583-D0A3-4A77-B048-5768FF1EF5DA@redback.com> Cc: CCAMP List , OSPF List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-03.txt Date: Thu, 10 Apr 2008 15:42:05 -0400 To: Mach Chen X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Mach, My comments have been addressed to my satisfaction. Depending on who reviews it, you may get requests to expand some more of the acronyms on first use during the Gen-ART review. Thanks, Acee On Apr 10, 2008, at 3:00 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Control and Measurement > Plane Working Group of the IETF. > > > Title : OSPF Extensions in Support of Inter-AS > Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) > Traffic Engineering > Author(s) : M. Chen, R. Zhang > Filename : draft-ietf-ccamp-ospf-interas-te-extension-03.txt > Pages : 18 > Date : 2008-04-09 > > This document describes extensions to the OSPF version 2 and 3 > protocols to support Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple > Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined > for the flooding of TE information about inter-AS links which can be > used to perform inter-AS TE path computation. > > > > > No support for flooding TE information from outside the AS is > proposed or defined in this document. > > Conventions used in this document > > 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]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- > te-extension-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. > Content-Type: text/plain > Content-ID: <2008-04-09234919.I-D@ietf.org> From owner-ccamp@ops.ietf.org Thu Apr 10 14:01:48 2008 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 815BF28C0F2 for ; Thu, 10 Apr 2008 14:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, 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 lC0YmvWv5HGT for ; Thu, 10 Apr 2008 14:01:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E6F013A6DD8 for ; Thu, 10 Apr 2008 14:01:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jk3nc-0009Ji-Ao for ccamp-data@psg.com; Thu, 10 Apr 2008 20:55:12 +0000 Received: from [212.25.127.231] (helo=gfi-gw.seabridge.co.il) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jk3nY-0009JC-V0 for ccamp@ops.ietf.org; Thu, 10 Apr 2008 20:55:10 +0000 Received: from dove.seabridge.co.il ([172.30.10.115]) by gfi-gw.seabridge.co.il with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Apr 2008 23:55:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89B4D.2792BC99" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Thu, 10 Apr 2008 23:54:44 +0300 Message-ID: In-Reply-To: <143200.46599.qm@web36807.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AcibIE66qdwgwKVYRBiqrraNeBTbMgALEZAQ From: "Nurit Sprecher" To: "ext Igor Bryskin" , "Attila Takacs" , "Don Fedyk" , , , X-OriginalArrivalTime: 10 Apr 2008 20:55:06.0205 (UTC) FILETIME=[27C4B8D0:01C89B4D] Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C89B4D.2792BC99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am not sure any more how we got into this discussion, but I am pretty much convinced that this does not relate to the GMPLS context.=20 The question was on the adoption of the draft on GMPLS for a data plane that is defined by the IEEE (802.1Qay). This is the way it is defined by the IEEE and we provide a control plane to control it. I am pretty sure that the use of the control plane for PBB-TE will ensure a consistent behavior of the PBB-TE network.=20 Personally I am in favor of making this draft an IETF one, and I hope you are all as well. Best regards, Nurit =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Igor Bryskin Sent: Thursday, April 10, 2008 18:13 To: Attila Takacs; Don Fedyk; neil.2.harrison@bt.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: Re: Continued Poll for Adoption of Ethernet I-Ds =20 Hi Attila, Please, see in line. ----- Original Message ---- From: Attila Takacs To: Igor Bryskin ; Don Fedyk ; neil.2.harrison@bt.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Sent: Thursday, April 10, 2008 2:54:21 AM Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Hi Igor, =20 But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain. =20 =20 Unfortunately, leaking from PBB to PBB-TE does not necessarily means immediate discarding of PBB frames. Due to the VLAN separation between PBB and PBB-TE, there is no clear layering here. Hence leaking can essentially mean that the VID of a bridged (PBB) frame is changed to a VID used for explicitly routed connections (PBB-TE). This does not necessarily means that the frame will be dropped. It is a valid assumption that the MAC address of the PBB frame is configured in the PBB-TE region as well and as such leakig PBB traffic will be forwarded as if it would belong to an explicitly routed connection. IB>> In order for a packet, leaking from PBB to PBB_TE not be dropped, it is necessary for the triplet from PBB MAC header (SA-DA-VID) to match one of configured on the node PBB-TE connections. Even if one assumes that this is possible, it is highly unlikely to be the case on the next along the connection PBB-TE node. Hence the packet will be dropped either immediately or on the next PBB-TE node. Cheers, Igor=20 Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation. =20 I think this is not necessary true, if one allocates the whole VLAN space to PBB-TE then there will be no bridged traffic in the network. As a consequence no leaking and no other cross effects is to be expected. =20 Best regards, Attila =20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 ------_=_NextPart_001_01C89B4D.2792BC99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I am not sure = any more how we got into this discussion, but I am pretty much convinced that = this does not relate to the GMPLS context.

The question was = on the adoption of the draft on GMPLS for a data plane that is defined by the = IEEE (802.1Qay). This is the way it is defined by the IEEE and we provide a = control plane to control it. I am pretty sure that the use of the control plane = for PBB-TE will ensure a consistent behavior of the PBB-TE network. =

Personally I am = in favor of making this draft an IETF one, and I hope you are all as = well.

Best = regards,

Nurit<= /span>

 =

From: owner-ccamp@ops.ietf.org = [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Igor Bryskin
Sent: Thursday, April 10, = 2008 18:13
To: Attila Takacs; Don = Fedyk; neil.2.harrison@bt.com; adrian@olddog.co.uk; ccamp@ops.ietf.org
Subject: Re: Continued = Poll for Adoption of Ethernet I-Ds

 

Hi Attila,

Please, see in line.

----- Original = Message ----
From: Attila Takacs <Attila.Takacs@ericsson.com>
To: Igor Bryskin <i_bryskin@yahoo.com>; Don Fedyk <dwfedyk@nortel.com>; neil.2.harrison@bt.com; adrian@olddog.co.uk; = ccamp@ops.ietf.org
Sent: Thursday, April 10, 2008 2:54:21 AM
Subject: RE: Continued Poll for Adoption of Ethernet = I-Ds

Hi = Igor,

 

=

But how the separation of VLAN ID space would = help in this case? If PBB packets are leaked into PBB-TE they will be = immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows = nothing about PBB-TE anyway the packets will be flooded across the PBB = domain.  

 

Unfortunately, = leaking from PBB to PBB-TE does not necessarily means immediate discarding of = PBB frames. Due to the VLAN separation between PBB and PBB-TE, there is = no clear layering here. Hence leaking can essentially mean that the VID = of a bridged (PBB) frame is changed to a VID used for explicitly routed connections (PBB-TE). This does not necessarily means that = the frame will be dropped. It is a valid assumption that the MAC address of = the PBB frame is configured in the PBB-TE region as well and as such leakig PBB = traffic will be forwarded as if it would belong to an explicitly routed connection.

IB>> In order for a packet, leaking from PBB to PBB_TE not be = dropped, it is necessary for the triplet from PBB MAC header (SA-DA-VID) to match = one of configured on the node PBB-TE connections. Even if one assumes that this = is possible, it is highly unlikely to be the case on the next along the = connection PBB-TE node. Hence the packet will be dropped either immediately or on = the next PBB-TE node.

Cheers,
Igor

=

Note that what I just wrote is true = regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence = there is no architectural need for the VLANID space separation.
  

I think this is = not necessary true, if one allocates the whole VLAN space to PBB-TE then = there will be no bridged traffic in the network. As a consequence no leaking and no = other cross effects is to be expected.

 

Best = regards,

Attila

 


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

------_=_NextPart_001_01C89B4D.2792BC99-- From owner-ccamp@ops.ietf.org Thu Apr 10 22:23:19 2008 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 64C5E3A6DC1 for ; Thu, 10 Apr 2008 22:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 IMg0jqF6gvr7 for ; Thu, 10 Apr 2008 22:23:18 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 844293A6DC0 for ; Thu, 10 Apr 2008 22:23:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkBcr-000F2j-Ak for ccamp-data@psg.com; Fri, 11 Apr 2008 05:16:37 +0000 Received: from [61.144.161.55] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkBco-000F1x-95 for ccamp@ops.ietf.org; Fri, 11 Apr 2008 05:16:35 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JZ500C13ANF5V@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Fri, 11 Apr 2008 13:16:27 +0800 (CST) Received: from M55527 ([10.111.12.186]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JZ5008JVANDVL@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Fri, 11 Apr 2008 13:16:27 +0800 (CST) Date: Fri, 11 Apr 2008 13:16:26 +0800 From: Mach Chen Subject: Re: Re: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-03.txt To: Acee Lindem Cc: CCAMP List , OSPF List Message-id: <200804111316248393389@huawei.com> Organization: Huawei MIME-version: 1.0 X-Mailer: Foxmail 6, 10, 201, 20 [cn] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT References: <20080410070002.2FAC33A6D2A@core3.amsl.com> <6CFC2583-D0A3-4A77-B048-5768FF1EF5DA@redback.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Acee, On 2008-04-11, at 03:42:09 Acee Lindem wrote: >Hi Mach, >My comments have been addressed to my satisfaction. Depending on who >reviews it, you may get requests to expand some more of the acronyms >on first use during the Gen-ART review. OK, I will try again. Thanks, Mach >Thanks, >Acee >On Apr 10, 2008, at 3:00 AM, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Common Control and Measurement >> Plane Working Group of the IETF. >> >> >> Title : OSPF Extensions in Support of Inter-AS >> Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) >> Traffic Engineering >> Author(s) : M. Chen, R. Zhang >> Filename : draft-ietf-ccamp-ospf-interas-te-extension-03.txt >> Pages : 18 >> Date : 2008-04-09 >> >> This document describes extensions to the OSPF version 2 and 3 >> protocols to support Multiprotocol Label Switching (MPLS) and >> Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple >> Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined >> for the flooding of TE information about inter-AS links which can be >> used to perform inter-AS TE path computation. >> >> >> >> >> No support for flooding TE information from outside the AS is >> proposed or defined in this document. >> >> Conventions used in this document >> >> 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]. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- >> te-extension-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. >> Content-Type: text/plain >> Content-ID: <2008-04-09234919.I-D@ietf.org> > From c.schmitz@garage-schmitz.lu Fri Apr 11 02:52:20 2008 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 ED0353A67FA; Fri, 11 Apr 2008 02:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -61.687 X-Spam-Level: X-Spam-Status: No, score=-61.687 tagged_above=-999 required=5 tests=[BANG_GUAR=0.939, BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FS_DOLLAR_BONUS=10.357, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 jZUn2GJ6ry3V; Fri, 11 Apr 2008 02:52:13 -0700 (PDT) Received: from 84.123.86.95.dyn.user.ono.com (84.123.86.95.dyn.user.ono.com [84.123.86.95]) by core3.amsl.com (Postfix) with SMTP id B10F428C263; Fri, 11 Apr 2008 02:52:05 -0700 (PDT) X-Originating-IP: 175.6.195.181 by smtp.189.82.188.126; Fri, 11 Apr 2008 05:51:38 -0500 Message-ID: From: "Melinda Rodriquez" Reply-To: "Melinda Rodriquez" To: call-home-bounces@ietf.org Subject: Come and get your MASSIVE $2400 BONUS NOW! Date: Fri, 11 Apr 2008 05:51:38 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Amazing $2400 bonuses..... Amazing Customer Support...... Amazing games..... Play at the world's most prestigious online casino..... Come and get your MASSIVE $2400 BONUS NOW! Fair Gaming, Fast Payouts unrivalled customer support: GUARANTEED!!! Join the superstars and some of the world’s BIGGEST winners........ ENTER HERE http://sixehahu80311.blogspot.com/ TO DOWNLOAD NOW! From owner-ccamp@ops.ietf.org Fri Apr 11 04:12:59 2008 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 D89F23A6B61 for ; Fri, 11 Apr 2008 04:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.223 X-Spam-Level: X-Spam-Status: No, score=0.223 tagged_above=-999 required=5 tests=[AWL=-1.697, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 5ePtTXR0UHuN for ; Fri, 11 Apr 2008 04:12:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EB1553A6C69 for ; Fri, 11 Apr 2008 04:12:58 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkH3m-000En3-17 for ccamp-data@psg.com; Fri, 11 Apr 2008 11:04:46 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkH3f-000Ely-4c for ccamp@ops.ietf.org; Fri, 11 Apr 2008 11:04:41 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3BB4aXj011592 for ; Fri, 11 Apr 2008 12:04:36 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3BB4Y3v011548 for ; Fri, 11 Apr 2008 12:04:35 +0100 Message-ID: <040901c89bc3$d2539480$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Conclusion on Ethernet I-Ds Date: Fri, 11 Apr 2008 12:04:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, I think we are there. Authors, please submit your I-Ds with the name changes shown below. In this first submission as WG I-Ds, please don't make any other changes except for dates, filenames, and anything needed to pass idnits (http://tools.ietf.org/tools/idnits/). Some of you have received comments during the polling process that you will want to address in subsequent revisions. draft-imajuku-ccamp-ethernet-gmpls-req-01.txt --->draft-ietf-ccamp-ethernet-gmpls-provider-reqs-00.txt draft-fedyk-gmpls-ethernet-pbb-te-02.txt --->draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt draft-berger-ccamp-gmpls-mef-uni-02.txt --->draft-ietf-ccamp-gmpls-mef-uni-00.txt draft-berger-ccamp-gmpls-ether-svcs-01.txt --->draft-ietf-ccamp-gmpls-ether-svcs-00.txt Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Apr 11 05:03:15 2008 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 D60353A6E2F for ; Fri, 11 Apr 2008 05:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 pzi8D3-Q0e5G for ; Fri, 11 Apr 2008 05:03:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 796FC3A6E82 for ; Fri, 11 Apr 2008 05:03:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkHqf-000JOl-FZ for ccamp-data@psg.com; Fri, 11 Apr 2008 11:55:17 +0000 Received: from [155.53.12.9] (helo=prattle.redback.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkHqc-000JOF-NC for ccamp@ops.ietf.org; Fri, 11 Apr 2008 11:55:16 +0000 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 69CBA56CE1; Fri, 11 Apr 2008 04:55:14 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19375-02; Fri, 11 Apr 2008 04:55:14 -0700 (PDT) Received: from [?+???n?IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 85EA756CE3; Fri, 11 Apr 2008 04:55:13 -0700 (PDT) In-Reply-To: <200804111316248393389@huawei.com> References: <20080410070002.2FAC33A6D2A@core3.amsl.com> <6CFC2583-D0A3-4A77-B048-5768FF1EF5DA@redback.com> <200804111316248393389@huawei.com> Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: CCAMP List , OSPF List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-03.txt Date: Fri, 11 Apr 2008 07:55:12 -0400 To: Mach Chen X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Mach, On Apr 11, 2008, at 1:16 AM, Mach Chen wrote: > Hi Acee, > > On 2008-04-11, at 03:42:09 Acee Lindem wrote: >> Hi Mach, >> My comments have been addressed to my satisfaction. Depending on who >> reviews it, you may get requests to expand some more of the acronyms >> on first use during the Gen-ART review. > > OK, I will try again. I'm happy with it as it is. I'd wait until the Gen-ART review since you may get additional comments. Thanks, Acee > > Thanks, > > Mach > >> Thanks, >> Acee >> On Apr 10, 2008, at 3:00 AM, Internet-Drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>> >>> >>> Title : OSPF Extensions in Support of Inter-AS >>> Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) >>> Traffic Engineering >>> Author(s) : M. Chen, R. Zhang >>> Filename : draft-ietf-ccamp-ospf-interas-te-extension-03.txt >>> Pages : 18 >>> Date : 2008-04-09 >>> >>> This document describes extensions to the OSPF version 2 and 3 >>> protocols to support Multiprotocol Label Switching (MPLS) and >>> Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple >>> Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined >>> for the flooding of TE information about inter-AS links which can be >>> used to perform inter-AS TE path computation. >>> >>> >>> >>> >>> No support for flooding TE information from outside the AS is >>> proposed or defined in this document. >>> >>> Conventions used in this document >>> >>> 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]. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- >>> te-extension-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. >>> Content-Type: text/plain >>> Content-ID: <2008-04-09234919.I-D@ietf.org> >> > > From owner-ccamp@ops.ietf.org Fri Apr 11 05:05:57 2008 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 2FED128C50E for ; Fri, 11 Apr 2008 05:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 iIKEMGjuMWBa for ; Fri, 11 Apr 2008 05:05:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 307173A6BEA for ; Fri, 11 Apr 2008 05:05:16 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkHwD-000Jv2-5u for ccamp-data@psg.com; Fri, 11 Apr 2008 12:01:01 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkHwA-000Jue-DL for ccamp@ops.ietf.org; Fri, 11 Apr 2008 12:00:59 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 5DD233A6F21; Fri, 11 Apr 2008 05:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-04.txt Message-Id: <20080411120001.5DD233A6F21@core3.amsl.com> Date: Fri, 11 Apr 2008 05:00:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, R. Zhang Filename : draft-ietf-ccamp-ospf-interas-te-extension-04.txt Pages : 18 Date : 2008-04-11 This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links which can be used to perform inter-AS TE path computation. No support for flooding TE information from outside the AS is proposed or defined in this document. Conventions used in this document 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-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-ospf-interas-te-extension-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-11044800.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Fri Apr 11 08:25:56 2008 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 75C733A6EAB for ; Fri, 11 Apr 2008 08:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.958 X-Spam-Level: X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 rUgDKFMSkPLR for ; Fri, 11 Apr 2008 08:25:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DE063A6937 for ; Fri, 11 Apr 2008 08:25:55 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkL0H-000Avl-Ai for ccamp-data@psg.com; Fri, 11 Apr 2008 15:17:25 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkL0E-000AvB-Gi for ccamp@ops.ietf.org; Fri, 11 Apr 2008 15:17:23 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3BFHH8u003333 for ; Fri, 11 Apr 2008 16:17:17 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3BFHFwq003282 for ; Fri, 11 Apr 2008 16:17:16 +0100 Message-ID: <049501c89be7$1ed42770$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Two more working group last calls Date: Fri, 11 Apr 2008 16:12:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, Sorry for the continued bombardment with reviewing activity. Here are two drafts that were discussed in Philadelphia with the intention to go to WG last call as soon as possible. draft-ietf-rfc4420-bis-02.txt This is the revision to RFC 4420 to fix the TLV encoding to be consistent with the previous RSVP-TE RFCs. The fix is to the interpretation of the Length field. Although we might not expect much in the way of review comments for this I-D, it would be very helpful if you could read the I-D, point out any typos, and send a note to say that you have read the document and believe it is ready for publication. draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt This I-D for asymmetrical bandwidth allocations on bidirectional LSPs has been moved into the WG from being an individual submission, and has been marked as "Experimental". The reasoning was: - This is clearly a draft that CCAMP needs to review, so it might as well be a CCAMP draft. - This is a "stake in the ground" for how this problem would be solved within RSVP-TE, but at this stage there are no known implementations and no-one considering implementation. Please send your reviews to the list by 12 noon GMT, April 26, 2008. Thanks, Adrian PS, I'll be notifying the MPLS mailing list of these two last calls. From owner-ccamp@ops.ietf.org Fri Apr 11 11:48:02 2008 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 18D473A6D2B for ; Fri, 11 Apr 2008 11:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 6ryHjeUUcVhA for ; Fri, 11 Apr 2008 11:48:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7A4A93A6C73 for ; Fri, 11 Apr 2008 11:48:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkOBx-00019d-EM for ccamp-data@psg.com; Fri, 11 Apr 2008 18:41:41 +0000 Received: from [63.118.34.24] (helo=ripley.ciena.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JkOBu-00019J-TN for ccamp@ops.ietf.org; Fri, 11 Apr 2008 18:41:40 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Two more working group last calls Date: Fri, 11 Apr 2008 14:41:24 -0400 Message-ID: <23F9E58A916663488B3D12D1FE1A999F0125E53A@mdmxm03.ciena.com> In-Reply-To: <049501c89be7$1ed42770$0300a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Two more working group last calls thread-index: Acib5/AjlMfuuVZuTdOp/bApnFmTxQAGqG2A References: <049501c89be7$1ed42770$0300a8c0@your029b8cecfe> From: "Ong, Lyndon" To: "Adrian Farrel" , X-OriginalArrivalTime: 11 Apr 2008 18:41:38.0674 (UTC) FILETIME=[AD523520:01C89C03] Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Adrian, I've looked over draft-ietf-rfc4420-bis-02.txt and did not notice any typos. The new Length description looks like the equivalent text in RFC 3471, which we support. It looks ready for publication. Request that other editors check to make sure that their drafts are updated to have the same interpretation of the Length field as well. Cheers, Lyndon =20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Friday, April 11, 2008 8:13 AM To: ccamp@ops.ietf.org Subject: Two more working group last calls Hi, Sorry for the continued bombardment with reviewing activity. Here are two drafts that were discussed in Philadelphia with the intention to go to WG last call as soon as possible. draft-ietf-rfc4420-bis-02.txt This is the revision to RFC 4420 to fix the TLV encoding to be consistent with the previous RSVP-TE RFCs. The fix is to the interpretation of the Length field. Although we might not expect much in the way of review comments for this I-D, it would be very helpful if you could read the I-D, point out any typos, and send a note to say that you have read the document and believe it is ready for publication. draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt This I-D for asymmetrical bandwidth allocations on bidirectional LSPs has been moved into the WG from being an individual submission, and has been marked as "Experimental". The reasoning was: - This is clearly a draft that CCAMP needs to review, so it might as well be a CCAMP draft. - This is a "stake in the ground" for how this problem would be solved within RSVP-TE, but at this stage there are no known implementations and no-one considering implementation. Please send your reviews to the list by 12 noon GMT, April 26, 2008. Thanks, Adrian PS, I'll be notifying the MPLS mailing list of these two last calls.=20 From c_ito@infotex.co.jp Fri Apr 11 15:30:31 2008 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 747FD3A6852; Fri, 11 Apr 2008 15:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.241 X-Spam-Level: X-Spam-Status: No, score=-88.241 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, 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 oScbkr3SSv2N; Fri, 11 Apr 2008 15:30:28 -0700 (PDT) Received: from client-201.240.161.96.speedy.net.pe (unknown [201.240.161.96]) by core3.amsl.com (Postfix) with SMTP id 29B3E28C16D; Fri, 11 Apr 2008 15:30:15 -0700 (PDT) X-Originating-IP: 10.122.84.200 by smtp.201.240.161.96; Fri, 11 Apr 2008 18:30:43 -0500 Message-ID: From: "Margie Amos" Reply-To: "Margie Amos" To: call-home-bounces@ietf.org Subject: Join tens of thousands of LUCKY winners today........ Date: Fri, 11 Apr 2008 18:30:43 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit It's your lucky day...... and it's your turn to win HUGE............ Enjoy our MASSIVE $2400 bonus......... Join tens of thousands of LUCKY winners today........ We promise: Fair Gaming, Amazingly fast payouts.... and the best in live customer support... Enter here http://pydinake12633.blogspot.com/ to download the world's leading online casino NOW... From caborca@laperla.com.mx Sat Apr 12 02:47:00 2008 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 2568828C1C1; Sat, 12 Apr 2008 02:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -71.646 X-Spam-Level: X-Spam-Status: No, score=-71.646 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, FS_DOLLAR_BONUS=10.357, HELO_EQ_BR=0.955, HELO_MISMATCH_BR=2.4, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_VIRTUACOMBR=1.193, 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 SKZqahnM-5Dm; Sat, 12 Apr 2008 02:46:58 -0700 (PDT) Received: from bd079458.virtua.com.br (unknown [189.7.148.88]) by core3.amsl.com (Postfix) with SMTP id E35EB28C186; Sat, 12 Apr 2008 02:46:47 -0700 (PDT) X-Originating-IP: 0.20.112.0 by smtp.189.7.148.88; Sat, 12 Apr 2008 05:47:16 -0500 Message-ID: From: "Rosemary Haskins" Reply-To: "Rosemary Haskins" To: call-home-bounces@ietf.org Subject: Come and get your MASSIVE $2400 BONUS NOW! Date: Sat, 12 Apr 2008 05:47:16 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit It's your lucky day...... and it's your turn to win HUGE............ Enjoy our MASSIVE $2400 bonus......... Join tens of thousands of LUCKY winners today........ We promise: Fair Gaming, Amazingly fast payouts.... and the best in live customer support... Enter here http://mexitoge36536.blogspot.com to download the world's leading online casino NOW... From owner-ccamp@ops.ietf.org Sun Apr 13 04:52:35 2008 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 2E65B28C181 for ; Sun, 13 Apr 2008 04:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 97RwfvI8REGd for ; Sun, 13 Apr 2008 04:52:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 124B13A67ED for ; Sun, 13 Apr 2008 04:52:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jl0eZ-000JqS-IG for ccamp-data@psg.com; Sun, 13 Apr 2008 11:45:47 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jl0eW-000Jpv-Sf for ccamp@ops.ietf.org; Sun, 13 Apr 2008 11:45:46 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 7F56F28C1EF; Sun, 13 Apr 2008 04:45:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt Message-Id: <20080413114501.7F56F28C1EF@core3.amsl.com> Date: Sun, 13 Apr 2008 04:45:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : Analysis of Inter-domain Label Switched Path (LSP) Recovery Author(s) : T. Takeda, et al. Filename : draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt Pages : 25 Date : 2008-04-13 Protection and recovery are important features of service provision in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networking is being widened from single domain scope to operate in multi-domain environments. Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering. This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. Takeda et al. Expires October 2008 [page 1] draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt March 2008 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-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-inter-domain-recovery-analysis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-13043320.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Sun Apr 13 04:59:06 2008 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 DDBF43A6A3E for ; Sun, 13 Apr 2008 04:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 xH-APhHdmg03 for ; Sun, 13 Apr 2008 04:59:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7BE733A6931 for ; Sun, 13 Apr 2008 04:59:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jl0jP-000KO6-5a for ccamp-data@psg.com; Sun, 13 Apr 2008 11:50:47 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jl0jM-000KNc-FB for ccamp@ops.ietf.org; Sun, 13 Apr 2008 11:50:45 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3DBogI0031338 for ; Sun, 13 Apr 2008 12:50:42 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3DBodsa031330 for ; Sun, 13 Apr 2008 12:50:41 +0100 Message-ID: <05a601c89d5c$97afebe0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <20080413114501.7F56F28C1EF@core3.amsl.com> Subject: Re: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt Date: Sun, 13 Apr 2008 12:50:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, Changes are all editorial. We made some re-works to make the text clearer and easier to read. Cheers, Adrian ----- Original Message ----- From: To: Cc: Sent: Sunday, April 13, 2008 12:45 PM Subject: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt >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 : Analysis of Inter-domain Label Switched Path (LSP) > Recovery > Author(s) : T. Takeda, et al. > Filename : draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt > Pages : 25 > Date : 2008-04-13 > > Protection and recovery are important features of service provision > in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) > networks. Increasingly, MPLS and GMPLS networking is being widened > from single domain scope to operate in multi-domain environments. > > Various schemes and processes have been developed to establish Label > Switched Paths (LSPs) in multi-domain environments. These are > discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol > Label Switching Traffic Engineering. > > This document analyzes the application of these techniques to > protection and recovery in multi-domain networks. The main focus for > this document is on establishing end-to-end diverse Traffic > Engineering (TE) LSPs in multi-domain networks. > > Takeda et al. > > > > > Expires October 2008 > > > > > [page 1] > > draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt > > March 2008 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-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. > -------------------------------------------------------------------------------- > _______________________________________________ > 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 > From primmis_@gmx.com Sun Apr 13 11:37:32 2008 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 F0AEC3A6AEA for ; Sun, 13 Apr 2008 11:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.123 X-Spam-Level: *** X-Spam-Status: No, score=3.123 tagged_above=-999 required=5 tests=[BAYES_60=1, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, SUBJ_ALL_CAPS=2.077, UPPERCASE_50_75=0.001] 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 ySFwbg9wqqC5 for ; Sun, 13 Apr 2008 11:37:32 -0700 (PDT) Received: from avas-mr17.fibertel.com.ar (avas-mr17.fibertel.com.ar [24.232.0.249]) by core3.amsl.com (Postfix) with ESMTP id C97853A6A67 for ; Sun, 13 Apr 2008 11:37:30 -0700 (PDT) Received: from 217-184-19-190.fibertel.com.ar ([190.19.184.217]:61315 "EHLO desktop" smtp-auth: "zoolander@fibertel.com.ar" rhost-flags-OK-FAIL-OK-FAIL) by avas-mr17.fibertel.com.ar with ESMTPA id S1479908AbYDMSh4; Sun, 13 Apr 2008 15:37:56 -0300 Organization: PRIMMIS Reply-To: primmis@gmx.com Message-ID: From: "PRIMMIS" To: "primmis" Subject: EQUIPA TU CASA EN 36 CUOTAS FIJAS EN PESOS! Date: Sun, 13 Apr 2008 15:29:40 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=SPLITOR00A_001_21181109D" X-Fib-Al-Info: Al X-Fib-Al-MRId: ba8c7418796ef5aaa3335f876bc1cba1 X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: primmis_@gmx.com This is a multi-part message in MIME format. ------=SPLITOR00A_001_21181109D Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable EQUIPA TU CASA EN 36 CUOTAS FIJA EQUIPA TU CASA EN 36 CUOTAS FIJAS EN PESOS! TODO CON CREDITO PERSONAL! MINIMOS REQUISITOS, con RECIBO DE SUELDO o MONOTRIBUTO! PRECIOS FINALES IVA INCLUIDO FACTURA A o B PROMOCION APERTURA CON TARJETAS VISA, MASTERCARD, AMERICAN EXPRESS, CABAL = O=20 TARJETA SHOPPING 6 cuotas SIN INTERES! PRIMMIS Email: primmis@gmx.com MSN: primmis@gmx.comSANYOLCD32XH4 Televisor de LCD de 32" High Definition = $4199=20 o 36 cuotas de $226SANYO LCD37XH4 Televisor de LCD de 37" High Definition = $5999=20 o 36 cuotas de $323 LG PLASMA TV con Disco Rigido 42PB2RR Plasma 42" con Disco Rigido de 80GB = Incorporado=20 $7799 o 36 cuotas de $419SANYOEX-2170 Increible Sistema 2.1 de Audio y = Video=20 de Alta Definici=F3n con reproducci=F3n DVD$1899 o 36 cuotas de $106=A0 NOBLEX TV 29" 29TC675=A0 NOBLEX $1199 o 36 cuotas de $65 PHILCO TV 21" PF21127 FTLA $860 o 36 cuotas de $47 CONSULTE EL PLAN DE CUOTAS QUE MAS LE CONVENGA PRIMMIS Email: primmis@gmx.com MSN: primmis@gmx.com=A0 ------=SPLITOR00A_001_21181109D Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable EQUIPA TU CASA EN 36 CUOTAS FIJA

EQUIPA TU CASA EN = 36=20 CUOTAS FIJAS EN PESOS!

TODO CON CREDITO=20 PERSONAL!
MINIMOS REQUISITOS, con RECIBO DE SUELDO o MONOTRIBUTO!

PRECIOS FINALES = IVA=20 INCLUIDO

FACTURA A o = B

PROMOCION APERTURA=20 CON TARJETAS VISA, MASTERCARD, AMERICAN EXPRESS, CABAL O TARJETA=20 SHOPPING 6 cuotas SIN INTERES!

PRIMMIS
Email: primmis@gmx.com
MSN: primmis@gmx.com

SANYO=20 LCD32XH4 Televisor de LCD de 32" High Definition $4199 o 36 cuotas de=20 $226

3D"LCD32XH4

SANYO LCD37XH4 Televisor de=20 LCD de 37" High Definition $5999 o 36 cuotas de $323

LG PLASMA TV con Disco=20 Rigido 42PB2RR Plasma 42" con Disco Rigido de 80GB=20 Incorporado $7799 o 36=20 cuotas de $419

SANYO=20 EX-2170 Increible Sistema 2.1 de Audio y Video de=20 Alta Definici=F3n con reproducci=F3n DVD=20 $1899 o 36 cuotas de $106

 
3D"EX-2170=20

NOBLEX TV 29" 29TC675 =20 NOBLEX $1199 o 36 cuotas de=20 $65

PHILCO TV 21" PF21127=20 FTLA $860 o 36 cuotas de=20 $47

CONSULTE EL PLAN DE CUOTAS QUE=20 MAS LE CONVENGA

PRIMMIS
Email: primmis@gmx.com
MSN: primmis@gmx.com

 
------=SPLITOR00A_001_21181109D-- From c.silva@limelighttour.cl Mon Apr 14 00:23:05 2008 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 4E2183A6C29; Mon, 14 Apr 2008 00:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -59.98 X-Spam-Level: X-Spam-Status: No, score=-59.98 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_REPLICA_ROLEX=3.157, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, 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 v2XHAOt1sC4p; Mon, 14 Apr 2008 00:23:04 -0700 (PDT) Received: from r190-134-37-39.dialup.adsl.anteldata.net.uy (r190-134-37-39.dialup.adsl.anteldata.net.uy [190.134.37.39]) by core3.amsl.com (Postfix) with SMTP id 0B04C3A6A6F; Mon, 14 Apr 2008 00:22:53 -0700 (PDT) X-Originating-IP: 244.192.0.204 by smtp.190.134.37.39; Mon, 14 Apr 2008 03:23:19 -0500 Message-ID: From: "Shirley North" Reply-To: "Shirley North" To: call-home-bounces@ietf.org Subject: One of a kind replicas Date: Mon, 14 Apr 2008 03:23:19 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit How about making your friends jealous and saving a lot of money doing it? Forget about spending thousands of dollars on a new Rolex watch! Instead, visit the newly redesigned Prestige Replicas and buy yourself a beautiful, one of a kind Rolex Datejust watch! http://giveruco30464.blogspot.com/ Of course, we're talking about replica watches, not the overpriced originals... After all, our Rolex Datejusts offer the same precise functionality and exact look than their costly counterparts, but you can buy yours for just a couple of hundred bucks. So, come aboard Prestige Replicas and take advantage of our extensive collection of replica Rolex watches, our superb customer service and our super low prices! http://giveruco30464.blogspot.com/ From owner-ccamp@ops.ietf.org Mon Apr 14 02:24:26 2008 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 61C6A28C233 for ; Mon, 14 Apr 2008 02:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 kPuik1vhFcIn for ; Mon, 14 Apr 2008 02:24:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6E52E28C26B for ; Mon, 14 Apr 2008 02:24:25 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlKne-000IuL-3L for ccamp-data@psg.com; Mon, 14 Apr 2008 09:16:30 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlKnb-000Itk-7q for ccamp@ops.ietf.org; Mon, 14 Apr 2008 09:16:28 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 7425B3A69BB; Mon, 14 Apr 2008 02:15:02 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-05.txt Message-Id: <20080414091502.7425B3A69BB@core3.amsl.com> Date: Mon, 14 Apr 2008 02:15:02 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, et al. Filename : draft-ietf-ccamp-ospf-interas-te-extension-05.txt Pages : 17 Date : 2008-04-14 This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links which can be used to perform inter-AS TE path computation. No support for flooding TE information from outside the AS is proposed or defined in this document.Conventions used in this document 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-05.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-ospf-interas-te-extension-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14021015.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Apr 14 03:28:09 2008 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 C16413A6E4A for ; Mon, 14 Apr 2008 03:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 oyZ1572RuAv8 for ; Mon, 14 Apr 2008 03:28:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0D81A3A6D98 for ; Mon, 14 Apr 2008 03:28:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlLqF-000OpM-Nd for ccamp-data@psg.com; Mon, 14 Apr 2008 10:23:15 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlLq9-000OoG-1q for ccamp@ops.ietf.org; Mon, 14 Apr 2008 10:23:11 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3EAMvAH031848; Mon, 14 Apr 2008 11:22:57 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3EAMtrF031826; Mon, 14 Apr 2008 11:22:57 +0100 Message-ID: <067501c89e19$803447a0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ross Callon" Cc: , Subject: Please publish draft-ietf-ccamp-ospf-interas-te-extension-05.txt Date: Mon, 14 Apr 2008 11:22:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Proto-write-up for draft-ietf-ccamp-ospf-interas-te-extension-05.txt Intended status : Standards Track This draft may be considered in parallel with draft-ietf-ccamp-isis- interas-te-extension-02.txt, but it is *not* required to process the I-Ds in parallel. > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Adrian Farrel is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? I-D has had a good level of discussions and review in CCAMP and in the OSPF working group. In particular, it received considerable input from OSPF experts in its early stages. Document Shepherd believes reviews to have been adequate. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. The document is sound. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Consensus is good. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? IANA section checked. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. Traffic engineering extensions to OSPFv2 and OSPFv3 have been defined and are used in support of MPLS-TE and GMPLS. The extensions provide a way of encoding the TE information for TE-enabled links within the network and flooding this information within an OSPF area. When establishing inter-AS MPLS-TE or GMPLS Label Switched Paths (LSPs) a path is computed one AS at a time. This path may be computed using conventional techniques at the first ASBR of each AS, or by using Path Computation Elements (PCEs) as specified by the PCE working group. In either case, if two ASes are connected by more than one inter-AS TE link, it is helpful for the computation point to know the capabilities of the available TE links in order to select a suitable path. This document describes extensions to OSPFv2 and OSPFv3 to flood TE information about inter-AS links. New LSAs are defined for this purpose in order to support transparent backward compatibility and to support the potential use of separate OSPF flooding instances. This document does not propose or define any mechanisms to advertise any other extra-AS TE information. This means that there is no proposal to distribute TE information from one AS within another AS. Nor is there any mechanism proposed to define or distribute "TE reachability" information. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? WG has good consensus. Three points arose during working group discussions that are worth noting. All points were resolved satisfactorily. 1. OSPFv3 Support The OSPF working group requested that this I-D consider OSPFv3 as well as the OSPFv2 extensions that it was originally limited to. In return, the OSPF working group is last calling the OSPFv3-TE extensions that are a pre-requisite. 2. OSPFv2 Separate Opaque LSA The original proposal in this I-D used extensions to the OSPFv2 opaque LSA used from flooding information about intra-domain TE links. This has been changed after requests from the OSPF working group to use a different opaque LSA enabling easier backward compatibility and more flexible transition to multi-instance OSPF in the future. 3. No Change to Scaling/Flooding Paradigm Many people within CCAMP expressed a concern that the I-D might indicate the intention to distribute TE information from one AS into another AS. This would obviously break the as-based scaling and confidentiality paradigms of IGP routing. The authors were very clear that this was not the intention and have added a specific section to cover non-objectives. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? There is a known implementation of the OSPFv2 extensions. There was also good support for the work from other vendors with the same objectives. There is no known implementation of the OSPFv3 extensions. Document review by Acee Lindem deserves special mention for its care and thoroughness. From owner-ccamp@ops.ietf.org Mon Apr 14 03:34:43 2008 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 292EC3A6BAA for ; Mon, 14 Apr 2008 03:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 wNpHoB26dNr7 for ; Mon, 14 Apr 2008 03:34:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3FB203A67CE for ; Mon, 14 Apr 2008 03:34:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlLxO-000PfS-VP for ccamp-data@psg.com; Mon, 14 Apr 2008 10:30:38 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlLxI-000Pee-JQ for ccamp@ops.ietf.org; Mon, 14 Apr 2008 10:30:34 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 2D23B3A6E34; Mon, 14 Apr 2008 03:30:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-isis-interas-te-extension-02.txt Message-Id: <20080414103001.2D23B3A6E34@core3.amsl.com> Date: Mon, 14 Apr 2008 03:30:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, et al. Filename : draft-ietf-ccamp-isis-interas-te-extension-02.txt Pages : 18 Date : 2008-04-14 This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter- AS TE path computation. No support for flooding TE information from outside the AS is proposed or defined in this document.Conventions used in this document 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-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-isis-interas-te-extension-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14032945.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Apr 14 04:06:52 2008 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 0BE103A6E69 for ; Mon, 14 Apr 2008 04:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 02wcDTcsoop4 for ; Mon, 14 Apr 2008 04:06:46 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C18FE28C2B7 for ; Mon, 14 Apr 2008 04:06:45 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlMNP-0002wy-Sd for ccamp-data@psg.com; Mon, 14 Apr 2008 10:57:31 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlMNM-0002wM-HZ for ccamp@ops.ietf.org; Mon, 14 Apr 2008 10:57:30 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3EAvIgi008254; Mon, 14 Apr 2008 11:57:18 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3EAvGPn008232; Mon, 14 Apr 2008 11:57:17 +0100 Message-ID: <069301c89e1e$4c6516c0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ross Callon" Cc: , Subject: Please publish draft-ietf-ccamp-isis-interas-te-extension-02.txt Date: Mon, 14 Apr 2008 11:57:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Proto-write-up for draft-ietf-ccamp-isis-interas-te-extension-02.txt Intended status : Standards Track This draft may be considered in parallel with draft-ietf-ccamp-ospf- interas-te-extension-05.txt, but it is *not* required to process the I-Ds in parallel. > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Adrian Farrel is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? I-D has had a good level of discussions and review in CCAMP and in the ISIS working group. In particular, it received considerable input from IS-IS experts in its early stages. Document Shepherd believes reviews to have been adequate. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. The document is sound. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Consensus is good. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? IANA section checked. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. Traffic engineering extensions to IS-IS have been defined and are used in support of MPLS-TE and GMPLS. The extensions provide a way of encoding the TE information for TE-enabled links within the network and flooding this information within an IS-IS area. When establishing inter-AS MPLS-TE or GMPLS Label Switched Paths (LSPs) a path is computed one AS at a time. This path may be computed using conventional techniques at the first ASBR of each AS, or by using Path Computation Elements (PCEs) as specified by the PCE working group. In either case, if two ASes are connected by more than one inter-AS TE link, it is helpful for the computation point to know the capabilities of the available TE links in order to select a suitable path. This document describes extensions to IS-IS to flood TE information about inter-AS links. A new IS-IS top-level TLV is defined for this purpose in order to support transparent backward compatibility and to support the potential use of separate IS-IS flooding instances. This document does not propose or define any mechanisms to advertise any other extra-AS TE information. This means that there is no proposal to distribute TE information from one AS within another AS. Nor is there any mechanism proposed to define or distribute "TE reachability" information. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? WG has good consensus. Two points arose during working group discussions that are worth noting. Both points were resolved satisfactorily. 1. Separate IS-IS Instances The original proposal in this I-D used extensions to the existing IS-IS top-level TLV used for TE information distribution. This has been changed after requests from the ISIS working group to use a different top-level TLV enabling easier backward compatibility and more flexible transition to multi-instance IS-IS in the future. 2. No Change to Scaling/Flooding Paradigm Many people within CCAMP expressed a concern that the I-D might indicate the intention to distribute TE information from one AS into another AS. This would obviously break the as-based scaling and confidentiality paradigms of IGP routing. The authors were very clear that this was not the intention and have added a specific section to cover non-objectives. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? There is a known implementation of the extensions. There was also good support for the work from other vendors with the same objectives. Document review by the IS-IS working group deserves special mention for its care and thoroughness. From owner-ccamp@ops.ietf.org Mon Apr 14 05:07:37 2008 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 012F828C2E9 for ; Mon, 14 Apr 2008 05:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 NjsfHgFsOtkI for ; Mon, 14 Apr 2008 05:07:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDABB28C2ED for ; Mon, 14 Apr 2008 05:07:35 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlNN5-0009IE-Fw for ccamp-data@psg.com; Mon, 14 Apr 2008 12:01:15 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlNMs-0009GA-9X for ccamp@ops.ietf.org; Mon, 14 Apr 2008 12:01:11 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 9DC8E28C2B6; Mon, 14 Apr 2008 05:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt Message-Id: <20080414120001.9DC8E28C2B6@core3.amsl.com> Date: Mon, 14 Apr 2008 05:00:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : Ethernet Traffic Parameters Author(s) : D. Papadimitriou, I. Property Filename : draft-ietf-ccamp-ethernet-traffic-parameters-04.txt Pages : 13 Date : 2008-04-13 This document describes the Metro Ethernet Forum (MEF) - specific Ethernet Traffic Parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-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-ethernet-traffic-parameters-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14045440.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Apr 14 10:11:14 2008 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 EC4253A6D94 for ; Mon, 14 Apr 2008 10:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 wA1VDFnyN+VV for ; Mon, 14 Apr 2008 10:11:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 07BDB3A6A87 for ; Mon, 14 Apr 2008 10:11:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlS3D-000Iiz-8z for ccamp-data@psg.com; Mon, 14 Apr 2008 17:01:03 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlS37-000IiM-7j for ccamp@ops.ietf.org; Mon, 14 Apr 2008 17:00:58 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 309853A6E3E; Mon, 14 Apr 2008 10:00:00 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lsp-dppm-01.txt Message-Id: <20080414170001.309853A6E3E@core3.amsl.com> Date: Mon, 14 Apr 2008 10:00:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in Generalized MPLS Networks Author(s) : W. Sun, G. Zhang, J. Gao, G. Xie, R. Papneja, B. Gu, X. Wei Filename : draft-ietf-ccamp-lsp-dppm-01.txt Pages : 39 Date : 2008-4-14 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for the future data transmission network. The GMPLS has been developed to control and cooperate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro area. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the dynamical LSP setup/release performance. These metrics can depict the features of the GMPLS network in LSP dynamic provisioning. They can also be used in operational networks for carriers to monitor the control plane performance in realtime. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-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-lsp-dppm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-4-14095648.I-D@ietf.org> --NextPart-- From cad-schroer.comservice@cad-schroer.com Mon Apr 14 12:11:07 2008 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 730F83A687A; Mon, 14 Apr 2008 12:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -60.474 X-Spam-Level: X-Spam-Status: No, score=-60.474 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SUB_PERFECT=0.725, TVD_RCVD_IP=1.931, 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 8RkVqS3ZfXoN; Mon, 14 Apr 2008 12:11:03 -0700 (PDT) Received: from 87-160-89-200.fibertel.com.ar (87-160-89-200.fibertel.com.ar [200.89.160.87]) by core3.amsl.com (Postfix) with SMTP id 4219328C1D4; Mon, 14 Apr 2008 12:10:17 -0700 (PDT) X-Originating-IP: 229.3.116.153 by smtp.200.89.160.87; Mon, 14 Apr 2008 15:10:45 -0500 Message-ID: From: "Jewel Erickson" Reply-To: "Jewel Erickson" To: call-home-bounces@ietf.org Subject: Replica watch is a perfect gift Date: Mon, 14 Apr 2008 15:10:45 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer! With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica! http://mokufafa51381.blogspot.com/ No virus found in this outgoing message Checked by PC Tools AntiVirus (4.0.0.26 - 10.068.007). http://www.pctools.com/free-antivirus/ From owner-ccamp@ops.ietf.org Mon Apr 14 12:11:24 2008 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 24FFD3A6A95 for ; Mon, 14 Apr 2008 12:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 Tgnal7qGNLN0 for ; Mon, 14 Apr 2008 12:11:16 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1772A3A6C35 for ; Mon, 14 Apr 2008 12:11:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlTvU-0009iG-BM for ccamp-data@psg.com; Mon, 14 Apr 2008 19:01:12 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlTvN-0009hX-GM for ccamp@ops.ietf.org; Mon, 14 Apr 2008 19:01:06 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id E2DB328C1CE; Mon, 14 Apr 2008 12:00:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt Message-Id: <20080414190001.E2DB328C1CE@core3.amsl.com> Date: Mon, 14 Apr 2008 12:00:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : GMPLS control of Ethernet Author(s) : D. Fedyk, D. Allan, H. Shah, N. Bitar, A. Takacs Filename : draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt Pages : 27 Date : 2008-4-14 This memo is complementary to [ARCH] and describes how a GMPLS control plane may be applied to the Provider Backbone Bridges Traffic Engineering (PBB-TE) [IEEE 802.1Qay] amendment to 802.1Q and how GMPLS can be used to configure VLAN-aware Ethernet switches in order to establish Ethernet point to point (P2P) and P2MP MAC switched paths and P2P/P2MP VID based trees. This document supports, but does not modify, the standard IEEE data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-pbb-te-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-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-4-14114629.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Apr 14 15:38:07 2008 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 1C6173A6A4C for ; Mon, 14 Apr 2008 15:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 vfhGel13i2vC for ; Mon, 14 Apr 2008 15:38:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C0283A6A51 for ; Mon, 14 Apr 2008 15:38:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlXCp-0008CL-QE for ccamp-data@psg.com; Mon, 14 Apr 2008 22:31:19 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlXCe-00088f-Rn for ccamp@ops.ietf.org; Mon, 14 Apr 2008 22:31:10 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id B0D7428C1DB; Mon, 14 Apr 2008 15:30:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-mef-uni-00.txt Message-Id: <20080414223001.B0D7428C1DB@core3.amsl.com> Date: Mon, 14 Apr 2008 15:30:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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, et al. Filename : draft-ietf-ccamp-gmpls-mef-uni-00.txt Pages : 11 Date : 2008-04-14 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 to 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. 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-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-ietf-ccamp-gmpls-mef-uni-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14151708.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Apr 14 15:41:04 2008 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 3D91F3A6F18 for ; Mon, 14 Apr 2008 15:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 KR7g2jZDNpIR for ; Mon, 14 Apr 2008 15:41:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D55BC3A6A51 for ; Mon, 14 Apr 2008 15:40:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlXCh-00088y-L4 for ccamp-data@psg.com; Mon, 14 Apr 2008 22:31:11 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlXCe-00088e-Rn for ccamp@ops.ietf.org; Mon, 14 Apr 2008 22:31:10 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id A81EF28C1C9; Mon, 14 Apr 2008 15:30:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-00.txt Message-Id: <20080414223001.A81EF28C1C9@core3.amsl.com> Date: Mon, 14 Apr 2008 15:30:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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, et al. Filename : draft-ietf-ccamp-gmpls-ether-svcs-00.txt Pages : 22 Date : 2008-04-14 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 required to 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 service and Ethernet virtual private line service. Support for MEF and ITU defined parameters are also covered. Some of the extensions defined in this document are generic in nature and not specific to Ethernet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-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-ietf-ccamp-gmpls-ether-svcs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14151706.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Mon Apr 14 18:48:59 2008 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 C4F5A3A6DF8 for ; Mon, 14 Apr 2008 18:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 OiCQsHST40aq for ; Mon, 14 Apr 2008 18:48:55 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B959E3A6B55 for ; Mon, 14 Apr 2008 18:48:54 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlaBZ-000PtP-MS for ccamp-data@psg.com; Tue, 15 Apr 2008 01:42:13 +0000 Received: from [202.112.26.52] (helo=mx2.sjtu.edu.cn) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JlaBV-000Prr-T9 for ccamp@ops.ietf.org; Tue, 15 Apr 2008 01:42:12 +0000 Received: from localhost (localhost [127.0.0.1]) by mx2.sjtu.edu.cn (Postfix) with ESMTP id E35412BF76; Tue, 15 Apr 2008 09:41:55 +0800 (CST) X-Virus-Scanned: Debian amavisd-new at sjtu.edu.cn Received: from mx2.sjtu.edu.cn ([127.0.0.1]) by localhost (mx2.sjtu.edu.cn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mLG1gcqs9qz; Tue, 15 Apr 2008 09:41:55 +0800 (CST) Received: from msc07ad750c26b (unknown [202.120.39.240]) (Authenticated sender: sunwq) by mx2.sjtu.edu.cn (Postfix) with ESMTP id F1DB32BECD; Tue, 15 Apr 2008 09:41:54 +0800 (CST) Reply-To: From: "Weiqiang Sun" To: "'Adrian Farrel'" Cc: References: <20080414170001.309853A6E3E@core3.amsl.com> In-Reply-To: <20080414170001.309853A6E3E@core3.amsl.com> Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-dppm-01.txt Date: Tue, 15 Apr 2008 09:41:42 +0800 Organization: Shanghai Jiao Tong University Message-ID: <001801c89e99$db3f6910$91be3b30$@edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcieU6uwKbe5AGKbRtiqiQDlFJ4BngARaUBA Content-Language: zh-cn Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Adrian and all, We have fixed the editorial issues pointed out by Adrian. Further comments will be highly appreciated. Cheers, Weiqiang -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, April 15, 2008 1:00 AM To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lsp-dppm-01.txt 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 : Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in Generalized MPLS Networks Author(s) : W. Sun, G. Zhang, J. Gao, G. Xie, R. Papneja, B. Gu, X. Wei Filename : draft-ietf-ccamp-lsp-dppm-01.txt Pages : 39 Date : 2008-4-14 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for the future data transmission network. The GMPLS has been developed to control and cooperate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro area. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the dynamical LSP setup/release performance. These metrics can depict the features of the GMPLS network in LSP dynamic provisioning. They can also be used in operational networks for carriers to monitor the control plane performance in realtime. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-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. From ca@mccaldas.com Wed Apr 16 08:34:07 2008 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 9FB5E3A6ED6; Wed, 16 Apr 2008 08:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -53.337 X-Spam-Level: X-Spam-Status: No, score=-53.337 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, 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 eHm3xwEyQaGw; Wed, 16 Apr 2008 08:34:06 -0700 (PDT) Received: from 201-255-163-230.mrse.com.ar (unknown [201.255.163.230]) by core3.amsl.com (Postfix) with SMTP id 2257128C23A; Wed, 16 Apr 2008 08:33:55 -0700 (PDT) X-Originating-IP: 220.103.232.46 by smtp.201.255.163.230; Wed, 16 Apr 2008 11:34:24 -0500 Message-ID: From: "Agnes Muniz" Reply-To: "Agnes Muniz" To: call-home-bounces@ietf.org Subject: Save 80% on Brand name replica watches Date: Wed, 16 Apr 2008 11:34:24 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer! With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica! http://kizevola61100.blogspot.com/ From owner-ccamp@ops.ietf.org Wed Apr 16 15:37:15 2008 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 A3FF03A6994 for ; Wed, 16 Apr 2008 15:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 dPQiH5ZI8QQD for ; Wed, 16 Apr 2008 15:37:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BB9AB3A6AAE for ; Wed, 16 Apr 2008 15:37:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmG9y-0000yR-Ji for ccamp-data@psg.com; Wed, 16 Apr 2008 22:31:22 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmG9v-0000xv-Ta for ccamp@ops.ietf.org; Wed, 16 Apr 2008 22:31:21 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 668D528C3E3; Wed, 16 Apr 2008 15:30:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt Message-Id: <20080416223001.668D528C3E3@core3.amsl.com> Date: Wed, 16 Apr 2008 15:30:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : Analysis of Inter-domain Label Switched Path (LSP) Recovery Author(s) : T. Takeda, et al. Filename : draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt Pages : 25 Date : 2008-04-16 Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments. Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering. This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. Takeda et al. Expires October 2008 [page 1] draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt April 2008 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-05.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-inter-domain-recovery-analysis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-16151923.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Wed Apr 16 15:37:44 2008 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 D9D813A6AAE for ; Wed, 16 Apr 2008 15:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.13 X-Spam-Level: ** X-Spam-Status: No, score=2.13 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1, SUBJ_ALL_CAPS=2.077] 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 WsItJtW6EDMs for ; Wed, 16 Apr 2008 15:37:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6F9E83A696C for ; Wed, 16 Apr 2008 15:37:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmG93-0000sV-La for ccamp-data@psg.com; Wed, 16 Apr 2008 22:30:25 +0000 Received: from [129.60.39.148] (helo=tama500.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmG90-0000s4-Jm for ccamp@ops.ietf.org; Wed, 16 Apr 2008 22:30:24 +0000 Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m3GMUL98021430 for ; Thu, 17 Apr 2008 07:30:21 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 119EF6BBF for ; Thu, 17 Apr 2008 07:30:21 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id DEA576B9E for ; Thu, 17 Apr 2008 07:30:20 +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 m3GMUKpX008263 for ; Thu, 17 Apr 2008 07:30:20 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m3GMUK0X008260 for ; Thu, 17 Apr 2008 07:30:20 +0900 (JST) Received: from [127.0.0.1] (neba-hp-shiomoto.nslab.ecl.ntt.co.jp [129.60.80.23]) by imc.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m3GMUA0o029992 for ; Thu, 17 Apr 2008 07:30:20 +0900 (JST) Message-ID: <48067D98.2080602@lab.ntt.co.jp> Date: Thu, 17 Apr 2008 07:28:40 +0900 From: Kohei Shiomoto User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Ccamp (E-mail)" Subject: MPLS2008 - CALL FOR PRESENTATIONS Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk MPLS 2008 INTERNATIONAL CONFERENCE http://www.mpls2008.com OCTOBER 19-22, 2008, WASHINGTON, DC For detailed CFP visit: http://www.isocore.com/mpls2008/call_for_papers/cfp.htm On line Submissions: http://www.isocore.com/mpls2008/call_for_papers/submissions.htm Deadline for submission of presentation proposals: May 2, 2008 CALL FOR PRESENTATION =========================== MPLS 2008 International Conference (http://www.mpls2008.com), the 11th Annual International Conference on MPLS and Related Technologies, will be held October 19 - 22, 2008, in Washington, DC. The Program Committee of MPLS2008 is soliciting presentation proposals for the conference. The committee seeks original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations addressing new technologies and operational experience are solicited from network equipment vendors, service providers, the research community, government agencies, and enterprise users. The deadline for submission of presentation proposals has been extended to May 2, 2008. Submissions in the form of extended summaries (200-500 words) are solicited. In your summary, please state succinctly what the original contribution of your presentation is. Please submit the proposals to the Submissions page: http://www.isocore.com/mpls2008/call_for_papers/submissions.htm This year's conference will include, but will not be limited to the following topics: MPLS Transport Profiles MPLS in multi-area and multi-AS networks Carrier/Metro Ethernet services Wireless and Mobility Backhauling Ethernet Operations, Administration, and Maintenance Multicast Enterprise / Next Generation MVPN Point-to-multipoint MPLS and applications Multicast in MPLS Pseudowires and VPLS Single and Multi-hop Pseudowire placement, setup, and management Providing QoS in MPLS networks OAM and network management for MPLS networks Voice over IP/MPLS IMS and IPTV over MPLS Triple-play applications on MPLS MPLS-enabled Advanced services and converged networks Interworking and migration for MPLS and GMPLS Multi-layer networks and integration with non-packet technologies Deploying, interworking, and operating L2 and L3 MPLS VPNs MPLS deployment experience: scaling, performance, and security Testing: MPLS test tools and certification experience Protection, restoration, and reliability for MPLS and Psuedowires Network processors for MPLS and GMPLS MPLS/GMPLS control plane resilience, scaling and robustness MPLS TE applications of the Path Computation Element (PCE) MPLS applications in the access network MPLS and IPv6 MPLS in the Enterprise Arena MPLS Support for Ethernet Services and VPLS GMPLS Applications (L1 VPNs, ASON, Optical Internetworking, NNI/UNI) Fast IP Routing Convergence versus MPLS Loop free networking High Availability (Graceful Restart, Non-Stop Routing, In-Service Software Upgrades, etc) MPLS in the Mobile Trunking Space MPLS Applications for Mobile Access Optimization MPLS Experience in Government Networks MPLS Experience in Research Networks Security features for MPLS and Pseudowires Congestion Notification and processing for MPLS and Pseudowires (G)MPLS interaction with routing protocols From c.lenaerts@waypointdesign.be Wed Apr 16 18:36:47 2008 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 3C8023A694C; Wed, 16 Apr 2008 18:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -53.451 X-Spam-Level: X-Spam-Status: No, score=-53.451 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, 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 eqv7CI+J1ZQr; Wed, 16 Apr 2008 18:36:46 -0700 (PDT) Received: from 189-18-147-60.dsl.telesp.net.br (189-18-147-60.dsl.telesp.net.br [189.18.147.60]) by core3.amsl.com (Postfix) with SMTP id 58D2A3A685D; Wed, 16 Apr 2008 18:36:31 -0700 (PDT) X-Originating-IP: 184.64.179.159 by smtp.189.18.147.60; Wed, 16 Apr 2008 21:37:00 -0500 Message-ID: From: "Renee Tuttle" Reply-To: "Renee Tuttle" To: call-home-bounces@ietf.org Subject: Save 80% on Brand name replica watches Date: Wed, 16 Apr 2008 21:37:00 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://fyluceho68310.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://fyluceho68310.blogspot.com/ From owner-ccamp@ops.ietf.org Thu Apr 17 02:17:45 2008 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 934EE3A6FDA for ; Thu, 17 Apr 2008 02:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 OvuC7sJiY-ga for ; Thu, 17 Apr 2008 02:17:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E7983A6FD8 for ; Thu, 17 Apr 2008 02:17:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmQ9o-000Lj1-TV for ccamp-data@psg.com; Thu, 17 Apr 2008 09:11:52 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmQ9i-000Lhm-Mk for ccamp@ops.ietf.org; Thu, 17 Apr 2008 09:11:48 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3H9Bgd3031659 for ; Thu, 17 Apr 2008 10:11:43 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3H9BeIB031640 for ; Thu, 17 Apr 2008 10:11:42 +0100 Message-ID: <0a7a01c8a06b$0b4c6540$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <20080416223001.668D528C3E3@core3.amsl.com> Subject: Re: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt Date: Thu, 17 Apr 2008 10:01:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk More editorial nits thanks to Deborah. Adrian ----- Original Message ----- From: To: Cc: Sent: Wednesday, April 16, 2008 11:30 PM Subject: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt >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 : Analysis of Inter-domain Label Switched Path (LSP) > Recovery > Author(s) : T. Takeda, et al. > Filename : draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt > Pages : 25 > Date : 2008-04-16 > > Protection and recovery are important features of service offerings > in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) > networks. Increasingly, MPLS and GMPLS networks are being extended > from single domain scope to multi-domain environments. > > Various schemes and processes have been developed to establish Label > Switched Paths (LSPs) in multi-domain environments. These are > discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol > Label Switching Traffic Engineering. > > This document analyzes the application of these techniques to > protection and recovery in multi-domain networks. The main focus for > this document is on establishing end-to-end diverse Traffic > Engineering (TE) LSPs in multi-domain networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt From owner-ccamp@ops.ietf.org Thu Apr 17 08:33:46 2008 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 488A03A695F for ; Thu, 17 Apr 2008 08:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.93 X-Spam-Level: X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 7d6L2iL+kJFi for ; Thu, 17 Apr 2008 08:33:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9ACCE28C577 for ; Thu, 17 Apr 2008 08:33:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmVxu-000PTZ-Ko for ccamp-data@psg.com; Thu, 17 Apr 2008 15:23:58 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmVxn-000PRj-Cv for ccamp@ops.ietf.org; Thu, 17 Apr 2008 15:23:53 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3HFNjkw004590 for ; Thu, 17 Apr 2008 16:23:47 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3HFNbb7004441 for ; Thu, 17 Apr 2008 16:23:44 +0100 Message-ID: <0b5b01c8a09f$0146a3b0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft communication to the MEF Date: Thu, 17 Apr 2008 16:14:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, Deborah and I took an action to send a communication to the MEF about our work with Ethernet to address their UNI and Service requirements. Now that we have WG drafts on the topics, we have prepared the attached. Please let me know if you have any comments. Thanks, Deborah and Adrian === Communication to the MEF from the IETF's CCAMP Working Group The IETF's CCAMP working group would like to inform the MEF of work it is carrying out to apply GMPLS protocols to the requirements of the Ethernet UNI and Ethernet service spectrum defined by the MEF. GMPLS is a family of IP-based protocols developed within the IETF and applicable to a range of technologies from packet switched networks (such as MPLS), through layer 2 networks (such as ATM, Frame Relay, and Ethernet), to optical networks (like TDM and WDM). We would like to draw your intention to the following Internet-Drafts that we are working on. We would welcome any feedback from your members on the requirements, details of the solutions proposed, or applicability of our work. "Ethernet Traffic Parameters" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-04.txt "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-00.txt "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-00.txt "GMPLS Ethernet Label Switching Architecture and Framework" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-01.txt Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs From c.riboldi@coeldist.it Thu Apr 17 09:53:52 2008 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 7B87728C577; Thu, 17 Apr 2008 09:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -52.447 X-Spam-Level: X-Spam-Status: No, score=-52.447 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_BAYES_5x7=0.6, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, 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 fHVZpasPE1Hg; Thu, 17 Apr 2008 09:53:51 -0700 (PDT) Received: from cpe-24-92-127-93.elp.res.rr.com (cpe-24-92-127-93.elp.res.rr.com [24.92.127.93]) by core3.amsl.com (Postfix) with SMTP id E574828C555; Thu, 17 Apr 2008 09:53:47 -0700 (PDT) X-Originating-IP: 60.115.55.223 by smtp.24.92.127.93; Thu, 17 Apr 2008 12:54:17 -0500 Message-ID: From: "Annmarie Williams" Reply-To: "Annmarie Williams" To: call-home-bounces@ietf.org Subject: Save 80% on Brand name replica watches Date: Thu, 17 Apr 2008 12:54:17 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is a one of a kind store: the online place where you can find the highest quality replica watches at the best prices in the world! Forget about flying to China to get a mockup Cartier watch... You can now get European quality Cartier replicas at deeply discounted prices at Prestige Replicas! The best part is that our watches are so finely crafted that even the most experienced connoisseur would have a hard time telling our watches from the real deal. http://sotalucu61508.blogspot.com/ Visit Prestige Replicas today and discover a wide range of top quality Cartier replica watches offered at unbelievable prices, with a 15% discount when you buy two! http://sotalucu61508.blogspot.com/ From owner-ccamp@ops.ietf.org Thu Apr 17 11:18:44 2008 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 E748B3A6D55 for ; Thu, 17 Apr 2008 11:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.08 X-Spam-Level: X-Spam-Status: No, score=-1.08 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 an3Ty97Twj3z for ; Thu, 17 Apr 2008 11:18:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 212B13A6C64 for ; Thu, 17 Apr 2008 11:18:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmYbs-0007U4-Kf for ccamp-data@psg.com; Thu, 17 Apr 2008 18:13:24 +0000 Received: from [155.53.12.9] (helo=prattle.redback.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmYbp-0007TG-Q8 for ccamp@ops.ietf.org; Thu, 17 Apr 2008 18:13:23 +0000 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 7CE506AE1E0; Thu, 17 Apr 2008 11:13:21 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10064-04; Thu, 17 Apr 2008 11:13:21 -0700 (PDT) Received: from [5&???g??p??`???$IPv6???1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 606026AE1DE; Thu, 17 Apr 2008 11:13:20 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <55FAFC06-9634-46AD-AD78-E0CF6CF2A6B8@redback.com> Cc: OSPF List , Alan Davey , Vishwas Manral , David Ward , Ross Callon , CCAMP List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: OSPF WG Last Call for Traffic Engineering Extensions to OSPF version 3 - draft-ietf-ospf-ospfv3-traffic-10.txt Date: Thu, 17 Apr 2008 14:13:19 -0400 To: Acee Lindem X-Mailer: Apple Mail (2.753) X-Virus-Scanned: by amavisd-new at redback.com Sender: owner-ccamp@ops.ietf.org Precedence: bulk The WG last call has completed and I've posted a new version incorporating Adrian's comments. We'll move on to AD review with this draft. Thanks, Acee On Mar 31, 2008, at 1:36 PM, Acee Lindem wrote: > We've WG last called this draft in the past and we're going to do > it again now. After some deliberations we've made the decision to > go forward with this document with the two existing implementations > and forgo the request for interoperability testing. The WG last > call will be begin today and end April 15, 2008 at 12:00 AM EDT. > Thanks, > Acee From owner-ccamp@ops.ietf.org Thu Apr 17 14:29:14 2008 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 5E6CC3A6924 for ; Thu, 17 Apr 2008 14:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.404 X-Spam-Level: **** X-Spam-Status: No, score=4.404 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MANGLED_LIST=2.3, 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 CPBZltxjgm1e for ; Thu, 17 Apr 2008 14:29:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7DF973A691D for ; Thu, 17 Apr 2008 14:29:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmbaL-00095a-UA for ccamp-data@psg.com; Thu, 17 Apr 2008 21:24:01 +0000 Received: from [216.104.42.195] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmbaH-00094H-5v for ccamp@ops.ietf.org; Thu, 17 Apr 2008 21:24:00 +0000 Received: from esc91.midphase.com ([216.104.33.66] helo=LC2.labn.net) by esc91.midphase.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JmbaB-000839-Di; Thu, 17 Apr 2008 17:23:51 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 17 Apr 2008 17:23:49 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: Two more working group last calls Cc: In-Reply-To: <049501c89be7$1ed42770$0300a8c0@your029b8cecfe> References: <049501c89be7$1ed42770$0300a8c0@your029b8cecfe> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: Adrian, See below for minor comments: At 11:12 AM 4/11/2008, Adrian Farrel wrote: >Hi, > >Sorry for the continued bombardment with reviewing activity. > >Here are two drafts that were discussed in Philadelphia with the >intention to go to WG last call as soon as possible. > >draft-ietf-rfc4420-bis-02.txt I assume that you mean draft-ietf-ccamp-rfc4420bis-02.txt. >This is the revision to RFC 4420 to fix the TLV encoding to be >consistent with the previous RSVP-TE RFCs. The fix is to the >interpretation of the Length field. >Although we might not expect much in the way of review comments for >this I-D, it would be very helpful if you could read the I-D, point >out any typos, and send a note to say that you have read the >document and believe it is ready for publication. Only a minor suggestion here: I suggest moving the rational for the updated provided from section 14 to section 1. Specifically: - drop section 14 - section 1, 1st paragraph: drop "See Section 14 for a summary of changes." and add: Prior to the change, the Length field indicated the length of the Value field only. After the change, as described in Section 3, the Length field indicates the length of the whole TLV. This change means that this document is consistent with the subobject format defined in [RFC3209] and the TLV format defined in [RFC3471]. Lou >Please send your reviews to the list by 12 noon GMT, April 26, 2008. > >Thanks, >Adrian > >PS, I'll be notifying the MPLS mailing list of these two last calls. > > > From owner-ccamp@ops.ietf.org Thu Apr 17 14:54:20 2008 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 3ADDB3A7010 for ; Thu, 17 Apr 2008 14:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.254 X-Spam-Level: *** X-Spam-Status: No, score=3.254 tagged_above=-999 required=5 tests=[AWL=1.150, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 9R3g8JXXF+tl for ; Thu, 17 Apr 2008 14:54:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 63B3E3A6DE0 for ; Thu, 17 Apr 2008 14:54:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmc04-000Cnv-J0 for ccamp-data@psg.com; Thu, 17 Apr 2008 21:50:36 +0000 Received: from [216.104.42.195] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmc01-000CnR-UJ for ccamp@ops.ietf.org; Thu, 17 Apr 2008 21:50:35 +0000 Received: from esc91.midphase.com ([216.104.33.66] helo=LC2.labn.net) by esc91.midphase.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Jmc00-0004MB-JQ; Thu, 17 Apr 2008 17:50:32 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 17 Apr 2008 17:50:31 -0400 To: "Dimiri Papadimitriou" From: Lou Berger Subject: Re: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt Cc: ccamp@ops.ietf.org In-Reply-To: <20080414120001.9DC8E28C2B6@core3.amsl.com> References: <20080414120001.9DC8E28C2B6@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: Dimitri, I think this versions missed an updated that we previously discussed. Specifically it should define 0 value for Switching Granularity (SG), i.e.: Value Switching Granularity ----- --------------------- 0 Provided in signaling. See [GMPLS-ESVCS] I'll update [GMPLS-ESVCS] to explicitly say that the 0 value MUST be used. Can you make sure this gets into the next rev? Much thanks, Lou At 08:00 AM 4/14/2008, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Common Control and Measurement >Plane Working Group of the IETF. > > > Title : Ethernet Traffic Parameters > Author(s) : D. Papadimitriou, I. Property > Filename : draft-ietf-ccamp-ethernet-traffic-parameters-04.txt > Pages : 13 > Date : 2008-04-13 > >This document describes the Metro Ethernet Forum (MEF) - specific >Ethernet Traffic Parameters as described in MEF10.1 when using >Generalized Multi-Protocol Label Switching (GMPLS) Resource >ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-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. > > > From owner-ccamp@ops.ietf.org Thu Apr 17 22:42:11 2008 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 B4A953A687C for ; Thu, 17 Apr 2008 22:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, 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 cWfRprPiAvWc for ; Thu, 17 Apr 2008 22:42:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C88D53A6810 for ; Thu, 17 Apr 2008 22:42:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmjFH-000Eyu-Ay for ccamp-data@psg.com; Fri, 18 Apr 2008 05:34:47 +0000 Received: from [64.208.49.5] (helo=smail6.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JmjFE-000EyD-F7 for ccamp@ops.ietf.org; Fri, 18 Apr 2008 05:34:46 +0000 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m3I5RG1I013490; Fri, 18 Apr 2008 07:27:18 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 18 Apr 2008 07:34:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt Date: Fri, 18 Apr 2008 07:32:21 +0200 Message-ID: <00275A5B436CA441900CB10936742A386C6BF2@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <200804172150.m3HLoThr028974@mailgate4.alcatel.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt Thread-Index: Acig1RXQRrHPYJyfS8eaPlaNznCSWQAQE1qw References: <20080414120001.9DC8E28C2B6@core3.amsl.com> <200804172150.m3HLoThr028974@mailgate4.alcatel.fr> From: "PAPADIMITRIOU Dimitri" To: "Lou Berger" Cc: X-OriginalArrivalTime: 18 Apr 2008 05:34:35.0590 (UTC) FILETIME=[E30FAE60:01C8A115] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Sender: owner-ccamp@ops.ietf.org Precedence: bulk lou=20 this version is only to align w/ 4420bis. changes like below are for the next. revision. hope this clarifies, -d. > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: Thursday, April 17, 2008 11:51 PM > To: PAPADIMITRIOU Dimitri > Cc: ccamp@ops.ietf.org > Subject: Re: I-D=20 > Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt=20 >=20 > Dimitri, > I think this versions missed an updated that we previously=20 > discussed. Specifically it should define 0 value for Switching=20 > Granularity (SG), i.e.: > Value Switching Granularity > ----- --------------------- > 0 Provided in signaling. See [GMPLS-ESVCS] >=20 > I'll update [GMPLS-ESVCS] to explicitly say that the 0 value=20 > MUST be used. >=20 > Can you make sure this gets into the next rev? >=20 > Much thanks, > Lou >=20 > At 08:00 AM 4/14/2008, Internet-Drafts@ietf.org wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > >directories. > >This draft is a work item of the Common Control and Measurement=20 > >Plane Working Group of the IETF. > > > > > > Title : Ethernet Traffic Parameters > > Author(s) : D. Papadimitriou, I. Property > > Filename :=20 > draft-ietf-ccamp-ethernet-traffic-parameters-04.txt > > Pages : 13 > > Date : 2008-04-13 > > > >This document describes the Metro Ethernet Forum (MEF) - specific > >Ethernet Traffic Parameters as described in MEF10.1 when using > >Generalized Multi-Protocol Label Switching (GMPLS) Resource > >ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet -traffic-parameters-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. > > > > > > >=20 >=20 From owner-ccamp@ops.ietf.org Fri Apr 18 02:47:52 2008 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 583AB3A6AA0 for ; Fri, 18 Apr 2008 02:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.961 X-Spam-Level: X-Spam-Status: No, score=0.961 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 GJS2Pl5Ob6Fw for ; Fri, 18 Apr 2008 02:47:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 771213A6DEC for ; Fri, 18 Apr 2008 02:47:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmn5L-000JZ5-Uw for ccamp-data@psg.com; Fri, 18 Apr 2008 09:40:47 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmn5I-000JYL-VQ for ccamp@ops.ietf.org; Fri, 18 Apr 2008 09:40:46 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3I9egrG008012 for ; Fri, 18 Apr 2008 10:40:42 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3I9ecKC007877 for ; Fri, 18 Apr 2008 10:40:42 +0100 Message-ID: <009e01c8a138$4085cc10$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: New mailing list for ASON Routing Discussions Date: Fri, 18 Apr 2008 10:40:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, As previously promised, we have set up an IETF mailing list for discussions of the ASON Routing Requirements and the production of a bis to RFC 4258. Our hope is that the Design Team will bring issues and discussions and early versions of their text to this list for wider discussion by the community. When their draft is ready for adoption by CCAMP (we hope around Dublin) this list will be closed, and discussion will move to the CCAMP list. Subscribe to the list at https://www.ietf.org/mailman/listinfo/ason-routing Regards, Adrian From owner-ccamp@ops.ietf.org Fri Apr 18 05:52:06 2008 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 9166028C248 for ; Fri, 18 Apr 2008 05:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.38 X-Spam-Level: * X-Spam-Status: No, score=1.38 tagged_above=-999 required=5 tests=[AWL=1.875, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 HtALSXwb8Lnx for ; Fri, 18 Apr 2008 05:52:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9B14A28C233 for ; Fri, 18 Apr 2008 05:52:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmpx2-000GeG-DE for ccamp-data@psg.com; Fri, 18 Apr 2008 12:44:24 +0000 Received: from [216.104.42.195] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmpww-000GdT-2h for ccamp@ops.ietf.org; Fri, 18 Apr 2008 12:44:22 +0000 Received: from esc91.midphase.com ([216.104.33.66] helo=LC2.labn.net) by esc91.midphase.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Jmpwr-0006dY-DI; Fri, 18 Apr 2008 08:44:13 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 18 Apr 2008 08:44:10 -0400 To: "PAPADIMITRIOU Dimitri" From: Lou Berger Subject: RE: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt Cc: "Lou Berger" , In-Reply-To: <00275A5B436CA441900CB10936742A386C6BF2@FRVELSMBS22.ad2.ad. alcatel.com> References: <20080414120001.9DC8E28C2B6@core3.amsl.com> <200804172150.m3HLoThr028974@mailgate4.alcatel.fr> <00275A5B436CA441900CB10936742A386C6BF2@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: Works for me. Thanks! Lou At 01:32 AM 4/18/2008, PAPADIMITRIOU Dimitri wrote: >lou > >this version is only to align w/ 4420bis. > >changes like below are for the next. revision. > >hope this clarifies, >-d. > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Thursday, April 17, 2008 11:51 PM > > To: PAPADIMITRIOU Dimitri > > Cc: ccamp@ops.ietf.org > > Subject: Re: I-D > > Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt > > > > Dimitri, > > I think this versions missed an updated that we previously > > discussed. Specifically it should define 0 value for Switching > > Granularity (SG), i.e.: > > Value Switching Granularity > > ----- --------------------- > > 0 Provided in signaling. See [GMPLS-ESVCS] > > > > I'll update [GMPLS-ESVCS] to explicitly say that the 0 value > > MUST be used. > > > > Can you make sure this gets into the next rev? > > > > Much thanks, > > Lou > > > > At 08:00 AM 4/14/2008, Internet-Drafts@ietf.org wrote: > > >A New Internet-Draft is available from the on-line Internet-Drafts > > >directories. > > >This draft is a work item of the Common Control and Measurement > > >Plane Working Group of the IETF. > > > > > > > > > Title : Ethernet Traffic Parameters > > > Author(s) : D. Papadimitriou, I. Property > > > Filename : > > draft-ietf-ccamp-ethernet-traffic-parameters-04.txt > > > Pages : 13 > > > Date : 2008-04-13 > > > > > >This document describes the Metro Ethernet Forum (MEF) - specific > > >Ethernet Traffic Parameters as described in MEF10.1 when using > > >Generalized Multi-Protocol Label Switching (GMPLS) Resource > > >ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet >-traffic-parameters-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. > > > > > > > > >-traffic-parameters-04.txt> > > > > From owner-ccamp@ops.ietf.org Fri Apr 18 10:59:00 2008 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 6B3C03A6BDD for ; Fri, 18 Apr 2008 10:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.046 X-Spam-Level: X-Spam-Status: No, score=-106.046 tagged_above=-999 required=5 tests=[AWL=-1.552, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 x14K4IIplCHz for ; Fri, 18 Apr 2008 10:58:51 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1F9013A6C70 for ; Fri, 18 Apr 2008 10:58:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmui6-000J5P-RL for ccamp-data@psg.com; Fri, 18 Apr 2008 17:49:18 +0000 Received: from [216.82.250.83] (helo=mail120.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jmuhu-000J3P-HI for ccamp@ops.ietf.org; Fri, 18 Apr 2008 17:49:12 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1208540943!27151466!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 23535 invoked from network); 18 Apr 2008 17:49:04 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-5.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 18 Apr 2008 17:49:04 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3IHn3aF020399; Fri, 18 Apr 2008 13:49:03 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3IHmxZm020378; Fri, 18 Apr 2008 13:49:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A17C.7B2E2091" Subject: Please publish draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt Date: Fri, 18 Apr 2008 12:48:58 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF10E5BE22@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please publish draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt Thread-Index: AcihfHqj8eQd+MGrTEibJiVeX2vvcw== From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Ross Callon" Cc: , "David Ward" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A17C.7B2E2091 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Proto-write-up for draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt Intended status : Informational > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Deborah Brungard is the document shepherd. She has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? I-D had good review and discussion in the CCAMP working group doing its development. It has not had review in any wider forums, but none was deemed necessary or appropriate. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No concerns. No IPR disclosures have been filed. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Consensus is good. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/ ). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downward references. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? The document is informational (no requests for IANA action). Null IANA section included. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments. Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering. This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? WG had good consensus with no disputes or disagreements. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? This is an Informational RFC with no protocol specifications. ------_=_NextPart_001_01C8A17C.7B2E2091 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Proto-write-up for draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt

Intended status : Informational

> (1.a) Who is the Document Shepherd = for this=20 document? Has the

> Document Shepherd personally = reviewed this=20 version of the

> document and, in particular, does he = or she=20 believe this

> version is ready for forwarding to = the IESG for=20 publication?

Deborah=20 Brungard is the document shepherd.

She has=20 personally reviewed the I-D and believes it is ready = for

forwarding to the IESG for = publication.

> (1.b) Has the document had adequate = review both=20 from key WG members

> and from key non-WG members? Does = the Document=20 Shepherd have

> any concerns about the depth or = breadth of the=20 reviews that

> have been performed?

I-D had good review and discussion in the CCAMP working

group = doing its=20 development. It has not had review in any wider forums, but none = was=20 deemed

necessary or appropriate.

> (1.c) Does the Document Shepherd = have concerns=20 that the document

> needs more review from a particular = or broader=20 perspective,

> e.g., security, operational = complexity, someone=20 familiar with

> AAA, internationalization or = XML?

No concerns.

> (1.d) Does the Document Shepherd = have any=20 specific concerns or

> issues with this document that the = Responsible=20 Area Director

> and/or the IESG should be aware of? = For example,=20 perhaps he

> or she is uncomfortable with certain = parts of=20 the document, or

> has concerns whether there really is = a need for=20 it. In any

> event, if the WG has discussed those = issues and=20 has indicated

> that it still wishes to advance the = document,=20 detail those

> concerns here. Has an IPR disclosure = related to=20 this document

> been filed? If so, please include a = reference to=20 the

> disclosure and summarize the WG = discussion and=20 conclusion on

> this issue.

No = concerns. No IPR=20 disclosures have been filed.

> (1.e) How solid is the WG consensus = behind this=20 document? Does it

> represent the strong concurrence of = a few=20 individuals, with

> others being silent, or does the WG = as a whole=20 understand and

> agree with it?

Consensus is good.

> (1.f) Has anyone threatened an = appeal or=20 otherwise indicated extreme

> discontent? If so, please summarise = the areas of=20 conflict in

> separate email messages to the = Responsible Area=20 Director. (It

> should be in a separate email = because this=20 questionnaire is

> entered into the ID = Tracker.)

No threats. No discontent.

> (1.g) Has the Document Shepherd = personally=20 verified that the

> document satisfies all ID nits? = (See

> http://www.ietf.org/ID-Checklist.html and

> http://tools.ietf.org/tools/idnits/). Boilerplate checks are

> not enough; this check needs to be = thorough. Has=20 the document

> met all formal review criteria it = needs to, such=20 as the MIB

> Doctor, media type and URI type=20 reviews?

All checks made.

> (1.h) Has the document split its = references into=20 normative and

> informative? Are there normative = references to=20 documents that

> are not ready for advancement or are = otherwise=20 in an unclear

> state? If such normative references = exist, what=20 is the

> strategy for their completion? Are = there=20 normative references

> that are downward references, as = described in=20 [RFC3967]? If

> so, list these downward references = to support=20 the Area

> Director in the Last Call procedure = for them=20 [RFC3967].

References split. No downward = references.

> (1.i) Has the Document Shepherd = verified that=20 the document IANA

> consideration section exists and is = consistent=20 with the body

> of the document? If the document = specifies=20 protocol

> extensions, are reservations = requested in=20 appropriate IANA

> registries? Are the IANA registries = clearly=20 identified? If

> the document creates a new registry, = does it=20 define the

> proposed initial contents of the = registry and an=20 allocation

> procedure for future registrations? = Does it=20 suggest a

> reasonable name for the new = registry? See=20 [RFC2434]. If the

> document describes an Expert Review = process has=20 Shepherd

> conferred with the Responsible Area = Director so=20 that the IESG

> can appoint the needed Expert during = the IESG=20 Evaluation?

The document is informational (no requests for IANA = action). Null

IANA section = included.

> (1.j) Has the Document Shepherd = verified that=20 sections of the

> document that are written in a = formal language,=20 such as XML

> code, BNF rules, MIB definitions, = etc., validate=20 correctly in

> an automated checker?

No such formal language is = used.

> (1.k) The IESG approval announcement = includes a=20 Document

> Announcement Write-Up. Please = provide such a=20 Document

> Announcement Write-Up. Recent = examples can be=20 found in the

> "Action" announcements for approved = documents.=20 The approval

> announcement contains the following=20 sections:

>

> Technical Summary

> Relevant content can frequently be = found in the=20 abstract

> and/or introduction of the document. = If not,=20 this may be

> an indication that there are = deficiencies in the=20 abstract

> or introduction.

Protection and recovery are = important=20 features of service offerings in = Multiprotocol Label Switching

(MPLS) and Generalized MPLS = (GMPLS) networks. Increasingly, MPLS and = GMPLS=20 networks

are being extended from single domain scope to = multi-domain=20 environments. Various schemes=20 and

processes have been = developed to establish=20 Label Switched Paths (LSPs) in=20 multi-domain environments.

These = are discussed in RFC 4726: A Framework = for=20 Inter-Domain Multiprotocol Label = Switching

Traffic Engineering.

This document analyzes the = application of=20 these techniques to protection = and=20 recovery in multi-domain

networks. The main focus = for this=20 document is on establishing end-to-end diverse Traffic Engineering=20 (TE)

LSPs in multi-domain = networks.

> Working Group Summary

> Was there anything in WG process = that is worth=20 noting? For

> example, was there controversy about = particular=20 points or

> were there decisions where the = consensus was=20 particularly

> rough?

WG had good=20 consensus with no disputes or disagreements.

> Document Quality

> Are there existing implementations = of the=20 protocol? Have a

> significant number of vendors = indicated their=20 plan to

> implement the specification? Are = there any=20 reviewers that

> merit special mention as having done = a thorough=20 review,

> e.g., one that resulted in important = changes or=20 a

> conclusion that the document had no = substantive=20 issues? If

> there was a MIB Doctor, Media Type = or other=20 expert review,

> what was its course (briefly)? In = the case of a=20 Media Type

> review, on what date was the request = posted?

This is = an=20 Informational RFC with no protocol=20 specifications.

= ------_=_NextPart_001_01C8A17C.7B2E2091-- From c2lr@c2lr.net Fri Apr 18 11:22:05 2008 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 E039C3A6C3D; Fri, 18 Apr 2008 11:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -86.019 X-Spam-Level: X-Spam-Status: No, score=-86.019 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, 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 Jy3TPqq8eCyM; Fri, 18 Apr 2008 11:22:05 -0700 (PDT) Received: from host81-155-173-227.range81-155.btcentralplus.com (host81-155-173-227.range81-155.btcentralplus.com [81.155.173.227]) by core3.amsl.com (Postfix) with SMTP id DA5143A6BB2; Fri, 18 Apr 2008 11:22:00 -0700 (PDT) X-Originating-IP: 70.98.128.91 by smtp.81.155.173.227; Fri, 18 Apr 2008 14:21:26 -0500 Message-ID: From: "Valerie Isaac" Reply-To: "Valerie Isaac" To: call-home-bounces@ietf.org Subject: Get your watch now Date: Fri, 18 Apr 2008 14:21:26 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://fybykaza20557.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://fybykaza20557.blogspot.com/ From c.vantonder@netgroup.co.za Sat Apr 19 23:57:30 2008 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 54A3D3A6A3A; Sat, 19 Apr 2008 23:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.35 X-Spam-Level: X-Spam-Status: No, score=-54.35 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_MX=0.535, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, SARE_SPEC_ROLEX_SEL=2.222, 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 VD--HzziBckN; Sat, 19 Apr 2008 23:57:29 -0700 (PDT) Received: from dup-148-233-207-116.prodigy.net.mx (unknown [148.233.207.116]) by core3.amsl.com (Postfix) with SMTP id 17D1F3A6AFF; Sat, 19 Apr 2008 23:56:44 -0700 (PDT) X-Originating-IP: 11.238.32.197 by smtp.148.233.207.116; Sun, 20 Apr 2008 02:56:58 -0500 Message-ID: From: "Willie Parr" Reply-To: "Willie Parr" To: call-home-bounces@ietf.org Subject: Take a look at the latest replica watches Date: Sun, 20 Apr 2008 02:56:58 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Looking for superior quality replica watches? Then welcome to the newly redesigned Prestige Replicas, home of the best reproduction Rolex Sportmodel watches on the whole web! Prestige Replicas offers a tremendous selection of Rolex replica timepieces for both men and women, all of them featuring the original manufacturer markings along with a myriad of details that make these watches look so much like the brand new Rolexes that even the experts are having a hard time differentiating them! http://nexymydylur56.blogspot.com/ So, come visit Prestige Replicas and enjoy not only the most beautiful Rolex Sportmodel replica watches at unbelievable prices, but also get an extra 15% off when you buy two! http://nexymydylur56.blogspot.com/ From c.s@messere.com Sun Apr 20 07:16:13 2008 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 4B3D13A6B6D; Sun, 20 Apr 2008 07:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.688 X-Spam-Level: X-Spam-Status: No, score=-89.688 tagged_above=-999 required=5 tests=[BAYES_99=3.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 s51fq9cNtgIK; Sun, 20 Apr 2008 07:16:12 -0700 (PDT) Received: from ip-150-144.tricom.net (ip-150-144.tricom.net [190.6.150.144]) by core3.amsl.com (Postfix) with SMTP id 165DB28C2C9; Sun, 20 Apr 2008 07:15:48 -0700 (PDT) X-Originating-IP: 162.4.189.70 by smtp.190.6.150.144; Sun, 20 Apr 2008 10:16:07 -0500 Message-ID: From: "Wesley Morin" Reply-To: "Wesley Morin" To: call-home-bounces@ietf.org Subject: Spring quality watches offer Date: Sun, 20 Apr 2008 10:16:07 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://bawedomykot20.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://bawedomykot20.blogspot.com/ From afracial@holaday.com Sun Apr 20 09:09:17 2008 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 3E7DD28C2B6; Sun, 20 Apr 2008 09:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.259 X-Spam-Level: **** X-Spam-Status: No, score=4.259 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MPART_ALT_DIFF=0.739, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=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 EQKyrLzzk9fe; Sun, 20 Apr 2008 09:09:16 -0700 (PDT) Received: from holaday.com (cm216.kappa36.maxonline.com.sg [58.182.36.216]) by core3.amsl.com (Postfix) with SMTP id E2A7B28C1E8; Sun, 20 Apr 2008 09:09:12 -0700 (PDT) Received: from yourdufxwufuzd ([180.235.156.219] helo=yourdufxwufuzd) by d824b63aholaday.com with ESMTP id 5884BC3182B083 for ; Mon, 21 Apr 2008 00:09:18 +0800 Message-ID: <001301c8a343$f10593b0$0209f36c@yourdufxwufuzd> From: Elinor Guerrero To: ccamp-archive@ietf.org Subject: be cook Date: Mon, 21 Apr 2008 00:09:18 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C8A343.F10593B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.181 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.2869 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C8A343.F10593B0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable for racist people to form world-wide organizations.. they could to speak. Often the more one knows the more one can partake. = globally competitive". And we have already seen some examples of ------=_NextPart_000_0010_01C8A343.F10593B0 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
software. It seems awfully limiting. Am I missing something? Is
=

C A 2N A D/9AN     P 6 9H A RM A 5CY

V/A \G _RA - $1.47
C 7/ A L / S - $2.27
S4 O M A - $0.60
L E8 V / T R A - $3.69
FEMALE V\A\G -R A - $1.57
U 4 L T 2R A M - $1.32
115 Items on Sale Today.

which is unfortunately high sought after and is in most cases
------=_NextPart_000_0010_01C8A343.F10593B0-- From c1@gatewayprimary.co.zw Sun Apr 20 18:28:32 2008 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 962E43A6B83; Sun, 20 Apr 2008 18:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -70.403 X-Spam-Level: X-Spam-Status: No, score=-70.403 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, 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 jC4jRcZLkWnH; Sun, 20 Apr 2008 18:28:31 -0700 (PDT) Received: from 227-142-21-190.adsl.terra.cl (227-142-21-190.adsl.terra.cl [190.21.142.227]) by core3.amsl.com (Postfix) with SMTP id 0D52D3A6AED; Sun, 20 Apr 2008 18:28:21 -0700 (PDT) X-Originating-IP: 52.208.80.192 by smtp.190.21.142.227; Sun, 20 Apr 2008 21:28:40 -0500 Message-ID: From: "Michel Cortes" Reply-To: "Michel Cortes" To: call-home-bounces@ietf.org Subject: 15% off on two watches Date: Sun, 20 Apr 2008 21:28:40 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://xobasigyfas55.blogspot.com/ From c.testelli@albergati.com Mon Apr 21 09:10:12 2008 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 77C893A68E4; Mon, 21 Apr 2008 09:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -77.446 X-Spam-Level: X-Spam-Status: No, score=-77.446 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 xvqpNm1ITpOP; Mon, 21 Apr 2008 09:10:01 -0700 (PDT) Received: from 190-51-48-232.speedy.com.ar (unknown [190.51.48.232]) by core3.amsl.com (Postfix) with SMTP id B27B23A6934; Mon, 21 Apr 2008 09:09:47 -0700 (PDT) X-Originating-IP: 88.126.184.200 by smtp.190.51.48.232; Mon, 21 Apr 2008 12:10:05 -0500 Message-ID: From: "Claudio Beard" Reply-To: "Claudio Beard" To: call-home-bounces@ietf.org Subject: Get your watch now Date: Mon, 21 Apr 2008 12:10:05 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you seen the latest Jaeger-LeCoultre watches? They are even more grandiose than ever before and, sadly, as expensive as always. That's why I got my new Jaeger-LeCoultre watch at Prestige Replicas, the popular online store that specializes in low priced replicas of high priced watches. But please don't be deterred by the word "replica"... I'm talking about the cream of the crop of replica watches; such high quality copies that not even the most discriminating connoisseurs would be able to tell the difference between a legitimate Jaeger-LeCoultre and a replica from Prestige Replicas... and the prices are so low that I bought two! Of course, the fact that they offer 15 percent discount when you buy more than one watch helped me make up my mind :) http://ginewywevet24.blogspot.com/ From owner-ccamp@ops.ietf.org Mon Apr 21 12:59:09 2008 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 C11D83A6F80 for ; Mon, 21 Apr 2008 12:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.06 X-Spam-Level: X-Spam-Status: No, score=-0.06 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_25=0.6, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 ypmmKPXyrWyC for ; Mon, 21 Apr 2008 12:59:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0A6B228C10D for ; Mon, 21 Apr 2008 12:56:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jo1yw-0002E3-Pi for ccamp-data@psg.com; Mon, 21 Apr 2008 19:47:18 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jo1yn-0002CI-0O for ccamp@ops.ietf.org; Mon, 21 Apr 2008 19:47:13 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3LJkqL9009655; Mon, 21 Apr 2008 20:46:52 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3LJklxS009625; Mon, 21 Apr 2008 20:46:49 +0100 Message-ID: <000001c8a3e8$6e7487d0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Lou Berger" , "Attila Takacs \(IJ/ETH\)" , "Diego Caviglia \(GO/MCI\)" , "Don Fedyk" , "MEURIC Julien RD-CORE-LAN" Subject: Last call review of draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt Date: Mon, 21 Apr 2008 20:25:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, Here are some review comments about this I-D. As is bound to be the case with an experiment that has not been carried out, I think there are a few wrinkles to be ironed. Cheers, Adrian === I struggled to see the utility of the Upstream_TSpec and Upstream_Adspec objects. By the time these objects are used (on the Resv) the reservation has already been made using the Upstream_Flowspec (on the Path message). This is strengthen by section 2.2.1 that says that the content is constructed using the same mechanisms as used for creating the content of the Flowspec. If that is so, it is a flowspec not a tspec. I would contest that what you really have is... Upstream_Flowspec is used to request a particular reservation as predicted by the ingress. Upstream_TSpec is used to report the intended traffic flow (which might not be the same as the reservation and might require a modification to the reservation). Upstream_Adspec reports the available resources in the upstream direction. In this case, the operational use would be... Path {TSpec, Adspec, Upstream_Flowspec} Resv {Flowspec = fn(TSpec, Adspec), Upstream_TSpec, Upstream_Adspec} If necessary Path {TSpec, Adspec, Upstream_Flowspec'} Resv {Flowspec, Upstream_TSpec, Upstream_Adspec} === I believe it would be helpful to indicate in the Abstract that this is an Experimental approach, and in the Introduction to include a whole paragraph on why this is positioned as an Experimental RFC. === Document title s/LSPs/Label Switched Paths/ === Abstract s/LSPs/Label Switched Paths (LSPs)/ === Section 1 para 1 s/LSPs/Label Switched Paths (LSPs)/ s/TDM/Time Division Multiplexing (TDM)/ === Section 1 para 2 s/discussion on/discussion of/ === Section 1 I believe it may be useful to say what an "asymmetric bandwidth LSP" is. Perhaps... In this context there has been discussion on the support of bidirectional LSPs with asymmetric bandwidth. ADD That is, bidirectional LSPs that have different bandwidth reservations in each direction. === Section 1.2 You have An alternative approach was considered and rejected. For reference purposes only, the rejected approach is summarized in Appendix A. Looking ahead at Appendix A, it is hard to see that this alternative has been rejected. In fact, it says "SHOULD NOT be implemented". Nowhere is there a definitive reason why the alternative has been rejected (although there are a few hints in the introduction to the Appendix). *If* you wish to retain the rejected approach in the documentation, then you need to give some background about why. What would be the implications of doing the approach that lead you to recommend against it? This material could happily go in the appendix leaving the only change to section 1.2 to be... s/rejected approach is summarized/rejected approach is summarized with reasons for rejection/ === Section 2 You have The new upstream objects carry the same information and are used in the same fashion as the existing downstream objects; they only differ in that they relate to traffic flowing in the upstream direction while the existing objects relate to traffic flowing in the downstream direction. They also differ in that they are used on messages in the opposite directions. === Section 2.1.1 You suggest using "Routing problem/MPLS label allocation failure" Are you sure you do not want to be able to tell whether it was the upstream or downstream resources that failed? Since these can be varied independently, it would surely be useful to know which failed. === Section 2.3.1 I think you need to clarify whether the Upstream_Adspec reports the available upstream resources before or after the reservation for the LSP in hand. Note that Adspec would apply before the reservation. === Section 3 You don't list Upstream_Flowspec as carried on a Notify. But an upstream notify session carries and you have defined this to carry Upstream_Flowspec. You also don't list ResvErr as able to carry Upstream_TSpec, but ResvErr can carry which presumably can carry the Upstream_TSpec as it also carries the Flowspec. Also, you don't list PathTear (can carry ) and ResvTear (carries ) Perhaps your excuse will be that you say "Unmodified formats are not listed." If that is the case, it should be pointed out that the formats of the other messages are not modified either! Maybe the best way forward is to show how you modify , and , and say that the use of these constructs on RSVP messages is not modified. That would be the smallest change to the documentation. === Section 4 OLD Per [RFC2205], nodes not supporting this extension should not recognize the new class numbers and respond with an "Unknown Object Class" error. NEW Per [RFC2205], nodes not supporting this extension will not recognize the new class numbers and SHOULD respond with an "Unknown Object Class" error. === Section 4 You have... The error message will propagate to the ingress which can then take action to avoid the path with the incompatible node, or may simply terminate the session. I think you need a little more care with the behavior for unknown object on a Resv since that error will propagate to the egress. === Section 5. You might need another error code as mentioned above. === Section 6 It is always worth referencing draft-ietf-mpls-mpls-and-gmpls-security-framework in GMPLS-related security sections. Although you have not introduced any new ways to penetrate the security, I wonder whether you have introduced new ways to attack the system once security is penetrated. Upstream_Adspec may be a way to damage the system without leaving immediate evidence of where the attack originated. Upstream_TSpec represents a new way to cause an LSP that has been set up, to be torn down. Of course these issues can be protected against, but you need to point them out so that people understand the increased risk and the potential need to use the existing security mechanisms. === Section 7.1 [MEF-TRAFFIC] has been revised. Does it need to be a normative reference? It is only cited as an example. === Section 7.2 [GMPLS-PBBTE] is now a CCAMP I-D === Section 8 s/Author's/Authors'/ === All appendix sections Section headers need left justify === Sections A, A.1, A.3, A.4 s/section/appendix/ (Except "Section 3", "Section 3.1") === From c.grooteman@mcg.nl Mon Apr 21 20:07:52 2008 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 3959428C111; Mon, 21 Apr 2008 20:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -66.675 X-Spam-Level: X-Spam-Status: No, score=-66.675 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 ia860yW3uB6y; Mon, 21 Apr 2008 20:07:51 -0700 (PDT) Received: from cable200-116-236-95.epm.net.co (cable200-116-236-95.epm.net.co [200.116.236.95]) by core3.amsl.com (Postfix) with SMTP id A60FF28C1A8; Mon, 21 Apr 2008 20:07:43 -0700 (PDT) X-Originating-IP: 176.136.170.160 by smtp.200.116.236.95; Mon, 21 Apr 2008 23:08:00 -0500 Message-ID: From: "Nikki Alexander" Reply-To: "Nikki Alexander" To: call-home-bounces@ietf.org Subject: Hot replica watches from 2008 Date: Mon, 21 Apr 2008 23:08:00 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you seen the latest Jaeger-LeCoultre watches? They are even more grandiose than ever before and, sadly, as expensive as always. That's why I got my new Jaeger-LeCoultre watch at Prestige Replicas, the popular online store that specializes in low priced replicas of high priced watches. But please don't be deterred by the word "replica"... I'm talking about the cream of the crop of replica watches; such high quality copies that not even the most discriminating connoisseurs would be able to tell the difference between a legitimate Jaeger-LeCoultre and a replica from Prestige Replicas... and the prices are so low that I bought two! Of course, the fact that they offer 15 percent discount when you buy more than one watch helped me make up my mind :) http://bizarymecid57.blogspot.com/ From owner-ccamp@ops.ietf.org Tue Apr 22 08:03:16 2008 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 26CA33A6D39 for ; Tue, 22 Apr 2008 08:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.742 X-Spam-Level: X-Spam-Status: No, score=0.742 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_25=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 0q8AoEU5yufV for ; Tue, 22 Apr 2008 08:03:14 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B2AA03A68D2 for ; Tue, 22 Apr 2008 08:03:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JoJsv-0002hD-9h for ccamp-data@psg.com; Tue, 22 Apr 2008 14:54:17 +0000 Received: from [216.104.42.195] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JoJso-0002gE-51 for ccamp@ops.ietf.org; Tue, 22 Apr 2008 14:54:12 +0000 Received: from esc91.midphase.com ([216.104.33.66] helo=LC2.labn.net) by esc91.midphase.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JoJsS-0003vh-Hp; Tue, 22 Apr 2008 10:53:49 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Apr 2008 10:51:36 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: Last call review of draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt Cc: ,"Lou Berger" , "Attila Takacs \(IJ/ETH\)" , "Diego Caviglia \(GO/MCI\)" , "Don Fedyk" , "MEURIC Julien RD-CORE-LAN" In-Reply-To: <000001c8a3e8$6e7487d0$0300a8c0@your029b8cecfe> References: <000001c8a3e8$6e7487d0$0300a8c0@your029b8cecfe> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: Adrian, Much thanks for the comments. Please see below for in-line responses. At 03:25 PM 4/21/2008, Adrian Farrel wrote: >Hi, > >Here are some review comments about this I-D. As is bound to be the >case with an experiment that has not been carried out, I think there >are a few wrinkles to be ironed. > >Cheers, >Adrian > >=== >I struggled to see the utility of the Upstream_TSpec and >Upstream_Adspec objects. By the time these objects are used (on the >Resv) the reservation has already been made using the >Upstream_Flowspec (on the Path message). The utility here really comes from the support of PSC modes and preservation of RSVP/IntServ semantics. In short we're maintaining the object types used in the downstream direction and instantiating them for the upstream direction. To quote 2210: From the point of view of RSVP objects, the breakdown is as follows: - The RSVP SENDER_TSPEC object carries the traffic specification (sender TSpec) generated by each data source within an RSVP session. It is transported unchanged through the network, and delivered to both intermediate nodes and receiving applications. - The RSVP ADSPEC object carries information which is generated at either data sources or intermediate network elements, is flowing downstream towards receivers, and may be used and updated inside the network before being delivered to receiving applications. This information includes both parameters describing the properties of the data path, including the availability of specific QoS control services, and parameters required by specific QoS control services to operate correctly. - The RSVP FLOWSPEC object carries reservation request (Receiver_TSpec and RSpec) information generated by data receivers. The information in the FLOWSPEC flows upstream towards data sources. It may be used or updated at intermediate network elements before arriving at the sending application. NOTE: The existence of both SENDER_TSPEC and ADSPEC RSVP objects is somewhat historical. Using the message format described in this note it would be possible to place all of the service control information carried "downstream" by RSVP in the same object. However, the distinction between data which is not updated within the network (in the SENDER_TSPEC object) and data which is updated within the network (in the ADSPEC object) may be useful to an implementation in practice, and is therefore retained. >This is strengthen by section 2.2.1 that says that the content is >constructed using the same mechanisms as used for creating the >content of the Flowspec. If that is so, it is a flowspec not a tspec. I see this as a reference to semantic construction. I think this is clear in the text, but am open to any specific improvements you can suggest: ... The contents of the UPSTREAM_TSPEC Object MUST be constructed using a consistent format and procedures used to construct the FLOWSPEC object that will be used for the LSP, e.g., [RFC2210] or [RFC4328]. The contents of the UPSTREAM_TSPEC Object MAY differ from contents of the UPSTREAM_FLOWSPEC object based on application data transmission requirements. >I would contest that what you really have is... >Upstream_Flowspec is used to request a particular reservation as >predicted by the ingress. yes. >Upstream_TSpec is used to report the intended traffic flow (which >might not be the same as the reservation and might require a >modification to the reservation). right. >Upstream_Adspec reports the available resources in the upstream direction. right again. >In this case, the operational use would be... >Path {TSpec, Adspec, Upstream_Flowspec} >Resv {Flowspec = fn(TSpec, Adspec), Upstream_TSpec, Upstream_Adspec} >If necessary > Path {TSpec, Adspec, Upstream_Flowspec'} > Resv {Flowspec, Upstream_TSpec, Upstream_Adspec} I think this is what the draft says. >=== >I believe it would be helpful to indicate in the Abstract that this >is an Experimental approach, and in the Introduction to include a >whole paragraph on why this is positioned as an Experimental RFC. Okay have added: NOTE: THIS IS AN EXPERIMENTAL RFC. Let us know if you'd to see anything additional. >=== >Document title >s/LSPs/Label Switched Paths/ >=== >Abstract >s/LSPs/Label Switched Paths (LSPs)/ >=== >Section 1 para 1 >s/LSPs/Label Switched Paths (LSPs)/ >s/TDM/Time Division Multiplexing (TDM)/ >=== >Section 1 para 2 >s/discussion on/discussion of/ >=== >Section 1 >I believe it may be useful to say what an "asymmetric bandwidth LSP" is. >Perhaps... > In this context there > has been discussion on the support of bidirectional LSPs with > asymmetric bandwidth. >ADD > That is, bidirectional LSPs that have different bandwidth > reservations in each direction. >=== okay. >Section 1.2 >You have > An alternative approach was considered and > rejected. For reference purposes only, the rejected approach is > summarized in Appendix A. > >Looking ahead at Appendix A, it is hard to see that this alternative >has been rejected. In fact, it says "SHOULD NOT be implemented". >Nowhere is there a definitive reason why the alternative has been >rejected (although there are a few hints in the introduction to the Appendix). well it does say: This section is included for historic purposes and SHOULD NOT be implemented. and In summary, the "ADSPEC Object" approach presented in this section SHOULD NOT be implemented. This seems pretty clear to me. What would you like it to say? >*If* you wish to retain the rejected approach in the documentation, >then you need to give some background about why. What would be the >implications of doing the approach that lead you to recommend against it? >This material could happily go in the appendix leaving the only >change to section 1.2 to be... >s/rejected approach is summarized/rejected approach is summarized >with reasons for rejection/ I've changed the sec. 1.2. text to read "An alternative approach was considered and rejected in favor of the more generic approach presented below." and to A.1. "In particular this approach is technology specific; it uses the ADSPEC object to carry traffic parameters for upstream data and requires MEF Ethernet Traffic Parameter while the approach presented above is suitable for use with any technology." >=== >Section 2 >You have > The new upstream objects carry the same information and are used in > the same fashion as the existing downstream objects; they only differ > in that they relate to traffic flowing in the upstream direction > while the existing objects relate to traffic flowing in the > downstream direction. > >They also differ in that they are used on messages in the opposite directions. okay. >=== >Section 2.1.1 >You suggest using "Routing problem/MPLS label allocation failure" >Are you sure you do not want to be able to tell whether it was the >upstream or downstream resources that failed? Since these can be >varied independently, it would surely be useful to know which failed. I don't have a strong opinion one way or another. >=== >Section 2.3.1 >I think you need to clarify whether the Upstream_Adspec reports the >available upstream resources before or after the reservation for the >LSP in hand. > Note that Adspec would apply before the reservation. This may be true on the initial path, but it isn't actually stated anywhere. Furthermore, the information may include an LSPs reservation even in the case where it is not yet made. e.g., RFC2212 talks in terms of reporting what the "flow might experience" which implies that the full Tspec is accounted for in the initial ADSPEC. So I think, like 2210, this should not be mentioned. >=== >Section 3 >You don't list Upstream_Flowspec as carried on a Notify. But an >upstream notify session carries and you have >defined this to carry Upstream_Flowspec. >You also don't list ResvErr as able to carry Upstream_TSpec, but >ResvErr can carry which presumably can carry >the Upstream_TSpec as it also carries the Flowspec. >Also, you don't list PathTear (can carry ) and >ResvTear (carries ) > >Perhaps your excuse will be that you say "Unmodified formats are not >listed." If that is the case, it should be pointed out that the >formats of the other messages are not modified either! nope. just a simple mistake. >Maybe the best way forward is to show how you modify descriptor>, and , and say >that the use of these constructs on RSVP messages is not modified. >That would be the smallest change to the documentation. Good catch. Have changed the text to read: Object name Applicable RSVP messages --------------- ------------------------ UPSTREAM_FLOWSPEC Path, PathTear, PathErr and Notify (via sender descriptor) UPSTREAM_TSPEC Resv, ResvConf, ResvTear, ResvErr and Notify (via flow descriptor list) UPSTREAM_ADSPEC Resv, ResvConf, ResvTear, ResvErr and Notify (via flow descriptor list) >=== >Section 4 >OLD > Per [RFC2205], nodes not > supporting this extension should not recognize the new class numbers > and respond with an "Unknown Object Class" error. >NEW > Per [RFC2205], nodes not > supporting this extension will not recognize the new class numbers > and SHOULD respond with an "Unknown Object Class" error okay, the should is lower case as this document cannot dictate behavior of non-conforming implementations ;-) >=== >Section 4 >You have... > The error message > will propagate to the ingress which can then take action to avoid the > path with the incompatible node, or may simply terminate the session. >I think you need a little more care with the behavior for unknown >object on a Resv since that error will propagate to the egress. This can only happen from a non-conformant implementation, i.e., one that passes a new object in the path but then rejects it in the resv. >=== >Section 5. >You might need another error code as mentioned above. >=== >Section 6 >It is always worth referencing >draft-ietf-mpls-mpls-and-gmpls-security-framework in GMPLS-related >security sections. > >Although you have not introduced any new ways to penetrate the >security, I wonder whether you have introduced new ways to attack >the system once security is penetrated. Upstream_Adspec may be a way >to damage the system without leaving immediate evidence of where the >attack originated. Upstream_TSpec represents a new way to cause an >LSP that has been set up, to be torn down. Of course these issues >can be protected against, but you need to point them out so that >people understand the increased risk and the potential need to use >the existing security mechanisms. okay have added some words on this. >=== >Section 7.1 >[MEF-TRAFFIC] has been revised. >Does it need to be a normative reference? It is only cited as an example. moved. >=== >Section 7.2 >[GMPLS-PBBTE] is now a CCAMP I-D >=== >Section 8 >s/Author's/Authors'/ >=== >All appendix sections >Section headers need left justify >=== >Sections A, A.1, A.3, A.4 >s/section/appendix/ (Except "Section 3", "Section 3.1") >=== isn't an appendix a section of the document? Thanks for the usual detailed review & comments... Lou From c.thompson@waverley-internet.co.uk Tue Apr 22 10:56:59 2008 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 5303328C15C; Tue, 22 Apr 2008 10:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.884 X-Spam-Level: X-Spam-Status: No, score=-76.884 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 Y36sL1O0UxNH; Tue, 22 Apr 2008 10:56:49 -0700 (PDT) Received: from 190-95-26-104.bk17-dsl.surnet.cl (190-95-26-104.bk17-dsl.surnet.cl [190.95.26.104]) by core3.amsl.com (Postfix) with SMTP id B89DA3A69DF; Tue, 22 Apr 2008 10:56:21 -0700 (PDT) X-Originating-IP: 94.182.52.50 by smtp.190.95.26.104; Tue, 22 Apr 2008 13:56:37 -0500 Message-ID: From: "Vito Mccarthy" Reply-To: "Vito Mccarthy" To: call-home-bounces@ietf.org Subject: April promo on watches Date: Tue, 22 Apr 2008 13:56:37 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit An IWC watch is a uniquely handcrafted time piece that combines a classical element with a timeless elegance. Its appeal comes from their traditional beauty and their superb performance. But this sophistication has always come with a high price tag. Except of course, when you buy an IWC replica. And Prestige Replicas has dozens of IWC replica watches at prices so incredibly low that you can rest assured they won't last long! So, why not head over to Prestige Replicas right now and take a look at their IWC watches? After all, isn't it time you wore a splendid wristwatch without having to spend a fortune? http://nilabykagec08.blogspot.com/ From ca@andreasschulze.de Wed Apr 23 00:15:08 2008 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 C00A028C228; Wed, 23 Apr 2008 00:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -61.797 X-Spam-Level: X-Spam-Status: No, score=-61.797 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CLUBINTERNET=0.781, HELO_EQ_DSL=1.129, HELO_EQ_FR=0.35, HOST_EQ_CLUBINTERNET=0.663, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, 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 q-gjyrPLj2MO; Wed, 23 Apr 2008 00:15:08 -0700 (PDT) Received: from bos94-2-87-91-81-164.dsl.club-internet.fr (bos94-2-87-91-81-164.dsl.club-internet.fr [87.91.81.164]) by core3.amsl.com (Postfix) with SMTP id ADA033A689E; Wed, 23 Apr 2008 00:14:50 -0700 (PDT) X-Originating-IP: 65.173.0.93 by smtp.87.91.81.164; Wed, 23 Apr 2008 03:15:05 -0500 Message-ID: From: "Jean Franks" Reply-To: "Jean Franks" To: call-home-bounces@ietf.org Subject: Rolex replica is a ultimate gift Date: Wed, 23 Apr 2008 03:15:05 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you seen the latest Jaeger-LeCoultre watches? They are even more grandiose than ever before and, sadly, as expensive as always. That's why I got my new Jaeger-LeCoultre watch at Prestige Replicas, the popular online store that specializes in low priced replicas of high priced watches. But please don't be deterred by the word "replica"... I'm talking about the cream of the crop of replica watches; such high quality copies that not even the most discriminating connoisseurs would be able to tell the difference between a legitimate Jaeger-LeCoultre and a replica from Prestige Replicas... and the prices are so low that I bought two! Of course, the fact that they offer 15 percent discount when you buy more than one watch helped me make up my mind :) http://bivanakahyv02.blogspot.com/ From c.ramthun@elkinco.com Thu Apr 24 00:41:18 2008 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 4D6D13A6885; Thu, 24 Apr 2008 00:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.78 X-Spam-Level: X-Spam-Status: No, score=-76.78 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 A78vyRO+D6Pc; Thu, 24 Apr 2008 00:41:17 -0700 (PDT) Received: from adsl190-29-152-31.epm.net.co (adsl190-29-152-31.epm.net.co [190.29.152.31]) by core3.amsl.com (Postfix) with SMTP id 0B31B3A6854; Thu, 24 Apr 2008 00:40:52 -0700 (PDT) X-Originating-IP: 178.200.244.240 by smtp.190.29.152.31; Thu, 24 Apr 2008 03:41:05 -0500 Message-ID: From: "Ezra Villa" Reply-To: "Ezra Villa" To: call-home-bounces@ietf.org Subject: Tag Heuer replicas better than originals Date: Thu, 24 Apr 2008 03:41:05 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Vacheron Constantin has been producing top of the line Swiss watches since 1755. That's a lot of years of watch making, if you ask me! That's why I figured that they've had plenty of time to make their fortune by selling their watches at full price, and it is now time we can get ourselves a Vacheron Constantin for a fraction of the price. That's why I visited Prestige Replicas, the online store that specializes in the best replica watches in the whole world, and sells them for just a couple of hundred bucks. As you can imagine, at Prestige Replicas I found dozens of beautiful Vacheron Constantin replicas in their most sought after models, at prices that are simply unbeatable. Want to see their collection of Vacheron Constantins? Head over to Prestige Replicas now! http://pebadyricid34.blogspot.com/ From c5workshop@c5frc.com Thu Apr 24 11:07:07 2008 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 34B393A6AA3; Thu, 24 Apr 2008 11:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.841 X-Spam-Level: X-Spam-Status: No, score=-90.841 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HOST_EQ_D_D_D_D=0.765, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 mUVRoatKIo-N; Thu, 24 Apr 2008 11:07:05 -0700 (PDT) Received: from h141.105.18.98.ip.windstream.net (h141.105.18.98.ip.windstream.net [98.18.105.141]) by core3.amsl.com (Postfix) with SMTP id 82D403A692E; Thu, 24 Apr 2008 11:07:00 -0700 (PDT) X-Originating-IP: 76.128.48.102 by smtp.98.18.105.141; Thu, 24 Apr 2008 14:07:13 -0500 Message-ID: From: "Gertrude Gunter" Reply-To: "Gertrude Gunter" To: call-home-bounces@ietf.org Subject: One of a kind replicas Date: Thu, 24 Apr 2008 14:07:13 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit If the only thing standing between you and a luxurious Cartier watch is money, then today is your lucky day! Prestige Replicas, the world-famous replica watches dealer, is offering a 15% discount during these spring months for two or more watches, making their whole Cartier collection even more affordable. http://pobohixecam22.blogspot.com/ As you are probably aware of, Prestige Replicas has one of the most extensive collections of Cartier replica watches in the whole wide web. Who cares if they are not legitimate? These replicas are of such high quality that not even a connoisseur would be able to distinguish them from an original Cartier. And with their online delivery guarantee you will be enjoying your new watch in just a couple of days! So, what are you waiting for? Visit Prestige Replicas today! http://pobohixecam22.blogspot.com/ From owner-ccamp@ops.ietf.org Thu Apr 24 13:09:18 2008 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 B090D3A6CC4 for ; Thu, 24 Apr 2008 13:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 TtMh5bzUqxP9 for ; Thu, 24 Apr 2008 13:09:17 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 49D133A6860 for ; Thu, 24 Apr 2008 13:09:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jp7bd-0002BY-J7 for ccamp-data@psg.com; Thu, 24 Apr 2008 19:59:45 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jp7ba-0002AU-Dc for ccamp@ops.ietf.org; Thu, 24 Apr 2008 19:59:44 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3OJxVck002804; Thu, 24 Apr 2008 20:59:31 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3OJx8YJ002651; Thu, 24 Apr 2008 20:59:30 +0100 Message-ID: <051301c8a645$b29b3710$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lou Berger" Cc: , "Attila Takacs \(IJ/ETH\)" , "Diego Caviglia \(GO/MCI\)" , "Don Fedyk" , "MEURIC Julien RD-CORE-LAN" References: <000001c8a3e8$6e7487d0$0300a8c0@your029b8cecfe> <200804221454.m3MEsA0C008868@mta3.iomartmail.com> Subject: Re: Last call review of draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt Date: Thu, 24 Apr 2008 20:58:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Lou, >>=== >>I struggled to see the utility of the Upstream_TSpec and Upstream_Adspec >>objects. By the time these objects are used (on the Resv) the reservation >>has already been made using the Upstream_Flowspec (on the Path message). [SNIP] I think I found the "exactly the same" description a little strong. But given our discussion (snipped) I think we are agreed on the usage. The only thing I find missing from the I-D might be expressed as... "When an egress receives an Upstream-Flowspec object, it responds with an Upstream-TSpec for describe the traffic flow that it will originate. When that Upstream-TSpec is received by the ingress, it may determine that the original reservation is not sufficient to satisfy the traffic flow. In this case it will issue a new Path message with an updated Upstream-Flowspec object to mnodify the resources reserved for the upstream traffic flow. This might also require that the LSP is re-routed, and in extreme cases might result in the LSP being torn down if sufficient resources are not available." >>=== >>I believe it would be helpful to indicate in the Abstract that this is an >>Experimental approach, and in the Introduction to include a whole >>paragraph on why this is positioned as an Experimental RFC. > > Okay have added: > > NOTE: THIS IS AN EXPERIMENTAL RFC. > > Let us know if you'd to see anything additional. In the abstract it would be fine to simply say: "The procedures described in this document are experimental." In the Introduction, you might say: "The usage of asymmetrical bidirectional LSPs is not well developed and no products have been developed yet. In consequence, the procedures described in this document are experimental." >>Section 1.2 >>You have >> An alternative approach was considered and >> rejected. For reference purposes only, the rejected approach is >> summarized in Appendix A. >> >>Looking ahead at Appendix A, it is hard to see that this alternative has >>been rejected. In fact, it says "SHOULD NOT be implemented". Nowhere is >>there a definitive reason why the alternative has been rejected (although >>there are a few hints in the introduction to the Appendix). > > well it does say: > This section is included for historic purposes and SHOULD NOT > be implemented. > > and > In summary, the "ADSPEC Object" approach presented in this > section SHOULD NOT be implemented. > > This seems pretty clear to me. What would you like it to say? Well, I've just seen an I-D bounced by the IESG because it uses "SHOULD" without explaining why you might actually do it. That is, there is a claim that in 2119 language "SHOULD" implies that there might be good reasons to deviate, so there needs to be text to describe how the deviation is handled and why it might be introduced. Curiously, NOT RECOMMENDED would mean the same thing, but might be more acceptable. [SNIP] > I've changed the sec. 1.2. text to read "An alternative approach was > considered and rejected in favor of the more generic approach presented > below." and to A.1. "In particular this approach is technology specific; > it uses the ADSPEC object to carry traffic parameters for upstream data > and requires MEF Ethernet Traffic Parameter while the approach presented > above is suitable for use with any technology." That's good. Thanks. >>=== >>Section 2.1.1 >>You suggest using "Routing problem/MPLS label allocation failure" >>Are you sure you do not want to be able to tell whether it was the >>upstream or downstream resources that failed? Since these can be varied >>independently, it would surely be useful to know which failed. > > I don't have a strong opinion one way or another. Me neither. We could ask the implementers :-) >>Section 2.3.1 >>I think you need to clarify whether the Upstream_Adspec reports the >>available upstream resources before or after the reservation for the LSP >>in hand. > >> Note that Adspec would apply before the reservation. > > This may be true on the initial path, but it isn't actually stated > anywhere. Furthermore, the information may include an LSPs reservation > even in the case where it is not yet made. e.g., RFC2212 talks in terms > of reporting what the "flow might experience" which implies that the full > Tspec is accounted for in the initial ADSPEC. > > So I think, like 2210, this should not be mentioned. OK >>=== >>Section 4 >>You have... >> The error message >> will propagate to the ingress which can then take action to avoid the >> path with the incompatible node, or may simply terminate the session. >>I think you need a little more care with the behavior for unknown object >>on a Resv since that error will propagate to the egress. > > This can only happen from a non-conformant implementation, i.e., one that > passes a new object in the path but then rejects it in the resv. Or a node that has to handle a non-conformant node that generates an Upstream-TSpec when it did not receive an Upstream-Flowspec. But let's leave it. Thanks for the work. Adrian From owner-ccamp@ops.ietf.org Thu Apr 24 13:16:47 2008 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 21EFF3A6913 for ; Thu, 24 Apr 2008 13:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 dPu3m24udb8A for ; Thu, 24 Apr 2008 13:16:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5347A3A6C4B for ; Thu, 24 Apr 2008 13:16:44 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jp7l4-0003rG-L2 for ccamp-data@psg.com; Thu, 24 Apr 2008 20:09:30 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jp7l1-0003pz-DN for ccamp@ops.ietf.org; Thu, 24 Apr 2008 20:09:29 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3OK9Ae4005762; Thu, 24 Apr 2008 21:09:10 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3OK93Of005730; Thu, 24 Apr 2008 21:09:08 +0100 Message-ID: <052601c8a647$0a0cd0c0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: Subject: Communication to the MEF from the IETF's CCAMP Working Group Date: Thu, 24 Apr 2008 21:08:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Dear Nan, Bob, and Bill, The IETF's CCAMP working group would like to inform the MEF of work it is carrying out to apply GMPLS protocols to the requirements of the Ethernet UNI and Ethernet service spectrum defined by the MEF. GMPLS is a family of IP-based protocols developed within the IETF and applicable to a range of technologies from packet switched networks (such as MPLS), through layer 2 networks (such as ATM, Frame Relay, and Ethernet), to optical networks (like TDM and WDM). We would like to draw your intention to the following Internet-Drafts that we are working on. We would welcome any feedback from your members on the requirements, details of the solutions proposed, or applicability of our work. "Ethernet Traffic Parameters" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-04.txt "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-00.txt "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-00.txt "GMPLS Ethernet Label Switching Architecture and Framework" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-01.txt Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs From owner-ccamp@ops.ietf.org Thu Apr 24 13:40:50 2008 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 BE2683A69E4 for ; Thu, 24 Apr 2008 13:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.217 X-Spam-Level: X-Spam-Status: No, score=-0.217 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 8LM0d9QysHj5 for ; Thu, 24 Apr 2008 13:40:49 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AAA953A6A70 for ; Thu, 24 Apr 2008 13:40:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jp8Am-0008Ld-IH for ccamp-data@psg.com; Thu, 24 Apr 2008 20:36:04 +0000 Received: from [216.104.42.195] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jp8Aj-0008Kk-6l for ccamp@ops.ietf.org; Thu, 24 Apr 2008 20:36:02 +0000 Received: from esc91.midphase.com ([216.104.33.66] helo=LC2.labn.net) by esc91.midphase.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Jp8Ae-0002JK-8W; Thu, 24 Apr 2008 16:35:56 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 24 Apr 2008 16:35:55 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: Last call review of draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt Cc: "Lou Berger" ,, "Attila Takacs \(IJ/ETH\)" , "Diego Caviglia \(GO/MCI\)" , "Don Fedyk" , "MEURIC Julien RD-CORE-LAN" In-Reply-To: <051301c8a645$b29b3710$0300a8c0@your029b8cecfe> References: <000001c8a3e8$6e7487d0$0300a8c0@your029b8cecfe> <200804221454.m3MEsA0C008868@mta3.iomartmail.com> <051301c8a645$b29b3710$0300a8c0@your029b8cecfe> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: Adrian, Please see below. At 03:58 PM 4/24/2008, Adrian Farrel wrote: >Hi Lou, > >>>=== >>>I struggled to see the utility of the Upstream_TSpec and >>>Upstream_Adspec objects. By the time these objects are used (on >>>the Resv) the reservation has already been made using the >>>Upstream_Flowspec (on the Path message). > >[SNIP] > >I think I found the "exactly the same" description a little strong. >But given our discussion (snipped) I think we are agreed on the usage. > >The only thing I find missing from the I-D might be expressed as... > >"When an egress receives an Upstream-Flowspec object, it responds >with an Upstream-TSpec for describe the traffic flow that it will >originate. When that Upstream-TSpec is received by the ingress, it >may determine that the original reservation is not sufficient to >satisfy the traffic flow. In this case it will issue a new Path >message with an updated Upstream-Flowspec object to mnodify the >resources reserved for the upstream traffic flow. This might also >require that the LSP is re-routed, and in extreme cases might result >in the LSP being torn down if sufficient resources are not available." Added to section 2.2.1. >>>=== >>>I believe it would be helpful to indicate in the Abstract that >>>this is an Experimental approach, and in the Introduction to >>>include a whole paragraph on why this is positioned as an Experimental RFC. >> >>Okay have added: >> >> NOTE: THIS IS AN EXPERIMENTAL RFC. >> >>Let us know if you'd to see anything additional. > >In the abstract it would be fine to simply say: > >"The procedures described in this document are experimental." done >In the Introduction, you might say: > >"The usage of asymmetrical bidirectional LSPs is not well developed >and no products have been developed yet. In consequence, the >procedures described in this document are experimental." added: "the procedures described in this document are experimental." >>>Section 1.2 >>>You have >>> An alternative approach was considered and >>> rejected. For reference purposes only, the rejected approach is >>> summarized in Appendix A. >>> >>>Looking ahead at Appendix A, it is hard to see that this >>>alternative has been rejected. In fact, it says "SHOULD NOT be >>>implemented". Nowhere is there a definitive reason why the >>>alternative has been rejected (although there are a few hints in >>>the introduction to the Appendix). >> >>well it does say: >> This section is included for historic purposes and SHOULD NOT >> be implemented. >> >>and >> In summary, the "ADSPEC Object" approach presented in this >> section SHOULD NOT be implemented. >> >>This seems pretty clear to me. What would you like it to say? > >Well, I've just seen an I-D bounced by the IESG because it uses >"SHOULD" without explaining why you might actually do it. That is, >there is a claim that in 2119 language "SHOULD" implies that there >might be good reasons to deviate, so there needs to be text to >describe how the deviation is handled and why it might be introduced. > >Curiously, NOT RECOMMENDED would mean the same thing, but might be >more acceptable. NOT RECOMMENDED it is. >[SNIP] > >>I've changed the sec. 1.2. text to read "An alternative approach >>was considered and rejected in favor of the more generic approach >>presented below." and to A.1. "In particular this approach is >>technology specific; it uses the ADSPEC object to carry traffic >>parameters for upstream data and requires MEF Ethernet Traffic >>Parameter while the approach presented above is suitable for use >>with any technology." > >That's good. >Thanks. > >>>=== >>>Section 2.1.1 >>>You suggest using "Routing problem/MPLS label allocation failure" >>>Are you sure you do not want to be able to tell whether it was the >>>upstream or downstream resources that failed? Since these can be >>>varied independently, it would surely be useful to know which failed. >> >>I don't have a strong opinion one way or another. > >Me neither. >We could ask the implementers :-) > >>>Section 2.3.1 >>>I think you need to clarify whether the Upstream_Adspec reports >>>the available upstream resources before or after the reservation >>>for the LSP in hand. >> >>> Note that Adspec would apply before the reservation. >> >>This may be true on the initial path, but it isn't actually stated >>anywhere. Furthermore, the information may include an LSPs >>reservation even in the case where it is not yet made. e.g., >>RFC2212 talks in terms of reporting what the "flow might >>experience" which implies that the full Tspec is accounted for in >>the initial ADSPEC. >> >>So I think, like 2210, this should not be mentioned. > >OK > >>>=== >>>Section 4 >>>You have... >>> The error message >>> will propagate to the ingress which can then take action to avoid the >>> path with the incompatible node, or may simply terminate the session. >>>I think you need a little more care with the behavior for unknown >>>object on a Resv since that error will propagate to the egress. >> >>This can only happen from a non-conformant implementation, i.e., >>one that passes a new object in the path but then rejects it in the resv. > >Or a node that has to handle a non-conformant node that generates an >Upstream-TSpec when it did not receive an Upstream-Flowspec. > >But let's leave it. great. Thanks for the comments! Lou >Thanks for the work. >Adrian > > > From owner-ccamp@ops.ietf.org Fri Apr 25 03:51:25 2008 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 3015E3A6DCE for ; Fri, 25 Apr 2008 03:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.22 X-Spam-Level: X-Spam-Status: No, score=0.22 tagged_above=-999 required=5 tests=[AWL=-1.585, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MANGLED_LIST=2.3, 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 CLtAqbV4X8CM for ; Fri, 25 Apr 2008 03:51:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 09B603A6920 for ; Fri, 25 Apr 2008 03:51:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JpLP3-000OCY-Id for ccamp-data@psg.com; Fri, 25 Apr 2008 10:43:41 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JpLP0-000OBv-OG for ccamp@ops.ietf.org; Fri, 25 Apr 2008 10:43:40 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3PAhWeL004223; Fri, 25 Apr 2008 11:43:32 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3PAhTOP004155; Fri, 25 Apr 2008 11:43:31 +0100 Message-ID: <05b501c8a6c1$318afb70$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lou Berger" Cc: References: <049501c89be7$1ed42770$0300a8c0@your029b8cecfe> Subject: Re: Two more working group last calls Date: Fri, 25 Apr 2008 11:43:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Lou, I just consulted with our AD on the "correct" way of doing this. He suggested... - The abstract and introduction should very clearly state that this document is an update to the previous document. - The introduction should point to a section somewhere in the document (possibly an annex) that describes the differences in some detail. - Otherwise, the new document can stand on its own. I think that is what we currently have. Do you feel strongly about your suggested change? Cheers, Adrian ----- Original Message ----- From: "Lou Berger" To: "Adrian Farrel" Cc: Sent: Thursday, April 17, 2008 10:23 PM Subject: Re: Two more working group last calls > Adrian, > See below for minor comments: > > At 11:12 AM 4/11/2008, Adrian Farrel wrote: >>Hi, >> >>Sorry for the continued bombardment with reviewing activity. >> >>Here are two drafts that were discussed in Philadelphia with the intention >>to go to WG last call as soon as possible. >> >>draft-ietf-rfc4420-bis-02.txt > > I assume that you mean draft-ietf-ccamp-rfc4420bis-02.txt. > > >>This is the revision to RFC 4420 to fix the TLV encoding to be consistent >>with the previous RSVP-TE RFCs. The fix is to the interpretation of the >>Length field. >>Although we might not expect much in the way of review comments for this >>I-D, it would be very helpful if you could read the I-D, point out any >>typos, and send a note to say that you have read the document and believe >>it is ready for publication. > > Only a minor suggestion here: > > I suggest moving the rational for the updated provided from section 14 to > section 1. Specifically: > > - drop section 14 > - section 1, 1st paragraph: drop "See Section 14 for a summary of > changes." and add: > Prior to the change, the Length field indicated the length of the > Value field only. After the change, as described in Section 3, the > Length field indicates the length of the whole TLV. This change means > that this document is consistent with the subobject format defined in > [RFC3209] and the TLV format defined in [RFC3471]. > > Lou From owner-ccamp@ops.ietf.org Fri Apr 25 07:14:43 2008 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 C378A3A6E05 for ; Fri, 25 Apr 2008 07:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MANGLED_LIST=2.3, 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 4oKFmVdTZhno for ; Fri, 25 Apr 2008 07:14:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C5DF93A6DFD for ; Fri, 25 Apr 2008 07:14:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JpOU7-0006aV-N0 for ccamp-data@psg.com; Fri, 25 Apr 2008 14:01:07 +0000 Received: from [216.104.42.195] (helo=esc91.midphase.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JpOU1-0006Zo-2U for ccamp@ops.ietf.org; Fri, 25 Apr 2008 14:01:02 +0000 Received: from esc91.midphase.com ([216.104.33.66] helo=LC2.labn.net) by esc91.midphase.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1JpOTy-0002bH-4s; Fri, 25 Apr 2008 10:00:58 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Apr 2008 10:00:55 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: Two more working group last calls Cc: "Lou Berger" , In-Reply-To: <05b501c8a6c1$318afb70$0300a8c0@your029b8cecfe> References: <049501c89be7$1ed42770$0300a8c0@your029b8cecfe> <05b501c8a6c1$318afb70$0300a8c0@your029b8cecfe> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc91.midphase.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: Adrian, Not sure how this is an AD issue, to me it's one of aesthetics/style. As this is an issue of style and personal preference, the choice is 100% the author's (i.e., yours). In other words, please feel free to ignore my suggestion! Lou At 06:43 AM 4/25/2008, Adrian Farrel wrote: >Hi Lou, > >I just consulted with our AD on the "correct" way of doing this. He >suggested... > >- The abstract and introduction should very clearly state that this > document is an update to the previous document. >- The introduction should point to a section somewhere in the > document (possibly an annex) that describes the differences in > some detail. >- Otherwise, the new document can stand on its own. > >I think that is what we currently have. > >Do you feel strongly about your suggested change? > >Cheers, >Adrian >----- Original Message ----- From: "Lou Berger" >To: "Adrian Farrel" >Cc: >Sent: Thursday, April 17, 2008 10:23 PM >Subject: Re: Two more working group last calls > > >>Adrian, >> See below for minor comments: >> >>At 11:12 AM 4/11/2008, Adrian Farrel wrote: >>>Hi, >>> >>>Sorry for the continued bombardment with reviewing activity. >>> >>>Here are two drafts that were discussed in Philadelphia with the >>>intention to go to WG last call as soon as possible. >>> >>>draft-ietf-rfc4420-bis-02.txt >> >>I assume that you mean draft-ietf-ccamp-rfc4420bis-02.txt. >> >> >>>This is the revision to RFC 4420 to fix the TLV encoding to be >>>consistent with the previous RSVP-TE RFCs. The fix is to the >>>interpretation of the Length field. >>>Although we might not expect much in the way of review comments >>>for this I-D, it would be very helpful if you could read the I-D, >>>point out any typos, and send a note to say that you have read the >>>document and believe it is ready for publication. >> >>Only a minor suggestion here: >> >>I suggest moving the rational for the updated provided from section >>14 to section 1. Specifically: >> >>- drop section 14 >>- section 1, 1st paragraph: drop "See Section 14 for a summary of >>changes." and add: >> Prior to the change, the Length field indicated the length of the >> Value field only. After the change, as described in Section 3, the >> Length field indicates the length of the whole TLV. This change means >> that this document is consistent with the subobject format defined in >> [RFC3209] and the TLV format defined in [RFC3471]. >> >>Lou > > > From owner-ccamp@ops.ietf.org Fri Apr 25 11:38:01 2008 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 B75C23A6AC4 for ; Fri, 25 Apr 2008 11:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.415 X-Spam-Level: X-Spam-Status: No, score=-105.415 tagged_above=-999 required=5 tests=[AWL=-1.148, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227, 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 xBxKg-R+OpC0 for ; Fri, 25 Apr 2008 11:38:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B3E1C3A68DB for ; Fri, 25 Apr 2008 11:38:00 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JpSgn-000BwV-Gj for ccamp-data@psg.com; Fri, 25 Apr 2008 18:30:29 +0000 Received: from [216.82.241.195] (helo=mail121.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JpSgh-000BvS-UA for ccamp@ops.ietf.org; Fri, 25 Apr 2008 18:30:28 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1209148218!26346392!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 25973 invoked from network); 25 Apr 2008 18:30:18 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-12.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 25 Apr 2008 18:30:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3PIUIIS001981 for ; Fri, 25 Apr 2008 14:30:18 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3PIUEvX001951 for ; Fri, 25 Apr 2008 14:30:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A702.6735B8E6" Subject: Working Group Last Call: draft-ietf-ccamp-pc-and-sc-reqs-02 Date: Fri, 25 Apr 2008 13:30:13 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF10F7A8D2@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call: draft-ietf-ccamp-pc-and-sc-reqs-02 Thread-Index: AcinAma4cVOgNqu6REeXIW68/i9pSw== From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A702.6735B8E6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable WG, =20 To ensure you have weekend reading material (especially here in the NE with our yet another rainy weekend), we have two more documents which we discussed in Phila to Last Call. I'll send separate mails. =20 And don't forget the Last Calls on draft-ietf-rfc4420bis-02.txt and draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt will end tomorrow. =20 This is to initiate a Working Group Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-02.t xt =20 Please send your comments to the mailing list prior to EOB May 9. =20 Adrian and Deborah ------_=_NextPart_001_01C8A702.6735B8E6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
WG,
 
To = ensure you have=20 weekend reading material (especially here in the NE with our yet=20 another rainy weekend), we have two more documents which we = discussed in=20 Phila to Last Call. I'll send separate mails.
 
And = don't forget the=20 Last Calls on draft-ietf-rfc4420bis-02.txt and draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt will end=20 tomorrow.
 
This = is to initiate=20 a Working Group Last Call on:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc= -reqs-02.txt
 
Please = send your=20 comments to the mailing list prior to EOB May 9.
 
Adrian = and=20 Deborah
------_=_NextPart_001_01C8A702.6735B8E6-- From c.herrero@comercialherrero.com Sat Apr 26 07:02:58 2008 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 0C9E228C197; Sat, 26 Apr 2008 07:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -62.202 X-Spam-Level: X-Spam-Status: No, score=-62.202 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 1RZi8b-2EP+U; Sat, 26 Apr 2008 07:02:53 -0700 (PDT) Received: from 201-213-223-5.net.prima.net.ar (201-213-223-5.net.prima.net.ar [201.213.223.5]) by core3.amsl.com (Postfix) with SMTP id E967928C101; Sat, 26 Apr 2008 06:59:59 -0700 (PDT) X-Originating-IP: 47.148.192.58 by smtp.201.213.223.5; Sat, 26 Apr 2008 10:00:07 -0500 Message-ID: From: "Anita Bates" Reply-To: "Anita Bates" To: call-home-bounces@ietf.org Subject: Take a look at the latest replica watches Date: Sat, 26 Apr 2008 10:00:07 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Isn't it time you got yourself the watch you've been dreaming of for years? If that watch is a Gucci, then there is no better place to spoil yourself than Prestige Replicas, because at our website we can put a beautiful Gucci replica watch on your wrist, in one of the latest and most desirable models, for under 200 dollars! There is no need to spend a fortune on a Gucci anymore... get yourself a replica instead! Prestige Replicas's replica watches are of the best quality, featuring such authentic details that not even a connoisseur could tell the difference, and our prices are simply unbeatable... come check us out and see for yourself! http://liwutokafeh10.blogspot.com/ From c.rademacher@hallopizza.de Sat Apr 26 17:49:42 2008 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 0AE683A6886; Sat, 26 Apr 2008 17:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -66.061 X-Spam-Level: X-Spam-Status: No, score=-66.061 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, 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 VzSzNo9BpAKq; Sat, 26 Apr 2008 17:49:41 -0700 (PDT) Received: from 175-147-16-190.fibertel.com.ar (175-147-16-190.fibertel.com.ar [190.16.147.175]) by core3.amsl.com (Postfix) with SMTP id 614883A6884; Sat, 26 Apr 2008 17:49:32 -0700 (PDT) X-Originating-IP: 186.184.184.6 by smtp.190.16.147.175; Sat, 26 Apr 2008 20:49:40 -0500 Message-ID: From: "Christine Mcintyre" Reply-To: "Christine Mcintyre" To: call-home-bounces@ietf.org Subject: Rolex replica is a ultimate gift Date: Sat, 26 Apr 2008 20:49:40 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://sileninigek54.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://sileninigek54.blogspot.com/ From owner-ccamp@ops.ietf.org Sun Apr 27 05:32:58 2008 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 6E5AC3A69FB for ; Sun, 27 Apr 2008 05:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 c3ewi4ZZI2lX for ; Sun, 27 Apr 2008 05:32:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3579B3A6989 for ; Sun, 27 Apr 2008 05:32:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jq5wm-000FTT-A7 for ccamp-data@psg.com; Sun, 27 Apr 2008 12:25:36 +0000 Received: from [62.128.201.248] (helo=asmtp1.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jq5wg-000FSg-42 for ccamp@ops.ietf.org; Sun, 27 Apr 2008 12:25:31 +0000 Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3RCPShY019960 for ; Sun, 27 Apr 2008 13:25:28 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3RCPKf7019948 for ; Sun, 27 Apr 2008 13:25:27 +0100 Message-ID: <06d401c8a861$c3127540$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Thoughts on draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt Date: Sun, 27 Apr 2008 13:24:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, Here are some thoughts on your draft. Cheers, Adrian === Title/document name You have the broad title "GMPLS control of Ethernet" yet the document is named draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt. I think that, as per the Abstract, you are limiting yourselves to 802.1Qay, and that is fine. So you should retitle the document "GMPLS Control of 802.1Qay Ethernet Networks" or something like that. === Author list Before this goes to become an RFC you will have to reduse the front page listing to no more than 4 names. I suggest that you do this by placing only the editors on the front page, but continuing to list all of the authors in the "Authors' Addresses" section. === Abstract s/the standard IEEE data/the standard IEEE data plane/ === Document History I think you could delete this now. Or move it to an Appendix if it is important to you. === Section 1 s/by a another/by another/ s/aligned with GMPLS/aligned with the GMPLS/ s/plane and the PBB-TE forwarding/plane and PBB-TE forwarding/ === You might add a sentence or two to the Introduction explaining why GMPLS is relevant. Something like... Generalized MPLS (GMPLS) [RFC3945] is a family of control plane protocols designed to operate in connection oriented and traffic engineering transport networks. GMPLS is applicable to a range of network technologies including Layer 2 Switching capable networks (L2SC). === Section 1 You have: Appendix A summarized the rational for this data plane technology until the IEEE specification is more mature. It is your intention that Appendix A will be removed becuase 802.1Qay explains the facts in enough detail? I would support that. We do not need to redocument IEEE work. Do you think that the work in IEEE is there yet? === Section 2 s/Ethernet Label switched Path/Ethernet Label Switched Path/ === Section 2.1 ESP: You have "between two or more CBPs" People will understand "between two CBPs" but may need help to understand "more". s/Ports(CBPs)/Ports (CBPs)/ s/(MSTI)(A set/(MSTI). (A set/ s/of MSTIs)./of MSTIs.)/ s/an GMPLS/a GMPLS/ === Section 2.1 PBB-TE Region Not sure I like this term. RFC 3945, RFC 4206, and the MLN Requirements I-D have a definition of region. Is "PBB-TE Region" an IEEE term? Does it map to layer or domain in GMPLS? === Section 2.1 Point-to-Multipoint PBB-TE service instance s/multipoint ESP/point-to-multipoint ESP/ s/leaves/branches/ ... or ... You might prefer to say that the n P2P ESPs are co-routed but in the oposite direction from the source-to-leaf sub-ESPs comprising the P2MP ESP. There is no such thing as a P2MP GMPLS bidirectional tree until you define one later. So this terminology at least needs a forward pointer. === Section 3 Please capitalise the section heading === Section 3 Suggest you replace "[see Appendix A]" with "see [IEEE 802.1Qay]". You could also retain a reference to Appendix A, but see the previous discussion. === Section 4.1 s/Ip_Source_Sddr/Ip_Source_Addr/ "From a GMPLS control plane point of view an Ethernet LSP MAY also be identified as any other LSP" What do you mean "MAY"? Surely this is "is". === Section 5.1 "This may be any switch along the path." This may be *originated by* any switch along the path? === Section 5.2 s/then node/the node/ Don't you need to be able to distinguish whether it is a source or dest address that has caused the problem? === Section 5.3 and 5.4 s/discontinuities/discrepencies/ ??? I'm not sure about these error cases, and I don't find a description in the body of the text (did I look ahard enough?). The error codes sounds like you are suggesting that an LSR (i.e. switch) that receives a Path message will check the information in the ERO against the informaiton in the Upstream-Label and Label-Set objects. But... - the hop information is stipped from the ERO before the Path is sent - we shouldn't have duplicate information in our data elements - the LSR should not "look ahead" in the ERO in any way different from the process described in RFC3209. === Section 7 I think a good deal of work is needed on this section. Possibly some more work is needed in draft-ietf-ccamp-gmpls-ethernet-arch-01.txt as well. All you have done here is lift the text from the architecture document. You need to consider... - I don't find any reference in the rest of your document to UNI ports - "Commonly known techniques" should have references - You should reference draft-ietf-mpls-mpls-and-gmpls-security-framework - What care should be taken to protect the trusted domain from untrusted access? - What happens if legacy Ethernet control plane techniques are enabled in the GMPLS controlled network? - What happens if Ethernet frames are injected into the network? It would appear that PBB-TE has many of the same vulnerabilities in this regard as Ethernet and IP. How does the network protect against this? Does GMPLS contribute to the protection? - Do the error codes described in section 5 provide a way to use GMPLS to probe the network and discover the configuration of core nodes? === Manageability With the introduction of a new technology to the GMPLS family, I think it would be worth your draft discussing the manageability of a GMPLS controlled PBB-TE network. What features do you require from GMPLS? How do you debug GMPLS established ESPs, and how do you debug the GMPLS control plane itself? Some of this may be by reference to existing or soon-to-be-created documents. (Notwithstanding section 4.5). === From ca.rh@ifsj.g12.br Sun Apr 27 05:57:41 2008 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 D58C83A6AFE; Sun, 27 Apr 2008 05:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -63.921 X-Spam-Level: X-Spam-Status: No, score=-63.921 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_MISMATCH_NET=0.611, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, 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 f2GgERFAIj5L; Sun, 27 Apr 2008 05:57:41 -0700 (PDT) Received: from 15.169.114-78.rev.gaoland.net (unknown [78.114.169.15]) by core3.amsl.com (Postfix) with SMTP id 3606C3A6A61; Sun, 27 Apr 2008 05:57:31 -0700 (PDT) X-Originating-IP: 232.73.136.72 by smtp.78.114.169.15; Sun, 27 Apr 2008 08:57:42 -0500 Message-ID: From: "Jan Moses" Reply-To: "Jan Moses" To: call-home-bounces@ietf.org Subject: Rolex replica is a ultimate gift Date: Sun, 27 Apr 2008 08:57:42 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080426-0, 26/04/2008), Outbound message X-Antivirus-Status: Clean An IWC watch is a uniquely handcrafted time piece that combines a classical element with a timeless elegance. Its appeal comes from their traditional beauty and their superb performance. But this sophistication has always come with a high price tag. Except of course, when you buy an IWC replica. And Prestige Replicas has dozens of IWC replica watches at prices so incredibly low that you can rest assured they won't last long! So, why not head over to Prestige Replicas right now and take a look at their IWC watches? After all, isn't it time you wore a splendid wristwatch without having to spend a fortune? http://nagofemutur50.blogspot.com/ From c.gab@gab-fotografie.de Sun Apr 27 15:41:32 2008 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 6C7D33A6D80; Sun, 27 Apr 2008 15:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -58.526 X-Spam-Level: X-Spam-Status: No, score=-58.526 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_REPLICA_ROLEX=3.157, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, REPLICA_WATCH=3.396, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_GENREP=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, 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 7OTWt8bQzAzz; Sun, 27 Apr 2008 15:41:31 -0700 (PDT) Received: from 200141102038.user.veloxzone.com.br (200141102038.user.veloxzone.com.br [200.141.102.38]) by core3.amsl.com (Postfix) with SMTP id 5452828C1B4; Sun, 27 Apr 2008 15:41:02 -0700 (PDT) X-Originating-IP: 10.116.128.57 by smtp.200.141.102.38; Sun, 27 Apr 2008 18:41:12 -0500 Message-ID: From: "Sherrie Wolff" Reply-To: "Sherrie Wolff" To: call-home-bounces@ietf.org Subject: Save 80% on Brand name replica watches Date: Sun, 27 Apr 2008 18:41:12 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080427-1, 27/04/2008), Outbound message X-Antivirus-Status: Clean When it comes down to getting a replica Rolex watch, there is just one place that offers its visitors and customers the highest quality available: Prestige Replicas. This unparalleled online store specializes in top of the line replica watches with unsurpassed performance, and bearing every marking that the genuine timepieces have. Every replica watch that Prestige Replicas carries, is made of solid stainless steel and features a sapphire crystal glass. What's more, every Rolex in store displays the green Rolex sticker with model number and logo on it. Just because you're buying a replica, don't settle for a low quality product. There are only a handful of online stores that offer the highest quality Rolex replica watches and Prestige Replicas is among them, and with the lowest available prices! http://xicerexilyc36.blogspot.com/ From primmis_@gmx.com Sun Apr 27 21:01:42 2008 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 89BA83A6BDB for ; Sun, 27 Apr 2008 21:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.804 X-Spam-Level: **** X-Spam-Status: No, score=4.804 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_80=2, FH_RELAY_NODNS=1.451, MIME_BASE64_TEXT=1.753, 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 UfyITDzkA1mn for ; Sun, 27 Apr 2008 21:01:41 -0700 (PDT) Received: from smtp.ciudad.com.ar (unknown [190.244.226.105]) by core3.amsl.com (Postfix) with SMTP id 3A94A3A6CC8 for ; Sun, 27 Apr 2008 21:01:40 -0700 (PDT) Received: from smtp.ciudad.com.ar[127.0.0.1] by smtp.ciudad.com.ar[127.0.0.1] (SMTPD32); Mon, 28 Apr 2008 01:01:33 +0200 Organization: PRIMMIS Reply-To: primmis@gmx.com Message-ID: <25b27cd7b923bd8d15e89da800150f8a@gmx.com> From: "PRIMMIS" To: Subject: Motos Financiadas 23 de abril 2008 Date: Mon, 28 Apr 2008 00:59:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: base64 VmVuZG8gbW90b3MgMEttIG51ZXZhcyBhbCBtZWpvciBwcmVjaW8geSB0b3RhbG1lbnRlIGZpbmFu Y2lhZGFzLCBwcmltZXIgY3VvdGEgZW4gMzAgZGlhcy4gRW50cmVnYSBlbiB0b2RvIGVsIHBhaXMu IENvbnN1bHRlIHkgY29tcHJ1ZWJlbG8uIElOQ1JFSUJMRSEhDQpFTUFJTDogcHJpbW1pc0BnbXgu Y29tDQpNU046IHByaW1taXNAZ214LmNvbQ== From c.graham@symnetics.com.ar Mon Apr 28 03:52:00 2008 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 92F3B28C296; Mon, 28 Apr 2008 03:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.346 X-Spam-Level: X-Spam-Status: No, score=-65.346 tagged_above=-999 required=5 tests=[BAYES_60=1, FB_QUALITY_REPLICA=10.357, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, 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 5pZcWlgGPyPu; Mon, 28 Apr 2008 03:51:59 -0700 (PDT) Received: from host90-104-dynamic.27-79-r.retail.telecomitalia.it (host90-104-dynamic.27-79-r.retail.telecomitalia.it [79.27.104.90]) by core3.amsl.com (Postfix) with SMTP id 653B53A6E81; Mon, 28 Apr 2008 03:51:43 -0700 (PDT) X-Originating-IP: 45.72.124.123 by smtp.79.27.104.90; Mon, 28 Apr 2008 06:51:53 -0500 Message-ID: From: "Russel Wiley" Reply-To: "Russel Wiley" To: call-home-bounces@ietf.org Subject: Hot replica watches from 2008 Date: Mon, 28 Apr 2008 06:51:53 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer! With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica! http://tacugufigac04.blogspot.com/ From fzduring@qstart.com Mon Apr 28 05:38:25 2008 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 026C828C116; Mon, 28 Apr 2008 05:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.586 X-Spam-Level: **** X-Spam-Status: No, score=4.586 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RCVD_IN_XBL=3.033, 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 g1B0F9bit2PL; Mon, 28 Apr 2008 05:38:19 -0700 (PDT) Received: from ns2.mineduc.cl (unknown [200.14.108.1]) by core3.amsl.com (Postfix) with SMTP id 6BBE93A6C37; Mon, 28 Apr 2008 05:38:16 -0700 (PDT) Received: from 05quigab02 ([171.192.144.192]) by 16c0ec8qstart.com with ESMTP id o4WNJLNG214790 for ; Mon, 28 Apr 2008 08:38:22 -0400 Message-ID: <000f01c8a90b$37799b30$069e0eec@05quigab02> From: Cyrus A. Spivey To: ccamp-archive@ietf.org Subject: her help Date: Mon, 28 Apr 2008 08:38:22 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C8A90B.37799B30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.1409 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.2869 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C8A90B.37799B30 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable involvement is restricted or modulated by my ability to, so to satisfactorally then it will be accepted by the masses;leaving user from excess radiation. Other physical problems that occur ------=_NextPart_000_000C_01C8A90B.37799B30 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
potentially harmful to our continued existence, might go a long
<= BR>

C A 1N A D/9AN     P 3 1H A RM A 0CY

V/A \G _RA - $1.47
C 8/ A L / S - $2.29
S4 O M A - $0.64
L E0 V / T R A - $3.63
FEMALE V /_A -/ G \R -/A - $1.51
U 5 L T 3R A M - $1.35
176 Items on Sale Today.

more computer sights coming on line and appearing throughout the
= ------=_NextPart_000_000C_01C8A90B.37799B30-- From owner-ccamp@ops.ietf.org Mon Apr 28 14:36:42 2008 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 87BF53A6C11 for ; Mon, 28 Apr 2008 14:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.505 X-Spam-Level: X-Spam-Status: No, score=0.505 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 s4KMlPD8g2mc for ; Mon, 28 Apr 2008 14:36:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 645E73A6D21 for ; Mon, 28 Apr 2008 14:36:17 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqatW-000EE0-NH for ccamp-data@psg.com; Mon, 28 Apr 2008 21:28:18 +0000 Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqatT-000ECv-P0 for ccamp@ops.ietf.org; Mon, 28 Apr 2008 21:28:17 +0000 Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m3SLSBI5007647 for ; Mon, 28 Apr 2008 22:28:12 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m3SLSATE007639 for ; Mon, 28 Apr 2008 22:28:11 +0100 Message-ID: <00c801c8a976$c141a900$0400a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <049501c89be7$1ed42770$0300a8c0@your029b8cecfe> Subject: Working group last calls complete Date: Mon, 28 Apr 2008 22:27:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, We completed the last calls on draft-ietf-ccamp-rfc4420bis-02.txt and draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt As I see it, there is no need for an update to draft-ietf-ccamp-rfc4420bis-02.txt. Lou has agreed the necessary changes to draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt so we just need to see a revised version and we can proceed. As I am an author of one of these I-Ds, Deborah will do the document shepherding. Cheers, Adrian From c2a@click2advertising.com Mon Apr 28 15:24:41 2008 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 5656A3A6CEA; Mon, 28 Apr 2008 15:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -72.159 X-Spam-Level: X-Spam-Status: No, score=-72.159 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 Ga2skAuc-+Wx; Mon, 28 Apr 2008 15:24:40 -0700 (PDT) Received: from r190-135-156-165.dialup.adsl.anteldata.net.uy (r190-135-156-165.dialup.adsl.anteldata.net.uy [190.135.156.165]) by core3.amsl.com (Postfix) with SMTP id D7E773A6A5A; Mon, 28 Apr 2008 15:22:36 -0700 (PDT) X-Originating-IP: 34.144.108.176 by smtp.190.135.156.165; Mon, 28 Apr 2008 18:22:43 -0500 Message-ID: From: "Carmine Sewell" Reply-To: "Carmine Sewell" To: call-home-bounces@ietf.org Subject: Get one of these awesome replicas Date: Mon, 28 Apr 2008 18:22:43 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Vacheron Constantin has been producing top of the line Swiss watches since 1755. That's a lot of years of watch making, if you ask me! That's why I figured that they've had plenty of time to make their fortune by selling their watches at full price, and it is now time we can get ourselves a Vacheron Constantin for a fraction of the price. That's why I visited Prestige Replicas, the online store that specializes in the best replica watches in the whole world, and sells them for just a couple of hundred bucks. As you can imagine, at Prestige Replicas I found dozens of beautiful Vacheron Constantin replicas in their most sought after models, at prices that are simply unbeatable. Want to see their collection of Vacheron Constantins? Head over to Prestige Replicas now! http://byzevyzamod78.blogspot.com/ From pqjune@m78.com Tue Apr 29 05:43:02 2008 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 BC55428C21F; Tue, 29 Apr 2008 05:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.94 X-Spam-Level: *** X-Spam-Status: No, score=3.94 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033] 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 dI2p4pEKrGsU; Tue, 29 Apr 2008 05:42:54 -0700 (PDT) Received: from ipa185.7.tellas.gr (ipa185.7.tellas.gr [84.254.7.185]) by core3.amsl.com (Postfix) with SMTP id D9C1F28C263; Tue, 29 Apr 2008 05:41:58 -0700 (PDT) Received: (qmail 42898 invoked from network); Tue, 29 Apr 2008 15:42:04 +0300 Received: from unknown (HELO sakhs) (pqjune@m78.com@150.85.38.166) by b907fe54m78.com with SMTP; Tue, 29 Apr 2008 15:42:04 +0300 Message-ID: <001801c8aa0f$92a94fa0$01b6f86c@sakhs> From: Jerri S. Kerns To: ccamp-archive@ietf.org Subject: He audio Date: Tue, 29 Apr 2008 15:42:04 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C8AA0F.92A94FA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.2962 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C8AA0F.92A94FA0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable intern will mean more of a Global economy; thus , the once known their own = language. Marshal McLuhan was convinced that the nuance directly reflects its creator's individual response to the ------=_NextPart_000_0015_01C8AA0F.92A94FA0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
how I'm trying to live daily. Banking on individual difference to

C A 4N A D/3AN     P 7 9H A RM A 5CY

V/A \G _RA - $1.47
C 5/ A L / S - $2.20
S3 O M A - $0.67
L E6 V / T R A - $3.61
FEMALE V /_A -/ G \R -/A - $1.57
U 3 L T 8R A M - $1.36
193 Items on Sale Today.

for downtown office space will drive the rent/lease prices down,
= ------=_NextPart_000_0015_01C8AA0F.92A94FA0-- From owner-ccamp@ops.ietf.org Tue Apr 29 09:04:37 2008 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 5513B3A6D7B for ; Tue, 29 Apr 2008 09:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.242 X-Spam-Level: X-Spam-Status: No, score=-105.242 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 q6tZSFOesIOK for ; Tue, 29 Apr 2008 09:04:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CCBAD28C33F for ; Tue, 29 Apr 2008 09:01:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jqrvw-0005PG-FX for ccamp-data@psg.com; Tue, 29 Apr 2008 15:39:56 +0000 Received: from [216.82.241.195] (helo=mail121.messagelabs.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jqruy-0005EK-J7 for ccamp@ops.ietf.org; Tue, 29 Apr 2008 15:39:35 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1209483534!21214142!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 7489 invoked from network); 29 Apr 2008 15:38:54 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 29 Apr 2008 15:38:54 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3TFcsQd012104 for ; Tue, 29 Apr 2008 11:38:54 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3TFcp06012079 for ; Tue, 29 Apr 2008 11:38:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA0F.1F7ABC40" Subject: Poll for WG Adoption of Two WSON documents Date: Tue, 29 Apr 2008 10:38:50 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqA== From: "BRUNGARD, DEBORAH A, ATTLABS" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA0F.1F7ABC40 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable CCAMP, =20 From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label s-02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8AA0F.1F7ABC40 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
CCAMP,
 
From = Philadelphia,=20 we had good support for adoption of two of the WSON documents as CCAMP = working=20 group documents:
 
- = Framework for=20 WSON
http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-03.txt
 
- = Lambda=20 Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm= pls-lambda-labels-02.txt
 
Please = express your=20 opinions (authors, we welcome your opinion also).
 
Thanks,
Adrian = and=20 Deborah
------_=_NextPart_001_01C8AA0F.1F7ABC40-- From owner-ccamp@ops.ietf.org Tue Apr 29 09:09:08 2008 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 36CA228C32E for ; Tue, 29 Apr 2008 09:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 NCRl6jvYMZMa for ; Tue, 29 Apr 2008 09:09:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 43C0628C30E for ; Tue, 29 Apr 2008 09:09:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JqsG1-0008Lp-Qe for ccamp-data@psg.com; Tue, 29 Apr 2008 16:00:41 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqsFR-0008Gd-Q3 for ccamp@ops.ietf.org; Tue, 29 Apr 2008 16:00:22 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 7493C3A6C7A; Tue, 29 Apr 2008 09:00:00 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt Message-Id: <20080429160001.7493C3A6C7A@core3.amsl.com> Date: Tue, 29 Apr 2008 09:00:01 -0700 (PDT) Sender: owner-ccamp@ops.ietf.org Precedence: bulk --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 : GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) Author(s) : L. Berger, et al. Filename : draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt Pages : 14 Date : 2008-04-29 This document defines a method for the support of GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original RSVP model for the transport of traffic related parameters. The procedures described in this document are experimental. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-asymm-bw-bidir-lsps-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-asymm-bw-bidir-lsps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-29085105.I-D@ietf.org> --NextPart-- From owner-ccamp@ops.ietf.org Tue Apr 29 09:15:41 2008 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 86CF53A6E41 for ; Tue, 29 Apr 2008 09:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 pKtmCQaDK7Uw for ; Tue, 29 Apr 2008 09:15:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 791243A6E39 for ; Tue, 29 Apr 2008 09:15:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JqsO8-0009XT-CV for ccamp-data@psg.com; Tue, 29 Apr 2008 16:09:04 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqsNk-0009Tc-Hu for ccamp@ops.ietf.org; Tue, 29 Apr 2008 16:08:51 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CC95C20FA3; Tue, 29 Apr 2008 18:08:38 +0200 (CEST) X-AuditID: c1b4fb3e-ab192bb000004ec0-0a-481748067297 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A2D9620560; Tue, 29 Apr 2008 18:08:38 +0200 (CEST) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 18:08:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA13.48B57400" Subject: RE: Poll for WG Adoption of Two WSON documents Date: Tue, 29 Apr 2008 18:08:28 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF684014F0E83@esealmw110.eemea.ericsson.se> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll for WG Adoption of Two WSON documents thread-index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAABA77w From: "Diego Caviglia" To: "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 29 Apr 2008 16:08:38.0637 (UTC) FILETIME=[490739D0:01C8AA13] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA13.48B57400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Deborah, Yes to all. =20 I'm a contributor/author of both. =20 BR =20 Diego =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: marted=EC 29 aprile 2008 17.39 To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents =20 CCAMP, =20 From Philadelphia, we had good support for adoption of two of the WSON = documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit= ched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels= -02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8AA13.48B57400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Deborah,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Yes to all.

 

I’m a contributor/author of = both.

 

BR

 

Diego

 

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, = ATTLABS
Sent: marted=EC 29 aprile = 2008 17.39
To: = ccamp@ops.ietf.org
Subject: Poll for WG = Adoption of Two WSON documents

 

CCAMP,

 

From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP = working group documents:

 

- Framework for WSON

 

- Lambda Labels

 

Please express your opinions (authors, we welcome = your opinion also).

 

Thanks,

Adrian and Deborah

------_=_NextPart_001_01C8AA13.48B57400-- From owner-ccamp@ops.ietf.org Tue Apr 29 09:19:43 2008 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 9F4763A6E0F for ; Tue, 29 Apr 2008 09:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.145 X-Spam-Level: X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, 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 XyuBgmUHRYYg for ; Tue, 29 Apr 2008 09:19:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD8753A6AA3 for ; Tue, 29 Apr 2008 09:19:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JqsSv-000ALq-IT for ccamp-data@psg.com; Tue, 29 Apr 2008 16:14:01 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqsSR-000AEL-PC for ccamp@ops.ietf.org; Tue, 29 Apr 2008 16:13:46 +0000 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Apr 2008 18:11:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Poll for WG Adoption of Two WSON documents Date: Tue, 29 Apr 2008 18:11:46 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02605875792@ftrdmel2> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAAA4vGw References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> From: To: X-OriginalArrivalTime: 29 Apr 2008 16:11:45.0740 (UTC) FILETIME=[B88CE0C0:01C8AA13] Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Deborah. I support both for WG docs. Cheers, Julien ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS CCAMP, =20 From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label s-02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah From owner-ccamp@ops.ietf.org Tue Apr 29 09:23:24 2008 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 6F8083A6CA7 for ; Tue, 29 Apr 2008 09:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 FuKQx0nVox09 for ; Tue, 29 Apr 2008 09:23:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7D0C528C34F for ; Tue, 29 Apr 2008 09:23:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JqsXr-000BCO-Ef for ccamp-data@psg.com; Tue, 29 Apr 2008 16:19:07 +0000 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqsXT-000B8k-3e for ccamp@ops.ietf.org; Tue, 29 Apr 2008 16:19:01 +0000 Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro.abac.com (8.14.1/8.14.1) with ESMTP id m3TGIUx4032620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2008 09:18:35 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <48174A58.9080108@grotto-networking.com> Date: Tue, 29 Apr 2008 09:18:32 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" CC: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Content-Type: multipart/alternative; boundary="------------030601000304010609010808" Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------030601000304010609010808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi WG chairs, Very much in favor of both becoming WG documents. Regards Greg B. BRUNGARD, DEBORAH A, ATTLABS wrote: > CCAMP, > > From Philadelphia, we had good support for adoption of two of the WSON > documents as CCAMP working group documents: > > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt > > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt > > Please express your opinions (authors, we welcome your opinion also). > > Thanks, > Adrian and Deborah -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------030601000304010609010808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi WG chairs,  Very much in favor of both becoming WG documents.

Regards

Greg B.

BRUNGARD, DEBORAH A, ATTLABS wrote:
CCAMP,
 
From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents:
 
- Framework for WSON
 
- Lambda Labels
 
Please express your opinions (authors, we welcome your opinion also).
 
Thanks,
Adrian and Deborah

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------030601000304010609010808-- From owner-ccamp@ops.ietf.org Tue Apr 29 09:28:20 2008 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 C278E28C387 for ; Tue, 29 Apr 2008 09:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 vSzBSoF80gNG for ; Tue, 29 Apr 2008 09:28:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DDF783A6E52 for ; Tue, 29 Apr 2008 09:27:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jqsbe-000Bkn-9q for ccamp-data@psg.com; Tue, 29 Apr 2008 16:23:02 +0000 Received: from [63.118.34.22] (helo=hicks.ciena.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqsbE-000Bh5-UT for ccamp@ops.ietf.org; Tue, 29 Apr 2008 16:22:52 +0000 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAMrnFkg/dicb/2dsb2JhbACCOjGpdw X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA15.386621E8" Subject: RE: Poll for WG Adoption of Two WSON documents Date: Tue, 29 Apr 2008 12:22:29 -0400 Message-ID: <23F9E58A916663488B3D12D1FE1A999F013622ED@mdmxm03.ciena.com> In-reply-to: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Poll for WG Adoption of Two WSON documents Thread-index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAABhDaw References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> From: "Ong, Lyndon" To: "BRUNGARD, DEBORAH A, ATTLABS" , X-OriginalArrivalTime: 29 Apr 2008 16:22:30.0504 (UTC) FILETIME=[38DC0E80:01C8AA15] Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA15.386621E8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support both as WG drafts. =20 Lyndon ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, April 29, 2008 8:39 AM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, =20 From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label s-02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8AA15.386621E8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support both as WG = drafts.
 
Lyndon

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Tuesday, April 29, 2008 8:39 AM
To:=20 ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON=20 documents

CCAMP,
 
From = Philadelphia,=20 we had good support for adoption of two of the WSON documents as CCAMP = working=20 group documents:
 
- = Framework for=20 WSON
http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-03.txt
 
- = Lambda=20 Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm= pls-lambda-labels-02.txt
 
Please = express your=20 opinions (authors, we welcome your opinion also).
 
Thanks,
Adrian = and=20 Deborah
------_=_NextPart_001_01C8AA15.386621E8-- From owner-ccamp@ops.ietf.org Tue Apr 29 09:38:37 2008 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 BF3AA3A6ABB for ; Tue, 29 Apr 2008 09:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 eoNJG8ZttS6c for ; Tue, 29 Apr 2008 09:38:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A90333A6E1F for ; Tue, 29 Apr 2008 09:38:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JqsgP-000CS0-Td for ccamp-data@psg.com; Tue, 29 Apr 2008 16:27:57 +0000 Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqsfW-000CK7-GE for ccamp@ops.ietf.org; Tue, 29 Apr 2008 16:27:19 +0000 Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K0300BVRHP1AW@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 29 Apr 2008 11:27:01 -0500 (CDT) Received: from L735042 ([10.124.12.83]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K030091KHOXEK@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 29 Apr 2008 11:27:01 -0500 (CDT) Date: Tue, 29 Apr 2008 11:26:57 -0500 From: Linda Dunbar Subject: RE: Poll for WG Adoption of Two WSON documents In-reply-to: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> To: "'BRUNGARD, DEBORAH A, ATTLABS'" , ccamp@ops.ietf.org Message-id: <003701c8aa15$d87090b0$530c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_49jiLnoVjuv7myoIcxekEg)" Thread-index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAABq6Bg References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_49jiLnoVjuv7myoIcxekEg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I support both. Linda Dunbar _____ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, April 29, 2008 10:39 AM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switche d-03.txt - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02 .txt Please express your opinions (authors, we welcome your opinion also). Thanks, Adrian and Deborah --Boundary_(ID_49jiLnoVjuv7myoIcxekEg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I support both.

 

Linda Dunbar

 

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, April 29, 2008 10:39 AM
To: ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON documents

 

CCAMP,

 

From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents:

 

- Framework for WSON

 

- Lambda Labels

 

Please express your opinions (authors, we welcome your opinion also).

 

Thanks,

Adrian and Deborah

--Boundary_(ID_49jiLnoVjuv7myoIcxekEg)-- From owner-ccamp@ops.ietf.org Tue Apr 29 09:54:47 2008 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 C5B6A3A6BF2 for ; Tue, 29 Apr 2008 09:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.662 X-Spam-Level: X-Spam-Status: No, score=0.662 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DK=1.009, HELO_MISMATCH_DK=1.7, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 kKAeRNLzfilV for ; Tue, 29 Apr 2008 09:54:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8B3393A6DC6 for ; Tue, 29 Apr 2008 09:54:46 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jqszy-000FAg-28 for ccamp-data@psg.com; Tue, 29 Apr 2008 16:48:10 +0000 Received: from [80.237.202.18] (helo=deframx18.softcom.dk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqszN-000F67-NB for ccamp@ops.ietf.org; Tue, 29 Apr 2008 16:47:48 +0000 Received: (qmail 30821 invoked by uid 74); 29 Apr 2008 16:47:31 -0000 Received: from mail.acreo.se (217.151.195.216) by deframx18.softcom.dk (envelope-from ) with ESMTP. tag msg.1209487650.835267.16464 (Processed in 0.271092 secs); 29 Apr 2008 16:47:31 -0000 X-SoftScan-Status: clean X-Secure-TLS: Yes, message received through TLS by deframx18.softcom.dk (RC4-MD5) Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by deframx18.softcom.dk over TLS secured channel with ESMTP; Tue, 29 Apr 2008 18:47:30 +0200 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Tue, 29 Apr 2008 18:47:30 +0200 From: Anders Gavler To: "BRUNGARD, DEBORAH A, ATTLABS" , "ccamp@ops.ietf.org" Date: Tue, 29 Apr 2008 18:47:29 +0200 Subject: RE: Poll for WG Adoption of Two WSON documents Thread-Topic: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAACViuA Message-ID: <73B74934786FBB4F951B5F99724CEB6002BA8CE0CC@acreoexc01.ad.acreo.se> References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: multipart/alternative; boundary="_000_73B74934786FBB4F951B5F99724CEB6002BA8CE0CCacreoexc01ada_" MIME-Version: 1.0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk --_000_73B74934786FBB4F951B5F99724CEB6002BA8CE0CCacreoexc01ada_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Supporting both as wg documents. /Anders ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf = Of BRUNGARD, DEBORAH A, ATTLABS Sent: den 29 april 2008 17:39 To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, From Philadelphia, we had good support for adoption of two of the WSON docu= ments as CCAMP working group documents: - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switch= ed-03.txt - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-0= 2.txt Please express your opinions (authors, we welcome your opinion also). Thanks, Adrian and Deborah --_000_73B74934786FBB4F951B5F99724CEB6002BA8CE0CCacreoexc01ada_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Supporting both as = wg documents.

 

/Anders<= /span>

 

From:= owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATT= LABS
Sent: den 29 april 2008 17:3= 9
To: ccamp@ops.ietf.org
Subject: Poll for WG Adoptio= n of Two WSON documents

 

CCAMP,

 

From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents:=

 

- Framework for WSON

 

- Lambda Labels

 

Please express your opinions (authors, we welcome your opinion also).

 

Thanks,

Adrian and Deborah

--_000_73B74934786FBB4F951B5F99724CEB6002BA8CE0CCacreoexc01ada_-- From owner-ccamp@ops.ietf.org Tue Apr 29 10:03:07 2008 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 84BE128C367 for ; Tue, 29 Apr 2008 10:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 G4ZMmJppa-lH for ; Tue, 29 Apr 2008 10:03:06 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EFF4728C376 for ; Tue, 29 Apr 2008 10:03:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jqt85-000GH3-97 for ccamp-data@psg.com; Tue, 29 Apr 2008 16:56:33 +0000 Received: from [206.16.17.180] (helo=usaga04-in.huawei.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jqt7c-000GE0-O8 for ccamp@ops.ietf.org; Tue, 29 Apr 2008 16:56:18 +0000 Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K0300BZQJ1FAW@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 29 Apr 2008 11:56:04 -0500 (CDT) Received: from L73682 ([10.124.12.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K03009JXJ1CEK@usaga04-in.huawei.com> for ccamp@ops.ietf.org; Tue, 29 Apr 2008 11:56:03 -0500 (CDT) Date: Tue, 29 Apr 2008 11:56:00 -0500 From: Young Lee Subject: RE: Poll for WG Adoption of Two WSON documents In-reply-to: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> To: "'BRUNGARD, DEBORAH A, ATTLABS'" , ccamp@ops.ietf.org Message-id: <004001c8aa19$e6f61390$6c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_LrpXkGu+nntqEghXeWEG7w)" Thread-index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAACqL4g References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_LrpXkGu+nntqEghXeWEG7w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I support both as WG drafts. Young _____ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, April 29, 2008 10:39 AM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switche d-03.txt - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02 .txt Please express your opinions (authors, we welcome your opinion also). Thanks, Adrian and Deborah --Boundary_(ID_LrpXkGu+nntqEghXeWEG7w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I support both as WG drafts.

 

Young

 

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, April 29, 2008 10:39 AM
To: ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON documents

 

CCAMP,

 

From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents:

 

- Framework for WSON

 

- Lambda Labels

 

Please express your opinions (authors, we welcome your opinion also).

 

Thanks,

Adrian and Deborah

--Boundary_(ID_LrpXkGu+nntqEghXeWEG7w)-- From owner-ccamp@ops.ietf.org Tue Apr 29 10:30:44 2008 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 6E5EF3A6CA7 for ; Tue, 29 Apr 2008 10:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.081 X-Spam-Level: * X-Spam-Status: No, score=1.081 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 EUk7syet1euW for ; Tue, 29 Apr 2008 10:30:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 483193A6C2B for ; Tue, 29 Apr 2008 10:30:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JqtZu-000Jp2-QQ for ccamp-data@psg.com; Tue, 29 Apr 2008 17:25:18 +0000 Received: from [202.32.8.206] (helo=tyo202.gate.nec.co.jp) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqtZR-000JlJ-Fy for ccamp@ops.ietf.org; Tue, 29 Apr 2008 17:25:04 +0000 Received: from mailgate3.nec.co.jp (mailgate54.nec.co.jp [10.7.69.193]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m3THOlTl028753; Wed, 30 Apr 2008 02:24:47 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m3THOlb11001; Wed, 30 Apr 2008 02:24:47 +0900 (JST) Received: from yonosuke.jp.nec.com (yonosuke.jp.nec.com [10.26.220.15]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id m3THOk6V009702; Wed, 30 Apr 2008 02:24:46 +0900 (JST) Received: from C08MAR60524 ([172.25.106.29] [172.25.106.29]) by mail.jp.nec.com with ESMTP; Wed, 30 Apr 2008 02:24:44 +0900 Reply-To: From: "Itaru Nishioka" To: "'BRUNGARD, DEBORAH A, ATTLABS'" , References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Subject: RE: Poll for WG Adoption of Two WSON documents Date: Wed, 30 Apr 2008 02:24:40 +0900 Organization: nec Message-Id: <003101c8aa1d$e97631f0$61ef3e0a@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01C8AA69.595DD9F0" X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAADqTAg Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0032_01C8AA69.595DD9F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Support both as WG drafts. Itaru. _____ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Wednesday, April 30, 2008 12:39 AM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt Please express your opinions (authors, we welcome your opinion also). Thanks, Adrian and Deborah ------=_NextPart_000_0032_01C8AA69.595DD9F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Support both as WG drafts.
 
 
Itaru.

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, = DEBORAH A,=20 ATTLABS
Sent: Wednesday, April 30, 2008 12:39 = AM
To:=20 ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON = documents

CCAMP,
 
From = Philadelphia,=20 we had good support for adoption of two of the WSON documents as CCAMP = working=20 group documents:
 
- = Framework for=20 WSON
http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-03.txt
 
- = Lambda=20 Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm= pls-lambda-labels-02.txt
 
Please express=20 your opinions (authors, we welcome your opinion = also).
 
Thanks,
Adrian and=20 Deborah
------=_NextPart_000_0032_01C8AA69.595DD9F0-- From owner-ccamp@ops.ietf.org Tue Apr 29 11:17:59 2008 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 E51E43A6A17 for ; Tue, 29 Apr 2008 11:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.547 X-Spam-Level: X-Spam-Status: No, score=-105.547 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 tPfn4SWAaoGz for ; Tue, 29 Apr 2008 11:17:59 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 373B43A682E for ; Tue, 29 Apr 2008 11:17:57 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JquIp-000PNE-2r for ccamp-data@psg.com; Tue, 29 Apr 2008 18:11:43 +0000 Received: from [168.127.0.57] (helo=fncnmp04.fnc.fujitsu.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JquIH-000PIZ-2y for ccamp@ops.ietf.org; Tue, 29 Apr 2008 18:11:28 +0000 Received: from rchemx01.fnc.net.local ([168.127.134.104]) by fncnmp02.fnc.fujitsu.com with ESMTP; 29 Apr 2008 13:11:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA24.657A4588" Subject: RE: Poll for WG Adoption of Two WSON documents Date: Tue, 29 Apr 2008 13:11:07 -0500 Message-ID: In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAAFSn2A From: "Bardalai, Snigdho" To: "BRUNGARD, DEBORAH A, ATTLABS" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA24.657A4588 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In favor of both IDs =20 Snigdho -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On = Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, April 29, 2008 10:39 AM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, =20 From Philadelphia, we had good support for adoption of two of the WSON = documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit= ched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels= -02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8AA24.657A4588 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In=20 favor of both IDs
 
Snigdho
-----Original Message-----
From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Tuesday, April 29, 2008 10:39 AM
To: = ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON = documents

CCAMP,
 
From = Philadelphia,=20 we had good support for adoption of two of the WSON documents as CCAMP = working=20 group documents:
 
- = Framework for=20 WSON
http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-03.txt
 
- = Lambda=20 Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm= pls-lambda-labels-02.txt
 
Please express=20 your opinions (authors, we welcome your opinion = also).
 
Thanks,
Adrian and=20 Deborah
------_=_NextPart_001_01C8AA24.657A4588-- From cabinetdelespinasse@delespinasse.com Tue Apr 29 12:13:49 2008 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 7A1C03A6D16; Tue, 29 Apr 2008 12:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -79.18 X-Spam-Level: X-Spam-Status: No, score=-79.18 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, J_CHICKENPOX_24=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, TVD_RCVD_IP=1.931, 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 OUFEBZlTCzou; Tue, 29 Apr 2008 12:13:47 -0700 (PDT) Received: from 190-174-132-7.speedy.com.ar (unknown [190.174.132.7]) by core3.amsl.com (Postfix) with SMTP id 63CD43A69F3; Tue, 29 Apr 2008 12:13:36 -0700 (PDT) X-Originating-IP: 0.201.121.234 by smtp.190.174.132.7; Tue, 29 Apr 2008 15:13:44 -0500 Message-ID: From: "Romeo Kline" Reply-To: "Romeo Kline" To: call-home-bounces@ietf.org Subject: 15% off on two watches Date: Tue, 29 Apr 2008 15:13:44 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://makisukadop82.blogspot.com/ From owner-ccamp@ops.ietf.org Tue Apr 29 12:30:40 2008 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 AF0D53A6DF3 for ; Tue, 29 Apr 2008 12:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.661 X-Spam-Level: X-Spam-Status: No, score=0.661 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_DK=1.009, HELO_MISMATCH_DK=1.7, RCVD_IN_DNSWL_LOW=-1, 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 ShyfxheVQNu0 for ; Tue, 29 Apr 2008 12:30:36 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1E6B028C30A for ; Tue, 29 Apr 2008 12:30:36 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JqvLw-0007zN-Ef for ccamp-data@psg.com; Tue, 29 Apr 2008 19:19:00 +0000 Received: from [213.150.41.59] (helo=dkcphmx22.softcom.dk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JqvLZ-0007vu-RT for ccamp@ops.ietf.org; Tue, 29 Apr 2008 19:18:52 +0000 Received: (qmail 32323 invoked by uid 74); 29 Apr 2008 19:18:35 -0000 Received: from mail.acreo.se (217.151.195.216) by dkcphmx22.softcom.dk (envelope-from ) with ESMTP. tag msg.1209496715.561771.30996 (Processed in 0.143797 secs); 29 Apr 2008 19:18:35 -0000 X-SoftScan-Status: clean X-Secure-TLS: Yes, message received through TLS by dkcphmx22.softcom.dk (RC4-MD5) Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by dkcphmx22.softcom.dk over TLS secured channel with ESMTP; Tue, 29 Apr 2008 21:18:35 +0200 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Tue, 29 Apr 2008 21:18:35 +0200 From: Jonas Martensson To: "BRUNGARD, DEBORAH A, ATTLABS" , "ccamp@ops.ietf.org" Date: Tue, 29 Apr 2008 21:16:50 +0200 Subject: RE: Poll for WG Adoption of Two WSON documents Thread-Topic: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAAHnSMM Message-ID: <1EC35EEAF3A9FA439C7D6AE45BF4378702AB4103ED@acreoexc01.ad.acreo.se> References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ccamp@ops.ietf.org Precedence: bulk I support both documents. Regards, Jonas From: owner-ccamp@ops.ietf.org [owner-ccamp@ops.ietf.org] On Behalf Of BRUN= GARD, DEBORAH A, ATTLABS [dbrungard@att.com] Sent: Tuesday, April 29, 2008 5:38 PM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, From Philadelphia, we had good support for adoption of two of the WSON docu= ments as CCAMP working group documents: - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switch= ed-03.txt - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-0= 2.txt Please express your opinions (authors, we welcome your opinion also). Thanks, Adrian and Deborah From owner-ccamp@ops.ietf.org Tue Apr 29 17:21:35 2008 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 20FD23A69E7 for ; Tue, 29 Apr 2008 17:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.196 X-Spam-Level: X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, 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 aQuDIG+EnVMk for ; Tue, 29 Apr 2008 17:21:33 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 919493A6C65 for ; Tue, 29 Apr 2008 17:21:02 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JqzxD-000DJB-CP for ccamp-data@psg.com; Wed, 30 Apr 2008 00:13:47 +0000 Received: from [129.60.39.148] (helo=tama500.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jqzwd-000DEy-Qy for ccamp@ops.ietf.org; Wed, 30 Apr 2008 00:13:26 +0000 Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m3U0DAVl010730 for ; Wed, 30 Apr 2008 09:13:10 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 750C163F4 for ; Wed, 30 Apr 2008 09:13:10 +0900 (JST) Received: from dmailsv1.y.ecl.ntt.co.jp (dmailsv1.y.ecl.ntt.co.jp [129.60.53.14]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 6E95A63ED for ; Wed, 30 Apr 2008 09:13:10 +0900 (JST) Received: from mailsv04.y.ecl.ntt.co.jp by dmailsv1.y.ecl.ntt.co.jp (8.14.2/dmailsv1-2.0) with ESMTP id m3U0DABA017928 for ; Wed, 30 Apr 2008 09:13:10 +0900 (JST) Received: from localhost by mailsv04.y.ecl.ntt.co.jp (8.14.1/Lab-1.7) with ESMTP id m3U0DA0h010796 for ; Wed, 30 Apr 2008 09:13:10 +0900 (JST) Message-Id: <6.0.0.20.2.20080430090849.0636a790@mailsv4.y.ecl.ntt.co.jp> X-Sender: wi002@mailsv4.y.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 6J-Jr3 Date: Wed, 30 Apr 2008 09:16:43 +0900 To: From: Wataru Imajuku Subject: Re: Poll for WG Adoption of Two WSON documents In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd .att.com> References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, Deborah and Adrian Both IDs are very much important and should be WG documents. Best Regards Wataru At 00:38 08/04/30, BRUNGARD, DEBORAH A, ATTLABS wrote: >CCAMP, > >From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: > >- Framework for WSON >http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt > >- Lambda Labels >http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt > >Please express your opinions (authors, we welcome your opinion also). > >Thanks, >Adrian and Deborah ------------------------------------- Wataru Imajuku@NTT Network Innovation Labs TEL: +81-46-859-4315 FAX: +81-46-859-5541 From owner-ccamp@ops.ietf.org Tue Apr 29 18:07:54 2008 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 D1AC13A681E for ; Tue, 29 Apr 2008 18:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 YnnKXY+Oy4TX for ; Tue, 29 Apr 2008 18:07:54 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1B5E83A68E5 for ; Tue, 29 Apr 2008 18:07:53 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jr0gM-000ICs-EH for ccamp-data@psg.com; Wed, 30 Apr 2008 01:00:26 +0000 Received: from [61.144.161.55] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jr0ft-000I9U-4y for ccamp@ops.ietf.org; Wed, 30 Apr 2008 01:00:11 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K0400BRS5FV9Y@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Wed, 30 Apr 2008 08:59:56 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K04007VZ5FV17@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Wed, 30 Apr 2008 08:59:55 +0800 (CST) Received: from l37133 ([10.70.77.61]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K0400FAJ5FVAZ@szxml04-in.huawei.com> for ccamp@ops.ietf.org; Wed, 30 Apr 2008 08:59:55 +0800 (CST) Date: Wed, 30 Apr 2008 08:59:55 +0800 From: Dan Li Subject: Re: Poll for WG Adoption of Two WSON documents To: "BRUNGARD, DEBORAH A, ATTLABS" , ccamp@ops.ietf.org Message-id: <021d01c8aa5d$81351800$3d4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: multipart/alternative; boundary="Boundary_(ID_3XHeaD2Jyd+cm/wXucZ5LQ)" X-Priority: 3 X-MSMail-priority: Normal References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_3XHeaD2Jyd+cm/wXucZ5LQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Yes, I support both IDs. Dan ----- Original Message ----- From: BRUNGARD, DEBORAH A, ATTLABS To: ccamp@ops.ietf.org Sent: Tuesday, April 29, 2008 11:38 PM Subject: Poll for WG Adoption of Two WSON documents CCAMP, From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt Please express your opinions (authors, we welcome your opinion also). Thanks, Adrian and Deborah --Boundary_(ID_3XHeaD2Jyd+cm/wXucZ5LQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Yes, I support both IDs.
 
Dan
 
----- Original Message -----
Sent: Tuesday, April 29, 2008 11:38 PM
Subject: Poll for WG Adoption of Two WSON documents

CCAMP,
 
From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents:
 
- Framework for WSON
 
- Lambda Labels
 
Please express your opinions (authors, we welcome your opinion also).
 
Thanks,
Adrian and Deborah
--Boundary_(ID_3XHeaD2Jyd+cm/wXucZ5LQ)-- From owner-ccamp@ops.ietf.org Tue Apr 29 18:52:14 2008 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 C73573A6BFD for ; Tue, 29 Apr 2008 18:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 DI0QtUkMdHzB for ; Tue, 29 Apr 2008 18:52:08 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E5E8228C371 for ; Tue, 29 Apr 2008 18:52:07 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jr1Pq-00006g-Ch for ccamp-data@psg.com; Wed, 30 Apr 2008 01:47:26 +0000 Received: from [61.144.161.55] (helo=szxga03-in.huawei.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jr1PN-000039-7D for ccamp@ops.ietf.org; Wed, 30 Apr 2008 01:47:11 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K0400B2Q7M89Y@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Wed, 30 Apr 2008 09:46:56 +0800 (CST) Received: from M55527 ([10.111.12.186]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K0400L7W7M7SW@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Wed, 30 Apr 2008 09:46:55 +0800 (CST) Date: Wed, 30 Apr 2008 09:46:55 +0800 From: Mach Chen Subject: Re: Poll for WG Adoption of Two WSON documents To: "BRUNGARD, DEBORAH A, ATTLABS" , "ccamp@ops.ietf.org" Message-id: <200804300946552104092@huawei.com> Organization: Huawei MIME-version: 1.0 X-Mailer: Foxmail 6, 10, 201, 20 [cn] Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi, In favor of both I-Ds. On 2008-04-29, at 23:56:05 BRUNGARD, DEBORAH A, ATTLABS wrote: >CCAMP, > >From Philadelphia, we had good support for adoption of two of the WSON >documents as CCAMP working group documents: > >- Framework for WSON >http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi >tched-03.txt > >- Lambda Labels >http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label >s-02.txt > >Please express your opinions (authors, we welcome your opinion also). > >Thanks, >Adrian and Deborah Best regards, Mach Chen From owner-ccamp@ops.ietf.org Tue Apr 29 19:47:39 2008 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 8C89E3A69D9 for ; Tue, 29 Apr 2008 19:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 tS2QSXWo8zvI for ; Tue, 29 Apr 2008 19:47:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id ADCF43A6CBA for ; Tue, 29 Apr 2008 19:47:38 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jr2IJ-0006OH-6p for ccamp-data@psg.com; Wed, 30 Apr 2008 02:43:43 +0000 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jr2Hl-0006K6-QY for ccamp@ops.ietf.org; Wed, 30 Apr 2008 02:43:24 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id A1CA7EC88D for ; Wed, 30 Apr 2008 11:43:08 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id 5E74AEC88A for ; Wed, 30 Apr 2008 11:43:08 +0900 (JST) Received: from [IPv6:::1] (unknown [IPv6:2001:200:601:2450:b998:6428:eac6:79ea]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id A2D2C578111 for ; Wed, 30 Apr 2008 11:43:06 +0900 (JST) Message-ID: <4817DCBE.6010607@cn.kddilabs.jp> Date: Wed, 30 Apr 2008 11:43:10 +0900 From: "Ogaki, Kenichi" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi All, I support both. Regards, Kenichi BRUNGARD, DEBORAH A, ATTLABS wrote: >CCAMP, > >>From Philadelphia, we had good support for adoption of two of the WSON >documents as CCAMP working group documents: > >- Framework for WSON >http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi >tched-03.txt > >- Lambda Labels >http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label >s-02.txt > >Please express your opinions (authors, we welcome your opinion also). > >Thanks, >Adrian and Deborah > > > From owner-ccamp@ops.ietf.org Tue Apr 29 21:18:43 2008 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 B9E803A68C3 for ; Tue, 29 Apr 2008 21:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 H-ZKkv8vCOAC for ; Tue, 29 Apr 2008 21:18:43 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D9F0C3A68B7 for ; Tue, 29 Apr 2008 21:18:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jr3ge-000FCt-41 for ccamp-data@psg.com; Wed, 30 Apr 2008 04:12:56 +0000 Received: from [2001:2f8:29::2] (helo=ns1.nict.go.jp) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jr3g6-000F9m-LE for ccamp@ops.ietf.org; Wed, 30 Apr 2008 04:12:41 +0000 Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns1.nict.go.jp with ESMTP id m3U4CHCd002727; Wed, 30 Apr 2008 13:12:17 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id m3U4CHCA007014; Wed, 30 Apr 2008 13:12:17 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id m3U4CHsu007011; Wed, 30 Apr 2008 13:12:17 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by localhost.nict.go.jp (Postfix) with ESMTP id EA1876E3E; Wed, 30 Apr 2008 13:12:16 +0900 (JST) Received: from [127.0.0.1] (ssh2.nict.go.jp [133.243.3.50]) by mail2.nict.go.jp (Postfix) with ESMTP id CB5676E39; Wed, 30 Apr 2008 13:12:16 +0900 (JST) Message-ID: <4817F1A2.60105@nict.go.jp> Date: Wed, 30 Apr 2008 13:12:18 +0900 From: Sugang XU User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" Cc: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi Adrian and Deborah, I support both for WG docs. Best Regards Sugang BRUNGARD, DEBORAH A, ATTLABS wrote: > CCAMP, > >>From Philadelphia, we had good support for adoption of two of the WSON > documents as CCAMP working group documents: > > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi > tched-03.txt > > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label > s-02.txt > > Please express your opinions (authors, we welcome your opinion also). > > Thanks, > Adrian and Deborah > From c.manganiello@smponline.it Wed Apr 30 00:30:14 2008 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 F16343A67FF; Wed, 30 Apr 2008 00:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -63.049 X-Spam-Level: X-Spam-Status: No, score=-63.049 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SARE_SPEC_REPLICA_OBFU=1.812, TVD_RCVD_IP=1.931, 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 nt2ytu++w+R2; Wed, 30 Apr 2008 00:30:13 -0700 (PDT) Received: from 200-158-229-218.dsl.telesp.net.br (200-158-229-218.dsl.telesp.net.br [200.158.229.218]) by core3.amsl.com (Postfix) with SMTP id 6346428C11B; Wed, 30 Apr 2008 00:30:00 -0700 (PDT) X-Originating-IP: 42.252.180.137 by smtp.200.158.229.218; Wed, 30 Apr 2008 03:30:06 -0500 Message-ID: From: "Bobby Gold" Reply-To: "Bobby Gold" To: call-home-bounces@ietf.org Subject: You can save 80% Date: Wed, 30 Apr 2008 03:30:06 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080429-1, 29/04/2008), Outbound message X-Antivirus-Status: Clean A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://zamubocunum43.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://zamubocunum43.blogspot.com/ From owner-ccamp@ops.ietf.org Wed Apr 30 00:33:06 2008 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 8FCC93A6A6F for ; Wed, 30 Apr 2008 00:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 NYduIO39+MxT for ; Wed, 30 Apr 2008 00:33:05 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5C2A03A6BB9 for ; Wed, 30 Apr 2008 00:33:05 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jr6fs-0006z6-AO for ccamp-data@psg.com; Wed, 30 Apr 2008 07:24:20 +0000 Received: from [193.180.251.62] (helo=mailgw4.ericsson.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jr6fT-0006vu-8y for ccamp@ops.ietf.org; Wed, 30 Apr 2008 07:24:10 +0000 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AC6F9214DF for ; Wed, 30 Apr 2008 09:23:52 +0200 (CEST) X-AuditID: c1b4fb3e-af19abb000004ec0-c1-48181e885495 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8AA0E206A2 for ; Wed, 30 Apr 2008 09:23:52 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 09:23:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA93.24161D8C" Subject: RE: Poll for WG Adoption of Two WSON documents Date: Wed, 30 Apr 2008 09:23:51 +0200 Message-ID: <56D2F550769FAA4CA70D5B2EB8419F14032F04ED@esealmw118.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAAg+kWA From: "Howard Green" To: X-OriginalArrivalTime: 30 Apr 2008 07:23:52.0277 (UTC) FILETIME=[241BB850:01C8AA93] X-Brightmail-Tracker: AAAAAA== Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA93.24161D8C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the adoption of both these drafts Howard ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: 29 April 2008 17:39 To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, =20 From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label s-02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8AA93.24161D8C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support the adoption of both these=20 drafts
Howard
From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: 29 April 2008 17:39
To:=20 ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON=20 documents

CCAMP,
 
From = Philadelphia,=20 we had good support for adoption of two of the WSON documents as CCAMP = working=20 group documents:
 
- = Framework for=20 WSON
http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-03.txt
 
- = Lambda=20 Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm= pls-lambda-labels-02.txt
 
Please = express your=20 opinions (authors, we welcome your opinion also).
 
Thanks,
Adrian = and=20 Deborah
------_=_NextPart_001_01C8AA93.24161D8C-- From owner-ccamp@ops.ietf.org Wed Apr 30 00:41:42 2008 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 CE7873A6A85 for ; Wed, 30 Apr 2008 00:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IT=0.635, 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 tGG8Dqilza77 for ; Wed, 30 Apr 2008 00:41:42 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 065BD3A6958 for ; Wed, 30 Apr 2008 00:41:42 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jr6sF-0008IX-1W for ccamp-data@psg.com; Wed, 30 Apr 2008 07:37:07 +0000 Received: from [195.250.30.2] (helo=chef.nextworks.it) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jr6rS-0008Cy-WD for ccamp@ops.ietf.org; Wed, 30 Apr 2008 07:36:36 +0000 Received: from [131.114.33.165] (unknown [131.114.33.165]) by chef.nextworks.it (Postfix) with ESMTP id 064A27BD51; Wed, 30 Apr 2008 08:46:38 +0200 (CEST) Message-ID: <4818216A.3080805@cpr.it> Date: Wed, 30 Apr 2008 09:36:10 +0200 From: Gino Carrozzo User-Agent: Thunderbird 2.0.0.5 (X11/20070730) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" CC: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk Support for both br Gino BRUNGARD, DEBORAH A, ATTLABS wrote: > CCAMP, > >>From Philadelphia, we had good support for adoption of two of the WSON > documents as CCAMP working group documents: > > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi > tched-03.txt > > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label > s-02.txt > > Please express your opinions (authors, we welcome your opinion also). > > Thanks, > Adrian and Deborah > From owner-ccamp@ops.ietf.org Wed Apr 30 01:22:09 2008 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 282483A6D83 for ; Wed, 30 Apr 2008 01:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 gJ0enlE8v+AR for ; Wed, 30 Apr 2008 01:22:04 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D5A183A6D7F for ; Wed, 30 Apr 2008 01:21:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jr7TQ-000Csn-6I for ccamp-data@psg.com; Wed, 30 Apr 2008 08:15:32 +0000 Received: from [2001:200:601:12:230:48ff:fe22:3a84] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jr7Sx-000CqY-4x for ccamp@ops.ietf.org; Wed, 30 Apr 2008 08:15:17 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 0D6A2EC85D; Wed, 30 Apr 2008 17:14:59 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id BE7B8EC83E; Wed, 30 Apr 2008 17:14:58 +0900 (JST) Received: from [127.0.0.1] (dhcp195.wlan.kddilabs.jp [172.19.110.195]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 3E225578111; Wed, 30 Apr 2008 17:14:56 +0900 (JST) Message-ID: <48182A80.1050002@kddilabs.jp> Date: Wed, 30 Apr 2008 17:14:56 +0900 From: Tomohiro Otani User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" Cc: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new Sender: owner-ccamp@ops.ietf.org Precedence: bulk Hi all, I support both as CCAMP WG documents. Regards, Tomo BRUNGARD, DEBORAH A, ATTLABS =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D= =E3=81=BE=E3=81=97=E3=81=9F: > CCAMP, > From Philadelphia, we had good support for adoption of two of the WSON=20 > documents as CCAMP working group documents: > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-sw= itched-03.txt > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labe= ls-02.txt > Please express your opinions (authors, we welcome your opinion also). > Thanks, > Adrian and Deborah From owner-ccamp@ops.ietf.org Wed Apr 30 03:28:17 2008 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 152863A6D5F for ; Wed, 30 Apr 2008 03:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_MESSAGE=0.001, 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 M8FetBSDey0E for ; Wed, 30 Apr 2008 03:28:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8780C3A6819 for ; Wed, 30 Apr 2008 03:28:13 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Jr9RN-0003Up-SY for ccamp-data@psg.com; Wed, 30 Apr 2008 10:21:33 +0000 Received: from [212.23.3.142] (helo=rutherford.zen.co.uk) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Jr9R2-0003SY-9b for ccamp@ops.ietf.org; Wed, 30 Apr 2008 10:21:23 +0000 Received: from [88.96.235.142] (helo=aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.63) (envelope-from ) id 1Jr9R1-00083R-0z for ccamp@ops.ietf.org; Wed, 30 Apr 2008 10:21:11 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Poll for WG Adoption of Two WSON documents Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AAAB.E9FF33DF" Date: Wed, 30 Apr 2008 11:20:09 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Poll for WG Adoption of Two WSON documents thread-index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAAnCOdg References: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> From: "Daniel King" To: X-Originating-Rutherford-IP: [88.96.235.142] Sender: owner-ccamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AAAB.E9FF33DF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello CCAMP,=20 =20 I would like to show my support for both drafts. =20 I should also disclose that I am a contributor to "draft-bernstein-ccamp-wavelength-switched-03.txt". =20 Thanks, Dan =20 From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: 29 April 2008 16:39 To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents =20 CCAMP, =20 From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label s-02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8AAAB.E9FF33DF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello CCAMP,

 

I would like to show my support for both = drafts.

 

I should also disclose that I am a contributor to = “draft-bernstein-ccamp-wavelength-switched-03.txt”.

 

Thanks,
Dan

 

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A, ATTLABS
Sent: 29 April 2008 16:39
To: ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON = documents

 

CCAMP,=

 

From Philadelphia, we had good support for adoption of two of the WSON = documents as CCAMP working group documents:

 

- Framework for WSON

 

- Lambda Labels

 

Please express your opinions (authors, we welcome your opinion = also).

 

Thanks,

Adrian and Deborah

------_=_NextPart_001_01C8AAAB.E9FF33DF-- From cacca@rnet.it Wed Apr 30 13:38:30 2008 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 D895D3A694A; Wed, 30 Apr 2008 13:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -78.165 X-Spam-Level: X-Spam-Status: No, score=-78.165 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, RCVD_IN_PBL=0.905, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 wQT1IKADCcUF; Wed, 30 Apr 2008 13:38:30 -0700 (PDT) Received: from 216.138.216.201.intelnet.net.gt (unknown [201.216.138.216]) by core3.amsl.com (Postfix) with SMTP id A0BBB3A6D1C; Wed, 30 Apr 2008 13:37:53 -0700 (PDT) X-Originating-IP: 62.8.199.182 by smtp.201.216.138.216; Wed, 30 Apr 2008 16:37:58 -0500 Message-ID: From: "Lynette Nunez" Reply-To: "Lynette Nunez" To: call-home-bounces@ietf.org Subject: Get 15% off these watches! Date: Wed, 30 Apr 2008 16:37:58 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Longines watches have been around for longer than you or I are old. And they have adorned the wrists of the rich and famous for the same length of time. Prestige Replicas plans to change that, by offering you a replica watch that is exactly the same in every detail, except for the price. http://nidozibywic52.blogspot.com/ Prestige Replicas now offers a 15% discount on the purchase of two items because of the site redesign, and this offer won't last. Neither will their new 2008 models! Having the most expensive Longines watches at the best prices, and ensuring the most expedite shipping on the web make this online shop the best choice. No need to wear that old Timex to that upcoming event, when Prestige Replicas can put you into a Longines replica for about the same cost in no time! http://nidozibywic52.blogspot.com/ Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Apr 2008 10:23:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Poll for WG Adoption of Two WSON documents Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AAAB.E9FF33DF" Date: Wed, 30 Apr 2008 11:20:09 +0100 Message-ID: Thread-Topic: Poll for WG Adoption of Two WSON documents thread-index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAAnCOdg From: "Daniel King" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AAAB.E9FF33DF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello CCAMP,=20 =20 I would like to show my support for both drafts. =20 I should also disclose that I am a contributor to "draft-bernstein-ccamp-wavelength-switched-03.txt". =20 Thanks, Dan =20 From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: 29 April 2008 16:39 To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents =20 CCAMP, =20 >From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label s-02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8AAAB.E9FF33DF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello CCAMP,

 

I would like to show my support for both = drafts.

 

I should also disclose that I am a contributor to = “draft-bernstein-ccamp-wavelength-switched-03.txt”.

 

Thanks,
Dan

 

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A, ATTLABS
Sent: 29 April 2008 16:39
To: ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON = documents

 

CCAMP,=

 

From Philadelphia, we had good support for adoption of two of the WSON = documents as CCAMP working group documents:

 

- Framework for WSON

 

- Lambda Labels

 

Please express your opinions (authors, we welcome your opinion = also).

 

Thanks,

Adrian and Deborah

------_=_NextPart_001_01C8AAAB.E9FF33DF-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Apr 2008 08:16:31 +0000 Message-ID: <48182A80.1050002@kddilabs.jp> Date: Wed, 30 Apr 2008 17:14:56 +0900 From: Tomohiro Otani User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" Cc: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, I support both as CCAMP WG documents. Regards, Tomo BRUNGARD, DEBORAH A, ATTLABS =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D= =E3=81=BE=E3=81=97=E3=81=9F: > CCAMP, > From Philadelphia, we had good support for adoption of two of the WSON=20 > documents as CCAMP working group documents: > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-sw= itched-03.txt > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labe= ls-02.txt > Please express your opinions (authors, we welcome your opinion also). > Thanks, > Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Apr 2008 07:37:42 +0000 Message-ID: <4818216A.3080805@cpr.it> Date: Wed, 30 Apr 2008 09:36:10 +0200 From: Gino Carrozzo User-Agent: Thunderbird 2.0.0.5 (X11/20070730) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" CC: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Support for both br Gino BRUNGARD, DEBORAH A, ATTLABS wrote: > CCAMP, > >>From Philadelphia, we had good support for adoption of two of the WSON > documents as CCAMP working group documents: > > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi > tched-03.txt > > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label > s-02.txt > > Please express your opinions (authors, we welcome your opinion also). > > Thanks, > Adrian and Deborah > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Apr 2008 07:26:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA93.24161D8C" Subject: RE: Poll for WG Adoption of Two WSON documents Date: Wed, 30 Apr 2008 09:23:51 +0200 Message-ID: <56D2F550769FAA4CA70D5B2EB8419F14032F04ED@esealmw118.eemea.ericsson.se> Thread-Topic: RE: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAAg+kWA From: "Howard Green" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA93.24161D8C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the adoption of both these drafts Howard ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: 29 April 2008 17:39 To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, =20 >From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label s-02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8AA93.24161D8C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support the adoption of both these=20 drafts
Howard
From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: 29 April 2008 17:39
To:=20 ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON=20 documents

CCAMP,
 
From = Philadelphia,=20 we had good support for adoption of two of the WSON documents as CCAMP = working=20 group documents:
 
- = Framework for=20 WSON
http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-03.txt
 
- = Lambda=20 Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm= pls-lambda-labels-02.txt
 
Please = express your=20 opinions (authors, we welcome your opinion also).
 
Thanks,
Adrian = and=20 Deborah
------_=_NextPart_001_01C8AA93.24161D8C-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Apr 2008 04:15:01 +0000 Message-ID: <4817F1A2.60105@nict.go.jp> Date: Wed, 30 Apr 2008 13:12:18 +0900 From: Sugang XU User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" Cc: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian and Deborah, I support both for WG docs. Best Regards Sugang BRUNGARD, DEBORAH A, ATTLABS wrote: > CCAMP, > >>From Philadelphia, we had good support for adoption of two of the WSON > documents as CCAMP working group documents: > > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi > tched-03.txt > > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label > s-02.txt > > Please express your opinions (authors, we welcome your opinion also). > > Thanks, > Adrian and Deborah > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Apr 2008 02:44:35 +0000 Message-ID: <4817DCBE.6010607@cn.kddilabs.jp> Date: Wed, 30 Apr 2008 11:43:10 +0900 From: "Ogaki, Kenichi" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All, I support both. Regards, Kenichi BRUNGARD, DEBORAH A, ATTLABS wrote: >CCAMP, > >>From Philadelphia, we had good support for adoption of two of the WSON >documents as CCAMP working group documents: > >- Framework for WSON >http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi >tched-03.txt > >- Lambda Labels >http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label >s-02.txt > >Please express your opinions (authors, we welcome your opinion also). > >Thanks, >Adrian and Deborah > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Apr 2008 01:48:42 +0000 Date: Wed, 30 Apr 2008 09:46:55 +0800 From: Mach Chen Subject: Re: Poll for WG Adoption of Two WSON documents To: "BRUNGARD, DEBORAH A, ATTLABS" , "ccamp@ops.ietf.org" Message-id: <200804300946552104092@huawei.com> Organization: Huawei MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, In favor of both I-Ds. On 2008-04-29, at 23:56:05 BRUNGARD, DEBORAH A, ATTLABS wrote: >CCAMP, > >From Philadelphia, we had good support for adoption of two of the WSON >documents as CCAMP working group documents: > >- Framework for WSON >http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi >tched-03.txt > >- Lambda Labels >http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label >s-02.txt > >Please express your opinions (authors, we welcome your opinion also). > >Thanks, >Adrian and Deborah Best regards, Mach Chen Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Apr 2008 01:01:24 +0000 Date: Wed, 30 Apr 2008 08:59:55 +0800 From: Dan Li Subject: Re: Poll for WG Adoption of Two WSON documents To: "BRUNGARD, DEBORAH A, ATTLABS" , ccamp@ops.ietf.org Message-id: <021d01c8aa5d$81351800$3d4d460a@china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_3XHeaD2Jyd+cm/wXucZ5LQ)" This is a multi-part message in MIME format. --Boundary_(ID_3XHeaD2Jyd+cm/wXucZ5LQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Yes, I support both IDs. Dan ----- Original Message ----- From: BRUNGARD, DEBORAH A, ATTLABS To: ccamp@ops.ietf.org Sent: Tuesday, April 29, 2008 11:38 PM Subject: Poll for WG Adoption of Two WSON documents CCAMP, From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt Please express your opinions (authors, we welcome your opinion also). Thanks, Adrian and Deborah --Boundary_(ID_3XHeaD2Jyd+cm/wXucZ5LQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Yes, I support both IDs.
 
Dan
 
----- Original Message -----
Sent: Tuesday, April 29, 2008 11:38 PM
Subject: Poll for WG Adoption of Two WSON documents

CCAMP,
 
From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents:
 
- Framework for WSON
 
- Lambda Labels
 
Please express your opinions (authors, we welcome your opinion also).
 
Thanks,
Adrian and Deborah
--Boundary_(ID_3XHeaD2Jyd+cm/wXucZ5LQ)-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 30 Apr 2008 00:16:20 +0000 Message-Id: <6.0.0.20.2.20080430090849.0636a790@mailsv4.y.ecl.ntt.co.jp> Date: Wed, 30 Apr 2008 09:16:43 +0900 To: From: Wataru Imajuku Subject: Re: Poll for WG Adoption of Two WSON documents Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Deborah and Adrian Both IDs are very much important and should be WG documents. Best Regards Wataru At 00:38 08/04/30, BRUNGARD, DEBORAH A, ATTLABS wrote: >CCAMP, > >From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: > >- Framework for WSON >http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt > >- Lambda Labels >http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt > >Please express your opinions (authors, we welcome your opinion also). > >Thanks, >Adrian and Deborah ------------------------------------- Wataru Imajuku@NTT Network Innovation Labs TEL: +81-46-859-4315 FAX: +81-46-859-5541 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2008 19:20:57 +0000 From: Jonas Martensson To: "BRUNGARD, DEBORAH A, ATTLABS" , "ccamp@ops.ietf.org" Date: Tue, 29 Apr 2008 21:16:50 +0200 Subject: RE: Poll for WG Adoption of Two WSON documents Thread-Topic: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAAHnSMM Message-ID: <1EC35EEAF3A9FA439C7D6AE45BF4378702AB4103ED@acreoexc01.ad.acreo.se> 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 support both documents. Regards, Jonas From: owner-ccamp@ops.ietf.org [owner-ccamp@ops.ietf.org] On Behalf Of BRUN= GARD, DEBORAH A, ATTLABS [dbrungard@att.com] Sent: Tuesday, April 29, 2008 5:38 PM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, >From Philadelphia, we had good support for adoption of two of the WSON docu= ments as CCAMP working group documents: - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switch= ed-03.txt - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-0= 2.txt Please express your opinions (authors, we welcome your opinion also). Thanks, Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2008 18:13:16 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA24.657A4588" Subject: RE: Poll for WG Adoption of Two WSON documents Date: Tue, 29 Apr 2008 13:11:07 -0500 Message-ID: Thread-Topic: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAAFSn2A From: "Bardalai, Snigdho" To: "BRUNGARD, DEBORAH A, ATTLABS" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA24.657A4588 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In favor of both IDs =20 Snigdho -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On = Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, April 29, 2008 10:39 AM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, =20 >From Philadelphia, we had good support for adoption of two of the WSON = documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit= ched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels= -02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8AA24.657A4588 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In=20 favor of both IDs
 
Snigdho
-----Original Message-----
From: = owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org]On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Tuesday, April 29, 2008 10:39 AM
To: = ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON = documents

CCAMP,
 
From = Philadelphia,=20 we had good support for adoption of two of the WSON documents as CCAMP = working=20 group documents:
 
- = Framework for=20 WSON
http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-03.txt
 
- = Lambda=20 Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm= pls-lambda-labels-02.txt
 
Please express=20 your opinions (authors, we welcome your opinion = also).
 
Thanks,
Adrian and=20 Deborah
------_=_NextPart_001_01C8AA24.657A4588-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2008 17:26:01 +0000 Reply-To: From: "Itaru Nishioka" To: "'BRUNGARD, DEBORAH A, ATTLABS'" , Subject: RE: Poll for WG Adoption of Two WSON documents Date: Wed, 30 Apr 2008 02:24:40 +0900 Organization: nec Message-Id: <003101c8aa1d$e97631f0$61ef3e0a@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01C8AA69.595DD9F0" Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAADqTAg This is a multi-part message in MIME format. ------=_NextPart_000_0032_01C8AA69.595DD9F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Support both as WG drafts. Itaru. _____ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Wednesday, April 30, 2008 12:39 AM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, >From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt Please express your opinions (authors, we welcome your opinion also). Thanks, Adrian and Deborah ------=_NextPart_000_0032_01C8AA69.595DD9F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Support both as WG drafts.
 
 
Itaru.

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, = DEBORAH A,=20 ATTLABS
Sent: Wednesday, April 30, 2008 12:39 = AM
To:=20 ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON = documents

CCAMP,
 
From = Philadelphia,=20 we had good support for adoption of two of the WSON documents as CCAMP = working=20 group documents:
 
- = Framework for=20 WSON
http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-03.txt
 
- = Lambda=20 Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm= pls-lambda-labels-02.txt
 
Please express=20 your opinions (authors, we welcome your opinion = also).
 
Thanks,
Adrian and=20 Deborah
------=_NextPart_000_0032_01C8AA69.595DD9F0-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2008 16:56:54 +0000 Date: Tue, 29 Apr 2008 11:56:00 -0500 From: Young Lee Subject: RE: Poll for WG Adoption of Two WSON documents To: "'BRUNGARD, DEBORAH A, ATTLABS'" , ccamp@ops.ietf.org Message-id: <004001c8aa19$e6f61390$6c0c7c0a@china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_LrpXkGu+nntqEghXeWEG7w)" Thread-index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAACqL4g This is a multi-part message in MIME format. --Boundary_(ID_LrpXkGu+nntqEghXeWEG7w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I support both as WG drafts. Young _____ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, April 29, 2008 10:39 AM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, >From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switche d-03.txt - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02 .txt Please express your opinions (authors, we welcome your opinion also). Thanks, Adrian and Deborah --Boundary_(ID_LrpXkGu+nntqEghXeWEG7w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I support both as WG drafts.

 

Young

 

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, April 29, 2008 10:39 AM
To: ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON documents

 

CCAMP,

 

From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents:

 

- Framework for WSON

 

- Lambda Labels

 

Please express your opinions (authors, we welcome your opinion also).

 

Thanks,

Adrian and Deborah

--Boundary_(ID_LrpXkGu+nntqEghXeWEG7w)-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2008 16:49:36 +0000 From: Anders Gavler To: "BRUNGARD, DEBORAH A, ATTLABS" , "ccamp@ops.ietf.org" Date: Tue, 29 Apr 2008 18:47:29 +0200 Subject: RE: Poll for WG Adoption of Two WSON documents Thread-Topic: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAACViuA Message-ID: <73B74934786FBB4F951B5F99724CEB6002BA8CE0CC@acreoexc01.ad.acreo.se> Accept-Language: sv-SE, en-US Content-Language: en-US acceptlanguage: sv-SE, en-US Content-Type: multipart/alternative; boundary="_000_73B74934786FBB4F951B5F99724CEB6002BA8CE0CCacreoexc01ada_" MIME-Version: 1.0 --_000_73B74934786FBB4F951B5F99724CEB6002BA8CE0CCacreoexc01ada_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Supporting both as wg documents. /Anders ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf = Of BRUNGARD, DEBORAH A, ATTLABS Sent: den 29 april 2008 17:39 To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, >From Philadelphia, we had good support for adoption of two of the WSON docu= ments as CCAMP working group documents: - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switch= ed-03.txt - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-0= 2.txt Please express your opinions (authors, we welcome your opinion also). Thanks, Adrian and Deborah --_000_73B74934786FBB4F951B5F99724CEB6002BA8CE0CCacreoexc01ada_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Supporting both as = wg documents.

 

/Anders<= /span>

 

From:= owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATT= LABS
Sent: den 29 april 2008 17:3= 9
To: ccamp@ops.ietf.org
Subject: Poll for WG Adoptio= n of Two WSON documents

 

CCAMP,

 

From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents:=

 

- Framework for WSON

 

- Lambda Labels

 

Please express your opinions (authors, we welcome your opinion also).

 

Thanks,

Adrian and Deborah

--_000_73B74934786FBB4F951B5F99724CEB6002BA8CE0CCacreoexc01ada_-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2008 16:28:34 +0000 Date: Tue, 29 Apr 2008 11:26:57 -0500 From: Linda Dunbar Subject: RE: Poll for WG Adoption of Two WSON documents To: "'BRUNGARD, DEBORAH A, ATTLABS'" , ccamp@ops.ietf.org Message-id: <003701c8aa15$d87090b0$530c7c0a@china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_49jiLnoVjuv7myoIcxekEg)" Thread-index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAABq6Bg This is a multi-part message in MIME format. --Boundary_(ID_49jiLnoVjuv7myoIcxekEg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I support both. Linda Dunbar _____ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, April 29, 2008 10:39 AM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, >From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switche d-03.txt - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02 .txt Please express your opinions (authors, we welcome your opinion also). Thanks, Adrian and Deborah --Boundary_(ID_49jiLnoVjuv7myoIcxekEg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I support both.

 

Linda Dunbar

 

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, April 29, 2008 10:39 AM
To: ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON documents

 

CCAMP,

 

From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents:

 

- Framework for WSON

 

- Lambda Labels

 

Please express your opinions (authors, we welcome your opinion also).

 

Thanks,

Adrian and Deborah

--Boundary_(ID_49jiLnoVjuv7myoIcxekEg)-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2008 16:23:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA15.386621E8" Subject: RE: Poll for WG Adoption of Two WSON documents Date: Tue, 29 Apr 2008 12:22:29 -0400 Message-ID: <23F9E58A916663488B3D12D1FE1A999F013622ED@mdmxm03.ciena.com> Thread-topic: Poll for WG Adoption of Two WSON documents Thread-index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAABhDaw From: "Ong, Lyndon" To: "BRUNGARD, DEBORAH A, ATTLABS" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA15.386621E8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support both as WG drafts. =20 Lyndon ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: Tuesday, April 29, 2008 8:39 AM To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents CCAMP, =20 >From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label s-02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8AA15.386621E8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support both as WG = drafts.
 
Lyndon

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH = A,=20 ATTLABS
Sent: Tuesday, April 29, 2008 8:39 AM
To:=20 ccamp@ops.ietf.org
Subject: Poll for WG Adoption of Two WSON=20 documents

CCAMP,
 
From = Philadelphia,=20 we had good support for adoption of two of the WSON documents as CCAMP = working=20 group documents:
 
- = Framework for=20 WSON
http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-03.txt
 
- = Lambda=20 Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm= pls-lambda-labels-02.txt
 
Please = express your=20 opinions (authors, we welcome your opinion also).
 
Thanks,
Adrian = and=20 Deborah
------_=_NextPart_001_01C8AA15.386621E8-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2008 16:19:36 +0000 Message-ID: <48174A58.9080108@grotto-networking.com> Date: Tue, 29 Apr 2008 09:18:32 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "BRUNGARD, DEBORAH A, ATTLABS" CC: ccamp@ops.ietf.org Subject: Re: Poll for WG Adoption of Two WSON documents Content-Type: multipart/alternative; boundary="------------030601000304010609010808" This is a multi-part message in MIME format. --------------030601000304010609010808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi WG chairs, Very much in favor of both becoming WG documents. Regards Greg B. BRUNGARD, DEBORAH A, ATTLABS wrote: > CCAMP, > > From Philadelphia, we had good support for adoption of two of the WSON > documents as CCAMP working group documents: > > - Framework for WSON > http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-03.txt > > - Lambda Labels > http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels-02.txt > > Please express your opinions (authors, we welcome your opinion also). > > Thanks, > Adrian and Deborah -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------030601000304010609010808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi WG chairs,  Very much in favor of both becoming WG documents.

Regards

Greg B.

BRUNGARD, DEBORAH A, ATTLABS wrote:
CCAMP,
 
From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents:
 
- Framework for WSON
 
- Lambda Labels
 
Please express your opinions (authors, we welcome your opinion also).
 
Thanks,
Adrian and Deborah

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------030601000304010609010808-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2008 16:14:34 +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: Poll for WG Adoption of Two WSON documents Date: Tue, 29 Apr 2008 18:11:46 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02605875792@ftrdmel2> Thread-Topic: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAAA4vGw From: To: Hi Deborah. I support both for WG docs. Cheers, Julien ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS CCAMP, =20 >From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label s-02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2008 16:09:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA13.48B57400" Subject: RE: Poll for WG Adoption of Two WSON documents Date: Tue, 29 Apr 2008 18:08:28 +0200 Message-ID: <0428AC48A879ED46A94F39D5665DF684014F0E83@esealmw110.eemea.ericsson.se> Thread-Topic: Poll for WG Adoption of Two WSON documents thread-index: AciqDx8YY3asg+WqQXCtnIzwaaVPqAABA77w From: "Diego Caviglia" To: "BRUNGARD, DEBORAH A, ATTLABS" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA13.48B57400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Deborah, Yes to all. =20 I'm a contributor/author of both. =20 BR =20 Diego =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of BRUNGARD, DEBORAH A, ATTLABS Sent: marted=EC 29 aprile 2008 17.39 To: ccamp@ops.ietf.org Subject: Poll for WG Adoption of Two WSON documents =20 CCAMP, =20 >From Philadelphia, we had good support for adoption of two of the WSON = documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swit= ched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-labels= -02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8AA13.48B57400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Deborah,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Yes to all.

 

I’m a contributor/author of = both.

 

BR

 

Diego

 

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of BRUNGARD, DEBORAH A, = ATTLABS
Sent: marted=EC 29 aprile = 2008 17.39
To: = ccamp@ops.ietf.org
Subject: Poll for WG = Adoption of Two WSON documents

 

CCAMP,

 

From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP = working group documents:

 

- Framework for WSON

 

- Lambda Labels

 

Please express your opinions (authors, we welcome = your opinion also).

 

Thanks,

Adrian and Deborah

------_=_NextPart_001_01C8AA13.48B57400-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2008 16:04:04 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt Message-Id: <20080429160001.7493C3A6C7A@core3.amsl.com> Date: Tue, 29 Apr 2008 09:00:01 -0700 (PDT) --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 : GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) Author(s) : L. Berger, et al. Filename : draft-ietf-ccamp-asymm-bw-bidir-lsps-01.txt Pages : 14 Date : 2008-04-29 This document defines a method for the support of GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original RSVP model for the transport of traffic related parameters. The procedures described in this document are experimental. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-asymm-bw-bidir-lsps-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-asymm-bw-bidir-lsps-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-29085105.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 29 Apr 2008 15:55:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8AA0F.1F7ABC40" Subject: Poll for WG Adoption of Two WSON documents Date: Tue, 29 Apr 2008 10:38:50 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF11005501@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Poll for WG Adoption of Two WSON documents Thread-Index: AciqDx8YY3asg+WqQXCtnIzwaaVPqA== From: "BRUNGARD, DEBORAH A, ATTLABS" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8AA0F.1F7ABC40 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable CCAMP, =20 >From Philadelphia, we had good support for adoption of two of the WSON documents as CCAMP working group documents: =20 - Framework for WSON http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-swi tched-03.txt =20 - Lambda Labels http://www.ietf.org/internet-drafts/draft-otani-ccamp-gmpls-lambda-label s-02.txt =20 Please express your opinions (authors, we welcome your opinion also). =20 Thanks, Adrian and Deborah ------_=_NextPart_001_01C8AA0F.1F7ABC40 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
CCAMP,
 
From = Philadelphia,=20 we had good support for adoption of two of the WSON documents as CCAMP = working=20 group documents:
 
- = Framework for=20 WSON
http://www.ietf.org/internet-drafts/draft-bernstein-= ccamp-wavelength-switched-03.txt
 
- = Lambda=20 Labels
http://www.ietf.org/internet-drafts/draft-otani-ccamp-gm= pls-lambda-labels-02.txt
 
Please = express your=20 opinions (authors, we welcome your opinion also).
 
Thanks,
Adrian = and=20 Deborah
------_=_NextPart_001_01C8AA0F.1F7ABC40-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 28 Apr 2008 21:31:09 +0000 Message-ID: <00c801c8a976$c141a900$0400a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Working group last calls complete Date: Mon, 28 Apr 2008 22:27:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Hi, We completed the last calls on draft-ietf-ccamp-rfc4420bis-02.txt and draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt As I see it, there is no need for an update to draft-ietf-ccamp-rfc4420bis-02.txt. Lou has agreed the necessary changes to draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt so we just need to see a revised version and we can proceed. As I am an author of one of these I-Ds, Deborah will do the document shepherding. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 27 Apr 2008 12:28:09 +0000 Message-ID: <06d401c8a861$c3127540$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Thoughts on draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt Date: Sun, 27 Apr 2008 13:24:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Here are some thoughts on your draft. Cheers, Adrian === Title/document name You have the broad title "GMPLS control of Ethernet" yet the document is named draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt. I think that, as per the Abstract, you are limiting yourselves to 802.1Qay, and that is fine. So you should retitle the document "GMPLS Control of 802.1Qay Ethernet Networks" or something like that. === Author list Before this goes to become an RFC you will have to reduse the front page listing to no more than 4 names. I suggest that you do this by placing only the editors on the front page, but continuing to list all of the authors in the "Authors' Addresses" section. === Abstract s/the standard IEEE data/the standard IEEE data plane/ === Document History I think you could delete this now. Or move it to an Appendix if it is important to you. === Section 1 s/by a another/by another/ s/aligned with GMPLS/aligned with the GMPLS/ s/plane and the PBB-TE forwarding/plane and PBB-TE forwarding/ === You might add a sentence or two to the Introduction explaining why GMPLS is relevant. Something like... Generalized MPLS (GMPLS) [RFC3945] is a family of control plane protocols designed to operate in connection oriented and traffic engineering transport networks. GMPLS is applicable to a range of network technologies including Layer 2 Switching capable networks (L2SC). === Section 1 You have: Appendix A summarized the rational for this data plane technology until the IEEE specification is more mature. It is your intention that Appendix A will be removed becuase 802.1Qay explains the facts in enough detail? I would support that. We do not need to redocument IEEE work. Do you think that the work in IEEE is there yet? === Section 2 s/Ethernet Label switched Path/Ethernet Label Switched Path/ === Section 2.1 ESP: You have "between two or more CBPs" People will understand "between two CBPs" but may need help to understand "more". s/Ports(CBPs)/Ports (CBPs)/ s/(MSTI)(A set/(MSTI). (A set/ s/of MSTIs)./of MSTIs.)/ s/an GMPLS/a GMPLS/ === Section 2.1 PBB-TE Region Not sure I like this term. RFC 3945, RFC 4206, and the MLN Requirements I-D have a definition of region. Is "PBB-TE Region" an IEEE term? Does it map to layer or domain in GMPLS? === Section 2.1 Point-to-Multipoint PBB-TE service instance s/multipoint ESP/point-to-multipoint ESP/ s/leaves/branches/ ... or ... You might prefer to say that the n P2P ESPs are co-routed but in the oposite direction from the source-to-leaf sub-ESPs comprising the P2MP ESP. There is no such thing as a P2MP GMPLS bidirectional tree until you define one later. So this terminology at least needs a forward pointer. === Section 3 Please capitalise the section heading === Section 3 Suggest you replace "[see Appendix A]" with "see [IEEE 802.1Qay]". You could also retain a reference to Appendix A, but see the previous discussion. === Section 4.1 s/Ip_Source_Sddr/Ip_Source_Addr/ "From a GMPLS control plane point of view an Ethernet LSP MAY also be identified as any other LSP" What do you mean "MAY"? Surely this is "is". === Section 5.1 "This may be any switch along the path." This may be *originated by* any switch along the path? === Section 5.2 s/then node/the node/ Don't you need to be able to distinguish whether it is a source or dest address that has caused the problem? === Section 5.3 and 5.4 s/discontinuities/discrepencies/ ??? I'm not sure about these error cases, and I don't find a description in the body of the text (did I look ahard enough?). The error codes sounds like you are suggesting that an LSR (i.e. switch) that receives a Path message will check the information in the ERO against the informaiton in the Upstream-Label and Label-Set objects. But... - the hop information is stipped from the ERO before the Path is sent - we shouldn't have duplicate information in our data elements - the LSR should not "look ahead" in the ERO in any way different from the process described in RFC3209. === Section 7 I think a good deal of work is needed on this section. Possibly some more work is needed in draft-ietf-ccamp-gmpls-ethernet-arch-01.txt as well. All you have done here is lift the text from the architecture document. You need to consider... - I don't find any reference in the rest of your document to UNI ports - "Commonly known techniques" should have references - You should reference draft-ietf-mpls-mpls-and-gmpls-security-framework - What care should be taken to protect the trusted domain from untrusted access? - What happens if legacy Ethernet control plane techniques are enabled in the GMPLS controlled network? - What happens if Ethernet frames are injected into the network? It would appear that PBB-TE has many of the same vulnerabilities in this regard as Ethernet and IP. How does the network protect against this? Does GMPLS contribute to the protection? - Do the error codes described in section 5 provide a way to use GMPLS to probe the network and discover the configuration of core nodes? === Manageability With the introduction of a new technology to the GMPLS family, I think it would be worth your draft discussing the manageability of a GMPLS controlled PBB-TE network. What features do you require from GMPLS? How do you debug GMPLS established ESPs, and how do you debug the GMPLS control plane itself? Some of this may be by reference to existing or soon-to-be-created documents. (Notwithstanding section 4.5). === Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Apr 2008 18:32:20 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A702.6735B8E6" Subject: Working Group Last Call: draft-ietf-ccamp-pc-and-sc-reqs-02 Date: Fri, 25 Apr 2008 13:30:13 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF10F7A8D2@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Working Group Last Call: draft-ietf-ccamp-pc-and-sc-reqs-02 Thread-Index: AcinAma4cVOgNqu6REeXIW68/i9pSw== From: "BRUNGARD, DEBORAH A, ATTLABS" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A702.6735B8E6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable WG, =20 To ensure you have weekend reading material (especially here in the NE with our yet another rainy weekend), we have two more documents which we discussed in Phila to Last Call. I'll send separate mails. =20 And don't forget the Last Calls on draft-ietf-rfc4420bis-02.txt and draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt will end tomorrow. =20 This is to initiate a Working Group Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc-reqs-02.t xt =20 Please send your comments to the mailing list prior to EOB May 9. =20 Adrian and Deborah ------_=_NextPart_001_01C8A702.6735B8E6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
WG,
 
To = ensure you have=20 weekend reading material (especially here in the NE with our yet=20 another rainy weekend), we have two more documents which we = discussed in=20 Phila to Last Call. I'll send separate mails.
 
And = don't forget the=20 Last Calls on draft-ietf-rfc4420bis-02.txt and draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt will end=20 tomorrow.
 
This = is to initiate=20 a Working Group Last Call on:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-and-sc= -reqs-02.txt
 
Please = send your=20 comments to the mailing list prior to EOB May 9.
 
Adrian = and=20 Deborah
------_=_NextPart_001_01C8A702.6735B8E6-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Apr 2008 14:03:10 +0000 Date: Fri, 25 Apr 2008 10:00:55 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: Two more working group last calls Cc: "Lou Berger" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Adrian, Not sure how this is an AD issue, to me it's one of aesthetics/style. As this is an issue of style and personal preference, the choice is 100% the author's (i.e., yours). In other words, please feel free to ignore my suggestion! Lou At 06:43 AM 4/25/2008, Adrian Farrel wrote: >Hi Lou, > >I just consulted with our AD on the "correct" way of doing this. He >suggested... > >- The abstract and introduction should very clearly state that this > document is an update to the previous document. >- The introduction should point to a section somewhere in the > document (possibly an annex) that describes the differences in > some detail. >- Otherwise, the new document can stand on its own. > >I think that is what we currently have. > >Do you feel strongly about your suggested change? > >Cheers, >Adrian >----- Original Message ----- From: "Lou Berger" >To: "Adrian Farrel" >Cc: >Sent: Thursday, April 17, 2008 10:23 PM >Subject: Re: Two more working group last calls > > >>Adrian, >> See below for minor comments: >> >>At 11:12 AM 4/11/2008, Adrian Farrel wrote: >>>Hi, >>> >>>Sorry for the continued bombardment with reviewing activity. >>> >>>Here are two drafts that were discussed in Philadelphia with the >>>intention to go to WG last call as soon as possible. >>> >>>draft-ietf-rfc4420-bis-02.txt >> >>I assume that you mean draft-ietf-ccamp-rfc4420bis-02.txt. >> >> >>>This is the revision to RFC 4420 to fix the TLV encoding to be >>>consistent with the previous RSVP-TE RFCs. The fix is to the >>>interpretation of the Length field. >>>Although we might not expect much in the way of review comments >>>for this I-D, it would be very helpful if you could read the I-D, >>>point out any typos, and send a note to say that you have read the >>>document and believe it is ready for publication. >> >>Only a minor suggestion here: >> >>I suggest moving the rational for the updated provided from section >>14 to section 1. Specifically: >> >>- drop section 14 >>- section 1, 1st paragraph: drop "See Section 14 for a summary of >>changes." and add: >> Prior to the change, the Length field indicated the length of the >> Value field only. After the change, as described in Section 3, the >> Length field indicates the length of the whole TLV. This change means >> that this document is consistent with the subobject format defined in >> [RFC3209] and the TLV format defined in [RFC3471]. >> >>Lou > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 25 Apr 2008 10:45:34 +0000 Message-ID: <05b501c8a6c1$318afb70$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lou Berger" Cc: Subject: Re: Two more working group last calls Date: Fri, 25 Apr 2008 11:43:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Hi Lou, I just consulted with our AD on the "correct" way of doing this. He suggested... - The abstract and introduction should very clearly state that this document is an update to the previous document. - The introduction should point to a section somewhere in the document (possibly an annex) that describes the differences in some detail. - Otherwise, the new document can stand on its own. I think that is what we currently have. Do you feel strongly about your suggested change? Cheers, Adrian ----- Original Message ----- From: "Lou Berger" To: "Adrian Farrel" Cc: Sent: Thursday, April 17, 2008 10:23 PM Subject: Re: Two more working group last calls > Adrian, > See below for minor comments: > > At 11:12 AM 4/11/2008, Adrian Farrel wrote: >>Hi, >> >>Sorry for the continued bombardment with reviewing activity. >> >>Here are two drafts that were discussed in Philadelphia with the intention >>to go to WG last call as soon as possible. >> >>draft-ietf-rfc4420-bis-02.txt > > I assume that you mean draft-ietf-ccamp-rfc4420bis-02.txt. > > >>This is the revision to RFC 4420 to fix the TLV encoding to be consistent >>with the previous RSVP-TE RFCs. The fix is to the interpretation of the >>Length field. >>Although we might not expect much in the way of review comments for this >>I-D, it would be very helpful if you could read the I-D, point out any >>typos, and send a note to say that you have read the document and believe >>it is ready for publication. > > Only a minor suggestion here: > > I suggest moving the rational for the updated provided from section 14 to > section 1. Specifically: > > - drop section 14 > - section 1, 1st paragraph: drop "See Section 14 for a summary of > changes." and add: > Prior to the change, the Length field indicated the length of the > Value field only. After the change, as described in Section 3, the > Length field indicates the length of the whole TLV. This change means > that this document is consistent with the subobject format defined in > [RFC3209] and the TLV format defined in [RFC3471]. > > Lou Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Apr 2008 20:36:38 +0000 Date: Thu, 24 Apr 2008 16:35:55 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: Last call review of draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt Cc: "Lou Berger" ,, "Attila Takacs \(IJ/ETH\)" , "Diego Caviglia \(GO/MCI\)" , "Don Fedyk" , "MEURIC Julien RD-CORE-LAN" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Adrian, Please see below. At 03:58 PM 4/24/2008, Adrian Farrel wrote: >Hi Lou, > >>>=== >>>I struggled to see the utility of the Upstream_TSpec and >>>Upstream_Adspec objects. By the time these objects are used (on >>>the Resv) the reservation has already been made using the >>>Upstream_Flowspec (on the Path message). > >[SNIP] > >I think I found the "exactly the same" description a little strong. >But given our discussion (snipped) I think we are agreed on the usage. > >The only thing I find missing from the I-D might be expressed as... > >"When an egress receives an Upstream-Flowspec object, it responds >with an Upstream-TSpec for describe the traffic flow that it will >originate. When that Upstream-TSpec is received by the ingress, it >may determine that the original reservation is not sufficient to >satisfy the traffic flow. In this case it will issue a new Path >message with an updated Upstream-Flowspec object to mnodify the >resources reserved for the upstream traffic flow. This might also >require that the LSP is re-routed, and in extreme cases might result >in the LSP being torn down if sufficient resources are not available." Added to section 2.2.1. >>>=== >>>I believe it would be helpful to indicate in the Abstract that >>>this is an Experimental approach, and in the Introduction to >>>include a whole paragraph on why this is positioned as an Experimental RFC. >> >>Okay have added: >> >> NOTE: THIS IS AN EXPERIMENTAL RFC. >> >>Let us know if you'd to see anything additional. > >In the abstract it would be fine to simply say: > >"The procedures described in this document are experimental." done >In the Introduction, you might say: > >"The usage of asymmetrical bidirectional LSPs is not well developed >and no products have been developed yet. In consequence, the >procedures described in this document are experimental." added: "the procedures described in this document are experimental." >>>Section 1.2 >>>You have >>> An alternative approach was considered and >>> rejected. For reference purposes only, the rejected approach is >>> summarized in Appendix A. >>> >>>Looking ahead at Appendix A, it is hard to see that this >>>alternative has been rejected. In fact, it says "SHOULD NOT be >>>implemented". Nowhere is there a definitive reason why the >>>alternative has been rejected (although there are a few hints in >>>the introduction to the Appendix). >> >>well it does say: >> This section is included for historic purposes and SHOULD NOT >> be implemented. >> >>and >> In summary, the "ADSPEC Object" approach presented in this >> section SHOULD NOT be implemented. >> >>This seems pretty clear to me. What would you like it to say? > >Well, I've just seen an I-D bounced by the IESG because it uses >"SHOULD" without explaining why you might actually do it. That is, >there is a claim that in 2119 language "SHOULD" implies that there >might be good reasons to deviate, so there needs to be text to >describe how the deviation is handled and why it might be introduced. > >Curiously, NOT RECOMMENDED would mean the same thing, but might be >more acceptable. NOT RECOMMENDED it is. >[SNIP] > >>I've changed the sec. 1.2. text to read "An alternative approach >>was considered and rejected in favor of the more generic approach >>presented below." and to A.1. "In particular this approach is >>technology specific; it uses the ADSPEC object to carry traffic >>parameters for upstream data and requires MEF Ethernet Traffic >>Parameter while the approach presented above is suitable for use >>with any technology." > >That's good. >Thanks. > >>>=== >>>Section 2.1.1 >>>You suggest using "Routing problem/MPLS label allocation failure" >>>Are you sure you do not want to be able to tell whether it was the >>>upstream or downstream resources that failed? Since these can be >>>varied independently, it would surely be useful to know which failed. >> >>I don't have a strong opinion one way or another. > >Me neither. >We could ask the implementers :-) > >>>Section 2.3.1 >>>I think you need to clarify whether the Upstream_Adspec reports >>>the available upstream resources before or after the reservation >>>for the LSP in hand. >> >>> Note that Adspec would apply before the reservation. >> >>This may be true on the initial path, but it isn't actually stated >>anywhere. Furthermore, the information may include an LSPs >>reservation even in the case where it is not yet made. e.g., >>RFC2212 talks in terms of reporting what the "flow might >>experience" which implies that the full Tspec is accounted for in >>the initial ADSPEC. >> >>So I think, like 2210, this should not be mentioned. > >OK > >>>=== >>>Section 4 >>>You have... >>> The error message >>> will propagate to the ingress which can then take action to avoid the >>> path with the incompatible node, or may simply terminate the session. >>>I think you need a little more care with the behavior for unknown >>>object on a Resv since that error will propagate to the egress. >> >>This can only happen from a non-conformant implementation, i.e., >>one that passes a new object in the path but then rejects it in the resv. > >Or a node that has to handle a non-conformant node that generates an >Upstream-TSpec when it did not receive an Upstream-Flowspec. > >But let's leave it. great. Thanks for the comments! Lou >Thanks for the work. >Adrian > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Apr 2008 20:09:52 +0000 Message-ID: <052601c8a647$0a0cd0c0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: Subject: Communication to the MEF from the IETF's CCAMP Working Group Date: Thu, 24 Apr 2008 21:08:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Dear Nan, Bob, and Bill, The IETF's CCAMP working group would like to inform the MEF of work it is carrying out to apply GMPLS protocols to the requirements of the Ethernet UNI and Ethernet service spectrum defined by the MEF. GMPLS is a family of IP-based protocols developed within the IETF and applicable to a range of technologies from packet switched networks (such as MPLS), through layer 2 networks (such as ATM, Frame Relay, and Ethernet), to optical networks (like TDM and WDM). We would like to draw your intention to the following Internet-Drafts that we are working on. We would welcome any feedback from your members on the requirements, details of the solutions proposed, or applicability of our work. "Ethernet Traffic Parameters" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-04.txt "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-00.txt "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-00.txt "GMPLS Ethernet Label Switching Architecture and Framework" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-01.txt Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 24 Apr 2008 20:02:23 +0000 Message-ID: <051301c8a645$b29b3710$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lou Berger" Cc: , "Attila Takacs \(IJ/ETH\)" , "Diego Caviglia \(GO/MCI\)" , "Don Fedyk" , "MEURIC Julien RD-CORE-LAN" Subject: Re: Last call review of draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt Date: Thu, 24 Apr 2008 20:58:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Hi Lou, >>=== >>I struggled to see the utility of the Upstream_TSpec and Upstream_Adspec >>objects. By the time these objects are used (on the Resv) the reservation >>has already been made using the Upstream_Flowspec (on the Path message). [SNIP] I think I found the "exactly the same" description a little strong. But given our discussion (snipped) I think we are agreed on the usage. The only thing I find missing from the I-D might be expressed as... "When an egress receives an Upstream-Flowspec object, it responds with an Upstream-TSpec for describe the traffic flow that it will originate. When that Upstream-TSpec is received by the ingress, it may determine that the original reservation is not sufficient to satisfy the traffic flow. In this case it will issue a new Path message with an updated Upstream-Flowspec object to mnodify the resources reserved for the upstream traffic flow. This might also require that the LSP is re-routed, and in extreme cases might result in the LSP being torn down if sufficient resources are not available." >>=== >>I believe it would be helpful to indicate in the Abstract that this is an >>Experimental approach, and in the Introduction to include a whole >>paragraph on why this is positioned as an Experimental RFC. > > Okay have added: > > NOTE: THIS IS AN EXPERIMENTAL RFC. > > Let us know if you'd to see anything additional. In the abstract it would be fine to simply say: "The procedures described in this document are experimental." In the Introduction, you might say: "The usage of asymmetrical bidirectional LSPs is not well developed and no products have been developed yet. In consequence, the procedures described in this document are experimental." >>Section 1.2 >>You have >> An alternative approach was considered and >> rejected. For reference purposes only, the rejected approach is >> summarized in Appendix A. >> >>Looking ahead at Appendix A, it is hard to see that this alternative has >>been rejected. In fact, it says "SHOULD NOT be implemented". Nowhere is >>there a definitive reason why the alternative has been rejected (although >>there are a few hints in the introduction to the Appendix). > > well it does say: > This section is included for historic purposes and SHOULD NOT > be implemented. > > and > In summary, the "ADSPEC Object" approach presented in this > section SHOULD NOT be implemented. > > This seems pretty clear to me. What would you like it to say? Well, I've just seen an I-D bounced by the IESG because it uses "SHOULD" without explaining why you might actually do it. That is, there is a claim that in 2119 language "SHOULD" implies that there might be good reasons to deviate, so there needs to be text to describe how the deviation is handled and why it might be introduced. Curiously, NOT RECOMMENDED would mean the same thing, but might be more acceptable. [SNIP] > I've changed the sec. 1.2. text to read "An alternative approach was > considered and rejected in favor of the more generic approach presented > below." and to A.1. "In particular this approach is technology specific; > it uses the ADSPEC object to carry traffic parameters for upstream data > and requires MEF Ethernet Traffic Parameter while the approach presented > above is suitable for use with any technology." That's good. Thanks. >>=== >>Section 2.1.1 >>You suggest using "Routing problem/MPLS label allocation failure" >>Are you sure you do not want to be able to tell whether it was the >>upstream or downstream resources that failed? Since these can be varied >>independently, it would surely be useful to know which failed. > > I don't have a strong opinion one way or another. Me neither. We could ask the implementers :-) >>Section 2.3.1 >>I think you need to clarify whether the Upstream_Adspec reports the >>available upstream resources before or after the reservation for the LSP >>in hand. > >> Note that Adspec would apply before the reservation. > > This may be true on the initial path, but it isn't actually stated > anywhere. Furthermore, the information may include an LSPs reservation > even in the case where it is not yet made. e.g., RFC2212 talks in terms > of reporting what the "flow might experience" which implies that the full > Tspec is accounted for in the initial ADSPEC. > > So I think, like 2210, this should not be mentioned. OK >>=== >>Section 4 >>You have... >> The error message >> will propagate to the ingress which can then take action to avoid the >> path with the incompatible node, or may simply terminate the session. >>I think you need a little more care with the behavior for unknown object >>on a Resv since that error will propagate to the egress. > > This can only happen from a non-conformant implementation, i.e., one that > passes a new object in the path but then rejects it in the resv. Or a node that has to handle a non-conformant node that generates an Upstream-TSpec when it did not receive an Upstream-Flowspec. But let's leave it. Thanks for the work. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 22 Apr 2008 14:56:23 +0000 Date: Tue, 22 Apr 2008 10:51:36 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: Last call review of draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt Cc: ,"Lou Berger" , "Attila Takacs \(IJ/ETH\)" , "Diego Caviglia \(GO/MCI\)" , "Don Fedyk" , "MEURIC Julien RD-CORE-LAN" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Adrian, Much thanks for the comments. Please see below for in-line responses. At 03:25 PM 4/21/2008, Adrian Farrel wrote: >Hi, > >Here are some review comments about this I-D. As is bound to be the >case with an experiment that has not been carried out, I think there >are a few wrinkles to be ironed. > >Cheers, >Adrian > >=== >I struggled to see the utility of the Upstream_TSpec and >Upstream_Adspec objects. By the time these objects are used (on the >Resv) the reservation has already been made using the >Upstream_Flowspec (on the Path message). The utility here really comes from the support of PSC modes and preservation of RSVP/IntServ semantics. In short we're maintaining the object types used in the downstream direction and instantiating them for the upstream direction. To quote 2210: From the point of view of RSVP objects, the breakdown is as follows: - The RSVP SENDER_TSPEC object carries the traffic specification (sender TSpec) generated by each data source within an RSVP session. It is transported unchanged through the network, and delivered to both intermediate nodes and receiving applications. - The RSVP ADSPEC object carries information which is generated at either data sources or intermediate network elements, is flowing downstream towards receivers, and may be used and updated inside the network before being delivered to receiving applications. This information includes both parameters describing the properties of the data path, including the availability of specific QoS control services, and parameters required by specific QoS control services to operate correctly. - The RSVP FLOWSPEC object carries reservation request (Receiver_TSpec and RSpec) information generated by data receivers. The information in the FLOWSPEC flows upstream towards data sources. It may be used or updated at intermediate network elements before arriving at the sending application. NOTE: The existence of both SENDER_TSPEC and ADSPEC RSVP objects is somewhat historical. Using the message format described in this note it would be possible to place all of the service control information carried "downstream" by RSVP in the same object. However, the distinction between data which is not updated within the network (in the SENDER_TSPEC object) and data which is updated within the network (in the ADSPEC object) may be useful to an implementation in practice, and is therefore retained. >This is strengthen by section 2.2.1 that says that the content is >constructed using the same mechanisms as used for creating the >content of the Flowspec. If that is so, it is a flowspec not a tspec. I see this as a reference to semantic construction. I think this is clear in the text, but am open to any specific improvements you can suggest: ... The contents of the UPSTREAM_TSPEC Object MUST be constructed using a consistent format and procedures used to construct the FLOWSPEC object that will be used for the LSP, e.g., [RFC2210] or [RFC4328]. The contents of the UPSTREAM_TSPEC Object MAY differ from contents of the UPSTREAM_FLOWSPEC object based on application data transmission requirements. >I would contest that what you really have is... >Upstream_Flowspec is used to request a particular reservation as >predicted by the ingress. yes. >Upstream_TSpec is used to report the intended traffic flow (which >might not be the same as the reservation and might require a >modification to the reservation). right. >Upstream_Adspec reports the available resources in the upstream direction. right again. >In this case, the operational use would be... >Path {TSpec, Adspec, Upstream_Flowspec} >Resv {Flowspec = fn(TSpec, Adspec), Upstream_TSpec, Upstream_Adspec} >If necessary > Path {TSpec, Adspec, Upstream_Flowspec'} > Resv {Flowspec, Upstream_TSpec, Upstream_Adspec} I think this is what the draft says. >=== >I believe it would be helpful to indicate in the Abstract that this >is an Experimental approach, and in the Introduction to include a >whole paragraph on why this is positioned as an Experimental RFC. Okay have added: NOTE: THIS IS AN EXPERIMENTAL RFC. Let us know if you'd to see anything additional. >=== >Document title >s/LSPs/Label Switched Paths/ >=== >Abstract >s/LSPs/Label Switched Paths (LSPs)/ >=== >Section 1 para 1 >s/LSPs/Label Switched Paths (LSPs)/ >s/TDM/Time Division Multiplexing (TDM)/ >=== >Section 1 para 2 >s/discussion on/discussion of/ >=== >Section 1 >I believe it may be useful to say what an "asymmetric bandwidth LSP" is. >Perhaps... > In this context there > has been discussion on the support of bidirectional LSPs with > asymmetric bandwidth. >ADD > That is, bidirectional LSPs that have different bandwidth > reservations in each direction. >=== okay. >Section 1.2 >You have > An alternative approach was considered and > rejected. For reference purposes only, the rejected approach is > summarized in Appendix A. > >Looking ahead at Appendix A, it is hard to see that this alternative >has been rejected. In fact, it says "SHOULD NOT be implemented". >Nowhere is there a definitive reason why the alternative has been >rejected (although there are a few hints in the introduction to the Appendix). well it does say: This section is included for historic purposes and SHOULD NOT be implemented. and In summary, the "ADSPEC Object" approach presented in this section SHOULD NOT be implemented. This seems pretty clear to me. What would you like it to say? >*If* you wish to retain the rejected approach in the documentation, >then you need to give some background about why. What would be the >implications of doing the approach that lead you to recommend against it? >This material could happily go in the appendix leaving the only >change to section 1.2 to be... >s/rejected approach is summarized/rejected approach is summarized >with reasons for rejection/ I've changed the sec. 1.2. text to read "An alternative approach was considered and rejected in favor of the more generic approach presented below." and to A.1. "In particular this approach is technology specific; it uses the ADSPEC object to carry traffic parameters for upstream data and requires MEF Ethernet Traffic Parameter while the approach presented above is suitable for use with any technology." >=== >Section 2 >You have > The new upstream objects carry the same information and are used in > the same fashion as the existing downstream objects; they only differ > in that they relate to traffic flowing in the upstream direction > while the existing objects relate to traffic flowing in the > downstream direction. > >They also differ in that they are used on messages in the opposite directions. okay. >=== >Section 2.1.1 >You suggest using "Routing problem/MPLS label allocation failure" >Are you sure you do not want to be able to tell whether it was the >upstream or downstream resources that failed? Since these can be >varied independently, it would surely be useful to know which failed. I don't have a strong opinion one way or another. >=== >Section 2.3.1 >I think you need to clarify whether the Upstream_Adspec reports the >available upstream resources before or after the reservation for the >LSP in hand. > Note that Adspec would apply before the reservation. This may be true on the initial path, but it isn't actually stated anywhere. Furthermore, the information may include an LSPs reservation even in the case where it is not yet made. e.g., RFC2212 talks in terms of reporting what the "flow might experience" which implies that the full Tspec is accounted for in the initial ADSPEC. So I think, like 2210, this should not be mentioned. >=== >Section 3 >You don't list Upstream_Flowspec as carried on a Notify. But an >upstream notify session carries and you have >defined this to carry Upstream_Flowspec. >You also don't list ResvErr as able to carry Upstream_TSpec, but >ResvErr can carry which presumably can carry >the Upstream_TSpec as it also carries the Flowspec. >Also, you don't list PathTear (can carry ) and >ResvTear (carries ) > >Perhaps your excuse will be that you say "Unmodified formats are not >listed." If that is the case, it should be pointed out that the >formats of the other messages are not modified either! nope. just a simple mistake. >Maybe the best way forward is to show how you modify descriptor>, and , and say >that the use of these constructs on RSVP messages is not modified. >That would be the smallest change to the documentation. Good catch. Have changed the text to read: Object name Applicable RSVP messages --------------- ------------------------ UPSTREAM_FLOWSPEC Path, PathTear, PathErr and Notify (via sender descriptor) UPSTREAM_TSPEC Resv, ResvConf, ResvTear, ResvErr and Notify (via flow descriptor list) UPSTREAM_ADSPEC Resv, ResvConf, ResvTear, ResvErr and Notify (via flow descriptor list) >=== >Section 4 >OLD > Per [RFC2205], nodes not > supporting this extension should not recognize the new class numbers > and respond with an "Unknown Object Class" error. >NEW > Per [RFC2205], nodes not > supporting this extension will not recognize the new class numbers > and SHOULD respond with an "Unknown Object Class" error okay, the should is lower case as this document cannot dictate behavior of non-conforming implementations ;-) >=== >Section 4 >You have... > The error message > will propagate to the ingress which can then take action to avoid the > path with the incompatible node, or may simply terminate the session. >I think you need a little more care with the behavior for unknown >object on a Resv since that error will propagate to the egress. This can only happen from a non-conformant implementation, i.e., one that passes a new object in the path but then rejects it in the resv. >=== >Section 5. >You might need another error code as mentioned above. >=== >Section 6 >It is always worth referencing >draft-ietf-mpls-mpls-and-gmpls-security-framework in GMPLS-related >security sections. > >Although you have not introduced any new ways to penetrate the >security, I wonder whether you have introduced new ways to attack >the system once security is penetrated. Upstream_Adspec may be a way >to damage the system without leaving immediate evidence of where the >attack originated. Upstream_TSpec represents a new way to cause an >LSP that has been set up, to be torn down. Of course these issues >can be protected against, but you need to point them out so that >people understand the increased risk and the potential need to use >the existing security mechanisms. okay have added some words on this. >=== >Section 7.1 >[MEF-TRAFFIC] has been revised. >Does it need to be a normative reference? It is only cited as an example. moved. >=== >Section 7.2 >[GMPLS-PBBTE] is now a CCAMP I-D >=== >Section 8 >s/Author's/Authors'/ >=== >All appendix sections >Section headers need left justify >=== >Sections A, A.1, A.3, A.4 >s/section/appendix/ (Except "Section 3", "Section 3.1") >=== isn't an appendix a section of the document? Thanks for the usual detailed review & comments... Lou Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 21 Apr 2008 19:49:19 +0000 Message-ID: <000001c8a3e8$6e7487d0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Lou Berger" , "Attila Takacs \(IJ/ETH\)" , "Diego Caviglia \(GO/MCI\)" , "Don Fedyk" , "MEURIC Julien RD-CORE-LAN" Subject: Last call review of draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt Date: Mon, 21 Apr 2008 20:25:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Here are some review comments about this I-D. As is bound to be the case with an experiment that has not been carried out, I think there are a few wrinkles to be ironed. Cheers, Adrian === I struggled to see the utility of the Upstream_TSpec and Upstream_Adspec objects. By the time these objects are used (on the Resv) the reservation has already been made using the Upstream_Flowspec (on the Path message). This is strengthen by section 2.2.1 that says that the content is constructed using the same mechanisms as used for creating the content of the Flowspec. If that is so, it is a flowspec not a tspec. I would contest that what you really have is... Upstream_Flowspec is used to request a particular reservation as predicted by the ingress. Upstream_TSpec is used to report the intended traffic flow (which might not be the same as the reservation and might require a modification to the reservation). Upstream_Adspec reports the available resources in the upstream direction. In this case, the operational use would be... Path {TSpec, Adspec, Upstream_Flowspec} Resv {Flowspec = fn(TSpec, Adspec), Upstream_TSpec, Upstream_Adspec} If necessary Path {TSpec, Adspec, Upstream_Flowspec'} Resv {Flowspec, Upstream_TSpec, Upstream_Adspec} === I believe it would be helpful to indicate in the Abstract that this is an Experimental approach, and in the Introduction to include a whole paragraph on why this is positioned as an Experimental RFC. === Document title s/LSPs/Label Switched Paths/ === Abstract s/LSPs/Label Switched Paths (LSPs)/ === Section 1 para 1 s/LSPs/Label Switched Paths (LSPs)/ s/TDM/Time Division Multiplexing (TDM)/ === Section 1 para 2 s/discussion on/discussion of/ === Section 1 I believe it may be useful to say what an "asymmetric bandwidth LSP" is. Perhaps... In this context there has been discussion on the support of bidirectional LSPs with asymmetric bandwidth. ADD That is, bidirectional LSPs that have different bandwidth reservations in each direction. === Section 1.2 You have An alternative approach was considered and rejected. For reference purposes only, the rejected approach is summarized in Appendix A. Looking ahead at Appendix A, it is hard to see that this alternative has been rejected. In fact, it says "SHOULD NOT be implemented". Nowhere is there a definitive reason why the alternative has been rejected (although there are a few hints in the introduction to the Appendix). *If* you wish to retain the rejected approach in the documentation, then you need to give some background about why. What would be the implications of doing the approach that lead you to recommend against it? This material could happily go in the appendix leaving the only change to section 1.2 to be... s/rejected approach is summarized/rejected approach is summarized with reasons for rejection/ === Section 2 You have The new upstream objects carry the same information and are used in the same fashion as the existing downstream objects; they only differ in that they relate to traffic flowing in the upstream direction while the existing objects relate to traffic flowing in the downstream direction. They also differ in that they are used on messages in the opposite directions. === Section 2.1.1 You suggest using "Routing problem/MPLS label allocation failure" Are you sure you do not want to be able to tell whether it was the upstream or downstream resources that failed? Since these can be varied independently, it would surely be useful to know which failed. === Section 2.3.1 I think you need to clarify whether the Upstream_Adspec reports the available upstream resources before or after the reservation for the LSP in hand. Note that Adspec would apply before the reservation. === Section 3 You don't list Upstream_Flowspec as carried on a Notify. But an upstream notify session carries and you have defined this to carry Upstream_Flowspec. You also don't list ResvErr as able to carry Upstream_TSpec, but ResvErr can carry which presumably can carry the Upstream_TSpec as it also carries the Flowspec. Also, you don't list PathTear (can carry ) and ResvTear (carries ) Perhaps your excuse will be that you say "Unmodified formats are not listed." If that is the case, it should be pointed out that the formats of the other messages are not modified either! Maybe the best way forward is to show how you modify , and , and say that the use of these constructs on RSVP messages is not modified. That would be the smallest change to the documentation. === Section 4 OLD Per [RFC2205], nodes not supporting this extension should not recognize the new class numbers and respond with an "Unknown Object Class" error. NEW Per [RFC2205], nodes not supporting this extension will not recognize the new class numbers and SHOULD respond with an "Unknown Object Class" error. === Section 4 You have... The error message will propagate to the ingress which can then take action to avoid the path with the incompatible node, or may simply terminate the session. I think you need a little more care with the behavior for unknown object on a Resv since that error will propagate to the egress. === Section 5. You might need another error code as mentioned above. === Section 6 It is always worth referencing draft-ietf-mpls-mpls-and-gmpls-security-framework in GMPLS-related security sections. Although you have not introduced any new ways to penetrate the security, I wonder whether you have introduced new ways to attack the system once security is penetrated. Upstream_Adspec may be a way to damage the system without leaving immediate evidence of where the attack originated. Upstream_TSpec represents a new way to cause an LSP that has been set up, to be torn down. Of course these issues can be protected against, but you need to point them out so that people understand the increased risk and the potential need to use the existing security mechanisms. === Section 7.1 [MEF-TRAFFIC] has been revised. Does it need to be a normative reference? It is only cited as an example. === Section 7.2 [GMPLS-PBBTE] is now a CCAMP I-D === Section 8 s/Author's/Authors'/ === All appendix sections Section headers need left justify === Sections A, A.1, A.3, A.4 s/section/appendix/ (Except "Section 3", "Section 3.1") === Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Apr 2008 17:51:17 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A17C.7B2E2091" Subject: Please publish draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt Date: Fri, 18 Apr 2008 12:48:58 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF10E5BE22@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Please publish draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt Thread-Index: AcihfHqj8eQd+MGrTEibJiVeX2vvcw== From: "BRUNGARD, DEBORAH A, ATTLABS" To: "Ross Callon" Cc: , "David Ward" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A17C.7B2E2091 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Proto-write-up for draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt Intended status : Informational > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Deborah Brungard is the document shepherd. She has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? I-D had good review and discussion in the CCAMP working group doing its development. It has not had review in any wider forums, but none was deemed necessary or appropriate. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No concerns. No IPR disclosures have been filed. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Consensus is good. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/ ). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downward references. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? The document is informational (no requests for IANA action). Null IANA section included. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments. Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering. This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? WG had good consensus with no disputes or disagreements. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? This is an Informational RFC with no protocol specifications. ------_=_NextPart_001_01C8A17C.7B2E2091 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Proto-write-up for draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt

Intended status : Informational

> (1.a) Who is the Document Shepherd = for this=20 document? Has the

> Document Shepherd personally = reviewed this=20 version of the

> document and, in particular, does he = or she=20 believe this

> version is ready for forwarding to = the IESG for=20 publication?

Deborah=20 Brungard is the document shepherd.

She has=20 personally reviewed the I-D and believes it is ready = for

forwarding to the IESG for = publication.

> (1.b) Has the document had adequate = review both=20 from key WG members

> and from key non-WG members? Does = the Document=20 Shepherd have

> any concerns about the depth or = breadth of the=20 reviews that

> have been performed?

I-D had good review and discussion in the CCAMP working

group = doing its=20 development. It has not had review in any wider forums, but none = was=20 deemed

necessary or appropriate.

> (1.c) Does the Document Shepherd = have concerns=20 that the document

> needs more review from a particular = or broader=20 perspective,

> e.g., security, operational = complexity, someone=20 familiar with

> AAA, internationalization or = XML?

No concerns.

> (1.d) Does the Document Shepherd = have any=20 specific concerns or

> issues with this document that the = Responsible=20 Area Director

> and/or the IESG should be aware of? = For example,=20 perhaps he

> or she is uncomfortable with certain = parts of=20 the document, or

> has concerns whether there really is = a need for=20 it. In any

> event, if the WG has discussed those = issues and=20 has indicated

> that it still wishes to advance the = document,=20 detail those

> concerns here. Has an IPR disclosure = related to=20 this document

> been filed? If so, please include a = reference to=20 the

> disclosure and summarize the WG = discussion and=20 conclusion on

> this issue.

No = concerns. No IPR=20 disclosures have been filed.

> (1.e) How solid is the WG consensus = behind this=20 document? Does it

> represent the strong concurrence of = a few=20 individuals, with

> others being silent, or does the WG = as a whole=20 understand and

> agree with it?

Consensus is good.

> (1.f) Has anyone threatened an = appeal or=20 otherwise indicated extreme

> discontent? If so, please summarise = the areas of=20 conflict in

> separate email messages to the = Responsible Area=20 Director. (It

> should be in a separate email = because this=20 questionnaire is

> entered into the ID = Tracker.)

No threats. No discontent.

> (1.g) Has the Document Shepherd = personally=20 verified that the

> document satisfies all ID nits? = (See

> http://www.ietf.org/ID-Checklist.html and

> http://tools.ietf.org/tools/idnits/). Boilerplate checks are

> not enough; this check needs to be = thorough. Has=20 the document

> met all formal review criteria it = needs to, such=20 as the MIB

> Doctor, media type and URI type=20 reviews?

All checks made.

> (1.h) Has the document split its = references into=20 normative and

> informative? Are there normative = references to=20 documents that

> are not ready for advancement or are = otherwise=20 in an unclear

> state? If such normative references = exist, what=20 is the

> strategy for their completion? Are = there=20 normative references

> that are downward references, as = described in=20 [RFC3967]? If

> so, list these downward references = to support=20 the Area

> Director in the Last Call procedure = for them=20 [RFC3967].

References split. No downward = references.

> (1.i) Has the Document Shepherd = verified that=20 the document IANA

> consideration section exists and is = consistent=20 with the body

> of the document? If the document = specifies=20 protocol

> extensions, are reservations = requested in=20 appropriate IANA

> registries? Are the IANA registries = clearly=20 identified? If

> the document creates a new registry, = does it=20 define the

> proposed initial contents of the = registry and an=20 allocation

> procedure for future registrations? = Does it=20 suggest a

> reasonable name for the new = registry? See=20 [RFC2434]. If the

> document describes an Expert Review = process has=20 Shepherd

> conferred with the Responsible Area = Director so=20 that the IESG

> can appoint the needed Expert during = the IESG=20 Evaluation?

The document is informational (no requests for IANA = action). Null

IANA section = included.

> (1.j) Has the Document Shepherd = verified that=20 sections of the

> document that are written in a = formal language,=20 such as XML

> code, BNF rules, MIB definitions, = etc., validate=20 correctly in

> an automated checker?

No such formal language is = used.

> (1.k) The IESG approval announcement = includes a=20 Document

> Announcement Write-Up. Please = provide such a=20 Document

> Announcement Write-Up. Recent = examples can be=20 found in the

> "Action" announcements for approved = documents.=20 The approval

> announcement contains the following=20 sections:

>

> Technical Summary

> Relevant content can frequently be = found in the=20 abstract

> and/or introduction of the document. = If not,=20 this may be

> an indication that there are = deficiencies in the=20 abstract

> or introduction.

Protection and recovery are = important=20 features of service offerings in = Multiprotocol Label Switching

(MPLS) and Generalized MPLS = (GMPLS) networks. Increasingly, MPLS and = GMPLS=20 networks

are being extended from single domain scope to = multi-domain=20 environments. Various schemes=20 and

processes have been = developed to establish=20 Label Switched Paths (LSPs) in=20 multi-domain environments.

These = are discussed in RFC 4726: A Framework = for=20 Inter-Domain Multiprotocol Label = Switching

Traffic Engineering.

This document analyzes the = application of=20 these techniques to protection = and=20 recovery in multi-domain

networks. The main focus = for this=20 document is on establishing end-to-end diverse Traffic Engineering=20 (TE)

LSPs in multi-domain = networks.

> Working Group Summary

> Was there anything in WG process = that is worth=20 noting? For

> example, was there controversy about = particular=20 points or

> were there decisions where the = consensus was=20 particularly

> rough?

WG had good=20 consensus with no disputes or disagreements.

> Document Quality

> Are there existing implementations = of the=20 protocol? Have a

> significant number of vendors = indicated their=20 plan to

> implement the specification? Are = there any=20 reviewers that

> merit special mention as having done = a thorough=20 review,

> e.g., one that resulted in important = changes or=20 a

> conclusion that the document had no = substantive=20 issues? If

> there was a MIB Doctor, Media Type = or other=20 expert review,

> what was its course (briefly)? In = the case of a=20 Media Type

> review, on what date was the request = posted?

This is = an=20 Informational RFC with no protocol=20 specifications.

= ------_=_NextPart_001_01C8A17C.7B2E2091-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Apr 2008 12:46:16 +0000 Date: Fri, 18 Apr 2008 08:44:10 -0400 To: "PAPADIMITRIOU Dimitri" From: Lou Berger Subject: RE: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt Cc: "Lou Berger" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Works for me. Thanks! Lou At 01:32 AM 4/18/2008, PAPADIMITRIOU Dimitri wrote: >lou > >this version is only to align w/ 4420bis. > >changes like below are for the next. revision. > >hope this clarifies, >-d. > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Thursday, April 17, 2008 11:51 PM > > To: PAPADIMITRIOU Dimitri > > Cc: ccamp@ops.ietf.org > > Subject: Re: I-D > > Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt > > > > Dimitri, > > I think this versions missed an updated that we previously > > discussed. Specifically it should define 0 value for Switching > > Granularity (SG), i.e.: > > Value Switching Granularity > > ----- --------------------- > > 0 Provided in signaling. See [GMPLS-ESVCS] > > > > I'll update [GMPLS-ESVCS] to explicitly say that the 0 value > > MUST be used. > > > > Can you make sure this gets into the next rev? > > > > Much thanks, > > Lou > > > > At 08:00 AM 4/14/2008, Internet-Drafts@ietf.org wrote: > > >A New Internet-Draft is available from the on-line Internet-Drafts > > >directories. > > >This draft is a work item of the Common Control and Measurement > > >Plane Working Group of the IETF. > > > > > > > > > Title : Ethernet Traffic Parameters > > > Author(s) : D. Papadimitriou, I. Property > > > Filename : > > draft-ietf-ccamp-ethernet-traffic-parameters-04.txt > > > Pages : 13 > > > Date : 2008-04-13 > > > > > >This document describes the Metro Ethernet Forum (MEF) - specific > > >Ethernet Traffic Parameters as described in MEF10.1 when using > > >Generalized Multi-Protocol Label Switching (GMPLS) Resource > > >ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet >-traffic-parameters-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. > > > > > > > > >-traffic-parameters-04.txt> > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Apr 2008 09:42:48 +0000 Message-ID: <009e01c8a138$4085cc10$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: New mailing list for ASON Routing Discussions Date: Fri, 18 Apr 2008 10:40:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, As previously promised, we have set up an IETF mailing list for discussions of the ASON Routing Requirements and the production of a bis to RFC 4258. Our hope is that the Design Team will bring issues and discussions and early versions of their text to this list for wider discussion by the community. When their draft is ready for adoption by CCAMP (we hope around Dublin) this list will be closed, and discussion will move to the CCAMP list. Subscribe to the list at https://www.ietf.org/mailman/listinfo/ason-routing Regards, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 18 Apr 2008 05:37: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: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt Date: Fri, 18 Apr 2008 07:32:21 +0200 Message-ID: <00275A5B436CA441900CB10936742A386C6BF2@FRVELSMBS22.ad2.ad.alcatel.com> Thread-Topic: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt Thread-Index: Acig1RXQRrHPYJyfS8eaPlaNznCSWQAQE1qw From: "PAPADIMITRIOU Dimitri" To: "Lou Berger" Cc: lou=20 this version is only to align w/ 4420bis. changes like below are for the next. revision. hope this clarifies, -d. > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: Thursday, April 17, 2008 11:51 PM > To: PAPADIMITRIOU Dimitri > Cc: ccamp@ops.ietf.org > Subject: Re: I-D=20 > Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt=20 >=20 > Dimitri, > I think this versions missed an updated that we previously=20 > discussed. Specifically it should define 0 value for Switching=20 > Granularity (SG), i.e.: > Value Switching Granularity > ----- --------------------- > 0 Provided in signaling. See [GMPLS-ESVCS] >=20 > I'll update [GMPLS-ESVCS] to explicitly say that the 0 value=20 > MUST be used. >=20 > Can you make sure this gets into the next rev? >=20 > Much thanks, > Lou >=20 > At 08:00 AM 4/14/2008, Internet-Drafts@ietf.org wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > >directories. > >This draft is a work item of the Common Control and Measurement=20 > >Plane Working Group of the IETF. > > > > > > Title : Ethernet Traffic Parameters > > Author(s) : D. Papadimitriou, I. Property > > Filename :=20 > draft-ietf-ccamp-ethernet-traffic-parameters-04.txt > > Pages : 13 > > Date : 2008-04-13 > > > >This document describes the Metro Ethernet Forum (MEF) - specific > >Ethernet Traffic Parameters as described in MEF10.1 when using > >Generalized Multi-Protocol Label Switching (GMPLS) Resource > >ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet -traffic-parameters-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. > > > > > > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2008 21:51:14 +0000 Date: Thu, 17 Apr 2008 17:50:31 -0400 To: "Dimiri Papadimitriou" From: Lou Berger Subject: Re: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Dimitri, I think this versions missed an updated that we previously discussed. Specifically it should define 0 value for Switching Granularity (SG), i.e.: Value Switching Granularity ----- --------------------- 0 Provided in signaling. See [GMPLS-ESVCS] I'll update [GMPLS-ESVCS] to explicitly say that the 0 value MUST be used. Can you make sure this gets into the next rev? Much thanks, Lou At 08:00 AM 4/14/2008, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Common Control and Measurement >Plane Working Group of the IETF. > > > Title : Ethernet Traffic Parameters > Author(s) : D. Papadimitriou, I. Property > Filename : draft-ietf-ccamp-ethernet-traffic-parameters-04.txt > Pages : 13 > Date : 2008-04-13 > >This document describes the Metro Ethernet Forum (MEF) - specific >Ethernet Traffic Parameters as described in MEF10.1 when using >Generalized Multi-Protocol Label Switching (GMPLS) Resource >ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-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. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2008 21:25:45 +0000 Date: Thu, 17 Apr 2008 17:23:49 -0400 To: "Adrian Farrel" From: Lou Berger Subject: Re: Two more working group last calls Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: Adrian, See below for minor comments: At 11:12 AM 4/11/2008, Adrian Farrel wrote: >Hi, > >Sorry for the continued bombardment with reviewing activity. > >Here are two drafts that were discussed in Philadelphia with the >intention to go to WG last call as soon as possible. > >draft-ietf-rfc4420-bis-02.txt I assume that you mean draft-ietf-ccamp-rfc4420bis-02.txt. >This is the revision to RFC 4420 to fix the TLV encoding to be >consistent with the previous RSVP-TE RFCs. The fix is to the >interpretation of the Length field. >Although we might not expect much in the way of review comments for >this I-D, it would be very helpful if you could read the I-D, point >out any typos, and send a note to say that you have read the >document and believe it is ready for publication. Only a minor suggestion here: I suggest moving the rational for the updated provided from section 14 to section 1. Specifically: - drop section 14 - section 1, 1st paragraph: drop "See Section 14 for a summary of changes." and add: Prior to the change, the Length field indicated the length of the Value field only. After the change, as described in Section 3, the Length field indicates the length of the whole TLV. This change means that this document is consistent with the subobject format defined in [RFC3209] and the TLV format defined in [RFC3471]. Lou >Please send your reviews to the list by 12 noon GMT, April 26, 2008. > >Thanks, >Adrian > >PS, I'll be notifying the MPLS mailing list of these two last calls. > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2008 18:14:40 +0000 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <55FAFC06-9634-46AD-AD78-E0CF6CF2A6B8@redback.com> Cc: OSPF List , Alan Davey , Vishwas Manral , David Ward , Ross Callon , CCAMP List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: OSPF WG Last Call for Traffic Engineering Extensions to OSPF version 3 - draft-ietf-ospf-ospfv3-traffic-10.txt Date: Thu, 17 Apr 2008 14:13:19 -0400 To: Acee Lindem The WG last call has completed and I've posted a new version incorporating Adrian's comments. We'll move on to AD review with this draft. Thanks, Acee On Mar 31, 2008, at 1:36 PM, Acee Lindem wrote: > We've WG last called this draft in the past and we're going to do > it again now. After some deliberations we've made the decision to > go forward with this document with the two existing implementations > and forgo the request for interoperability testing. The WG last > call will be begin today and end April 15, 2008 at 12:00 AM EDT. > Thanks, > Acee Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2008 15:26:29 +0000 Message-ID: <0b5b01c8a09f$0146a3b0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft communication to the MEF Date: Thu, 17 Apr 2008 16:14:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Deborah and I took an action to send a communication to the MEF about our work with Ethernet to address their UNI and Service requirements. Now that we have WG drafts on the topics, we have prepared the attached. Please let me know if you have any comments. Thanks, Deborah and Adrian === Communication to the MEF from the IETF's CCAMP Working Group The IETF's CCAMP working group would like to inform the MEF of work it is carrying out to apply GMPLS protocols to the requirements of the Ethernet UNI and Ethernet service spectrum defined by the MEF. GMPLS is a family of IP-based protocols developed within the IETF and applicable to a range of technologies from packet switched networks (such as MPLS), through layer 2 networks (such as ATM, Frame Relay, and Ethernet), to optical networks (like TDM and WDM). We would like to draw your intention to the following Internet-Drafts that we are working on. We would welcome any feedback from your members on the requirements, details of the solutions proposed, or applicability of our work. "Ethernet Traffic Parameters" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-04.txt "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-00.txt "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-00.txt "GMPLS Ethernet Label Switching Architecture and Framework" http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-01.txt Best regards, Adrian Farrel and Deborah Brungard IETF CCAMP Working Group Co-Chairs Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 17 Apr 2008 09:13:53 +0000 Message-ID: <0a7a01c8a06b$0b4c6540$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Re: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt Date: Thu, 17 Apr 2008 10:01:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit More editorial nits thanks to Deborah. Adrian ----- Original Message ----- From: To: Cc: Sent: Wednesday, April 16, 2008 11:30 PM Subject: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt >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 : Analysis of Inter-domain Label Switched Path (LSP) > Recovery > Author(s) : T. Takeda, et al. > Filename : draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt > Pages : 25 > Date : 2008-04-16 > > Protection and recovery are important features of service offerings > in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) > networks. Increasingly, MPLS and GMPLS networks are being extended > from single domain scope to multi-domain environments. > > Various schemes and processes have been developed to establish Label > Switched Paths (LSPs) in multi-domain environments. These are > discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol > Label Switching Traffic Engineering. > > This document analyzes the application of these techniques to > protection and recovery in multi-domain networks. The main focus for > this document is on establishing end-to-end diverse Traffic > Engineering (TE) LSPs in multi-domain networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Apr 2008 22:32:49 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt Message-Id: <20080416223001.668D528C3E3@core3.amsl.com> Date: Wed, 16 Apr 2008 15:30:01 -0700 (PDT) --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 : Analysis of Inter-domain Label Switched Path (LSP) Recovery Author(s) : T. Takeda, et al. Filename : draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt Pages : 25 Date : 2008-04-16 Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments. Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering. This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. Takeda et al. Expires October 2008 [page 1] draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt April 2008 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-05.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-inter-domain-recovery-analysis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-16151923.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 16 Apr 2008 22:32:41 +0000 Message-ID: <48067D98.2080602@lab.ntt.co.jp> Date: Thu, 17 Apr 2008 07:28:40 +0900 From: Kohei Shiomoto User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Ccamp (E-mail)" Subject: MPLS2008 - CALL FOR PRESENTATIONS Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit MPLS 2008 INTERNATIONAL CONFERENCE http://www.mpls2008.com OCTOBER 19-22, 2008, WASHINGTON, DC For detailed CFP visit: http://www.isocore.com/mpls2008/call_for_papers/cfp.htm On line Submissions: http://www.isocore.com/mpls2008/call_for_papers/submissions.htm Deadline for submission of presentation proposals: May 2, 2008 CALL FOR PRESENTATION =========================== MPLS 2008 International Conference (http://www.mpls2008.com), the 11th Annual International Conference on MPLS and Related Technologies, will be held October 19 - 22, 2008, in Washington, DC. The Program Committee of MPLS2008 is soliciting presentation proposals for the conference. The committee seeks original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations addressing new technologies and operational experience are solicited from network equipment vendors, service providers, the research community, government agencies, and enterprise users. The deadline for submission of presentation proposals has been extended to May 2, 2008. Submissions in the form of extended summaries (200-500 words) are solicited. In your summary, please state succinctly what the original contribution of your presentation is. Please submit the proposals to the Submissions page: http://www.isocore.com/mpls2008/call_for_papers/submissions.htm This year's conference will include, but will not be limited to the following topics: MPLS Transport Profiles MPLS in multi-area and multi-AS networks Carrier/Metro Ethernet services Wireless and Mobility Backhauling Ethernet Operations, Administration, and Maintenance Multicast Enterprise / Next Generation MVPN Point-to-multipoint MPLS and applications Multicast in MPLS Pseudowires and VPLS Single and Multi-hop Pseudowire placement, setup, and management Providing QoS in MPLS networks OAM and network management for MPLS networks Voice over IP/MPLS IMS and IPTV over MPLS Triple-play applications on MPLS MPLS-enabled Advanced services and converged networks Interworking and migration for MPLS and GMPLS Multi-layer networks and integration with non-packet technologies Deploying, interworking, and operating L2 and L3 MPLS VPNs MPLS deployment experience: scaling, performance, and security Testing: MPLS test tools and certification experience Protection, restoration, and reliability for MPLS and Psuedowires Network processors for MPLS and GMPLS MPLS/GMPLS control plane resilience, scaling and robustness MPLS TE applications of the Path Computation Element (PCE) MPLS applications in the access network MPLS and IPv6 MPLS in the Enterprise Arena MPLS Support for Ethernet Services and VPLS GMPLS Applications (L1 VPNs, ASON, Optical Internetworking, NNI/UNI) Fast IP Routing Convergence versus MPLS Loop free networking High Availability (Graceful Restart, Non-Stop Routing, In-Service Software Upgrades, etc) MPLS in the Mobile Trunking Space MPLS Applications for Mobile Access Optimization MPLS Experience in Government Networks MPLS Experience in Research Networks Security features for MPLS and Pseudowires Congestion Notification and processing for MPLS and Pseudowires (G)MPLS interaction with routing protocols Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 15 Apr 2008 01:45:11 +0000 Reply-To: From: "Weiqiang Sun" To: "'Adrian Farrel'" Cc: Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-dppm-01.txt Date: Tue, 15 Apr 2008 09:41:42 +0800 Organization: Shanghai Jiao Tong University Message-ID: <001801c89e99$db3f6910$91be3b30$@edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcieU6uwKbe5AGKbRtiqiQDlFJ4BngARaUBA Content-Language: zh-cn Hi Adrian and all, We have fixed the editorial issues pointed out by Adrian. Further comments will be highly appreciated. Cheers, Weiqiang -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, April 15, 2008 1:00 AM To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lsp-dppm-01.txt 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 : Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in Generalized MPLS Networks Author(s) : W. Sun, G. Zhang, J. Gao, G. Xie, R. Papneja, B. Gu, X. Wei Filename : draft-ietf-ccamp-lsp-dppm-01.txt Pages : 39 Date : 2008-4-14 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for the future data transmission network. The GMPLS has been developed to control and cooperate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro area. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the dynamical LSP setup/release performance. These metrics can depict the features of the GMPLS network in LSP dynamic provisioning. They can also be used in operational networks for carriers to monitor the control plane performance in realtime. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-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. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Apr 2008 22:33:45 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-mef-uni-00.txt Message-Id: <20080414223001.B0D7428C1DB@core3.amsl.com> Date: Mon, 14 Apr 2008 15:30:01 -0700 (PDT) --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, et al. Filename : draft-ietf-ccamp-gmpls-mef-uni-00.txt Pages : 11 Date : 2008-04-14 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 to 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. 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-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-ietf-ccamp-gmpls-mef-uni-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14151708.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Apr 2008 22:33:37 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-00.txt Message-Id: <20080414223001.A81EF28C1C9@core3.amsl.com> Date: Mon, 14 Apr 2008 15:30:01 -0700 (PDT) --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, et al. Filename : draft-ietf-ccamp-gmpls-ether-svcs-00.txt Pages : 22 Date : 2008-04-14 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 required to 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 service and Ethernet virtual private line service. Support for MEF and ITU defined parameters are also covered. Some of the extensions defined in this document are generic in nature and not specific to Ethernet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-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-ietf-ccamp-gmpls-ether-svcs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14151706.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Apr 2008 19:02:40 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt Message-Id: <20080414190001.E2DB328C1CE@core3.amsl.com> Date: Mon, 14 Apr 2008 12:00:01 -0700 (PDT) --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 : GMPLS control of Ethernet Author(s) : D. Fedyk, D. Allan, H. Shah, N. Bitar, A. Takacs Filename : draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt Pages : 27 Date : 2008-4-14 This memo is complementary to [ARCH] and describes how a GMPLS control plane may be applied to the Provider Backbone Bridges Traffic Engineering (PBB-TE) [IEEE 802.1Qay] amendment to 802.1Q and how GMPLS can be used to configure VLAN-aware Ethernet switches in order to establish Ethernet point to point (P2P) and P2MP MAC switched paths and P2P/P2MP VID based trees. This document supports, but does not modify, the standard IEEE data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-pbb-te-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-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-4-14114629.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Apr 2008 17:03:14 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lsp-dppm-01.txt Message-Id: <20080414170001.309853A6E3E@core3.amsl.com> Date: Mon, 14 Apr 2008 10:00:01 -0700 (PDT) --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 : Label Switched Path (LSP) Dynamical Provisioning Performance Metrics in Generalized MPLS Networks Author(s) : W. Sun, G. Zhang, J. Gao, G. Xie, R. Papneja, B. Gu, X. Wei Filename : draft-ietf-ccamp-lsp-dppm-01.txt Pages : 39 Date : 2008-4-14 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for the future data transmission network. The GMPLS has been developed to control and cooperate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro area. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the dynamical LSP setup/release performance. These metrics can depict the features of the GMPLS network in LSP dynamic provisioning. They can also be used in operational networks for carriers to monitor the control plane performance in realtime. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-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-lsp-dppm-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-4-14095648.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Apr 2008 12:02:59 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-04.txt Message-Id: <20080414120001.9DC8E28C2B6@core3.amsl.com> Date: Mon, 14 Apr 2008 05:00:01 -0700 (PDT) --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 : Ethernet Traffic Parameters Author(s) : D. Papadimitriou, I. Property Filename : draft-ietf-ccamp-ethernet-traffic-parameters-04.txt Pages : 13 Date : 2008-04-13 This document describes the Metro Ethernet Forum (MEF) - specific Ethernet Traffic Parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-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-ethernet-traffic-parameters-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14045440.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Apr 2008 10:58:11 +0000 Message-ID: <069301c89e1e$4c6516c0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ross Callon" Cc: , Subject: Please publish draft-ietf-ccamp-isis-interas-te-extension-02.txt Date: Mon, 14 Apr 2008 11:57:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Proto-write-up for draft-ietf-ccamp-isis-interas-te-extension-02.txt Intended status : Standards Track This draft may be considered in parallel with draft-ietf-ccamp-ospf- interas-te-extension-05.txt, but it is *not* required to process the I-Ds in parallel. > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Adrian Farrel is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? I-D has had a good level of discussions and review in CCAMP and in the ISIS working group. In particular, it received considerable input from IS-IS experts in its early stages. Document Shepherd believes reviews to have been adequate. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. The document is sound. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Consensus is good. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? IANA section checked. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. Traffic engineering extensions to IS-IS have been defined and are used in support of MPLS-TE and GMPLS. The extensions provide a way of encoding the TE information for TE-enabled links within the network and flooding this information within an IS-IS area. When establishing inter-AS MPLS-TE or GMPLS Label Switched Paths (LSPs) a path is computed one AS at a time. This path may be computed using conventional techniques at the first ASBR of each AS, or by using Path Computation Elements (PCEs) as specified by the PCE working group. In either case, if two ASes are connected by more than one inter-AS TE link, it is helpful for the computation point to know the capabilities of the available TE links in order to select a suitable path. This document describes extensions to IS-IS to flood TE information about inter-AS links. A new IS-IS top-level TLV is defined for this purpose in order to support transparent backward compatibility and to support the potential use of separate IS-IS flooding instances. This document does not propose or define any mechanisms to advertise any other extra-AS TE information. This means that there is no proposal to distribute TE information from one AS within another AS. Nor is there any mechanism proposed to define or distribute "TE reachability" information. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? WG has good consensus. Two points arose during working group discussions that are worth noting. Both points were resolved satisfactorily. 1. Separate IS-IS Instances The original proposal in this I-D used extensions to the existing IS-IS top-level TLV used for TE information distribution. This has been changed after requests from the ISIS working group to use a different top-level TLV enabling easier backward compatibility and more flexible transition to multi-instance IS-IS in the future. 2. No Change to Scaling/Flooding Paradigm Many people within CCAMP expressed a concern that the I-D might indicate the intention to distribute TE information from one AS into another AS. This would obviously break the as-based scaling and confidentiality paradigms of IGP routing. The authors were very clear that this was not the intention and have added a specific section to cover non-objectives. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? There is a known implementation of the extensions. There was also good support for the work from other vendors with the same objectives. Document review by the IS-IS working group deserves special mention for its care and thoroughness. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Apr 2008 10:30:56 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-isis-interas-te-extension-02.txt Message-Id: <20080414103001.2D23B3A6E34@core3.amsl.com> Date: Mon, 14 Apr 2008 03:30:01 -0700 (PDT) --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 : ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, et al. Filename : draft-ietf-ccamp-isis-interas-te-extension-02.txt Pages : 18 Date : 2008-04-14 This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter- AS TE path computation. No support for flooding TE information from outside the AS is proposed or defined in this document.Conventions used in this document 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-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-isis-interas-te-extension-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14032945.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Apr 2008 10:24:13 +0000 Message-ID: <067501c89e19$803447a0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ross Callon" Cc: , Subject: Please publish draft-ietf-ccamp-ospf-interas-te-extension-05.txt Date: Mon, 14 Apr 2008 11:22:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Proto-write-up for draft-ietf-ccamp-ospf-interas-te-extension-05.txt Intended status : Standards Track This draft may be considered in parallel with draft-ietf-ccamp-isis- interas-te-extension-02.txt, but it is *not* required to process the I-Ds in parallel. > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Adrian Farrel is the document shepherd. He has personally reviewed the I-D and believes it is ready for forwarding to the IESG for publication. > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? I-D has had a good level of discussions and review in CCAMP and in the OSPF working group. In particular, it received considerable input from OSPF experts in its early stages. Document Shepherd believes reviews to have been adequate. > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? No concerns. > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. The document is sound. > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Consensus is good. > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? All checks made. > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. References split. No downrefs. > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? IANA section checked. > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? No such formal language is used. > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. Traffic engineering extensions to OSPFv2 and OSPFv3 have been defined and are used in support of MPLS-TE and GMPLS. The extensions provide a way of encoding the TE information for TE-enabled links within the network and flooding this information within an OSPF area. When establishing inter-AS MPLS-TE or GMPLS Label Switched Paths (LSPs) a path is computed one AS at a time. This path may be computed using conventional techniques at the first ASBR of each AS, or by using Path Computation Elements (PCEs) as specified by the PCE working group. In either case, if two ASes are connected by more than one inter-AS TE link, it is helpful for the computation point to know the capabilities of the available TE links in order to select a suitable path. This document describes extensions to OSPFv2 and OSPFv3 to flood TE information about inter-AS links. New LSAs are defined for this purpose in order to support transparent backward compatibility and to support the potential use of separate OSPF flooding instances. This document does not propose or define any mechanisms to advertise any other extra-AS TE information. This means that there is no proposal to distribute TE information from one AS within another AS. Nor is there any mechanism proposed to define or distribute "TE reachability" information. > Working Group Summary > Was there anything in WG process that is worth noting? For > example, was there controversy about particular points or > were there decisions where the consensus was particularly > rough? WG has good consensus. Three points arose during working group discussions that are worth noting. All points were resolved satisfactorily. 1. OSPFv3 Support The OSPF working group requested that this I-D consider OSPFv3 as well as the OSPFv2 extensions that it was originally limited to. In return, the OSPF working group is last calling the OSPFv3-TE extensions that are a pre-requisite. 2. OSPFv2 Separate Opaque LSA The original proposal in this I-D used extensions to the OSPFv2 opaque LSA used from flooding information about intra-domain TE links. This has been changed after requests from the OSPF working group to use a different opaque LSA enabling easier backward compatibility and more flexible transition to multi-instance OSPF in the future. 3. No Change to Scaling/Flooding Paradigm Many people within CCAMP expressed a concern that the I-D might indicate the intention to distribute TE information from one AS into another AS. This would obviously break the as-based scaling and confidentiality paradigms of IGP routing. The authors were very clear that this was not the intention and have added a specific section to cover non-objectives. > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type or other expert review, > what was its course (briefly)? In the case of a Media Type > review, on what date was the request posted? There is a known implementation of the OSPFv2 extensions. There was also good support for the work from other vendors with the same objectives. There is no known implementation of the OSPFv3 extensions. Document review by Acee Lindem deserves special mention for its care and thoroughness. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 14 Apr 2008 09:18:41 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-05.txt Message-Id: <20080414091502.7425B3A69BB@core3.amsl.com> Date: Mon, 14 Apr 2008 02:15:02 -0700 (PDT) --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 : OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, et al. Filename : draft-ietf-ccamp-ospf-interas-te-extension-05.txt Pages : 17 Date : 2008-04-14 This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links which can be used to perform inter-AS TE path computation. No support for flooding TE information from outside the AS is proposed or defined in this document.Conventions used in this document 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-05.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-ospf-interas-te-extension-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-14021015.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 13 Apr 2008 11:50:54 +0000 Message-ID: <05a601c89d5c$97afebe0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Re: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt Date: Sun, 13 Apr 2008 12:50:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Changes are all editorial. We made some re-works to make the text clearer and easier to read. Cheers, Adrian ----- Original Message ----- From: To: Cc: Sent: Sunday, April 13, 2008 12:45 PM Subject: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt >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 : Analysis of Inter-domain Label Switched Path (LSP) > Recovery > Author(s) : T. Takeda, et al. > Filename : draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt > Pages : 25 > Date : 2008-04-13 > > Protection and recovery are important features of service provision > in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) > networks. Increasingly, MPLS and GMPLS networking is being widened > from single domain scope to operate in multi-domain environments. > > Various schemes and processes have been developed to establish Label > Switched Paths (LSPs) in multi-domain environments. These are > discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol > Label Switching Traffic Engineering. > > This document analyzes the application of these techniques to > protection and recovery in multi-domain networks. The main focus for > this document is on establishing end-to-end diverse Traffic > Engineering (TE) LSPs in multi-domain networks. > > Takeda et al. > > > > > Expires October 2008 > > > > > [page 1] > > draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt > > March 2008 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-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. > -------------------------------------------------------------------------------- > _______________________________________________ > 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 > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 13 Apr 2008 11:48:25 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt Message-Id: <20080413114501.7F56F28C1EF@core3.amsl.com> Date: Sun, 13 Apr 2008 04:45:01 -0700 (PDT) --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 : Analysis of Inter-domain Label Switched Path (LSP) Recovery Author(s) : T. Takeda, et al. Filename : draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt Pages : 25 Date : 2008-04-13 Protection and recovery are important features of service provision in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networking is being widened from single domain scope to operate in multi-domain environments. Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering. This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. Takeda et al. Expires October 2008 [page 1] draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt March 2008 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-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-inter-domain-recovery-analysis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-13043320.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Apr 2008 18:44:18 +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: Two more working group last calls Date: Fri, 11 Apr 2008 14:41:24 -0400 Message-ID: <23F9E58A916663488B3D12D1FE1A999F0125E53A@mdmxm03.ciena.com> Thread-Topic: Two more working group last calls thread-index: Acib5/AjlMfuuVZuTdOp/bApnFmTxQAGqG2A From: "Ong, Lyndon" To: "Adrian Farrel" , Hi Adrian, I've looked over draft-ietf-rfc4420-bis-02.txt and did not notice any typos. The new Length description looks like the equivalent text in RFC 3471, which we support. It looks ready for publication. Request that other editors check to make sure that their drafts are updated to have the same interpretation of the Length field as well. Cheers, Lyndon =20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Friday, April 11, 2008 8:13 AM To: ccamp@ops.ietf.org Subject: Two more working group last calls Hi, Sorry for the continued bombardment with reviewing activity. Here are two drafts that were discussed in Philadelphia with the intention to go to WG last call as soon as possible. draft-ietf-rfc4420-bis-02.txt This is the revision to RFC 4420 to fix the TLV encoding to be consistent with the previous RSVP-TE RFCs. The fix is to the interpretation of the Length field. Although we might not expect much in the way of review comments for this I-D, it would be very helpful if you could read the I-D, point out any typos, and send a note to say that you have read the document and believe it is ready for publication. draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt This I-D for asymmetrical bandwidth allocations on bidirectional LSPs has been moved into the WG from being an individual submission, and has been marked as "Experimental". The reasoning was: - This is clearly a draft that CCAMP needs to review, so it might as well be a CCAMP draft. - This is a "stake in the ground" for how this problem would be solved within RSVP-TE, but at this stage there are no known implementations and no-one considering implementation. Please send your reviews to the list by 12 noon GMT, April 26, 2008. Thanks, Adrian PS, I'll be notifying the MPLS mailing list of these two last calls.=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Apr 2008 15:20:11 +0000 Message-ID: <049501c89be7$1ed42770$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Two more working group last calls Date: Fri, 11 Apr 2008 16:12:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Sorry for the continued bombardment with reviewing activity. Here are two drafts that were discussed in Philadelphia with the intention to go to WG last call as soon as possible. draft-ietf-rfc4420-bis-02.txt This is the revision to RFC 4420 to fix the TLV encoding to be consistent with the previous RSVP-TE RFCs. The fix is to the interpretation of the Length field. Although we might not expect much in the way of review comments for this I-D, it would be very helpful if you could read the I-D, point out any typos, and send a note to say that you have read the document and believe it is ready for publication. draft-ietf-ccamp-asymm-bw-bidir-lsps-00.txt This I-D for asymmetrical bandwidth allocations on bidirectional LSPs has been moved into the WG from being an individual submission, and has been marked as "Experimental". The reasoning was: - This is clearly a draft that CCAMP needs to review, so it might as well be a CCAMP draft. - This is a "stake in the ground" for how this problem would be solved within RSVP-TE, but at this stage there are no known implementations and no-one considering implementation. Please send your reviews to the list by 12 noon GMT, April 26, 2008. Thanks, Adrian PS, I'll be notifying the MPLS mailing list of these two last calls. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Apr 2008 12:01:16 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-04.txt Message-Id: <20080411120001.5DD233A6F21@core3.amsl.com> Date: Fri, 11 Apr 2008 05:00:01 -0700 (PDT) --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 : OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, R. Zhang Filename : draft-ietf-ccamp-ospf-interas-te-extension-04.txt Pages : 18 Date : 2008-04-11 This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links which can be used to perform inter-AS TE path computation. No support for flooding TE information from outside the AS is proposed or defined in this document. Conventions used in this document 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-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-ospf-interas-te-extension-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-11044800.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Apr 2008 11:55:59 +0000 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: CCAMP List , OSPF List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-03.txt Date: Fri, 11 Apr 2008 07:55:12 -0400 To: Mach Chen Hi Mach, On Apr 11, 2008, at 1:16 AM, Mach Chen wrote: > Hi Acee, > > On 2008-04-11, at 03:42:09 Acee Lindem wrote: >> Hi Mach, >> My comments have been addressed to my satisfaction. Depending on who >> reviews it, you may get requests to expand some more of the acronyms >> on first use during the Gen-ART review. > > OK, I will try again. I'm happy with it as it is. I'd wait until the Gen-ART review since you may get additional comments. Thanks, Acee > > Thanks, > > Mach > >> Thanks, >> Acee >> On Apr 10, 2008, at 3:00 AM, Internet-Drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Common Control and Measurement >>> Plane Working Group of the IETF. >>> >>> >>> Title : OSPF Extensions in Support of Inter-AS >>> Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) >>> Traffic Engineering >>> Author(s) : M. Chen, R. Zhang >>> Filename : draft-ietf-ccamp-ospf-interas-te-extension-03.txt >>> Pages : 18 >>> Date : 2008-04-09 >>> >>> This document describes extensions to the OSPF version 2 and 3 >>> protocols to support Multiprotocol Label Switching (MPLS) and >>> Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple >>> Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined >>> for the flooding of TE information about inter-AS links which can be >>> used to perform inter-AS TE path computation. >>> >>> >>> >>> >>> No support for flooding TE information from outside the AS is >>> proposed or defined in this document. >>> >>> Conventions used in this document >>> >>> 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]. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- >>> te-extension-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. >>> Content-Type: text/plain >>> Content-ID: <2008-04-09234919.I-D@ietf.org> >> > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Apr 2008 11:07:38 +0000 Message-ID: <040901c89bc3$d2539480$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Conclusion on Ethernet I-Ds Date: Fri, 11 Apr 2008 12:04:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, I think we are there. Authors, please submit your I-Ds with the name changes shown below. In this first submission as WG I-Ds, please don't make any other changes except for dates, filenames, and anything needed to pass idnits (http://tools.ietf.org/tools/idnits/). Some of you have received comments during the polling process that you will want to address in subsequent revisions. draft-imajuku-ccamp-ethernet-gmpls-req-01.txt --->draft-ietf-ccamp-ethernet-gmpls-provider-reqs-00.txt draft-fedyk-gmpls-ethernet-pbb-te-02.txt --->draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt draft-berger-ccamp-gmpls-mef-uni-02.txt --->draft-ietf-ccamp-gmpls-mef-uni-00.txt draft-berger-ccamp-gmpls-ether-svcs-01.txt --->draft-ietf-ccamp-gmpls-ether-svcs-00.txt Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 11 Apr 2008 05:18:39 +0000 Date: Fri, 11 Apr 2008 13:16:26 +0800 From: Mach Chen Subject: Re: Re: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-03.txt To: Acee Lindem Cc: CCAMP List , OSPF List Message-id: <200804111316248393389@huawei.com> Organization: Huawei MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi Acee, On 2008-04-11, at 03:42:09 Acee Lindem wrote: >Hi Mach, >My comments have been addressed to my satisfaction. Depending on who >reviews it, you may get requests to expand some more of the acronyms >on first use during the Gen-ART review. OK, I will try again. Thanks, Mach >Thanks, >Acee >On Apr 10, 2008, at 3:00 AM, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Common Control and Measurement >> Plane Working Group of the IETF. >> >> >> Title : OSPF Extensions in Support of Inter-AS >> Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) >> Traffic Engineering >> Author(s) : M. Chen, R. Zhang >> Filename : draft-ietf-ccamp-ospf-interas-te-extension-03.txt >> Pages : 18 >> Date : 2008-04-09 >> >> This document describes extensions to the OSPF version 2 and 3 >> protocols to support Multiprotocol Label Switching (MPLS) and >> Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple >> Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined >> for the flooding of TE information about inter-AS links which can be >> used to perform inter-AS TE path computation. >> >> >> >> >> No support for flooding TE information from outside the AS is >> proposed or defined in this document. >> >> Conventions used in this document >> >> 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]. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- >> te-extension-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. >> Content-Type: text/plain >> Content-ID: <2008-04-09234919.I-D@ietf.org> > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Apr 2008 20:56:45 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89B4D.2792BC99" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Thu, 10 Apr 2008 23:54:44 +0300 Message-ID: Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AcibIE66qdwgwKVYRBiqrraNeBTbMgALEZAQ From: "Nurit Sprecher" To: "ext Igor Bryskin" , "Attila Takacs" , "Don Fedyk" , , , This is a multi-part message in MIME format. ------_=_NextPart_001_01C89B4D.2792BC99 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am not sure any more how we got into this discussion, but I am pretty much convinced that this does not relate to the GMPLS context.=20 The question was on the adoption of the draft on GMPLS for a data plane that is defined by the IEEE (802.1Qay). This is the way it is defined by the IEEE and we provide a control plane to control it. I am pretty sure that the use of the control plane for PBB-TE will ensure a consistent behavior of the PBB-TE network.=20 Personally I am in favor of making this draft an IETF one, and I hope you are all as well. Best regards, Nurit =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Igor Bryskin Sent: Thursday, April 10, 2008 18:13 To: Attila Takacs; Don Fedyk; neil.2.harrison@bt.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: Re: Continued Poll for Adoption of Ethernet I-Ds =20 Hi Attila, Please, see in line. ----- Original Message ---- From: Attila Takacs To: Igor Bryskin ; Don Fedyk ; neil.2.harrison@bt.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Sent: Thursday, April 10, 2008 2:54:21 AM Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Hi Igor, =20 But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain. =20 =20 Unfortunately, leaking from PBB to PBB-TE does not necessarily means immediate discarding of PBB frames. Due to the VLAN separation between PBB and PBB-TE, there is no clear layering here. Hence leaking can essentially mean that the VID of a bridged (PBB) frame is changed to a VID used for explicitly routed connections (PBB-TE). This does not necessarily means that the frame will be dropped. It is a valid assumption that the MAC address of the PBB frame is configured in the PBB-TE region as well and as such leakig PBB traffic will be forwarded as if it would belong to an explicitly routed connection. IB>> In order for a packet, leaking from PBB to PBB_TE not be dropped, it is necessary for the triplet from PBB MAC header (SA-DA-VID) to match one of configured on the node PBB-TE connections. Even if one assumes that this is possible, it is highly unlikely to be the case on the next along the connection PBB-TE node. Hence the packet will be dropped either immediately or on the next PBB-TE node. Cheers, Igor=20 Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation. =20 I think this is not necessary true, if one allocates the whole VLAN space to PBB-TE then there will be no bridged traffic in the network. As a consequence no leaking and no other cross effects is to be expected. =20 Best regards, Attila =20 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 ------_=_NextPart_001_01C89B4D.2792BC99 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I am not sure = any more how we got into this discussion, but I am pretty much convinced that = this does not relate to the GMPLS context.

The question was = on the adoption of the draft on GMPLS for a data plane that is defined by the = IEEE (802.1Qay). This is the way it is defined by the IEEE and we provide a = control plane to control it. I am pretty sure that the use of the control plane = for PBB-TE will ensure a consistent behavior of the PBB-TE network. =

Personally I am = in favor of making this draft an IETF one, and I hope you are all as = well.

Best = regards,

Nurit<= /span>

 =

From: owner-ccamp@ops.ietf.org = [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Igor Bryskin
Sent: Thursday, April 10, = 2008 18:13
To: Attila Takacs; Don = Fedyk; neil.2.harrison@bt.com; adrian@olddog.co.uk; ccamp@ops.ietf.org
Subject: Re: Continued = Poll for Adoption of Ethernet I-Ds

 

Hi Attila,

Please, see in line.

----- Original = Message ----
From: Attila Takacs <Attila.Takacs@ericsson.com>
To: Igor Bryskin <i_bryskin@yahoo.com>; Don Fedyk <dwfedyk@nortel.com>; neil.2.harrison@bt.com; adrian@olddog.co.uk; = ccamp@ops.ietf.org
Sent: Thursday, April 10, 2008 2:54:21 AM
Subject: RE: Continued Poll for Adoption of Ethernet = I-Ds

Hi = Igor,

 

=

But how the separation of VLAN ID space would = help in this case? If PBB packets are leaked into PBB-TE they will be = immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows = nothing about PBB-TE anyway the packets will be flooded across the PBB = domain.  

 

Unfortunately, = leaking from PBB to PBB-TE does not necessarily means immediate discarding of = PBB frames. Due to the VLAN separation between PBB and PBB-TE, there is = no clear layering here. Hence leaking can essentially mean that the VID = of a bridged (PBB) frame is changed to a VID used for explicitly routed connections (PBB-TE). This does not necessarily means that = the frame will be dropped. It is a valid assumption that the MAC address of = the PBB frame is configured in the PBB-TE region as well and as such leakig PBB = traffic will be forwarded as if it would belong to an explicitly routed connection.

IB>> In order for a packet, leaking from PBB to PBB_TE not be = dropped, it is necessary for the triplet from PBB MAC header (SA-DA-VID) to match = one of configured on the node PBB-TE connections. Even if one assumes that this = is possible, it is highly unlikely to be the case on the next along the = connection PBB-TE node. Hence the packet will be dropped either immediately or on = the next PBB-TE node.

Cheers,
Igor

=

Note that what I just wrote is true = regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence = there is no architectural need for the VLANID space separation.
  

I think this is = not necessary true, if one allocates the whole VLAN space to PBB-TE then = there will be no bridged traffic in the network. As a consequence no leaking and no = other cross effects is to be expected.

 

Best = regards,

Attila

 


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

------_=_NextPart_001_01C89B4D.2792BC99-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Apr 2008 19:44:52 +0000 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6CFC2583-D0A3-4A77-B048-5768FF1EF5DA@redback.com> Cc: CCAMP List , OSPF List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-03.txt Date: Thu, 10 Apr 2008 15:42:05 -0400 To: Mach Chen Hi Mach, My comments have been addressed to my satisfaction. Depending on who reviews it, you may get requests to expand some more of the acronyms on first use during the Gen-ART review. Thanks, Acee On Apr 10, 2008, at 3:00 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Control and Measurement > Plane Working Group of the IETF. > > > Title : OSPF Extensions in Support of Inter-AS > Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) > Traffic Engineering > Author(s) : M. Chen, R. Zhang > Filename : draft-ietf-ccamp-ospf-interas-te-extension-03.txt > Pages : 18 > Date : 2008-04-09 > > This document describes extensions to the OSPF version 2 and 3 > protocols to support Multiprotocol Label Switching (MPLS) and > Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple > Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined > for the flooding of TE information about inter-AS links which can be > used to perform inter-AS TE path computation. > > > > > No support for flooding TE information from outside the AS is > proposed or defined in this document. > > Conventions used in this document > > 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]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- > te-extension-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. > Content-Type: text/plain > Content-ID: <2008-04-09234919.I-D@ietf.org> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Apr 2008 15:16:17 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=T/RTyi/GBZCETeVADDBL7DHnkspF3uBM0fKrZGpSs3zxSA3qpL3bJwpf2wg7uSTgLz8wChhlJ4SARr4fxzbcBC8VnAykOITaxHQ/g1hYXLSM4tvhafUTL30+tzN4CC7poe555oCx1EY7LpgKf19Wis3n3+Zr+0jDl7razALG6I4=; Date: Thu, 10 Apr 2008 08:13:09 -0700 (PDT) From: Igor Bryskin Subject: Re: Continued Poll for Adoption of Ethernet I-Ds To: Attila Takacs , Don Fedyk , neil.2.harrison@bt.com, adrian@olddog.co.uk, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-608773676-1207840389=:46599" Message-ID: <143200.46599.qm@web36807.mail.mud.yahoo.com> --0-608773676-1207840389=:46599 Content-Type: text/plain; charset=us-ascii Hi Attila, Please, see in line. ----- Original Message ---- From: Attila Takacs To: Igor Bryskin ; Don Fedyk ; neil.2.harrison@bt.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Sent: Thursday, April 10, 2008 2:54:21 AM Subject: RE: Continued Poll for Adoption of Ethernet I-Ds DIV { MARGIN:0px;} Hi Igor, But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain. Unfortunately, leaking from PBB to PBB-TE does not necessarily means immediate discarding of PBB frames. Due to the VLAN separation between PBB and PBB-TE, there is no clear layering here. Hence leaking can essentially mean that the VID of a bridged (PBB) frame is changed to a VID used for explicitly routed connections (PBB-TE). This does not necessarily means that the frame will be dropped. It is a valid assumption that the MAC address of the PBB frame is configured in the PBB-TE region as well and as such leakig PBB traffic will be forwarded as if it would belong to an explicitly routed connection. IB>> In order for a packet, leaking from PBB to PBB_TE not be dropped, it is necessary for the triplet from PBB MAC header (SA-DA-VID) to match one of configured on the node PBB-TE connections. Even if one assumes that this is possible, it is highly unlikely to be the case on the next along the connection PBB-TE node. Hence the packet will be dropped either immediately or on the next PBB-TE node. Cheers, Igor Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation. I think this is not necessary true, if one allocates the whole VLAN space to PBB-TE then there will be no bridged traffic in the network. As a consequence no leaking and no other cross effects is to be expected. Best regards, Attila __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-608773676-1207840389=:46599 Content-Type: text/html; charset=us-ascii
Hi Attila,

Please, see in line.

----- Original Message ----
From: Attila Takacs <Attila.Takacs@ericsson.com>
To: Igor Bryskin <i_bryskin@yahoo.com>; Don Fedyk <dwfedyk@nortel.com>; neil.2.harrison@bt.com; adrian@olddog.co.uk; ccamp@ops.ietf.org
Sent: Thursday, April 10, 2008 2:54:21 AM
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

Hi Igor,
 
But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain.  
 
Unfortunately, leaking from PBB to PBB-TE does not necessarily means immediate discarding of PBB frames. Due to the VLAN separation between PBB and PBB-TE, there is no clear layering here. Hence leaking can essentially mean that the VID of a bridged (PBB) frame is changed to a VID used for explicitly routed connections (PBB-TE). This does not necessarily means that the frame will be dropped. It is a valid assumption that the MAC address of the PBB frame is configured in the PBB-TE region as well and as such leakig PBB traffic will be forwarded as if it would belong to an explicitly routed connection.

IB>> In order for a packet, leaking from PBB to PBB_TE not be dropped, it is necessary for the triplet from PBB MAC header (SA-DA-VID) to match one of configured on the node PBB-TE connections. Even if one assumes that this is possible, it is highly unlikely to be the case on the next along the connection PBB-TE node. Hence the packet will be dropped either immediately or on the next PBB-TE node.

Cheers,
Igor
Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation.
  
I think this is not necessary true, if one allocates the whole VLAN space to PBB-TE then there will be no bridged traffic in the network. As a consequence no leaking and no other cross effects is to be expected.
 
Best regards,
Attila


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-608773676-1207840389=:46599-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Apr 2008 08:46:08 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89AE7.032223C2" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Thu, 10 Apr 2008 09:43:02 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0239F1C3@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciZvdU00p78wmPjQTmVUbI9h7E4/wAUo6cgAA2egTAADV+mQAAWX7cwAAQmeFA= From: To: , , , , , This is a multi-part message in MIME format. ------_=_NextPart_001_01C89AE7.032223C2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed Attila.....let's not get this out of proportion......the key thing is to understand that we are dealing with different layer networks in PBB (cl-ps) and PBB-TE (co-ps) networks and getting this right is then largely a matter of good design and implementation. If we want to throw stones at the underlying arch issue I can think of another technology close to home that provides a far richer set of problems in this respect ;-) =20 regards, Neil -----Original Message----- From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]=20 Sent: 10 April 2008 07:55 To: Nurit Sprecher; ext Don Fedyk; Harrison,N,Neil,DMF R; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Hi all, =20 I do agree that a clear/single network operation mode is desirable in practice, however, as Nurit pointed out, IEEE 802.1Qay is more permissive in this regard.=20 However, if every VLAN is allocated for PBB-TE, which is a valid configuration in 802.1Qay, then the network will operate in a clear co-ps mode without side effects due to parallel PBB operation. =20 On the other hand, I can imagine that in some cases having a PBB bridged VLAN used, e.g.,to create connectivity for control traffic, would be desirable and I do not see a problem with this until it does not carry customer traffic. =20 I think we do not need to do anything in here; the level of permitted coexistence of PBB and PBB-TE is a network operational issue, and it does not really affect the GMPLS extensions much more than probably adding support to ensure that the VLANs configured for PBB-TE are the same throughout the network. =20 Best regards, Attila =20 _____ =20 From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit Sprecher Sent: Wednesday, April 09, 2008 10:02 PM To: ext Don Fedyk; neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Hi all, So maybe this is something to be commented to the IEEE........they operate hybrid PBB/PBB-TE networks.=20 In this draft we provide a control plane to the dataplane that is defined by the IEEE, and specifically we define a control plane for PBB-TE as defined by the IEEE 802.1Qay.=20 Nurit =20 _____ =20 From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Don Fedyk Sent: Wednesday, April 09, 2008 17:38 To: neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: RE: Continued Poll for Adoption of Ethernet I-Ds =20 Hi Igor and Neil =20 See below, IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.=20 What am I missing here? Thanks, Igor=20 =20 NH=3D> Excellent question. I have made exactly this same observation in the past. In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks. I think there are 2 reasons for this: =20 - Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks. So this issue may not be so obvious to many folks in IEEE. Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling. However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks. So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true. =20 - Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware. Maybe some of the Ethernet hardware experts can provide further clarification here. =20 =20 Disclaimer I'm not a hardware expert but Neil is correct there is currently no "context" within an Ethernet Frame that could separate the PBB B-VID space and the PBB-TE B-VID space. If these spaces used overlapping B-VID values there would be know way to know by looking at the Frame. In fact one of the attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA). A result is a switch cannot tell the context implicitly.=20 One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to.=20 =20 Between the PBB B-MAC (server) and the PBB C-MAC (client) it is clear looking at a frame. Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing that separates the behavior. =20 =20 Regards, Don=20 =20 regards, Neil ------_=_NextPart_001_01C89AE7.032223C2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Agreed=20 Attila.....let's not get this out of proportion......the key = thing is to=20 understand that we are dealing with different layer networks in PBB = (cl-ps) and=20 PBB-TE (co-ps) networks and getting this right is then largely a matter = of good=20 design and implementation.  If we want to throw stones at the underlying arch issue I can think of = another=20 technology close to home that provides a far=20 richer set of problems in this respect=20 ;-)
 
regards, Neil
-----Original Message-----
From: = Attila Takacs=20 [mailto:Attila.Takacs@ericsson.com]
Sent: 10 April 2008=20 07:55
To: Nurit Sprecher; ext Don Fedyk; Harrison,N,Neil,DMF = R;=20 i_bryskin@yahoo.com; adrian@olddog.co.uk;=20 ccamp@ops.ietf.org
Subject: RE: Continued Poll for Adoption = of=20 Ethernet I-Ds

Hi=20 all,
 
I do=20 agree that a clear/single network operation mode is desirable in = practice,=20 however, as Nurit pointed out, IEEE 802.1Qay is more = permissive in this regard.
However, if every VLAN is = allocated for=20 PBB-TE, which is a valid configuration in 802.1Qay, then the = network will=20 operate in a clear co-ps mode without side effects due to parallel PBB = operation.
 
On the other hand, I can = imagine that in=20 some cases having a PBB bridged VLAN used, e.g.,to create connectivity = for=20 control traffic, would be desirable and I do not see a = problem with this=20 until it does not carry customer=20 traffic.
 
I think we do not need to do = anything in=20 here; the level of permitted coexistence of PBB and PBB-TE is a = network=20 operational issue, and it does not really affect the GMPLS extensions = much=20 more than probably adding support to ensure that the VLANs configured = for=20 PBB-TE are the same throughout the=20 network.
 
Best=20 regards,
Attila
 
From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit=20 Sprecher
Sent: Wednesday, April 09, 2008 10:02 = PM
To:=20 ext Don Fedyk; neil.2.harrison@bt.com; i_bryskin@yahoo.com;=20 adrian@olddog.co.uk; ccamp@ops.ietf.org
Subject: RE: = Continued=20 Poll for Adoption of Ethernet I-Ds

Hi=20 all,

So maybe = this is=20 something to be commented to the IEEE……..they operate = hybrid PBB/PBB-TE=20 networks.

In this = draft we=20 provide a control plane to the dataplane that is defined by the = IEEE, and=20 specifically we define a control plane for PBB-TE as defined by the = IEEE=20 802.1Qay.

Nurit

 

From:=20 owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] = On Behalf Of ext Don = Fedyk
Sent: Wednesday, April 09, = 2008=20 17:38
To:=20 neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk;=20 ccamp@ops.ietf.org
Subject: RE: Continued Poll = for=20 Adoption of Ethernet I-Ds

 

Hi Igor = and=20 Neil

 

See=20 below,


IB>> I agree with what you are = saying.=20 What confuses me, though, is that 802.1ay prescribes allocating of = certain=20 range(s) of VLANIDs for the PBB-TE use, while allowing use of = other=20 VLANIDs for their native Ethernet purposes. I wonder why is that? = Why not=20 to say that all VLANIDs are available for the PBB-TE use. If what = you are=20 saying is correct (which, again, I believe you are), that is, = PBB-TE and=20 non-PBB-TE (say, PBB) are completely separate layer network, than = VLANIDs=20 are not shared between the two.

What am I missing=20 here?

Thanks,
Igor 

 

NH=3D>=20 Excellent question.  I have made exactly this same = observation in the=20 past.  In principle there is no reason why you cannot re-use = all the=20 codepoints of each/every field in the traffic unit because, as = stated,=20 although the traffic units look identical they do belong to quite=20 different layer networks.  I think there are 2 reasons for=20 this:

 

-   =20 Firstly, most IEEE folks are not familiar with, and therefore do = not use,=20 functional architecture techniques to describe layer = networks.  So=20 this issue may not be so obvious to many folks in IEEE.  = Further,=20 when we have QinQ techniques these are a form of sublayering (like = we find=20 in nested LSPs in MPLS) and so we don't have distinct layer = networks=20 here......and although folks may not describe it as such they do = recognise=20 that one of the consequences of this (ie still a single layer = network) is=20 that it affects scaling.  However, once we have the .1ah = stuff and=20 MACinMAC (ie true client/server) then everyone intuitively = recognises we=20 have quite disjoint layer networks.  So what I am saying here = is that=20 for folks who don't have a strong background in functional = architecture,=20 the observation you have made may not be so obvious even though it = is=20 architecturally true.

 

-   =20 Secondly, there could be practical/implementation reasons for = doing this=20 (ie creating a split in VID codepoints) when dealing with COTS = Ethernet=20 hardware.  Maybe some of the Ethernet hardware experts can = provide=20 further clarification here.   

 

Disclaimer I'm not=20 a hardware expert but Neil is correct there is currently no = "context" within=20 an Ethernet Frame that could separate the PBB B-VID space and the = PBB-TE=20 B-VID space. If  these spaces used overlapping B-VID values = there would=20 be know way to know by looking at the Frame.  In fact one of = the=20 attractions of PBB-TE is that it can reuse the existing forwarding = HW=20 because it essentially forwards on (B-VID+MAC DA).  A = result=20 is a switch cannot tell the context implicitly.=20

One=20 thing this does provide however is a clear way to 'know' when = looking at a=20 traffic unit in isolation exactly which layer network it belongs=20 to. 

 

Between = the PBB=20 B-MAC (server) and the PBB C-MAC  (client) = it is=20 clear looking at a frame.   Between PBB and PBB-TE the = B-VID space=20 partitioning in the management (and control plane) is the only thing = that=20 separates the behavior. 

 

Regards,

Don=20

 

regards,=20 = Neil

------_=_NextPart_001_01C89AE7.032223C2-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Apr 2008 07:01:43 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-03.txt Message-Id: <20080410070002.2FAC33A6D2A@core3.amsl.com> Date: Thu, 10 Apr 2008 00:00:02 -0700 (PDT) --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 : OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, R. Zhang Filename : draft-ietf-ccamp-ospf-interas-te-extension-03.txt Pages : 18 Date : 2008-04-09 This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links which can be used to perform inter-AS TE path computation. No support for flooding TE information from outside the AS is proposed or defined in this document. Conventions used in this document 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-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-ospf-interas-te-extension-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-09234919.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Apr 2008 07:01:33 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ccamp-isis-interas-te-extension-01.txt Message-Id: <20080410070002.385533A6C1A@core3.amsl.com> Date: Thu, 10 Apr 2008 00:00:02 -0700 (PDT) --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 : ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Author(s) : M. Chen, R. Zhang Filename : draft-ietf-ccamp-isis-interas-te-extension-01.txt Pages : 19 Date : 2008-04-09 This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links which can be used to perform inter- AS TE path computation. No support for flooding TE information from outside the AS is proposed or defined in this document. Conventions used in this document 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]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas-te-extension-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-isis-interas-te-extension-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-04-09235228.I-D@ietf.org> --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Apr 2008 06:57:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89AD7.B41BBF70" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Thu, 10 Apr 2008 08:54:21 +0200 Message-ID: <53CCFDD6E346CB43994852666C210E9102624856@esealmw116.eemea.ericsson.se> Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciaV3+R0AYEnRkpSBSudo939mSy7QAfHkaw From: "Attila Takacs" To: "Igor Bryskin" , "Don Fedyk" , , , This is a multi-part message in MIME format. ------_=_NextPart_001_01C89AD7.B41BBF70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor, =20 But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain. =20 =20 Unfortunately, leaking from PBB to PBB-TE does not necessarily means immediate discarding of PBB frames. Due to the VLAN separation between PBB and PBB-TE, there is no clear layering here. Hence leaking can essentially mean that the VID of a bridged (PBB) frame is changed to a VID used for explicitly routed connections (PBB-TE). This does not necessarily means that the frame will be dropped. It is a valid assumption that the MAC address of the PBB frame is configured in the PBB-TE region as well and as such leakig PBB traffic will be forwarded as if it would belong to an explicitly routed connection.=20 Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation. =20 I think this is not necessary true, if one allocates the whole VLAN space to PBB-TE then there will be no bridged traffic in the network. As a consequence no leaking and no other cross effects is to be expected. =20 Best regards, Attila ------_=_NextPart_001_01C89AD7.B41BBF70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Igor,
 
But=20 how the separation of VLAN ID space would help in this case? If PBB = packets=20 are leaked into PBB-TE they will be immediately dropped because there = will be=20 no PBB-TE connections configured for such packets. If PBB-TE packets = are=20 leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway = the=20 packets will be flooded across the PBB domain.  
 
Unfortunately,=20 leaking from PBB to PBB-TE does not necessarily means immediate = discarding of=20 PBB frames. Due to the VLAN separation between PBB and PBB-TE, = there is no=20 clear layering here. Hence leaking can essentially mean that the VID = of a=20 bridged (PBB) frame is changed to a VID used for explicitly=20 routed connections (PBB-TE). This does not necessarily means that = the frame=20 will be dropped. It is a valid assumption that the MAC address of the = PBB frame=20 is configured in the PBB-TE region as well and as such leakig PBB = traffic will=20 be forwarded as if it would belong to an explicitly routed = connection.=20
Note=20 that what I just wrote is true regardless whether PBB-TE uses = specially=20 allocated ranges of VLANIDs or all VLANIDs. Hence there is no = architectural=20 need for the VLANID space separation.
   I = think this is=20 not necessary true, if one allocates the whole VLAN space to PBB-TE then = there=20 will be no bridged traffic in the network. As a consequence no leaking = and no=20 other cross effects is to be expected.   Best=20 regards, Attila ------_=_NextPart_001_01C89AD7.B41BBF70-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Apr 2008 06:57:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89AD7.C4196512" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Thu, 10 Apr 2008 08:54:47 +0200 Message-ID: <53CCFDD6E346CB43994852666C210E9102624857@esealmw116.eemea.ericsson.se> Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciZvdU00p78wmPjQTmVUbI9h7E4/wAUo6cgAA2egTAADV+mQAAWX7cw From: "Attila Takacs" To: "Nurit Sprecher" , "ext Don Fedyk" , , , , This is a multi-part message in MIME format. ------_=_NextPart_001_01C89AD7.C4196512 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I do agree that a clear/single network operation mode is desirable in practice, however, as Nurit pointed out, IEEE 802.1Qay is more permissive in this regard.=20 However, if every VLAN is allocated for PBB-TE, which is a valid configuration in 802.1Qay, then the network will operate in a clear co-ps mode without side effects due to parallel PBB operation. =20 On the other hand, I can imagine that in some cases having a PBB bridged VLAN used, e.g.,to create connectivity for control traffic, would be desirable and I do not see a problem with this until it does not carry customer traffic. =20 I think we do not need to do anything in here; the level of permitted coexistence of PBB and PBB-TE is a network operational issue, and it does not really affect the GMPLS extensions much more than probably adding support to ensure that the VLANs configured for PBB-TE are the same throughout the network. =20 Best regards, Attila =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit Sprecher Sent: Wednesday, April 09, 2008 10:02 PM To: ext Don Fedyk; neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: RE: Continued Poll for Adoption of Ethernet I-Ds =09 =09 Hi all, So maybe this is something to be commented to the IEEE........they operate hybrid PBB/PBB-TE networks.=20 In this draft we provide a control plane to the dataplane that is defined by the IEEE, and specifically we define a control plane for PBB-TE as defined by the IEEE 802.1Qay.=20 Nurit =20 =09 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Don Fedyk Sent: Wednesday, April 09, 2008 17:38 To: neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: RE: Continued Poll for Adoption of Ethernet I-Ds =20 Hi Igor and Neil =20 See below, =09 IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.=20 =09 What am I missing here? =09 Thanks, Igor=20 =20 NH=3D> Excellent question. I have made exactly this same observation in the past. In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks. I think there are 2 reasons for this: =20 - Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks. So this issue may not be so obvious to many folks in IEEE. Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling. However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks. So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true. =20 - Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware. Maybe some of the Ethernet hardware experts can provide further clarification here. =20 =20 Disclaimer I'm not a hardware expert but Neil is correct there is currently no "context" within an Ethernet Frame that could separate the PBB B-VID space and the PBB-TE B-VID space. If these spaces used overlapping B-VID values there would be know way to know by looking at the Frame. In fact one of the attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA). A result is a switch cannot tell the context implicitly.=20 One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to.=20 =20 Between the PBB B-MAC (server) and the PBB C-MAC (client) it is clear looking at a frame. Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing that separates the behavior. =20 =20 Regards, Don=20 =20 regards, Neil ------_=_NextPart_001_01C89AD7.C4196512 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message=
Hi=20 all,
 
I do=20 agree that a clear/single network operation mode is desirable in = practice,=20 however, as Nurit pointed out, IEEE 802.1Qay is more = permissive in this regard.
However, if every VLAN is = allocated for=20 PBB-TE, which is a valid configuration in 802.1Qay, then the = network will=20 operate in a clear co-ps mode without side effects due to parallel PBB=20 operation.
 
On the other hand, I can = imagine that in=20 some cases having a PBB bridged VLAN used, e.g.,to create connectivity = for=20 control traffic, would be desirable and I do not see a problem with = this=20 until it does not carry customer=20 traffic.
 
I think we do not need to do = anything in=20 here; the level of permitted coexistence of PBB and PBB-TE is a network=20 operational issue, and it does not really affect the GMPLS extensions = much more=20 than probably adding support to ensure that the VLANs configured for = PBB-TE are=20 the same throughout the = network.
 
Best=20 regards,
Attila
 
From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Nurit=20 Sprecher
Sent: Wednesday, April 09, 2008 10:02 = PM
To: ext=20 Don Fedyk; neil.2.harrison@bt.com; i_bryskin@yahoo.com; = adrian@olddog.co.uk;=20 ccamp@ops.ietf.org
Subject: RE: Continued Poll for Adoption = of=20 Ethernet I-Ds

Hi=20 all,

So maybe = this is=20 something to be commented to the IEEE……..they operate = hybrid PBB/PBB-TE=20 networks.

In this = draft we=20 provide a control plane to the dataplane that is defined by the IEEE, = and=20 specifically we define a control plane for PBB-TE as defined by the = IEEE=20 802.1Qay.

Nurit

 

From:=20 owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Don = Fedyk
Sent: Wednesday, April 09, 2008 = 17:38
To:=20 neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk;=20 ccamp@ops.ietf.org
Subject: RE: Continued Poll for = Adoption=20 of Ethernet I-Ds

 

Hi Igor and = Neil

 

See=20 below,


IB>> I agree with what you are = saying.=20 What confuses me, though, is that 802.1ay prescribes allocating of = certain=20 range(s) of VLANIDs for the PBB-TE use, while allowing use of other = VLANIDs=20 for their native Ethernet purposes. I wonder why is that? Why not to = say=20 that all VLANIDs are available for the PBB-TE use. If what you are = saying is=20 correct (which, again, I believe you are), that is, PBB-TE and = non-PBB-TE=20 (say, PBB) are completely separate layer network, than VLANIDs are = not=20 shared between the two.

What am I missing=20 here?

Thanks,
Igor 

 

NH=3D>=20 Excellent question.  I have made exactly this same observation = in the=20 past.  In principle there is no reason why you cannot re-use = all the=20 codepoints of each/every field in the traffic unit because, as = stated,=20 although the traffic units look identical they do belong to quite = different=20 layer networks.  I think there are 2 reasons for=20 this:

 

-   =20 Firstly, most IEEE folks are not familiar with, and therefore do not = use,=20 functional architecture techniques to describe layer networks.  = So this=20 issue may not be so obvious to many folks in IEEE.  Further, = when we=20 have QinQ techniques these are a form of sublayering (like we find = in nested=20 LSPs in MPLS) and so we don't have distinct layer networks = here......and=20 although folks may not describe it as such they do recognise that = one of the=20 consequences of this (ie still a single layer network) is that it = affects=20 scaling.  However, once we have the .1ah stuff and MACinMAC (ie = true=20 client/server) then everyone intuitively recognises we have quite = disjoint=20 layer networks.  So what I am saying here is that for folks who = don't=20 have a strong background in functional architecture, the observation = you=20 have made may not be so obvious even though it is architecturally=20 true.

 

-   =20 Secondly, there could be practical/implementation reasons for doing = this (ie=20 creating a split in VID codepoints) when dealing with COTS Ethernet=20 hardware.  Maybe some of the Ethernet hardware experts can = provide=20 further clarification here.   

 

Disclaimer = I'm not a=20 hardware expert but Neil is correct there is currently no "context" = within an=20 Ethernet Frame that could separate the PBB B-VID space and the PBB-TE = B-VID=20 space. If  these spaces used overlapping B-VID values there would = be know=20 way to know by looking at the Frame.  In fact one of the = attractions of=20 PBB-TE is that it can reuse the existing forwarding HW because it = essentially=20 forwards on (B-VID+MAC DA).  A result is a switch = cannot tell=20 the context implicitly.

One=20 thing this does provide however is a clear way to 'know' when = looking at a=20 traffic unit in isolation exactly which layer network it belongs=20 to. 

 

Between the = PBB B-MAC=20 (server) and the PBB C-MAC  (client) it = is clear=20 looking at a frame.   Between PBB and PBB-TE the B-VID space = partitioning in the management (and control plane) is the only thing = that=20 separates the behavior. 

 

Regards,

Don=20

 

regards,=20 = Neil

------_=_NextPart_001_01C89AD7.C4196512-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 10 Apr 2008 01:33:41 +0000 Date: Thu, 10 Apr 2008 09:31:06 +0800 From: Mach Chen Subject: Re: Last call complete on Advertisement of inter-AS TE links To: Adrian Farrel Cc: CCAMP List Message-id: <200804100931061910652@huawei.com> Organization: Huawei MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi Adrian and all, Thanks for the review and comment. I will update and resubmit the I-Ds ASAP. Best regards, Mach Chen On 2008-04-10, at 00:06:32 Adrian Farrel wrote: >Hi, > >The last call completed. Given the high level of review and discussion in >the past and the relatively small size of the I-Ds, I'm not surprised that >we only got a couple of comments during last call. > >Mach, can you make the changes to the I-D to satisfy Acee's comments on the >OSPF draft, and check to see if there is any similar language in the IS-IS >draft? One point... > >Where he suggests alternative text for "TE Router ID", I think this is fine, >but it would be helpful if you retained "TE Router ID" in brackets to give >the extra information. > >Thanks, >Adrian >----- Original Message ----- >From: "Acee Lindem" >To: "Adrian Farrel" >Cc: "OSPF List" ; "CCAMP List" >Sent: Friday, April 04, 2008 3:46 PM >Subject: Re: [OSPF] CCAMP last call on advertisement of inter-AS TE links > > >>I can't speak for the OSPF WG as a whole, but I have reviewed the subject >>document and am very happy to see that the suggestion to use separate >>inter-AS LSA types has been incorporated. I have no further technical >>comments on the document and trust that the ccamp WG has verified that >>this information encoding meets the TE requirements. The usage described >>in sections 2.2 and 2.3 seem reasonable to me. >> >> I have the following editorial comments: >> >> 1. Sections 3.3.2 and 3.3.2 - Both of these say "Use of the TE Router >> ID is RECOMMENDED." I believe these should be respectively replaced by >> "Use of the TE Router Address as specified in the Router Address TLV >> [OSPF-TE] is RECOMMENDED." and "Use of the TE Router IPv6 Address as >> specified in the IPv6 Router Address as specified in the IPv6 Router >> Address TLV [OSPF-V3-TE] is RECOMMENDED." >> 2. Section 3.2.1 states "This is because... that may operate in a >> different address space;". If they are using a different address space on >> the link between the ASes, then I'd expect there to be problems with BGP >> as well :^) I'd suggest: >> "Given that OSPF is an IGP and should only be utilized between >> routers in the same routing domain, the OSPF specific Link ID and >> Neighbor ID sub-TLVs are not applicable to inter-AS links.". >> 3. You may want to expand some acronyms on their first use. For >> example, "AS Boundary Router (ASBR)", "Link State Advertisement (LSA)" >> and >> "Path Computation Element (PCE)". >> 4. [OSPFV3] is listed to as both a Normative and Informative reference. >> >> Thanks, >> Acee >> >> On Mar 19, 2008, at 2:06 PM, Adrian Farrel wrote: >> >>> Hi, >>> >>> You may recall providing useful review and feedback on >>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- >>> te-extension-02.txt >>> >>> The authors believe that they have taken on board all the comments >>> received >>> from the OSPF working group and have updated the draft accordingly. >>> >>> >>> CCAMP is holding a three week working group last call on this I-D along >>> with >>> its IS-IS partner document: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas- >>> te-extension-00.txt >>> >>> These documents describe how to advertise the TE links that connect an >>> AS to >>> the outside world within the AS's IGP. As the drafts are at pains to >>> point >>> out, there is no proposal to advertise the TE information more widely >>> (such >>> as to other ASes). >>> >>> The last call will end at 12 noon BST on April 9th 2008. >>> >>> Please send your comments to the CCAMP list or direct to the CCAMP >>> chairs. >>> >>> Thanks, >>> Adrian and Deborah >>> >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Apr 2008 20:09:23 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89A7D.440F47C9" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Wed, 9 Apr 2008 23:02:01 +0300 Message-ID: Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciZvdU00p78wmPjQTmVUbI9h7E4/wAUo6cgAA2egTAADV+mQA== From: "Nurit Sprecher" To: "ext Don Fedyk" , , , , This is a multi-part message in MIME format. ------_=_NextPart_001_01C89A7D.440F47C9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, So maybe this is something to be commented to the IEEE........they operate hybrid PBB/PBB-TE networks.=20 In this draft we provide a control plane to the dataplane that is defined by the IEEE, and specifically we define a control plane for PBB-TE as defined by the IEEE 802.1Qay.=20 Nurit =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Don Fedyk Sent: Wednesday, April 09, 2008 17:38 To: neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org Subject: RE: Continued Poll for Adoption of Ethernet I-Ds =20 Hi Igor and Neil =20 See below, =09 IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.=20 =09 What am I missing here? =09 Thanks, Igor=20 =20 NH=3D> Excellent question. I have made exactly this same observation in the past. In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks. I think there are 2 reasons for this: =20 - Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks. So this issue may not be so obvious to many folks in IEEE. Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling. However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks. So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true. =20 - Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware. Maybe some of the Ethernet hardware experts can provide further clarification here. =20 =20 Disclaimer I'm not a hardware expert but Neil is correct there is currently no "context" within an Ethernet Frame that could separate the PBB B-VID space and the PBB-TE B-VID space. If these spaces used overlapping B-VID values there would be know way to know by looking at the Frame. In fact one of the attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA). A result is a switch cannot tell the context implicitly.=20 One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to.=20 =20 Between the PBB B-MAC (server) and the PBB C-MAC (client) it is clear looking at a frame. Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing that separates the behavior. =20 =20 Regards, Don=20 =20 regards, Neil ------_=_NextPart_001_01C89A7D.440F47C9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi = all,

So maybe this is something to be commented to the IEEE……..they operate hybrid = PBB/PBB-TE networks.

In this draft we = provide a control plane to the dataplane that is defined by the IEEE, and = specifically we define a control plane for PBB-TE as defined by the IEEE 802.1Qay. =

Nurit<= /span>

 =

From: owner-ccamp@ops.ietf.org = [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ext Don Fedyk
Sent: Wednesday, April = 09, 2008 17:38
To: = neil.2.harrison@bt.com; i_bryskin@yahoo.com; adrian@olddog.co.uk; ccamp@ops.ietf.org
Subject: RE: Continued = Poll for Adoption of Ethernet I-Ds

 

Hi Igor and = Neil

 

See = below,


IB>> I agree with what you are saying. What confuses me, though, = is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the = PBB-TE use, while allowing use of other VLANIDs for their native Ethernet = purposes. I wonder why is that? Why not to say that all VLANIDs are available for = the PBB-TE use. If what you are saying is correct (which, again, I believe = you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate = layer network, than VLANIDs are not shared between the two.

What am I missing here?

Thanks,
Igor 

 

NH=3D> Excellent question.  I have made exactly this same observation in = the past.  In principle there is no reason why you cannot re-use all = the codepoints of each/every field in the traffic unit because, as stated, = although the traffic units look identical they do belong to quite different layer networks.  I think there are 2 reasons for = this:

 

-    Firstly, most IEEE folks are not familiar with, and therefore do not = use, functional architecture techniques to describe layer networks.  So = this issue may not be so obvious to many folks in IEEE.  Further, when = we have QinQ techniques these are a form of sublayering (like we find in nested = LSPs in MPLS) and so we don't have distinct layer networks here......and = although folks may not describe it as such they do recognise that one of the = consequences of this (ie still a single layer network) is that it affects scaling.  However, once we have the .1ah stuff and MACinMAC (ie true = client/server) then everyone intuitively recognises we have quite disjoint layer = networks.  So what I am saying here is that for folks who don't have a strong = background in functional architecture, the observation you have made may not be so = obvious even though it is architecturally true.

 

-    Secondly, there could be practical/implementation reasons for doing this = (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware.  Maybe some of the Ethernet hardware experts can provide = further clarification here.   

 

Disclaimer I'm = not a hardware expert but Neil is correct there is currently no = "context" within an Ethernet Frame that could separate the PBB B-VID space and the = PBB-TE B-VID space. If  these spaces used overlapping B-VID values there = would be know way to know by looking at the Frame.  In fact one of the = attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA).  A result is a = switch cannot tell the context implicitly.

One = thing this does provide however is a clear way to 'know' when looking at a = traffic unit in isolation exactly which layer network it belongs = to. 

 

Between the PBB = B-MAC (server) and the PBB C-MAC  (client) it is = clear looking at a frame.   Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing = that separates the behavior. 

 

Regards,

Don =

 

regards, Neil

------_=_NextPart_001_01C89A7D.440F47C9-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Apr 2008 16:04:36 +0000 Message-ID: <029d01c89a5b$304133a0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "CCAMP List" Subject: Last call complete on Advertisement of inter-AS TE links Date: Wed, 9 Apr 2008 16:57:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Hi, The last call completed. Given the high level of review and discussion in the past and the relatively small size of the I-Ds, I'm not surprised that we only got a couple of comments during last call. Mach, can you make the changes to the I-D to satisfy Acee's comments on the OSPF draft, and check to see if there is any similar language in the IS-IS draft? One point... Where he suggests alternative text for "TE Router ID", I think this is fine, but it would be helpful if you retained "TE Router ID" in brackets to give the extra information. Thanks, Adrian ----- Original Message ----- From: "Acee Lindem" To: "Adrian Farrel" Cc: "OSPF List" ; "CCAMP List" Sent: Friday, April 04, 2008 3:46 PM Subject: Re: [OSPF] CCAMP last call on advertisement of inter-AS TE links >I can't speak for the OSPF WG as a whole, but I have reviewed the subject >document and am very happy to see that the suggestion to use separate >inter-AS LSA types has been incorporated. I have no further technical >comments on the document and trust that the ccamp WG has verified that >this information encoding meets the TE requirements. The usage described >in sections 2.2 and 2.3 seem reasonable to me. > > I have the following editorial comments: > > 1. Sections 3.3.2 and 3.3.2 - Both of these say "Use of the TE Router > ID is RECOMMENDED." I believe these should be respectively replaced by > "Use of the TE Router Address as specified in the Router Address TLV > [OSPF-TE] is RECOMMENDED." and "Use of the TE Router IPv6 Address as > specified in the IPv6 Router Address as specified in the IPv6 Router > Address TLV [OSPF-V3-TE] is RECOMMENDED." > 2. Section 3.2.1 states "This is because... that may operate in a > different address space;". If they are using a different address space on > the link between the ASes, then I'd expect there to be problems with BGP > as well :^) I'd suggest: > "Given that OSPF is an IGP and should only be utilized between > routers in the same routing domain, the OSPF specific Link ID and > Neighbor ID sub-TLVs are not applicable to inter-AS links.". > 3. You may want to expand some acronyms on their first use. For > example, "AS Boundary Router (ASBR)", "Link State Advertisement (LSA)" > and > "Path Computation Element (PCE)". > 4. [OSPFV3] is listed to as both a Normative and Informative reference. > > Thanks, > Acee > > On Mar 19, 2008, at 2:06 PM, Adrian Farrel wrote: > >> Hi, >> >> You may recall providing useful review and feedback on >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- >> te-extension-02.txt >> >> The authors believe that they have taken on board all the comments >> received >> from the OSPF working group and have updated the draft accordingly. >> >> >> CCAMP is holding a three week working group last call on this I-D along >> with >> its IS-IS partner document: >> >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas- >> te-extension-00.txt >> >> These documents describe how to advertise the TE links that connect an >> AS to >> the outside world within the AS's IGP. As the drafts are at pains to >> point >> out, there is no proposal to advertise the TE information more widely >> (such >> as to other ASes). >> >> The last call will end at 12 noon BST on April 9th 2008. >> >> Please send your comments to the CCAMP list or direct to the CCAMP >> chairs. >> >> Thanks, >> Adrian and Deborah >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Apr 2008 15:32:09 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=MMs2AMEbvos8bkQtHLeJ/nSbtFNpme4gwtA+gtx0RTEmA/WlqAdlJ++gVqH8I9SphgSCVMRxV4whPzw2c27i7g1XIVgLameUeW0NYCzQr79dImULEtagsx5NckiBVA11tqP+4aRVnfLSN8xtHt8v1kJsxeBLnTrBIExSECMDakU=; Date: Wed, 9 Apr 2008 08:31:03 -0700 (PDT) From: Igor Bryskin Subject: Re: Continued Poll for Adoption of Ethernet I-Ds To: Don Fedyk , neil.2.harrison@bt.com, adrian@olddog.co.uk, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1949939702-1207755063=:64983" Message-ID: <285306.64983.qm@web36808.mail.mud.yahoo.com> --0-1949939702-1207755063=:64983 Content-Type: text/plain; charset=us-ascii Hi Don, IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two. What am I missing here? Thanks, Igor NH=> Excellent question. I have made exactly this same observation in the past. In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks. I think there are 2 reasons for this: - Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks. So this issue may not be so obvious to many folks in IEEE. Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling. However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks. So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true. - Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware. Maybe some of the Ethernet hardware experts can provide further clarification here. Disclaimer I'm not a hardware expert but Neil is correct there is currently no "context" within an Ethernet Frame that could separate the PBB B-VID space and the PBB-TE B-VID space. If these spaces used overlapping B-VID values there would be know way to know by looking at the Frame. In fact one of the attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA). A result is a switch cannot tell the context implicitly. One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to. Between the PBB B-MAC (server) and the PBB C-MAC (client) it is clear looking at a frame. Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing that separates the behavior. IB>> I think you are missing the point here. When it is said that PBB-TE and PBB (or any other native Ethernet) are different layer networks it means that what happens in one layer is transparent/irrelevant for the other even when the two layers have identical LI overhead. In other words this means that one layer does not get to analyze the LI (MAC header in this case) of the other layer unless there is some kind of misconfiguration and packets from one layer are leaking into another. But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain. Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation. Cheers, Igor __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-1949939702-1207755063=:64983 Content-Type: text/html; charset=us-ascii
Hi Don,


IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.

What am I missing here?

Thanks,
Igor 
 
NH=> Excellent question.  I have made exactly this same observation in the past.  In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks.  I think there are 2 reasons for this:
 
-    Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks.  So this issue may not be so obvious to many folks in IEEE.  Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling.  However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks.  So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true.
 
-    Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware.  Maybe some of the Ethernet hardware experts can provide further clarification here.   
 
Disclaimer I'm not a hardware expert but Neil is correct there is currently no "context" within an Ethernet Frame that could separate the PBB B-VID space and the PBB-TE B-VID space. If  these spaces used overlapping B-VID values there would be know way to know by looking at the Frame.  In fact one of the attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA).  A result is a switch cannot tell the context implicitly.
One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to. 
 
Between the PBB B-MAC (server) and the PBB C-MAC  (client) it is clear looking at a frame.   Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing that separates the behavior. 
 
IB>> I think you are missing the point here. When it is said that PBB-TE and PBB (or any other native Ethernet) are different layer networks it means that what happens in one layer is transparent/irrelevant for the other  even when the two layers have identical LI overhead. In other words this means that one layer does not get to analyze the LI (MAC header in this case) of the other layer unless there is some kind of misconfiguration and packets from one layer are leaking into another. But how the separation of VLAN ID space would help in this case? If PBB packets are leaked into PBB-TE they will be immediately dropped because there will be no PBB-TE connections configured for such packets. If PBB-TE packets are leaked into PBB, than, since, PBB knows nothing about PBB-TE anyway the packets will be flooded across the PBB domain. Note that what I just wrote is true regardless whether PBB-TE uses specially allocated ranges of VLANIDs or all VLANIDs. Hence there is no architectural need for the VLANID space separation.

Cheers,
Igor

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-1949939702-1207755063=:64983-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Apr 2008 14:51:59 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89A4F.58ECE102" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Wed, 9 Apr 2008 10:38:15 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA41471C58A@zrtphxm2.corp.nortel.com> Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciZvdU00p78wmPjQTmVUbI9h7E4/wAUo6cgAA2egTA= From: "Don Fedyk" To: , , , This is a multi-part message in MIME format. ------_=_NextPart_001_01C89A4F.58ECE102 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor and Neil =20 See below, =09 IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.=20 =09 What am I missing here? =09 Thanks, Igor=20 =20 NH=3D> Excellent question. I have made exactly this same observation in the past. In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks. I think there are 2 reasons for this: =20 - Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks. So this issue may not be so obvious to many folks in IEEE. Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling. However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks. So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true. =20 - Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware. Maybe some of the Ethernet hardware experts can provide further clarification here. =20 =20 Disclaimer I'm not a hardware expert but Neil is correct there is currently no "context" within an Ethernet Frame that could separate the PBB B-VID space and the PBB-TE B-VID space. If these spaces used overlapping B-VID values there would be know way to know by looking at the Frame. In fact one of the attractions of PBB-TE is that it can reuse the existing forwarding HW because it essentially forwards on (B-VID+MAC DA). A result is a switch cannot tell the context implicitly.=20 One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to.=20 =20 Between the PBB B-MAC (server) and the PBB C-MAC (client) it is clear looking at a frame. Between PBB and PBB-TE the B-VID space partitioning in the management (and control plane) is the only thing that separates the behavior. =20 =20 Regards, Don=20 =20 regards, Neil ------_=_NextPart_001_01C89A4F.58ECE102 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi Igor and Neil
 
See below,

IB>> I agree with what you = are saying.=20 What confuses me, though, is that 802.1ay prescribes allocating of = certain=20 range(s) of VLANIDs for the PBB-TE use, while allowing use of other = VLANIDs=20 for their native Ethernet purposes. I wonder why is that? Why not to = say that=20 all VLANIDs are available for the PBB-TE use. If what you are saying = is=20 correct (which, again, I believe you are), that is, PBB-TE and = non-PBB-TE=20 (say, PBB) are completely separate layer network, than VLANIDs are not = shared=20 between the two.

What am I missing = here?

Thanks,
Igor 
 
NH=3D> Excellent question.  I have made exactly this = same=20 observation in the past.  In principle there is no reason why you = cannot=20 re-use all the codepoints of each/every field in the traffic unit = because, as=20 stated, although the traffic units look identical they do belong to = quite=20 different layer networks.  I think there are 2 reasons for=20 this:
 
-    Firstly, most IEEE folks are not familiar = with, and=20 therefore do not use, functional architecture techniques to describe = layer=20 networks.  So this issue may not be so obvious to many folks in=20 IEEE.  Further, when we have QinQ techniques these are a form of=20 sublayering (like we find in nested LSPs in MPLS) and so we don't have = distinct layer networks here......and although folks may not describe = it as=20 such they do recognise that one of the consequences of this (ie still = a single=20 layer network) is that it affects scaling.  However, once we have = the=20 .1ah stuff and MACinMAC (ie true client/server) then everyone = intuitively=20 recognises we have quite disjoint layer networks.  So what I am = saying=20 here is that for folks who don't have a strong background in = functional=20 architecture, the observation you have made may not be so obvious even = though=20 it is architecturally true.
 
-    Secondly, there = could be=20 practical/implementation reasons for doing this (ie creating a split = in VID=20 codepoints) when dealing with COTS Ethernet hardware.  Maybe some = of the=20 Ethernet hardware experts can provide further clarification=20 here.   
 
Disclaimer I'm not a hardware expert but Neil is correct = there is=20 currently no "context" within an Ethernet Frame that could separate the = PBB=20 B-VID space and the PBB-TE B-VID space. If  these spaces used = overlapping=20 B-VID values there would be know way to know by looking at the = Frame.  In=20 fact one of the attractions of PBB-TE is that it can reuse the existing=20 forwarding HW because it essentially forwards on (B-VID+MAC = DA).  A=20 result is a switch cannot tell the context implicitly.=20
One thing this does provide however is = a clear way=20 to 'know' when looking at a traffic unit in isolation exactly which = layer=20 network it belongs to. 
 
Between the PBB B-MAC (server) and the PBB C-MAC=20  (client) it is clear = looking at a=20 frame.   Between PBB and PBB-TE the B-VID space partitioning = in the=20 management (and control plane) is the only thing that separates the=20 behavior. 
 
Regards,
Don
 
regards, Neil
------_=_NextPart_001_01C89A4F.58ECE102-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Apr 2008 07:52:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89A16.66948A36" Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Date: Wed, 9 Apr 2008 08:48:29 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0239EC2C@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciZvdU00p78wmPjQTmVUbI9h7E4/wAUo6cg From: To: , , This is a multi-part message in MIME format. ------_=_NextPart_001_01C89A16.66948A36 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Igor....please see in-line (have snipped mail to your question only) =20 Igor Bryskin wrote 08 April 2008 22:17 > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt Notionally support. One concern I have revolves around the implications of this para: "4.1.3 Hybrid operation with legacy Ethernet The solution should take into consideration the operational scenario that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet hybrid networks. This morphs of network architecture is possible considering evolution scenario of Ethernet. In such networks, legacy Ethernet functionality such as Spanning Tree Protocol (SPT), Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE functionality. The solution must not prevent the simultaneous existence of GMPLS controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with native Ethernet Layer2 control protocols on same node and interface." We must avoid the mistake that different network modes (ie cl-ps or co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and also have the same CP). More specifically, native Ethernet is cl-ps and PBB-TE is co-ps....so even though the base DP traffic unit of these 2 different network modes looks the same they MUST exist in their own layer network space. This requires that some (lower) server layer network should create *different resource partitions* (in either space, freq or time dimensions) for each client layer network mode type. IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.=20 What am I missing here? Thanks, Igor=20 =20 NH=3D> Excellent question. I have made exactly this same observation in the past. In principle there is no reason why you cannot re-use all the codepoints of each/every field in the traffic unit because, as stated, although the traffic units look identical they do belong to quite different layer networks. I think there are 2 reasons for this: =20 - Firstly, most IEEE folks are not familiar with, and therefore do not use, functional architecture techniques to describe layer networks. So this issue may not be so obvious to many folks in IEEE. Further, when we have QinQ techniques these are a form of sublayering (like we find in nested LSPs in MPLS) and so we don't have distinct layer networks here......and although folks may not describe it as such they do recognise that one of the consequences of this (ie still a single layer network) is that it affects scaling. However, once we have the .1ah stuff and MACinMAC (ie true client/server) then everyone intuitively recognises we have quite disjoint layer networks. So what I am saying here is that for folks who don't have a strong background in functional architecture, the observation you have made may not be so obvious even though it is architecturally true. =20 - Secondly, there could be practical/implementation reasons for doing this (ie creating a split in VID codepoints) when dealing with COTS Ethernet hardware. Maybe some of the Ethernet hardware experts can provide further clarification here. =20 =20 One thing this does provide however is a clear way to 'know' when looking at a traffic unit in isolation exactly which layer network it belongs to. =20 regards, Neil ------_=_NextPart_001_01C89A16.66948A36 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi Igor....please see in-line (have snipped mail to your = question=20 only)
 
Igor Bryskin  wrote=20 08 April 2008 22:17

>=20 draft-imajuku-ccamp-ethernet-gmpls-req-01.txt

Notionally = support. =20 One concern I have revolves around the implications
of this=20 para:

"4.1.3 Hybrid operation with legacy Ethernet

  = The=20 solution should take into consideration the operational = scenario
  that=20 GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet
  = hybrid=20 networks. This morphs of network architecture is possible
  = considering=20 evolution scenario of Ethernet. In such networks, legacy
  = Ethernet=20 functionality such as Spanning Tree Protocol (SPT),
  Link = Aggregation=20 [IEEE802.3], and so on must co-exist with PBB-TE
 =20 functionality.

  The solution must not prevent the = simultaneous=20 existence of GMPLS
  controlled Eth-LSPs and PBB[IEE802.1ah] or=20 PB[IEE802.1ad] with
  native Ethernet Layer2 control protocols = on same=20 node and interface."

We must avoid the mistake that different = network=20 modes (ie cl-ps or
co-ps or co-cs) can somehow 'co-exist' in the same = DP=20 layer network (and
also have the same CP).  More specifically, = native=20 Ethernet is cl-ps and
PBB-TE is co-ps....so even though the base DP = traffic=20 unit of these 2
different network modes looks the same they MUST = exist in=20 their own
layer network space.  This requires that some (lower) = server=20 layer
network should create *different resource partitions* (in = either=20 space,
freq or time dimensions) for each client layer network mode=20 type.

IB>> I agree with what you are saying. What confuses = me,=20 though, is that 802.1ay prescribes allocating of certain range(s) of = VLANIDs for=20 the PBB-TE use, while allowing use of other VLANIDs for their native = Ethernet=20 purposes. I wonder why is that? Why not to say that all VLANIDs are = available=20 for the PBB-TE use. If what you are saying is correct (which, again, I = believe=20 you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely = separate=20 layer network, than VLANIDs are not shared between the two.

What = am I=20 missing here?

Thanks,
Igor 
 
NH=3D> Excellent question.  I have made exactly this = same=20 observation in the past.  In principle there is no reason why you = cannot=20 re-use all the codepoints of each/every field in the traffic unit = because, as=20 stated, although the traffic units look identical they do belong to = quite=20 different layer networks.  I think there are 2 reasons for=20 this:
 
-    Firstly, most IEEE folks are not familiar = with, and=20 therefore do not use, functional architecture techniques to describe = layer=20 networks.  So this issue may not be so obvious to many folks in = IEEE. =20 Further, when we have QinQ techniques these are a form of sublayering = (like we=20 find in nested LSPs in MPLS) and so we don't have distinct layer = networks=20 here......and although folks may not describe it as such they do = recognise that=20 one of the consequences of this (ie still a single layer network) is = that it=20 affects scaling.  However, once we have the .1ah stuff and MACinMAC = (ie=20 true client/server) then everyone intuitively recognises we have quite = disjoint=20 layer networks.  So what I am saying here is that for folks who = don't have=20 a strong background in functional architecture, the observation you have = made=20 may not be so obvious even though it is architecturally=20 true.
 
-    Secondly, there could be = practical/implementation=20 reasons for doing this (ie creating a split in VID codepoints) when = dealing with=20 COTS Ethernet hardware.  Maybe some of the Ethernet hardware = experts can=20 provide further clarification here. 
 
One thing this does provide however is a clear way to 'know' = when looking=20 at a traffic unit in isolation exactly which layer network it belongs=20 to.
 
regards, Neil
------_=_NextPart_001_01C89A16.66948A36-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Apr 2008 02:43:53 +0000 Reply-To: From: "Weiqiang Sun" To: "'Adrian Farrel'" Cc: Subject: RE: Editorial comment about draft-ietf-ccamp-lsp-dppm-00.txt Date: Wed, 9 Apr 2008 10:41:56 +0800 Organization: Shanghai Jiao Tong University Message-ID: <002701c899eb$48776e50$d9664af0$@edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AciZtFY8IND/XzYcRPidD5/Dxrt/zwANhn2Q Content-Language: zh-cn Hi Adrian, Many thanks for the thorough comments. We will get them fixed one by one and post it again. Best regards, Weiqiang -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, April 09, 2008 4:08 AM To: sunwq@sjtu.edu.cn Cc: ccamp@ops.ietf.org Subject: Editorial comment about draft-ietf-ccamp-lsp-dppm-00.txt Hi, Here are some editorial comments for your draft. These changes will help your draft through the IETF process and will make it easier to review for others. Cheers, Adrian === Document header s/ccamp/Network Working Group/ (This is for obscure historic reasons :-) === Author list You need to reduce to a list of no more than four authors listed on the front page. Others can continue to be listed in the section at the end of the draft. There are two ways to handle this: 1. If some of the authros are doing most of the work, keep them on the front page, but remove the others. 2. If one or two people are editing the work done by the rest of the team, leave them on the frint page and mark them as "(Editor)". === Document title s/Dynamical/Dynamic/ === Abstract s/for the future data transmission/for future data transmission/ s/The GMPLS/GMPLS/ s/cooperate/operate/ s/in metro area/in metro areas/ === 1. Introduction s/cooperate/operate/ s/This draft intends to define/This document defines/ s/The metrics defined in this draft/The metrics defined in this document/ === 1. Introduction For example, an new object can be added to the GMPLS TE STD MIB [RFC4802] such that the current and past control plane performance can be monitored through network management systems. The extension of TE-MIB to support the metrics defined is out the scope of this document. I think that technically you cannot add objects to a defined MIB module, but you can define extensions to a MIB module to contain new objects. === 2. Conventions Used in This Document I don't think you need this text as you do not use any of the formal language. === 3. Overview of Performance Metrics I would like to see a little more introduction to what we are going to get in sections 4 to 8, and then 9 through 12. in other words, an overview of what is coming later so that I can navigate the rest of the document a little more easily. === 4. A Singleton Definition for single unidirectional LSP Setup Delay Can you make all section headings use captials. For example, 4. A Singleton Definition for Single Unidirectional LSP Setup Delay === 14. Discussion s/But in the draft/But in this document/ === 15. Security Considerations This section is a little thin! Could the information you propose to collect be used to facilitate attacks? For example by identifying weak spots in the network. Could the collection of information impact the operation of the network? If this is the case, requesting that performance behavior is monitored and reported could be used to attack the network. === You are missing an IANA section. This can simply say... X. IANA Considerations This document makes no requests for IANA action. === 17. Normative References [RFC2119] You might not need this any more if you delete Section 2. [RFC2330] This is an Informational RFC. If you can, you should make it an Informative Reference. This is not absolutely required - if you believe it really is normative (i.e., your document cannot be read without reference to this RFC) then it is OK to keep it as a Normative Reference. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 09 Apr 2008 00:45:00 +0000 Message-Id: <6.0.0.20.2.20080409001807.06c43b50@mailsv4.y.ecl.ntt.co.jp> Date: Wed, 09 Apr 2008 09:47:31 +0900 To: From: Wataru Imajuku Subject: Re: Polling for Adoption of Ethernet I-Ds Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Yes to all. Best Regards Wataru At 05:23 08/03/28, Adrian Farrel wrote: >Hi, > >From Philadelphia, we have four candidate I-Ds for adoption as CCAMP working group documents. > >Please express your opinions. > >Note that acceptance of these I-Ds does not mean that the discussion about the architecture is done. I think we made some progress on that topic in Philadelphia, and I think the authors took on the task of making some updates of semantics and for clarity, but I expect the discussion may go on for a while. > >draft-imajuku-ccamp-ethernet-gmpls-req-01.txt >draft-fedyk-gmpls-ethernet-pbb-te-02.txt >draft-berger-ccamp-gmpls-mef-uni-02.txt >draft-berger-ccamp-gmpls-ether-svcs-01.txt > >Thanks, >Adrian > > ------------------------------------- Wataru Imajuku@NTT Network Innovation Labs TEL: +81-46-859-4315 FAX: +81-46-859-5541 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2008 21:20:12 +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: Continued Poll for Adoption of Ethernet I-Ds Date: Tue, 8 Apr 2008 17:19:54 -0400 Message-ID: Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciY0KHD+nKzi8VGTxyjIAwTHRMYUAA7Z7ww From: "Pandian, Vijay" To: "Adrian Farrel" , Yes to all. Vijay=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Monday, April 07, 2008 12:54 PM To: ccamp@ops.ietf.org Subject: Continued Poll for Adoption of Ethernet I-Ds Hi, We have seen some good support for these I-Ds and no objections, but I don't think we have seen anything like the level of support that was evident in the room in Philadelphia. We haven't seen support from more than half of the authors of the documents. So, please, if you haven't already done so, give an indication of whether or not you support each of these four documents becoming working group drafts.=20 Remember, you can be in favor of some and not other if you like. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, March 27, 2008 9:23 PM Subject: Polling for Adoption of Ethernet I-Ds > Hi, > > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP=20 > working group documents. > > Please express your opinions. > > Note that acceptance of these I-Ds does not mean that the discussion about=20 > the architecture is done. I think we made some progress on that topic in=20 > Philadelphia, and I think the authors took on the task of making some=20 > updates of semantics and for clarity, but I expect the discussion may go=20 > on for a while. > > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > draft-berger-ccamp-gmpls-mef-uni-02.txt > draft-berger-ccamp-gmpls-ether-svcs-01.txt > > Thanks, > Adrian > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2008 21:18:13 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=F/d6SkNfUDna2wwd/Ngj5niv0R1YPM9GkfP3xsc+0wKeb/GuHlhqiFdKb2sIevMZAuxie8UzVqtq/D0B3yHV9lxPQugl6RcVzx7NvH993VMVqLLfgGqD91jSP3b84fdUgGAcFeIUDi4lIQh1YRX/8nYuWuIiQePoGoG/E3dLx1U=; Date: Tue, 8 Apr 2008 14:16:35 -0700 (PDT) From: Igor Bryskin Subject: Re: Continued Poll for Adoption of Ethernet I-Ds To: neil.2.harrison@bt.com, adrian@olddog.co.uk, ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1744815800-1207689395=:29318" Message-ID: <957328.29318.qm@web36801.mail.mud.yahoo.com> --0-1744815800-1207689395=:29318 Content-Type: text/plain; charset=us-ascii Hi Neil. Please, see my question in-line. Regards, Igor ----- Original Message ---- From: "neil.2.harrison@bt.com" To: adrian@olddog.co.uk; ccamp@ops.ietf.org Sent: Monday, April 7, 2008 4:57:57 PM Subject: RE: Continued Poll for Adoption of Ethernet I-Ds Adrian, Here is my view (with some brief rationale): > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt Notionally support. One concern I have revolves around the implications of this para: "4.1.3 Hybrid operation with legacy Ethernet The solution should take into consideration the operational scenario that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet hybrid networks. This morphs of network architecture is possible considering evolution scenario of Ethernet. In such networks, legacy Ethernet functionality such as Spanning Tree Protocol (SPT), Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE functionality. The solution must not prevent the simultaneous existence of GMPLS controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with native Ethernet Layer2 control protocols on same node and interface." We must avoid the mistake that different network modes (ie cl-ps or co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and also have the same CP). More specifically, native Ethernet is cl-ps and PBB-TE is co-ps....so even though the base DP traffic unit of these 2 different network modes looks the same they MUST exist in their own layer network space. This requires that some (lower) server layer network should create *different resource partitions* (in either space, freq or time dimensions) for each client layer network mode type. IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two. What am I missing here? Thanks, Igor Aside=> For the case of private network services (which also includes 'network builder' transport services, ie how one creates client layer network topology) we are ultimately dealing with a time varying aggregate of message/file/stream applications.....these may not even be supported in the immediate client layer network, but there will ultimately be a 'very top' layer network that does support these. So in the server layer network what we have to deal with are (latent) abstractions of such time varying application aggregates. In such cases the key behaviour that the server network must provide to the client network is one of transparency, ie a client/server layer network relationship must provide full functional decoupling of the client and server layer networks. This is not simply a technically driven requirement but it also has commercial and (in some cases) regulatory drivers. Although this is a necessary condition (at least for reachability isolation of different client service instances) it is not generally sufficient for client service cases which require resource isolation (ie the traffic behaviour of client service instance X cannot impact the traffic behaviour experienced by client service instance Y). To satisfy the latter requirement the server layer network (i) must provide connections (ie only p2p or p2mp constructs allowed - which is also a necessary condition) and (ii) the server layer resources should not be overbooked (for a full sufficiency condition). Although not all client cases need this (strong resource isolation) service from the server layer network, the server layer network must nevertheless have the capability of providing it. All these requirements are forced to be met when the server layer technology belongs to the co-cs mode. However, care is required when the server layer network belongs to the co-ps mode (eg PBB-TE), eg don't violate the rules of a connection. And of course these requirements cannot be assured in the cl-ps mode as this does not, by definition, provide connections. > draft-fedyk-gmpls-ethernet-pbb-te-02.txt Support. Couple of small points: - OAM activation/deactivation (ie CV flow) needs to be synchronised to whatever CP or MP mechanism sets-up/tears-down ESPs for obvious operational reasons. Further, the CP (if ESP signalled) or MP (if ESP provisioned) needs to tell ESP DP sink trail termination point of the expected B-MAC SA. - Although IDs major on security from the perspective of malicious attacks (on the DP/CP/MP) there is also an aspect of security related to defects, ie customer traffic leaking from one connection into another connection under misconnectivity defects. A major advantage for operators and their customers of using domain-unique (non-swapped) labels is that misconnectivity defects are very unlikely to propagate, and in any case are always detectable at a connection trail termination point due to the B-MAC SA in each traffic unit. This benefit exists without running any OAM at all.....indeed, one only requires a CV OAM flow in PBB-TE to detect simple breaks such that they can be distinguished from a quiescent traffic case. This results in a significant opex benefit since it means operators only need to run OAM on important connections and not all connections (which is the case for label-swapping if misconnectivity defects must be detected). Maybe this 'security benefit' should be mentioned in the security section? > draft-berger-ccamp-gmpls-mef-uni-02.txt > draft-berger-ccamp-gmpls-ether-svcs-01.txt No problems with the IDs themselves, as they are only attempting to satisfy externally perceived requirements....but I do have a concern with the external requirements. When we talk about UNIs (and E-NNIs) we should be clear that we are actually dealing with public network services and the horizontal peer-partitioning of a single layer network between different operator and customer parties, ie this is NOT the same as the private 'network builder' case (briefly discussed previously) since that is based on a vertical client/server relationship between different layer networks. A critical issue (usually overlooked in my experience) here is the importance in being clear about the 'end-system message/file/stream application to first layer network adaptation functions'. Ethernet does not currently define such adaptation functions for message/file/stream applications (IP does of course with UDP, TCP and RTP respectively). I don't really want to go into all the detail here, but I simply want to make the point that before folks get too carried away defining UNIs/NNIs (for any network technology) they should be clear that this signifies a clear intention to develop public network services and requires careful attention to the end-system to first layer network adaptation functions.....so it's not simply about defining interworking between CP signalling or routing functions, or even DP OAM functions say. Therefore, as you might guess, whilst we in IETF/CCAMPs may quite easily define UNIs/E-NNIs for the DP (OAM) and CP say, we should also be cognizant of the ultimate implications of the direction MEF and ITU are taking here. Aside=> A slight twist on the above is where folks have considered E-NNI peer interworking between *different* technologies. This recently came up in the ITU wrt T-MPLS OAM in draft G.8114 which was undergoing AAP. G.8114 contained a proposal to peer interwork T-MPLS and Ethernet networks simply because they had both been 'bestowed' with similar, and IMO far too complex, DP OAM. It should be self-evident that it is not sensible to try and interwork 2 technologies that belong to different network modes (simply because there will be significant functional component mismatch across the DP and CP), but in any case there are no end-system application to first layer network adaptations functions defined for either of these technologies (noting that if these were defined they would be required to either (i) pass transparently between the 2 network peer partitions at the interworking point if common or (ii) there would have to be interworking cases defined if not common). It was quite evident that no thought had been given to these matters whatsoever in G.8114 and so we requested that the interworking proposal was removed. Later, and as most folks probably know by now, the AAP progress of G.8114 was stopped anyway due to larger concerns that IETF had on T-MPLS in general. regards, Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: 07 April 2008 17:54 > To: ccamp@ops.ietf.org > Subject: Continued Poll for Adoption of Ethernet I-Ds > > > Hi, > > We have seen some good support for these I-Ds and no > objections, but I don't > think we have seen anything like the level of support that > was evident in > the room in Philadelphia. We haven't seen support from more > than half of the > authors of the documents. > > So, please, if you haven't already done so, give an > indication of whether or > not you support each of these four documents becoming working > group drafts. > Remember, you can be in favor of some and not other if you like. > > Thanks, > Adrian > > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Thursday, March 27, 2008 9:23 PM > Subject: Polling for Adoption of Ethernet I-Ds > > > > Hi, > > > > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP > > working group documents. > > > > Please express your opinions. > > > > Note that acceptance of these I-Ds does not mean that the > discussion > > about > > the architecture is done. I think we made some progress on > that topic in > > Philadelphia, and I think the authors took on the task of > making some > > updates of semantics and for clarity, but I expect the > discussion may go > > on for a while. > > > > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > > draft-berger-ccamp-gmpls-mef-uni-02.txt > > draft-berger-ccamp-gmpls-ether-svcs-01.txt > > > > Thanks, > > Adrian > > > > > > > > > > ____________________________________________________________________________________ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com --0-1744815800-1207689395=:29318 Content-Type: text/html; charset=us-ascii
Hi Neil. Please, see my question in-line.
Regards,
Igor

----- Original Message ----
From: "neil.2.harrison@bt.com" <neil.2.harrison@bt.com>
To: adrian@olddog.co.uk; ccamp@ops.ietf.org
Sent: Monday, April 7, 2008 4:57:57 PM
Subject: RE: Continued Poll for Adoption of Ethernet I-Ds

Adrian,  Here is my view (with some brief rationale):

> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt

Notionally support.  One concern I have revolves around the implications
of this para:

"4.1.3 Hybrid operation with legacy Ethernet

  The solution should take into consideration the operational scenario
  that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet
  hybrid networks. This morphs of network architecture is possible
  considering evolution scenario of Ethernet. In such networks, legacy
  Ethernet functionality such as Spanning Tree Protocol (SPT),
  Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE
  functionality.

  The solution must not prevent the simultaneous existence of GMPLS
  controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with
  native Ethernet Layer2 control protocols on same node and interface."

We must avoid the mistake that different network modes (ie cl-ps or
co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and
also have the same CP).  More specifically, native Ethernet is cl-ps and
PBB-TE is co-ps....so even though the base DP traffic unit of these 2
different network modes looks the same they MUST exist in their own
layer network space.  This requires that some (lower) server layer
network should create *different resource partitions* (in either space,
freq or time dimensions) for each client layer network mode type.

IB>> I agree with what you are saying. What confuses me, though, is that 802.1ay prescribes allocating of certain range(s) of VLANIDs for the PBB-TE use, while allowing use of other VLANIDs for their native Ethernet purposes. I wonder why is that? Why not to say that all VLANIDs are available for the PBB-TE use. If what you are saying is correct (which, again, I believe you are), that is, PBB-TE and non-PBB-TE (say, PBB) are completely separate layer network, than VLANIDs are not shared between the two.

What am I missing here?

Thanks,
Igor

Aside=> For the case of private network services (which also includes
'network builder' transport services, ie how one creates client layer
network topology) we are ultimately dealing with a time varying
aggregate of message/file/stream applications.....these may not even be
supported in the immediate client layer network, but there will
ultimately be a 'very top' layer network that does support these.  So in
the server layer network what we have to deal with are (latent)
abstractions of such time varying application aggregates.  In such cases
the key behaviour that the server network must provide to the client
network is one of transparency, ie a client/server layer network
relationship must provide full functional decoupling of the client and
server layer networks.  This is not simply a technically driven
requirement but it also has commercial and (in some cases) regulatory
drivers.  Although this is a necessary condition (at least for
reachability isolation of different client service instances) it is not
generally sufficient for client service cases which require resource
isolation (ie the traffic behaviour of client service instance X cannot
impact the traffic behaviour experienced by client service instance Y).
To satisfy the latter requirement the server layer network (i) must
provide connections (ie only p2p or p2mp constructs allowed - which is
also a necessary condition) and (ii) the server layer resources should
not be overbooked (for a full sufficiency condition).  Although not all
client cases need this (strong resource isolation) service from the
server layer network, the server layer network must nevertheless have
the capability of providing it.

All these requirements are forced to be met when the server layer
technology belongs to the co-cs mode.  However, care is required when
the server layer network belongs to the co-ps mode (eg PBB-TE), eg don't
violate the rules of a connection.  And of course these requirements
cannot be assured in the cl-ps mode as this does not, by definition,
provide connections.


> draft-fedyk-gmpls-ethernet-pbb-te-02.txt

Support.  Couple of small points:
-    OAM activation/deactivation (ie CV flow) needs to be
synchronised to whatever CP or MP mechanism sets-up/tears-down ESPs for
obvious operational reasons.  Further, the CP (if ESP signalled) or MP
(if ESP provisioned) needs to tell ESP DP sink trail termination point
of the expected B-MAC SA.
-    Although IDs major on security from the perspective of malicious
attacks (on the DP/CP/MP) there is also an aspect of security related to
defects, ie customer traffic leaking from one connection into another
connection under misconnectivity defects.  A major advantage for
operators and their customers of using domain-unique (non-swapped)
labels is that misconnectivity defects are very unlikely to propagate,
and in any case are always detectable at a connection trail termination
point due to the B-MAC SA in each traffic unit. This benefit exists
without running any OAM at all.....indeed, one only requires a CV OAM
flow in PBB-TE to detect simple breaks such that they can be
distinguished from a quiescent traffic case.  This results in a
significant opex benefit since it means operators only need to run OAM
on important connections and not all connections (which is the case for
label-swapping if misconnectivity defects must be detected).  Maybe this
'security benefit' should be mentioned in the security section?


> draft-berger-ccamp-gmpls-mef-uni-02.txt
> draft-berger-ccamp-gmpls-ether-svcs-01.txt

No problems with the IDs themselves, as they are only attempting to
satisfy externally perceived requirements....but I do have a concern
with the external requirements.

When we talk about UNIs (and E-NNIs) we should be clear that we are
actually dealing with public network services and the horizontal
peer-partitioning of a single layer network between different operator
and customer parties, ie this is NOT the same as the private 'network
builder' case (briefly discussed previously) since that is based on a
vertical client/server relationship between different layer networks.  A
critical issue (usually overlooked in my experience) here is the
importance in being clear about the 'end-system message/file/stream
application to first layer network adaptation functions'.  Ethernet does
not currently define such adaptation functions for message/file/stream
applications (IP does of course with UDP, TCP and RTP respectively).  I
don't really want to go into all the detail here, but I simply want to
make the point that before folks get too carried away defining UNIs/NNIs
(for any network technology) they should be clear that this signifies a
clear intention to develop public network services and requires careful
attention to the end-system to first layer network adaptation
functions.....so it's not simply about defining interworking between CP
signalling or routing functions, or even DP OAM functions say.
Therefore, as you might guess, whilst we in IETF/CCAMPs may quite easily
define UNIs/E-NNIs for the DP (OAM) and CP say, we should also be
cognizant of the ultimate implications of the direction MEF and ITU are
taking here.

Aside=> A slight twist on the above is where folks have considered E-NNI
peer interworking between *different* technologies.  This recently came
up in the ITU wrt T-MPLS OAM in draft G.8114 which was undergoing AAP.
G.8114 contained a proposal to peer interwork T-MPLS and Ethernet
networks simply because they had both been 'bestowed' with similar, and
IMO far too complex, DP OAM.  It should be self-evident that it is not
sensible to try and interwork 2 technologies that belong to different
network modes (simply because there will be significant functional
component mismatch across the DP and CP), but in any case there are no
end-system application to first layer network adaptations functions
defined for either of these technologies (noting that if these were
defined they would be required to either (i) pass transparently between
the 2 network peer partitions at the interworking point if common or
(ii) there would have to be interworking cases defined if not common).
It was quite evident that no thought had been given to these matters
whatsoever in G.8114 and so we requested that the interworking proposal
was removed.  Later, and as most folks probably know by now, the AAP
progress of G.8114 was stopped anyway due to larger concerns that IETF
had on T-MPLS in general.

regards, Neil



> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> Sent: 07 April 2008 17:54
> To: ccamp@ops.ietf.org
> Subject: Continued Poll for Adoption of Ethernet I-Ds
>
>
> Hi,
>
> We have seen some good support for these I-Ds and no
> objections, but I don't
> think we have seen anything like the level of support that
> was evident in
> the room in Philadelphia. We haven't seen support from more
> than half of the
> authors of the documents.
>
> So, please, if you haven't already done so, give an
> indication of whether or
> not you support each of these four documents becoming working
> group drafts.
> Remember, you can be in favor of some and not other if you like.
>
> Thanks,
> Adrian
>
> ----- Original Message -----
> From: "Adrian Farrel" <adrian@olddog.co.uk>
> To: <ccamp@ops.ietf.org>
> Sent: Thursday, March 27, 2008 9:23 PM
> Subject: Polling for Adoption of Ethernet I-Ds
>
>
> > Hi,
> >
> > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP

> > working group documents.
> >
> > Please express your opinions.
> >
> > Note that acceptance of these I-Ds does not mean that the
> discussion
> > about
> > the architecture is done. I think we made some progress on
> that topic in
> > Philadelphia, and I think the authors took on the task of
> making some
> > updates of semantics and for clarity, but I expect the
> discussion may go
> > on for a while.
> >
> > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt
> > draft-fedyk-gmpls-ethernet-pbb-te-02.txt
> > draft-berger-ccamp-gmpls-mef-uni-02.txt
> > draft-berger-ccamp-gmpls-ether-svcs-01.txt
> >
> > Thanks,
> > Adrian
> >
> >
> >
>
>
>
>



You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. --0-1744815800-1207689395=:29318-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2008 20:10:25 +0000 Message-ID: <012601c899b4$46ac0220$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: Editorial comment about draft-ietf-ccamp-lsp-dppm-00.txt Date: Tue, 8 Apr 2008 21:08:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Here are some editorial comments for your draft. These changes will help your draft through the IETF process and will make it easier to review for others. Cheers, Adrian === Document header s/ccamp/Network Working Group/ (This is for obscure historic reasons :-) === Author list You need to reduce to a list of no more than four authors listed on the front page. Others can continue to be listed in the section at the end of the draft. There are two ways to handle this: 1. If some of the authros are doing most of the work, keep them on the front page, but remove the others. 2. If one or two people are editing the work done by the rest of the team, leave them on the frint page and mark them as "(Editor)". === Document title s/Dynamical/Dynamic/ === Abstract s/for the future data transmission/for future data transmission/ s/The GMPLS/GMPLS/ s/cooperate/operate/ s/in metro area/in metro areas/ === 1. Introduction s/cooperate/operate/ s/This draft intends to define/This document defines/ s/The metrics defined in this draft/The metrics defined in this document/ === 1. Introduction For example, an new object can be added to the GMPLS TE STD MIB [RFC4802] such that the current and past control plane performance can be monitored through network management systems. The extension of TE-MIB to support the metrics defined is out the scope of this document. I think that technically you cannot add objects to a defined MIB module, but you can define extensions to a MIB module to contain new objects. === 2. Conventions Used in This Document I don't think you need this text as you do not use any of the formal language. === 3. Overview of Performance Metrics I would like to see a little more introduction to what we are going to get in sections 4 to 8, and then 9 through 12. in other words, an overview of what is coming later so that I can navigate the rest of the document a little more easily. === 4. A Singleton Definition for single unidirectional LSP Setup Delay Can you make all section headings use captials. For example, 4. A Singleton Definition for Single Unidirectional LSP Setup Delay === 14. Discussion s/But in the draft/But in this document/ === 15. Security Considerations This section is a little thin! Could the information you propose to collect be used to facilitate attacks? For example by identifying weak spots in the network. Could the collection of information impact the operation of the network? If this is the case, requesting that performance behavior is monitored and reported could be used to attack the network. === You are missing an IANA section. This can simply say... X. IANA Considerations This document makes no requests for IANA action. === 17. Normative References [RFC2119] You might not need this any more if you delete Section 2. [RFC2330] This is an Informational RFC. If you can, you should make it an Informative Reference. This is not absolutely required - if you believe it really is normative (i.e., your document cannot be read without reference to this RFC) then it is OK to keep it as a Normative Reference. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2008 14:37:08 +0000 Message-ID: <47FB82A5.8040309@cn.kddilabs.jp> Date: Tue, 08 Apr 2008 23:35:17 +0900 From: "Ogaki, Kenichi" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: ccamp@ops.ietf.org Subject: Re: Continued Poll for Adoption of Ethernet I-Ds Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Yes to all. Best regards, Kenichi Adrian Farrel wrote: > Hi, > > We have seen some good support for these I-Ds and no objections, but I > don't think we have seen anything like the level of support that was > evident in the room in Philadelphia. We haven't seen support from more > than half of the authors of the documents. > > So, please, if you haven't already done so, give an indication of > whether or not you support each of these four documents becoming > working group drafts. Remember, you can be in favor of some and not > other if you like. > > Thanks, > Adrian > > ----- Original Message ----- From: "Adrian Farrel" > To: > Sent: Thursday, March 27, 2008 9:23 PM > Subject: Polling for Adoption of Ethernet I-Ds > > >> Hi, >> >> >From Philadelphia, we have four candidate I-Ds for adoption as CCAMP >> working group documents. >> >> Please express your opinions. >> >> Note that acceptance of these I-Ds does not mean that the discussion >> about the architecture is done. I think we made some progress on that >> topic in Philadelphia, and I think the authors took on the task of >> making some updates of semantics and for clarity, but I expect the >> discussion may go on for a while. >> >> draft-imajuku-ccamp-ethernet-gmpls-req-01.txt >> draft-fedyk-gmpls-ethernet-pbb-te-02.txt >> draft-berger-ccamp-gmpls-mef-uni-02.txt >> draft-berger-ccamp-gmpls-ether-svcs-01.txt >> >> Thanks, >> Adrian >> >> >> > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2008 13:52:41 +0000 Message-ID: <006f01c8997f$b227aca0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Last Call: draft-ietf-tsvwg-rsvp-user-error-spec (User-Defined Errors for RSVP) to Proposed Standard Date: Tue, 8 Apr 2008 14:51:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Note well. Adrian ----- Original Message ----- From: "The IESG" To: "IETF-Announce" Cc: Sent: Monday, April 07, 2008 2:41 PM Subject: Last Call: draft-ietf-tsvwg-rsvp-user-error-spec (User-Defined Errors for RSVP) to Proposed Standard > The IESG has received a request from the Transport Area Working Group WG > (tsvwg) to consider the following document: > > - 'User-Defined Errors for RSVP ' > as a Proposed Standard > > 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 2008-04-21. 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-tsvwg-rsvp-user-error-spec-06.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15932&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2008 13:13:11 +0000 Message-ID: <002d01c8997a$2e23b110$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: draft-dasgupta-ccamp-path-comp-analysis-01 Date: Tue, 8 Apr 2008 14:12:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Forwarded on behalf of Sukrit who has some posting problems... ----- Original Message ----- From: "Sukrit Dasgupta" To: ; Sent: Monday, April 07, 2008 6:43 PM Subject: [Pce] draft-dasgupta-ccamp-path-comp-analysis-01 > Hi CCAMP and PCE > > We have an ID: draft-dasgupta-ccamp-path-comp-analysis-01.txt that > was presented in IETF 69 at Chicago. This draft captures a > performance comparison of the per-domain path computation technique > and PCE based path computation for computing inter-domain paths. The > goal of this document is not to pick a winner but to shed some light > on a few performance metrics with simulations carried out on two > representative scenarios. > > During the presentation at IETF69, we had positive comments and > support for this draft. A few comments made on the CCAMP list have > been incorporated. > > ------------------------------------------------------------------------ > ----------------------------------------------------------------------- > Abstract: > This document presents a performance comparison between the per- > domain path computation method and the Path Computation Element > (PCE) > Architecture based Backward Recursive Path Computation (BRPC) > procedure. Metrics to capture the significant performance aspects > are identified and detailed simulations are carried out on realistic > scenarios. A performance analysis for each of the path computation > methods is then undertaken. > ------------------------------------------------------------------------ > ----------------------------------------------------------------------- > > ASCII version: http://www.ietf.org/internet-drafts/draft-dasgupta- > ccamp-path-comp-analysis-01.txt > PDF version: http://www.ietf.org/internet-drafts/draft-dasgupta-ccamp- > path-comp-analysis-01.pdf > > > It would be great if we could get some input/comments/suggestions on > this work from the lists so we could proceed. > > Thanks and Regards, > Sukrit Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2008 12:55: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: Continued Poll for Adoption of Ethernet I-Ds Date: Tue, 8 Apr 2008 13:53:22 +0100 Message-ID: <346DD76A8C47FD4A87FA57FD1DEBCC9C028A8144@E03MVB1-UKBR.domain1.systemhost.net> Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciY0DOZ4hoiUpdsSWSqXbCAbNToMAAp0yoA From: To: , Yes to all Alan=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: 07 April 2008 17:54 To: ccamp@ops.ietf.org Subject: Continued Poll for Adoption of Ethernet I-Ds Hi, We have seen some good support for these I-Ds and no objections, but I don't think we have seen anything like the level of support that was evident in the room in Philadelphia. We haven't seen support from more than half of the authors of the documents. So, please, if you haven't already done so, give an indication of whether or not you support each of these four documents becoming working group drafts.=20 Remember, you can be in favor of some and not other if you like. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, March 27, 2008 9:23 PM Subject: Polling for Adoption of Ethernet I-Ds > Hi, > > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP=20 > working group documents. > > Please express your opinions. > > Note that acceptance of these I-Ds does not mean that the discussion about=20 > the architecture is done. I think we made some progress on that topic in=20 > Philadelphia, and I think the authors took on the task of making some=20 > updates of semantics and for clarity, but I expect the discussion may go=20 > on for a while. > > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > draft-berger-ccamp-gmpls-mef-uni-02.txt > draft-berger-ccamp-gmpls-ether-svcs-01.txt > > Thanks, > Adrian > > >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 08 Apr 2008 09:14:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=nGCzeV916RSKe0EfyUSg767MWnF39auoNj+xKG/tU3I=; b=SSSi3vE8W8chTK+5hUwB3bZSgvxx5PEWrFTuhe4E+A9UetjjhYJmStLamAw0dr6ikDZ3EYmhYbnh0KScsz33LmOIXzIwzgojD7jeqAwEnrshR/Zt5rHm6JnFEANxRhZMgQNyYu+i2NU/Xy3Y/aEuwf9JpYB6lJCz5JKZf+W8Rfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h+Ej6tnRFg6Wo6TwRukXR/UHFnEf/xau/27e8iLgF6BjsRDTdusDchIn5MOzFlrZmRe3mQS/a44PXlGZ5uNnZjInTFaasVSdHPpTZe4IaQ4Qs86w14+PbgFjsWS4AjqvlUumdjrIswpWo23pFW2R9hXh7GkOlPlsZfXHwGR+W+4= Message-ID: <8c99930d0804080211w311159a8gceaebebbcbdf1334@mail.gmail.com> Date: Tue, 8 Apr 2008 05:11:29 -0400 From: "Andrew G. Malis" To: "Adrian Farrel" Subject: Re: Continued Poll for Adoption of Ethernet I-Ds Cc: ccamp@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Adrian, Yes to all. Cheers, Andy On Mon, Apr 7, 2008 at 12:53 PM, Adrian Farrel wrote: > Hi, > > We have seen some good support for these I-Ds and no objections, but I don't > think we have seen anything like the level of support that was evident in > the room in Philadelphia. We haven't seen support from more than half of the > authors of the documents. > > So, please, if you haven't already done so, give an indication of whether or > not you support each of these four documents becoming working group drafts. > Remember, you can be in favor of some and not other if you like. > > Thanks, > Adrian > > ----- Original Message ----- From: "Adrian Farrel" > To: > Sent: Thursday, March 27, 2008 9:23 PM > Subject: Polling for Adoption of Ethernet I-Ds > > > > Hi, > > > > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP > working group documents. > > > > Please express your opinions. > > > > Note that acceptance of these I-Ds does not mean that the discussion about > the architecture is done. I think we made some progress on that topic in > Philadelphia, and I think the authors took on the task of making some > updates of semantics and for clarity, but I expect the discussion may go on > for a while. > > > > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > > draft-berger-ccamp-gmpls-mef-uni-02.txt > > draft-berger-ccamp-gmpls-ether-svcs-01.txt > > > > Thanks, > > Adrian > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Apr 2008 20:59:49 +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: Continued Poll for Adoption of Ethernet I-Ds Date: Mon, 7 Apr 2008 21:57:57 +0100 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0233D547@E03MVB2-UKBR.domain1.systemhost.net> Thread-Topic: Continued Poll for Adoption of Ethernet I-Ds Thread-Index: AciY0DOIvMkBKwaUQCSYbnfEelfIHwADFARw From: To: , Adrian, Here is my view (with some brief rationale): > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt Notionally support. One concern I have revolves around the implications of this para: "4.1.3 Hybrid operation with legacy Ethernet The solution should take into consideration the operational scenario that GMPLS controls Ethernet LSPs over PBB-TE and Legacy Ethernet hybrid networks. This morphs of network architecture is possible considering evolution scenario of Ethernet. In such networks, legacy Ethernet functionality such as Spanning Tree Protocol (SPT), Link Aggregation [IEEE802.3], and so on must co-exist with PBB-TE functionality. The solution must not prevent the simultaneous existence of GMPLS controlled Eth-LSPs and PBB[IEE802.1ah] or PB[IEE802.1ad] with native Ethernet Layer2 control protocols on same node and interface." We must avoid the mistake that different network modes (ie cl-ps or co-ps or co-cs) can somehow 'co-exist' in the same DP layer network (and also have the same CP). More specifically, native Ethernet is cl-ps and PBB-TE is co-ps....so even though the base DP traffic unit of these 2 different network modes looks the same they MUST exist in their own layer network space. This requires that some (lower) server layer network should create *different resource partitions* (in either space, freq or time dimensions) for each client layer network mode type. Aside=3D> For the case of private network services (which also includes 'network builder' transport services, ie how one creates client layer network topology) we are ultimately dealing with a time varying aggregate of message/file/stream applications.....these may not even be supported in the immediate client layer network, but there will ultimately be a 'very top' layer network that does support these. So in the server layer network what we have to deal with are (latent) abstractions of such time varying application aggregates. In such cases the key behaviour that the server network must provide to the client network is one of transparency, ie a client/server layer network relationship must provide full functional decoupling of the client and server layer networks. This is not simply a technically driven requirement but it also has commercial and (in some cases) regulatory drivers. Although this is a necessary condition (at least for reachability isolation of different client service instances) it is not generally sufficient for client service cases which require resource isolation (ie the traffic behaviour of client service instance X cannot impact the traffic behaviour experienced by client service instance Y). To satisfy the latter requirement the server layer network (i) must provide connections (ie only p2p or p2mp constructs allowed - which is also a necessary condition) and (ii) the server layer resources should not be overbooked (for a full sufficiency condition). Although not all client cases need this (strong resource isolation) service from the server layer network, the server layer network must nevertheless have the capability of providing it. All these requirements are forced to be met when the server layer technology belongs to the co-cs mode. However, care is required when the server layer network belongs to the co-ps mode (eg PBB-TE), eg don't violate the rules of a connection. And of course these requirements cannot be assured in the cl-ps mode as this does not, by definition, provide connections. > draft-fedyk-gmpls-ethernet-pbb-te-02.txt Support. Couple of small points: - OAM activation/deactivation (ie CV flow) needs to be synchronised to whatever CP or MP mechanism sets-up/tears-down ESPs for obvious operational reasons. Further, the CP (if ESP signalled) or MP (if ESP provisioned) needs to tell ESP DP sink trail termination point of the expected B-MAC SA. - Although IDs major on security from the perspective of malicious attacks (on the DP/CP/MP) there is also an aspect of security related to defects, ie customer traffic leaking from one connection into another connection under misconnectivity defects. A major advantage for operators and their customers of using domain-unique (non-swapped) labels is that misconnectivity defects are very unlikely to propagate, and in any case are always detectable at a connection trail termination point due to the B-MAC SA in each traffic unit. This benefit exists without running any OAM at all.....indeed, one only requires a CV OAM flow in PBB-TE to detect simple breaks such that they can be distinguished from a quiescent traffic case. This results in a significant opex benefit since it means operators only need to run OAM on important connections and not all connections (which is the case for label-swapping if misconnectivity defects must be detected). Maybe this 'security benefit' should be mentioned in the security section? > draft-berger-ccamp-gmpls-mef-uni-02.txt > draft-berger-ccamp-gmpls-ether-svcs-01.txt No problems with the IDs themselves, as they are only attempting to satisfy externally perceived requirements....but I do have a concern with the external requirements. When we talk about UNIs (and E-NNIs) we should be clear that we are actually dealing with public network services and the horizontal peer-partitioning of a single layer network between different operator and customer parties, ie this is NOT the same as the private 'network builder' case (briefly discussed previously) since that is based on a vertical client/server relationship between different layer networks. A critical issue (usually overlooked in my experience) here is the importance in being clear about the 'end-system message/file/stream application to first layer network adaptation functions'. Ethernet does not currently define such adaptation functions for message/file/stream applications (IP does of course with UDP, TCP and RTP respectively). I don't really want to go into all the detail here, but I simply want to make the point that before folks get too carried away defining UNIs/NNIs (for any network technology) they should be clear that this signifies a clear intention to develop public network services and requires careful attention to the end-system to first layer network adaptation functions.....so it's not simply about defining interworking between CP signalling or routing functions, or even DP OAM functions say. Therefore, as you might guess, whilst we in IETF/CCAMPs may quite easily define UNIs/E-NNIs for the DP (OAM) and CP say, we should also be cognizant of the ultimate implications of the direction MEF and ITU are taking here. Aside=3D> A slight twist on the above is where folks have considered = E-NNI peer interworking between *different* technologies. This recently came up in the ITU wrt T-MPLS OAM in draft G.8114 which was undergoing AAP. G.8114 contained a proposal to peer interwork T-MPLS and Ethernet networks simply because they had both been 'bestowed' with similar, and IMO far too complex, DP OAM. It should be self-evident that it is not sensible to try and interwork 2 technologies that belong to different network modes (simply because there will be significant functional component mismatch across the DP and CP), but in any case there are no end-system application to first layer network adaptations functions defined for either of these technologies (noting that if these were defined they would be required to either (i) pass transparently between the 2 network peer partitions at the interworking point if common or (ii) there would have to be interworking cases defined if not common). It was quite evident that no thought had been given to these matters whatsoever in G.8114 and so we requested that the interworking proposal was removed. Later, and as most folks probably know by now, the AAP progress of G.8114 was stopped anyway due to larger concerns that IETF had on T-MPLS in general.=20 regards, Neil=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: 07 April 2008 17:54 > To: ccamp@ops.ietf.org > Subject: Continued Poll for Adoption of Ethernet I-Ds >=20 >=20 > Hi, >=20 > We have seen some good support for these I-Ds and no > objections, but I don't=20 > think we have seen anything like the level of support that=20 > was evident in=20 > the room in Philadelphia. We haven't seen support from more=20 > than half of the=20 > authors of the documents. >=20 > So, please, if you haven't already done so, give an > indication of whether or=20 > not you support each of these four documents becoming working=20 > group drafts.=20 > Remember, you can be in favor of some and not other if you like. >=20 > Thanks, > Adrian >=20 > ----- Original Message ----- > From: "Adrian Farrel" > To: > Sent: Thursday, March 27, 2008 9:23 PM > Subject: Polling for Adoption of Ethernet I-Ds >=20 >=20 > > Hi, > > > > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP > > working group documents. > > > > Please express your opinions. > > > > Note that acceptance of these I-Ds does not mean that the > discussion > > about > > the architecture is done. I think we made some progress on > that topic in > > Philadelphia, and I think the authors took on the task of > making some > > updates of semantics and for clarity, but I expect the > discussion may go > > on for a while. > > > > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > > draft-berger-ccamp-gmpls-mef-uni-02.txt > > draft-berger-ccamp-gmpls-ether-svcs-01.txt > > > > Thanks, > > Adrian > > > > > >=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Apr 2008 18:51:57 +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: Polling for Adoption of Ethernet I-Ds Date: Mon, 7 Apr 2008 14:49:49 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D1468B0AA@zcarhxm0.corp.nortel.com> Thread-Topic: Polling for Adoption of Ethernet I-Ds Thread-Index: AciQSzi1US4kTWcKRlOB8mr6QZczRQIlN0aQ From: "Hamid Ould-Brahim" To: "Adrian Farrel" , Yes to all. Hamid. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Thursday, March 27, 2008 4:23 PM > To: ccamp@ops.ietf.org > Subject: Polling for Adoption of Ethernet I-Ds >=20 > Hi, >=20 > From Philadelphia, we have four candidate I-Ds for adoption=20 > as CCAMP working group documents. >=20 > Please express your opinions. >=20 > Note that acceptance of these I-Ds does not mean that the=20 > discussion about the architecture is done. I think we made=20 > some progress on that topic in Philadelphia, and I think the=20 > authors took on the task of making some updates of semantics=20 > and for clarity, but I expect the discussion may go on for a while. >=20 > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > draft-berger-ccamp-gmpls-mef-uni-02.txt > draft-berger-ccamp-gmpls-ether-svcs-01.txt >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Apr 2008 16:55:22 +0000 Message-ID: <033b01c898cf$ee650830$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Continued Poll for Adoption of Ethernet I-Ds Date: Mon, 7 Apr 2008 17:53:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit Hi, We have seen some good support for these I-Ds and no objections, but I don't think we have seen anything like the level of support that was evident in the room in Philadelphia. We haven't seen support from more than half of the authors of the documents. So, please, if you haven't already done so, give an indication of whether or not you support each of these four documents becoming working group drafts. Remember, you can be in favor of some and not other if you like. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, March 27, 2008 9:23 PM Subject: Polling for Adoption of Ethernet I-Ds > Hi, > > From Philadelphia, we have four candidate I-Ds for adoption as CCAMP > working group documents. > > Please express your opinions. > > Note that acceptance of these I-Ds does not mean that the discussion about > the architecture is done. I think we made some progress on that topic in > Philadelphia, and I think the authors took on the task of making some > updates of semantics and for clarity, but I expect the discussion may go > on for a while. > > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > draft-berger-ccamp-gmpls-mef-uni-02.txt > draft-berger-ccamp-gmpls-ether-svcs-01.txt > > Thanks, > Adrian > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Apr 2008 12:59:09 +0000 Message-ID: <02b201c898ae$c3a103e0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Acee Lindem" Cc: "CCAMP List" , "OSPF List" Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions toOSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt Date: Mon, 7 Apr 2008 13:56:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Thanks Acee, That does the job. Adrian ----- Original Message ----- From: "Acee Lindem" Cc: "CCAMP List" ; "OSPF List" Sent: Sunday, April 06, 2008 12:15 PM Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions toOSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt > Alan Davey pointed out that I was missing the word "is" in my text. I > went ahead with a more verbose explanation of the protocol differences. > > *************** > *** 342,348 **** > The Link TLV describes a single link and consists of a set of sub- > TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID > sub- > TLV are applicable to OSPFv3. The Link ID sub-TLV can't be > used in > ! OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3. > > Three new sub-TLVs for the Link TLV are defined: > > --- 342,356 ---- > The Link TLV describes a single link and consists of a set of sub- > TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID > sub- > TLV are applicable to OSPFv3. The Link ID sub-TLV can't be > used in > ! OSPFv3 since it is defined to use the OSPFv2 identification for the > ! Designated Router (DR) on multi-access networks. In OSPFv2, > ! neighbors on point-to-point networks and virtual links are > identified > ! by their Router IDs while neighbors on broadcast, Non-Broadcast > ! Multi-Access (NBMA), and Point-to-Multipoint links are > identified by > ! their IPv4 interface addresses (Refer to section 8.2 in [OSPFV2]). > ! The IPv4 interface address is not known to OSPFv3. In contrast to > ! OSPFv2, OSPFv3 always identifies neighboring routers by their > Router > ! IDs (Refer to section 2.11 in [OSPFV3]). > > Three new sub-TLVs for the Link TLV are defined: > > *************** > > > On Apr 5, 2008, at 12:51 PM, Acee Lindem wrote: > >> Adrian, >> >> How's this: >> >> *************** >> *** 342,348 **** >> The Link TLV describes a single link and consists of a set of >> sub- >> TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID >> sub- >> TLV are applicable to OSPFv3. The Link ID sub-TLV can't be >> used in >> ! OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3. >> >> Three new sub-TLVs for the Link TLV are defined: >> >> --- 342,351 ---- >> The Link TLV describes a single link and consists of a set of >> sub- >> TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID >> sub- >> TLV are applicable to OSPFv3. The Link ID sub-TLV can't be >> used in >> ! OSPFv3 since it defined to contain the IPv4 address of the >> Designated >> ! Router (DR) for multi-access interfaces. In contrast to OSPFv2, >> ! OSPFv3 always identifies a neighboring router by the Router ID >> (Refer >> ! to section 2.11 in [OSPFV3]). >> >> Three new sub-TLVs for the Link TLV are defined: >> >> *************** >> >> I plan to wait until the WG last call has completed to submit the >> update. >> Thanks, >> Acee >> >> On Apr 5, 2008, at 11:50 AM, Acee Lindem wrote: >> >>> Hi Adrian, >>> >>> Thanks for the review. >>> >>> On Apr 4, 2008, at 3:56 PM, Adrian Farrel wrote: >>> >>>> Hi, >>>> >>>> Just a couple of comments... >>>> >>>> === >>>> Section 1 >>>> s/proposes the addition of/defines/ >>> >>> Changed. >>> >>> >>>> === >>>> Section 4 >>>> Forgive me for not remembering this discussion... >>>> The draft says that we cannot use the Link ID sub-TLV "due to the >>>> protocol >>>> differences." >>> >>> The link-ID is cannot be used since, in the case of multi-access >>> network, it contains the IPv4 address of the Designated Router (DR). >>> OSPFv3 doesn't have this information. >>> >>> >>>> It then says that the Link ID sub-TLV SHOULD NOT be included >>>> (implying that >>>> it MAY be included under certain circumstances) but MUST be ignored. >>> >>> This is the spirit of being conservative in what one sends and >>> liberal in what one excepts. >>> >>> >>> >>>> 1. Does ignored mean "continue to be flooded" or "stripped from the >>>> LSA"? >>> >>> In OSPF, only the originator should modify an LSA. So, it means >>> neither. >>> >>> >>> >>>> 2. Is it not possible to consider operating a GMPLS control plane >>>> in an IPv6 >>>> network where the routers use IPv6 addresses to communicate (so all >>>> control >>>> plane messages will be addressed using IPv6, and the router address >>>> will be >>>> IPv6 as described in Section 3) but where the data channel >>>> identifiers are >>>> assigned from an IPv4 address space? Recall that in GMPLS the >>>> interfaces >>>> used for OSPF exchange are not those used for data exchange. >>> >>> I believe it is probable that IPv4 and IPv6 will coexist. However, >>> OSPFv3 doesn't know the IPv4 address of the DR (at least it is not >>> standardized). Hence, this isn't the right sub-TLV to reflect this >>> topology. >>> >>> >>> >>>> >>>> Whatever the answers, I think it would help if the reasons were >>>> clarified >>>> beyond "protocol differences." >>> >>> I'll expand this to describe the multi-access network case. Sound >>> good? >>> >>> Thanks, >>> Acee >>> >>> >>> >>>> === >>>> >>>> Cheers, >>>> Adrian >>>> >>>> PS I wouldn't mind if you spelled my name right in the acks >>>> section :-) >>>> >>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 07 Apr 2008 02:14:14 +0000 Date: Mon, 07 Apr 2008 10:11:00 +0800 From: Mach Chen Subject: Re: Re: [OSPF] CCAMP last call on advertisement of inter-AS TE links To: Acee Lindem , Adrian Farrel Cc: OSPF List , CCAMP List Message-id: <200804071010599657422@huawei.com> Organization: Huawei MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi Acee, Thanks for your review and comments! Since there are no technical issues, I will update the I-D until the end of the WG last call. On 2008-04-04, at 22:49:13 Acee Lindem wrote: >I can't speak for the OSPF WG as a whole, but I have reviewed the >subject document and am very happy to see that the suggestion to use >separate inter-AS LSA types has been incorporated. I have no further >technical comments on the document and trust that the ccamp WG has >verified that this information encoding meets the TE requirements. >The usage described in sections 2.2 and 2.3 seem reasonable to me. > >I have the following editorial comments: > > 1. Sections 3.3.2 and 3.3.2 - Both of these say "Use of the TE >Router ID is RECOMMENDED." I believe these should be respectively >replaced by "Use of the TE Router Address as specified in the Router >Address TLV [OSPF-TE] is RECOMMENDED." and "Use of the TE Router IPv6 >Address as specified in the IPv6 Router Address as specified in the >IPv6 Router Address TLV [OSPF-V3-TE] is RECOMMENDED." > 2. Section 3.2.1 states "This is because... that may operate in a >different address space;". If they are using a different address >space on the link between the ASes, then I'd expect there to be >problems with BGP as well :^) I'd suggest: > "Given that OSPF is an IGP and should only be utilized between >routers in the same routing domain, the OSPF specific Link ID and >Neighbor ID sub-TLVs are not applicable to inter-AS links.". > 3. You may want to expand some acronyms on their first use. For >example, "AS Boundary Router (ASBR)", "Link State Advertisement >(LSA)" and > "Path Computation Element (PCE)". > 4. [OSPFV3] is listed to as both a Normative and Informative >reference. > >Thanks, >Acee > >On Mar 19, 2008, at 2:06 PM, Adrian Farrel wrote: > >> Hi, >> >> You may recall providing useful review and feedback on >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- >> te-extension-02.txt >> >> The authors believe that they have taken on board all the comments >> received >> from the OSPF working group and have updated the draft accordingly. >> >> >> CCAMP is holding a three week working group last call on this I-D >> along with >> its IS-IS partner document: >> >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas- >> te-extension-00.txt >> >> These documents describe how to advertise the TE links that connect >> an AS to >> the outside world within the AS's IGP. As the drafts are at pains >> to point >> out, there is no proposal to advertise the TE information more >> widely (such >> as to other ASes). >> >> The last call will end at 12 noon BST on April 9th 2008. >> >> Please send your comments to the CCAMP list or direct to the CCAMP >> chairs. >> >> Thanks, >> Adrian and Deborah >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > Best regards, Mach Chen Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 06 Apr 2008 11:17:33 +0000 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: CCAMP List , OSPF List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions to OSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt Date: Sun, 6 Apr 2008 07:15:18 -0400 Alan Davey pointed out that I was missing the word "is" in my text. I went ahead with a more verbose explanation of the protocol differences. *************** *** 342,348 **** The Link TLV describes a single link and consists of a set of sub- TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID sub- TLV are applicable to OSPFv3. The Link ID sub-TLV can't be used in ! OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3. Three new sub-TLVs for the Link TLV are defined: --- 342,356 ---- The Link TLV describes a single link and consists of a set of sub- TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID sub- TLV are applicable to OSPFv3. The Link ID sub-TLV can't be used in ! OSPFv3 since it is defined to use the OSPFv2 identification for the ! Designated Router (DR) on multi-access networks. In OSPFv2, ! neighbors on point-to-point networks and virtual links are identified ! by their Router IDs while neighbors on broadcast, Non-Broadcast ! Multi-Access (NBMA), and Point-to-Multipoint links are identified by ! their IPv4 interface addresses (Refer to section 8.2 in [OSPFV2]). ! The IPv4 interface address is not known to OSPFv3. In contrast to ! OSPFv2, OSPFv3 always identifies neighboring routers by their Router ! IDs (Refer to section 2.11 in [OSPFV3]). Three new sub-TLVs for the Link TLV are defined: *************** On Apr 5, 2008, at 12:51 PM, Acee Lindem wrote: > Adrian, > > How's this: > > *************** > *** 342,348 **** > The Link TLV describes a single link and consists of a set of > sub- > TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID > sub- > TLV are applicable to OSPFv3. The Link ID sub-TLV can't be > used in > ! OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3. > > Three new sub-TLVs for the Link TLV are defined: > > --- 342,351 ---- > The Link TLV describes a single link and consists of a set of > sub- > TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID > sub- > TLV are applicable to OSPFv3. The Link ID sub-TLV can't be > used in > ! OSPFv3 since it defined to contain the IPv4 address of the > Designated > ! Router (DR) for multi-access interfaces. In contrast to OSPFv2, > ! OSPFv3 always identifies a neighboring router by the Router ID > (Refer > ! to section 2.11 in [OSPFV3]). > > Three new sub-TLVs for the Link TLV are defined: > > *************** > > I plan to wait until the WG last call has completed to submit the > update. > Thanks, > Acee > > On Apr 5, 2008, at 11:50 AM, Acee Lindem wrote: > >> Hi Adrian, >> >> Thanks for the review. >> >> On Apr 4, 2008, at 3:56 PM, Adrian Farrel wrote: >> >>> Hi, >>> >>> Just a couple of comments... >>> >>> === >>> Section 1 >>> s/proposes the addition of/defines/ >> >> Changed. >> >> >>> === >>> Section 4 >>> Forgive me for not remembering this discussion... >>> The draft says that we cannot use the Link ID sub-TLV "due to the >>> protocol >>> differences." >> >> The link-ID is cannot be used since, in the case of multi-access >> network, it contains the IPv4 address of the Designated Router (DR). >> OSPFv3 doesn't have this information. >> >> >>> It then says that the Link ID sub-TLV SHOULD NOT be included >>> (implying that >>> it MAY be included under certain circumstances) but MUST be ignored. >> >> This is the spirit of being conservative in what one sends and >> liberal in what one excepts. >> >> >> >>> 1. Does ignored mean "continue to be flooded" or "stripped from the >>> LSA"? >> >> In OSPF, only the originator should modify an LSA. So, it means >> neither. >> >> >> >>> 2. Is it not possible to consider operating a GMPLS control plane >>> in an IPv6 >>> network where the routers use IPv6 addresses to communicate (so all >>> control >>> plane messages will be addressed using IPv6, and the router address >>> will be >>> IPv6 as described in Section 3) but where the data channel >>> identifiers are >>> assigned from an IPv4 address space? Recall that in GMPLS the >>> interfaces >>> used for OSPF exchange are not those used for data exchange. >> >> I believe it is probable that IPv4 and IPv6 will coexist. However, >> OSPFv3 doesn't know the IPv4 address of the DR (at least it is not >> standardized). Hence, this isn't the right sub-TLV to reflect this >> topology. >> >> >> >>> >>> Whatever the answers, I think it would help if the reasons were >>> clarified >>> beyond "protocol differences." >> >> I'll expand this to describe the multi-access network case. Sound >> good? >> >> Thanks, >> Acee >> >> >> >>> === >>> >>> Cheers, >>> Adrian >>> >>> PS I wouldn't mind if you spelled my name right in the acks >>> section :-) >>> >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Apr 2008 16:51:55 +0000 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <02388B0D-3AB4-4954-B459-4FD88AB04440@redback.com> Cc: Adrian Farrel , CCAMP List , OSPF List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions to OSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt Date: Sat, 5 Apr 2008 12:51:00 -0400 Adrian, How's this: *************** *** 342,348 **** The Link TLV describes a single link and consists of a set of sub- TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID sub- TLV are applicable to OSPFv3. The Link ID sub-TLV can't be used in ! OSPFv3 due to the protocol differences between OSPFv2 and OSPFv3. Three new sub-TLVs for the Link TLV are defined: --- 342,351 ---- The Link TLV describes a single link and consists of a set of sub- TLVs [TE]. All of the sub-TLVs in [TE] other than the Link ID sub- TLV are applicable to OSPFv3. The Link ID sub-TLV can't be used in ! OSPFv3 since it defined to contain the IPv4 address of the Designated ! Router (DR) for multi-access interfaces. In contrast to OSPFv2, ! OSPFv3 always identifies a neighboring router by the Router ID (Refer ! to section 2.11 in [OSPFV3]). Three new sub-TLVs for the Link TLV are defined: *************** I plan to wait until the WG last call has completed to submit the update. Thanks, Acee On Apr 5, 2008, at 11:50 AM, Acee Lindem wrote: > Hi Adrian, > > Thanks for the review. > > On Apr 4, 2008, at 3:56 PM, Adrian Farrel wrote: > >> Hi, >> >> Just a couple of comments... >> >> === >> Section 1 >> s/proposes the addition of/defines/ > > Changed. > > >> === >> Section 4 >> Forgive me for not remembering this discussion... >> The draft says that we cannot use the Link ID sub-TLV "due to the >> protocol >> differences." > > The link-ID is cannot be used since, in the case of multi-access > network, it contains the IPv4 address of the Designated Router (DR). > OSPFv3 doesn't have this information. > > >> It then says that the Link ID sub-TLV SHOULD NOT be included >> (implying that >> it MAY be included under certain circumstances) but MUST be ignored. > > This is the spirit of being conservative in what one sends and > liberal in what one excepts. > > > >> 1. Does ignored mean "continue to be flooded" or "stripped from the >> LSA"? > > In OSPF, only the originator should modify an LSA. So, it means > neither. > > > >> 2. Is it not possible to consider operating a GMPLS control plane >> in an IPv6 >> network where the routers use IPv6 addresses to communicate (so all >> control >> plane messages will be addressed using IPv6, and the router address >> will be >> IPv6 as described in Section 3) but where the data channel >> identifiers are >> assigned from an IPv4 address space? Recall that in GMPLS the >> interfaces >> used for OSPF exchange are not those used for data exchange. > > I believe it is probable that IPv4 and IPv6 will coexist. However, > OSPFv3 doesn't know the IPv4 address of the DR (at least it is not > standardized). Hence, this isn't the right sub-TLV to reflect this > topology. > > > >> >> Whatever the answers, I think it would help if the reasons were >> clarified >> beyond "protocol differences." > > I'll expand this to describe the multi-access network case. Sound > good? > > Thanks, > Acee > > > >> === >> >> Cheers, >> Adrian >> >> PS I wouldn't mind if you spelled my name right in the acks >> section :-) >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 05 Apr 2008 15:53:26 +0000 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <90CE7EEE-1F2F-44DD-8B58-A5F9C6A49C4B@redback.com> Cc: "OSPF List" , CCAMP List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions to OSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt Date: Sat, 5 Apr 2008 11:50:25 -0400 To: Adrian Farrel Hi Adrian, Thanks for the review. On Apr 4, 2008, at 3:56 PM, Adrian Farrel wrote: > Hi, > > Just a couple of comments... > > === > Section 1 > s/proposes the addition of/defines/ Changed. > === > Section 4 > Forgive me for not remembering this discussion... > The draft says that we cannot use the Link ID sub-TLV "due to the > protocol > differences." The link-ID is cannot be used since, in the case of multi-access network, it contains the IPv4 address of the Designated Router (DR). OSPFv3 doesn't have this information. > It then says that the Link ID sub-TLV SHOULD NOT be included > (implying that > it MAY be included under certain circumstances) but MUST be ignored. This is the spirit of being conservative in what one sends and liberal in what one excepts. > 1. Does ignored mean "continue to be flooded" or "stripped from the > LSA"? In OSPF, only the originator should modify an LSA. So, it means neither. > 2. Is it not possible to consider operating a GMPLS control plane > in an IPv6 > network where the routers use IPv6 addresses to communicate (so all > control > plane messages will be addressed using IPv6, and the router address > will be > IPv6 as described in Section 3) but where the data channel > identifiers are > assigned from an IPv4 address space? Recall that in GMPLS the > interfaces > used for OSPF exchange are not those used for data exchange. I believe it is probable that IPv4 and IPv6 will coexist. However, OSPFv3 doesn't know the IPv4 address of the DR (at least it is not standardized). Hence, this isn't the right sub-TLV to reflect this topology. > > Whatever the answers, I think it would help if the reasons were > clarified > beyond "protocol differences." I'll expand this to describe the multi-access network case. Sound good? Thanks, Acee > === > > Cheers, > Adrian > > PS I wouldn't mind if you spelled my name right in the acks > section :-) > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Apr 2008 19:58:45 +0000 Message-ID: <003001c8968d$ea0217e0$0300a8c0@your029b8cecfe> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "OSPF List" Cc: "CCAMP List" Subject: Re: [OSPF] OSPF WG Last Call for Traffic Engineering Extensions to OSPFversion 3 - draft-ietf-ospf-ospfv3-traffic-10.txt Date: Fri, 4 Apr 2008 20:56:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Just a couple of comments... === Section 1 s/proposes the addition of/defines/ === Section 4 Forgive me for not remembering this discussion... The draft says that we cannot use the Link ID sub-TLV "due to the protocol differences." It then says that the Link ID sub-TLV SHOULD NOT be included (implying that it MAY be included under certain circumstances) but MUST be ignored. 1. Does ignored mean "continue to be flooded" or "stripped from the LSA"? 2. Is it not possible to consider operating a GMPLS control plane in an IPv6 network where the routers use IPv6 addresses to communicate (so all control plane messages will be addressed using IPv6, and the router address will be IPv6 as described in Section 3) but where the data channel identifiers are assigned from an IPv4 address space? Recall that in GMPLS the interfaces used for OSPF exchange are not those used for data exchange. Whatever the answers, I think it would help if the reasons were clarified beyond "protocol differences." === Cheers, Adrian PS I wouldn't mind if you spelled my name right in the acks section :-) Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Apr 2008 14:48:41 +0000 Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: OSPF List , CCAMP List Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: [OSPF] CCAMP last call on advertisement of inter-AS TE links Date: Fri, 4 Apr 2008 10:46:16 -0400 To: Adrian Farrel I can't speak for the OSPF WG as a whole, but I have reviewed the subject document and am very happy to see that the suggestion to use separate inter-AS LSA types has been incorporated. I have no further technical comments on the document and trust that the ccamp WG has verified that this information encoding meets the TE requirements. The usage described in sections 2.2 and 2.3 seem reasonable to me. I have the following editorial comments: 1. Sections 3.3.2 and 3.3.2 - Both of these say "Use of the TE Router ID is RECOMMENDED." I believe these should be respectively replaced by "Use of the TE Router Address as specified in the Router Address TLV [OSPF-TE] is RECOMMENDED." and "Use of the TE Router IPv6 Address as specified in the IPv6 Router Address as specified in the IPv6 Router Address TLV [OSPF-V3-TE] is RECOMMENDED." 2. Section 3.2.1 states "This is because... that may operate in a different address space;". If they are using a different address space on the link between the ASes, then I'd expect there to be problems with BGP as well :^) I'd suggest: "Given that OSPF is an IGP and should only be utilized between routers in the same routing domain, the OSPF specific Link ID and Neighbor ID sub-TLVs are not applicable to inter-AS links.". 3. You may want to expand some acronyms on their first use. For example, "AS Boundary Router (ASBR)", "Link State Advertisement (LSA)" and "Path Computation Element (PCE)". 4. [OSPFV3] is listed to as both a Normative and Informative reference. Thanks, Acee On Mar 19, 2008, at 2:06 PM, Adrian Farrel wrote: > Hi, > > You may recall providing useful review and feedback on > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas- > te-extension-02.txt > > The authors believe that they have taken on board all the comments > received > from the OSPF working group and have updated the draft accordingly. > > > CCAMP is holding a three week working group last call on this I-D > along with > its IS-IS partner document: > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-isis-interas- > te-extension-00.txt > > These documents describe how to advertise the TE links that connect > an AS to > the outside world within the AS's IGP. As the drafts are at pains > to point > out, there is no proposal to advertise the TE information more > widely (such > as to other ASes). > > The last call will end at 12 noon BST on April 9th 2008. > > Please send your comments to the CCAMP list or direct to the CCAMP > chairs. > > Thanks, > Adrian and Deborah > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 04 Apr 2008 09:45:33 +0000 Message-ID: <47F5F7EF.5030906@pi.se> Date: Fri, 04 Apr 2008 11:42:07 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: mpls@ietf.org, ccamp , l1vpn@ietf.org, pwe3 , L2VPN CC: David Ward , Ross Callon , George Swallow Subject: conclusion on the status of Y.1711 and RFC3429 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, on March 28 the MPLS WG chairs polled the several working group mailing lists about the state of Y.1711 and RFC3429 implementations and deployments. Our conclusion is that there is enough implementations and deployments of Y.1711 and hence it is not possible to, for time being, deprecate label 14 or obsolete RFC3429. This conclusion however leaves with the issue of investigating if Y.1711, other ITU-T documents and RFC3429 is well enough aligned or if updates is needed. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 03 Apr 2008 11:40:49 +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: Question on the status of Y.1711 and RFC3429 Date: Thu, 3 Apr 2008 14:38:30 +0300 Message-ID: <64122293A6365B4A9794DC5636F9ACFD02D3D118@ILPTEX02.ecitele.com> Thread-Topic: Question on the status of Y.1711 and RFC3429 Thread-Index: AciQsMzOn/guAnfHTHCRQvl2K2wxvAEzhEzw From: Alexander Vainshtein To: "Loa Andersson" , , CC: "Ross Callon" , "David Ward" , "pwe3" , , "L2VPN" , "ccamp" Loa, George and all, ECI Telecom has implemented ITU-T recommendation Y.1711 using=20 Label 14 as defined in RFC 3429 in its XDM (TM) products family.=20 The corresponding products have been deployed in live=20 networks, and their Y.1711-related functionality is now in=20 operational use. Based on this, we (ECI) object to deprecation of the Label 14=20 allocation that is currently defined in RFC 3429 and suggests using a different reserved label value for T-MPLS needs. Regards, Sasha=20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Loa Andersson > Sent: Friday, March 28, 2008 11:50 AM > To: mpls@ietf.org; pwe3; l3vpn@ietf.org; L2VPN; ccamp > Cc: Ross Callon; David Ward > Subject: Question on the status of Y.1711 and RFC3429 >=20 > All, >=20 > In the discussions the IETF and the ITU-T have had on T-MPLS we have > discussed the intended use for label 14 and the different documents > where this has been specified. >=20 > As a side effect we've also started to ask ourselves if there are any > implementations and/or deployments that uses label 14. >=20 > A quick survey among known implementers of MPLS has not shown any > implementations/deployments. >=20 > Since one of the approaches discussed in the Joint Working Team > context is a solution that requires the allocation of a reserved > label and reserved labels are a scarce resource we'd like to know > if it possible to redefine label 14 for that particular use. >=20 > There are still technical issues to be sorted out with the suggested > approach, but in the mean time we would like to know if it is possible > to deprecate RFC3429 and redefine the OAM Alert Label. >=20 > The questions is: "Are there any implementations/deployments of Y.1711 > or the OAM Alert label as it is allocated in RFC3429; and is there > objection to deprecating the protocol as it stands today?" >=20 > ITU-T has sent out a question along the same lines, see the included > mail below. >=20 > Please respond to the mpls working group mailing list or to the mpls > working chairs directly. As usual non-responses will be counted as > that there is no implementation/deployment. >=20 > Loa and George >=20 >=20 > ------------------- included mail ------------------------------------ >=20 > All users/implementers of recommendation Y.1711, >=20 > Currently the Joint Working Team of ITU-T and IETF experts is > considering the options of using IETF mechanisms to provide > OAM for T-MPLS. >=20 > One possibility is the following mechanism: > ------------------------------------------- > Push/pop a label at the MEP/domain boundary. >=20 > This makes the OAM alert label directly visible at the > sink MEP. >=20 > To make the OAM label visible to a MIP the TTL in the server > (lower) layer is set by the MEP to expire when the OAM frame > reaches the intended MIP. >=20 > The OAM alert label will point to an "opcode" at the bottom > of the stack. > ------------------------------------------ >=20 > This behaviour (when the OAM alert label is received) is not > consistent with the behaviour currently defined in Y.1711 when > label 14 is received. >=20 > *QUESTION* are there any users/implementers of the current Y.1711 > concerned with this change in behaviour? >=20 > If there are no concerns then recommendation Y.1711 can be > withdrawn or revised to describe the desired behaviour (described > above). >=20 > Please send me (or this list) your response ASAP. >=20 > Kind regards, Huub van Helvoort, your rapporteur. >=20 > --=20 > Loa Andersson >=20 > Principal Networking Architect > Acreo AB phone: +46 8 632 77 14 > Isafjordsgatan 22 mobile: +46 739 81 21 64 > Kista, Sweden email: loa.andersson@acreo.se > loa@pi.se >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 01 Apr 2008 00:59:26 +0000 Message-ID: <47F1886B.8050507@kddilabs.jp> Date: Tue, 01 Apr 2008 09:57:15 +0900 From: Tomohiro Otani User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: Polling for Adoption of Ethernet I-Ds Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello everyone, I support these documents for adoption as WG documents in ccamp WG. Regards, Tomo Adrian Farrel =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81= =97=E3=81=9F: > Hi, > >> From Philadelphia, we have four candidate I-Ds for adoption as CCAMP=20 >> working=20 > group documents. > > Please express your opinions. > > Note that acceptance of these I-Ds does not mean that the discussion=20 > about the architecture is done. I think we made some progress on that=20 > topic in Philadelphia, and I think the authors took on the task of=20 > making some updates of semantics and for clarity, but I expect the=20 > discussion may go on for a while. > > draft-imajuku-ccamp-ethernet-gmpls-req-01.txt > draft-fedyk-gmpls-ethernet-pbb-te-02.txt > draft-berger-ccamp-gmpls-mef-uni-02.txt > draft-berger-ccamp-gmpls-ether-svcs-01.txt > > Thanks, > Adrian > > > >