From Attila.Takacs@ericsson.com Tue Dec 1 02:48:55 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF82D3A67FC; Tue, 1 Dec 2009 02:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 orz6vfe0UtcH; Tue, 1 Dec 2009 02:48:54 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2ECAF3A684F; Tue, 1 Dec 2009 02:48:53 -0800 (PST) X-AuditID: c1b4fb3c-b7b08ae000000935-a7-4b14f48d4f55 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id F3.C2.02357.D84F41B4; Tue, 1 Dec 2009 11:48:45 +0100 (CET) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 11:48:45 +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 Date: Tue, 1 Dec 2009 11:48:44 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts Thread-Index: Acpyc9otSWxyGHD2SjOmfJZ7NEzfiA== From: "Attila Takacs" To: , X-OriginalArrivalTime: 01 Dec 2009 10:48:45.0360 (UTC) FILETIME=[DAF25300:01CA7273] X-Brightmail-Tracker: AAAAAA== Subject: [CCAMP] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 10:48:55 -0000 Hi all, Some thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts. I think we need to extend the OAM Function flags (described in draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: -CC -CV -PM Loss -PM Delay -Fault Management signals With regards to BFD I see three operation vs. configuration modes: 1) Set CC in the flags and only bootstrap the BFD session, by sending the local discriminator values in RSVP-TE and leave timer negotiation to BFD control messages. This is similar to LSP Ping based bootstrapping described in draft-ietf-bfd-mpls-07.txt. 2) Set CC in the flags but configure the timers via the control plane, this should correspond to "CC mode" in draft-asm-mpls-tp-bfd-cc-cv-01. We may include the min/max intervals and by doing so support initial timer negotiation in control plane. However, we may need a flag in CC configuration sub-TLV (now in draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called "Suggested TX Interval sub-TLV") to indicate whether data plane timer renegotiation is enabled or disabled (i.e., subsequently via BFD control messages). This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be disabled for TP LSPs by default. 3) In case of "full" MPLS-TP OAM support any of the flags could be set as needed, reflecting "CV/CC mode" described in draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as described in draft-frost-mpls-tp-loss-delay-00 and management signals as given in draft-sfv-mpls-tp-fault-00. To configure CC we will need to add -enable/disable DP timer re-negotiation -PHB to identify priority and drop precedence of CC packets When it comes to CV, it would be interesting to discuss whether only the OAM identifiers described in draft-ietf-mpls-tp-identifiers-00 are ought to be supported. If so, those could be derived from RSVP-TE signaling without the need to carry them explicitly in MPLS-TP OAM Configuration sub-TLVs (now called Source unique MEP_ID sub-TLV in draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03).=20 For Performance Monitoring Loss/Delay we need to add new TLVs, carrying -measurement interval -possibly loss/delay bound thresholds (given we what these for MPLS-TP) that could be used to assess the quality of the connection and may eventually trigger protection -PHB of control packets if we want to set it differently from CC packets or from data traffic. For the Fault Management Signals, I would add a new "Fault Management Signals sub-TLV" carrying: -Enabled signals flags: AIS, LDI, LKR, CFS (which, except CFS, are specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault indication messages -flag to enable/disable explicitly clear of faults -PHB of fault management packets=20 Another thing we may want to consider is adding a sub-TLV to set consequent actions that are configurable. This is described to some extent in the MPLS-TP OAM Framework. The defects identified include: Loss Of Continuity defect, Mis-connectivity defect, MEP misconfiguration defect, Period Misconfiguration defect. An operator may want to configure if the consequence of LOC should be the blocking or non-blocking of outgoing data traffic. Similarly it may be useful to configure whether the "Period Misconfiguration defect" should result in a signal fail condition or not. I plan to send detailed text to the editors of draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the lines described above. Please comment! Thanks, Attila From lberger@labn.net Tue Dec 1 04:02:35 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330333A684E for ; Tue, 1 Dec 2009 04:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 8d3PsC9zPlvt for ; Tue, 1 Dec 2009 04:02:35 -0800 (PST) Received: from outbound-mail-21.bluehost.com (outbound-mail-21.bluehost.com [69.89.21.16]) by core3.amsl.com (Postfix) with SMTP id EEBD43A6819 for ; Tue, 1 Dec 2009 04:02:34 -0800 (PST) Received: (qmail 6716 invoked by uid 0); 1 Dec 2009 11:55:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy2.bluehost.com with SMTP; 1 Dec 2009 11:55:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=tGaTcKV9htXApzNFb5biBxZyYkc2xfGCBo8w9ZvU6biLgX9auzE0qi0sWSTdiaSruiscmwvlfaL3ORz5yxGEwKihs4VOlF12TatQ7TpLzIDIgT8tstjI7M8u1JDjtejU; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NFRKe-0008J4-9I; Tue, 01 Dec 2009 04:55:48 -0700 Message-ID: <4B150443.70805@labn.net> Date: Tue, 01 Dec 2009 06:55:47 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Attila Takacs References: <4B0FAEDB.8030104@pi.nu> <53CCFDD6E346CB43994852666C210E91092283B0@esealmw116.eemea.ericsson.se> <8c99930d0911300943k413eeb56md6669e3ba86cc614@mail.gmail.com> <53CCFDD6E346CB43994852666C210E910925C4DB@esealmw116.eemea.ericsson.se> In-Reply-To: <53CCFDD6E346CB43994852666C210E910925C4DB@esealmw116.eemea.ericsson.se> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org, mpls-tp@ietf.org, "DEBORAH A, ATTLABS BRUNGARD" Subject: Re: [CCAMP] [mpls-tp] OAM configuration via the control plane - four drafts that needs to coordinated X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 12:02:35 -0000 Attila, While unusual, I see no real issues with suspending the poll. All, Please keep in mind that becoming a WG document does not mean that the technical details of a document are frozen. It does mean that the working group become the authoritative body for technical content, i.e., WG consensus drives a WG document while author consensus drives an individual document. Lou On 12/1/2009 1:20 AM, Attila Takacs wrote: > Hi Deborah, Lou, all, > > Given the interest in the new technology specific OAM configuration documents and the proposed update of the framework itself, the authors of draft-kern and draft-bellagamba would like to work together updating their documents, in parallel with an update of the framework document, before asking to become WG documents. > > Hence, I would like to ask the CCAMP chairs to suspend the call of draft-kern, and reinitiate it once the updates took place. > > Thanks, > Attila > >> -----Original Message----- >> From: Andrew G. Malis [mailto:agmalis@gmail.com] >> Sent: Monday, November 30, 2009 6:43 PM >> To: Attila Takacs >> Cc: Loa Andersson; mpls-tp@ietf.org; ccamp@ietf.org >> Subject: Re: [CCAMP] [mpls-tp] OAM configuration via the >> control plane - four drafts that needs to coordinated >> >> Attila and Loa, >> >> I certainly agree that the four drafts in question need to be >> consistent and should be worked in parallel to keep them that way. >> Also, Loa's request to follow Bob's precedent in RFC 5036 for >> TLV specification is certainly reasonable. Also, the first >> alternative in Attila's email (adding an additional 32 flag >> bits) seems the simpler choice. >> >> Cheers, >> Andy >> >> On Mon, Nov 30, 2009 at 2:25 PM, Attila Takacs >> wrote: >>> Hi Loa, >>> >>> Thanks for your review and comments! >>> >>>> There are a few issues that needs to be resolved. >>>> >>>> 1. We need to understand how generic it is possible to capture >>>> the OAM functions in the OAM Functions Flag Field in the OAM >>>> Configuration TLV. >>>> One idea with the flag field is that if you use default values >>>> for >>>> a OAM flagged in the flag field you don't need further >> sub-TLVs. >>>> However there seems to be different needs depending on the >>>> forwarding >>>> planes, e.g. it seems that the Ethernet draft makes the >>>> assumption >>>> that cc and cv is always run together at the same >> time, while in >>>> mpls-tp context we see that cc without cv is possible, >> and cc is >>>> implicit in proactive cv. >>>> Now with the current "Connectivity Monitoring flag" it is >>>> perfectly >>>> possible to take correct actions based on the default >> values for >>>> Ethernet, but for mpls(-tp) you be required to add some extra >>>> information. We can do this with using a mpls(-tp) specific >>>> sub-TLV, >>>> there is no real problem in that, but we loses some of >> the power >>>> of >>>> very simple trigger we have in the flag field. Or we >> could add a >>>> CC >>>> flag to the flag field, and let the "Connectivity >> Monitoring flag" >>>> represent th case where we use CC and CV in combination. >>>> Again that is not a problem, but I concerned that if this is >>>> recurring we would very quickly run out of in flags in >> the rather >>>> small OAM Functions Flag Field. Extending the field >> would be one >>>> way >>>> to resolve this. >>> >>> This is a point we discussed off-line in Hiroshima between >> Elisa, you >>> and myself. The reason to progress the framewrok togeather >> with a set >>> of technology specific documents is exactly to see what and >> how would >>> fit into the framework and what needs to be technology specific. >>> >>> Up until now, having 3 flags seemed to be enough, there may >> indeed be >>> a need to separate CC and CV as we see MPLS-TP OAM unfold. Also we >>> need to see how other TP OAM functions will fit into the >> configuration >>> fwk and/or if they are specific to the MPLS-TP OAM >> configuration document. >>> >>> In any case, one way to extend the flags field would be to have a >>> dedicated flag at the end that would extend the field with an >>> additional >>> 32 flags. In paralell it would also be possible to define >> the flags to >>> be scoped under technology specific documents. These two were Loa's >>> proposal in Hiroshima. >>> >>> An alternative would be to remove the flags and let the OAM >> function >>> specific sub-TLVs self represent the need of and trigger the >>> establishment of the corresponding OAM function. This >> would, probably >>> simplify the structure but would require more data to configure >>> default OAM functions. >>> >>> I think both alternatives are viable. >>> >>>> >>>> 2. Specifying and describing TLVs. In order to make RFCs >> easy to read >>>> and understand the TLV specifications need to be >> precise and to >>>> the >>>> point, I think there is a lot to be learned from e.g RFC5036, >>>> there >>>> Bob create an art of clearly specifying e.g. TLVs. >> There is e.g a >>>> clear and exactly matching list of explanations for >> each field in >>>> in the TLV >>>> >>>> In the four OAM Configuration drafts this is less >> clear. I'm not >>>> picking on any draft or author here, yes requesting >> that we sue a >>>> model that is as clear as in RFC5036. >>>> >>> >>> Since the darfts are still work in progress and are a result of >>> continous evolution there is for sure room to improve the text. >>> >>>> Again looking at the OAM Configuration TLV (but I'm >> not picking >>>> on >>>> that one in particular, this is recurring) >>>> - the Type field contains the value we want IANA to >> assign, this >>>> very >>>> quickly becomes hard to track since IANA will assign >> may Type >>>> (2) >>>> e.g. one each as sub-TLV for different TLVs. The type field >>>> should >>>> contain the name of the TLV. >>>> - what follows the TLV picture is a mix of defining what goes >>>> into >>>> the and what behavior that is expected in some cases. >>>> The list after should only indicates what goes into the TLV >>>> field >>>> - E.g. under OAM type it says that an "error" should >> be generated >>>> if >>>> the OAM type is not supported, I think this os an example of >>>> what >>>> indicated where we find the error codes. >>>> - names in the TLV picture and the list defining what >> goes into >>>> the >>>> field should be the same. >>>> >>> >>> I could not decode the issue here, could you please clarify? >>> >>> Thanks, >>> Attila >>> >>>> I realize that having said this it will be necessary to >> start sending >>>> text to the authors of the different drafts, will do so as >> soon as I >>>> can. >>>> >>>> >>>> In order finally come up with a good control of OAM in >> gmpls we need >>>> to fix all four drafts. This does not in anyway require >> that we stop >>>> working on the technology specif draft, but fixes and >> clarifications >>>> in the framework needs to be reflected in the technology specific >>>> drafts. >>>> From an MPLS-TP project view it is also necessary to progress the >>>> mpls-tp specific drafts early, at least in parallel with the other >>>> drafts. >>>> >>>> /Loa >>>> -- >>>> >>>> >>>> Loa Andersson email: >>>> loa.andersson@ericsson.com >>>> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc >>>> phone: +46 10 717 52 13 >>>> +46 767 72 92 >>>> 13 _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >> > > > From lberger@labn.net Tue Dec 1 04:07:11 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B2428C0EE for ; Tue, 1 Dec 2009 04:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 SUhveeuHpFMx for ; Tue, 1 Dec 2009 04:07:10 -0800 (PST) Received: from outbound-mail-117.bluehost.com (outbound-mail-117.bluehost.com [69.89.22.17]) by core3.amsl.com (Postfix) with SMTP id 64B513A684E for ; Tue, 1 Dec 2009 04:07:10 -0800 (PST) Received: (qmail 30955 invoked by uid 0); 1 Dec 2009 12:07:03 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy3.bluehost.com with SMTP; 1 Dec 2009 12:07:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=dpu6faVHzercJUArWSw1wO35WyhUj5reFWnfnJ9FgPutYBCIS+NSNwtCzVyBoxCf/ysJZWEhOMU5YI4oRjhxlj1XkGfRq9+pt9WpF8AaF+ijw31r5ux/Mqx0Ix4cguR9; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NFRVX-0002EY-5T; Tue, 01 Dec 2009 05:07:03 -0700 Message-ID: <4B1506E7.3070805@labn.net> Date: Tue, 01 Dec 2009 07:07:03 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: ccamp@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Suspended: poll on making draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 12:07:11 -0000 The document authors have asked that we defer this poll until they make some further updates to this document. The plan will be to re-poll the WG once the document authors inform us that the changes have been made. Given recent discussion on the list, I expect that this poll will take place together with the other technology specific OAM document, draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext. Please keep in mind that becoming a WG document does not mean that the technical details of a document are frozen. It does mean that the working group becomes the authoritative body for technical content, i.e., WG consensus drives a WG document while author consensus drives an individual document. Lou On 11/23/2009 5:20 PM, BRUNGARD, DEBORAH A (ATTLABS) wrote: > All, > > This is to start a two week poll on making > draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt a ccamp working group > document. Send a mail to the mailing list indicating "yes/support" or > "no/do not support". > > The poll ends Monday, Dec. 7, 2009. > > Deborah > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From loa@pi.nu Wed Dec 2 05:15:10 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E55F28C1C9; Wed, 2 Dec 2009 05:15:10 -0800 (PST) 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 ffTLLKx35MPT; Wed, 2 Dec 2009 05:15:09 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id B3E7928C0FC; Wed, 2 Dec 2009 05:15:09 -0800 (PST) Received: from [192.36.158.71] (wdhcp-158-71.verkstad.net [192.36.158.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 20B0CD404B; Wed, 2 Dec 2009 14:14:59 +0100 (CET) Message-ID: <4B166852.2060502@pi.nu> Date: Wed, 02 Dec 2009 14:14:58 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] wg lasxt call on draft-ietf-mpls-tp-nm-framework-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 13:15:10 -0000 All, this is to start a 2 week wg last call on draft-ietf-mpls-tp-nm-framework-02. The wg last call ends on Dec 17. Please send yor comments to the mpls-tp@ietf.org mailing list. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Wed Dec 2 06:58:47 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15923A689F; Wed, 2 Dec 2009 06:58:47 -0800 (PST) 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=[AWL=0.000, 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 HFKbs+2Sb6jY; Wed, 2 Dec 2009 06:58:46 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 9629D3A6873; Wed, 2 Dec 2009 06:58:46 -0800 (PST) Received: from [192.36.158.71] (wdhcp-158-71.verkstad.net [192.36.158.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id B672BD4056; Wed, 2 Dec 2009 15:58:36 +0100 (CET) Message-ID: <4B16809A.3040409@pi.nu> Date: Wed, 02 Dec 2009 15:58:34 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Attila Takacs References: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> In-Reply-To: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 14:58:47 -0000 Attila, thanks - I think things are converging quite a bit now. May the OAM Configuration TLV specified in the OAM Configuration Framweork only be present in the PATH message? /Loa Attila Takacs wrote: > Hi all, > > Some thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM > configuration drafts. > > I think we need to extend the OAM Function flags (described in > draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: > > -CC > -CV > -PM Loss > -PM Delay > -Fault Management signals > > > With regards to BFD I see three operation vs. configuration modes: > > 1) Set CC in the flags and only bootstrap the BFD session, by sending > the local discriminator values in RSVP-TE and leave timer negotiation to > BFD control messages. This is similar to LSP Ping based bootstrapping > described in draft-ietf-bfd-mpls-07.txt. > > 2) Set CC in the flags but configure the timers via the control plane, > this should correspond to "CC mode" in draft-asm-mpls-tp-bfd-cc-cv-01. > We may include the min/max intervals and by doing so support initial > timer negotiation in control plane. However, we may need a flag in CC > configuration sub-TLV (now in > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called "Suggested TX > Interval sub-TLV") to indicate whether data plane timer renegotiation is > enabled or disabled (i.e., subsequently via BFD control messages). This, > as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be disabled for > TP LSPs by default. > > 3) In case of "full" MPLS-TP OAM support any of the flags could be set > as needed, reflecting "CV/CC mode" described in > draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as described > in draft-frost-mpls-tp-loss-delay-00 and management signals as given in > draft-sfv-mpls-tp-fault-00. > > > > To configure CC we will need to add > -enable/disable DP timer re-negotiation > -PHB to identify priority and drop precedence of CC packets > > When it comes to CV, it would be interesting to discuss whether only the > OAM identifiers described in draft-ietf-mpls-tp-identifiers-00 are ought > to be supported. If so, those could be derived from RSVP-TE signaling > without the need to carry them explicitly in MPLS-TP OAM Configuration > sub-TLVs (now called Source unique MEP_ID sub-TLV in > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). > > For Performance Monitoring Loss/Delay we need to add new TLVs, carrying > -measurement interval > -possibly loss/delay bound thresholds (given we what these for MPLS-TP) > that could be used to assess the quality of the connection and may > eventually trigger protection > -PHB of control packets if we want to set it differently from CC packets > or from data traffic. > > For the Fault Management Signals, I would add a new "Fault Management > Signals sub-TLV" carrying: > -Enabled signals flags: AIS, LDI, LKR, CFS (which, except CFS, are > specified in draft-sfv-mpls-tp-fault-00) > -refresh timer of fault indication messages > -flag to enable/disable explicitly clear of faults > -PHB of fault management packets > > > Another thing we may want to consider is adding a sub-TLV to set > consequent actions that are configurable. This is described to some > extent in the MPLS-TP OAM Framework. The defects identified include: > Loss Of Continuity defect, Mis-connectivity defect, MEP misconfiguration > defect, Period Misconfiguration defect. > > An operator may want to configure if the consequence of LOC should be > the blocking or non-blocking of outgoing data traffic. Similarly it may > be useful to configure whether the "Period Misconfiguration defect" > should result in a signal fail condition or not. > > > I plan to send detailed text to the editors of > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the lines > described above. Please comment! > Thanks, > Attila > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From EROCH@nortel.com Wed Dec 2 14:02:30 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53A13A697E for ; Wed, 2 Dec 2009 14:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 rRwch-HeaCHq for ; Wed, 2 Dec 2009 14:02:30 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CF8AC3A6952 for ; Wed, 2 Dec 2009 14:02:26 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nB2M2AG06636; Wed, 2 Dec 2009 22:02:11 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 Date: Wed, 2 Dec 2009 17:01:47 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A029ADCB1@zcarhxm2.corp.nortel.com> In-Reply-To: <4B06FB22.8090301@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: AcpqH2jN5UF5WUetQO+ZWwqeMGsF0QJeFghw References: <4B06FB22.8090301@labn.net> From: "Evelyne Roch" To: "Lou Berger" , "CCAMP" , Subject: Re: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 22:02:30 -0000 Lou, I think this document fails to address some important requirements for VCAT signaling. As we described in draft-roch-ccamp-gmpls-inv-mux-00, there are requirements for VCAT signaling to be performed independently from the member signaling in certain conditions when business relationships do not permit the provider of the members to carry VCAT signaling on its behalf, due to policies or existence of statically configured connections. I would prefer to see a signaling approach that allows for independent VCAT signaling and does not require the members to carry information related to the VCAT services.=20 Regards, Evelyne Roch e-mail: eroch@nortel.com -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Friday, November 20, 2009 3:25 PM To: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org Subject: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 As discussed in last week's session, it's time for the working group to last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas Please send your comments to the list or the authors&chairs before the last call closes in two weeks, on December 4, 2009. Thank you, Lou (and Deborah) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Jonathan.Sadler@tellabs.com Wed Dec 2 14:47:37 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46A728C10B for ; Wed, 2 Dec 2009 14:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=1.211, 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 HCtFDEiicyh7 for ; Wed, 2 Dec 2009 14:47:37 -0800 (PST) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id EF59528C10A for ; Wed, 2 Dec 2009 14:47:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.47,331,1257120000"; d="scan'208";a="1303926957" Received: from usnvwwmspht02.hq.tellabs.com (HELO usnvwwmspht02.tellabs-west.tellabsinc.net) ([172.23.211.70]) by mx4-priv.tellabs.com with ESMTP; 02 Dec 2009 22:47:24 +0000 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht02.tellabs-west.tellabsinc.net ([172.23.211.70]) with mapi; Wed, 2 Dec 2009 16:47:24 -0600 From: "Sadler, Jonathan B." To: Lou Berger , CCAMP , "draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org" Date: Wed, 2 Dec 2009 16:47:06 -0600 Thread-Topic: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: AcpqH2ryjNr5gUbmTN+LuGhTuQZF0wJflMJw Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net> References: <4B06FB22.8090301@labn.net> In-Reply-To: <4B06FB22.8090301@labn.net> 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 Subject: Re: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 22:47:37 -0000 Hi all, As mentioned in the CCAMP working group meeting, this draft has a dependenc= y on a control plane operating in the STS-n/VC-n environment, and that cont= rol plane carrying the CALL information used for configuring the VCAT group= . Given carrier requirements to not extend a carrier's control plane to the c= ustomer premise (e.g. draft-jenkins-mpls-tp-bt-requirements-00, and the car= rier requirements document liaised by the OIF), this dependency is not acce= ptable. Instead, a mechanism needs to exist where the STS-n connections ca= n be named and signaled for incorporation into a VCAT group independent of = the out-of-band network or process used to setup the STS-n/VC-n connections= . Hence, further work on this draft is needed before it can progress. Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Friday, November 20, 2009 2:25 PM To: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org Subject: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-= 08 As discussed in last week's session, it's time for the working group to=20 last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas Please send your comments to the list or the authors&chairs before the last call closes in two weeks, on December 4, 2009. Thank you, Lou (and Deborah) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From gregb@grotto-networking.com Wed Dec 2 16:49:11 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9431E3A69B8 for ; Wed, 2 Dec 2009 16:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 lo13uU+07tlS for ; Wed, 2 Dec 2009 16:49:10 -0800 (PST) Received: from mail14c40.carrierzone.com (mail14c40.carrierzone.com [209.235.156.154]) by core3.amsl.com (Postfix) with ESMTP id 6DB1F3A68DE for ; Wed, 2 Dec 2009 16:49:10 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail14c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB30n6L8018603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 00:49:10 GMT Message-ID: <4B170AF8.1080900@grotto-networking.com> Date: Wed, 02 Dec 2009 16:48:56 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Sadler, Jonathan B." References: <4B06FB22.8090301@labn.net> <5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP , "draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org" Subject: Re: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 00:49:11 -0000 Hi folks, this draft has been very stable for a very long time. The last major revision was to put in some advanced features requested by Jonathan and Evelyn. Adrian and I worked out a solution to providing those features over two years ago. I don't work on MPLS-TP and didn't know that this was a topic covered by that. Is it? I haven't seen any specific textual changes requested just vague assertions that this draft cannot do everything and anything somebody could think of. VCAT/LCAS is a fairly general technique applying to PDH, SDH, and G.709 technologies. This draft was intended to cover those and was approved as a working group document over four years ago. Unless there is something specifically technically wrong I'm not sure that we need to start all over again with this. Regards GB Sadler, Jonathan B. wrote: > Hi all, > > As mentioned in the CCAMP working group meeting, this draft has a dependency on a control plane operating in the STS-n/VC-n environment, and that control plane carrying the CALL information used for configuring the VCAT group. > > Given carrier requirements to not extend a carrier's control plane to the customer premise (e.g. draft-jenkins-mpls-tp-bt-requirements-00, and the carrier requirements document liaised by the OIF), this dependency is not acceptable. Instead, a mechanism needs to exist where the STS-n connections can be named and signaled for incorporation into a VCAT group independent of the out-of-band network or process used to setup the STS-n/VC-n connections. > > Hence, further work on this draft is needed before it can progress. > > Jonathan Sadler > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Friday, November 20, 2009 2:25 PM > To: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org > Subject: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 > > As discussed in last week's session, it's time for the working group to > last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas > > Please send your comments to the list or the authors&chairs > before the last call closes in two weeks, on December 4, 2009. > > Thank you, > Lou (and Deborah) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From julien.meuric@orange-ftgroup.com Thu Dec 3 03:37:14 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38CA528C149 for ; Thu, 3 Dec 2009 03:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 bvqSo-OxsvDQ for ; Thu, 3 Dec 2009 03:37:13 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id D942C28C147 for ; Thu, 3 Dec 2009 03:37:12 -0800 (PST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 12:37:01 +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 Date: Thu, 3 Dec 2009 12:36:58 +0100 Message-ID: In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: AcpqH2ryjNr5gUbmTN+LuGhTuQZF0wJflMJwABipFkA= References: <4B06FB22.8090301@labn.net> <5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net> From: To: , , , X-OriginalArrivalTime: 03 Dec 2009 11:37:01.0694 (UTC) FILETIME=[EE1F51E0:01CA740C] Subject: Re: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 11:37:14 -0000 Hi all. Jonathan, both documents you refer to are out of scope here: - draft-jenkins-mpls-tp-bt-requirements is entitled "BT Requirements..." and explicitely express an individual's view; - OIF's carrier requirements are interesting information for IETF but do not reflect any IETF consensus either. Furthermore, I do not see why the solution defined in draft-ietf-ccamp-gmpls-vcat-lcas would preclude you from covering your specific case. I assume your client nodes have 2 things to handle: - the VCAT group, which can be configured by a Notify message, - the STS-m/VC-n termination points, configured by a Path message. If you consider a kind of overlay operation (not to be confused with an "overlay architecture" glued to network layers), you can limit the latter signaling to the end nodes, i.e. your client network. Then, if the server layer have its STS-m/VC-n configured by RSVP-TE, you can get 2 things: - the level of (in)dependancy you need so as to connect to the client termination points by using the identifiers you like, - the solution defined in the current draft as it is. A bit tricky you might say, but I prefer to see tricky solutions for corner cases than making the mainstream solution tricky. Regards, Julien -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Sadler, Jonathan B. Hi all, As mentioned in the CCAMP working group meeting, this draft has a dependency on a control plane operating in the STS-n/VC-n environment, and that control plane carrying the CALL information used for configuring the VCAT group. Given carrier requirements to not extend a carrier's control plane to the customer premise (e.g. draft-jenkins-mpls-tp-bt-requirements-00, and the carrier requirements document liaised by the OIF), this dependency is not acceptable. Instead, a mechanism needs to exist where the STS-n connections can be named and signaled for incorporation into a VCAT group independent of the out-of-band network or process used to setup the STS-n/VC-n connections. Hence, further work on this draft is needed before it can progress. Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Friday, November 20, 2009 2:25 PM To: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org Subject: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 As discussed in last week's session, it's time for the working group to=20 last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas Please send your comments to the list or the authors&chairs before the last call closes in two weeks, on December 4, 2009. Thank you, Lou (and Deborah) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Attila.Takacs@ericsson.com Thu Dec 3 05:14:12 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251B03A6A56; Thu, 3 Dec 2009 05:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 KE5Y10+nVWbT; Thu, 3 Dec 2009 05:14:11 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 73FF63A6853; Thu, 3 Dec 2009 05:14:10 -0800 (PST) X-AuditID: c1b4fb3e-b7bb0ae000002e70-59-4b17b998a47e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id E7.DA.11888.899B71B4; Thu, 3 Dec 2009 14:14:01 +0100 (CET) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.119]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 3 Dec 2009 14:14:00 +0100 From: Attila Takacs To: Loa Andersson Date: Thu, 3 Dec 2009 14:13:58 +0100 Thread-Topic: [CCAMP] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts Thread-Index: AcpzX+/cLsvnrLrwTGqXM6wBQ4oITAAuiNMA Message-ID: <79F41BA1E9BF3C489375521EF8DDE23C016A4AC8@ESESSCMS0355.eemea.ericsson.se> References: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> <4B16809A.3040409@pi.nu> In-Reply-To: <4B16809A.3040409@pi.nu> 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 X-Brightmail-Tracker: AAAAAA== Cc: "ccamp@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 13:14:12 -0000 Hi Loa, It can be carried in the LSP_ATTRIBUTES Object in the Resv message; so it c= an be used for timer negotiation and discriminator synchronization if neede= d. Attila > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu]=20 > Sent: Wednesday, December 02, 2009 3:59 PM > To: Attila Takacs > Cc: ccamp@ietf.org; mpls-tp@ietf.org > Subject: Re: [CCAMP] Thoughts on updating the OAM=20 > Configuration fwk and the MPLS-TP OAM configuration drafts >=20 > Attila, >=20 > thanks - I think things are converging quite a bit now. >=20 > May the OAM Configuration TLV specified in the OAM=20 > Configuration Framweork only be present in the PATH message? >=20 > /Loa >=20 > Attila Takacs wrote: > > Hi all, > >=20 > > Some thoughts on updating the OAM Configuration fwk and the MPLS-TP=20 > > OAM configuration drafts. > >=20 > > I think we need to extend the OAM Function flags (described in > > draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: > >=20 > > -CC > > -CV > > -PM Loss > > -PM Delay > > -Fault Management signals > >=20 > >=20 > > With regards to BFD I see three operation vs. configuration modes: > >=20 > > 1) Set CC in the flags and only bootstrap the BFD session,=20 > by sending=20 > > the local discriminator values in RSVP-TE and leave timer=20 > negotiation=20 > > to BFD control messages. This is similar to LSP Ping based=20 > > bootstrapping described in draft-ietf-bfd-mpls-07.txt. > >=20 > > 2) Set CC in the flags but configure the timers via the=20 > control plane,=20 > > this should correspond to "CC mode" in=20 > draft-asm-mpls-tp-bfd-cc-cv-01. > > We may include the min/max intervals and by doing so=20 > support initial=20 > > timer negotiation in control plane. However, we may need a=20 > flag in CC=20 > > configuration sub-TLV (now in > > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called=20 > "Suggested TX=20 > > Interval sub-TLV") to indicate whether data plane timer=20 > renegotiation=20 > > is enabled or disabled (i.e., subsequently via BFD control=20 > messages).=20 > > This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be=20 > > disabled for TP LSPs by default. > >=20 > > 3) In case of "full" MPLS-TP OAM support any of the flags=20 > could be set=20 > > as needed, reflecting "CV/CC mode" described in=20 > > draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as=20 > > described in draft-frost-mpls-tp-loss-delay-00 and=20 > management signals=20 > > as given in draft-sfv-mpls-tp-fault-00. > >=20 > >=20 > >=20 > > To configure CC we will need to add > > -enable/disable DP timer re-negotiation -PHB to identify=20 > priority and=20 > > drop precedence of CC packets > >=20 > > When it comes to CV, it would be interesting to discuss=20 > whether only=20 > > the OAM identifiers described in=20 > draft-ietf-mpls-tp-identifiers-00 are=20 > > ought to be supported. If so, those could be derived from RSVP-TE=20 > > signaling without the need to carry them explicitly in MPLS-TP OAM=20 > > Configuration sub-TLVs (now called Source unique MEP_ID sub-TLV in=20 > > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). > >=20 > > For Performance Monitoring Loss/Delay we need to add new TLVs,=20 > > carrying -measurement interval -possibly loss/delay bound=20 > thresholds=20 > > (given we what these for MPLS-TP) that could be used to assess the=20 > > quality of the connection and may eventually trigger=20 > protection -PHB=20 > > of control packets if we want to set it differently from CC=20 > packets or=20 > > from data traffic. > >=20 > > For the Fault Management Signals, I would add a new "Fault=20 > Management=20 > > Signals sub-TLV" carrying: > > -Enabled signals flags: AIS, LDI, LKR, CFS (which, except CFS, are=20 > > specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault=20 > > indication messages -flag to enable/disable explicitly=20 > clear of faults=20 > > -PHB of fault management packets > >=20 > >=20 > > Another thing we may want to consider is adding a sub-TLV to set=20 > > consequent actions that are configurable. This is described to some=20 > > extent in the MPLS-TP OAM Framework. The defects identified include: > > Loss Of Continuity defect, Mis-connectivity defect, MEP=20 > > misconfiguration defect, Period Misconfiguration defect. > >=20 > > An operator may want to configure if the consequence of LOC=20 > should be=20 > > the blocking or non-blocking of outgoing data traffic. Similarly it=20 > > may be useful to configure whether the "Period=20 > Misconfiguration defect" > > should result in a signal fail condition or not. > >=20 > >=20 > > I plan to send detailed text to the editors of > > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the lines=20 > > described above. Please comment! > > Thanks, > > Attila > >=20 > >=20 > >=20 > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp >=20 > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > = From loa@pi.nu Thu Dec 3 06:04:57 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609FF3A6891; Thu, 3 Dec 2009 06:04:57 -0800 (PST) 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=[AWL=0.000, 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 wHXuS9DUT5Hu; Thu, 3 Dec 2009 06:04:56 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id C1BCF3A6862; Thu, 3 Dec 2009 06:04:55 -0800 (PST) Received: from [192.36.158.113] (wdhcp-158-113.verkstad.net [192.36.158.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 57111D4053; Thu, 3 Dec 2009 15:04:45 +0100 (CET) Message-ID: <4B17C57B.40200@pi.nu> Date: Thu, 03 Dec 2009 15:04:43 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Attila Takacs References: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> <4B16809A.3040409@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AC8@ESESSCMS0355.eemea.ericsson.se> In-Reply-To: <79F41BA1E9BF3C489375521EF8DDE23C016A4AC8@ESESSCMS0355.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ccamp@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 14:04:57 -0000 Attila, OK great, then we need to update that in the framework. I also have a question on the relationship between flags and the sub-tlvs. I think there are four possibilities: 1. A flag is set, but there is no sub-tlv - the action here should be to turn on the function the flag indicates using default values I also think that if a function indicated by flag is running, it should be left unchanged, even if it is not running on default values 2. A flag is set, and there is a sub-tlv - the action here would be to turn on the function indicated by the flag, using the parameters found in sub-tlv 3. A flag is not set, and there is no sub-tlv - the action here would be to turn off any function that has been configured earlier 4. A flag is not set, but there is sub-tlv - this should be treated as an error conditions and an error message should be returned, no changes to the configured OAM should be made. Is this correctly understood? /Loa Attila Takacs wrote: > Hi Loa, > > It can be carried in the LSP_ATTRIBUTES Object in the Resv message; so it can be used for timer negotiation and discriminator synchronization if needed. > > Attila > >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Wednesday, December 02, 2009 3:59 PM >> To: Attila Takacs >> Cc: ccamp@ietf.org; mpls-tp@ietf.org >> Subject: Re: [CCAMP] Thoughts on updating the OAM >> Configuration fwk and the MPLS-TP OAM configuration drafts >> >> Attila, >> >> thanks - I think things are converging quite a bit now. >> >> May the OAM Configuration TLV specified in the OAM >> Configuration Framweork only be present in the PATH message? >> >> /Loa >> >> Attila Takacs wrote: >>> Hi all, >>> >>> Some thoughts on updating the OAM Configuration fwk and the MPLS-TP >>> OAM configuration drafts. >>> >>> I think we need to extend the OAM Function flags (described in >>> draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: >>> >>> -CC >>> -CV >>> -PM Loss >>> -PM Delay >>> -Fault Management signals >>> >>> >>> With regards to BFD I see three operation vs. configuration modes: >>> >>> 1) Set CC in the flags and only bootstrap the BFD session, >> by sending >>> the local discriminator values in RSVP-TE and leave timer >> negotiation >>> to BFD control messages. This is similar to LSP Ping based >>> bootstrapping described in draft-ietf-bfd-mpls-07.txt. >>> >>> 2) Set CC in the flags but configure the timers via the >> control plane, >>> this should correspond to "CC mode" in >> draft-asm-mpls-tp-bfd-cc-cv-01. >>> We may include the min/max intervals and by doing so >> support initial >>> timer negotiation in control plane. However, we may need a >> flag in CC >>> configuration sub-TLV (now in >>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called >> "Suggested TX >>> Interval sub-TLV") to indicate whether data plane timer >> renegotiation >>> is enabled or disabled (i.e., subsequently via BFD control >> messages). >>> This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be >>> disabled for TP LSPs by default. >>> >>> 3) In case of "full" MPLS-TP OAM support any of the flags >> could be set >>> as needed, reflecting "CV/CC mode" described in >>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as >>> described in draft-frost-mpls-tp-loss-delay-00 and >> management signals >>> as given in draft-sfv-mpls-tp-fault-00. >>> >>> >>> >>> To configure CC we will need to add >>> -enable/disable DP timer re-negotiation -PHB to identify >> priority and >>> drop precedence of CC packets >>> >>> When it comes to CV, it would be interesting to discuss >> whether only >>> the OAM identifiers described in >> draft-ietf-mpls-tp-identifiers-00 are >>> ought to be supported. If so, those could be derived from RSVP-TE >>> signaling without the need to carry them explicitly in MPLS-TP OAM >>> Configuration sub-TLVs (now called Source unique MEP_ID sub-TLV in >>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). >>> >>> For Performance Monitoring Loss/Delay we need to add new TLVs, >>> carrying -measurement interval -possibly loss/delay bound >> thresholds >>> (given we what these for MPLS-TP) that could be used to assess the >>> quality of the connection and may eventually trigger >> protection -PHB >>> of control packets if we want to set it differently from CC >> packets or >>> from data traffic. >>> >>> For the Fault Management Signals, I would add a new "Fault >> Management >>> Signals sub-TLV" carrying: >>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except CFS, are >>> specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault >>> indication messages -flag to enable/disable explicitly >> clear of faults >>> -PHB of fault management packets >>> >>> >>> Another thing we may want to consider is adding a sub-TLV to set >>> consequent actions that are configurable. This is described to some >>> extent in the MPLS-TP OAM Framework. The defects identified include: >>> Loss Of Continuity defect, Mis-connectivity defect, MEP >>> misconfiguration defect, Period Misconfiguration defect. >>> >>> An operator may want to configure if the consequence of LOC >> should be >>> the blocking or non-blocking of outgoing data traffic. Similarly it >>> may be useful to configure whether the "Period >> Misconfiguration defect" >>> should result in a signal fail condition or not. >>> >>> >>> I plan to send detailed text to the editors of >>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the lines >>> described above. Please comment! >>> Thanks, >>> Attila >>> >>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> -- >> >> >> Loa Andersson email: >> loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From Attila.Takacs@ericsson.com Thu Dec 3 06:17:38 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB63028C131; Thu, 3 Dec 2009 06:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 ivqQAG3N4RAG; Thu, 3 Dec 2009 06:17:37 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id D885928C0EA; Thu, 3 Dec 2009 06:17:36 -0800 (PST) X-AuditID: c1b4fb24-b7beeae000003a71-44-4b17c877154e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id A0.2D.14961.778C71B4; Thu, 3 Dec 2009 15:17:27 +0100 (CET) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.119]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 3 Dec 2009 15:17:27 +0100 From: Attila Takacs To: Loa Andersson Date: Thu, 3 Dec 2009 15:17:25 +0100 Thread-Topic: [CCAMP] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts Thread-Index: Acp0IbM9R+fv7wMpRH2IMTOqCe1F9QAAWgfQ Message-ID: <79F41BA1E9BF3C489375521EF8DDE23C016A4AFD@ESESSCMS0355.eemea.ericsson.se> References: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> <4B16809A.3040409@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AC8@ESESSCMS0355.eemea.ericsson.se> <4B17C57B.40200@pi.nu> In-Reply-To: <4B17C57B.40200@pi.nu> 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 X-Brightmail-Tracker: AAAAAA== Cc: "ccamp@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 14:17:38 -0000 Hi Loa,=20 >=20 > OK great, then we need to update that in the framework. >=20 Ok, I will do so. > I also have a question on the relationship between flags and=20 > the sub-tlvs. >=20 > I think there are four possibilities: >=20 > 1. A flag is set, but there is no sub-tlv > - the action here should be to turn on the function the > flag indicates using default values > I also think that if a function indicated by flag is > running, it should be left unchanged, even if it is not > running on default values >=20 > 2. A flag is set, and there is a sub-tlv > - the action here would be to turn on the function indicated by > the flag, using the parameters found in sub-tlv >=20 > 3. A flag is not set, and there is no sub-tlv > - the action here would be to turn off any function that has > been configured earlier >=20 > 4. A flag is not set, but there is sub-tlv > - this should be treated as an error conditions and an > error message should be returned, no changes to the configured > OAM should be made. >=20 > Is this correctly understood? Yes. I will check is this need clarification in the fwk. Attila >=20 > /Loa >=20 > Attila Takacs wrote: > > Hi Loa, > >=20 > > It can be carried in the LSP_ATTRIBUTES Object in the Resv=20 > message; so it can be used for timer negotiation and=20 > discriminator synchronization if needed. > >=20 > > Attila > >=20 > >> -----Original Message----- > >> From: Loa Andersson [mailto:loa@pi.nu] > >> Sent: Wednesday, December 02, 2009 3:59 PM > >> To: Attila Takacs > >> Cc: ccamp@ietf.org; mpls-tp@ietf.org > >> Subject: Re: [CCAMP] Thoughts on updating the OAM=20 > Configuration fwk=20 > >> and the MPLS-TP OAM configuration drafts > >> > >> Attila, > >> > >> thanks - I think things are converging quite a bit now. > >> > >> May the OAM Configuration TLV specified in the OAM Configuration=20 > >> Framweork only be present in the PATH message? > >> > >> /Loa > >> > >> Attila Takacs wrote: > >>> Hi all, > >>> > >>> Some thoughts on updating the OAM Configuration fwk and=20 > the MPLS-TP=20 > >>> OAM configuration drafts. > >>> > >>> I think we need to extend the OAM Function flags (described in > >>> draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: > >>> > >>> -CC > >>> -CV > >>> -PM Loss > >>> -PM Delay > >>> -Fault Management signals > >>> > >>> > >>> With regards to BFD I see three operation vs. configuration modes: > >>> > >>> 1) Set CC in the flags and only bootstrap the BFD session, > >> by sending > >>> the local discriminator values in RSVP-TE and leave timer > >> negotiation > >>> to BFD control messages. This is similar to LSP Ping based=20 > >>> bootstrapping described in draft-ietf-bfd-mpls-07.txt. > >>> > >>> 2) Set CC in the flags but configure the timers via the > >> control plane, > >>> this should correspond to "CC mode" in > >> draft-asm-mpls-tp-bfd-cc-cv-01. > >>> We may include the min/max intervals and by doing so > >> support initial > >>> timer negotiation in control plane. However, we may need a > >> flag in CC > >>> configuration sub-TLV (now in > >>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called > >> "Suggested TX > >>> Interval sub-TLV") to indicate whether data plane timer > >> renegotiation > >>> is enabled or disabled (i.e., subsequently via BFD control > >> messages).=20 > >>> This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be=20 > >>> disabled for TP LSPs by default. > >>> > >>> 3) In case of "full" MPLS-TP OAM support any of the flags > >> could be set > >>> as needed, reflecting "CV/CC mode" described in=20 > >>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as=20 > >>> described in draft-frost-mpls-tp-loss-delay-00 and > >> management signals > >>> as given in draft-sfv-mpls-tp-fault-00. > >>> > >>> > >>> > >>> To configure CC we will need to add > >>> -enable/disable DP timer re-negotiation -PHB to identify > >> priority and > >>> drop precedence of CC packets > >>> > >>> When it comes to CV, it would be interesting to discuss > >> whether only > >>> the OAM identifiers described in > >> draft-ietf-mpls-tp-identifiers-00 are > >>> ought to be supported. If so, those could be derived from RSVP-TE=20 > >>> signaling without the need to carry them explicitly in=20 > MPLS-TP OAM=20 > >>> Configuration sub-TLVs (now called Source unique MEP_ID=20 > sub-TLV in=20 > >>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). > >>> > >>> For Performance Monitoring Loss/Delay we need to add new TLVs,=20 > >>> carrying -measurement interval -possibly loss/delay bound > >> thresholds > >>> (given we what these for MPLS-TP) that could be used to=20 > assess the=20 > >>> quality of the connection and may eventually trigger > >> protection -PHB > >>> of control packets if we want to set it differently from CC > >> packets or > >>> from data traffic. > >>> > >>> For the Fault Management Signals, I would add a new "Fault > >> Management > >>> Signals sub-TLV" carrying: > >>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except=20 > CFS, are=20 > >>> specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault=20 > >>> indication messages -flag to enable/disable explicitly > >> clear of faults > >>> -PHB of fault management packets > >>> > >>> > >>> Another thing we may want to consider is adding a sub-TLV to set=20 > >>> consequent actions that are configurable. This is=20 > described to some=20 > >>> extent in the MPLS-TP OAM Framework. The defects=20 > identified include: > >>> Loss Of Continuity defect, Mis-connectivity defect, MEP=20 > >>> misconfiguration defect, Period Misconfiguration defect. > >>> > >>> An operator may want to configure if the consequence of LOC > >> should be > >>> the blocking or non-blocking of outgoing data traffic.=20 > Similarly it=20 > >>> may be useful to configure whether the "Period > >> Misconfiguration defect" > >>> should result in a signal fail condition or not. > >>> > >>> > >>> I plan to send detailed text to the editors of > >>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the lines=20 > >>> described above. Please comment! > >>> Thanks, > >>> Attila > >>> > >>> > >>> > >>> _______________________________________________ > >>> CCAMP mailing list > >>> CCAMP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ccamp > >> -- > >> > >> > >> Loa Andersson email:=20 > >> loa.andersson@ericsson.com > >> Sr Strategy and Standards Manager loa@pi.nu > >> Ericsson Inc phone: +46 10 717 52 13 > >> +46 767 72 92 13 >=20 > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92=20 > 13 _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > = From loa@pi.nu Thu Dec 3 09:20:58 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99CAF3A68E2; Thu, 3 Dec 2009 09:20:58 -0800 (PST) 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 L-XiIitKfHu3; Thu, 3 Dec 2009 09:20:57 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 994C53A672F; Thu, 3 Dec 2009 09:20:56 -0800 (PST) Received: from [192.36.158.113] (wdhcp-158-113.verkstad.net [192.36.158.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id CE737D4053; Thu, 3 Dec 2009 18:20:45 +0100 (CET) Message-ID: <4B17F36A.2090908@pi.nu> Date: Thu, 03 Dec 2009 18:20:42 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Attila Takacs References: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> <4B16809A.3040409@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AC8@ESESSCMS0355.eemea.ericsson.se> <4B17C57B.40200@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AFD@ESESSCMS0355.eemea.ericsson.se> In-Reply-To: <79F41BA1E9BF3C489375521EF8DDE23C016A4AFD@ESESSCMS0355.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ccamp@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 17:20:58 -0000 Attila, if we agree on this the we also have a method to easily reconfigure OAM on already set up LSPs, simple send a refresh PATH or RESV. What do people think is this a good idea? /Loa Attila Takacs wrote: > Hi Loa, > >> OK great, then we need to update that in the framework. >> > Ok, I will do so. > >> I also have a question on the relationship between flags and >> the sub-tlvs. >> >> I think there are four possibilities: >> >> 1. A flag is set, but there is no sub-tlv >> - the action here should be to turn on the function the >> flag indicates using default values >> I also think that if a function indicated by flag is >> running, it should be left unchanged, even if it is not >> running on default values >> >> 2. A flag is set, and there is a sub-tlv >> - the action here would be to turn on the function indicated by >> the flag, using the parameters found in sub-tlv >> >> 3. A flag is not set, and there is no sub-tlv >> - the action here would be to turn off any function that has >> been configured earlier >> >> 4. A flag is not set, but there is sub-tlv >> - this should be treated as an error conditions and an >> error message should be returned, no changes to the configured >> OAM should be made. >> >> Is this correctly understood? > Yes. I will check is this need clarification in the fwk. > > Attila > >> /Loa >> >> Attila Takacs wrote: >>> Hi Loa, >>> >>> It can be carried in the LSP_ATTRIBUTES Object in the Resv >> message; so it can be used for timer negotiation and >> discriminator synchronization if needed. >>> Attila >>> >>>> -----Original Message----- >>>> From: Loa Andersson [mailto:loa@pi.nu] >>>> Sent: Wednesday, December 02, 2009 3:59 PM >>>> To: Attila Takacs >>>> Cc: ccamp@ietf.org; mpls-tp@ietf.org >>>> Subject: Re: [CCAMP] Thoughts on updating the OAM >> Configuration fwk >>>> and the MPLS-TP OAM configuration drafts >>>> >>>> Attila, >>>> >>>> thanks - I think things are converging quite a bit now. >>>> >>>> May the OAM Configuration TLV specified in the OAM Configuration >>>> Framweork only be present in the PATH message? >>>> >>>> /Loa >>>> >>>> Attila Takacs wrote: >>>>> Hi all, >>>>> >>>>> Some thoughts on updating the OAM Configuration fwk and >> the MPLS-TP >>>>> OAM configuration drafts. >>>>> >>>>> I think we need to extend the OAM Function flags (described in >>>>> draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: >>>>> >>>>> -CC >>>>> -CV >>>>> -PM Loss >>>>> -PM Delay >>>>> -Fault Management signals >>>>> >>>>> >>>>> With regards to BFD I see three operation vs. configuration modes: >>>>> >>>>> 1) Set CC in the flags and only bootstrap the BFD session, >>>> by sending >>>>> the local discriminator values in RSVP-TE and leave timer >>>> negotiation >>>>> to BFD control messages. This is similar to LSP Ping based >>>>> bootstrapping described in draft-ietf-bfd-mpls-07.txt. >>>>> >>>>> 2) Set CC in the flags but configure the timers via the >>>> control plane, >>>>> this should correspond to "CC mode" in >>>> draft-asm-mpls-tp-bfd-cc-cv-01. >>>>> We may include the min/max intervals and by doing so >>>> support initial >>>>> timer negotiation in control plane. However, we may need a >>>> flag in CC >>>>> configuration sub-TLV (now in >>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called >>>> "Suggested TX >>>>> Interval sub-TLV") to indicate whether data plane timer >>>> renegotiation >>>>> is enabled or disabled (i.e., subsequently via BFD control >>>> messages). >>>>> This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be >>>>> disabled for TP LSPs by default. >>>>> >>>>> 3) In case of "full" MPLS-TP OAM support any of the flags >>>> could be set >>>>> as needed, reflecting "CV/CC mode" described in >>>>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as >>>>> described in draft-frost-mpls-tp-loss-delay-00 and >>>> management signals >>>>> as given in draft-sfv-mpls-tp-fault-00. >>>>> >>>>> >>>>> >>>>> To configure CC we will need to add >>>>> -enable/disable DP timer re-negotiation -PHB to identify >>>> priority and >>>>> drop precedence of CC packets >>>>> >>>>> When it comes to CV, it would be interesting to discuss >>>> whether only >>>>> the OAM identifiers described in >>>> draft-ietf-mpls-tp-identifiers-00 are >>>>> ought to be supported. If so, those could be derived from RSVP-TE >>>>> signaling without the need to carry them explicitly in >> MPLS-TP OAM >>>>> Configuration sub-TLVs (now called Source unique MEP_ID >> sub-TLV in >>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). >>>>> >>>>> For Performance Monitoring Loss/Delay we need to add new TLVs, >>>>> carrying -measurement interval -possibly loss/delay bound >>>> thresholds >>>>> (given we what these for MPLS-TP) that could be used to >> assess the >>>>> quality of the connection and may eventually trigger >>>> protection -PHB >>>>> of control packets if we want to set it differently from CC >>>> packets or >>>>> from data traffic. >>>>> >>>>> For the Fault Management Signals, I would add a new "Fault >>>> Management >>>>> Signals sub-TLV" carrying: >>>>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except >> CFS, are >>>>> specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault >>>>> indication messages -flag to enable/disable explicitly >>>> clear of faults >>>>> -PHB of fault management packets >>>>> >>>>> >>>>> Another thing we may want to consider is adding a sub-TLV to set >>>>> consequent actions that are configurable. This is >> described to some >>>>> extent in the MPLS-TP OAM Framework. The defects >> identified include: >>>>> Loss Of Continuity defect, Mis-connectivity defect, MEP >>>>> misconfiguration defect, Period Misconfiguration defect. >>>>> >>>>> An operator may want to configure if the consequence of LOC >>>> should be >>>>> the blocking or non-blocking of outgoing data traffic. >> Similarly it >>>>> may be useful to configure whether the "Period >>>> Misconfiguration defect" >>>>> should result in a signal fail condition or not. >>>>> >>>>> >>>>> I plan to send detailed text to the editors of >>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the lines >>>>> described above. Please comment! >>>>> Thanks, >>>>> Attila >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> -- >>>> >>>> >>>> Loa Andersson email: >>>> loa.andersson@ericsson.com >>>> Sr Strategy and Standards Manager loa@pi.nu >>>> Ericsson Inc phone: +46 10 717 52 13 >>>> +46 767 72 92 13 >> -- >> >> >> Loa Andersson email: >> loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 >> 13 _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From agmalis@gmail.com Thu Dec 3 09:29:32 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85BF13A68E2; Thu, 3 Dec 2009 09:29:32 -0800 (PST) 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 Ky9a8qoTaaac; Thu, 3 Dec 2009 09:29:31 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 13B4A3A672F; Thu, 3 Dec 2009 09:29:31 -0800 (PST) Received: by ywh15 with SMTP id 15so1551218ywh.5 for ; Thu, 03 Dec 2009 09:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=wWaljlp56pJ+OEsbaYWIXXN7m3LpwHEiXf7QhVbKAD4=; b=AafAQKEVFfrLCbsdO7CHdsBAwm+gE+v3VmKPjaU53LYE2yoJDCcNd+5elFh9T/yCvy slxabcYhP5RJg1CWXEg8cKx/vQWBH0Prma7UOrC3jzXJKkiUomsETomykrXiNbUdBO86 zWLdkPIfxsEHX0UhRJbVJXaaGDLQ+GrHlc7Y8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=vTlMmu2qImOvspW0LnUrKWv4pe4md4NkaPtE8VOGRDRioDy+gYlPgTtyDV4TbbG2UI k6KwB7iaVtwmj+v9xnfodiujCow6HyaVz1Y/52ip9MUaU70XDizNtcELCWnBYWl/EYJY C4MIAh6BhNGMXI5WMoTxYQ3LR7KOTElvemdq8= MIME-Version: 1.0 Received: by 10.100.63.2 with SMTP id l2mr2200013ana.177.1259861357442; Thu, 03 Dec 2009 09:29:17 -0800 (PST) In-Reply-To: <4B17F36A.2090908@pi.nu> References: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> <4B16809A.3040409@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AC8@ESESSCMS0355.eemea.ericsson.se> <4B17C57B.40200@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AFD@ESESSCMS0355.eemea.ericsson.se> <4B17F36A.2090908@pi.nu> From: "Andrew G. Malis" Date: Thu, 3 Dec 2009 18:28:57 +0100 Message-ID: <8c99930d0912030928m3d0668d6wbe17ae5edac2002a@mail.gmail.com> To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ccamp@ietf.org" , Attila Takacs , "mpls-tp@ietf.org" Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 17:29:32 -0000 +1 Cheers, Andy On Thu, Dec 3, 2009 at 6:20 PM, Loa Andersson wrote: > Attila, > > if we agree on this the we also have a method to easily reconfigure > OAM on already set up LSPs, simple send a refresh PATH or RESV. > > What do people think is this a good idea? > > /Loa > > Attila Takacs wrote: >> >> Hi Loa, >>> >>> OK great, then we need to update that in the framework. >>> >> Ok, I will do so. >> >>> I also have a question on the relationship between flags and the >>> sub-tlvs. >>> >>> I think there are four possibilities: >>> >>> 1. A flag is set, but there is no sub-tlv >>> =A0 =A0- the action here should be to turn on the function the >>> =A0 =A0 =A0flag indicates using default values >>> =A0 =A0 =A0I also think that if a function indicated by flag is >>> =A0 =A0 =A0running, it should be left unchanged, even if it is not >>> =A0 =A0 =A0running on default values >>> >>> 2. A flag is set, and there is a sub-tlv >>> =A0 =A0- the action here would be to turn on the function indicated by >>> =A0 =A0 =A0the flag, using the parameters found in sub-tlv >>> >>> 3. A flag is not set, and there is no sub-tlv >>> =A0 =A0- the action here would be to turn off any function that has >>> =A0 =A0 =A0been configured earlier >>> >>> 4. A flag is not set, but there is sub-tlv >>> =A0 =A0 =A0- this should be treated as an error conditions and an >>> =A0 =A0 =A0 =A0error message should be returned, no changes to the conf= igured >>> =A0 =A0 =A0 =A0OAM should be made. >>> >>> Is this correctly understood? >> >> Yes. I will check is this need clarification in the fwk. >> >> Attila >> >>> /Loa >>> >>> Attila Takacs wrote: >>>> >>>> Hi Loa, >>>> >>>> It can be carried in the LSP_ATTRIBUTES Object in the Resv >>> >>> message; so it can be used for timer negotiation and discriminator >>> synchronization if needed. >>>> >>>> Attila >>>> >>>>> -----Original Message----- >>>>> From: Loa Andersson [mailto:loa@pi.nu] >>>>> Sent: Wednesday, December 02, 2009 3:59 PM >>>>> To: Attila Takacs >>>>> Cc: ccamp@ietf.org; mpls-tp@ietf.org >>>>> Subject: Re: [CCAMP] Thoughts on updating the OAM >>> >>> Configuration fwk >>>>> >>>>> and the MPLS-TP OAM configuration drafts >>>>> >>>>> Attila, >>>>> >>>>> thanks - I think things are converging quite a bit now. >>>>> >>>>> May the OAM Configuration TLV specified in the OAM Configuration >>>>> Framweork only be present in the PATH message? >>>>> >>>>> /Loa >>>>> >>>>> Attila Takacs wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Some thoughts on updating the OAM Configuration fwk and >>> >>> the MPLS-TP >>>>>> >>>>>> OAM configuration drafts. >>>>>> >>>>>> I think we need to extend the OAM Function flags (described in >>>>>> draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: >>>>>> >>>>>> -CC >>>>>> -CV >>>>>> -PM Loss >>>>>> -PM Delay >>>>>> -Fault Management signals >>>>>> >>>>>> >>>>>> With regards to BFD I see three operation vs. configuration modes: >>>>>> >>>>>> 1) Set CC in the flags and only bootstrap the BFD session, >>>>> >>>>> by sending >>>>>> >>>>>> the local discriminator values in RSVP-TE and leave timer >>>>> >>>>> negotiation >>>>>> >>>>>> to BFD control messages. This is similar to LSP Ping based >>>>>> bootstrapping described in draft-ietf-bfd-mpls-07.txt. >>>>>> >>>>>> 2) Set CC in the flags but configure the timers via the >>>>> >>>>> control plane, >>>>>> >>>>>> this should correspond to "CC mode" in >>>>> >>>>> draft-asm-mpls-tp-bfd-cc-cv-01. >>>>>> >>>>>> We may include the min/max intervals and by doing so >>>>> >>>>> support initial >>>>>> >>>>>> timer negotiation in control plane. However, we may need a >>>>> >>>>> flag in CC >>>>>> >>>>>> configuration sub-TLV (now in >>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called >>>>> >>>>> "Suggested TX >>>>>> >>>>>> Interval sub-TLV") to indicate whether data plane timer >>>>> >>>>> renegotiation >>>>>> >>>>>> is enabled or disabled (i.e., subsequently via BFD control >>>>> >>>>> messages). >>>>>> >>>>>> This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be >>>>>> disabled for TP LSPs by default. >>>>>> >>>>>> 3) In case of "full" MPLS-TP OAM support any of the flags >>>>> >>>>> could be set >>>>>> >>>>>> as needed, reflecting "CV/CC mode" described in >>>>>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as descri= bed in >>>>>> draft-frost-mpls-tp-loss-delay-00 and >>>>> >>>>> management signals >>>>>> >>>>>> as given in draft-sfv-mpls-tp-fault-00. >>>>>> >>>>>> >>>>>> >>>>>> To configure CC we will need to add >>>>>> -enable/disable DP timer re-negotiation -PHB to identify >>>>> >>>>> priority and >>>>>> >>>>>> drop precedence of CC packets >>>>>> >>>>>> When it comes to CV, it would be interesting to discuss >>>>> >>>>> whether only >>>>>> >>>>>> the OAM identifiers described in >>>>> >>>>> draft-ietf-mpls-tp-identifiers-00 are >>>>>> >>>>>> ought to be supported. If so, those could be derived from RSVP-TE >>>>>> signaling without the need to carry them explicitly in >>> >>> MPLS-TP OAM >>>>>> >>>>>> Configuration sub-TLVs (now called Source unique MEP_ID >>> >>> sub-TLV in >>>>>> >>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). >>>>>> >>>>>> For Performance Monitoring Loss/Delay we need to add new TLVs, >>>>>> carrying -measurement interval -possibly loss/delay bound >>>>> >>>>> thresholds >>>>>> >>>>>> (given we what these for MPLS-TP) that could be used to >>> >>> assess the >>>>>> >>>>>> quality of the connection and may eventually trigger >>>>> >>>>> protection -PHB >>>>>> >>>>>> of control packets if we want to set it differently from CC >>>>> >>>>> packets or >>>>>> >>>>>> from data traffic. >>>>>> >>>>>> For the Fault Management Signals, I would add a new "Fault >>>>> >>>>> Management >>>>>> >>>>>> Signals sub-TLV" carrying: >>>>>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except >>> >>> CFS, are >>>>>> >>>>>> specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault >>>>>> indication messages -flag to enable/disable explicitly >>>>> >>>>> clear of faults >>>>>> >>>>>> -PHB of fault management packets >>>>>> >>>>>> >>>>>> Another thing we may want to consider is adding a sub-TLV to set >>>>>> consequent actions that are configurable. This is >>> >>> described to some >>>>>> >>>>>> extent in the MPLS-TP OAM Framework. The defects >>> >>> identified include: >>>>>> >>>>>> Loss Of Continuity defect, Mis-connectivity defect, MEP >>>>>> misconfiguration defect, Period Misconfiguration defect. >>>>>> >>>>>> An operator may want to configure if the consequence of LOC >>>>> >>>>> should be >>>>>> >>>>>> the blocking or non-blocking of outgoing data traffic. >>> >>> Similarly it >>>>>> >>>>>> may be useful to configure whether the "Period >>>>> >>>>> Misconfiguration defect" >>>>>> >>>>>> should result in a signal fail condition or not. >>>>>> >>>>>> >>>>>> I plan to send detailed text to the editors of >>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the lines >>>>>> described above. Please comment! >>>>>> Thanks, >>>>>> Attila >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> -- >>>>> >>>>> >>>>> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: = loa.andersson@ericsson.com >>>>> Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu >>>>> Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone= : +46 10 717 52 13 >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0+46 767 72 92 13 >>> >>> -- >>> >>> >>> Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: lo= a.andersson@ericsson.com >>> Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu >>> Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: = +46 10 717 52 13 >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0+46 767 72 92 13 >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp > > -- > > > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.= andersson@ericsson.com > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +4= 6 10 717 52 13 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From gregimirsky@gmail.com Thu Dec 3 09:34:59 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18803A6890; Thu, 3 Dec 2009 09:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 rD6HZJVF6XGV; Thu, 3 Dec 2009 09:34:58 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 20A4A3A6801; Thu, 3 Dec 2009 09:34:56 -0800 (PST) Received: by bwz23 with SMTP id 23so1367653bwz.29 for ; Thu, 03 Dec 2009 09:34:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/fOBTkJRGlqD4cd5xHX4d3+e2Or4dN05usY4EjIJkJ0=; b=kRtKrfY9fzOmqt9HUg0vjyzgHT3ZIuYjiCpIZN+CJYGTD2zV9EYhOzC+/8/zu8Tipq bTUGoffUBIWvy4nblfbDlk5FY8UqfMpvJYQs0gIihtrjSy8FkoIwXKLkH9kJSdLDgI0d i4AiR7cTk7p7UyVMQU8oyB2XYetlUoRuz7oW4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CKQOza+FELcWraQyTYuvAdjGla17ZSAEvXGmaE9Xj1a2SkkeApb5g/2/PpMIi/p0i0 H669lXeleqsx5kvNltrNFrlRKO9rtZi2tNDKIBtWvqEOBwlUYVkFrF494Djmh/v8ULPB NUJklJ+RUs7SpNNlJ7KKsUoy9trt2PYbogSl8= MIME-Version: 1.0 Received: by 10.204.25.207 with SMTP id a15mr1991021bkc.8.1259861685682; Thu, 03 Dec 2009 09:34:45 -0800 (PST) In-Reply-To: <4B17F36A.2090908@pi.nu> References: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> <4B16809A.3040409@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AC8@ESESSCMS0355.eemea.ericsson.se> <4B17C57B.40200@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AFD@ESESSCMS0355.eemea.ericsson.se> <4B17F36A.2090908@pi.nu> Date: Thu, 3 Dec 2009 09:34:45 -0800 Message-ID: <787be2780912030934n18eeed99haeb6db2bcce3a409@mail.gmail.com> From: Greg Mirsky To: Loa Andersson Content-Type: multipart/alternative; boundary=0003255579563dc2570479d6681d Cc: "ccamp@ietf.org" , Attila Takacs , "mpls-tp@ietf.org" Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 17:34:59 -0000 --0003255579563dc2570479d6681d Content-Type: text/plain; charset=ISO-8859-1 Yes, indeed Regards, Greg On Thu, Dec 3, 2009 at 9:20 AM, Loa Andersson wrote: > Attila, > > if we agree on this the we also have a method to easily reconfigure > OAM on already set up LSPs, simple send a refresh PATH or RESV. > > What do people think is this a good idea? > > > /Loa > > Attila Takacs wrote: > >> Hi Loa, >> >>> OK great, then we need to update that in the framework. >>> >>> Ok, I will do so. >> >> I also have a question on the relationship between flags and the >>> sub-tlvs. >>> >>> I think there are four possibilities: >>> >>> 1. A flag is set, but there is no sub-tlv >>> - the action here should be to turn on the function the >>> flag indicates using default values >>> I also think that if a function indicated by flag is >>> running, it should be left unchanged, even if it is not >>> running on default values >>> >>> 2. A flag is set, and there is a sub-tlv >>> - the action here would be to turn on the function indicated by >>> the flag, using the parameters found in sub-tlv >>> >>> 3. A flag is not set, and there is no sub-tlv >>> - the action here would be to turn off any function that has >>> been configured earlier >>> >>> 4. A flag is not set, but there is sub-tlv >>> - this should be treated as an error conditions and an >>> error message should be returned, no changes to the configured >>> OAM should be made. >>> >>> Is this correctly understood? >>> >> Yes. I will check is this need clarification in the fwk. >> >> Attila >> >> /Loa >>> >>> Attila Takacs wrote: >>> >>>> Hi Loa, >>>> >>>> It can be carried in the LSP_ATTRIBUTES Object in the Resv >>>> >>> message; so it can be used for timer negotiation and discriminator >>> synchronization if needed. >>> >>>> Attila >>>> >>>> -----Original Message----- >>>>> From: Loa Andersson [mailto:loa@pi.nu] >>>>> Sent: Wednesday, December 02, 2009 3:59 PM >>>>> To: Attila Takacs >>>>> Cc: ccamp@ietf.org; mpls-tp@ietf.org >>>>> Subject: Re: [CCAMP] Thoughts on updating the OAM >>>>> >>>> Configuration fwk >>> >>>> and the MPLS-TP OAM configuration drafts >>>>> >>>>> Attila, >>>>> >>>>> thanks - I think things are converging quite a bit now. >>>>> >>>>> May the OAM Configuration TLV specified in the OAM Configuration >>>>> Framweork only be present in the PATH message? >>>>> >>>>> /Loa >>>>> >>>>> Attila Takacs wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Some thoughts on updating the OAM Configuration fwk and >>>>>> >>>>> the MPLS-TP >>> >>>> OAM configuration drafts. >>>>>> >>>>>> I think we need to extend the OAM Function flags (described in >>>>>> draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: >>>>>> >>>>>> -CC >>>>>> -CV >>>>>> -PM Loss >>>>>> -PM Delay >>>>>> -Fault Management signals >>>>>> >>>>>> >>>>>> With regards to BFD I see three operation vs. configuration modes: >>>>>> >>>>>> 1) Set CC in the flags and only bootstrap the BFD session, >>>>>> >>>>> by sending >>>>> >>>>>> the local discriminator values in RSVP-TE and leave timer >>>>>> >>>>> negotiation >>>>> >>>>>> to BFD control messages. This is similar to LSP Ping based >>>>>> bootstrapping described in draft-ietf-bfd-mpls-07.txt. >>>>>> >>>>>> 2) Set CC in the flags but configure the timers via the >>>>>> >>>>> control plane, >>>>> >>>>>> this should correspond to "CC mode" in >>>>>> >>>>> draft-asm-mpls-tp-bfd-cc-cv-01. >>>>> >>>>>> We may include the min/max intervals and by doing so >>>>>> >>>>> support initial >>>>> >>>>>> timer negotiation in control plane. However, we may need a >>>>>> >>>>> flag in CC >>>>> >>>>>> configuration sub-TLV (now in >>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called >>>>>> >>>>> "Suggested TX >>>>> >>>>>> Interval sub-TLV") to indicate whether data plane timer >>>>>> >>>>> renegotiation >>>>> >>>>>> is enabled or disabled (i.e., subsequently via BFD control >>>>>> >>>>> messages). >>>>> >>>>>> This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be >>>>>> disabled for TP LSPs by default. >>>>>> >>>>>> 3) In case of "full" MPLS-TP OAM support any of the flags >>>>>> >>>>> could be set >>>>> >>>>>> as needed, reflecting "CV/CC mode" described in >>>>>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as described in >>>>>> draft-frost-mpls-tp-loss-delay-00 and >>>>>> >>>>> management signals >>>>> >>>>>> as given in draft-sfv-mpls-tp-fault-00. >>>>>> >>>>>> >>>>>> >>>>>> To configure CC we will need to add >>>>>> -enable/disable DP timer re-negotiation -PHB to identify >>>>>> >>>>> priority and >>>>> >>>>>> drop precedence of CC packets >>>>>> >>>>>> When it comes to CV, it would be interesting to discuss >>>>>> >>>>> whether only >>>>> >>>>>> the OAM identifiers described in >>>>>> >>>>> draft-ietf-mpls-tp-identifiers-00 are >>>>> >>>>>> ought to be supported. If so, those could be derived from RSVP-TE >>>>>> signaling without the need to carry them explicitly in >>>>>> >>>>> MPLS-TP OAM >>> >>>> Configuration sub-TLVs (now called Source unique MEP_ID >>>>>> >>>>> sub-TLV in >>> >>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). >>>>>> >>>>>> For Performance Monitoring Loss/Delay we need to add new TLVs, >>>>>> carrying -measurement interval -possibly loss/delay bound >>>>>> >>>>> thresholds >>>>> >>>>>> (given we what these for MPLS-TP) that could be used to >>>>>> >>>>> assess the >>> >>>> quality of the connection and may eventually trigger >>>>>> >>>>> protection -PHB >>>>> >>>>>> of control packets if we want to set it differently from CC >>>>>> >>>>> packets or >>>>> >>>>>> from data traffic. >>>>>> >>>>>> For the Fault Management Signals, I would add a new "Fault >>>>>> >>>>> Management >>>>> >>>>>> Signals sub-TLV" carrying: >>>>>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except >>>>>> >>>>> CFS, are >>> >>>> specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault >>>>>> indication messages -flag to enable/disable explicitly >>>>>> >>>>> clear of faults >>>>> >>>>>> -PHB of fault management packets >>>>>> >>>>>> >>>>>> Another thing we may want to consider is adding a sub-TLV to set >>>>>> consequent actions that are configurable. This is >>>>>> >>>>> described to some >>> >>>> extent in the MPLS-TP OAM Framework. The defects >>>>>> >>>>> identified include: >>> >>>> Loss Of Continuity defect, Mis-connectivity defect, MEP misconfiguration >>>>>> defect, Period Misconfiguration defect. >>>>>> >>>>>> An operator may want to configure if the consequence of LOC >>>>>> >>>>> should be >>>>> >>>>>> the blocking or non-blocking of outgoing data traffic. >>>>>> >>>>> Similarly it >>> >>>> may be useful to configure whether the "Period >>>>>> >>>>> Misconfiguration defect" >>>>> >>>>>> should result in a signal fail condition or not. >>>>>> >>>>>> >>>>>> I plan to send detailed text to the editors of >>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the lines >>>>>> described above. Please comment! >>>>>> Thanks, >>>>>> Attila >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>> -- >>>>> >>>>> >>>>> Loa Andersson email: >>>>> loa.andersson@ericsson.com >>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>> +46 767 72 92 13 >>>>> >>>> -- >>> >>> >>> Loa Andersson email: loa.andersson@ericsson.com >>> Sr Strategy and Standards Manager loa@pi.nu >>> Ericsson Inc phone: +46 10 717 52 13 >>> +46 767 72 92 13 >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >> > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --0003255579563dc2570479d6681d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, indeed

Regards,
Greg

On Th= u, Dec 3, 2009 at 9:20 AM, Loa Andersson <loa@pi.nu> wrote:
Attila,

if we agree on this the we also have a method to easily reconfigure
OAM on already set up LSPs, simple send a refresh PATH or RESV.

What do people think is this a good idea?
=

/Loa

Attila Takacs wrote:
Hi Loa,
OK great, then we need to update that in the framework.

Ok, I will do so.

I also have a question on the relationship between flags and the sub-tlvs.<= br>
I think there are four possibilities:

1. A flag is set, but there is no sub-tlv
=A0 =A0- the action here should be to turn on the function the
=A0 =A0 =A0flag indicates using default values
=A0 =A0 =A0I also think that if a function indicated by flag is
=A0 =A0 =A0running, it should be left unchanged, even if it is not
=A0 =A0 =A0running on default values

2. A flag is set, and there is a sub-tlv
=A0 =A0- the action here would be to turn on the function indicated by
=A0 =A0 =A0the flag, using the parameters found in sub-tlv

3. A flag is not set, and there is no sub-tlv
=A0 =A0- the action here would be to turn off any function that has
=A0 =A0 =A0been configured earlier

4. A flag is not set, but there is sub-tlv
=A0 =A0 =A0- this should be treated as an error conditions and an
=A0 =A0 =A0 =A0error message should be returned, no changes to the configu= red
=A0 =A0 =A0 =A0OAM should be made.

Is this correctly understood?
Yes. I will check is this need clarification in the fwk.

Attila

/Loa

Attila Takacs wrote:
Hi Loa,

It can be carried in the LSP_ATTRIBUTES Object in the Resv
message; so it can be used for timer negotiation and discriminator synchron= ization if needed.
Attila

-----Original Message-----
From: Loa Andersson [mailto:= loa@pi.nu]
Sent: Wednesday, December 02, 2009 3:59 PM
To: Attila Takacs
Cc: ccamp@ietf.org;= mpls-tp@ietf.org=
Subject: Re: [CCAMP] Thoughts on updating the OAM
Configuration fwk
and the MPLS-TP OAM configuration drafts

Attila,

thanks - I think things are converging quite a bit now.

May the OAM Configuration TLV specified in the OAM Configuration Framweork = only be present in the PATH message?

/Loa

Attila Takacs wrote:
Hi all,

Some thoughts on updating the OAM Configuration fwk and
the MPLS-TP
OAM configuration drafts.

I think we need to extend the OAM Function flags (described in
draft-ietf-ccamp-oam-configuration-fwk-02) to five flags:

-CC
-CV
-PM Loss
-PM Delay
-Fault Management signals


With regards to BFD I see three operation vs. configuration modes:

1) Set CC in the flags and only bootstrap the BFD session,
by sending
the local discriminator values in RSVP-TE and leave timer
negotiation
to BFD control messages. This is similar to LSP Ping based bootstrapping de= scribed in draft-ietf-bfd-mpls-07.txt.

2) Set CC in the flags but configure the timers via the
control plane,
this should correspond to "CC mode" in
draft-asm-mpls-tp-bfd-cc-cv-01.
We may include the min/max intervals and by doing so
support initial
timer negotiation in control plane. However, we may need a
flag in CC
configuration sub-TLV (now in
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called
"Suggested TX
Interval sub-TLV") to indicate whether data plane timer
renegotiation
is enabled or disabled (i.e., subsequently via BFD control
messages).
This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be disabled fo= r TP LSPs by default.

3) In case of "full" MPLS-TP OAM support any of the flags
could be set
as needed, reflecting "CV/CC mode" described in draft-asm-mpls-tp= -bfd-cc-cv-01, delay and loss measurement as described in draft-frost-mpls-= tp-loss-delay-00 and
management signals
as given in draft-sfv-mpls-tp-fault-00.



To configure CC we will need to add
-enable/disable DP timer re-negotiation -PHB to identify
priority and
drop precedence of CC packets

When it comes to CV, it would be interesting to discuss
whether only
the OAM identifiers described in
draft-ietf-mpls-tp-identifiers-00 are
ought to be supported. If so, those could be derived from RSVP-TE signaling= without the need to carry them explicitly in
MPLS-TP OAM
Configuration sub-TLVs (now called Source unique MEP_ID
sub-TLV in
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03).

For Performance Monitoring Loss/Delay we need to add new TLVs, carrying -me= asurement interval -possibly loss/delay bound
thresholds
(given we what these for MPLS-TP) that could be used to
assess the
quality of the connection and may eventually trigger
protection -PHB
of control packets if we want to set it differently from CC
packets or
from data traffic.

For the Fault Management Signals, I would add a new "Fault
Management
Signals sub-TLV" carrying:
-Enabled signals flags: AIS, LDI, LKR, CFS (which, except
CFS, are
specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault indication= messages -flag to enable/disable explicitly
clear of faults
-PHB of fault management packets


Another thing we may want to consider is adding a sub-TLV to set consequent= actions that are configurable. This is
described to some
extent in the MPLS-TP OAM Framework. The defects
identified include:
Loss Of Continuity defect, Mis-connectivity defect, MEP misconfiguration de= fect, Period Misconfiguration defect.

An operator may want to configure if the consequence of LOC
should be
the blocking or non-blocking of outgoing data traffic.
Similarly it
may be useful to configure whether the "Period
Misconfiguration defect"
should result in a signal fail condition or not.


I plan to send detailed text to the editors of
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the lines described= above. Please comment!
Thanks,
Attila



_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@eri= csson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0+46 767 72 92 13
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@eri= csson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0+46 767 72 92 13 _______________________________________= ________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@eri= csson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--0003255579563dc2570479d6681d-- From neil.2.harrison@bt.com Thu Dec 3 09:41:32 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8162E28C156; Thu, 3 Dec 2009 09:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 zGTeblf+bv3w; Thu, 3 Dec 2009 09:41:30 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 14B9D28C150; Thu, 3 Dec 2009 09:41:29 -0800 (PST) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 17:41:20 +0000 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_01CA743F.D2BCDF2D" Date: Thu, 3 Dec 2009 17:41:17 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C05636144@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <787be2780912030934n18eeed99haeb6db2bcce3a409@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Thoughts on updating the OAM Configuration fwk and theMPLS-TP OAM configuration drafts Thread-Index: Acp0PvFCfv3/hfwoQ3msDf0YsGywvgAAC96g From: To: X-OriginalArrivalTime: 03 Dec 2009 17:41:20.0507 (UTC) FILETIME=[D2FD7CB0:01CA743F] Cc: ccamp@ietf.org, Attila.Takacs@ericsson.com, mpls-tp@ietf.org Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration fwk and theMPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 17:41:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA743F.D2BCDF2D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It sounds like a sensible idea to me Loa. Indeed, I have always been of the view that in co mode networks using a CP the signalling protocol has a very important role to play wrt telling trail termination points what SA to expect in CV OAM DP packets, and also activating/deactivating the (CV) defect detection/handling in sync with set-up/tear-down of the connection. =20 regards, Neil ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: 03 December 2009 17:35 To: Loa Andersson Cc: ccamp@ietf.org; Attila Takacs; mpls-tp@ietf.org Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration fwk and theMPLS-TP OAM configuration drafts =09 =09 Yes, indeed =09 Regards, Greg =09 =09 On Thu, Dec 3, 2009 at 9:20 AM, Loa Andersson wrote: =09 Attila, =09 if we agree on this the we also have a method to easily reconfigure OAM on already set up LSPs, simple send a refresh PATH or RESV. =09 What do people think is this a good idea?=20 /Loa =09 Attila Takacs wrote: =09 Hi Loa,=20 =09 OK great, then we need to update that in the framework. =09 =09 Ok, I will do so. =09 =09 I also have a question on the relationship between flags and the sub-tlvs. =09 I think there are four possibilities: =09 1. A flag is set, but there is no sub-tlv - the action here should be to turn on the function the flag indicates using default values I also think that if a function indicated by flag is running, it should be left unchanged, even if it is not running on default values =09 2. A flag is set, and there is a sub-tlv - the action here would be to turn on the function indicated by the flag, using the parameters found in sub-tlv =09 3. A flag is not set, and there is no sub-tlv - the action here would be to turn off any function that has been configured earlier =09 4. A flag is not set, but there is sub-tlv - this should be treated as an error conditions and an error message should be returned, no changes to the configured OAM should be made. =09 Is this correctly understood? =09 Yes. I will check is this need clarification in the fwk. =09 Attila =09 =09 /Loa =09 Attila Takacs wrote: =09 Hi Loa, =09 It can be carried in the LSP_ATTRIBUTES Object in the Resv=20 =09 message; so it can be used for timer negotiation and discriminator synchronization if needed. =09 Attila =09 =09 -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, December 02, 2009 3:59 PM To: Attila Takacs Cc: ccamp@ietf.org; mpls-tp@ietf.org Subject: Re: [CCAMP] Thoughts on updating the OAM=20 =09 Configuration fwk=20 =09 and the MPLS-TP OAM configuration drafts =09 Attila, =09 thanks - I think things are converging quite a bit now. =09 May the OAM Configuration TLV specified in the OAM Configuration Framweork only be present in the PATH message? =09 /Loa =09 Attila Takacs wrote: =09 Hi all, =09 Some thoughts on updating the OAM Configuration fwk and=20 =09 the MPLS-TP=20 =09 OAM configuration drafts. =09 I think we need to extend the OAM Function flags (described in =09 draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: =09 -CC -CV -PM Loss -PM Delay -Fault Management signals =09 =09 With regards to BFD I see three operation vs. configuration modes: =09 1) Set CC in the flags and only bootstrap the BFD session, =09 by sending =09 the local discriminator values in RSVP-TE and leave timer =09 negotiation =09 to BFD control messages. This is similar to LSP Ping based bootstrapping described in draft-ietf-bfd-mpls-07.txt. =09 2) Set CC in the flags but configure the timers via the =09 control plane, =09 this should correspond to "CC mode" in =09 draft-asm-mpls-tp-bfd-cc-cv-01. =09 We may include the min/max intervals and by doing so =09 support initial =09 timer negotiation in control plane. However, we may need a =09 flag in CC =09 configuration sub-TLV (now in =09 draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called =09 "Suggested TX =09 Interval sub-TLV") to indicate whether data plane timer =09 renegotiation =09 is enabled or disabled (i.e., subsequently via BFD control =09 messages).=20 =09 This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be disabled for TP LSPs by default. =09 3) In case of "full" MPLS-TP OAM support any of the flags =09 could be set =09 as needed, reflecting "CV/CC mode" described in draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as described in draft-frost-mpls-tp-loss-delay-00 and =09 management signals =09 as given in draft-sfv-mpls-tp-fault-00. =09 =09 =09 To configure CC we will need to add -enable/disable DP timer re-negotiation -PHB to identify =09 priority and =09 drop precedence of CC packets =09 When it comes to CV, it would be interesting to discuss =09 whether only =09 the OAM identifiers described in =09 draft-ietf-mpls-tp-identifiers-00 are =09 ought to be supported. If so, those could be derived from RSVP-TE signaling without the need to carry them explicitly in=20 =09 MPLS-TP OAM=20 =09 Configuration sub-TLVs (now called Source unique MEP_ID=20 =09 sub-TLV in=20 =09 =09 draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). =09 For Performance Monitoring Loss/Delay we need to add new TLVs, carrying -measurement interval -possibly loss/delay bound =09 thresholds =09 (given we what these for MPLS-TP) that could be used to=20 =09 assess the=20 =09 quality of the connection and may eventually trigger =09 protection -PHB =09 of control packets if we want to set it differently from CC =09 packets or =09 from data traffic. =09 For the Fault Management Signals, I would add a new "Fault =09 Management =09 Signals sub-TLV" carrying: -Enabled signals flags: AIS, LDI, LKR, CFS (which, except=20 =09 CFS, are=20 =09 specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault indication messages -flag to enable/disable explicitly =09 clear of faults =09 -PHB of fault management packets =09 =09 Another thing we may want to consider is adding a sub-TLV to set consequent actions that are configurable. This is=20 =09 described to some=20 =09 extent in the MPLS-TP OAM Framework. The defects=20 =09 identified include: =09 Loss Of Continuity defect, Mis-connectivity defect, MEP misconfiguration defect, Period Misconfiguration defect. =09 An operator may want to configure if the consequence of LOC =09 should be =09 the blocking or non-blocking of outgoing data traffic.=20 =09 Similarly it=20 =09 may be useful to configure whether the "Period =09 Misconfiguration defect" =09 should result in a signal fail condition or not. =09 =09 I plan to send detailed text to the editors of =09 draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the lines described above. Please comment! Thanks, Attila =09 =09 =09 =09 _______________________________________________ CCAMP mailing list CCAMP@ietf.org =09 https://www.ietf.org/mailman/listinfo/ccamp =09 -- =09 =09 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 =09 +46 767 72 92 13 =09 --=20 =09 =09 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 =09 +46 767 72 92 13 _______________________________________________ CCAMP mailing list CCAMP@ietf.org =09 https://www.ietf.org/mailman/listinfo/ccamp =09 --=20 =09 =09 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp =09 ------_=_NextPart_001_01CA743F.D2BCDF2D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It sounds like a sensible idea to me = Loa.  Indeed,=20 I have always been of the view that in co mode networks using a CP=20 the signalling protocol has a very important role to play wrt = telling trail=20 termination points what SA to expect in CV OAM DP packets, and also=20 activating/deactivating the (CV) defect detection/handling in sync with=20 set-up/tear-down of the connection.
 
regards, Neil

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg=20 Mirsky
Sent: 03 December 2009 17:35
To: Loa=20 Andersson
Cc: ccamp@ietf.org; Attila Takacs;=20 mpls-tp@ietf.org
Subject: Re: [CCAMP] Thoughts on updating = the OAM=20 Configuration fwk and theMPLS-TP OAM configuration = drafts

Yes, indeed

Regards,
Greg

On Thu, Dec 3, 2009 at 9:20 AM, Loa Andersson = <loa@pi.nu> = wrote:
Attila,

if=20 we agree on this the we also have a method to easily = reconfigure
OAM on=20 already set up LSPs, simple send a refresh PATH or RESV.

What = do=20 people think is this a good idea?


/Loa

Attila Takacs wrote:
Hi=20 Loa,
OK=20 great, then we need to update that in the=20 framework.

Ok, I will do so.

I=20 also have a question on the relationship between flags and the=20 sub-tlvs.

I think there are four possibilities:

1. = A flag=20 is set, but there is no sub-tlv
   - the action = here should=20 be to turn on the function the
     flag = indicates=20 using default values
     I also think that if = a=20 function indicated by flag is
     running, it = should=20 be left unchanged, even if it is not
    =  running on=20 default values

2. A flag is set, and there is a = sub-tlv
 =20  - the action here would be to turn on the function = indicated=20 by
     the flag, using the parameters found = in=20 sub-tlv

3. A flag is not set, and there is no = sub-tlv
 =20  - the action here would be to turn off any function that=20 has
     been configured earlier

4. A = flag is=20 not set, but there is sub-tlv
     - this = should be=20 treated as an error conditions and an
     =20  error message should be returned, no changes to the=20 configured
       OAM should be = made.

Is=20 this correctly understood?
Yes. I will check is = this need=20 clarification in the fwk.

Attila

/Loa

Attila=20 Takacs wrote:
Hi=20 Loa,

It can be carried in the LSP_ATTRIBUTES Object in = the Resv=20
message; so it can be used for timer = negotiation and=20 discriminator synchronization if needed.
Attila

-----Original=20 Message-----
From: Loa Andersson [mailto:loa@pi.nu]
Sent:=20 Wednesday, December 02, 2009 3:59 PM
To: Attila = Takacs
Cc: ccamp@ietf.org; mpls-tp@ietf.org
Subject: Re: [CCAMP] = Thoughts=20 on updating the OAM =
Configuration fwk
and=20 the MPLS-TP OAM configuration = drafts

Attila,

thanks -=20 I think things are converging quite a bit now.

May = the OAM=20 Configuration TLV specified in the OAM Configuration = Framweork only=20 be present in the PATH message?

/Loa

Attila = Takacs=20 wrote:
Hi=20 all,

Some thoughts on updating the OAM = Configuration fwk=20 and
the MPLS-TP =
OAM=20 configuration drafts.

I think we need to extend the = OAM=20 Function flags (described=20 in
draft-ietf-ccamp-oam-configuration-fwk-02) to five=20 flags:

-CC
-CV
-PM Loss
-PM = Delay
-Fault=20 Management signals


With regards to BFD I see = three=20 operation vs. configuration modes:

1) Set CC in the = flags=20 and only bootstrap the BFD session,
by = sending
the=20 local discriminator values in RSVP-TE and leave=20 timer
negotiation
to=20 BFD control messages. This is similar to LSP Ping based=20 bootstrapping described in = draft-ietf-bfd-mpls-07.txt.

2)=20 Set CC in the flags but configure the timers via=20 the
control plane,
this=20 should correspond to "CC mode"=20 in
draft-asm-mpls-tp-bfd-cc-cv-01.
We=20 may include the min/max intervals and by doing=20 so
support initial
timer=20 negotiation in control plane. However, we may need=20 a
flag in CC
configuration=20 sub-TLV (now=20 in
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03=20 called
"Suggested TX
Interval=20 sub-TLV") to indicate whether data plane=20 timer
renegotiation
is=20 enabled or disabled (i.e., subsequently via BFD=20 control
messages).
This,=20 as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be = disabled=20 for TP LSPs by default.

3) In case of "full" = MPLS-TP OAM=20 support any of the flags
could be set
as=20 needed, reflecting "CV/CC mode" described in=20 draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement = as=20 described in draft-frost-mpls-tp-loss-delay-00=20 and
management signals
as=20 given in draft-sfv-mpls-tp-fault-00.



To = configure=20 CC we will need to add
-enable/disable DP timer = re-negotiation=20 -PHB to identify
priority and
drop=20 precedence of CC packets

When it comes to CV, it = would be=20 interesting to discuss
whether only
the=20 OAM identifiers described=20 in
draft-ietf-mpls-tp-identifiers-00 are
ought=20 to be supported. If so, those could be derived from = RSVP-TE=20 signaling without the need to carry them explicitly in=20
MPLS-TP OAM
Configuration=20 sub-TLVs (now called Source unique MEP_ID=20
sub-TLV in
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03).

For=20 Performance Monitoring Loss/Delay we need to add new TLVs, = carrying -measurement interval -possibly loss/delay=20 bound
thresholds
(given=20 we what these for MPLS-TP) that could be used to=20
assess the
quality=20 of the connection and may eventually=20 trigger
protection -PHB
of=20 control packets if we want to set it differently from=20 CC
packets or
from=20 data traffic.

For the Fault Management Signals, I = would add=20 a new "Fault
Management
Signals=20 sub-TLV" carrying:
-Enabled signals flags: AIS, LDI, = LKR, CFS=20 (which, except =
CFS, are
specified=20 in draft-sfv-mpls-tp-fault-00) -refresh timer of fault = indication=20 messages -flag to enable/disable = explicitly
clear of=20 faults
-PHB=20 of fault management packets


Another thing we = may want=20 to consider is adding a sub-TLV to set consequent actions = that are=20 configurable. This is=20
described to some =
extent=20 in the MPLS-TP OAM Framework. The defects=20
identified = include:
Loss=20 Of Continuity defect, Mis-connectivity defect, MEP=20 misconfiguration defect, Period Misconfiguration = defect.

An=20 operator may want to configure if the consequence of=20 LOC
should be
the=20 blocking or non-blocking of outgoing data traffic.=20
Similarly it
may=20 be useful to configure whether the=20 "Period
Misconfiguration defect"
should=20 result in a signal fail condition or not.


I = plan to=20 send detailed text to the editors=20 of
draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 = along the=20 lines described above. Please=20 = comment!
Thanks,
Attila



____________________________= ___________________
CCAMP=20 mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--


Loa=20 Andersson               =  =20         email: loa.andersson@ericsson.com
Sr = Strategy and=20 Standards Manager           =  loa@pi.nu
Ericsson Inc=20                 =  =20        phone: +46 10 717 52 13
  =  =20                 =  =20                 =  =20      +46 767 72 92 = 13
--=20


Loa Andersson           =  =20             email: loa.andersson@ericsson.com
Sr Strategy = and=20 Standards Manager            loa@pi.nu
Ericsson Inc=20                   =  =20      phone: +46 10 717 52 13
    =  =20                   =  =20                   =  +46=20 767 72 92 13 = _______________________________________________
CCAMP=20 mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

--=20


Loa Andersson             =  =20           email: loa.andersson@ericsson.com
Sr Strategy and = Standards=20 Manager            loa@pi.nu
Ericsson Inc       =  =20                  phone: = +46 10=20 717 52 13
                =  =20                   =    =20     +46 767 72 92=20 13
_______________________________________________
CCAMP = mailing=20 list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
=

------_=_NextPart_001_01CA743F.D2BCDF2D-- From tnadeau@lucidvision.com Thu Dec 3 10:14:20 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9623A67D8; Thu, 3 Dec 2009 10:14:20 -0800 (PST) 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 ngK5LJvNJOHR; Thu, 3 Dec 2009 10:14:11 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 7618C3A6892; Thu, 3 Dec 2009 10:14:07 -0800 (PST) Received: from [10.144.221.27] (unknown [32.140.129.165]) by lucidvision.com (Postfix) with ESMTP id AD50342141E2; Thu, 3 Dec 2009 13:13:55 -0500 (EST) References: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> <4B16809A.3040409@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AC8@ESESSCMS0355.eemea.ericsson.se> <4B17C57B.40200@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AFD@ESESSCMS0355.eemea.ericsson.se> <4B17F36A.2090908@pi.nu> <8c99930d0912030928m3d0668d6wbe17ae5edac2002a@mail.gmail.com> Message-Id: <3F0E9049-4EDC-4E86-934C-9D5673FE11AF@lucidvision.com> From: Thomas Nadeau To: "Andrew G. Malis" In-Reply-To: <8c99930d0912030928m3d0668d6wbe17ae5edac2002a@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Thu, 3 Dec 2009 13:13:44 -0500 Cc: "ccamp@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [CCAMP] [mpls-tp] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 18:14:20 -0000 Has anyone thought about security ramifications of allowing this? On Dec 3, 2009, at 12:28 PM, "Andrew G. Malis" wrote: > +1 > > Cheers, > Andy > > On Thu, Dec 3, 2009 at 6:20 PM, Loa Andersson wrote: >> Attila, >> >> if we agree on this the we also have a method to easily reconfigure >> OAM on already set up LSPs, simple send a refresh PATH or RESV. >> >> What do people think is this a good idea? >> >> /Loa >> >> Attila Takacs wrote: >>> >>> Hi Loa, >>>> >>>> OK great, then we need to update that in the framework. >>>> >>> Ok, I will do so. >>> >>>> I also have a question on the relationship between flags and the >>>> sub-tlvs. >>>> >>>> I think there are four possibilities: >>>> >>>> 1. A flag is set, but there is no sub-tlv >>>> - the action here should be to turn on the function the >>>> flag indicates using default values >>>> I also think that if a function indicated by flag is >>>> running, it should be left unchanged, even if it is not >>>> running on default values >>>> >>>> 2. A flag is set, and there is a sub-tlv >>>> - the action here would be to turn on the function indicated by >>>> the flag, using the parameters found in sub-tlv >>>> >>>> 3. A flag is not set, and there is no sub-tlv >>>> - the action here would be to turn off any function that has >>>> been configured earlier >>>> >>>> 4. A flag is not set, but there is sub-tlv >>>> - this should be treated as an error conditions and an >>>> error message should be returned, no changes to the >>>> configured >>>> OAM should be made. >>>> >>>> Is this correctly understood? >>> >>> Yes. I will check is this need clarification in the fwk. >>> >>> Attila >>> >>>> /Loa >>>> >>>> Attila Takacs wrote: >>>>> >>>>> Hi Loa, >>>>> >>>>> It can be carried in the LSP_ATTRIBUTES Object in the Resv >>>> >>>> message; so it can be used for timer negotiation and discriminator >>>> synchronization if needed. >>>>> >>>>> Attila >>>>> >>>>>> -----Original Message----- >>>>>> From: Loa Andersson [mailto:loa@pi.nu] >>>>>> Sent: Wednesday, December 02, 2009 3:59 PM >>>>>> To: Attila Takacs >>>>>> Cc: ccamp@ietf.org; mpls-tp@ietf.org >>>>>> Subject: Re: [CCAMP] Thoughts on updating the OAM >>>> >>>> Configuration fwk >>>>>> >>>>>> and the MPLS-TP OAM configuration drafts >>>>>> >>>>>> Attila, >>>>>> >>>>>> thanks - I think things are converging quite a bit now. >>>>>> >>>>>> May the OAM Configuration TLV specified in the OAM Configuration >>>>>> Framweork only be present in the PATH message? >>>>>> >>>>>> /Loa >>>>>> >>>>>> Attila Takacs wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Some thoughts on updating the OAM Configuration fwk and >>>> >>>> the MPLS-TP >>>>>>> >>>>>>> OAM configuration drafts. >>>>>>> >>>>>>> I think we need to extend the OAM Function flags (described in >>>>>>> draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: >>>>>>> >>>>>>> -CC >>>>>>> -CV >>>>>>> -PM Loss >>>>>>> -PM Delay >>>>>>> -Fault Management signals >>>>>>> >>>>>>> >>>>>>> With regards to BFD I see three operation vs. configuration >>>>>>> modes: >>>>>>> >>>>>>> 1) Set CC in the flags and only bootstrap the BFD session, >>>>>> >>>>>> by sending >>>>>>> >>>>>>> the local discriminator values in RSVP-TE and leave timer >>>>>> >>>>>> negotiation >>>>>>> >>>>>>> to BFD control messages. This is similar to LSP Ping based >>>>>>> bootstrapping described in draft-ietf-bfd-mpls-07.txt. >>>>>>> >>>>>>> 2) Set CC in the flags but configure the timers via the >>>>>> >>>>>> control plane, >>>>>>> >>>>>>> this should correspond to "CC mode" in >>>>>> >>>>>> draft-asm-mpls-tp-bfd-cc-cv-01. >>>>>>> >>>>>>> We may include the min/max intervals and by doing so >>>>>> >>>>>> support initial >>>>>>> >>>>>>> timer negotiation in control plane. However, we may need a >>>>>> >>>>>> flag in CC >>>>>>> >>>>>>> configuration sub-TLV (now in >>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called >>>>>> >>>>>> "Suggested TX >>>>>>> >>>>>>> Interval sub-TLV") to indicate whether data plane timer >>>>>> >>>>>> renegotiation >>>>>>> >>>>>>> is enabled or disabled (i.e., subsequently via BFD control >>>>>> >>>>>> messages). >>>>>>> >>>>>>> This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be >>>>>>> disabled for TP LSPs by default. >>>>>>> >>>>>>> 3) In case of "full" MPLS-TP OAM support any of the flags >>>>>> >>>>>> could be set >>>>>>> >>>>>>> as needed, reflecting "CV/CC mode" described in >>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as >>>>>>> described in >>>>>>> draft-frost-mpls-tp-loss-delay-00 and >>>>>> >>>>>> management signals >>>>>>> >>>>>>> as given in draft-sfv-mpls-tp-fault-00. >>>>>>> >>>>>>> >>>>>>> >>>>>>> To configure CC we will need to add >>>>>>> -enable/disable DP timer re-negotiation -PHB to identify >>>>>> >>>>>> priority and >>>>>>> >>>>>>> drop precedence of CC packets >>>>>>> >>>>>>> When it comes to CV, it would be interesting to discuss >>>>>> >>>>>> whether only >>>>>>> >>>>>>> the OAM identifiers described in >>>>>> >>>>>> draft-ietf-mpls-tp-identifiers-00 are >>>>>>> >>>>>>> ought to be supported. If so, those could be derived from RSVP- >>>>>>> TE >>>>>>> signaling without the need to carry them explicitly in >>>> >>>> MPLS-TP OAM >>>>>>> >>>>>>> Configuration sub-TLVs (now called Source unique MEP_ID >>>> >>>> sub-TLV in >>>>>>> >>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). >>>>>>> >>>>>>> For Performance Monitoring Loss/Delay we need to add new TLVs, >>>>>>> carrying -measurement interval -possibly loss/delay bound >>>>>> >>>>>> thresholds >>>>>>> >>>>>>> (given we what these for MPLS-TP) that could be used to >>>> >>>> assess the >>>>>>> >>>>>>> quality of the connection and may eventually trigger >>>>>> >>>>>> protection -PHB >>>>>>> >>>>>>> of control packets if we want to set it differently from CC >>>>>> >>>>>> packets or >>>>>>> >>>>>>> from data traffic. >>>>>>> >>>>>>> For the Fault Management Signals, I would add a new "Fault >>>>>> >>>>>> Management >>>>>>> >>>>>>> Signals sub-TLV" carrying: >>>>>>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except >>>> >>>> CFS, are >>>>>>> >>>>>>> specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault >>>>>>> indication messages -flag to enable/disable explicitly >>>>>> >>>>>> clear of faults >>>>>>> >>>>>>> -PHB of fault management packets >>>>>>> >>>>>>> >>>>>>> Another thing we may want to consider is adding a sub-TLV to set >>>>>>> consequent actions that are configurable. This is >>>> >>>> described to some >>>>>>> >>>>>>> extent in the MPLS-TP OAM Framework. The defects >>>> >>>> identified include: >>>>>>> >>>>>>> Loss Of Continuity defect, Mis-connectivity defect, MEP >>>>>>> misconfiguration defect, Period Misconfiguration defect. >>>>>>> >>>>>>> An operator may want to configure if the consequence of LOC >>>>>> >>>>>> should be >>>>>>> >>>>>>> the blocking or non-blocking of outgoing data traffic. >>>> >>>> Similarly it >>>>>>> >>>>>>> may be useful to configure whether the "Period >>>>>> >>>>>> Misconfiguration defect" >>>>>>> >>>>>>> should result in a signal fail condition or not. >>>>>>> >>>>>>> >>>>>>> I plan to send detailed text to the editors of >>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the >>>>>>> lines >>>>>>> described above. Please comment! >>>>>>> Thanks, >>>>>>> Attila >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> Loa Andersson email: loa.andersson@ericsson.com >>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>>> +46 767 72 92 13 >>>> >>>> -- >>>> >>>> >>>> Loa Andersson email: loa.andersson@ericsson.com >>>> Sr Strategy and Standards Manager loa@pi.nu >>>> Ericsson Inc phone: +46 10 717 52 13 >>>> +46 767 72 92 13 >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >> >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > From db3546@att.com Thu Dec 3 10:47:03 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A739B3A6949 for ; Thu, 3 Dec 2009 10:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.296 X-Spam-Level: X-Spam-Status: No, score=-106.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Deo8p8MUdTsa for ; Thu, 3 Dec 2009 10:47:02 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 51E5D3A6939 for ; Thu, 3 Dec 2009 10:47:00 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-7.tower-167.messagelabs.com!1259866010!20893730!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 6006 invoked from network); 3 Dec 2009 18:46:51 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Dec 2009 18:46:51 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nB3IkmUB000939 for ; Thu, 3 Dec 2009 13:46:48 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nB3IkgYJ000897 for ; Thu, 3 Dec 2009 13:46:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Dec 2009 13:46:43 -0500 Message-ID: In-Reply-To: <4B170AF8.1080900@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group last call:draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: Acpzsm5FRdsP8BT7SKWJ2mH2XDBUsgAko0xA References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net> <4B170AF8.1080900@grotto-networking.com> From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "Greg Bernstein" , "Sadler, Jonathan B." Cc: CCAMP Subject: Re: [CCAMP] Working group last call:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 18:47:03 -0000 Hi all, As Greg notes, this draft has been stable for a long time, it has a dependency on the MLN-ext work and it was waiting for it to complete. We did consider (and respond to) OIF on their requirements, including: https://ops.ietf.org/lists/ccamp/ccamp.2008/msg00741.html I'm not sure, myself, Jonathan (and Evelyne) on your concerns, I'll send a separate mail (with my chair hat off) to try to understand. Deborah=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein Sent: Wednesday, December 02, 2009 7:49 PM To: Sadler, Jonathan B. Cc: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org Subject: Re: [CCAMP] Working group last call:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi folks, this draft has been very stable for a very long time. The last major revision was to put in some advanced features requested=20 by Jonathan and Evelyn. Adrian and I worked out a solution to providing=20 those features over two years ago. I don't work on MPLS-TP and didn't=20 know that this was a topic covered by that. Is it? I haven't seen any specific textual changes requested just vague=20 assertions that this draft cannot do everything and anything somebody=20 could think of. VCAT/LCAS is a fairly general technique applying to PDH, SDH, and G.709=20 technologies. This draft was intended to cover those and was approved as a working group document over four years ago. Unless there is something=20 specifically technically wrong I'm not sure that we need to start all=20 over again with this. Regards GB Sadler, Jonathan B. wrote: > Hi all, > > As mentioned in the CCAMP working group meeting, this draft has a dependency on a control plane operating in the STS-n/VC-n environment, and that control plane carrying the CALL information used for configuring the VCAT group. > > Given carrier requirements to not extend a carrier's control plane to the customer premise (e.g. draft-jenkins-mpls-tp-bt-requirements-00, and the carrier requirements document liaised by the OIF), this dependency is not acceptable. Instead, a mechanism needs to exist where the STS-n connections can be named and signaled for incorporation into a VCAT group independent of the out-of-band network or process used to setup the STS-n/VC-n connections. > > Hence, further work on this draft is needed before it can progress. > > Jonathan Sadler > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Friday, November 20, 2009 2:25 PM > To: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org > Subject: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 > > As discussed in last week's session, it's time for the working group to=20 > last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas > > Please send your comments to the list or the authors&chairs > before the last call closes in two weeks, on December 4, 2009. > > Thank you, > Lou (and Deborah) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From neil.2.harrison@bt.com Thu Dec 3 11:10:26 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC883A68B8; Thu, 3 Dec 2009 11:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.031 X-Spam-Level: X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 8DvWTvmBrCBX; Thu, 3 Dec 2009 11:10:25 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 983953A65A5; Thu, 3 Dec 2009 11:10:24 -0800 (PST) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 19:10:15 +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 Date: Thu, 3 Dec 2009 19:10:13 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C05636176@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <3F0E9049-4EDC-4E86-934C-9D5673FE11AF@lucidvision.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] [CCAMP] Thoughts on updating the OAM Configurationfwk and the MPLS-TP OAM configuration drafts Thread-Index: Acp0RG2vpZxKPuBQR1+TW8M0HuBw/gAB8xwQ From: To: , X-OriginalArrivalTime: 03 Dec 2009 19:10:15.0419 (UTC) FILETIME=[3ED874B0:01CA744C] Cc: ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] Thoughts on updating the OAM Configurationfwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 19:10:26 -0000 =20 Hi Tom....this is why it is always a good idea for a co mode network to take its CP/MP logically OOB wrt to the traffic DP....a forced action for the co-cs mode, but requires a conscious design decision in the co-ps mode. regards, Neil =20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Thomas Nadeau > Sent: 03 December 2009 18:14 > To: Andrew G. Malis > Cc: ccamp@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] [CCAMP] Thoughts on updating the OAM=20 > Configurationfwk and the MPLS-TP OAM configuration drafts >=20 > Has anyone thought about security ramifications of allowing this? >=20 >=20 > On Dec 3, 2009, at 12:28 PM, "Andrew G. Malis" > wrote: >=20 > > +1 > > > > Cheers, > > Andy > > > > On Thu, Dec 3, 2009 at 6:20 PM, Loa Andersson wrote: > >> Attila, > >> > >> if we agree on this the we also have a method to easily=20 > reconfigure=20 > >> OAM on already set up LSPs, simple send a refresh PATH or RESV. > >> > >> What do people think is this a good idea? > >> > >> /Loa > >> > >> Attila Takacs wrote: > >>> > >>> Hi Loa, > >>>> > >>>> OK great, then we need to update that in the framework. > >>>> > >>> Ok, I will do so. > >>> > >>>> I also have a question on the relationship between flags and the=20 > >>>> sub-tlvs. > >>>> > >>>> I think there are four possibilities: > >>>> > >>>> 1. A flag is set, but there is no sub-tlv > >>>> - the action here should be to turn on the function the > >>>> flag indicates using default values > >>>> I also think that if a function indicated by flag is > >>>> running, it should be left unchanged, even if it is not > >>>> running on default values > >>>> > >>>> 2. A flag is set, and there is a sub-tlv > >>>> - the action here would be to turn on the function=20 > indicated by > >>>> the flag, using the parameters found in sub-tlv > >>>> > >>>> 3. A flag is not set, and there is no sub-tlv > >>>> - the action here would be to turn off any function that has > >>>> been configured earlier > >>>> > >>>> 4. A flag is not set, but there is sub-tlv > >>>> - this should be treated as an error conditions and an > >>>> error message should be returned, no changes to the=20 > >>>> configured > >>>> OAM should be made. > >>>> > >>>> Is this correctly understood? > >>> > >>> Yes. I will check is this need clarification in the fwk. > >>> > >>> Attila > >>> > >>>> /Loa > >>>> > >>>> Attila Takacs wrote: > >>>>> > >>>>> Hi Loa, > >>>>> > >>>>> It can be carried in the LSP_ATTRIBUTES Object in the Resv > >>>> > >>>> message; so it can be used for timer negotiation and=20 > discriminator=20 > >>>> synchronization if needed. > >>>>> > >>>>> Attila > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Loa Andersson [mailto:loa@pi.nu] > >>>>>> Sent: Wednesday, December 02, 2009 3:59 PM > >>>>>> To: Attila Takacs > >>>>>> Cc: ccamp@ietf.org; mpls-tp@ietf.org > >>>>>> Subject: Re: [CCAMP] Thoughts on updating the OAM > >>>> > >>>> Configuration fwk > >>>>>> > >>>>>> and the MPLS-TP OAM configuration drafts > >>>>>> > >>>>>> Attila, > >>>>>> > >>>>>> thanks - I think things are converging quite a bit now. > >>>>>> > >>>>>> May the OAM Configuration TLV specified in the OAM=20 > Configuration=20 > >>>>>> Framweork only be present in the PATH message? > >>>>>> > >>>>>> /Loa > >>>>>> > >>>>>> Attila Takacs wrote: > >>>>>>> > >>>>>>> Hi all, > >>>>>>> > >>>>>>> Some thoughts on updating the OAM Configuration fwk and > >>>> > >>>> the MPLS-TP > >>>>>>> > >>>>>>> OAM configuration drafts. > >>>>>>> > >>>>>>> I think we need to extend the OAM Function flags (described in > >>>>>>> draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: > >>>>>>> > >>>>>>> -CC > >>>>>>> -CV > >>>>>>> -PM Loss > >>>>>>> -PM Delay > >>>>>>> -Fault Management signals > >>>>>>> > >>>>>>> > >>>>>>> With regards to BFD I see three operation vs. configuration > >>>>>>> modes: > >>>>>>> > >>>>>>> 1) Set CC in the flags and only bootstrap the BFD session, > >>>>>> > >>>>>> by sending > >>>>>>> > >>>>>>> the local discriminator values in RSVP-TE and leave timer > >>>>>> > >>>>>> negotiation > >>>>>>> > >>>>>>> to BFD control messages. This is similar to LSP Ping based=20 > >>>>>>> bootstrapping described in draft-ietf-bfd-mpls-07.txt. > >>>>>>> > >>>>>>> 2) Set CC in the flags but configure the timers via the > >>>>>> > >>>>>> control plane, > >>>>>>> > >>>>>>> this should correspond to "CC mode" in > >>>>>> > >>>>>> draft-asm-mpls-tp-bfd-cc-cv-01. > >>>>>>> > >>>>>>> We may include the min/max intervals and by doing so > >>>>>> > >>>>>> support initial > >>>>>>> > >>>>>>> timer negotiation in control plane. However, we may need a > >>>>>> > >>>>>> flag in CC > >>>>>>> > >>>>>>> configuration sub-TLV (now in > >>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called > >>>>>> > >>>>>> "Suggested TX > >>>>>>> > >>>>>>> Interval sub-TLV") to indicate whether data plane timer > >>>>>> > >>>>>> renegotiation > >>>>>>> > >>>>>>> is enabled or disabled (i.e., subsequently via BFD control > >>>>>> > >>>>>> messages). > >>>>>>> > >>>>>>> This, as described in draft-asm-mpls-tp-bfd-cc-cv-01,=20 > should be=20 > >>>>>>> disabled for TP LSPs by default. > >>>>>>> > >>>>>>> 3) In case of "full" MPLS-TP OAM support any of the flags > >>>>>> > >>>>>> could be set > >>>>>>> > >>>>>>> as needed, reflecting "CV/CC mode" described in=20 > >>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as=20 > >>>>>>> described in draft-frost-mpls-tp-loss-delay-00 and > >>>>>> > >>>>>> management signals > >>>>>>> > >>>>>>> as given in draft-sfv-mpls-tp-fault-00. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> To configure CC we will need to add -enable/disable DP timer=20 > >>>>>>> re-negotiation -PHB to identify > >>>>>> > >>>>>> priority and > >>>>>>> > >>>>>>> drop precedence of CC packets > >>>>>>> > >>>>>>> When it comes to CV, it would be interesting to discuss > >>>>>> > >>>>>> whether only > >>>>>>> > >>>>>>> the OAM identifiers described in > >>>>>> > >>>>>> draft-ietf-mpls-tp-identifiers-00 are > >>>>>>> > >>>>>>> ought to be supported. If so, those could be derived=20 > from RSVP-=20 > >>>>>>> TE signaling without the need to carry them explicitly in > >>>> > >>>> MPLS-TP OAM > >>>>>>> > >>>>>>> Configuration sub-TLVs (now called Source unique MEP_ID > >>>> > >>>> sub-TLV in > >>>>>>> > >>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). > >>>>>>> > >>>>>>> For Performance Monitoring Loss/Delay we need to add=20 > new TLVs,=20 > >>>>>>> carrying -measurement interval -possibly loss/delay bound > >>>>>> > >>>>>> thresholds > >>>>>>> > >>>>>>> (given we what these for MPLS-TP) that could be used to > >>>> > >>>> assess the > >>>>>>> > >>>>>>> quality of the connection and may eventually trigger > >>>>>> > >>>>>> protection -PHB > >>>>>>> > >>>>>>> of control packets if we want to set it differently from CC > >>>>>> > >>>>>> packets or > >>>>>>> > >>>>>>> from data traffic. > >>>>>>> > >>>>>>> For the Fault Management Signals, I would add a new "Fault > >>>>>> > >>>>>> Management > >>>>>>> > >>>>>>> Signals sub-TLV" carrying: > >>>>>>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except > >>>> > >>>> CFS, are > >>>>>>> > >>>>>>> specified in draft-sfv-mpls-tp-fault-00) -refresh=20 > timer of fault=20 > >>>>>>> indication messages -flag to enable/disable explicitly > >>>>>> > >>>>>> clear of faults > >>>>>>> > >>>>>>> -PHB of fault management packets > >>>>>>> > >>>>>>> > >>>>>>> Another thing we may want to consider is adding a=20 > sub-TLV to set=20 > >>>>>>> consequent actions that are configurable. This is > >>>> > >>>> described to some > >>>>>>> > >>>>>>> extent in the MPLS-TP OAM Framework. The defects > >>>> > >>>> identified include: > >>>>>>> > >>>>>>> Loss Of Continuity defect, Mis-connectivity defect, MEP=20 > >>>>>>> misconfiguration defect, Period Misconfiguration defect. > >>>>>>> > >>>>>>> An operator may want to configure if the consequence of LOC > >>>>>> > >>>>>> should be > >>>>>>> > >>>>>>> the blocking or non-blocking of outgoing data traffic. > >>>> > >>>> Similarly it > >>>>>>> > >>>>>>> may be useful to configure whether the "Period > >>>>>> > >>>>>> Misconfiguration defect" > >>>>>>> > >>>>>>> should result in a signal fail condition or not. > >>>>>>> > >>>>>>> > >>>>>>> I plan to send detailed text to the editors of > >>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the=20 > >>>>>>> lines described above. Please comment! > >>>>>>> Thanks, > >>>>>>> Attila > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> CCAMP mailing list > >>>>>>> CCAMP@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> > >>>>>> Loa Andersson email:=20 > loa.andersson@ericsson.com > >>>>>> Sr Strategy and Standards Manager loa@pi.nu > >>>>>> Ericsson Inc phone: +46 10 717 52 13 > >>>>>> +46 767 72 92 13 > >>>> > >>>> -- > >>>> > >>>> > >>>> Loa Andersson email:=20 > loa.andersson@ericsson.com > >>>> Sr Strategy and Standards Manager loa@pi.nu > >>>> Ericsson Inc phone: +46 10 717 52 13 > >>>> +46 767 72 92 13=20 > >>>> _______________________________________________ > >>>> CCAMP mailing list > >>>> CCAMP@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ccamp > >> > >> -- > >> > >> > >> Loa Andersson email:=20 > loa.andersson@ericsson.com > >> Sr Strategy and Standards Manager loa@pi.nu > >> Ericsson Inc phone: +46 10 717 52 13 > >> +46 767 72 92 13=20 > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > >> > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 From db3546@att.com Thu Dec 3 11:26:05 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A67D28C168 for ; Thu, 3 Dec 2009 11:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.33 X-Spam-Level: X-Spam-Status: No, score=-106.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 hT+NFd5qOm1e for ; Thu, 3 Dec 2009 11:26:04 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 8F01B28C0F8 for ; Thu, 3 Dec 2009 11:26:04 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-8.tower-146.messagelabs.com!1259868351!15256630!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 15514 invoked from network); 3 Dec 2009 19:25:52 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Dec 2009 19:25:52 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nB3JPqab027732; Thu, 3 Dec 2009 14:25:52 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nB3JPoEF027721; Thu, 3 Dec 2009 14:25:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Dec 2009 14:25:52 -0500 Message-ID: In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: AcpqH2ryjNr5gUbmTN+LuGhTuQZF0wJflMJwACsHDaA= References: <4B06FB22.8090301@labn.net> <5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net> From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "Sadler, Jonathan B." , "Lou Berger" , "CCAMP" , Subject: Re: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 19:26:05 -0000 (my chair hat off) Jonathan, As the independent scenario for supporting pre-establishment of server layer connections was already added to the document (section 4.5.2) and as you are saying a customer premise, you are concerned on the UNI scenario when the CE has the VCAT functionality? Deborah -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Sadler, Jonathan B. Sent: Wednesday, December 02, 2009 5:47 PM To: Lou Berger; CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org Subject: Re: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi all, As mentioned in the CCAMP working group meeting, this draft has a dependency on a control plane operating in the STS-n/VC-n environment, and that control plane carrying the CALL information used for configuring the VCAT group. Given carrier requirements to not extend a carrier's control plane to the customer premise (e.g. draft-jenkins-mpls-tp-bt-requirements-00, and the carrier requirements document liaised by the OIF), this dependency is not acceptable. Instead, a mechanism needs to exist where the STS-n connections can be named and signaled for incorporation into a VCAT group independent of the out-of-band network or process used to setup the STS-n/VC-n connections. Hence, further work on this draft is needed before it can progress. Jonathan Sadler -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Friday, November 20, 2009 2:25 PM To: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org Subject: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 As discussed in last week's session, it's time for the working group to=20 last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas Please send your comments to the list or the authors&chairs before the last call closes in two weeks, on December 4, 2009. Thank you, Lou (and Deborah) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From tnadeau@lucidvision.com Thu Dec 3 11:47:35 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8DE3A691E; Thu, 3 Dec 2009 11:47:35 -0800 (PST) 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 vFbM1Xi+Eqnj; Thu, 3 Dec 2009 11:47:34 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 066F53A68C2; Thu, 3 Dec 2009 11:47:34 -0800 (PST) Received: from [192.168.1.120] (unknown [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 99482421480B; Thu, 3 Dec 2009 14:47:25 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C05636176@E03MVB2-UKBR.domain1.systemhost.net> Date: Thu, 3 Dec 2009 14:47:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <501F19F3-92D5-4AB3-A9CD-10DFBF568A96@lucidvision.com> References: <2ECAA42C79676B42AEBAC11229CA7D0C05636176@E03MVB2-UKBR.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1077) Cc: ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] Thoughts on updating the OAM Configurationfwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 19:47:35 -0000 That still doesn't answer my question. *) Has anyone thought = about unapproved RSVP messages being send to modify/deactivate/activate = LSPs in this model described here? =20 --Tom On Dec 3, 2009, at 2:10 PM, wrote: >=20 > Hi Tom....this is why it is always a good idea for a co mode network = to > take its CP/MP logically OOB wrt to the traffic DP....a forced action > for the co-cs mode, but requires a conscious design decision in the > co-ps mode. >=20 > regards, Neil =20 >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org=20 >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Thomas Nadeau >> Sent: 03 December 2009 18:14 >> To: Andrew G. Malis >> Cc: ccamp@ietf.org; mpls-tp@ietf.org >> Subject: Re: [mpls-tp] [CCAMP] Thoughts on updating the OAM=20 >> Configurationfwk and the MPLS-TP OAM configuration drafts >>=20 >> Has anyone thought about security ramifications of allowing this? >>=20 >>=20 >> On Dec 3, 2009, at 12:28 PM, "Andrew G. Malis" >> wrote: >>=20 >>> +1 >>>=20 >>> Cheers, >>> Andy >>>=20 >>> On Thu, Dec 3, 2009 at 6:20 PM, Loa Andersson wrote: >>>> Attila, >>>>=20 >>>> if we agree on this the we also have a method to easily=20 >> reconfigure=20 >>>> OAM on already set up LSPs, simple send a refresh PATH or RESV. >>>>=20 >>>> What do people think is this a good idea? >>>>=20 >>>> /Loa >>>>=20 >>>> Attila Takacs wrote: >>>>>=20 >>>>> Hi Loa, >>>>>>=20 >>>>>> OK great, then we need to update that in the framework. >>>>>>=20 >>>>> Ok, I will do so. >>>>>=20 >>>>>> I also have a question on the relationship between flags and the=20= >>>>>> sub-tlvs. >>>>>>=20 >>>>>> I think there are four possibilities: >>>>>>=20 >>>>>> 1. A flag is set, but there is no sub-tlv >>>>>> - the action here should be to turn on the function the >>>>>> flag indicates using default values >>>>>> I also think that if a function indicated by flag is >>>>>> running, it should be left unchanged, even if it is not >>>>>> running on default values >>>>>>=20 >>>>>> 2. A flag is set, and there is a sub-tlv >>>>>> - the action here would be to turn on the function=20 >> indicated by >>>>>> the flag, using the parameters found in sub-tlv >>>>>>=20 >>>>>> 3. A flag is not set, and there is no sub-tlv >>>>>> - the action here would be to turn off any function that has >>>>>> been configured earlier >>>>>>=20 >>>>>> 4. A flag is not set, but there is sub-tlv >>>>>> - this should be treated as an error conditions and an >>>>>> error message should be returned, no changes to the=20 >>>>>> configured >>>>>> OAM should be made. >>>>>>=20 >>>>>> Is this correctly understood? >>>>>=20 >>>>> Yes. I will check is this need clarification in the fwk. >>>>>=20 >>>>> Attila >>>>>=20 >>>>>> /Loa >>>>>>=20 >>>>>> Attila Takacs wrote: >>>>>>>=20 >>>>>>> Hi Loa, >>>>>>>=20 >>>>>>> It can be carried in the LSP_ATTRIBUTES Object in the Resv >>>>>>=20 >>>>>> message; so it can be used for timer negotiation and=20 >> discriminator=20 >>>>>> synchronization if needed. >>>>>>>=20 >>>>>>> Attila >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Loa Andersson [mailto:loa@pi.nu] >>>>>>>> Sent: Wednesday, December 02, 2009 3:59 PM >>>>>>>> To: Attila Takacs >>>>>>>> Cc: ccamp@ietf.org; mpls-tp@ietf.org >>>>>>>> Subject: Re: [CCAMP] Thoughts on updating the OAM >>>>>>=20 >>>>>> Configuration fwk >>>>>>>>=20 >>>>>>>> and the MPLS-TP OAM configuration drafts >>>>>>>>=20 >>>>>>>> Attila, >>>>>>>>=20 >>>>>>>> thanks - I think things are converging quite a bit now. >>>>>>>>=20 >>>>>>>> May the OAM Configuration TLV specified in the OAM=20 >> Configuration=20 >>>>>>>> Framweork only be present in the PATH message? >>>>>>>>=20 >>>>>>>> /Loa >>>>>>>>=20 >>>>>>>> Attila Takacs wrote: >>>>>>>>>=20 >>>>>>>>> Hi all, >>>>>>>>>=20 >>>>>>>>> Some thoughts on updating the OAM Configuration fwk and >>>>>>=20 >>>>>> the MPLS-TP >>>>>>>>>=20 >>>>>>>>> OAM configuration drafts. >>>>>>>>>=20 >>>>>>>>> I think we need to extend the OAM Function flags (described in >>>>>>>>> draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: >>>>>>>>>=20 >>>>>>>>> -CC >>>>>>>>> -CV >>>>>>>>> -PM Loss >>>>>>>>> -PM Delay >>>>>>>>> -Fault Management signals >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> With regards to BFD I see three operation vs. configuration >>>>>>>>> modes: >>>>>>>>>=20 >>>>>>>>> 1) Set CC in the flags and only bootstrap the BFD session, >>>>>>>>=20 >>>>>>>> by sending >>>>>>>>>=20 >>>>>>>>> the local discriminator values in RSVP-TE and leave timer >>>>>>>>=20 >>>>>>>> negotiation >>>>>>>>>=20 >>>>>>>>> to BFD control messages. This is similar to LSP Ping based=20 >>>>>>>>> bootstrapping described in draft-ietf-bfd-mpls-07.txt. >>>>>>>>>=20 >>>>>>>>> 2) Set CC in the flags but configure the timers via the >>>>>>>>=20 >>>>>>>> control plane, >>>>>>>>>=20 >>>>>>>>> this should correspond to "CC mode" in >>>>>>>>=20 >>>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01. >>>>>>>>>=20 >>>>>>>>> We may include the min/max intervals and by doing so >>>>>>>>=20 >>>>>>>> support initial >>>>>>>>>=20 >>>>>>>>> timer negotiation in control plane. However, we may need a >>>>>>>>=20 >>>>>>>> flag in CC >>>>>>>>>=20 >>>>>>>>> configuration sub-TLV (now in >>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called >>>>>>>>=20 >>>>>>>> "Suggested TX >>>>>>>>>=20 >>>>>>>>> Interval sub-TLV") to indicate whether data plane timer >>>>>>>>=20 >>>>>>>> renegotiation >>>>>>>>>=20 >>>>>>>>> is enabled or disabled (i.e., subsequently via BFD control >>>>>>>>=20 >>>>>>>> messages). >>>>>>>>>=20 >>>>>>>>> This, as described in draft-asm-mpls-tp-bfd-cc-cv-01,=20 >> should be=20 >>>>>>>>> disabled for TP LSPs by default. >>>>>>>>>=20 >>>>>>>>> 3) In case of "full" MPLS-TP OAM support any of the flags >>>>>>>>=20 >>>>>>>> could be set >>>>>>>>>=20 >>>>>>>>> as needed, reflecting "CV/CC mode" described in=20 >>>>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as=20= >>>>>>>>> described in draft-frost-mpls-tp-loss-delay-00 and >>>>>>>>=20 >>>>>>>> management signals >>>>>>>>>=20 >>>>>>>>> as given in draft-sfv-mpls-tp-fault-00. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> To configure CC we will need to add -enable/disable DP timer=20= >>>>>>>>> re-negotiation -PHB to identify >>>>>>>>=20 >>>>>>>> priority and >>>>>>>>>=20 >>>>>>>>> drop precedence of CC packets >>>>>>>>>=20 >>>>>>>>> When it comes to CV, it would be interesting to discuss >>>>>>>>=20 >>>>>>>> whether only >>>>>>>>>=20 >>>>>>>>> the OAM identifiers described in >>>>>>>>=20 >>>>>>>> draft-ietf-mpls-tp-identifiers-00 are >>>>>>>>>=20 >>>>>>>>> ought to be supported. If so, those could be derived=20 >> from RSVP-=20 >>>>>>>>> TE signaling without the need to carry them explicitly in >>>>>>=20 >>>>>> MPLS-TP OAM >>>>>>>>>=20 >>>>>>>>> Configuration sub-TLVs (now called Source unique MEP_ID >>>>>>=20 >>>>>> sub-TLV in >>>>>>>>>=20 >>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). >>>>>>>>>=20 >>>>>>>>> For Performance Monitoring Loss/Delay we need to add=20 >> new TLVs,=20 >>>>>>>>> carrying -measurement interval -possibly loss/delay bound >>>>>>>>=20 >>>>>>>> thresholds >>>>>>>>>=20 >>>>>>>>> (given we what these for MPLS-TP) that could be used to >>>>>>=20 >>>>>> assess the >>>>>>>>>=20 >>>>>>>>> quality of the connection and may eventually trigger >>>>>>>>=20 >>>>>>>> protection -PHB >>>>>>>>>=20 >>>>>>>>> of control packets if we want to set it differently from CC >>>>>>>>=20 >>>>>>>> packets or >>>>>>>>>=20 >>>>>>>>> from data traffic. >>>>>>>>>=20 >>>>>>>>> For the Fault Management Signals, I would add a new "Fault >>>>>>>>=20 >>>>>>>> Management >>>>>>>>>=20 >>>>>>>>> Signals sub-TLV" carrying: >>>>>>>>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except >>>>>>=20 >>>>>> CFS, are >>>>>>>>>=20 >>>>>>>>> specified in draft-sfv-mpls-tp-fault-00) -refresh=20 >> timer of fault=20 >>>>>>>>> indication messages -flag to enable/disable explicitly >>>>>>>>=20 >>>>>>>> clear of faults >>>>>>>>>=20 >>>>>>>>> -PHB of fault management packets >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Another thing we may want to consider is adding a=20 >> sub-TLV to set=20 >>>>>>>>> consequent actions that are configurable. This is >>>>>>=20 >>>>>> described to some >>>>>>>>>=20 >>>>>>>>> extent in the MPLS-TP OAM Framework. The defects >>>>>>=20 >>>>>> identified include: >>>>>>>>>=20 >>>>>>>>> Loss Of Continuity defect, Mis-connectivity defect, MEP=20 >>>>>>>>> misconfiguration defect, Period Misconfiguration defect. >>>>>>>>>=20 >>>>>>>>> An operator may want to configure if the consequence of LOC >>>>>>>>=20 >>>>>>>> should be >>>>>>>>>=20 >>>>>>>>> the blocking or non-blocking of outgoing data traffic. >>>>>>=20 >>>>>> Similarly it >>>>>>>>>=20 >>>>>>>>> may be useful to configure whether the "Period >>>>>>>>=20 >>>>>>>> Misconfiguration defect" >>>>>>>>>=20 >>>>>>>>> should result in a signal fail condition or not. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I plan to send detailed text to the editors of >>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the=20 >>>>>>>>> lines described above. Please comment! >>>>>>>>> Thanks, >>>>>>>>> Attila >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> CCAMP mailing list >>>>>>>>> CCAMP@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>>=20 >>>>>>>> -- >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Loa Andersson email:=20 >> loa.andersson@ericsson.com >>>>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>>>>> +46 767 72 92 13 >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>>=20 >>>>>> Loa Andersson email:=20 >> loa.andersson@ericsson.com >>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>>> +46 767 72 92 13=20 >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>=20 >>>> -- >>>>=20 >>>>=20 >>>> Loa Andersson email:=20 >> loa.andersson@ericsson.com >>>> Sr Strategy and Standards Manager loa@pi.nu >>>> Ericsson Inc phone: +46 10 717 52 13 >>>> +46 767 72 92 13=20 >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>=20 >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>=20 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >>=20 >=20 From EROCH@nortel.com Thu Dec 3 12:35:20 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094003A62C1 for ; Thu, 3 Dec 2009 12:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 TFZXZfJ5a9JS for ; Thu, 3 Dec 2009 12:35:19 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B117F3A6977 for ; Thu, 3 Dec 2009 12:35:18 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nB3KYxF26363; Thu, 3 Dec 2009 20:35:00 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 Date: Thu, 3 Dec 2009 15:34:15 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A029F3816@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: Acpzsm5FRdsP8BT7SKWJ2mH2XDBUsgAko0xAAAS8QCA= References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com> From: "Evelyne Roch" To: "BRUNGARD, DEBORAH A (ATTLABS)" , "Greg Bernstein" , "Sadler, Jonathan B." Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 20:35:20 -0000 Deborah, In the link you included referring to the correspondence sent to OIF, the following requirements are worth discussing further as the draft doesn't address them adequately: - Clean separation of VCG (VCAT Group) control from the control of VCG members - Supports the ability to create and modify the VCG independent of its members=20 To me, these requirements imply that the call control for VCAT group and VCG members is independent. In other words, a VCAT call exists independently from a VCG member call. This method was mentioned in a previous message http://www.ietf.org/mail-archive/web/ccamp/current/msg09711.html.=20 Evelyne=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Thursday, December 03, 2009 1:47 PM To: Greg Bernstein; Sadler, Jonathan B. Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi all, As Greg notes, this draft has been stable for a long time, it has a dependency on the MLN-ext work and it was waiting for it to complete. We did consider (and respond to) OIF on their requirements, including: https://ops.ietf.org/lists/ccamp/ccamp.2008/msg00741.html I'm not sure, myself, Jonathan (and Evelyne) on your concerns, I'll send a separate mail (with my chair hat off) to try to understand. Deborah=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein Sent: Wednesday, December 02, 2009 7:49 PM To: Sadler, Jonathan B. Cc: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org Subject: Re: [CCAMP] Working group last call:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi folks, this draft has been very stable for a very long time. The last major revision was to put in some advanced features requested by Jonathan and Evelyn. Adrian and I worked out a solution to providing those features over two years ago. I don't work on MPLS-TP and didn't know that this was a topic covered by that. Is it? I haven't seen any specific textual changes requested just vague assertions that this draft cannot do everything and anything somebody could think of. VCAT/LCAS is a fairly general technique applying to PDH, SDH, and G.709 technologies. This draft was intended to cover those and was approved as a working group document over four years ago. Unless there is something specifically technically wrong I'm not sure that we need to start all over again with this. Regards GB Sadler, Jonathan B. wrote: > Hi all, > > As mentioned in the CCAMP working group meeting, this draft has a dependency on a control plane operating in the STS-n/VC-n environment, and that control plane carrying the CALL information used for configuring the VCAT group. > > Given carrier requirements to not extend a carrier's control plane to the customer premise (e.g. draft-jenkins-mpls-tp-bt-requirements-00, and the carrier requirements document liaised by the OIF), this dependency is not acceptable. Instead, a mechanism needs to exist where the STS-n connections can be named and signaled for incorporation into a VCAT group independent of the out-of-band network or process used to setup the STS-n/VC-n connections. > > Hence, further work on this draft is needed before it can progress. > > Jonathan Sadler > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Friday, November 20, 2009 2:25 PM > To: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org > Subject: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 > > As discussed in last week's session, it's time for the working group to=20 > last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas > > Please send your comments to the list or the authors&chairs before the > last call closes in two weeks, on December 4, 2009. > > Thank you, > Lou (and Deborah) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > =20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From db3546@att.com Thu Dec 3 13:50:42 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 842AA3A6A3B for ; Thu, 3 Dec 2009 13:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.357 X-Spam-Level: X-Spam-Status: No, score=-106.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 a6rw+-E2wpA1 for ; Thu, 3 Dec 2009 13:50:40 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id C37093A62C1 for ; Thu, 3 Dec 2009 13:50:40 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-11.tower-161.messagelabs.com!1259877030!6949788!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 2080 invoked from network); 3 Dec 2009 21:50:31 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Dec 2009 21:50:31 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nB3LoRal026506 for ; Thu, 3 Dec 2009 16:50:27 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nB3LoOBk026495 for ; Thu, 3 Dec 2009 16:50:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Dec 2009 16:50:25 -0500 Message-ID: In-Reply-To: <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: Acpzsm5FRdsP8BT7SKWJ2mH2XDBUsgAko0xAAAHUDkAAA2T/0A== References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com> From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "Evelyne Roch" Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 21:50:42 -0000 Hi Evelyne, There may be confusion between the previous GMPLS support of VCAT and this document version. This document added procedures to support this independence (section 4.2-4.5) - this is why the VCG call layer was added. Section 4.5 provides procedures for different scenarios of independence with the VCAT call and the LSPs. As Greg noted, there was an effort to respond on the mail exchange and include clarifications in the document (e.g. section 4.5). Can you describe your remaining concern wrt to the draft - clarifications for section 4.2/missing scenario in 4.5/etc.? Deborah (chair hat on) -----Original Message----- From: Evelyne Roch [mailto:eroch@nortel.com]=20 Sent: Thursday, December 03, 2009 3:19 PM To: BRUNGARD, DEBORAH A (ATTLABS) Subject: RE: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Deborah, In the link you included referring to the correspondence sent to OIF, the following requirements are worth discussing further as the draft doesn't address them adequately: - Clean separation of VCG (VCAT Group) control from the control of VCG members - Supports the ability to create and modify the VCG independent of its members=20 To me, these requirements imply that the call control for VCAT group and VCG members is independent. In other words, a VCAT call exists independently from a VCG member call. This method was mentioned in a previous message http://www.ietf.org/mail-archive/web/ccamp/current/msg09711.html.=20 Evelyne -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Thursday, December 03, 2009 1:47 PM To: Greg Bernstein; Sadler, Jonathan B. Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi all, As Greg notes, this draft has been stable for a long time, it has a dependency on the MLN-ext work and it was waiting for it to complete. We did consider (and respond to) OIF on their requirements, including: https://ops.ietf.org/lists/ccamp/ccamp.2008/msg00741.html I'm not sure, myself, Jonathan (and Evelyne) on your concerns, I'll send a separate mail (with my chair hat off) to try to understand. Deborah=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein Sent: Wednesday, December 02, 2009 7:49 PM To: Sadler, Jonathan B. Cc: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org Subject: Re: [CCAMP] Working group last call:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi folks, this draft has been very stable for a very long time. The last major revision was to put in some advanced features requested by Jonathan and Evelyn. Adrian and I worked out a solution to providing those features over two years ago. I don't work on MPLS-TP and didn't know that this was a topic covered by that. Is it? I haven't seen any specific textual changes requested just vague assertions that this draft cannot do everything and anything somebody could think of. VCAT/LCAS is a fairly general technique applying to PDH, SDH, and G.709 technologies. This draft was intended to cover those and was approved as a working group document over four years ago. Unless there is something specifically technically wrong I'm not sure that we need to start all over again with this. Regards GB Sadler, Jonathan B. wrote: > Hi all, > > As mentioned in the CCAMP working group meeting, this draft has a dependency on a control plane operating in the STS-n/VC-n environment, and that control plane carrying the CALL information used for configuring the VCAT group. > > Given carrier requirements to not extend a carrier's control plane to the customer premise (e.g. draft-jenkins-mpls-tp-bt-requirements-00, and the carrier requirements document liaised by the OIF), this dependency is not acceptable. Instead, a mechanism needs to exist where the STS-n connections can be named and signaled for incorporation into a VCAT group independent of the out-of-band network or process used to setup the STS-n/VC-n connections. > > Hence, further work on this draft is needed before it can progress. > > Jonathan Sadler > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Friday, November 20, 2009 2:25 PM > To: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org > Subject: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 > > As discussed in last week's session, it's time for the working group to=20 > last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas > > Please send your comments to the list or the authors&chairs before the > last call closes in two weeks, on December 4, 2009. > > Thank you, > Lou (and Deborah) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > =20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From zhang.fei3@zte.com.cn Thu Dec 3 22:08:10 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28F733A69BB for ; Thu, 3 Dec 2009 22:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 ABsghnBYvt0H for ; Thu, 3 Dec 2009 22:08:09 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id E74533A681E for ; Thu, 3 Dec 2009 22:08:08 -0800 (PST) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 9110473195744; Fri, 4 Dec 2009 13:45:22 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 89005.1464720505; Fri, 4 Dec 2009 14:07:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id nB467w1h052381; Fri, 4 Dec 2009 14:07:58 +0800 (CST) (envelope-from zhang.fei3@zte.com.cn) To: "Young Lee" , MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 4 Dec 2009 14:07:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-12-04 14:07:49, Serialize complete at 2009-12-04 14:07:49 Content-Type: multipart/alternative; boundary="=_alternative 0022251948257682_=" X-MAIL: mse2.zte.com.cn nB467w1h052381 Subject: Re: [CCAMP] poll on makingdraft-lee-ccamp-wson-signal-compatibility-ospf-00.txt ccamp wg document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 06:08:10 -0000 This is a multipart message in MIME format. --=_alternative 0022251948257682_= Content-Type: text/plain; charset="US-ASCII" Yes/Support Fei -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Monday, November 23, 2009 4:20 PM To: ccamp@ietf.org Subject: [CCAMP] poll on makingdraft-lee-ccamp-wson-signal-compatibility-ospf-00.txt ccamp wg document All, This is to start a two week poll on making draft-lee-ccamp-wson-signal-compatibility-ospf-00.txt a ccamp working group document. Send a mail to the mailing list indicating "yes/support" or "no/do not support". The poll ends Monday, Dec. 7, 2009. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --=_alternative 0022251948257682_= Content-Type: text/html; charset="US-ASCII"
Yes/Support

Fei
-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS)
Sent: Monday, November 23, 2009 4:20 PM
To: ccamp@ietf.org
Subject: [CCAMP] poll on
makingdraft-lee-ccamp-wson-signal-compatibility-ospf-00.txt ccamp wg document

All,

This is to start a two week poll on making draft-lee-ccamp-wson-signal-compatibility-ospf-00.txt a ccamp working group document. Send a mail to the mailing list indicating "yes/support"
or "no/do not support".

The poll ends Monday, Dec. 7, 2009.

Deborah
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
 --=_alternative 0022251948257682_=-- From neil.2.harrison@bt.com Fri Dec 4 02:03:00 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A6D28C0FC; Fri, 4 Dec 2009 02:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-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 FcHDsD82iRDu; Fri, 4 Dec 2009 02:02:58 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 1AB8228C0FB; Fri, 4 Dec 2009 02:02:57 -0800 (PST) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 10:02:48 +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 Date: Fri, 4 Dec 2009 10:02:41 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C056362A0@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <501F19F3-92D5-4AB3-A9CD-10DFBF568A96@lucidvision.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] [CCAMP] Thoughts on updating the OAM Configurationfwk and the MPLS-TP OAM configuration drafts Thread-Index: Acp0UXKMPvXiPPNHS2Whu2S8i14mkgAdnT6w From: To: X-OriginalArrivalTime: 04 Dec 2009 10:02:48.0596 (UTC) FILETIME=[EF06C540:01CA74C8] Cc: ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] Thoughts on updating the OAM Configurationfwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 10:03:00 -0000 Thanks Tom....but won't the CP signalling/routing protocols for MPLS-TP (if one is used) sit under a reserved label that should not appear in the traffic DP (except for OAM messages themselves, which is arch wrong IMO since OAM is in the same DP as the traffic). So I am not clear how external parties could access the CP. Sorry I am not getting your point, can you please expand on your specific concerns, eg with some exmaples? Thanks.....regards, Neil > -----Original Message----- > From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 > Sent: 03 December 2009 19:47 > To: Harrison,N,Neil,DPF2 R > Cc: agmalis@gmail.com; ccamp@ietf.org; mpls-tp@ietf.org > Subject: Re: [mpls-tp] [CCAMP] Thoughts on updating the OAM=20 > Configurationfwk and the MPLS-TP OAM configuration drafts >=20 >=20 > That still doesn't answer my question. *) Has anyone=20 > thought about unapproved RSVP messages being send to=20 > modify/deactivate/activate LSPs in this model described here? =20 >=20 > --Tom >=20 >=20 >=20 > On Dec 3, 2009, at 2:10 PM, wrote: >=20 > >=20 > > Hi Tom....this is why it is always a good idea for a co=20 > mode network=20 > > to take its CP/MP logically OOB wrt to the traffic DP....a forced=20 > > action for the co-cs mode, but requires a conscious design=20 > decision in=20 > > the co-ps mode. > >=20 > > regards, Neil =20 > >> -----Original Message----- > >> From: mpls-tp-bounces@ietf.org > >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Thomas Nadeau > >> Sent: 03 December 2009 18:14 > >> To: Andrew G. Malis > >> Cc: ccamp@ietf.org; mpls-tp@ietf.org > >> Subject: Re: [mpls-tp] [CCAMP] Thoughts on updating the OAM=20 > >> Configurationfwk and the MPLS-TP OAM configuration drafts > >>=20 > >> Has anyone thought about security ramifications of allowing this? > >>=20 > >>=20 > >> On Dec 3, 2009, at 12:28 PM, "Andrew G. Malis" > >> wrote: > >>=20 > >>> +1 > >>>=20 > >>> Cheers, > >>> Andy > >>>=20 > >>> On Thu, Dec 3, 2009 at 6:20 PM, Loa Andersson wrote: > >>>> Attila, > >>>>=20 > >>>> if we agree on this the we also have a method to easily > >> reconfigure > >>>> OAM on already set up LSPs, simple send a refresh PATH or RESV. > >>>>=20 > >>>> What do people think is this a good idea? > >>>>=20 > >>>> /Loa > >>>>=20 > >>>> Attila Takacs wrote: > >>>>>=20 > >>>>> Hi Loa, > >>>>>>=20 > >>>>>> OK great, then we need to update that in the framework. > >>>>>>=20 > >>>>> Ok, I will do so. > >>>>>=20 > >>>>>> I also have a question on the relationship between=20 > flags and the=20 > >>>>>> sub-tlvs. > >>>>>>=20 > >>>>>> I think there are four possibilities: > >>>>>>=20 > >>>>>> 1. A flag is set, but there is no sub-tlv > >>>>>> - the action here should be to turn on the function the > >>>>>> flag indicates using default values > >>>>>> I also think that if a function indicated by flag is > >>>>>> running, it should be left unchanged, even if it is not > >>>>>> running on default values > >>>>>>=20 > >>>>>> 2. A flag is set, and there is a sub-tlv > >>>>>> - the action here would be to turn on the function > >> indicated by > >>>>>> the flag, using the parameters found in sub-tlv > >>>>>>=20 > >>>>>> 3. A flag is not set, and there is no sub-tlv > >>>>>> - the action here would be to turn off any function that has > >>>>>> been configured earlier > >>>>>>=20 > >>>>>> 4. A flag is not set, but there is sub-tlv > >>>>>> - this should be treated as an error conditions and an > >>>>>> error message should be returned, no changes to the=20 > >>>>>> configured > >>>>>> OAM should be made. > >>>>>>=20 > >>>>>> Is this correctly understood? > >>>>>=20 > >>>>> Yes. I will check is this need clarification in the fwk. > >>>>>=20 > >>>>> Attila > >>>>>=20 > >>>>>> /Loa > >>>>>>=20 > >>>>>> Attila Takacs wrote: > >>>>>>>=20 > >>>>>>> Hi Loa, > >>>>>>>=20 > >>>>>>> It can be carried in the LSP_ATTRIBUTES Object in the Resv > >>>>>>=20 > >>>>>> message; so it can be used for timer negotiation and > >> discriminator > >>>>>> synchronization if needed. > >>>>>>>=20 > >>>>>>> Attila > >>>>>>>=20 > >>>>>>>> -----Original Message----- > >>>>>>>> From: Loa Andersson [mailto:loa@pi.nu] > >>>>>>>> Sent: Wednesday, December 02, 2009 3:59 PM > >>>>>>>> To: Attila Takacs > >>>>>>>> Cc: ccamp@ietf.org; mpls-tp@ietf.org > >>>>>>>> Subject: Re: [CCAMP] Thoughts on updating the OAM > >>>>>>=20 > >>>>>> Configuration fwk > >>>>>>>>=20 > >>>>>>>> and the MPLS-TP OAM configuration drafts > >>>>>>>>=20 > >>>>>>>> Attila, > >>>>>>>>=20 > >>>>>>>> thanks - I think things are converging quite a bit now. > >>>>>>>>=20 > >>>>>>>> May the OAM Configuration TLV specified in the OAM > >> Configuration > >>>>>>>> Framweork only be present in the PATH message? > >>>>>>>>=20 > >>>>>>>> /Loa > >>>>>>>>=20 > >>>>>>>> Attila Takacs wrote: > >>>>>>>>>=20 > >>>>>>>>> Hi all, > >>>>>>>>>=20 > >>>>>>>>> Some thoughts on updating the OAM Configuration fwk and > >>>>>>=20 > >>>>>> the MPLS-TP > >>>>>>>>>=20 > >>>>>>>>> OAM configuration drafts. > >>>>>>>>>=20 > >>>>>>>>> I think we need to extend the OAM Function flags=20 > (described in > >>>>>>>>> draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: > >>>>>>>>>=20 > >>>>>>>>> -CC > >>>>>>>>> -CV > >>>>>>>>> -PM Loss > >>>>>>>>> -PM Delay > >>>>>>>>> -Fault Management signals > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> With regards to BFD I see three operation vs. configuration > >>>>>>>>> modes: > >>>>>>>>>=20 > >>>>>>>>> 1) Set CC in the flags and only bootstrap the BFD session, > >>>>>>>>=20 > >>>>>>>> by sending > >>>>>>>>>=20 > >>>>>>>>> the local discriminator values in RSVP-TE and leave timer > >>>>>>>>=20 > >>>>>>>> negotiation > >>>>>>>>>=20 > >>>>>>>>> to BFD control messages. This is similar to LSP Ping based=20 > >>>>>>>>> bootstrapping described in draft-ietf-bfd-mpls-07.txt. > >>>>>>>>>=20 > >>>>>>>>> 2) Set CC in the flags but configure the timers via the > >>>>>>>>=20 > >>>>>>>> control plane, > >>>>>>>>>=20 > >>>>>>>>> this should correspond to "CC mode" in > >>>>>>>>=20 > >>>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01. > >>>>>>>>>=20 > >>>>>>>>> We may include the min/max intervals and by doing so > >>>>>>>>=20 > >>>>>>>> support initial > >>>>>>>>>=20 > >>>>>>>>> timer negotiation in control plane. However, we may need a > >>>>>>>>=20 > >>>>>>>> flag in CC > >>>>>>>>>=20 > >>>>>>>>> configuration sub-TLV (now in > >>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called > >>>>>>>>=20 > >>>>>>>> "Suggested TX > >>>>>>>>>=20 > >>>>>>>>> Interval sub-TLV") to indicate whether data plane timer > >>>>>>>>=20 > >>>>>>>> renegotiation > >>>>>>>>>=20 > >>>>>>>>> is enabled or disabled (i.e., subsequently via BFD control > >>>>>>>>=20 > >>>>>>>> messages). > >>>>>>>>>=20 > >>>>>>>>> This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, > >> should be > >>>>>>>>> disabled for TP LSPs by default. > >>>>>>>>>=20 > >>>>>>>>> 3) In case of "full" MPLS-TP OAM support any of the flags > >>>>>>>>=20 > >>>>>>>> could be set > >>>>>>>>>=20 > >>>>>>>>> as needed, reflecting "CV/CC mode" described in=20 > >>>>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss=20 > measurement as=20 > >>>>>>>>> described in draft-frost-mpls-tp-loss-delay-00 and > >>>>>>>>=20 > >>>>>>>> management signals > >>>>>>>>>=20 > >>>>>>>>> as given in draft-sfv-mpls-tp-fault-00. > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> To configure CC we will need to add -enable/disable=20 > DP timer=20 > >>>>>>>>> re-negotiation -PHB to identify > >>>>>>>>=20 > >>>>>>>> priority and > >>>>>>>>>=20 > >>>>>>>>> drop precedence of CC packets > >>>>>>>>>=20 > >>>>>>>>> When it comes to CV, it would be interesting to discuss > >>>>>>>>=20 > >>>>>>>> whether only > >>>>>>>>>=20 > >>>>>>>>> the OAM identifiers described in > >>>>>>>>=20 > >>>>>>>> draft-ietf-mpls-tp-identifiers-00 are > >>>>>>>>>=20 > >>>>>>>>> ought to be supported. If so, those could be derived > >> from RSVP- > >>>>>>>>> TE signaling without the need to carry them explicitly in > >>>>>>=20 > >>>>>> MPLS-TP OAM > >>>>>>>>>=20 > >>>>>>>>> Configuration sub-TLVs (now called Source unique MEP_ID > >>>>>>=20 > >>>>>> sub-TLV in > >>>>>>>>>=20 > >>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). > >>>>>>>>>=20 > >>>>>>>>> For Performance Monitoring Loss/Delay we need to add > >> new TLVs, > >>>>>>>>> carrying -measurement interval -possibly loss/delay bound > >>>>>>>>=20 > >>>>>>>> thresholds > >>>>>>>>>=20 > >>>>>>>>> (given we what these for MPLS-TP) that could be used to > >>>>>>=20 > >>>>>> assess the > >>>>>>>>>=20 > >>>>>>>>> quality of the connection and may eventually trigger > >>>>>>>>=20 > >>>>>>>> protection -PHB > >>>>>>>>>=20 > >>>>>>>>> of control packets if we want to set it differently from CC > >>>>>>>>=20 > >>>>>>>> packets or > >>>>>>>>>=20 > >>>>>>>>> from data traffic. > >>>>>>>>>=20 > >>>>>>>>> For the Fault Management Signals, I would add a new "Fault > >>>>>>>>=20 > >>>>>>>> Management > >>>>>>>>>=20 > >>>>>>>>> Signals sub-TLV" carrying: > >>>>>>>>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except > >>>>>>=20 > >>>>>> CFS, are > >>>>>>>>>=20 > >>>>>>>>> specified in draft-sfv-mpls-tp-fault-00) -refresh > >> timer of fault > >>>>>>>>> indication messages -flag to enable/disable explicitly > >>>>>>>>=20 > >>>>>>>> clear of faults > >>>>>>>>>=20 > >>>>>>>>> -PHB of fault management packets > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> Another thing we may want to consider is adding a > >> sub-TLV to set > >>>>>>>>> consequent actions that are configurable. This is > >>>>>>=20 > >>>>>> described to some > >>>>>>>>>=20 > >>>>>>>>> extent in the MPLS-TP OAM Framework. The defects > >>>>>>=20 > >>>>>> identified include: > >>>>>>>>>=20 > >>>>>>>>> Loss Of Continuity defect, Mis-connectivity defect, MEP=20 > >>>>>>>>> misconfiguration defect, Period Misconfiguration defect. > >>>>>>>>>=20 > >>>>>>>>> An operator may want to configure if the consequence of LOC > >>>>>>>>=20 > >>>>>>>> should be > >>>>>>>>>=20 > >>>>>>>>> the blocking or non-blocking of outgoing data traffic. > >>>>>>=20 > >>>>>> Similarly it > >>>>>>>>>=20 > >>>>>>>>> may be useful to configure whether the "Period > >>>>>>>>=20 > >>>>>>>> Misconfiguration defect" > >>>>>>>>>=20 > >>>>>>>>> should result in a signal fail condition or not. > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> I plan to send detailed text to the editors of > >>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the=20 > >>>>>>>>> lines described above. Please comment! > >>>>>>>>> Thanks, > >>>>>>>>> Attila > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>>=20 > >>>>>>>>> _______________________________________________ > >>>>>>>>> CCAMP mailing list > >>>>>>>>> CCAMP@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>>>>>>=20 > >>>>>>>> -- > >>>>>>>>=20 > >>>>>>>>=20 > >>>>>>>> Loa Andersson email:=20 > >> loa.andersson@ericsson.com > >>>>>>>> Sr Strategy and Standards Manager loa@pi.nu > >>>>>>>> Ericsson Inc phone: +46 10 717 52 13 > >>>>>>>> +46 767 72 92 13 > >>>>>>=20 > >>>>>> -- > >>>>>>=20 > >>>>>>=20 > >>>>>> Loa Andersson email:=20 > >> loa.andersson@ericsson.com > >>>>>> Sr Strategy and Standards Manager loa@pi.nu > >>>>>> Ericsson Inc phone: +46 10 717 52 13 > >>>>>> +46 767 72 92 13=20 > >>>>>> _______________________________________________ > >>>>>> CCAMP mailing list > >>>>>> CCAMP@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>>=20 > >>>> -- > >>>>=20 > >>>>=20 > >>>> Loa Andersson email:=20 > >> loa.andersson@ericsson.com > >>>> Sr Strategy and Standards Manager loa@pi.nu > >>>> Ericsson Inc phone: +46 10 717 52 13 > >>>> +46 767 72 92 13=20 > >>>> _______________________________________________ > >>>> CCAMP mailing list > >>>> CCAMP@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>>=20 > >>> _______________________________________________ > >>> mpls-tp mailing list > >>> mpls-tp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mpls-tp > >>>=20 > >> _______________________________________________ > >> mpls-tp mailing list > >> mpls-tp@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls-tp > >>=20 > >=20 >=20 >=20 From benjamin.niven-jenkins@bt.com Fri Dec 4 03:39:02 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68C473A69EB; Fri, 4 Dec 2009 03:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 cLwn0bq8CxZP; Fri, 4 Dec 2009 03:39:01 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by core3.amsl.com (Postfix) with ESMTP id B034A3A69F2; Fri, 4 Dec 2009 03:39:00 -0800 (PST) Received: from RDW083A009HT61.domain1.systemhost.net (10.187.59.12) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 4 Dec 2009 11:38:50 +0000 Received: from RDW083V001RVA1.domain1.systemhost.net ([10.187.59.10]) by RDW083A009HT61.domain1.systemhost.net ([10.187.59.12]) with mapi; Fri, 4 Dec 2009 11:38:50 +0000 From: To: , Date: Fri, 4 Dec 2009 11:38:48 +0000 Thread-Topic: [mpls-tp] [CCAMP] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts Thread-Index: Acp0RG3+bR4Oic3/Qryq9bvkpKPotgAkenoE Message-ID: In-Reply-To: <3F0E9049-4EDC-4E86-934C-9D5673FE11AF@lucidvision.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 11:39:02 -0000 Tom, Can you be more specific? I don't see any greater security ramifications resulting from unapproved RSVP messages being sent to modify/deactivate/activate LSPs in this model than the current usages of RSVP-TE. Although for a slightly different context in Section 4.4.3.3 of draft-jenkins-mpls-tp-bt-requirements-00.txt I have the following note: [Editor's note: Need to insert some text requiring a mechanism to limit the chance of fat fingers running inappropriate tests, e.g. on a per PW basis the ability to run a throughput test (and the maximum rate) needs to be pre-authorised via some mechanism e.g. within the PW interface configuration] When writing the draft I had quite a lengthy discussion with Simon (the draft's co-author) about suitable mechanisms but I timed out on constructin= g some suitable text (and still haven't got around to it). Maybe something similar would be needed for being able to reconfigure the OAM on already setup LSPs. What I was thinking about for draft-jenkins was something like being able to specify in the interface configuration a requirement for explicit authentication/authorisation (possibly limited to specific account roles) before performing the Throughput test so (1) operations folks might think twice before continuing and (2) AAA can specifically record who performed the action so if things do go wrong the guilty operations person can be tracked down and "re-educated". Ben On 03/12/2009 18:13, "Thomas Nadeau" wrote: > Has anyone thought about security ramifications of allowing this? >=20 >=20 > On Dec 3, 2009, at 12:28 PM, "Andrew G. Malis" > wrote: >=20 >> +1 >>=20 >> Cheers, >> Andy >>=20 >> On Thu, Dec 3, 2009 at 6:20 PM, Loa Andersson wrote: >>> Attila, >>>=20 >>> if we agree on this the we also have a method to easily reconfigure >>> OAM on already set up LSPs, simple send a refresh PATH or RESV. >>>=20 >>> What do people think is this a good idea? >>>=20 >>> /Loa >>>=20 >>> Attila Takacs wrote: >>>>=20 >>>> Hi Loa, >>>>>=20 >>>>> OK great, then we need to update that in the framework. >>>>>=20 >>>> Ok, I will do so. >>>>=20 >>>>> I also have a question on the relationship between flags and the >>>>> sub-tlvs. >>>>>=20 >>>>> I think there are four possibilities: >>>>>=20 >>>>> 1. A flag is set, but there is no sub-tlv >>>>> - the action here should be to turn on the function the >>>>> flag indicates using default values >>>>> I also think that if a function indicated by flag is >>>>> running, it should be left unchanged, even if it is not >>>>> running on default values >>>>>=20 >>>>> 2. A flag is set, and there is a sub-tlv >>>>> - the action here would be to turn on the function indicated by >>>>> the flag, using the parameters found in sub-tlv >>>>>=20 >>>>> 3. A flag is not set, and there is no sub-tlv >>>>> - the action here would be to turn off any function that has >>>>> been configured earlier >>>>>=20 >>>>> 4. A flag is not set, but there is sub-tlv >>>>> - this should be treated as an error conditions and an >>>>> error message should be returned, no changes to the >>>>> configured >>>>> OAM should be made. >>>>>=20 >>>>> Is this correctly understood? >>>>=20 >>>> Yes. I will check is this need clarification in the fwk. >>>>=20 >>>> Attila >>>>=20 >>>>> /Loa >>>>>=20 >>>>> Attila Takacs wrote: >>>>>>=20 >>>>>> Hi Loa, >>>>>>=20 >>>>>> It can be carried in the LSP_ATTRIBUTES Object in the Resv >>>>>=20 >>>>> message; so it can be used for timer negotiation and discriminator >>>>> synchronization if needed. >>>>>>=20 >>>>>> Attila >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Loa Andersson [mailto:loa@pi.nu] >>>>>>> Sent: Wednesday, December 02, 2009 3:59 PM >>>>>>> To: Attila Takacs >>>>>>> Cc: ccamp@ietf.org; mpls-tp@ietf.org >>>>>>> Subject: Re: [CCAMP] Thoughts on updating the OAM >>>>>=20 >>>>> Configuration fwk >>>>>>>=20 >>>>>>> and the MPLS-TP OAM configuration drafts >>>>>>>=20 >>>>>>> Attila, >>>>>>>=20 >>>>>>> thanks - I think things are converging quite a bit now. >>>>>>>=20 >>>>>>> May the OAM Configuration TLV specified in the OAM Configuration >>>>>>> Framweork only be present in the PATH message? >>>>>>>=20 >>>>>>> /Loa >>>>>>>=20 >>>>>>> Attila Takacs wrote: >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> Some thoughts on updating the OAM Configuration fwk and >>>>>=20 >>>>> the MPLS-TP >>>>>>>>=20 >>>>>>>> OAM configuration drafts. >>>>>>>>=20 >>>>>>>> I think we need to extend the OAM Function flags (described in >>>>>>>> draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: >>>>>>>>=20 >>>>>>>> -CC >>>>>>>> -CV >>>>>>>> -PM Loss >>>>>>>> -PM Delay >>>>>>>> -Fault Management signals >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> With regards to BFD I see three operation vs. configuration >>>>>>>> modes: >>>>>>>>=20 >>>>>>>> 1) Set CC in the flags and only bootstrap the BFD session, >>>>>>>=20 >>>>>>> by sending >>>>>>>>=20 >>>>>>>> the local discriminator values in RSVP-TE and leave timer >>>>>>>=20 >>>>>>> negotiation >>>>>>>>=20 >>>>>>>> to BFD control messages. This is similar to LSP Ping based >>>>>>>> bootstrapping described in draft-ietf-bfd-mpls-07.txt. >>>>>>>>=20 >>>>>>>> 2) Set CC in the flags but configure the timers via the >>>>>>>=20 >>>>>>> control plane, >>>>>>>>=20 >>>>>>>> this should correspond to "CC mode" in >>>>>>>=20 >>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01. >>>>>>>>=20 >>>>>>>> We may include the min/max intervals and by doing so >>>>>>>=20 >>>>>>> support initial >>>>>>>>=20 >>>>>>>> timer negotiation in control plane. However, we may need a >>>>>>>=20 >>>>>>> flag in CC >>>>>>>>=20 >>>>>>>> configuration sub-TLV (now in >>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called >>>>>>>=20 >>>>>>> "Suggested TX >>>>>>>>=20 >>>>>>>> Interval sub-TLV") to indicate whether data plane timer >>>>>>>=20 >>>>>>> renegotiation >>>>>>>>=20 >>>>>>>> is enabled or disabled (i.e., subsequently via BFD control >>>>>>>=20 >>>>>>> messages). >>>>>>>>=20 >>>>>>>> This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be >>>>>>>> disabled for TP LSPs by default. >>>>>>>>=20 >>>>>>>> 3) In case of "full" MPLS-TP OAM support any of the flags >>>>>>>=20 >>>>>>> could be set >>>>>>>>=20 >>>>>>>> as needed, reflecting "CV/CC mode" described in >>>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as >>>>>>>> described in >>>>>>>> draft-frost-mpls-tp-loss-delay-00 and >>>>>>>=20 >>>>>>> management signals >>>>>>>>=20 >>>>>>>> as given in draft-sfv-mpls-tp-fault-00. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> To configure CC we will need to add >>>>>>>> -enable/disable DP timer re-negotiation -PHB to identify >>>>>>>=20 >>>>>>> priority and >>>>>>>>=20 >>>>>>>> drop precedence of CC packets >>>>>>>>=20 >>>>>>>> When it comes to CV, it would be interesting to discuss >>>>>>>=20 >>>>>>> whether only >>>>>>>>=20 >>>>>>>> the OAM identifiers described in >>>>>>>=20 >>>>>>> draft-ietf-mpls-tp-identifiers-00 are >>>>>>>>=20 >>>>>>>> ought to be supported. If so, those could be derived from RSVP- >>>>>>>> TE >>>>>>>> signaling without the need to carry them explicitly in >>>>>=20 >>>>> MPLS-TP OAM >>>>>>>>=20 >>>>>>>> Configuration sub-TLVs (now called Source unique MEP_ID >>>>>=20 >>>>> sub-TLV in >>>>>>>>=20 >>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). >>>>>>>>=20 >>>>>>>> For Performance Monitoring Loss/Delay we need to add new TLVs, >>>>>>>> carrying -measurement interval -possibly loss/delay bound >>>>>>>=20 >>>>>>> thresholds >>>>>>>>=20 >>>>>>>> (given we what these for MPLS-TP) that could be used to >>>>>=20 >>>>> assess the >>>>>>>>=20 >>>>>>>> quality of the connection and may eventually trigger >>>>>>>=20 >>>>>>> protection -PHB >>>>>>>>=20 >>>>>>>> of control packets if we want to set it differently from CC >>>>>>>=20 >>>>>>> packets or >>>>>>>>=20 >>>>>>>> from data traffic. >>>>>>>>=20 >>>>>>>> For the Fault Management Signals, I would add a new "Fault >>>>>>>=20 >>>>>>> Management >>>>>>>>=20 >>>>>>>> Signals sub-TLV" carrying: >>>>>>>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except >>>>>=20 >>>>> CFS, are >>>>>>>>=20 >>>>>>>> specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault >>>>>>>> indication messages -flag to enable/disable explicitly >>>>>>>=20 >>>>>>> clear of faults >>>>>>>>=20 >>>>>>>> -PHB of fault management packets >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Another thing we may want to consider is adding a sub-TLV to set >>>>>>>> consequent actions that are configurable. This is >>>>>=20 >>>>> described to some >>>>>>>>=20 >>>>>>>> extent in the MPLS-TP OAM Framework. The defects >>>>>=20 >>>>> identified include: >>>>>>>>=20 >>>>>>>> Loss Of Continuity defect, Mis-connectivity defect, MEP >>>>>>>> misconfiguration defect, Period Misconfiguration defect. >>>>>>>>=20 >>>>>>>> An operator may want to configure if the consequence of LOC >>>>>>>=20 >>>>>>> should be >>>>>>>>=20 >>>>>>>> the blocking or non-blocking of outgoing data traffic. >>>>>=20 >>>>> Similarly it >>>>>>>>=20 >>>>>>>> may be useful to configure whether the "Period >>>>>>>=20 >>>>>>> Misconfiguration defect" >>>>>>>>=20 >>>>>>>> should result in a signal fail condition or not. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I plan to send detailed text to the editors of >>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the >>>>>>>> lines >>>>>>>> described above. Please comment! >>>>>>>> Thanks, >>>>>>>> Attila >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>=20 >>>>>>> -- >>>>>>>=20 >>>>>>>=20 >>>>>>> Loa Andersson email: loa.andersson@ericsson= .com >>>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>>>> +46 767 72 92 13 >>>>>=20 >>>>> -- >>>>>=20 >>>>>=20 >>>>> Loa Andersson email: loa.andersson@ericsson.c= om >>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>> +46 767 72 92 13 >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>=20 >>> -- >>>=20 >>>=20 >>> Loa Andersson email: loa.andersson@ericsson.com >>> Sr Strategy and Standards Manager loa@pi.nu >>> Ericsson Inc phone: +46 10 717 52 13 >>> +46 767 72 92 13 >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>>=20 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >>=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From loa@pi.nu Fri Dec 4 04:58:10 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4393A28C0EF; Fri, 4 Dec 2009 04:58:10 -0800 (PST) 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=[AWL=0.000, 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 H7lESge9+JX6; Fri, 4 Dec 2009 04:58:08 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 75A0F3A69DB; Fri, 4 Dec 2009 04:58:08 -0800 (PST) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id EF2B4D4053; Fri, 4 Dec 2009 13:57:56 +0100 (CET) Message-ID: <4B190753.4080500@pi.nu> Date: Fri, 04 Dec 2009 13:57:55 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: benjamin.niven-jenkins@bt.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 12:58:10 -0000 Tom, benjamin.niven-jenkins@bt.com wrote: > Tom, > > Can you be more specific? I don't see any greater security ramifications > resulting from unapproved RSVP messages being sent to > modify/deactivate/activate LSPs in this model than the current usages of > RSVP-TE. I agree with Ben, I don't see any additional security issues as compared to how RSVP-TE is used today. /Loa > > Although for a slightly different context in Section 4.4.3.3 of > draft-jenkins-mpls-tp-bt-requirements-00.txt I have the following note: > > [Editor's note: Need to insert some text requiring a mechanism to > limit the chance of fat fingers running inappropriate tests, e.g. on > a per PW basis the ability to run a throughput test (and the maximum > rate) needs to be pre-authorised via some mechanism e.g. within the > PW interface configuration] > > When writing the draft I had quite a lengthy discussion with Simon (the > draft's co-author) about suitable mechanisms but I timed out on constructing > some suitable text (and still haven't got around to it). > > Maybe something similar would be needed for being able to reconfigure the > OAM on already setup LSPs. What I was thinking about for draft-jenkins was > something like being able to specify in the interface configuration a > requirement for explicit authentication/authorisation (possibly limited to > specific account roles) before performing the Throughput test so (1) > operations folks might think twice before continuing and (2) AAA can > specifically record who performed the action so if things do go wrong the > guilty operations person can be tracked down and "re-educated". > > Ben > > > > On 03/12/2009 18:13, "Thomas Nadeau" wrote: > >> Has anyone thought about security ramifications of allowing this? >> >> >> On Dec 3, 2009, at 12:28 PM, "Andrew G. Malis" >> wrote: >> >>> +1 >>> >>> Cheers, >>> Andy >>> >>> On Thu, Dec 3, 2009 at 6:20 PM, Loa Andersson wrote: >>>> Attila, >>>> >>>> if we agree on this the we also have a method to easily reconfigure >>>> OAM on already set up LSPs, simple send a refresh PATH or RESV. >>>> >>>> What do people think is this a good idea? >>>> >>>> /Loa >>>> >>>> Attila Takacs wrote: >>>>> Hi Loa, >>>>>> OK great, then we need to update that in the framework. >>>>>> >>>>> Ok, I will do so. >>>>> >>>>>> I also have a question on the relationship between flags and the >>>>>> sub-tlvs. >>>>>> >>>>>> I think there are four possibilities: >>>>>> >>>>>> 1. A flag is set, but there is no sub-tlv >>>>>> - the action here should be to turn on the function the >>>>>> flag indicates using default values >>>>>> I also think that if a function indicated by flag is >>>>>> running, it should be left unchanged, even if it is not >>>>>> running on default values >>>>>> >>>>>> 2. A flag is set, and there is a sub-tlv >>>>>> - the action here would be to turn on the function indicated by >>>>>> the flag, using the parameters found in sub-tlv >>>>>> >>>>>> 3. A flag is not set, and there is no sub-tlv >>>>>> - the action here would be to turn off any function that has >>>>>> been configured earlier >>>>>> >>>>>> 4. A flag is not set, but there is sub-tlv >>>>>> - this should be treated as an error conditions and an >>>>>> error message should be returned, no changes to the >>>>>> configured >>>>>> OAM should be made. >>>>>> >>>>>> Is this correctly understood? >>>>> Yes. I will check is this need clarification in the fwk. >>>>> >>>>> Attila >>>>> >>>>>> /Loa >>>>>> >>>>>> Attila Takacs wrote: >>>>>>> Hi Loa, >>>>>>> >>>>>>> It can be carried in the LSP_ATTRIBUTES Object in the Resv >>>>>> message; so it can be used for timer negotiation and discriminator >>>>>> synchronization if needed. >>>>>>> Attila >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Loa Andersson [mailto:loa@pi.nu] >>>>>>>> Sent: Wednesday, December 02, 2009 3:59 PM >>>>>>>> To: Attila Takacs >>>>>>>> Cc: ccamp@ietf.org; mpls-tp@ietf.org >>>>>>>> Subject: Re: [CCAMP] Thoughts on updating the OAM >>>>>> Configuration fwk >>>>>>>> and the MPLS-TP OAM configuration drafts >>>>>>>> >>>>>>>> Attila, >>>>>>>> >>>>>>>> thanks - I think things are converging quite a bit now. >>>>>>>> >>>>>>>> May the OAM Configuration TLV specified in the OAM Configuration >>>>>>>> Framweork only be present in the PATH message? >>>>>>>> >>>>>>>> /Loa >>>>>>>> >>>>>>>> Attila Takacs wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Some thoughts on updating the OAM Configuration fwk and >>>>>> the MPLS-TP >>>>>>>>> OAM configuration drafts. >>>>>>>>> >>>>>>>>> I think we need to extend the OAM Function flags (described in >>>>>>>>> draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: >>>>>>>>> >>>>>>>>> -CC >>>>>>>>> -CV >>>>>>>>> -PM Loss >>>>>>>>> -PM Delay >>>>>>>>> -Fault Management signals >>>>>>>>> >>>>>>>>> >>>>>>>>> With regards to BFD I see three operation vs. configuration >>>>>>>>> modes: >>>>>>>>> >>>>>>>>> 1) Set CC in the flags and only bootstrap the BFD session, >>>>>>>> by sending >>>>>>>>> the local discriminator values in RSVP-TE and leave timer >>>>>>>> negotiation >>>>>>>>> to BFD control messages. This is similar to LSP Ping based >>>>>>>>> bootstrapping described in draft-ietf-bfd-mpls-07.txt. >>>>>>>>> >>>>>>>>> 2) Set CC in the flags but configure the timers via the >>>>>>>> control plane, >>>>>>>>> this should correspond to "CC mode" in >>>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01. >>>>>>>>> We may include the min/max intervals and by doing so >>>>>>>> support initial >>>>>>>>> timer negotiation in control plane. However, we may need a >>>>>>>> flag in CC >>>>>>>>> configuration sub-TLV (now in >>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called >>>>>>>> "Suggested TX >>>>>>>>> Interval sub-TLV") to indicate whether data plane timer >>>>>>>> renegotiation >>>>>>>>> is enabled or disabled (i.e., subsequently via BFD control >>>>>>>> messages). >>>>>>>>> This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be >>>>>>>>> disabled for TP LSPs by default. >>>>>>>>> >>>>>>>>> 3) In case of "full" MPLS-TP OAM support any of the flags >>>>>>>> could be set >>>>>>>>> as needed, reflecting "CV/CC mode" described in >>>>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as >>>>>>>>> described in >>>>>>>>> draft-frost-mpls-tp-loss-delay-00 and >>>>>>>> management signals >>>>>>>>> as given in draft-sfv-mpls-tp-fault-00. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> To configure CC we will need to add >>>>>>>>> -enable/disable DP timer re-negotiation -PHB to identify >>>>>>>> priority and >>>>>>>>> drop precedence of CC packets >>>>>>>>> >>>>>>>>> When it comes to CV, it would be interesting to discuss >>>>>>>> whether only >>>>>>>>> the OAM identifiers described in >>>>>>>> draft-ietf-mpls-tp-identifiers-00 are >>>>>>>>> ought to be supported. If so, those could be derived from RSVP- >>>>>>>>> TE >>>>>>>>> signaling without the need to carry them explicitly in >>>>>> MPLS-TP OAM >>>>>>>>> Configuration sub-TLVs (now called Source unique MEP_ID >>>>>> sub-TLV in >>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). >>>>>>>>> >>>>>>>>> For Performance Monitoring Loss/Delay we need to add new TLVs, >>>>>>>>> carrying -measurement interval -possibly loss/delay bound >>>>>>>> thresholds >>>>>>>>> (given we what these for MPLS-TP) that could be used to >>>>>> assess the >>>>>>>>> quality of the connection and may eventually trigger >>>>>>>> protection -PHB >>>>>>>>> of control packets if we want to set it differently from CC >>>>>>>> packets or >>>>>>>>> from data traffic. >>>>>>>>> >>>>>>>>> For the Fault Management Signals, I would add a new "Fault >>>>>>>> Management >>>>>>>>> Signals sub-TLV" carrying: >>>>>>>>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except >>>>>> CFS, are >>>>>>>>> specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault >>>>>>>>> indication messages -flag to enable/disable explicitly >>>>>>>> clear of faults >>>>>>>>> -PHB of fault management packets >>>>>>>>> >>>>>>>>> >>>>>>>>> Another thing we may want to consider is adding a sub-TLV to set >>>>>>>>> consequent actions that are configurable. This is >>>>>> described to some >>>>>>>>> extent in the MPLS-TP OAM Framework. The defects >>>>>> identified include: >>>>>>>>> Loss Of Continuity defect, Mis-connectivity defect, MEP >>>>>>>>> misconfiguration defect, Period Misconfiguration defect. >>>>>>>>> >>>>>>>>> An operator may want to configure if the consequence of LOC >>>>>>>> should be >>>>>>>>> the blocking or non-blocking of outgoing data traffic. >>>>>> Similarly it >>>>>>>>> may be useful to configure whether the "Period >>>>>>>> Misconfiguration defect" >>>>>>>>> should result in a signal fail condition or not. >>>>>>>>> >>>>>>>>> >>>>>>>>> I plan to send detailed text to the editors of >>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the >>>>>>>>> lines >>>>>>>>> described above. Please comment! >>>>>>>>> Thanks, >>>>>>>>> Attila >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> CCAMP mailing list >>>>>>>>> CCAMP@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> Loa Andersson email: loa.andersson@ericsson.com >>>>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>>>>> +46 767 72 92 13 >>>>>> -- >>>>>> >>>>>> >>>>>> Loa Andersson email: loa.andersson@ericsson.com >>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>>> +46 767 72 92 13 >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> -- >>>> >>>> >>>> Loa Andersson email: loa.andersson@ericsson.com >>>> Sr Strategy and Standards Manager loa@pi.nu >>>> Ericsson Inc phone: +46 10 717 52 13 >>>> +46 767 72 92 13 >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From tnadeau@lucidvision.com Fri Dec 4 05:26:27 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81D63A6A17; Fri, 4 Dec 2009 05:26:27 -0800 (PST) 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 RP-cTNKhuqQv; Fri, 4 Dec 2009 05:26:26 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 00A953A6A14; Fri, 4 Dec 2009 05:26:25 -0800 (PST) Received: from [192.168.1.120] (unknown [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id DEA8B42170F8; Fri, 4 Dec 2009 08:26:16 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: <4B190753.4080500@pi.nu> Date: Fri, 4 Dec 2009 08:26:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B190753.4080500@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1077) Cc: ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 13:26:28 -0000 I guess my point is to ask whether or not we've thought through = the architectural and security implications of allowing changes to = configurations via a signaling protocol. More specially, are we = targeting OAM configuration to be contained to just RSVP-related = configuration, or are we going to allow it to go beyond that? If its = the former, I'd agree, the security implications are similar to those of = the base protocol; however, when we go beyond that such as the = discussion of enabling/disabling existing LSPs or such things, I see = potential issues there. --Tom On Dec 4, 2009, at 7:57 AM, Loa Andersson wrote: > Tom, >=20 >=20 > benjamin.niven-jenkins@bt.com wrote: >> Tom, >> Can you be more specific? I don't see any greater security = ramifications >> resulting from unapproved RSVP messages being sent to >> modify/deactivate/activate LSPs in this model than the current usages = of >> RSVP-TE. >=20 > I agree with Ben, I don't see any additional security issues as > compared to how RSVP-TE is used today. >=20 > /Loa >> Although for a slightly different context in Section 4.4.3.3 of >> draft-jenkins-mpls-tp-bt-requirements-00.txt I have the following = note: >> [Editor's note: Need to insert some text requiring a mechanism to >> limit the chance of fat fingers running inappropriate tests, e.g. = on >> a per PW basis the ability to run a throughput test (and the = maximum >> rate) needs to be pre-authorised via some mechanism e.g. within the >> PW interface configuration] >> When writing the draft I had quite a lengthy discussion with Simon = (the >> draft's co-author) about suitable mechanisms but I timed out on = constructing >> some suitable text (and still haven't got around to it). >> Maybe something similar would be needed for being able to reconfigure = the >> OAM on already setup LSPs. What I was thinking about for = draft-jenkins was >> something like being able to specify in the interface configuration a >> requirement for explicit authentication/authorisation (possibly = limited to >> specific account roles) before performing the Throughput test so (1) >> operations folks might think twice before continuing and (2) AAA can >> specifically record who performed the action so if things do go wrong = the >> guilty operations person can be tracked down and "re-educated". >> Ben >> On 03/12/2009 18:13, "Thomas Nadeau" wrote: >>> Has anyone thought about security ramifications of allowing this? >>>=20 >>>=20 >>> On Dec 3, 2009, at 12:28 PM, "Andrew G. Malis" >>> wrote: >>>=20 >>>> +1 >>>>=20 >>>> Cheers, >>>> Andy >>>>=20 >>>> On Thu, Dec 3, 2009 at 6:20 PM, Loa Andersson wrote: >>>>> Attila, >>>>>=20 >>>>> if we agree on this the we also have a method to easily = reconfigure >>>>> OAM on already set up LSPs, simple send a refresh PATH or RESV. >>>>>=20 >>>>> What do people think is this a good idea? >>>>>=20 >>>>> /Loa >>>>>=20 >>>>> Attila Takacs wrote: >>>>>> Hi Loa, >>>>>>> OK great, then we need to update that in the framework. >>>>>>>=20 >>>>>> Ok, I will do so. >>>>>>=20 >>>>>>> I also have a question on the relationship between flags and the >>>>>>> sub-tlvs. >>>>>>>=20 >>>>>>> I think there are four possibilities: >>>>>>>=20 >>>>>>> 1. A flag is set, but there is no sub-tlv >>>>>>> - the action here should be to turn on the function the >>>>>>> flag indicates using default values >>>>>>> I also think that if a function indicated by flag is >>>>>>> running, it should be left unchanged, even if it is not >>>>>>> running on default values >>>>>>>=20 >>>>>>> 2. A flag is set, and there is a sub-tlv >>>>>>> - the action here would be to turn on the function indicated = by >>>>>>> the flag, using the parameters found in sub-tlv >>>>>>>=20 >>>>>>> 3. A flag is not set, and there is no sub-tlv >>>>>>> - the action here would be to turn off any function that has >>>>>>> been configured earlier >>>>>>>=20 >>>>>>> 4. A flag is not set, but there is sub-tlv >>>>>>> - this should be treated as an error conditions and an >>>>>>> error message should be returned, no changes to the >>>>>>> configured >>>>>>> OAM should be made. >>>>>>>=20 >>>>>>> Is this correctly understood? >>>>>> Yes. I will check is this need clarification in the fwk. >>>>>>=20 >>>>>> Attila >>>>>>=20 >>>>>>> /Loa >>>>>>>=20 >>>>>>> Attila Takacs wrote: >>>>>>>> Hi Loa, >>>>>>>>=20 >>>>>>>> It can be carried in the LSP_ATTRIBUTES Object in the Resv >>>>>>> message; so it can be used for timer negotiation and = discriminator >>>>>>> synchronization if needed. >>>>>>>> Attila >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Loa Andersson [mailto:loa@pi.nu] >>>>>>>>> Sent: Wednesday, December 02, 2009 3:59 PM >>>>>>>>> To: Attila Takacs >>>>>>>>> Cc: ccamp@ietf.org; mpls-tp@ietf.org >>>>>>>>> Subject: Re: [CCAMP] Thoughts on updating the OAM >>>>>>> Configuration fwk >>>>>>>>> and the MPLS-TP OAM configuration drafts >>>>>>>>>=20 >>>>>>>>> Attila, >>>>>>>>>=20 >>>>>>>>> thanks - I think things are converging quite a bit now. >>>>>>>>>=20 >>>>>>>>> May the OAM Configuration TLV specified in the OAM = Configuration >>>>>>>>> Framweork only be present in the PATH message? >>>>>>>>>=20 >>>>>>>>> /Loa >>>>>>>>>=20 >>>>>>>>> Attila Takacs wrote: >>>>>>>>>> Hi all, >>>>>>>>>>=20 >>>>>>>>>> Some thoughts on updating the OAM Configuration fwk and >>>>>>> the MPLS-TP >>>>>>>>>> OAM configuration drafts. >>>>>>>>>>=20 >>>>>>>>>> I think we need to extend the OAM Function flags (described = in >>>>>>>>>> draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: >>>>>>>>>>=20 >>>>>>>>>> -CC >>>>>>>>>> -CV >>>>>>>>>> -PM Loss >>>>>>>>>> -PM Delay >>>>>>>>>> -Fault Management signals >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> With regards to BFD I see three operation vs. configuration >>>>>>>>>> modes: >>>>>>>>>>=20 >>>>>>>>>> 1) Set CC in the flags and only bootstrap the BFD session, >>>>>>>>> by sending >>>>>>>>>> the local discriminator values in RSVP-TE and leave timer >>>>>>>>> negotiation >>>>>>>>>> to BFD control messages. This is similar to LSP Ping based >>>>>>>>>> bootstrapping described in draft-ietf-bfd-mpls-07.txt. >>>>>>>>>>=20 >>>>>>>>>> 2) Set CC in the flags but configure the timers via the >>>>>>>>> control plane, >>>>>>>>>> this should correspond to "CC mode" in >>>>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01. >>>>>>>>>> We may include the min/max intervals and by doing so >>>>>>>>> support initial >>>>>>>>>> timer negotiation in control plane. However, we may need a >>>>>>>>> flag in CC >>>>>>>>>> configuration sub-TLV (now in >>>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called >>>>>>>>> "Suggested TX >>>>>>>>>> Interval sub-TLV") to indicate whether data plane timer >>>>>>>>> renegotiation >>>>>>>>>> is enabled or disabled (i.e., subsequently via BFD control >>>>>>>>> messages). >>>>>>>>>> This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should = be >>>>>>>>>> disabled for TP LSPs by default. >>>>>>>>>>=20 >>>>>>>>>> 3) In case of "full" MPLS-TP OAM support any of the flags >>>>>>>>> could be set >>>>>>>>>> as needed, reflecting "CV/CC mode" described in >>>>>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as >>>>>>>>>> described in >>>>>>>>>> draft-frost-mpls-tp-loss-delay-00 and >>>>>>>>> management signals >>>>>>>>>> as given in draft-sfv-mpls-tp-fault-00. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> To configure CC we will need to add >>>>>>>>>> -enable/disable DP timer re-negotiation -PHB to identify >>>>>>>>> priority and >>>>>>>>>> drop precedence of CC packets >>>>>>>>>>=20 >>>>>>>>>> When it comes to CV, it would be interesting to discuss >>>>>>>>> whether only >>>>>>>>>> the OAM identifiers described in >>>>>>>>> draft-ietf-mpls-tp-identifiers-00 are >>>>>>>>>> ought to be supported. If so, those could be derived from = RSVP- >>>>>>>>>> TE >>>>>>>>>> signaling without the need to carry them explicitly in >>>>>>> MPLS-TP OAM >>>>>>>>>> Configuration sub-TLVs (now called Source unique MEP_ID >>>>>>> sub-TLV in >>>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). >>>>>>>>>>=20 >>>>>>>>>> For Performance Monitoring Loss/Delay we need to add new = TLVs, >>>>>>>>>> carrying -measurement interval -possibly loss/delay bound >>>>>>>>> thresholds >>>>>>>>>> (given we what these for MPLS-TP) that could be used to >>>>>>> assess the >>>>>>>>>> quality of the connection and may eventually trigger >>>>>>>>> protection -PHB >>>>>>>>>> of control packets if we want to set it differently from CC >>>>>>>>> packets or >>>>>>>>>> from data traffic. >>>>>>>>>>=20 >>>>>>>>>> For the Fault Management Signals, I would add a new "Fault >>>>>>>>> Management >>>>>>>>>> Signals sub-TLV" carrying: >>>>>>>>>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except >>>>>>> CFS, are >>>>>>>>>> specified in draft-sfv-mpls-tp-fault-00) -refresh timer of = fault >>>>>>>>>> indication messages -flag to enable/disable explicitly >>>>>>>>> clear of faults >>>>>>>>>> -PHB of fault management packets >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Another thing we may want to consider is adding a sub-TLV to = set >>>>>>>>>> consequent actions that are configurable. This is >>>>>>> described to some >>>>>>>>>> extent in the MPLS-TP OAM Framework. The defects >>>>>>> identified include: >>>>>>>>>> Loss Of Continuity defect, Mis-connectivity defect, MEP >>>>>>>>>> misconfiguration defect, Period Misconfiguration defect. >>>>>>>>>>=20 >>>>>>>>>> An operator may want to configure if the consequence of LOC >>>>>>>>> should be >>>>>>>>>> the blocking or non-blocking of outgoing data traffic. >>>>>>> Similarly it >>>>>>>>>> may be useful to configure whether the "Period >>>>>>>>> Misconfiguration defect" >>>>>>>>>> should result in a signal fail condition or not. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I plan to send detailed text to the editors of >>>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the >>>>>>>>>> lines >>>>>>>>>> described above. Please comment! >>>>>>>>>> Thanks, >>>>>>>>>> Attila >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> CCAMP mailing list >>>>>>>>>> CCAMP@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>>> -- >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Loa Andersson email: = loa.andersson@ericsson.com >>>>>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>>>>>> +46 767 72 92 13 >>>>>>> -- >>>>>>>=20 >>>>>>>=20 >>>>>>> Loa Andersson email: = loa.andersson@ericsson.com >>>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>>>> +46 767 72 92 13 >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> -- >>>>>=20 >>>>>=20 >>>>> Loa Andersson email: = loa.andersson@ericsson.com >>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>> +46 767 72 92 13 >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>=20 >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>=20 >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > --=20 >=20 >=20 > Loa Andersson email: = loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 >=20 From lberger@labn.net Fri Dec 4 07:14:07 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09B483A6A2E for ; Fri, 4 Dec 2009 07:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 03iZXLIRJ1pt for ; Fri, 4 Dec 2009 07:14:05 -0800 (PST) Received: from outbound-mail-145.bluehost.com (outbound-mail-145.bluehost.com [67.222.38.35]) by core3.amsl.com (Postfix) with SMTP id 382F23A6A29 for ; Fri, 4 Dec 2009 07:14:05 -0800 (PST) Received: (qmail 26436 invoked by uid 0); 4 Dec 2009 15:13:56 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy5.bluehost.com with SMTP; 4 Dec 2009 15:13:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Jvs2hVBVLVU6CcVPyCBseno+7dLFPqUg/2PHWGgm2el2FBgft49rqHz52pxiGDMwWyKLOtpm2I2nSCcKt+GEfbXA1KQT1S6v0CCpkwAJ+xxjZTjLIkjIGMEudXXVbl9/; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NGZr2-00076W-Cm; Fri, 04 Dec 2009 08:13:56 -0700 Message-ID: <4B19273C.2000006@labn.net> Date: Fri, 04 Dec 2009 10:14:04 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Evelyne Roch References: <4B06FB22.8090301@labn.net> <90243C8A881F8D419D855264D9636F3A029ADCB1@zcarhxm2.corp.nortel.com> In-Reply-To: <90243C8A881F8D419D855264D9636F3A029ADCB1@zcarhxm2.corp.nortel.com> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org Subject: Re: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 15:14:07 -0000 Evelyne, Jonathan, As Deborah and others have said in previous messages, this document has been stable for quite a while and is focused on a specific set of requirements. These requirements are covered in section 3 of the draft. With in-scope scenarios described in section 3.2. It sounds to me like the basic point being raised by both of you goes to the intended scope of this document. In particular, Section 3.2 and the rest of the document doesn't allow for the the scenario where one or more members are established using a mechanism other than what is described in the document. Is this correct or am I missing another point? Certainly any limitations in a document with respect to the described technical solution to meeting the document's scope need to be addressed. Albeit a bit late in the process, I also think raising points on requirements is valid in WG last call. But such new requirements must be evaluated for inclusion and must meet a high bar to be included at such a late stage of the process. In evaluating how such points are to be addressed, I think it is particularly important to gauge if the existing solution (and requirements set) handles a useful functionality set and if the new requirements are valid and can still be addressed independently or incrementally. I think the general sentiment on the list so far has been that the existing document scope (VCAT signaled using the mechanisms in the document) is useful and that the your requirements should be explored independently from this document. I think this is a reasonable position and doesn't preclude the WG discussing your new scenario. Not withstanding the existing section 3 (and 3.2), I think it is valid that this document make its scope even clearer by highlighting the scope earlier in the document. Also, any open technical points related to the described mechanisms also need to be run to ground as part of this (and any) last call. Lou On 12/2/2009 5:01 PM, Evelyne Roch wrote: > Lou, > > I think this document fails to address some important requirements for > VCAT signaling. As we described in draft-roch-ccamp-gmpls-inv-mux-00, > there are requirements for VCAT signaling to be performed independently > from the member signaling in certain conditions when business > relationships do not permit the provider of the members to carry VCAT > signaling on its behalf, due to policies or existence of statically > configured connections. I would prefer to see a signaling approach that > allows for independent VCAT signaling and does not require the members > to carry information related to the VCAT services. > > Regards, > Evelyne Roch > e-mail: eroch@nortel.com > > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Friday, November 20, 2009 3:25 PM > To: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org > Subject: [CCAMP] Working group last call: > draft-ietf-ccamp-gmpls-vcat-lcas-08 > > As discussed in last week's session, it's time for the working group to > last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas > > Please send your comments to the list or the authors&chairs before the > last call closes in two weeks, on December 4, 2009. > > Thank you, > Lou (and Deborah) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From root@core3.amsl.com Fri Dec 4 07:30:02 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 549E43A695B; Fri, 4 Dec 2009 07:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091204153002.549E43A695B@core3.amsl.com> Date: Fri, 4 Dec 2009 07:30:02 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-07.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 15:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework Author(s) : D. Fedyk, et al. Filename : draft-ietf-ccamp-gmpls-ethernet-arch-07.txt Pages : 21 Date : 2009-12-04 There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized MPLS based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed and this document provides a framework for these extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ethernet-arch-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-04071502.I-D@ietf.org> --NextPart-- From EROCH@nortel.com Fri Dec 4 09:11:52 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1BA3A6A38 for ; Fri, 4 Dec 2009 09:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 tYvl0d7NzpUm for ; Fri, 4 Dec 2009 09:11:44 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 858B73A6A3F for ; Fri, 4 Dec 2009 09:11:43 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nB4HBSC10816; Fri, 4 Dec 2009 17:11:28 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 Date: Fri, 4 Dec 2009 12:10:56 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: Acpzsm5FRdsP8BT7SKWJ2mH2XDBUsgAko0xAAAHUDkAAA2T/0AApnNYg References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com> From: "Evelyne Roch" To: "BRUNGARD, DEBORAH A (ATTLABS)" Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 17:11:52 -0000 According to RFC4974: "In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls." In draft-ietf-ccamp-gmpls-vcat-lcas-08, section 4.2: "To support a VCG with multiple co-signaled VCG members sets requires=20 being able to identify separate control plane LSPs with a single VCG=20 and exchange information pertaining to the VCG as a whole. This is=20 very similar to the "Call" concept described in [RFC4974]. We can think of our VCAT/LCAS connection, e.g., our VCG, as a higher layer=20 service that makes use of multiple lower layer (server) connections=20 that are controlled by one or more control plane LSPs. " I would make a stronger statement and say that the VCG is an association between VCAT endpoints to support VCAT services and the VCG is a call: - There is an association between the VCAT endpoints and that is a VCAT call. - There is also an association between the member endpoints and that is the member call.=20 I have big problems with section 4.2.1 bullet 4 stating that the VCG identifier can be used to identify a particular VCG separately from the call ID so that call members can be reused. Based on section 4.2.1 bullet 4 (and text 4.4), the call that is signaled in the draft is NOT a VCAT call but rather a member call (which may contain multiple members). The members are "added/removed" from the VCG using the Notify message. But the Notify message is ALSO used to signal the VCG as it contains the number of members, whether LCAS is required and the VCG ID. That is why I state that this not provide a clean separation of VCAT control from member control.=20 Looking at it from a management's perspective, how does one manage its VCAT service? Normally, one would expect a VCAT service to be associated with a VCAT call and be identified by its call id. In the draft, that is not possible as there is no VCAT call ID. The only way to identify the call is by the combination of the VCG ID and session. Evelyne -----Original Message----- From: BRUNGARD, DEBORAH A (ATTLABS) [mailto:db3546@att.com]=20 Sent: Thursday, December 03, 2009 4:50 PM To: Roch, Evelyne (CAR:Q840) Cc: CCAMP Subject: RE: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi Evelyne, There may be confusion between the previous GMPLS support of VCAT and this document version. This document added procedures to support this independence (section 4.2-4.5) - this is why the VCG call layer was added. Section 4.5 provides procedures for different scenarios of independence with the VCAT call and the LSPs. As Greg noted, there was an effort to respond on the mail exchange and include clarifications in the document (e.g. section 4.5). Can you describe your remaining concern wrt to the draft - clarifications for section 4.2/missing scenario in 4.5/etc.? Deborah (chair hat on) -----Original Message----- From: Evelyne Roch [mailto:eroch@nortel.com] Sent: Thursday, December 03, 2009 3:19 PM To: BRUNGARD, DEBORAH A (ATTLABS) Subject: RE: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Deborah, In the link you included referring to the correspondence sent to OIF, the following requirements are worth discussing further as the draft doesn't address them adequately: - Clean separation of VCG (VCAT Group) control from the control of VCG members - Supports the ability to create and modify the VCG independent of its members=20 To me, these requirements imply that the call control for VCAT group and VCG members is independent. In other words, a VCAT call exists independently from a VCG member call. This method was mentioned in a previous message http://www.ietf.org/mail-archive/web/ccamp/current/msg09711.html.=20 Evelyne -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Thursday, December 03, 2009 1:47 PM To: Greg Bernstein; Sadler, Jonathan B. Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi all, As Greg notes, this draft has been stable for a long time, it has a dependency on the MLN-ext work and it was waiting for it to complete. We did consider (and respond to) OIF on their requirements, including: https://ops.ietf.org/lists/ccamp/ccamp.2008/msg00741.html I'm not sure, myself, Jonathan (and Evelyne) on your concerns, I'll send a separate mail (with my chair hat off) to try to understand. Deborah=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein Sent: Wednesday, December 02, 2009 7:49 PM To: Sadler, Jonathan B. Cc: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org Subject: Re: [CCAMP] Working group last call:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi folks, this draft has been very stable for a very long time. The last major revision was to put in some advanced features requested by Jonathan and Evelyn. Adrian and I worked out a solution to providing those features over two years ago. I don't work on MPLS-TP and didn't know that this was a topic covered by that. Is it? I haven't seen any specific textual changes requested just vague assertions that this draft cannot do everything and anything somebody could think of. VCAT/LCAS is a fairly general technique applying to PDH, SDH, and G.709 technologies. This draft was intended to cover those and was approved as a working group document over four years ago. Unless there is something specifically technically wrong I'm not sure that we need to start all over again with this. Regards GB Sadler, Jonathan B. wrote: > Hi all, > > As mentioned in the CCAMP working group meeting, this draft has a dependency on a control plane operating in the STS-n/VC-n environment, and that control plane carrying the CALL information used for configuring the VCAT group. > > Given carrier requirements to not extend a carrier's control plane to the customer premise (e.g. draft-jenkins-mpls-tp-bt-requirements-00, and the carrier requirements document liaised by the OIF), this dependency is not acceptable. Instead, a mechanism needs to exist where the STS-n connections can be named and signaled for incorporation into a VCAT group independent of the out-of-band network or process used to setup the STS-n/VC-n connections. > > Hence, further work on this draft is needed before it can progress. > > Jonathan Sadler > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Friday, November 20, 2009 2:25 PM > To: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org > Subject: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 > > As discussed in last week's session, it's time for the working group to=20 > last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas > > Please send your comments to the list or the authors&chairs before the > last call closes in two weeks, on December 4, 2009. > > Thank you, > Lou (and Deborah) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > =20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From EROCH@nortel.com Fri Dec 4 09:21:08 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178573A6A48 for ; Fri, 4 Dec 2009 09:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UrCHr-MvOKHU for ; Fri, 4 Dec 2009 09:21:07 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CFA193A6937 for ; Fri, 4 Dec 2009 09:21:06 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nB4HKqC13399; Fri, 4 Dec 2009 17:20:52 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 Date: Fri, 4 Dec 2009 12:20:49 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02A3D322@zcarhxm2.corp.nortel.com> In-Reply-To: <4B19273C.2000006@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: Acp09G3lmjiulWPETnmzFbxhn0n06wAEIQXw References: <4B06FB22.8090301@labn.net> <90243C8A881F8D419D855264D9636F3A029ADCB1@zcarhxm2.corp.nortel.com> <4B19273C.2000006@labn.net> From: "Evelyne Roch" To: "Lou Berger" Cc: CCAMP , draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org Subject: Re: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 17:21:08 -0000 Lou, I just clarified the problems I have with the draft in a response to Deborah but I'll add another point in response to your email regarding requirements. To me, member sharing means that there can exist multiple members, the members having been independently signaled. Those multiple members are put "in a common pool" according to the draft. The criteria for being in the "common" pool is not specified in the draft. My interpretation is that the LSPs created for one of the elementary signal types between the same endpoints can be put in the same VCG. It does not mean that the LSPs have to be in the same member call.=20 Evelyne -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, December 04, 2009 10:14 AM To: Roch, Evelyne (CAR:Q840) Cc: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org; Sadler, Jonathan B. Subject: Re: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 Evelyne, Jonathan, As Deborah and others have said in previous messages, this document has been stable for quite a while and is focused on a specific set of requirements. These requirements are covered in section 3 of the draft. With in-scope scenarios described in section 3.2. It sounds to me like the basic point being raised by both of you goes to the intended scope of this document. In particular, Section 3.2 and the rest of the document doesn't allow for the the scenario where one or more members are established using a mechanism other than what is described in the document. Is this correct or am I missing another point? Certainly any limitations in a document with respect to the described technical solution to meeting the document's scope need to be addressed. Albeit a bit late in the process, I also think raising points on requirements is valid in WG last call. But such new requirements must be evaluated for inclusion and must meet a high bar to be included at such a late stage of the process. In evaluating how such points are to be addressed, I think it is particularly important to gauge if the existing solution (and requirements set) handles a useful functionality set and if the new requirements are valid and can still be addressed independently or incrementally. I think the general sentiment on the list so far has been that the existing document scope (VCAT signaled using the mechanisms in the document) is useful and that the your requirements should be explored independently from this document. I think this is a reasonable position and doesn't preclude the WG discussing your new scenario. Not withstanding the existing section 3 (and 3.2), I think it is valid that this document make its scope even clearer by highlighting the scope earlier in the document. Also, any open technical points related to=20 the described mechanisms also need to be run to ground as part of this (and any) last call. Lou On 12/2/2009 5:01 PM, Evelyne Roch wrote: > Lou, > > I think this document fails to address some important requirements for > VCAT signaling. As we described in draft-roch-ccamp-gmpls-inv-mux-00, > there are requirements for VCAT signaling to be performed=20 > independently from the member signaling in certain conditions when=20 > business relationships do not permit the provider of the members to=20 > carry VCAT signaling on its behalf, due to policies or existence of=20 > statically configured connections. I would prefer to see a signaling=20 > approach that allows for independent VCAT signaling and does not=20 > require the members to carry information related to the VCAT services. > > Regards, > Evelyne Roch > e-mail: eroch@nortel.com > > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Friday, November 20, 2009 3:25 PM > To: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org > Subject: [CCAMP] Working group last call: > draft-ietf-ccamp-gmpls-vcat-lcas-08 > > As discussed in last week's session, it's time for the working group=20 > to last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas > > Please send your comments to the list or the authors&chairs before the > last call closes in two weeks, on December 4, 2009. > > Thank you, > Lou (and Deborah) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From wwwrun@core3.amsl.com Fri Dec 4 11:07:59 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 35BA23A685B; Fri, 4 Dec 2009 11:07:58 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20091204190759.35BA23A685B@core3.amsl.com> Date: Fri, 4 Dec 2009 11:07:59 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: draft-ietf-ccamp-gmpls-ethernet-arch (Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework) to Informational RFC X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 19:07:59 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-12-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16902&rfc_flag=0 From gregb@grotto-networking.com Fri Dec 4 13:09:32 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69C0E3A689B for ; Fri, 4 Dec 2009 13:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 sIET6Djvt0XK for ; Fri, 4 Dec 2009 13:09:31 -0800 (PST) Received: from mail16c40.carrierzone.com (mail16c40.carrierzone.com [209.235.156.156]) by core3.amsl.com (Postfix) with ESMTP id F24A93A6833 for ; Fri, 4 Dec 2009 13:09:30 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail16c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB4L9JGS006734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Dec 2009 21:09:23 GMT Message-ID: <4B197A79.1020301@grotto-networking.com> Date: Fri, 04 Dec 2009 13:09:13 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Evelyne Roch References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com> <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> In-Reply-To: <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 21:09:32 -0000 Hi Evelyne see comments below. Greg Evelyne Roch wrote: > -- snip -- > > I would make a stronger statement and say that the VCG is an association > between VCAT endpoints to support VCAT services and the VCG is a call: > --> The way we are trying to use the existing GMPLS call mechanisms, I'm not sure we can say that the "VCG is a call" from a GMPLS point of view. A VCG is an association between VCAT endpoints. > - There is an association between the VCAT endpoints and that is a VCAT > call. > ---> I'm not sure that we have calls of calls in GMPLS. At the time this was written this wasn't deemed desirable. > - There is also an association between the member endpoints and that is > the member call. > ---> This is true. > I have big problems with section 4.2.1 bullet 4 stating that the VCG > identifier can be used to identify a particular VCG separately from the > call ID so that call members can be reused. > ---> These are what you call "member call IDs". > Based on section 4.2.1 bullet 4 (and text 4.4), the call that is > signaled in the draft is NOT a VCAT call but rather a member call (which > may contain multiple members). The members are "added/removed" from the > VCG using the Notify message. But the Notify message is ALSO used to > signal the VCG as it contains the number of members, whether LCAS is > required and the VCG ID. That is why I state that this not provide a > clean separation of VCAT control from member control. > ---> Maybe Lou or other GMPLS signaling experts have a strong opinion on this issue. At the time of writing we wanted a solution that met the requirements and made use of existing/emerging GMPLS mechanisms. I also recall that no alternative implementations were offered. My co-authors and I were most interested in providing GMPLS support for VCAT/LCAS and used mechanisms as suggested by the working group and working group chairs. > Looking at it from a management's perspective, how does one manage its > VCAT service? Normally, one would expect a VCAT service to be associated > with a VCAT call and be identified by its call id. In the draft, that is > not possible as there is no VCAT call ID. The only way to identify the > call is by the combination of the VCG ID and session. > ---> We made sure the draft supported the "member sharing case" but as you point out this can require some management intervention, i.e., management would initiate changes to VCG membership, rather that a higher "VCAT level" signaling message to initiate the change. One the desired VCG membership change is known we proved automated signaling support for that. For most member sharing services, this seemed adequate, since a simpler to provide "member sharing" like functionality with signaling is just to tear down are re-setup connections. So it was hard to convince folks to allow us to do "calls of calls" specific to this applicatio > Evelyne > > > > -----Original Message----- > From: BRUNGARD, DEBORAH A (ATTLABS) [mailto:db3546@att.com] > Sent: Thursday, December 03, 2009 4:50 PM > To: Roch, Evelyne (CAR:Q840) > Cc: CCAMP > Subject: RE: [CCAMP] Working group > lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 > > Hi Evelyne, > > There may be confusion between the previous GMPLS support of VCAT and > this document version. This document added procedures to support this > independence (section 4.2-4.5) - this is why the VCG call layer was > added. Section 4.5 provides procedures for different scenarios of > independence with the VCAT call and the LSPs. As Greg noted, there was > an effort to respond on the mail exchange and include clarifications in > the document (e.g. section 4.5). Can you describe your remaining concern > wrt to the draft - clarifications for section 4.2/missing scenario in > 4.5/etc.? > > Deborah > (chair hat on) > > > -----Original Message----- > From: Evelyne Roch [mailto:eroch@nortel.com] > Sent: Thursday, December 03, 2009 3:19 PM > To: BRUNGARD, DEBORAH A (ATTLABS) > Subject: RE: [CCAMP] Working group > lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 > > Deborah, > > In the link you included referring to the correspondence sent to OIF, > the following requirements are worth discussing further as the draft > doesn't address them adequately: > > - Clean separation of VCG (VCAT Group) control from the control of VCG > members > - Supports the ability to create and modify the VCG independent of its > members > > To me, these requirements imply that the call control for VCAT group and > VCG members is independent. In other words, a VCAT call exists > independently from a VCG member call. This method was mentioned in a > previous message > http://www.ietf.org/mail-archive/web/ccamp/current/msg09711.html. > > Evelyne > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of BRUNGARD, DEBORAH A (ATTLABS) > Sent: Thursday, December 03, 2009 1:47 PM > To: Greg Bernstein; Sadler, Jonathan B. > Cc: CCAMP > Subject: Re: [CCAMP] Working group > lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 > > Hi all, > > As Greg notes, this draft has been stable for a long time, it has a > dependency on the MLN-ext work and it was waiting for it to complete. > > We did consider (and respond to) OIF on their requirements, including: > https://ops.ietf.org/lists/ccamp/ccamp.2008/msg00741.html > > > I'm not sure, myself, Jonathan (and Evelyne) on your concerns, I'll send > a separate mail (with my chair hat off) to try to understand. > > Deborah > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Greg Bernstein > Sent: Wednesday, December 02, 2009 7:49 PM > To: Sadler, Jonathan B. > Cc: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org > Subject: Re: [CCAMP] Working group last > call:draft-ietf-ccamp-gmpls-vcat-lcas-08 > > Hi folks, this draft has been very stable for a very long time. > The last major revision was to put in some advanced features requested > by Jonathan and Evelyn. Adrian and I worked out a solution to providing > those features over two years ago. I don't work on MPLS-TP and didn't > know that this was a topic covered by that. Is it? > I haven't seen any specific textual changes requested just vague > assertions that this draft cannot do everything and anything somebody > could think of. > VCAT/LCAS is a fairly general technique applying to PDH, SDH, and G.709 > technologies. This draft was intended to cover those and was approved as > > a working group document over four years ago. Unless there is something > specifically technically wrong I'm not sure that we need to start all > over again with this. > > Regards > > GB > > Sadler, Jonathan B. wrote: > >> Hi all, >> >> As mentioned in the CCAMP working group meeting, this draft has a >> > dependency on a control plane operating in the STS-n/VC-n environment, > and that control plane carrying the CALL information used for > configuring the VCAT group. > >> Given carrier requirements to not extend a carrier's control plane to >> > the customer premise (e.g. draft-jenkins-mpls-tp-bt-requirements-00, and > the carrier requirements document liaised by the OIF), this dependency > is not acceptable. Instead, a mechanism needs to exist where the STS-n > connections can be named and signaled for incorporation into a VCAT > group independent of the out-of-band network or process used to setup > the STS-n/VC-n connections. > >> Hence, further work on this draft is needed before it can progress. >> >> Jonathan Sadler >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> > Of Lou Berger > >> Sent: Friday, November 20, 2009 2:25 PM >> To: CCAMP; draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org >> Subject: [CCAMP] Working group last call: >> > draft-ietf-ccamp-gmpls-vcat-lcas-08 > >> As discussed in last week's session, it's time for the working group >> > to > >> last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt >> >> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas >> >> Please send your comments to the list or the authors&chairs before the >> > > >> last call closes in two weeks, on December 4, 2009. >> >> Thank you, >> Lou (and Deborah) >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From EROCH@nortel.com Fri Dec 4 13:27:59 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E3B3A69DD for ; Fri, 4 Dec 2009 13:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 y9Fq5lE9tX3e for ; Fri, 4 Dec 2009 13:27:58 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2C57D3A6980 for ; Fri, 4 Dec 2009 13:27:58 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nB4LRd612571; Fri, 4 Dec 2009 21:27:39 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 Date: Fri, 4 Dec 2009 16:27:25 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com> In-Reply-To: <4B197A79.1020301@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: Acp1Jg8gO6vIHbUeSmy/5sMDA7rz9gAAbO9g References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com> <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> <4B197A79.1020301@grotto-networking.com> From: "Evelyne Roch" To: "Greg Bernstein" Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 21:27:59 -0000 Greg, see below. >-----Original Message----- >From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 >Sent: Friday, December 04, 2009 4:09 PM >To: Roch, Evelyne (CAR:Q840) >Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP >Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 >I'm not sure that we have calls of calls in GMPLS. At the time this >was written this wasn't deemed desirable. The model of calls being supported by calls is clearly support by ASON, whether at the same layer (see G.8080 section 6.7) or different layer (section 6.6). I find it highly desirable. Evelyne From zhang.fei3@zte.com.cn Fri Dec 4 22:35:16 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9573A6823 for ; Fri, 4 Dec 2009 22:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 aYNOkUnIe+FF for ; Fri, 4 Dec 2009 22:35:14 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id D4AA73A6781 for ; Fri, 4 Dec 2009 22:35:13 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 11164473195744; Sat, 5 Dec 2009 14:05:01 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 83949.2187257994; Sat, 5 Dec 2009 14:34:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id nB56YtLn064664; Sat, 5 Dec 2009 14:34:55 +0800 (CST) (envelope-from zhang.fei3@zte.com.cn) To: "'BRUNGARD, DEBORAH A (ATTLABS)'" , ccamp@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.fei3@zte.com.cn Date: Sat, 5 Dec 2009 14:34:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-12-05 14:34:45, Serialize complete at 2009-12-05 14:34:45 Content-Type: multipart/alternative; boundary="=_alternative 00249D3248257683_=" X-MAIL: mse2.zte.com.cn nB56YtLn064664 Subject: Re: [CCAMP] poll on making draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 06:35:16 -0000 This is a multipart message in MIME format. --=_alternative 00249D3248257683_= Content-Type: text/plain; charset="US-ASCII" "yes/support" Fei -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Monday, November 23, 2009 4:21 PM To: ccamp@ietf.org Subject: [CCAMP] poll on making draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document All, This is to start a two week poll on making draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt a ccamp working group document. Send a mail to the mailing list indicating "yes/support" or "no/do not support". The poll ends Monday, Dec. 7, 2009. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --=_alternative 00249D3248257683_= Content-Type: text/html; charset="US-ASCII"
"yes/support"

Fei


-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of
BRUNGARD, DEBORAH A (ATTLABS)
Sent: Monday, November 23, 2009 4:21 PM
To: ccamp@ietf.org
Subject: [CCAMP] poll on making
draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document

All,

This is to start a two week poll on making
draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt a ccamp working group
document. Send a mail to the mailing list indicating "yes/support" or
"no/do not support".

The poll ends Monday, Dec. 7, 2009.

Deborah
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

 --=_alternative 00249D3248257683_=-- From root@core3.amsl.com Sun Dec 6 18:30:03 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 261EC3A69F6; Sun, 6 Dec 2009 18:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091207023003.261EC3A69F6@core3.amsl.com> Date: Sun, 6 Dec 2009 18:30:02 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g-694-lambda-labels-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 02:30:03 -0000 --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 Labels for Lambda-Switching Capable Label Switching Routers Author(s) : T. Otani, et al. Filename : draft-ietf-ccamp-gmpls-g-694-lambda-labels-05.txt Pages : 13 Date : 2009-12-06 Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. However, [RFC3471] has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength continuity is not considered. In order to achieve interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format, being compliant with either [G.694.1](DWDM-grid) or [G.694.2](CWDM-grid). Moreover some consideration on how to ensure lambda continuity with RSVP-TE is provided. This document is a companion to the Generalized Multi- Protocol Label Switching (GMPLS) signaling. It defines the label format when Lambda Switching is requested in an all optical network. 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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-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-gmpls-g-694-lambda-labels-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-06181904.I-D@ietf.org> --NextPart-- From danli@huawei.com Sun Dec 6 22:40:19 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B013A68FE for ; Sun, 6 Dec 2009 22:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.259 X-Spam-Level: * X-Spam-Status: No, score=1.259 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 fhuSaTGCMTM1 for ; Sun, 6 Dec 2009 22:40:18 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 8322128C0DD for ; Sun, 6 Dec 2009 22:40:17 -0800 (PST) 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 <0KU900CM7RUF2Y@szxga01-in.huawei.com> for ccamp@ietf.org; Mon, 07 Dec 2009 14:39:52 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU9007OYRUFS6@szxga01-in.huawei.com> for ccamp@ietf.org; Mon, 07 Dec 2009 14:39:51 +0800 (CST) Received: from l37133a ([10.70.77.79]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU900KO2RUF3Y@szxml06-in.huawei.com> for ccamp@ietf.org; Mon, 07 Dec 2009 14:39:51 +0800 (CST) Date: Mon, 07 Dec 2009 14:39:51 +0800 From: Dan Li To: ccamp@ietf.org Message-id: <00e001ca7708$143b8850$4f4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_QBJtNh3dIbgY+574R7FTog)" X-Priority: 3 X-MSMail-priority: Normal Cc: "Deborah A. Brungard" Subject: [CCAMP] Fw: I-D Action:draft-ietf-ccamp-gmpls-g-694-lambda-labels-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 06:40:19 -0000 This is a multi-part message in MIME format. --Boundary_(ID_QBJtNh3dIbgY+574R7FTog) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi, We have received the liaison from the ITU-T Q6/15 on 27th October 2009. Please refer to: https://datatracker.ietf.org/documents/LIAISON/file718.pdf Some comments with respect to draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt are provided in the liaison: 1) Removal of reference to G.694 in title of document; 2) Abstract: replace "ITU-T G.694" (which doesn't exist in this form) with "either G.694.1 (DWDM-grid) or G.694.2 (CWDM-grid)". Make equivalent changes elsewhere in the draft where "G.694" (rather than G.694.1 or G.694.2) appears (3 places); 3) Clause 3 and Figure 1 in particular: the term "DWDM" (which stands for Dense Wavelength Division Multiplexing) seems to be applied to optical multiplexers/de-multiplexers. Q6 suggests that it would be better to refer to these devices as "DWDM multiplexer & demultiplexer"; 4) Clause 4.1: reference (2 instances) is made to "tables" in G.694.1. It is suggested to replace this by "grids"; 5) Clause 4.2: the "order" in the IETF wavelength label is currently indicated as: Grid, C.S., reserved, n; Q.6/15 has understood from the meeting on 20 March that there was a agreement to define this as: Grid, C.S., n, reserved, where n is defined to be bits 7 to 22 and bits 23 to 32 are reserved. The latter bit allocation is the one that has been included in draft revised G.697. Except comment 5, all the comments are editorial. In draft-ietf-ccamp-gmpls-g-694-lambda-labels-05.txt, the following changes are made: 1) The comments provided by ITU-T Q6/15 via liaison (COM15-LS78-E) are incorporated except the last comment, which is not adopted. 2) Terms such as PXC, DWDM and CSPF, are explicitly described. 3) The new IETF draft template is used for this version. 4) Added Takehiro Tsuritani and Dan Li as the editors/authors of this draft. For comment 5, as we have discussed in the mailing list before, the current format is more convenient for the code implementation, so we would like to keep the current format, which is described in current draft. Best regards, Authors of lambda-label draft ----- Original Message ----- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ccamp@ietf.org Sent: Monday, December 07, 2009 10:30 AM Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-g-694-lambda-labels-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 : Generalized Labels for Lambda-Switching Capable Label Switching Routers Author(s) : T. Otani, et al. Filename : draft-ietf-ccamp-gmpls-g-694-lambda-labels-05.txt Pages : 13 Date : 2009-12-06 Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. However, [RFC3471] has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength continuity is not considered. In order to achieve interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format, being compliant with either [G.694.1](DWDM-grid) or [G.694.2](CWDM-grid). Moreover some consideration on how to ensure lambda continuity with RSVP-TE is provided. This document is a companion to the Generalized Multi- Protocol Label Switching (GMPLS) signaling. It defines the label format when Lambda Switching is requested in an all optical network. 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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-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. -------------------------------------------------------------------------------- _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --Boundary_(ID_QBJtNh3dIbgY+574R7FTog) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC4zNjI3IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkhpLDwvRk9O VD48L0RJVj4NCjxESVY+DQo8UD48Rk9OVCBmYWNlPUFyaWFsPldlIGhhdmUgcmVjZWl2ZWQgdGhl IGxpYWlzb24gZnJvbSB0aGUgSVRVLVQgUTYvMTUgb24gMjd0aCANCk9jdG9iZXIgMjAwOS4gUGxl YXNlIHJlZmVyIHRvOjwvRk9OVD48L1A+DQo8UD48QSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvY3VtZW50cy9MSUFJU09OL2ZpbGU3MTgucGRmIj48Rk9OVCANCmZhY2U9QXJp YWw+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2N1bWVudHMvTElBSVNPTi9maWxlNzE4 LnBkZjwvRk9OVD48L0E+PC9QPg0KPFA+PEZPTlQgZmFjZT1BcmlhbD5Tb21lIGNvbW1lbnRzJm5i c3A7d2l0aCByZXNwZWN0IA0KdG8mbmJzcDtkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWctNjk0LWxh bWJkYS1sYWJlbHMtMDQudHh0IGFyZSBwcm92aWRlZCBpbiB0aGUgDQpsaWFpc29uOjwvRk9OVD48 L1A+DQo8UD48Rk9OVCBmYWNlPUFyaWFsPjEpIFJlbW92YWwgb2YgcmVmZXJlbmNlIHRvIEcuNjk0 IGluIHRpdGxlIG9mIGRvY3VtZW50OzxCUj4yKSANCkFic3RyYWN0OiByZXBsYWNlIJNJVFUtVCBH LjY5NJQgKHdoaWNoIGRvZXNuknQgZXhpc3QgaW4gdGhpcyBmb3JtKSB3aXRoIJNlaXRoZXIgDQpH LjY5NC4xIChEV0RNLWdyaWQpIG9yIEcuNjk0LjIgKENXRE0tZ3JpZCmULiBNYWtlIGVxdWl2YWxl bnQgY2hhbmdlcyBlbHNld2hlcmUgDQppbiB0aGUgZHJhZnQgd2hlcmUgk0cuNjk0lCAocmF0aGVy IHRoYW4gRy42OTQuMSBvciBHLjY5NC4yKSBhcHBlYXJzICgzIA0KcGxhY2VzKTs8QlI+MykgQ2xh dXNlIDMgYW5kIEZpZ3VyZSAxIGluIHBhcnRpY3VsYXI6IHRoZSB0ZXJtIJNEV0RNlCAod2hpY2gg DQpzdGFuZHMgZm9yIERlbnNlIFdhdmVsZW5ndGggRGl2aXNpb24gTXVsdGlwbGV4aW5nKSBzZWVt cyB0byBiZSBhcHBsaWVkIHRvIA0Kb3B0aWNhbCBtdWx0aXBsZXhlcnMvZGUtbXVsdGlwbGV4ZXJz LiBRNiBzdWdnZXN0cyB0aGF0IGl0IHdvdWxkIGJlIGJldHRlciB0byANCnJlZmVyIHRvIHRoZXNl IGRldmljZXMgYXMgk0RXRE0gbXVsdGlwbGV4ZXIgJmFtcDsgZGVtdWx0aXBsZXhlcpQ7PEJSPjQp IENsYXVzZSANCjQuMTogcmVmZXJlbmNlICgyIGluc3RhbmNlcykgaXMgbWFkZSB0byCTdGFibGVz lCBpbiBHLjY5NC4xLiBJdCBpcyBzdWdnZXN0ZWQgdG8gDQpyZXBsYWNlIHRoaXMgYnkgk2dyaWRz lDs8QlI+NSkgQ2xhdXNlIDQuMjogdGhlIJNvcmRlcpQgaW4gdGhlIElFVEYgd2F2ZWxlbmd0aCAN CmxhYmVsIGlzIGN1cnJlbnRseSBpbmRpY2F0ZWQgYXM6IEdyaWQsIEMuUy4sIHJlc2VydmVkLCBu OyBRLjYvMTUgaGFzIHVuZGVyc3Rvb2QgDQpmcm9tIHRoZSBtZWV0aW5nIG9uIDIwIE1hcmNoIHRo YXQgdGhlcmUgd2FzIGEgYWdyZWVtZW50IHRvIGRlZmluZSB0aGlzIGFzOiBHcmlkLCANCkMuUy4s IG4sIHJlc2VydmVkLCB3aGVyZSBuIGlzIGRlZmluZWQgdG8gYmUgYml0cyA3IHRvIDIyIGFuZCBi aXRzIDIzIHRvIDMyIGFyZSANCnJlc2VydmVkLiBUaGUgbGF0dGVyIGJpdCBhbGxvY2F0aW9uIGlz IHRoZSBvbmUgdGhhdCBoYXMgYmVlbiBpbmNsdWRlZCBpbiBkcmFmdCANCnJldmlzZWQgRy42OTcu PC9GT05UPiZuYnNwOzwvUD4NCjxQPjxGT05UIGZhY2U9QXJpYWw+RXhjZXB0IGNvbW1lbnQgNSwg YWxsIHRoZSBjb21tZW50cyBhcmUgZWRpdG9yaWFsLiANCkluJm5ic3A7Jm5ic3A7ZHJhZnQtaWV0 Zi1jY2FtcC1nbXBscy1nLTY5NC1sYW1iZGEtbGFiZWxzLTA1LnR4dCwgdGhlIGZvbGxvd2luZyAN CmNoYW5nZXMgYXJlIG1hZGU6PC9GT05UPjwvUD4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD4xKSZu YnNwO1RoZSBjb21tZW50cyBwcm92aWRlZCBieSBJVFUtVCBRNi8xNSB2aWEgbGlhaXNvbiANCihD T00xNS1MUzc4LUUpIGFyZSBpbmNvcnBvcmF0ZWQgZXhjZXB0IHRoZSBsYXN0IGNvbW1lbnQsIHdo aWNoJm5ic3A7aXMgbm90IA0KYWRvcHRlZC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWw+MikgVGVybXMgc3VjaCBhcyBQWEMsIERXRE0gYW5kIENTUEYsIGFyZSBleHBsaWNpdGx5 IA0KZGVzY3JpYmVkLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD4zKSBUaGUg bmV3IElFVEYgZHJhZnQgdGVtcGxhdGUgaXMgdXNlZCBmb3IgdGhpcyANCnZlcnNpb24uPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjQpIEFkZGVkJm5ic3A7VGFrZWhpcm8gVHN1 cml0YW5pIGFuZCZuYnNwO0RhbiBMaSZuYnNwO2FzIA0KdGhlJm5ic3A7ZWRpdG9ycy9hdXRob3Jz IG9mIHRoaXMgZHJhZnQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5Gb3IgY29tbWVudCA1LCBhcyB3 ZSBoYXZlIGRpc2N1c3NlZCBpbiB0aGUgbWFpbGluZyBsaXN0IA0KYmVmb3JlLCB0aGUgY3VycmVu dCBmb3JtYXQgaXMgbW9yZSBjb252ZW5pZW50IGZvciB0aGUgY29kZSBpbXBsZW1lbnRhdGlvbiwg c28gd2UgDQp3b3VsZCBsaWtlIHRvIGtlZXAgdGhlIGN1cnJlbnQgZm9ybWF0LCB3aGljaCBpcyBk ZXNjcmliZWQgaW4gY3VycmVudCANCmRyYWZ0LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+QmVzdCBy ZWdhcmRzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+QXV0aG9ycyBvZiZuYnNwO2xhbWJkYS1sYWJl bCBkcmFmdCZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8UD4mbmJzcDs8L1A+PC9ESVY+DQo8RElWIHN0eWxlPSJGT05UOiA5cHQg JiMyMzQzNTsmIzIwMzA3OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCjxESVYgc3R5 bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4g PEEgDQp0aXRsZT1JbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcgDQpocmVmPSJtYWlsdG86SW50ZXJu ZXQtRHJhZnRzQGlldGYub3JnIj5JbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmc8L0E+IDwvRElWPg0K PERJVj48Qj5Ubzo8L0I+IDxBIHRpdGxlPWktZC1hbm5vdW5jZUBpZXRmLm9yZyANCmhyZWY9Im1h aWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvQT4gPC9E SVY+DQo8RElWPjxCPkNjOjwvQj4gPEEgdGl0bGU9Y2NhbXBAaWV0Zi5vcmcgDQpocmVmPSJtYWls dG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9BPiA8L0RJVj4NCjxESVY+PEI+U2Vu dDo8L0I+IE1vbmRheSwgRGVjZW1iZXIgMDcsIDIwMDkgMTA6MzAgQU08L0RJVj4NCjxESVY+PEI+ U3ViamVjdDo8L0I+IFtDQ0FNUF0gSS1EIA0KQWN0aW9uOmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMt Zy02OTQtbGFtYmRhLWxhYmVscy0wNS50eHQ8L0RJVj48L0RJVj4NCjxESVY+PEJSPjwvRElWPkEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIA0KSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxCUj5UaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBDb21tb24gQ29udHJvbCANCmFuZCBNZWFzdXJlbWVudCBQbGFuZSBXb3JraW5nIEdyb3VwIG9m IHRoZSANCklFVEYuPEJSPjxCUj48QlI+VGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo6IEdlbmVyYWxpemVkIExhYmVscyBm b3IgTGFtYmRhLVN3aXRjaGluZyBDYXBhYmxlIExhYmVsIFN3aXRjaGluZyANClJvdXRlcnM8QlI+ QXV0aG9yKHMpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogVC4gT3Rhbmks IGV0IA0KYWwuPEJSPkZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDogDQpkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWctNjk0LWxhbWJkYS1sYWJlbHMtMDUu dHh0PEJSPlBhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KOiAxMzxCUj5EYXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogDQoyMDA5LTEyLTA2PEJS PjxCUj5UZWNobm9sb2d5IGluIHRoZSBvcHRpY2FsIGRvbWFpbiBpcyBjb25zdGFudGx5IGV2b2x2 aW5nIGFuZCBhcyANCmEgPEJSPmNvbnNlcXVlbmNlIG5ldyBlcXVpcG1lbnQgcHJvdmlkaW5nIGxh bWJkYSBzd2l0Y2hpbmcgY2FwYWJpbGl0eSBoYXMgDQo8QlI+YmVlbiBkZXZlbG9wZWQgYW5kIGlz IGN1cnJlbnRseSBiZWluZyBkZXBsb3llZC4gSG93ZXZlciwgW1JGQzM0NzFdIDxCUj5oYXMgDQpk ZWZpbmVkIHRoYXQgYSB3YXZlbGVuZ3RoIGxhYmVsIChzZWN0aW9uIDMuMi4xLjEpICJvbmx5IGhh cyA8QlI+c2lnbmlmaWNhbmNlIA0KYmV0d2VlbiB0d28gbmVpZ2hib3JzIiBhbmQgZ2xvYmFsIHdh dmVsZW5ndGggY29udGludWl0eSA8QlI+aXMgbm90IGNvbnNpZGVyZWQuIA0KSW4gb3JkZXIgdG8g YWNoaWV2ZSBpbnRlcm9wZXJhYmlsaXR5IGluIGEgbmV0d29yayA8QlI+Y29tcG9zZWQgb2YgbmV4 dCANCmdlbmVyYXRpb24gbGFtYmRhIHN3aXRjaC1jYXBhYmxlIGVxdWlwbWVudCwgdGhpcyA8QlI+ ZG9jdW1lbnQgZGVmaW5lcyBhIHN0YW5kYXJkIA0KbGFtYmRhIGxhYmVsIGZvcm1hdCwgYmVpbmcg Y29tcGxpYW50IDxCUj53aXRoIGVpdGhlciBbRy42OTQuMV0oRFdETS1ncmlkKSBvciANCltHLjY5 NC4yXShDV0RNLWdyaWQpLiBNb3Jlb3ZlciA8QlI+c29tZSBjb25zaWRlcmF0aW9uIG9uIGhvdyB0 byBlbnN1cmUgbGFtYmRhIA0KY29udGludWl0eSB3aXRoIFJTVlAtVEUgPEJSPmlzIHByb3ZpZGVk LiBUaGlzIGRvY3VtZW50IGlzIGEgY29tcGFuaW9uIHRvIHRoZSANCkdlbmVyYWxpemVkIE11bHRp LTxCUj5Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKEdNUExTKSBzaWduYWxpbmcuIEl0IGRlZmlu ZXMgdGhlIA0KbGFiZWwgPEJSPmZvcm1hdCB3aGVuIExhbWJkYSBTd2l0Y2hpbmcgaXMgcmVxdWVz dGVkIGluIGFuIGFsbCBvcHRpY2FsIG5ldHdvcmsuIA0KPEJSPjxCUj5Db252ZW50aW9ucyB1c2Vk IGluIHRoaXMgZG9jdW1lbnQgPEJSPjxCUj5UaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgDQpO T1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgPEJSPiJTSE9VTEQiLCAiU0hP VUxEIE5PVCIsIA0KIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMg PEJSPmRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCANCmFzIGRlc2NyaWJlZCBpbiBbUkZD MjExOV0uPEJSPjxCUj5BIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8QlI+PEEgDQpo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1w LWdtcGxzLWctNjk0LWxhbWJkYS1sYWJlbHMtMDUudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWctNjk0LWxhbWJkYS1sYWJlbHMt MDUudHh0PC9BPjxCUj48QlI+SW50ZXJuZXQtRHJhZnRzIA0KYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6PEJSPjxBIA0KaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy8iPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9BPjxCUj48 QlI+QmVsb3cgDQppcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50 IG1haWwgcmVhZGVyPEJSPmltcGxlbWVudGF0aW9uIHRvIA0KYXV0b21hdGljYWxseSByZXRyaWV2 ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGU8QlI+SW50ZXJuZXQtRHJhZnQuPEJSPg0KPFA+DQo8 SFI+DQoNCjxQPjwvUD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxCUj5DQ0FNUCBtYWlsaW5nIA0KbGlzdDxCUj48QSBocmVmPSJtYWlsdG86Q0NBTVBAaWV0 Zi5vcmciPkNDQU1QQGlldGYub3JnPC9BPjxCUj48QSANCmhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXAiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2NhbXA8L0E+PEJSPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_QBJtNh3dIbgY+574R7FTog)-- From lberger@labn.net Mon Dec 7 12:07:52 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9643A6944 for ; Mon, 7 Dec 2009 12:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ZprQpdU+Yr1G for ; Mon, 7 Dec 2009 12:07:51 -0800 (PST) Received: from outbound-mail-319.bluehost.com (outbound-mail-319.bluehost.com [67.222.54.251]) by core3.amsl.com (Postfix) with SMTP id 2C6F43A6933 for ; Mon, 7 Dec 2009 12:07:51 -0800 (PST) Received: (qmail 731 invoked by uid 0); 7 Dec 2009 20:07:41 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy6.bluehost.com with SMTP; 7 Dec 2009 20:07:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=qt6LtNjdtf+m5q5J5n4h/i8TvF1bb+M0r9E4rzS3PwT6PnTlRtZH9XiWQXYPJYEzrUY0OK/BzNQTXWnXNO9ECYQo1m7qfc3dbotBKIN4PQKOEzDFKZlPpJmbA5p4DvHO; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NHjrw-00075K-HX; Mon, 07 Dec 2009 13:07:40 -0700 Message-ID: <4B1D60A8.2060605@labn.net> Date: Mon, 07 Dec 2009 15:08:08 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: CCAMP , draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org References: <4B06FB22.8090301@labn.net> In-Reply-To: <4B06FB22.8090301@labn.net> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 20:07:52 -0000 Authors, I have some comments on the draft (sorry about being late), most of which are at the nit level. I do have one more significant editorial comment: - section 4.5 defines a fairly significant portion of this extension but does so without any real use of RFC2119 normative language. I think this section needs to be explicit about how nodes are to process objects and messages and therefore should be revised to use formal normative language. References to existing defined procedures are beneficial as well. I'd expect this revision to translate into formalization of current technical details and no change in mechanisms. The following are my other comments: - Section 1: You should add references for each technology referenced in this section. It's probably worth mentioning that the scope of the document is limited to scenarios where all member signals are controlled using mechanisms defined in this document. - Section 2: This section should be removed. (Generally such sections shouldn't be numbered so that when they are dropped all sections in the document doesn't get renumbered.) - Section 3.2: Same comment as before, not that only scenarios that use common mechanism are supported by this extension. -Section 3.3: The type of the member signal that the VCG will contain, e.g., VC-3, VC-4, etc. The total number of members to be in the VCG. This provides the endpoints in both the LCAS and non-LCAS case with information on which to accept or reject the request, and in the non-LCAS case will let the receiving endpoint know when all members of the VCG have been established. Identification of the VCG and its associated members. This provides information that allows the endpoints to differentiate multiple VCGs and to tell what members (LSPs) to associate with a particular VCG. Text should be indented to indicate that it's part of a list -Section 4.1 4.1. VCGs Composed of a Single Co-Signaled Member Set Note that this section is for informational purposes only. Perhaps this should be in it's own section? - Section 4.2.1: VCG Call setup information signaled via the Notify message with the Call management bit (C-bit) set: Do you mean? VCG Call setup information is signaled a new CALL_ATTRIBUTES Object TLV with the following information: -Section 4.3 We define a new 4.4. VCAT CALL_ATTRIBUTES TLV Object For use in the CALL_ATTRIBUTES object in Notify messages we define the following VCAT related TLV: It looks like a section heading made it's way into the text. Should the text read: We define a new VCAT CALL_ATTRIBUTES TLV Object for use in the CALL_ATTRIBUTES object in Notify messages with the following format: - Section 4.5 See first comment. - Section 4.5.3 The following aren't clear and should be rephrased: Given a VCAT call without an associated VCG such as that set up in section 4.5.2. one associates it with a VCG as follows. and To take a particular VCG out of service, rather than just removing all its member, a special flag element is included. - Section 6 This section should be revised to follow rfc5226. It also looks like you are asking IANA to establish a registry for Signal types, is this correct? Lou On 11/20/2009 3:25 PM, Lou Berger wrote: > As discussed in last week's session, it's time for the working group to > last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas > > Please send your comments to the list or the authors&chairs > before the last call closes in two weeks, on December 4, 2009. > > Thank you, > Lou (and Deborah) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From lberger@labn.net Mon Dec 7 15:39:03 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB6E3A6A05 for ; Mon, 7 Dec 2009 15:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 3bAu8VSonnc9 for ; Mon, 7 Dec 2009 15:39:02 -0800 (PST) Received: from outbound-mail-134.bluehost.com (outbound-mail-134.bluehost.com [67.222.39.24]) by core3.amsl.com (Postfix) with SMTP id B8C683A69D2 for ; Mon, 7 Dec 2009 15:38:51 -0800 (PST) Received: (qmail 32550 invoked by uid 0); 7 Dec 2009 23:38:41 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy4.bluehost.com with SMTP; 7 Dec 2009 23:38:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=mVTz03fyOcHriVtKQpxTMaGPymkcqo0C0pNju7C/+0FPpFJ7oGhkiPoF+/zPU50eX69Cum4LxxNOB5NhsX904p6MJchBnQt3J/ygeGg/pd7xrYyxQnrn2FYdXaTkaU0F; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NHnA9-0004MY-Jg; Mon, 07 Dec 2009 16:38:41 -0700 Message-ID: <4B1D921D.20905@labn.net> Date: Mon, 07 Dec 2009 18:39:09 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: CCAMP , draft-ietf-ccamp-gmpls-vcat-lcas@tools.ietf.org References: <4B06FB22.8090301@labn.net> In-Reply-To: <4B06FB22.8090301@labn.net> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 23:39:03 -0000 This working group last call is complete. Authors, Please update your document according to comments received. Please also let the working group know how you propose to resolve each comment. Please feel free to discuss proposed resolutions on the list prior to issuing an updated document where appropriate. Lou On 11/20/2009 3:25 PM, Lou Berger wrote: > As discussed in last week's session, it's time for the working group to > last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas > > Please send your comments to the list or the authors&chairs > before the last call closes in two weeks, on December 4, 2009. > > Thank you, > Lou (and Deborah) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From cbenson@adax.com Mon Dec 7 17:31:56 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745D83A68F9; Mon, 7 Dec 2009 17:31:56 -0800 (PST) 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 wHmrk267YAsS; Mon, 7 Dec 2009 17:31:55 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id D9D603A696C; Mon, 7 Dec 2009 17:31:54 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id B7308120990; Mon, 7 Dec 2009 17:31:44 -0800 (PST) Received: by adax (Postfix, from userid 243) id C6C9F8E52B; Mon, 7 Dec 2009 17:32:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id BFD6F8E52A; Mon, 7 Dec 2009 17:32:08 -0800 (PST) Date: Mon, 7 Dec 2009 17:32:08 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Loa Andersson In-Reply-To: <4B17C57B.40200@pi.nu> Message-ID: References: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> <4B16809A.3040409@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AC8@ESESSCMS0355.eemea.ericsson.se> <4B17C57B.40200@pi.nu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Mon, 07 Dec 2009 18:59:30 -0800 Cc: "ccamp@ietf.org" , Attila Takacs , "mpls-tp@ietf.org" Subject: Re: [CCAMP] [mpls-tp] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 01:31:56 -0000 Loa and Attila, When viewing the four possibilities as enumerated by Loa, I wonder if the fourth might be better thus: 4. A flag is not set, but there is sub-tlv - this will result in the function being TURNED OFF, AND is treated as an error condition: an error message should be returned (indicating incompatible sub-tlv). My reason for suggesting this is in case there is any misidentification of whether a sub-tlv is associated with the flag being considered or not. In all the other three cases, the value of the flag is sufficient to determine the resultant state of the function. Perhaps it would be "cleaner" if that were so in this fourth case as well. If a peer were using some unrelated experimental extension, but accidentally re-used a sub-tlv tag associated with the flag under examination, then it would be unable to turn off the flag's feature. This is an error case that "shouldn't" happen, but it seems cleaner to me if the flag alone can tell us the eventual state of the function, without also needing the ability to associate a sub-tlv (or set of sub-tlvs) with the cleared flag, to identify Loa's case 4. Just a thought. With thanks, from Chris Benson. On Thu, 3 Dec 2009, Loa Andersson wrote: >> Date: Thu, 03 Dec 2009 15:04:43 +0100 >> From: Loa Andersson >> To: Attila Takacs >> Cc: "ccamp@ietf.org" , "mpls-tp@ietf.org" >> Subject: Re: [mpls-tp] [CCAMP] Thoughts on updating the OAM Configuration >> fwk and the MPLS-TP OAM configuration drafts >> >> Attila, >> >> OK great, then we need to update that in the framework. >> >> I also have a question on the relationship between flags and >> the sub-tlvs. >> >> I think there are four possibilities: >> >> 1. A flag is set, but there is no sub-tlv >> - the action here should be to turn on the function the >> flag indicates using default values >> I also think that if a function indicated by flag is >> running, it should be left unchanged, even if it is not >> running on default values >> >> 2. A flag is set, and there is a sub-tlv >> - the action here would be to turn on the function indicated by >> the flag, using the parameters found in sub-tlv >> >> 3. A flag is not set, and there is no sub-tlv >> - the action here would be to turn off any function that has >> been configured earlier >> >> 4. A flag is not set, but there is sub-tlv >> - this should be treated as an error conditions and an >> error message should be returned, no changes to the configured >> OAM should be made. >> >> Is this correctly understood? >> >> /Loa >> >> Attila Takacs wrote: >> > Hi Loa, >> > >> > It can be carried in the LSP_ATTRIBUTES Object in the Resv message; so it >> > can be used for timer negotiation and discriminator synchronization if >> > needed. >> > >> > Attila >> > >> > > -----Original Message----- >> > > From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, December 02, >> > > 2009 3:59 PM >> > > To: Attila Takacs >> > > Cc: ccamp@ietf.org; mpls-tp@ietf.org >> > > Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration fwk and >> > > the MPLS-TP OAM configuration drafts >> > > >> > > Attila, >> > > >> > > thanks - I think things are converging quite a bit now. >> > > >> > > May the OAM Configuration TLV specified in the OAM Configuration >> > > Framweork only be present in the PATH message? >> > > >> > > /Loa >> > > >> > > Attila Takacs wrote: >> > > > Hi all, >> > > > >> > > > Some thoughts on updating the OAM Configuration fwk and the MPLS-TP >> > > > OAM configuration drafts. >> > > > >> > > > I think we need to extend the OAM Function flags (described in >> > > > draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: >> > > > >> > > > -CC >> > > > -CV >> > > > -PM Loss >> > > > -PM Delay >> > > > -Fault Management signals >> > > > >> > > > >> > > > With regards to BFD I see three operation vs. configuration modes: >> > > > >> > > > 1) Set CC in the flags and only bootstrap the BFD session, >> > > by sending >> > > > the local discriminator values in RSVP-TE and leave timer >> > > negotiation >> > > > to BFD control messages. This is similar to LSP Ping based >> > > > bootstrapping described in draft-ietf-bfd-mpls-07.txt. >> > > > >> > > > 2) Set CC in the flags but configure the timers via the >> > > control plane, >> > > > this should correspond to "CC mode" in >> > > draft-asm-mpls-tp-bfd-cc-cv-01. >> > > > We may include the min/max intervals and by doing so >> > > support initial >> > > > timer negotiation in control plane. However, we may need a >> > > flag in CC >> > > > configuration sub-TLV (now in >> > > > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called >> > > "Suggested TX >> > > > Interval sub-TLV") to indicate whether data plane timer >> > > renegotiation >> > > > is enabled or disabled (i.e., subsequently via BFD control >> > > messages). >> > > > This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be >> > > > disabled for TP LSPs by default. >> > > > >> > > > 3) In case of "full" MPLS-TP OAM support any of the flags >> > > could be set >> > > > as needed, reflecting "CV/CC mode" described in >> > > > draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as >> > > > described in draft-frost-mpls-tp-loss-delay-00 and >> > > management signals >> > > > as given in draft-sfv-mpls-tp-fault-00. >> > > > >> > > > >> > > > >> > > > To configure CC we will need to add >> > > > -enable/disable DP timer re-negotiation -PHB to identify >> > > priority and >> > > > drop precedence of CC packets >> > > > >> > > > When it comes to CV, it would be interesting to discuss >> > > whether only >> > > > the OAM identifiers described in >> > > draft-ietf-mpls-tp-identifiers-00 are >> > > > ought to be supported. If so, those could be derived from RSVP-TE >> > > > signaling without the need to carry them explicitly in MPLS-TP OAM >> > > > Configuration sub-TLVs (now called Source unique MEP_ID sub-TLV in >> > > > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). >> > > > >> > > > For Performance Monitoring Loss/Delay we need to add new TLVs, >> > > > carrying -measurement interval -possibly loss/delay bound >> > > thresholds >> > > > (given we what these for MPLS-TP) that could be used to assess the >> > > > quality of the connection and may eventually trigger >> > > protection -PHB >> > > > of control packets if we want to set it differently from CC >> > > packets or >> > > > from data traffic. >> > > > >> > > > For the Fault Management Signals, I would add a new "Fault >> > > Management >> > > > Signals sub-TLV" carrying: >> > > > -Enabled signals flags: AIS, LDI, LKR, CFS (which, except CFS, are >> > > > specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault >> > > > indication messages -flag to enable/disable explicitly >> > > clear of faults >> > > > -PHB of fault management packets >> > > > >> > > > >> > > > Another thing we may want to consider is adding a sub-TLV to set >> > > > consequent actions that are configurable. This is described to some >> > > > extent in the MPLS-TP OAM Framework. The defects identified include: >> > > > Loss Of Continuity defect, Mis-connectivity defect, MEP >> > > > misconfiguration defect, Period Misconfiguration defect. >> > > > >> > > > An operator may want to configure if the consequence of LOC >> > > should be >> > > > the blocking or non-blocking of outgoing data traffic. Similarly it >> > > > may be useful to configure whether the "Period >> > > Misconfiguration defect" >> > > > should result in a signal fail condition or not. >> > > > >> > > > >> > > > I plan to send detailed text to the editors of >> > > > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the lines >> > > > described above. Please comment! >> > > > Thanks, >> > > > Attila >> > > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > CCAMP mailing list >> > > > CCAMP@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/ccamp >> > > -- >> > > >> > > >> > > Loa Andersson email: loa.andersson@ericsson.com >> > > Sr Strategy and Standards Manager loa@pi.nu >> > > Ericsson Inc phone: +46 10 717 52 13 >> > > +46 767 72 92 13 >> >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> >> From zhang.fei3@zte.com.cn Mon Dec 7 19:28:12 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E833A6806; Mon, 7 Dec 2009 19:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.314 X-Spam-Level: X-Spam-Status: No, score=-97.314 tagged_above=-999 required=5 tests=[AWL=-4.524, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 leRGQRI5jV1c; Mon, 7 Dec 2009 19:28:11 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id C07273A681F; Mon, 7 Dec 2009 19:28:09 -0800 (PST) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91102225802621; Tue, 8 Dec 2009 11:05:05 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 83949.2785726770; Tue, 8 Dec 2009 11:26:53 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id nB83RS9Y038866; Tue, 8 Dec 2009 11:27:28 +0800 (CST) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> To: "Attila Takacs" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 8 Dec 2009 11:27:22 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-12-08 11:27:22, Serialize complete at 2009-12-08 11:27:22 Content-Type: multipart/alternative; boundary="=_alternative 0013780D48257686_=" X-MAIL: mse2.zte.com.cn nB83RS9Y038866 Cc: ccamp@ietf.org, ccamp-bounces@ietf.org, mpls-tp@ietf.org Subject: [CCAMP] =?gb2312?b?tPC4tDogIFRob3VnaHRzIG9uIHVwZGF0aW5nIHRoZSBP?= =?gb2312?b?QU0gQ29uZmlndXJhdGlvbiBmd2sgYW5kIHRoZQlNUExTLVRQIE9BTSBjb25m?= =?gb2312?b?aWd1cmF0aW9uIGRyYWZ0cw==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 03:28:13 -0000 This is a multipart message in MIME format. --=_alternative 0013780D48257686_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYXR0aWxhDQoNCjEpIFNldCBDQyBpbiB0aGUgZmxhZ3MgYW5kIG9ubHkgYm9vdHN0cmFwIHRo ZSBCRkQgc2Vzc2lvbiwgYnkgc2VuZGluZw0KdGhlIGxvY2FsIGRpc2NyaW1pbmF0b3IgdmFsdWVz IGluIFJTVlAtVEUgYW5kIGxlYXZlIHRpbWVyIG5lZ290aWF0aW9uIHRvDQpCRkQgY29udHJvbCBt ZXNzYWdlcy4gVGhpcyBpcyBzaW1pbGFyIHRvIExTUCBQaW5nIGJhc2VkIGJvb3RzdHJhcHBpbmcN CmRlc2NyaWJlZCBpbiBkcmFmdC1pZXRmLWJmZC1tcGxzLTA3LnR4dC4NCg0KMikgU2V0IENDIGlu IHRoZSBmbGFncyBidXQgY29uZmlndXJlIHRoZSB0aW1lcnMgdmlhIHRoZSBjb250cm9sIHBsYW5l LA0KdGhpcyBzaG91bGQgY29ycmVzcG9uZCB0byAiQ0MgbW9kZSIgaW4gZHJhZnQtYXNtLW1wbHMt dHAtYmZkLWNjLWN2LTAxLg0KV2UgbWF5IGluY2x1ZGUgdGhlIG1pbi9tYXggaW50ZXJ2YWxzIGFu ZCBieSBkb2luZyBzbyBzdXBwb3J0IGluaXRpYWwNCnRpbWVyIG5lZ290aWF0aW9uIGluIGNvbnRy b2wgcGxhbmUuIEhvd2V2ZXIsIHdlIG1heSBuZWVkIGEgZmxhZyBpbiBDQw0KY29uZmlndXJhdGlv biBzdWItVExWIChub3cgaW4NCmRyYWZ0LWJlbGxhZ2FtYmEtY2NhbXAtcnN2cC10ZS1tcGxzLXRw LW9hbS1leHQtMDMgY2FsbGVkICJTdWdnZXN0ZWQgVFgNCkludGVydmFsIHN1Yi1UTFYiKSB0byBp bmRpY2F0ZSB3aGV0aGVyIGRhdGEgcGxhbmUgdGltZXIgcmVuZWdvdGlhdGlvbiBpcw0KZW5hYmxl ZCBvciBkaXNhYmxlZCAoaS5lLiwgc3Vic2VxdWVudGx5IHZpYSBCRkQgY29udHJvbCBtZXNzYWdl cykuIFRoaXMsDQphcyBkZXNjcmliZWQgaW4gZHJhZnQtYXNtLW1wbHMtdHAtYmZkLWNjLWN2LTAx LCBzaG91bGQgYmUgZGlzYWJsZWQgZm9yDQpUUCBMU1BzIGJ5IGRlZmF1bHQuDQoNCklmIHdlIHdh bnQgdG8gY29uZmlndXJlIFBXIG9hbSB1c2luZyB0aGUgc2FtZSBwcm9jZWR1cmUsIGZvciB0aGUg c2V0dGluZyANCnVwIG9mIFBXIA0KaW4gdHdvIGRpcmVjdGlvbnMgaXMgaW5kZXBlbmRlbnQgKG5v dCBsaWtlIFJTVlAtVEUsIHBhdGggYW5kIHJlc3YgbWVzc2FnZSANCmFyZSBkZXBlbmRlbnQpLA0K d2UgaGFkIGJldHRlciBwdXQgdGhlIHRpbWVyIG5lZ290aWF0aW9uIGluIHRoZSBCRkQgc2Vzc2lv biBpdHNlbGYuDQpBbmQgaW4gdGhpcyB3YXksIGl0IHdpbGwgYmUgZWFzaWVyIHRvIHJlbmVnb3Rp YXRlIHRoZSB0aW1lciBpZiB0aGUgdHdvIA0KZW5kcyB3YW50IHRvIGNoYW5nZQ0KaXQuDQoNCg0K V2hlbiBpdCBjb21lcyB0byBDViwgaXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gZGlzY3VzcyB3 aGV0aGVyIG9ubHkgdGhlDQpPQU0gaWRlbnRpZmllcnMgZGVzY3JpYmVkIGluIGRyYWZ0LWlldGYt bXBscy10cC1pZGVudGlmaWVycy0wMCBhcmUgb3VnaHQNCnRvIGJlIHN1cHBvcnRlZC4gSWYgc28s IHRob3NlIGNvdWxkIGJlIGRlcml2ZWQgZnJvbSBSU1ZQLVRFIHNpZ25hbGluZw0Kd2l0aG91dCB0 aGUgbmVlZCB0byBjYXJyeSB0aGVtIGV4cGxpY2l0bHkgaW4gTVBMUy1UUCBPQU0gQ29uZmlndXJh dGlvbg0Kc3ViLVRMVnMgKG5vdyBjYWxsZWQgU291cmNlIHVuaXF1ZSBNRVBfSUQgc3ViLVRMViBp bg0KZHJhZnQtYmVsbGFnYW1iYS1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAtb2FtLWV4dC0wMykuIA0K DQpJIGFncmVlIHdpdGggeW91LCB0aGlzIHNob3VsZCBiZSB1cGRhdGVkIGluIHRoZSBmdXJ0dXJl IHZlcnNpb24uDQoNCkIuUi4NCg0KOikNCg0KRmVpDQoNCg0KDQoiQXR0aWxhIFRha2FjcyIgPEF0 dGlsYS5UYWthY3NAZXJpY3Nzb24uY29tPiANCreivP7IyzogIGNjYW1wLWJvdW5jZXNAaWV0Zi5v cmcNCjIwMDktMTItMDEgMTg6NDgNCg0KytW8/sjLDQo8Y2NhbXBAaWV0Zi5vcmc+LCA8bXBscy10 cEBpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KW0NDQU1QXSBUaG91Z2h0cyBvbiB1cGRhdGluZyB0 aGUgT0FNIENvbmZpZ3VyYXRpb24gZndrIGFuZCB0aGUgIE1QTFMtVFAgDQpPQU0gY29uZmlndXJh dGlvbiBkcmFmdHMNCg0KDQoNCg0KDQoNCkhpIGFsbCwNCg0KU29tZSB0aG91Z2h0cyBvbiB1cGRh dGluZyB0aGUgT0FNIENvbmZpZ3VyYXRpb24gZndrIGFuZCB0aGUgTVBMUy1UUCBPQU0NCmNvbmZp Z3VyYXRpb24gZHJhZnRzLg0KDQpJIHRoaW5rIHdlIG5lZWQgdG8gZXh0ZW5kIHRoZSBPQU0gRnVu Y3Rpb24gZmxhZ3MgKGRlc2NyaWJlZCBpbg0KZHJhZnQtaWV0Zi1jY2FtcC1vYW0tY29uZmlndXJh dGlvbi1md2stMDIpIHRvIGZpdmUgZmxhZ3M6DQoNCi1DQw0KLUNWDQotUE0gTG9zcw0KLVBNIERl bGF5DQotRmF1bHQgTWFuYWdlbWVudCBzaWduYWxzDQoNCg0KV2l0aCByZWdhcmRzIHRvIEJGRCBJ IHNlZSB0aHJlZSBvcGVyYXRpb24gdnMuIGNvbmZpZ3VyYXRpb24gbW9kZXM6DQoNCjEpIFNldCBD QyBpbiB0aGUgZmxhZ3MgYW5kIG9ubHkgYm9vdHN0cmFwIHRoZSBCRkQgc2Vzc2lvbiwgYnkgc2Vu ZGluZw0KdGhlIGxvY2FsIGRpc2NyaW1pbmF0b3IgdmFsdWVzIGluIFJTVlAtVEUgYW5kIGxlYXZl IHRpbWVyIG5lZ290aWF0aW9uIHRvDQpCRkQgY29udHJvbCBtZXNzYWdlcy4gVGhpcyBpcyBzaW1p bGFyIHRvIExTUCBQaW5nIGJhc2VkIGJvb3RzdHJhcHBpbmcNCmRlc2NyaWJlZCBpbiBkcmFmdC1p ZXRmLWJmZC1tcGxzLTA3LnR4dC4NCg0KMikgU2V0IENDIGluIHRoZSBmbGFncyBidXQgY29uZmln dXJlIHRoZSB0aW1lcnMgdmlhIHRoZSBjb250cm9sIHBsYW5lLA0KdGhpcyBzaG91bGQgY29ycmVz cG9uZCB0byAiQ0MgbW9kZSIgaW4gZHJhZnQtYXNtLW1wbHMtdHAtYmZkLWNjLWN2LTAxLg0KV2Ug bWF5IGluY2x1ZGUgdGhlIG1pbi9tYXggaW50ZXJ2YWxzIGFuZCBieSBkb2luZyBzbyBzdXBwb3J0 IGluaXRpYWwNCnRpbWVyIG5lZ290aWF0aW9uIGluIGNvbnRyb2wgcGxhbmUuIEhvd2V2ZXIsIHdl IG1heSBuZWVkIGEgZmxhZyBpbiBDQw0KY29uZmlndXJhdGlvbiBzdWItVExWIChub3cgaW4NCmRy YWZ0LWJlbGxhZ2FtYmEtY2NhbXAtcnN2cC10ZS1tcGxzLXRwLW9hbS1leHQtMDMgY2FsbGVkICJT dWdnZXN0ZWQgVFgNCkludGVydmFsIHN1Yi1UTFYiKSB0byBpbmRpY2F0ZSB3aGV0aGVyIGRhdGEg cGxhbmUgdGltZXIgcmVuZWdvdGlhdGlvbiBpcw0KZW5hYmxlZCBvciBkaXNhYmxlZCAoaS5lLiwg c3Vic2VxdWVudGx5IHZpYSBCRkQgY29udHJvbCBtZXNzYWdlcykuIFRoaXMsDQphcyBkZXNjcmli ZWQgaW4gZHJhZnQtYXNtLW1wbHMtdHAtYmZkLWNjLWN2LTAxLCBzaG91bGQgYmUgZGlzYWJsZWQg Zm9yDQpUUCBMU1BzIGJ5IGRlZmF1bHQuDQoNCjMpIEluIGNhc2Ugb2YgImZ1bGwiIE1QTFMtVFAg T0FNIHN1cHBvcnQgYW55IG9mIHRoZSBmbGFncyBjb3VsZCBiZSBzZXQNCmFzIG5lZWRlZCwgcmVm bGVjdGluZyAiQ1YvQ0MgbW9kZSIgZGVzY3JpYmVkIGluDQpkcmFmdC1hc20tbXBscy10cC1iZmQt Y2MtY3YtMDEsIGRlbGF5IGFuZCBsb3NzIG1lYXN1cmVtZW50IGFzIGRlc2NyaWJlZA0KaW4gZHJh ZnQtZnJvc3QtbXBscy10cC1sb3NzLWRlbGF5LTAwIGFuZCBtYW5hZ2VtZW50IHNpZ25hbHMgYXMg Z2l2ZW4gaW4NCmRyYWZ0LXNmdi1tcGxzLXRwLWZhdWx0LTAwLg0KDQoNCg0KVG8gY29uZmlndXJl IENDIHdlIHdpbGwgbmVlZCB0byBhZGQNCi1lbmFibGUvZGlzYWJsZSBEUCB0aW1lciByZS1uZWdv dGlhdGlvbg0KLVBIQiB0byBpZGVudGlmeSBwcmlvcml0eSBhbmQgZHJvcCBwcmVjZWRlbmNlIG9m IENDIHBhY2tldHMNCg0KV2hlbiBpdCBjb21lcyB0byBDViwgaXQgd291bGQgYmUgaW50ZXJlc3Rp bmcgdG8gZGlzY3VzcyB3aGV0aGVyIG9ubHkgdGhlDQpPQU0gaWRlbnRpZmllcnMgZGVzY3JpYmVk IGluIGRyYWZ0LWlldGYtbXBscy10cC1pZGVudGlmaWVycy0wMCBhcmUgb3VnaHQNCnRvIGJlIHN1 cHBvcnRlZC4gSWYgc28sIHRob3NlIGNvdWxkIGJlIGRlcml2ZWQgZnJvbSBSU1ZQLVRFIHNpZ25h bGluZw0Kd2l0aG91dCB0aGUgbmVlZCB0byBjYXJyeSB0aGVtIGV4cGxpY2l0bHkgaW4gTVBMUy1U UCBPQU0gQ29uZmlndXJhdGlvbg0Kc3ViLVRMVnMgKG5vdyBjYWxsZWQgU291cmNlIHVuaXF1ZSBN RVBfSUQgc3ViLVRMViBpbg0KZHJhZnQtYmVsbGFnYW1iYS1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAt b2FtLWV4dC0wMykuIA0KDQpGb3IgUGVyZm9ybWFuY2UgTW9uaXRvcmluZyBMb3NzL0RlbGF5IHdl IG5lZWQgdG8gYWRkIG5ldyBUTFZzLCBjYXJyeWluZw0KLW1lYXN1cmVtZW50IGludGVydmFsDQot cG9zc2libHkgbG9zcy9kZWxheSBib3VuZCB0aHJlc2hvbGRzIChnaXZlbiB3ZSB3aGF0IHRoZXNl IGZvciBNUExTLVRQKQ0KdGhhdCBjb3VsZCBiZSB1c2VkIHRvIGFzc2VzcyB0aGUgcXVhbGl0eSBv ZiB0aGUgY29ubmVjdGlvbiBhbmQgbWF5DQpldmVudHVhbGx5IHRyaWdnZXIgcHJvdGVjdGlvbg0K LVBIQiBvZiBjb250cm9sIHBhY2tldHMgaWYgd2Ugd2FudCB0byBzZXQgaXQgZGlmZmVyZW50bHkg ZnJvbSBDQyBwYWNrZXRzDQpvciBmcm9tIGRhdGEgdHJhZmZpYy4NCg0KRm9yIHRoZSBGYXVsdCBN YW5hZ2VtZW50IFNpZ25hbHMsIEkgd291bGQgYWRkIGEgbmV3ICJGYXVsdCBNYW5hZ2VtZW50DQpT aWduYWxzIHN1Yi1UTFYiIGNhcnJ5aW5nOg0KLUVuYWJsZWQgc2lnbmFscyBmbGFnczogQUlTLCBM REksIExLUiwgQ0ZTICh3aGljaCwgZXhjZXB0IENGUywgYXJlDQpzcGVjaWZpZWQgaW4gZHJhZnQt c2Z2LW1wbHMtdHAtZmF1bHQtMDApDQotcmVmcmVzaCB0aW1lciBvZiBmYXVsdCBpbmRpY2F0aW9u IG1lc3NhZ2VzDQotZmxhZyB0byBlbmFibGUvZGlzYWJsZSBleHBsaWNpdGx5IGNsZWFyIG9mIGZh dWx0cw0KLVBIQiBvZiBmYXVsdCBtYW5hZ2VtZW50IHBhY2tldHMgDQoNCg0KQW5vdGhlciB0aGlu ZyB3ZSBtYXkgd2FudCB0byBjb25zaWRlciBpcyBhZGRpbmcgYSBzdWItVExWIHRvIHNldA0KY29u c2VxdWVudCBhY3Rpb25zIHRoYXQgYXJlIGNvbmZpZ3VyYWJsZS4gVGhpcyBpcyBkZXNjcmliZWQg dG8gc29tZQ0KZXh0ZW50IGluIHRoZSBNUExTLVRQIE9BTSBGcmFtZXdvcmsuIFRoZSBkZWZlY3Rz IGlkZW50aWZpZWQgaW5jbHVkZToNCkxvc3MgT2YgQ29udGludWl0eSBkZWZlY3QsIE1pcy1jb25u ZWN0aXZpdHkgZGVmZWN0LCBNRVAgbWlzY29uZmlndXJhdGlvbg0KZGVmZWN0LCBQZXJpb2QgTWlz Y29uZmlndXJhdGlvbiBkZWZlY3QuDQoNCkFuIG9wZXJhdG9yIG1heSB3YW50IHRvIGNvbmZpZ3Vy ZSBpZiB0aGUgY29uc2VxdWVuY2Ugb2YgTE9DIHNob3VsZCBiZQ0KdGhlIGJsb2NraW5nIG9yIG5v bi1ibG9ja2luZyBvZiBvdXRnb2luZyBkYXRhIHRyYWZmaWMuIFNpbWlsYXJseSBpdCBtYXkNCmJl IHVzZWZ1bCB0byBjb25maWd1cmUgd2hldGhlciB0aGUgIlBlcmlvZCBNaXNjb25maWd1cmF0aW9u IGRlZmVjdCINCnNob3VsZCByZXN1bHQgaW4gYSBzaWduYWwgZmFpbCBjb25kaXRpb24gb3Igbm90 Lg0KDQoNCkkgcGxhbiB0byBzZW5kIGRldGFpbGVkIHRleHQgdG8gdGhlIGVkaXRvcnMgb2YNCmRy YWZ0LWJlbGxhZ2FtYmEtY2NhbXAtcnN2cC10ZS1tcGxzLXRwLW9hbS1leHQtMDMgYWxvbmcgdGhl IGxpbmVzDQpkZXNjcmliZWQgYWJvdmUuIFBsZWFzZSBjb21tZW50IQ0KVGhhbmtzLA0KQXR0aWxh DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Q0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQoNCg0K --=_alternative 0013780D48257686_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGF0dGlsYTwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTI+PHR0PjEpIFNldCBDQyBpbiB0aGUgZmxhZ3MgYW5kIG9ubHkg Ym9vdHN0cmFwIHRoZSBCRkQNCnNlc3Npb24sIGJ5IHNlbmRpbmc8YnI+DQp0aGUgbG9jYWwgZGlz Y3JpbWluYXRvciB2YWx1ZXMgaW4gUlNWUC1URSBhbmQgbGVhdmUgdGltZXIgbmVnb3RpYXRpb24g dG88YnI+DQpCRkQgY29udHJvbCBtZXNzYWdlcy4gVGhpcyBpcyBzaW1pbGFyIHRvIExTUCBQaW5n IGJhc2VkIGJvb3RzdHJhcHBpbmc8YnI+DQpkZXNjcmliZWQgaW4gZHJhZnQtaWV0Zi1iZmQtbXBs cy0wNy50eHQuPGJyPg0KPGJyPg0KMikgU2V0IENDIGluIHRoZSBmbGFncyBidXQgY29uZmlndXJl IHRoZSB0aW1lcnMgdmlhIHRoZSBjb250cm9sIHBsYW5lLDxicj4NCnRoaXMgc2hvdWxkIGNvcnJl c3BvbmQgdG8gJnF1b3Q7Q0MgbW9kZSZxdW90OyBpbiBkcmFmdC1hc20tbXBscy10cC1iZmQtY2Mt Y3YtMDEuPGJyPg0KV2UgbWF5IGluY2x1ZGUgdGhlIG1pbi9tYXggaW50ZXJ2YWxzIGFuZCBieSBk b2luZyBzbyBzdXBwb3J0IGluaXRpYWw8YnI+DQp0aW1lciBuZWdvdGlhdGlvbiBpbiBjb250cm9s IHBsYW5lLiBIb3dldmVyLCB3ZSBtYXkgbmVlZCBhIGZsYWcgaW4gQ0M8YnI+DQpjb25maWd1cmF0 aW9uIHN1Yi1UTFYgKG5vdyBpbjxicj4NCmRyYWZ0LWJlbGxhZ2FtYmEtY2NhbXAtcnN2cC10ZS1t cGxzLXRwLW9hbS1leHQtMDMgY2FsbGVkICZxdW90O1N1Z2dlc3RlZA0KVFg8YnI+DQpJbnRlcnZh bCBzdWItVExWJnF1b3Q7KSB0byBpbmRpY2F0ZSB3aGV0aGVyIGRhdGEgcGxhbmUgdGltZXIgcmVu ZWdvdGlhdGlvbg0KaXM8YnI+DQplbmFibGVkIG9yIGRpc2FibGVkIChpLmUuLCBzdWJzZXF1ZW50 bHkgdmlhIEJGRCBjb250cm9sIG1lc3NhZ2VzKS4gVGhpcyw8YnI+DQphcyBkZXNjcmliZWQgaW4g ZHJhZnQtYXNtLW1wbHMtdHAtYmZkLWNjLWN2LTAxLCBzaG91bGQgYmUgZGlzYWJsZWQgZm9yPGJy Pg0KVFAgTFNQcyBieSBkZWZhdWx0LjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiB3ZSB3YW50IHRvIGNvbmZpZ3VyZSBQVyBvYW0gdXNpbmcN CnRoZSBzYW1lIHByb2NlZHVyZSwgZm9yIHRoZSBzZXR0aW5nIHVwIG9mIFBXIDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aW4gdHdvIGRpcmVjdGlvbnMgaXMgaW5k ZXBlbmRlbnQgKG5vdA0KbGlrZSBSU1ZQLVRFLCBwYXRoIGFuZCByZXN2IG1lc3NhZ2UgYXJlIGRl cGVuZGVudCksPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj53ZSBo YWQgYmV0dGVyIHB1dCB0aGUgdGltZXIgbmVnb3RpYXRpb24NCmluIHRoZSBCRkQgc2Vzc2lvbiBp dHNlbGYuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BbmQgaW4g dGhpcyB3YXksIGl0IHdpbGwgYmUgZWFzaWVyIHRvDQpyZW5lZ290aWF0ZSB0aGUgdGltZXIgaWYg dGhlIHR3byBlbmRzIHdhbnQgdG8gY2hhbmdlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5pdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48YnI+ DQpXaGVuIGl0IGNvbWVzIHRvIENWLCBpdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBkaXNjdXNz IHdoZXRoZXIgb25seSB0aGU8YnI+DQpPQU0gaWRlbnRpZmllcnMgZGVzY3JpYmVkIGluIGRyYWZ0 LWlldGYtbXBscy10cC1pZGVudGlmaWVycy0wMCBhcmUgb3VnaHQ8YnI+DQp0byBiZSBzdXBwb3J0 ZWQuIElmIHNvLCB0aG9zZSBjb3VsZCBiZSBkZXJpdmVkIGZyb20gUlNWUC1URSBzaWduYWxpbmc8 YnI+DQp3aXRob3V0IHRoZSBuZWVkIHRvIGNhcnJ5IHRoZW0gZXhwbGljaXRseSBpbiBNUExTLVRQ IE9BTSBDb25maWd1cmF0aW9uPGJyPg0Kc3ViLVRMVnMgKG5vdyBjYWxsZWQgU291cmNlIHVuaXF1 ZSBNRVBfSUQgc3ViLVRMViBpbjxicj4NCmRyYWZ0LWJlbGxhZ2FtYmEtY2NhbXAtcnN2cC10ZS1t cGxzLXRwLW9hbS1leHQtMDMpLiA8L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+SSBhZ3JlZSB3aXRoIHlvdSwgdGhpcyBzaG91bGQgYmUgdXBkYXRl ZA0KaW4gdGhlIGZ1cnR1cmUgdmVyc2lvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkIuUi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPjopPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5GZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+PGI+JnF1b3Q7QXR0aWxhIFRha2FjcyZxdW90Ow0KJmx0O0F0dGlsYS5UYWthY3NA ZXJpY3Nzb24uY29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj63orz+yMs6ICZuYnNwO2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0xMi0wMSAxODo0ODwvZm9udD4NCjx0 ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7Y2NhbXBA aWV0Zi5vcmcmZ3Q7LCAmbHQ7bXBscy10cEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltDQ0FNUF0gVGhvdWdodHMg b24gdXBkYXRpbmcgdGhlIE9BTQ0KQ29uZmlndXJhdGlvbiBmd2sgYW5kIHRoZSAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtNUExTLVRQIE9BTQ0KY29uZmlndXJhdGlvbiBkcmFmdHM8L2ZvbnQ+ PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFi bGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PkhpIGFs bCw8YnI+DQo8YnI+DQpTb21lIHRob3VnaHRzIG9uIHVwZGF0aW5nIHRoZSBPQU0gQ29uZmlndXJh dGlvbiBmd2sgYW5kIHRoZSBNUExTLVRQIE9BTTxicj4NCmNvbmZpZ3VyYXRpb24gZHJhZnRzLjxi cj4NCjxicj4NCkkgdGhpbmsgd2UgbmVlZCB0byBleHRlbmQgdGhlIE9BTSBGdW5jdGlvbiBmbGFn cyAoZGVzY3JpYmVkIGluPGJyPg0KZHJhZnQtaWV0Zi1jY2FtcC1vYW0tY29uZmlndXJhdGlvbi1m d2stMDIpIHRvIGZpdmUgZmxhZ3M6PGJyPg0KPGJyPg0KLUNDPGJyPg0KLUNWPGJyPg0KLVBNIExv c3M8YnI+DQotUE0gRGVsYXk8YnI+DQotRmF1bHQgTWFuYWdlbWVudCBzaWduYWxzPGJyPg0KPGJy Pg0KPGJyPg0KV2l0aCByZWdhcmRzIHRvIEJGRCBJIHNlZSB0aHJlZSBvcGVyYXRpb24gdnMuIGNv bmZpZ3VyYXRpb24gbW9kZXM6PGJyPg0KPGJyPg0KMSkgU2V0IENDIGluIHRoZSBmbGFncyBhbmQg b25seSBib290c3RyYXAgdGhlIEJGRCBzZXNzaW9uLCBieSBzZW5kaW5nPGJyPg0KdGhlIGxvY2Fs IGRpc2NyaW1pbmF0b3IgdmFsdWVzIGluIFJTVlAtVEUgYW5kIGxlYXZlIHRpbWVyIG5lZ290aWF0 aW9uIHRvPGJyPg0KQkZEIGNvbnRyb2wgbWVzc2FnZXMuIFRoaXMgaXMgc2ltaWxhciB0byBMU1Ag UGluZyBiYXNlZCBib290c3RyYXBwaW5nPGJyPg0KZGVzY3JpYmVkIGluIGRyYWZ0LWlldGYtYmZk LW1wbHMtMDcudHh0Ljxicj4NCjxicj4NCjIpIFNldCBDQyBpbiB0aGUgZmxhZ3MgYnV0IGNvbmZp Z3VyZSB0aGUgdGltZXJzIHZpYSB0aGUgY29udHJvbCBwbGFuZSw8YnI+DQp0aGlzIHNob3VsZCBj b3JyZXNwb25kIHRvICZxdW90O0NDIG1vZGUmcXVvdDsgaW4gZHJhZnQtYXNtLW1wbHMtdHAtYmZk LWNjLWN2LTAxLjxicj4NCldlIG1heSBpbmNsdWRlIHRoZSBtaW4vbWF4IGludGVydmFscyBhbmQg YnkgZG9pbmcgc28gc3VwcG9ydCBpbml0aWFsPGJyPg0KdGltZXIgbmVnb3RpYXRpb24gaW4gY29u dHJvbCBwbGFuZS4gSG93ZXZlciwgd2UgbWF5IG5lZWQgYSBmbGFnIGluIENDPGJyPg0KY29uZmln dXJhdGlvbiBzdWItVExWIChub3cgaW48YnI+DQpkcmFmdC1iZWxsYWdhbWJhLWNjYW1wLXJzdnAt dGUtbXBscy10cC1vYW0tZXh0LTAzIGNhbGxlZCAmcXVvdDtTdWdnZXN0ZWQNClRYPGJyPg0KSW50 ZXJ2YWwgc3ViLVRMViZxdW90OykgdG8gaW5kaWNhdGUgd2hldGhlciBkYXRhIHBsYW5lIHRpbWVy IHJlbmVnb3RpYXRpb24NCmlzPGJyPg0KZW5hYmxlZCBvciBkaXNhYmxlZCAoaS5lLiwgc3Vic2Vx dWVudGx5IHZpYSBCRkQgY29udHJvbCBtZXNzYWdlcykuIFRoaXMsPGJyPg0KYXMgZGVzY3JpYmVk IGluIGRyYWZ0LWFzbS1tcGxzLXRwLWJmZC1jYy1jdi0wMSwgc2hvdWxkIGJlIGRpc2FibGVkIGZv cjxicj4NClRQIExTUHMgYnkgZGVmYXVsdC48YnI+DQo8YnI+DQozKSBJbiBjYXNlIG9mICZxdW90 O2Z1bGwmcXVvdDsgTVBMUy1UUCBPQU0gc3VwcG9ydCBhbnkgb2YgdGhlIGZsYWdzIGNvdWxkDQpi ZSBzZXQ8YnI+DQphcyBuZWVkZWQsIHJlZmxlY3RpbmcgJnF1b3Q7Q1YvQ0MgbW9kZSZxdW90OyBk ZXNjcmliZWQgaW48YnI+DQpkcmFmdC1hc20tbXBscy10cC1iZmQtY2MtY3YtMDEsIGRlbGF5IGFu ZCBsb3NzIG1lYXN1cmVtZW50IGFzIGRlc2NyaWJlZDxicj4NCmluIGRyYWZ0LWZyb3N0LW1wbHMt dHAtbG9zcy1kZWxheS0wMCBhbmQgbWFuYWdlbWVudCBzaWduYWxzIGFzIGdpdmVuIGluPGJyPg0K ZHJhZnQtc2Z2LW1wbHMtdHAtZmF1bHQtMDAuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KVG8gY29u ZmlndXJlIENDIHdlIHdpbGwgbmVlZCB0byBhZGQ8YnI+DQotZW5hYmxlL2Rpc2FibGUgRFAgdGlt ZXIgcmUtbmVnb3RpYXRpb248YnI+DQotUEhCIHRvIGlkZW50aWZ5IHByaW9yaXR5IGFuZCBkcm9w IHByZWNlZGVuY2Ugb2YgQ0MgcGFja2V0czxicj4NCjxicj4NCldoZW4gaXQgY29tZXMgdG8gQ1Ys IGl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGRpc2N1c3Mgd2hldGhlciBvbmx5IHRoZTxicj4N Ck9BTSBpZGVudGlmaWVycyBkZXNjcmliZWQgaW4gZHJhZnQtaWV0Zi1tcGxzLXRwLWlkZW50aWZp ZXJzLTAwIGFyZSBvdWdodDxicj4NCnRvIGJlIHN1cHBvcnRlZC4gSWYgc28sIHRob3NlIGNvdWxk IGJlIGRlcml2ZWQgZnJvbSBSU1ZQLVRFIHNpZ25hbGluZzxicj4NCndpdGhvdXQgdGhlIG5lZWQg dG8gY2FycnkgdGhlbSBleHBsaWNpdGx5IGluIE1QTFMtVFAgT0FNIENvbmZpZ3VyYXRpb248YnI+ DQpzdWItVExWcyAobm93IGNhbGxlZCBTb3VyY2UgdW5pcXVlIE1FUF9JRCBzdWItVExWIGluPGJy Pg0KZHJhZnQtYmVsbGFnYW1iYS1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAtb2FtLWV4dC0wMykuIDxi cj4NCjxicj4NCkZvciBQZXJmb3JtYW5jZSBNb25pdG9yaW5nIExvc3MvRGVsYXkgd2UgbmVlZCB0 byBhZGQgbmV3IFRMVnMsIGNhcnJ5aW5nPGJyPg0KLW1lYXN1cmVtZW50IGludGVydmFsPGJyPg0K LXBvc3NpYmx5IGxvc3MvZGVsYXkgYm91bmQgdGhyZXNob2xkcyAoZ2l2ZW4gd2Ugd2hhdCB0aGVz ZSBmb3IgTVBMUy1UUCk8YnI+DQp0aGF0IGNvdWxkIGJlIHVzZWQgdG8gYXNzZXNzIHRoZSBxdWFs aXR5IG9mIHRoZSBjb25uZWN0aW9uIGFuZCBtYXk8YnI+DQpldmVudHVhbGx5IHRyaWdnZXIgcHJv dGVjdGlvbjxicj4NCi1QSEIgb2YgY29udHJvbCBwYWNrZXRzIGlmIHdlIHdhbnQgdG8gc2V0IGl0 IGRpZmZlcmVudGx5IGZyb20gQ0MgcGFja2V0czxicj4NCm9yIGZyb20gZGF0YSB0cmFmZmljLjxi cj4NCjxicj4NCkZvciB0aGUgRmF1bHQgTWFuYWdlbWVudCBTaWduYWxzLCBJIHdvdWxkIGFkZCBh IG5ldyAmcXVvdDtGYXVsdCBNYW5hZ2VtZW50PGJyPg0KU2lnbmFscyBzdWItVExWJnF1b3Q7IGNh cnJ5aW5nOjxicj4NCi1FbmFibGVkIHNpZ25hbHMgZmxhZ3M6IEFJUywgTERJLCBMS1IsIENGUyAo d2hpY2gsIGV4Y2VwdCBDRlMsIGFyZTxicj4NCnNwZWNpZmllZCBpbiBkcmFmdC1zZnYtbXBscy10 cC1mYXVsdC0wMCk8YnI+DQotcmVmcmVzaCB0aW1lciBvZiBmYXVsdCBpbmRpY2F0aW9uIG1lc3Nh Z2VzPGJyPg0KLWZsYWcgdG8gZW5hYmxlL2Rpc2FibGUgZXhwbGljaXRseSBjbGVhciBvZiBmYXVs dHM8YnI+DQotUEhCIG9mIGZhdWx0IG1hbmFnZW1lbnQgcGFja2V0cyA8YnI+DQo8YnI+DQo8YnI+ DQpBbm90aGVyIHRoaW5nIHdlIG1heSB3YW50IHRvIGNvbnNpZGVyIGlzIGFkZGluZyBhIHN1Yi1U TFYgdG8gc2V0PGJyPg0KY29uc2VxdWVudCBhY3Rpb25zIHRoYXQgYXJlIGNvbmZpZ3VyYWJsZS4g VGhpcyBpcyBkZXNjcmliZWQgdG8gc29tZTxicj4NCmV4dGVudCBpbiB0aGUgTVBMUy1UUCBPQU0g RnJhbWV3b3JrLiBUaGUgZGVmZWN0cyBpZGVudGlmaWVkIGluY2x1ZGU6PGJyPg0KTG9zcyBPZiBD b250aW51aXR5IGRlZmVjdCwgTWlzLWNvbm5lY3Rpdml0eSBkZWZlY3QsIE1FUCBtaXNjb25maWd1 cmF0aW9uPGJyPg0KZGVmZWN0LCBQZXJpb2QgTWlzY29uZmlndXJhdGlvbiBkZWZlY3QuPGJyPg0K PGJyPg0KQW4gb3BlcmF0b3IgbWF5IHdhbnQgdG8gY29uZmlndXJlIGlmIHRoZSBjb25zZXF1ZW5j ZSBvZiBMT0Mgc2hvdWxkIGJlPGJyPg0KdGhlIGJsb2NraW5nIG9yIG5vbi1ibG9ja2luZyBvZiBv dXRnb2luZyBkYXRhIHRyYWZmaWMuIFNpbWlsYXJseSBpdCBtYXk8YnI+DQpiZSB1c2VmdWwgdG8g Y29uZmlndXJlIHdoZXRoZXIgdGhlICZxdW90O1BlcmlvZCBNaXNjb25maWd1cmF0aW9uIGRlZmVj dCZxdW90Ozxicj4NCnNob3VsZCByZXN1bHQgaW4gYSBzaWduYWwgZmFpbCBjb25kaXRpb24gb3Ig bm90Ljxicj4NCjxicj4NCjxicj4NCkkgcGxhbiB0byBzZW5kIGRldGFpbGVkIHRleHQgdG8gdGhl IGVkaXRvcnMgb2Y8YnI+DQpkcmFmdC1iZWxsYWdhbWJhLWNjYW1wLXJzdnAtdGUtbXBscy10cC1v YW0tZXh0LTAzIGFsb25nIHRoZSBsaW5lczxicj4NCmRlc2NyaWJlZCBhYm92ZS4gUGxlYXNlIGNv bW1lbnQhPGJyPg0KVGhhbmtzLDxicj4NCkF0dGlsYTxicj4NCjxicj4NCjxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ0NBTVAg bWFpbGluZyBsaXN0PGJyPg0KQ0NBTVBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 0013780D48257686_=-- From loa@pi.nu Tue Dec 8 04:13:35 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9441028C11C; Tue, 8 Dec 2009 04:13:35 -0800 (PST) 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 Ukl7Zwx0+0Am; Tue, 8 Dec 2009 04:13:33 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 8AF6F3A67E2; Tue, 8 Dec 2009 04:13:32 -0800 (PST) Received: from [172.17.186.95] (static-72-8-44-146.wal.onecommunications.net [72.8.44.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 5A52ED4052; Tue, 8 Dec 2009 13:13:18 +0100 (CET) Message-ID: <4B1E42DB.7080205@pi.nu> Date: Tue, 08 Dec 2009 13:13:15 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Nadeau References: <4B190753.4080500@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 12:13:35 -0000 Tom, all the four drafts we've discussed are extensions to RSVP-TE, so the same considerations that apply to other RSVP-TE applications applies here. /Loa Thomas Nadeau wrote: > I guess my point is to ask whether or not we've thought through the architectural and security implications of allowing changes to configurations via a signaling protocol. More specially, are we targeting OAM configuration to be contained to just RSVP-related configuration, or are we going to allow it to go beyond that? If its the former, I'd agree, the security implications are similar to those of the base protocol; however, when we go beyond that such as the discussion of enabling/disabling existing LSPs or such things, I see potential issues there. > > --Tom > > > On Dec 4, 2009, at 7:57 AM, Loa Andersson wrote: > >> Tom, >> >> >> benjamin.niven-jenkins@bt.com wrote: >>> Tom, >>> Can you be more specific? I don't see any greater security ramifications >>> resulting from unapproved RSVP messages being sent to >>> modify/deactivate/activate LSPs in this model than the current usages of >>> RSVP-TE. >> I agree with Ben, I don't see any additional security issues as >> compared to how RSVP-TE is used today. >> >> /Loa >>> Although for a slightly different context in Section 4.4.3.3 of >>> draft-jenkins-mpls-tp-bt-requirements-00.txt I have the following note: >>> [Editor's note: Need to insert some text requiring a mechanism to >>> limit the chance of fat fingers running inappropriate tests, e.g. on >>> a per PW basis the ability to run a throughput test (and the maximum >>> rate) needs to be pre-authorised via some mechanism e.g. within the >>> PW interface configuration] >>> When writing the draft I had quite a lengthy discussion with Simon (the >>> draft's co-author) about suitable mechanisms but I timed out on constructing >>> some suitable text (and still haven't got around to it). >>> Maybe something similar would be needed for being able to reconfigure the >>> OAM on already setup LSPs. What I was thinking about for draft-jenkins was >>> something like being able to specify in the interface configuration a >>> requirement for explicit authentication/authorisation (possibly limited to >>> specific account roles) before performing the Throughput test so (1) >>> operations folks might think twice before continuing and (2) AAA can >>> specifically record who performed the action so if things do go wrong the >>> guilty operations person can be tracked down and "re-educated". >>> Ben >>> On 03/12/2009 18:13, "Thomas Nadeau" wrote: >>>> Has anyone thought about security ramifications of allowing this? >>>> >>>> >>>> On Dec 3, 2009, at 12:28 PM, "Andrew G. Malis" >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> Cheers, >>>>> Andy >>>>> >>>>> On Thu, Dec 3, 2009 at 6:20 PM, Loa Andersson wrote: >>>>>> Attila, >>>>>> >>>>>> if we agree on this the we also have a method to easily reconfigure >>>>>> OAM on already set up LSPs, simple send a refresh PATH or RESV. >>>>>> >>>>>> What do people think is this a good idea? >>>>>> >>>>>> /Loa >>>>>> >>>>>> Attila Takacs wrote: >>>>>>> Hi Loa, >>>>>>>> OK great, then we need to update that in the framework. >>>>>>>> >>>>>>> Ok, I will do so. >>>>>>> >>>>>>>> I also have a question on the relationship between flags and the >>>>>>>> sub-tlvs. >>>>>>>> >>>>>>>> I think there are four possibilities: >>>>>>>> >>>>>>>> 1. A flag is set, but there is no sub-tlv >>>>>>>> - the action here should be to turn on the function the >>>>>>>> flag indicates using default values >>>>>>>> I also think that if a function indicated by flag is >>>>>>>> running, it should be left unchanged, even if it is not >>>>>>>> running on default values >>>>>>>> >>>>>>>> 2. A flag is set, and there is a sub-tlv >>>>>>>> - the action here would be to turn on the function indicated by >>>>>>>> the flag, using the parameters found in sub-tlv >>>>>>>> >>>>>>>> 3. A flag is not set, and there is no sub-tlv >>>>>>>> - the action here would be to turn off any function that has >>>>>>>> been configured earlier >>>>>>>> >>>>>>>> 4. A flag is not set, but there is sub-tlv >>>>>>>> - this should be treated as an error conditions and an >>>>>>>> error message should be returned, no changes to the >>>>>>>> configured >>>>>>>> OAM should be made. >>>>>>>> >>>>>>>> Is this correctly understood? >>>>>>> Yes. I will check is this need clarification in the fwk. >>>>>>> >>>>>>> Attila >>>>>>> >>>>>>>> /Loa >>>>>>>> >>>>>>>> Attila Takacs wrote: >>>>>>>>> Hi Loa, >>>>>>>>> >>>>>>>>> It can be carried in the LSP_ATTRIBUTES Object in the Resv >>>>>>>> message; so it can be used for timer negotiation and discriminator >>>>>>>> synchronization if needed. >>>>>>>>> Attila >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Loa Andersson [mailto:loa@pi.nu] >>>>>>>>>> Sent: Wednesday, December 02, 2009 3:59 PM >>>>>>>>>> To: Attila Takacs >>>>>>>>>> Cc: ccamp@ietf.org; mpls-tp@ietf.org >>>>>>>>>> Subject: Re: [CCAMP] Thoughts on updating the OAM >>>>>>>> Configuration fwk >>>>>>>>>> and the MPLS-TP OAM configuration drafts >>>>>>>>>> >>>>>>>>>> Attila, >>>>>>>>>> >>>>>>>>>> thanks - I think things are converging quite a bit now. >>>>>>>>>> >>>>>>>>>> May the OAM Configuration TLV specified in the OAM Configuration >>>>>>>>>> Framweork only be present in the PATH message? >>>>>>>>>> >>>>>>>>>> /Loa >>>>>>>>>> >>>>>>>>>> Attila Takacs wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Some thoughts on updating the OAM Configuration fwk and >>>>>>>> the MPLS-TP >>>>>>>>>>> OAM configuration drafts. >>>>>>>>>>> >>>>>>>>>>> I think we need to extend the OAM Function flags (described in >>>>>>>>>>> draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: >>>>>>>>>>> >>>>>>>>>>> -CC >>>>>>>>>>> -CV >>>>>>>>>>> -PM Loss >>>>>>>>>>> -PM Delay >>>>>>>>>>> -Fault Management signals >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> With regards to BFD I see three operation vs. configuration >>>>>>>>>>> modes: >>>>>>>>>>> >>>>>>>>>>> 1) Set CC in the flags and only bootstrap the BFD session, >>>>>>>>>> by sending >>>>>>>>>>> the local discriminator values in RSVP-TE and leave timer >>>>>>>>>> negotiation >>>>>>>>>>> to BFD control messages. This is similar to LSP Ping based >>>>>>>>>>> bootstrapping described in draft-ietf-bfd-mpls-07.txt. >>>>>>>>>>> >>>>>>>>>>> 2) Set CC in the flags but configure the timers via the >>>>>>>>>> control plane, >>>>>>>>>>> this should correspond to "CC mode" in >>>>>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01. >>>>>>>>>>> We may include the min/max intervals and by doing so >>>>>>>>>> support initial >>>>>>>>>>> timer negotiation in control plane. However, we may need a >>>>>>>>>> flag in CC >>>>>>>>>>> configuration sub-TLV (now in >>>>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called >>>>>>>>>> "Suggested TX >>>>>>>>>>> Interval sub-TLV") to indicate whether data plane timer >>>>>>>>>> renegotiation >>>>>>>>>>> is enabled or disabled (i.e., subsequently via BFD control >>>>>>>>>> messages). >>>>>>>>>>> This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be >>>>>>>>>>> disabled for TP LSPs by default. >>>>>>>>>>> >>>>>>>>>>> 3) In case of "full" MPLS-TP OAM support any of the flags >>>>>>>>>> could be set >>>>>>>>>>> as needed, reflecting "CV/CC mode" described in >>>>>>>>>>> draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as >>>>>>>>>>> described in >>>>>>>>>>> draft-frost-mpls-tp-loss-delay-00 and >>>>>>>>>> management signals >>>>>>>>>>> as given in draft-sfv-mpls-tp-fault-00. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> To configure CC we will need to add >>>>>>>>>>> -enable/disable DP timer re-negotiation -PHB to identify >>>>>>>>>> priority and >>>>>>>>>>> drop precedence of CC packets >>>>>>>>>>> >>>>>>>>>>> When it comes to CV, it would be interesting to discuss >>>>>>>>>> whether only >>>>>>>>>>> the OAM identifiers described in >>>>>>>>>> draft-ietf-mpls-tp-identifiers-00 are >>>>>>>>>>> ought to be supported. If so, those could be derived from RSVP- >>>>>>>>>>> TE >>>>>>>>>>> signaling without the need to carry them explicitly in >>>>>>>> MPLS-TP OAM >>>>>>>>>>> Configuration sub-TLVs (now called Source unique MEP_ID >>>>>>>> sub-TLV in >>>>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). >>>>>>>>>>> >>>>>>>>>>> For Performance Monitoring Loss/Delay we need to add new TLVs, >>>>>>>>>>> carrying -measurement interval -possibly loss/delay bound >>>>>>>>>> thresholds >>>>>>>>>>> (given we what these for MPLS-TP) that could be used to >>>>>>>> assess the >>>>>>>>>>> quality of the connection and may eventually trigger >>>>>>>>>> protection -PHB >>>>>>>>>>> of control packets if we want to set it differently from CC >>>>>>>>>> packets or >>>>>>>>>>> from data traffic. >>>>>>>>>>> >>>>>>>>>>> For the Fault Management Signals, I would add a new "Fault >>>>>>>>>> Management >>>>>>>>>>> Signals sub-TLV" carrying: >>>>>>>>>>> -Enabled signals flags: AIS, LDI, LKR, CFS (which, except >>>>>>>> CFS, are >>>>>>>>>>> specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault >>>>>>>>>>> indication messages -flag to enable/disable explicitly >>>>>>>>>> clear of faults >>>>>>>>>>> -PHB of fault management packets >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Another thing we may want to consider is adding a sub-TLV to set >>>>>>>>>>> consequent actions that are configurable. This is >>>>>>>> described to some >>>>>>>>>>> extent in the MPLS-TP OAM Framework. The defects >>>>>>>> identified include: >>>>>>>>>>> Loss Of Continuity defect, Mis-connectivity defect, MEP >>>>>>>>>>> misconfiguration defect, Period Misconfiguration defect. >>>>>>>>>>> >>>>>>>>>>> An operator may want to configure if the consequence of LOC >>>>>>>>>> should be >>>>>>>>>>> the blocking or non-blocking of outgoing data traffic. >>>>>>>> Similarly it >>>>>>>>>>> may be useful to configure whether the "Period >>>>>>>>>> Misconfiguration defect" >>>>>>>>>>> should result in a signal fail condition or not. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I plan to send detailed text to the editors of >>>>>>>>>>> draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the >>>>>>>>>>> lines >>>>>>>>>>> described above. Please comment! >>>>>>>>>>> Thanks, >>>>>>>>>>> Attila >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> CCAMP mailing list >>>>>>>>>>> CCAMP@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Loa Andersson email: loa.andersson@ericsson.com >>>>>>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>>>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>>>>>>> +46 767 72 92 13 >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> Loa Andersson email: loa.andersson@ericsson.com >>>>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>>>>> +46 767 72 92 13 >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> -- >>>>>> >>>>>> >>>>>> Loa Andersson email: loa.andersson@ericsson.com >>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>> Ericsson Inc phone: +46 10 717 52 13 >>>>>> +46 767 72 92 13 >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>> _______________________________________________ >>>>> mpls-tp mailing list >>>>> mpls-tp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>>>> >>>> _______________________________________________ >>>> mpls-tp mailing list >>>> mpls-tp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Tue Dec 8 05:37:56 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC203A6A12; Tue, 8 Dec 2009 05:37:56 -0800 (PST) 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 rlutmgrFBSKB; Tue, 8 Dec 2009 05:37:55 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 02C793A69FD; Tue, 8 Dec 2009 05:37:54 -0800 (PST) Received: from [172.17.186.95] (static-72-8-44-146.wal.onecommunications.net [72.8.44.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 72659D4052; Tue, 8 Dec 2009 14:37:41 +0100 (CET) Message-ID: <4B1E56A3.1020604@pi.nu> Date: Tue, 08 Dec 2009 14:37:39 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Chris Benson , "ccamp@ietf.org" , "mpls-tp@ietf.org" References: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> <4B16809A.3040409@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AC8@ESESSCMS0355.eemea.ericsson.se> <4B17C57B.40200@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CCAMP] [mpls-tp] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 13:37:56 -0000 Chris, see inline please. Chris Benson wrote: > Loa and Attila, > > When viewing the four possibilities as enumerated by > Loa, I wonder if the fourth might be better thus: > > 4. A flag is not set, but there is sub-tlv > - this will result in the function being TURNED OFF, > AND is treated as an error condition: an error message > should be returned (indicating incompatible sub-tlv). This is what I had proposed 4. A flag is not set, but there is sub-tlv - this should be treated as an error conditions and an error message should be returned, no changes to the configured OAM should be made. I see the rational behind what you are saying, so 1. We agree that this is an error, and I'm also fine with sending the error message indicating incompatible sub-TLV 2. I'm less convinced, but open to discuss, turning off "the function". Are you proposing turning off the function indicated by the sub-TLV? Or any active OAM funtions? I believe the first. I would be rather hesitant to do any changes based on something that we can identify as an error. Though I guess that your reasoning is that the flag indicates "turn off". I can see that, but would like to have more comments. /Loa > > My reason for suggesting this is in case there is any > misidentification of whether a sub-tlv is associated > with the flag being considered or not. In all the other > three cases, the value of the flag is sufficient to > determine the resultant state of the function. Perhaps > it would be "cleaner" if that were so in this fourth case > as well. > > If a peer were using some unrelated experimental extension, > but accidentally re-used a sub-tlv tag associated with the > flag under examination, then it would be unable to turn > off the flag's feature. > > This is an error case that "shouldn't" happen, but it seems > cleaner to me if the flag alone can tell us the eventual > state of the function, without also needing the ability to > associate a sub-tlv (or set of sub-tlvs) with the cleared > flag, to identify Loa's case 4. > > Just a thought. With thanks, from Chris Benson. > > On Thu, 3 Dec 2009, Loa Andersson wrote: > >>> Date: Thu, 03 Dec 2009 15:04:43 +0100 >>> From: Loa Andersson >>> To: Attila Takacs >>> Cc: "ccamp@ietf.org" , "mpls-tp@ietf.org" >>> Subject: Re: [mpls-tp] [CCAMP] Thoughts on updating the OAM Configuration >>> fwk and the MPLS-TP OAM configuration drafts >>> >>> Attila, >>> >>> OK great, then we need to update that in the framework. >>> >>> I also have a question on the relationship between flags and >>> the sub-tlvs. >>> >>> I think there are four possibilities: >>> >>> 1. A flag is set, but there is no sub-tlv >>> - the action here should be to turn on the function the >>> flag indicates using default values >>> I also think that if a function indicated by flag is >>> running, it should be left unchanged, even if it is not >>> running on default values >>> >>> 2. A flag is set, and there is a sub-tlv >>> - the action here would be to turn on the function indicated by >>> the flag, using the parameters found in sub-tlv >>> >>> 3. A flag is not set, and there is no sub-tlv >>> - the action here would be to turn off any function that has >>> been configured earlier >>> >>> 4. A flag is not set, but there is sub-tlv >>> - this should be treated as an error conditions and an >>> error message should be returned, no changes to the configured >>> OAM should be made. >>> >>> Is this correctly understood? >>> >>> /Loa >>> >>> Attila Takacs wrote: >>> > Hi Loa, >>> > >>> > It can be carried in the LSP_ATTRIBUTES Object in the Resv message; so it >>> > can be used for timer negotiation and discriminator synchronization if >>> > needed. >>> > >>> > Attila >>> > >>> > > -----Original Message----- >>> > > From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, December 02, >>> > > 2009 3:59 PM >>> > > To: Attila Takacs >>> > > Cc: ccamp@ietf.org; mpls-tp@ietf.org >>> > > Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration fwk and >>> > > the MPLS-TP OAM configuration drafts >>> > > >>> > > Attila, >>> > > >>> > > thanks - I think things are converging quite a bit now. >>> > > >>> > > May the OAM Configuration TLV specified in the OAM Configuration >>> > > Framweork only be present in the PATH message? >>> > > >>> > > /Loa >>> > > >>> > > Attila Takacs wrote: >>> > > > Hi all, >>> > > > >>> > > > Some thoughts on updating the OAM Configuration fwk and the MPLS-TP >>> > > > OAM configuration drafts. >>> > > > >>> > > > I think we need to extend the OAM Function flags (described in >>> > > > draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: >>> > > > >>> > > > -CC >>> > > > -CV >>> > > > -PM Loss >>> > > > -PM Delay >>> > > > -Fault Management signals >>> > > > >>> > > > >>> > > > With regards to BFD I see three operation vs. configuration modes: >>> > > > >>> > > > 1) Set CC in the flags and only bootstrap the BFD session, >>> > > by sending >>> > > > the local discriminator values in RSVP-TE and leave timer >>> > > negotiation >>> > > > to BFD control messages. This is similar to LSP Ping based >>> > > > bootstrapping described in draft-ietf-bfd-mpls-07.txt. >>> > > > >>> > > > 2) Set CC in the flags but configure the timers via the >>> > > control plane, >>> > > > this should correspond to "CC mode" in >>> > > draft-asm-mpls-tp-bfd-cc-cv-01. >>> > > > We may include the min/max intervals and by doing so >>> > > support initial >>> > > > timer negotiation in control plane. However, we may need a >>> > > flag in CC >>> > > > configuration sub-TLV (now in >>> > > > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called >>> > > "Suggested TX >>> > > > Interval sub-TLV") to indicate whether data plane timer >>> > > renegotiation >>> > > > is enabled or disabled (i.e., subsequently via BFD control >>> > > messages). >>> > > > This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be >>> > > > disabled for TP LSPs by default. >>> > > > >>> > > > 3) In case of "full" MPLS-TP OAM support any of the flags >>> > > could be set >>> > > > as needed, reflecting "CV/CC mode" described in >>> > > > draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as >>> > > > described in draft-frost-mpls-tp-loss-delay-00 and >>> > > management signals >>> > > > as given in draft-sfv-mpls-tp-fault-00. >>> > > > >>> > > > >>> > > > >>> > > > To configure CC we will need to add >>> > > > -enable/disable DP timer re-negotiation -PHB to identify >>> > > priority and >>> > > > drop precedence of CC packets >>> > > > >>> > > > When it comes to CV, it would be interesting to discuss >>> > > whether only >>> > > > the OAM identifiers described in >>> > > draft-ietf-mpls-tp-identifiers-00 are >>> > > > ought to be supported. If so, those could be derived from RSVP-TE >>> > > > signaling without the need to carry them explicitly in MPLS-TP OAM >>> > > > Configuration sub-TLVs (now called Source unique MEP_ID sub-TLV in >>> > > > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). >>> > > > >>> > > > For Performance Monitoring Loss/Delay we need to add new TLVs, >>> > > > carrying -measurement interval -possibly loss/delay bound >>> > > thresholds >>> > > > (given we what these for MPLS-TP) that could be used to assess the >>> > > > quality of the connection and may eventually trigger >>> > > protection -PHB >>> > > > of control packets if we want to set it differently from CC >>> > > packets or >>> > > > from data traffic. >>> > > > >>> > > > For the Fault Management Signals, I would add a new "Fault >>> > > Management >>> > > > Signals sub-TLV" carrying: >>> > > > -Enabled signals flags: AIS, LDI, LKR, CFS (which, except CFS, are >>> > > > specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault >>> > > > indication messages -flag to enable/disable explicitly >>> > > clear of faults >>> > > > -PHB of fault management packets >>> > > > >>> > > > >>> > > > Another thing we may want to consider is adding a sub-TLV to set >>> > > > consequent actions that are configurable. This is described to some >>> > > > extent in the MPLS-TP OAM Framework. The defects identified include: >>> > > > Loss Of Continuity defect, Mis-connectivity defect, MEP >>> > > > misconfiguration defect, Period Misconfiguration defect. >>> > > > >>> > > > An operator may want to configure if the consequence of LOC >>> > > should be >>> > > > the blocking or non-blocking of outgoing data traffic. Similarly it >>> > > > may be useful to configure whether the "Period >>> > > Misconfiguration defect" >>> > > > should result in a signal fail condition or not. >>> > > > >>> > > > >>> > > > I plan to send detailed text to the editors of >>> > > > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the lines >>> > > > described above. Please comment! >>> > > > Thanks, >>> > > > Attila >>> > > > >>> > > > >>> > > > >>> > > > _______________________________________________ >>> > > > CCAMP mailing list >>> > > > CCAMP@ietf.org >>> > > > https://www.ietf.org/mailman/listinfo/ccamp >>> > > -- >>> > > >>> > > >>> > > Loa Andersson email: loa.andersson@ericsson.com >>> > > Sr Strategy and Standards Manager loa@pi.nu >>> > > Ericsson Inc phone: +46 10 717 52 13 >>> > > +46 767 72 92 13 >>> >>> -- >>> >>> >>> Loa Andersson email: loa.andersson@ericsson.com >>> Sr Strategy and Standards Manager loa@pi.nu >>> Ericsson Inc phone: +46 10 717 52 13 >>> +46 767 72 92 13 >>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >>> -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From db3546@att.com Tue Dec 8 08:34:44 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6193A6866 for ; Tue, 8 Dec 2009 08:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.379 X-Spam-Level: X-Spam-Status: No, score=-106.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 zQU6oK0YAwSx for ; Tue, 8 Dec 2009 08:34:44 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 097B93A6843 for ; Tue, 8 Dec 2009 08:34:43 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1260290071!42313086!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 22647 invoked from network); 8 Dec 2009 16:34:32 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Dec 2009 16:34:32 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nB8GYSFK008130 for ; Tue, 8 Dec 2009 11:34:28 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nB8GYNHY008077 for ; Tue, 8 Dec 2009 11:34:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Dec 2009 11:34:25 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] poll on makingdraft-lee-ccamp-wson-signal-compatibility-ospf-00.txt ccamp wg document Thread-Index: AcpsiyX6jIdbMKuST6ymgbpjP3HGUwLmJ5zQ References: From: "BRUNGARD, DEBORAH A (ATTLABS)" To: Subject: Re: [CCAMP] poll on makingdraft-lee-ccamp-wson-signal-compatibility-ospf-00.txt ccamp wg document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 16:34:44 -0000 Hi, We have good support for this document. Authors, please submit the document as a wg document (draft-ietf-ccamp-wson-signal-compatibility-ospf-00.txt). Thanks, Deborah and Lou -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTLABS) Sent: Monday, November 23, 2009 5:20 PM To: ccamp@ietf.org Subject: [CCAMP] poll on makingdraft-lee-ccamp-wson-signal-compatibility-ospf-00.txt ccampwg document All, This is to start a two week poll on making draft-lee-ccamp-wson-signal-compatibility-ospf-00.txt a ccamp working group document. Send a mail to the mailing list indicating "yes/support" or "no/do not support". The poll ends Monday, Dec. 7, 2009. Deborah _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From gregb@grotto-networking.com Tue Dec 8 10:04:38 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D643A6827 for ; Tue, 8 Dec 2009 10:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HTML_MESSAGE=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 HlGzoDkaGxS4 for ; Tue, 8 Dec 2009 10:04:37 -0800 (PST) Received: from mail32c40.carrierzone.com (mail32c40.carrierzone.com [209.235.156.172]) by core3.amsl.com (Postfix) with ESMTP id 2CBA13A67A7 for ; Tue, 8 Dec 2009 10:04:08 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail32c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB8I3pE8001926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2009 18:03:55 GMT Message-ID: <4B1E9508.1010502@grotto-networking.com> Date: Tue, 08 Dec 2009 10:03:52 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Evelyne Roch References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com> <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> <4B197A79.1020301@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com> In-Reply-To: <90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com> Content-Type: multipart/alternative; boundary="------------080405050403020505040802" Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 18:04:38 -0000 This is a multi-part message in MIME format. --------------080405050403020505040802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Evelyne, the main focus on this work was to support VCGs with diversely routed routed members. We were asked to include the member sharing scenario and formulated a method to accommodate it without significantly increasing the complexity of the messages involved. It seems to us that the solution included in this draft provides sufficient functionality to meet the requirements in the document. Is there a scenario you think is within the scope of the draft that is not addressed? Greg Evelyne Roch wrote: > Greg, see below. > > >> -----Original Message----- >> From: Greg Bernstein [mailto:gregb@grotto-networking.com] >> Sent: Friday, December 04, 2009 4:09 PM >> To: Roch, Evelyne (CAR:Q840) >> Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP >> Subject: Re: [CCAMP] Working group >> > lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 > > > > >> I'm not sure that we have calls of calls in GMPLS. At the time this >> was written this wasn't deemed desirable. >> > > The model of calls being supported by calls is clearly support by ASON, > whether at the same layer (see G.8080 section 6.7) or different layer > (section 6.6). I find it highly desirable. > > > > Evelyne > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------080405050403020505040802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Evelyne, the main focus on this work was to support VCGs with diversely routed routed members. We were asked to include the member sharing scenario and formulated a method to accommodate it without significantly increasing the complexity of the messages involved.  It seems to us that the solution included in this draft provides sufficient functionality to meet the requirements in the document. Is there a scenario you think is within the scope of the draft that is not addressed?

Greg

Evelyne Roch wrote: 
Greg, see below.

  
-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com] 
Sent: Friday, December 04, 2009 4:09 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
    
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

<snip>

  
I'm not sure that we have calls of calls in GMPLS. At the time this
was written this wasn't deemed desirable.
    

The model of calls being supported by calls is clearly support by ASON,
whether at the same layer (see G.8080 section 6.7) or different layer
(section 6.6). I find it highly desirable.

<snip>

Evelyne


  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------080405050403020505040802-- From francesco.fondelli@gmail.com Tue Dec 8 10:19:43 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2191A3A6A35; Tue, 8 Dec 2009 10:19:43 -0800 (PST) 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 c39b1prwpqv0; Tue, 8 Dec 2009 10:19:42 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id E2D833A6A19; Tue, 8 Dec 2009 10:19:41 -0800 (PST) Received: by fxm5 with SMTP id 5so6529333fxm.28 for ; Tue, 08 Dec 2009 10:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9BfppSrhlP/z4480OOVWHvqT4tVYmTlpZfcQsf7pUto=; b=VujlemEw3fUf31H1MnbMXRTW1DEvIWbI3a5NOBZvCQ2/1dUnW4HKfOHquzwhUNtzyG SrFZI9uqYYIC4tvG7B6VRsWLiK0dXqqIdOoBBjORYw5b3X3Ta5yQS5f2FWo3inQW8Zee bDUJ9aIaq4YXZkZG1SwrMmqhTfma0iBuwP2sQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fAEFEDECu10Miz9ymUumaKhm5AcJL7vqpe75UX3AJwm/8XFymc52QSDnGyOKAyGQ8F UF+EKsX5CBhJOjrmT8lbxNGURPJwBrmd0XR3FrQkfDSRcRx9v7Ks/rOTXzs77TS9s0NR D6NRD9H0HgsTiJ27V7UC0iEozjHccSRDdCPkU= MIME-Version: 1.0 Received: by 10.223.4.220 with SMTP id 28mr1407707fas.18.1260296368058; Tue, 08 Dec 2009 10:19:28 -0800 (PST) In-Reply-To: <4B1E56A3.1020604@pi.nu> References: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> <4B16809A.3040409@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AC8@ESESSCMS0355.eemea.ericsson.se> <4B17C57B.40200@pi.nu> <4B1E56A3.1020604@pi.nu> Date: Tue, 8 Dec 2009 19:19:27 +0100 Message-ID: <7c923b5e0912081019mb3c955fn2571e0b4efe8e5de@mail.gmail.com> From: Francesco Fondelli To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ccamp@ietf.org" , Chris Benson , "mpls-tp@ietf.org" Subject: Re: [CCAMP] [mpls-tp] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 18:19:43 -0000 On Tue, Dec 8, 2009 at 2:37 PM, Loa Andersson wrote: > 1. We agree that this is an error, and I'm also fine with > =A0 sending the error message indicating incompatible sub-TLV > 2. I'm less convinced, but open to discuss, turning off "the > =A0 function". Are you proposing turning off the function indicated > =A0 by the sub-TLV? Or any active OAM funtions? I believe the > =A0 first. I would be rather hesitant to do any changes based > =A0 on something that we can identify as an error. > =A0 Though I guess that your reasoning is that the flag indicates > =A0 "turn off". > =A0 I can see that, but would like to have more comments. An error is an error, send back a big NACK to the originator of the request and do nothing (well... one may log something). I'd go for the original proposal (which is already described in the oam-configuration-fwk ID, I think). My 2p. > /Loa Ciao FF From cbenson@adax.com Tue Dec 8 11:51:44 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13AD13A68A2; Tue, 8 Dec 2009 11:51:44 -0800 (PST) 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 HPw+nZSLNxWD; Tue, 8 Dec 2009 11:51:42 -0800 (PST) Received: from mail1.adax.com (mail1.adax.com [208.201.231.104]) by core3.amsl.com (Postfix) with ESMTP id 108FC3A657C; Tue, 8 Dec 2009 11:51:42 -0800 (PST) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 7E8071209C5; Tue, 8 Dec 2009 11:51:31 -0800 (PST) Received: by adax (Postfix, from userid 243) id 6593A8E52B; Tue, 8 Dec 2009 11:51:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id 5E4988E52A; Tue, 8 Dec 2009 11:51:57 -0800 (PST) Date: Tue, 8 Dec 2009 11:51:57 -0800 (PST) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Loa Andersson , Attila.Takacs@ericsson.com, Francesco.Fondelli@gmail.com In-Reply-To: <4B1E56A3.1020604@pi.nu> Message-ID: References: <53CCFDD6E346CB43994852666C210E910925CC3F@esealmw116.eemea.ericsson.se> <4B16809A.3040409@pi.nu> <79F41BA1E9BF3C489375521EF8DDE23C016A4AC8@ESESSCMS0355.eemea.ericsson.se> <4B17C57B.40200@pi.nu> <4B1E56A3.1020604@pi.nu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 08 Dec 2009 12:00:07 -0800 Cc: "ccamp@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [CCAMP] [mpls-tp] Thoughts on updating the OAM Configuration fwk and the MPLS-TP OAM configuration drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 19:51:44 -0000 Loa, Yes, I believe you understood my original suggestion. My intention was to suggest that if a specific flag is NOT set, AND the related function was previously enabled, then it would become disabled (turned off). The only case under discussion (by me) is where there is erroneously also a specific-function-related sub-TLV parameter present, which I think we agree should only be present when turning ON a function (flag SET). I am less in favour of my own proposal today (following one other negative response), because I guess there will remain only a small number of flags, and only a correspondingly small number of sub-TLV parameters that should NOT be present when the flag is NOT set. My original comment was to simplify the parsing of whether a previously enabled function should be turned OFF. [I previously suggested:] IF ((a function was previously enabled) AND (its specific flag is now NOT set)) THEN disable the function. ... regardless of any erroneously included sub-TLVs. But as has been emphasized [thanks Francesco], this can be considered (in the erroneous case) to be: [BAD corollary of my suggestion:] IF (the received message is erroneously inconsistent) THEN maybe do it anyway. which is more important to avoid than slightly more complicated parsing. I'm withdrawing my suggestion, and agree with Loa's original 4 numbered cases, as characterized by Francesco Fondelli (an error is an error and deserves a NAK). So, "never mind", and thanks for the responses. Chris Benson. On Tue, 8 Dec 2009, Loa Andersson wrote: >> Date: Tue, 08 Dec 2009 14:37:39 +0100 >> From: Loa Andersson >> To: Chris Benson , "ccamp@ietf.org" , >> "mpls-tp@ietf.org" >> Subject: Re: [mpls-tp] [CCAMP] Thoughts on updating the OAM Configuration >> fwk and the MPLS-TP OAM configuration drafts >> >> Chris, >> >> see inline please. >> >> Chris Benson wrote: >> > Loa and Attila, >> > >> > When viewing the four possibilities as enumerated by >> > Loa, I wonder if the fourth might be better thus: >> > >> > 4. A flag is not set, but there is sub-tlv >> > - this will result in the function being TURNED OFF, >> > AND is treated as an error condition: an error message >> > should be returned (indicating incompatible sub-tlv). >> >> This is what I had proposed >> >> 4. A flag is not set, but there is sub-tlv >> - this should be treated as an error conditions and an >> error message should be returned, no changes to the configured >> OAM should be made. >> >> I see the rational behind what you are saying, so >> >> 1. We agree that this is an error, and I'm also fine with >> sending the error message indicating incompatible sub-TLV >> 2. I'm less convinced, but open to discuss, turning off "the >> function". Are you proposing turning off the function indicated >> by the sub-TLV? Or any active OAM funtions? I believe the >> first. I would be rather hesitant to do any changes based >> on something that we can identify as an error. >> Though I guess that your reasoning is that the flag indicates >> "turn off". >> I can see that, but would like to have more comments. >> >> /Loa >> >> > >> > My reason for suggesting this is in case there is any >> > misidentification of whether a sub-tlv is associated >> > with the flag being considered or not. In all the other >> > three cases, the value of the flag is sufficient to >> > determine the resultant state of the function. Perhaps >> > it would be "cleaner" if that were so in this fourth case >> > as well. >> > >> > If a peer were using some unrelated experimental extension, >> > but accidentally re-used a sub-tlv tag associated with the >> > flag under examination, then it would be unable to turn >> > off the flag's feature. >> > >> > This is an error case that "shouldn't" happen, but it seems >> > cleaner to me if the flag alone can tell us the eventual >> > state of the function, without also needing the ability to >> > associate a sub-tlv (or set of sub-tlvs) with the cleared >> > flag, to identify Loa's case 4. >> > >> > Just a thought. With thanks, from Chris Benson. >> > >> > On Thu, 3 Dec 2009, Loa Andersson wrote: >> > >> > > > Date: Thu, 03 Dec 2009 15:04:43 +0100 >> > > > From: Loa Andersson >> > > > To: Attila Takacs >> > > > Cc: "ccamp@ietf.org" , "mpls-tp@ietf.org" >> > > > >> > > > Subject: Re: [mpls-tp] [CCAMP] Thoughts on updating the OAM >> > > > Configuration >> > > > fwk and the MPLS-TP OAM configuration drafts >> > > > >> > > > Attila, >> > > > >> > > > OK great, then we need to update that in the framework. >> > > > >> > > > I also have a question on the relationship between flags and >> > > > the sub-tlvs. >> > > > >> > > > I think there are four possibilities: >> > > > >> > > > 1. A flag is set, but there is no sub-tlv >> > > > - the action here should be to turn on the function the >> > > > flag indicates using default values >> > > > I also think that if a function indicated by flag is >> > > > running, it should be left unchanged, even if it is not >> > > > running on default values >> > > > >> > > > 2. A flag is set, and there is a sub-tlv >> > > > - the action here would be to turn on the function indicated by >> > > > the flag, using the parameters found in sub-tlv >> > > > >> > > > 3. A flag is not set, and there is no sub-tlv >> > > > - the action here would be to turn off any function that has >> > > > been configured earlier >> > > > >> > > > 4. A flag is not set, but there is sub-tlv >> > > > - this should be treated as an error conditions and an >> > > > error message should be returned, no changes to the configured >> > > > OAM should be made. >> > > > >> > > > Is this correctly understood? >> > > > >> > > > /Loa >> > > > >> > > > Attila Takacs wrote: >> > > > > Hi Loa, >> > > > > >> > > > > It can be carried in the LSP_ATTRIBUTES Object in the Resv message; >> > > > > so it >> > > > > can be used for timer negotiation and discriminator synchronization >> > > > > if >> > > > > needed. >> > > > > >> > > > > Attila >> > > > > >> > > > > > -----Original Message----- >> > > > > > From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, December >> > > > > > 02, >> > > > > > 2009 3:59 PM >> > > > > > To: Attila Takacs >> > > > > > Cc: ccamp@ietf.org; mpls-tp@ietf.org >> > > > > > Subject: Re: [CCAMP] Thoughts on updating the OAM Configuration >> > > > > > fwk and >> > > > > > the MPLS-TP OAM configuration drafts >> > > > > > >> > > > > > Attila, >> > > > > > >> > > > > > thanks - I think things are converging quite a bit now. >> > > > > > >> > > > > > May the OAM Configuration TLV specified in the OAM Configuration >> > > > > > Framweork only be present in the PATH message? >> > > > > > >> > > > > > /Loa >> > > > > > >> > > > > > Attila Takacs wrote: >> > > > > > > Hi all, >> > > > > > > >> > > > > > > Some thoughts on updating the OAM Configuration fwk and the >> > > > > > > MPLS-TP >> > > > > > > OAM configuration drafts. >> > > > > > > >> > > > > > > I think we need to extend the OAM Function flags (described in >> > > > > > > draft-ietf-ccamp-oam-configuration-fwk-02) to five flags: >> > > > > > > >> > > > > > > -CC >> > > > > > > -CV >> > > > > > > -PM Loss >> > > > > > > -PM Delay >> > > > > > > -Fault Management signals >> > > > > > > >> > > > > > > >> > > > > > > With regards to BFD I see three operation vs. configuration >> > > > > > > modes: >> > > > > > > >> > > > > > > 1) Set CC in the flags and only bootstrap the BFD session, >> > > > > > by sending >> > > > > > > the local discriminator values in RSVP-TE and leave timer >> > > > > > negotiation >> > > > > > > to BFD control messages. This is similar to LSP Ping based >> > > > > > > bootstrapping described in draft-ietf-bfd-mpls-07.txt. >> > > > > > > >> > > > > > > 2) Set CC in the flags but configure the timers via the >> > > > > > control plane, >> > > > > > > this should correspond to "CC mode" in >> > > > > > draft-asm-mpls-tp-bfd-cc-cv-01. >> > > > > > > We may include the min/max intervals and by doing so >> > > > > > support initial >> > > > > > > timer negotiation in control plane. However, we may need a >> > > > > > flag in CC >> > > > > > > configuration sub-TLV (now in >> > > > > > > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 called >> > > > > > "Suggested TX >> > > > > > > Interval sub-TLV") to indicate whether data plane timer >> > > > > > renegotiation >> > > > > > > is enabled or disabled (i.e., subsequently via BFD control >> > > > > > messages). >> > > > > > > This, as described in draft-asm-mpls-tp-bfd-cc-cv-01, should be >> > > > > > > disabled for TP LSPs by default. >> > > > > > > >> > > > > > > 3) In case of "full" MPLS-TP OAM support any of the flags >> > > > > > could be set >> > > > > > > as needed, reflecting "CV/CC mode" described in >> > > > > > > draft-asm-mpls-tp-bfd-cc-cv-01, delay and loss measurement as >> > > > > > > described in draft-frost-mpls-tp-loss-delay-00 and >> > > > > > management signals >> > > > > > > as given in draft-sfv-mpls-tp-fault-00. >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > To configure CC we will need to add >> > > > > > > -enable/disable DP timer re-negotiation -PHB to identify >> > > > > > priority and >> > > > > > > drop precedence of CC packets >> > > > > > > >> > > > > > > When it comes to CV, it would be interesting to discuss >> > > > > > whether only >> > > > > > > the OAM identifiers described in >> > > > > > draft-ietf-mpls-tp-identifiers-00 are >> > > > > > > ought to be supported. If so, those could be derived from >> > > > > > > RSVP-TE >> > > > > > > signaling without the need to carry them explicitly in MPLS-TP >> > > > > > > OAM >> > > > > > > Configuration sub-TLVs (now called Source unique MEP_ID sub-TLV >> > > > > > > in >> > > > > > > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03). >> > > > > > > >> > > > > > > For Performance Monitoring Loss/Delay we need to add new TLVs, >> > > > > > > carrying -measurement interval -possibly loss/delay bound >> > > > > > thresholds >> > > > > > > (given we what these for MPLS-TP) that could be used to assess >> > > > > > > the >> > > > > > > quality of the connection and may eventually trigger >> > > > > > protection -PHB >> > > > > > > of control packets if we want to set it differently from CC >> > > > > > packets or >> > > > > > > from data traffic. >> > > > > > > >> > > > > > > For the Fault Management Signals, I would add a new "Fault >> > > > > > Management >> > > > > > > Signals sub-TLV" carrying: >> > > > > > > -Enabled signals flags: AIS, LDI, LKR, CFS (which, except CFS, >> > > > > > > are >> > > > > > > specified in draft-sfv-mpls-tp-fault-00) -refresh timer of fault >> > > > > > > indication messages -flag to enable/disable explicitly >> > > > > > clear of faults >> > > > > > > -PHB of fault management packets >> > > > > > > >> > > > > > > >> > > > > > > Another thing we may want to consider is adding a sub-TLV to set >> > > > > > > consequent actions that are configurable. This is described to >> > > > > > > some >> > > > > > > extent in the MPLS-TP OAM Framework. The defects identified >> > > > > > > include: >> > > > > > > Loss Of Continuity defect, Mis-connectivity defect, MEP >> > > > > > > misconfiguration defect, Period Misconfiguration defect. >> > > > > > > >> > > > > > > An operator may want to configure if the consequence of LOC >> > > > > > should be >> > > > > > > the blocking or non-blocking of outgoing data traffic. Similarly >> > > > > > > it >> > > > > > > may be useful to configure whether the "Period >> > > > > > Misconfiguration defect" >> > > > > > > should result in a signal fail condition or not. >> > > > > > > >> > > > > > > >> > > > > > > I plan to send detailed text to the editors of >> > > > > > > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-03 along the >> > > > > > > lines >> > > > > > > described above. Please comment! >> > > > > > > Thanks, >> > > > > > > Attila >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > _______________________________________________ >> > > > > > > CCAMP mailing list >> > > > > > > CCAMP@ietf.org >> > > > > > > https://www.ietf.org/mailman/listinfo/ccamp >> > > > > > -- >> > > > > > >> > > > > > >> > > > > > Loa Andersson email: >> > > > > > loa.andersson@ericsson.com >> > > > > > Sr Strategy and Standards Manager loa@pi.nu >> > > > > > Ericsson Inc phone: +46 10 717 52 13 >> > > > > > +46 767 72 92 13 >> > > > >> > > > -- >> > > > >> > > > >> > > > Loa Andersson email: >> > > > loa.andersson@ericsson.com >> > > > Sr Strategy and Standards Manager loa@pi.nu >> > > > Ericsson Inc phone: +46 10 717 52 13 >> > > > +46 767 72 92 13 >> > > > _______________________________________________ >> > > > mpls-tp mailing list >> > > > mpls-tp@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/mpls-tp >> > > > >> > > > >> >> -- >> >> >> Loa Andersson email: loa.andersson@ericsson.com >> Sr Strategy and Standards Manager loa@pi.nu >> Ericsson Inc phone: +46 10 717 52 13 >> +46 767 72 92 13 >> From root@core3.amsl.com Tue Dec 8 14:00:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A9CD83A6A82; Tue, 8 Dec 2009 14:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091208220001.A9CD83A6A82@core3.amsl.com> Date: Tue, 8 Dec 2009 14:00:01 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-wson-signal-compatibility-ospf-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 22:00:01 -0000 --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 Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks Author(s) : Y. Lee, G. Bernstein Filename : draft-ietf-ccamp-wson-signal-compatibility-ospf-00.txt Pages : 15 Date : 2009-12-08 This document provides GMPLS OSPF routing enhancements to support signal compatibility constraints associated with WSON network elements. These routing enhancements are required in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals. 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-wson-signal-compatibility-ospf-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-wson-signal-compatibility-ospf-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-08135959.I-D@ietf.org> --NextPart-- From EROCH@nortel.com Wed Dec 9 12:51:18 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02D83A65A6 for ; Wed, 9 Dec 2009 12:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 oYogaKo5Aq8G for ; Wed, 9 Dec 2009 12:51:17 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 1560C3A657C for ; Wed, 9 Dec 2009 12:51:15 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nB9KouT14182; Wed, 9 Dec 2009 20:50:56 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_01CA7911.3569B4C2" Date: Wed, 9 Dec 2009 15:50:14 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com> In-Reply-To: <4B1E9508.1010502@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: Acp4MNK55Mfi3nDqRR6kseKDKcIjoQA3/KTQ References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com> <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> <4B197A79.1020301@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com> <4B1E9508.1010502@grotto-networking.com> From: "Evelyne Roch" To: "Greg Bernstein" Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 20:51:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7911.3569B4C2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, =20 First, I think we need to further clarify the requirements as I'm not sure all the readers will interpret the requirements the same way. What exactly does it mean to be "in a common pool"? =20 Evelyne ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Tuesday, December 08, 2009 1:04 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi Evelyne, the main focus on this work was to support VCGs with diversely routed routed members. We were asked to include the member sharing scenario and formulated a method to accommodate it without significantly increasing the complexity of the messages involved. It seems to us that the solution included in this draft provides sufficient functionality to meet the requirements in the document. Is there a scenario you think is within the scope of the draft that is not addressed? Greg Evelyne Roch wrote:=20 Greg, see below. =09 =20 -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Friday, December 04, 2009 4:09 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group =20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 =20 I'm not sure that we have calls of calls in GMPLS. At the time this was written this wasn't deemed desirable. =20 =09 The model of calls being supported by calls is clearly support by ASON, whether at the same layer (see G.8080 section 6.7) or different layer (section 6.6). I find it highly desirable. =09 =09 Evelyne =09 =09 =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 ------_=_NextPart_001_01CA7911.3569B4C2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greg,
 
First, I think we need to further clarify the = requirements=20 as I'm not sure all the readers will interpret the requirements the = same=20 way. What exactly does it mean to be "in a common=20 pool"?
 
Evelyne

From: Greg Bernstein=20 [mailto:gregb@grotto-networking.com]
Sent: Tuesday, December = 08, 2009=20 1:04 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, = DEBORAH A=20 (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group=20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, the main focus on this work was to support VCGs = with=20 diversely routed routed members. We were asked to include the member = sharing=20 scenario and formulated a method to accommodate it without significantly = increasing the complexity of the messages involved.  It seems to us = that=20 the solution included in this draft provides sufficient functionality to = meet=20 the requirements in the document. Is there a scenario you think is = within the=20 scope of the draft that is not addressed?

Greg

Evelyne = Roch wrote:=20 
Greg, see below.

  
-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networkin=
g.com]=20
Sent: Friday, December 04, 2009 4:09 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
    
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

<snip>

  
I'm not sure that we have =
calls of calls in GMPLS. At the time this
was written this wasn't deemed desirable.
    

The model of calls being supported by calls is clearly support by ASON,
whether at the same layer (see G.8080 section 6.7) or different layer
(section 6.6). I find it highly desirable.

<snip>

Evelyne


  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
------_=_NextPart_001_01CA7911.3569B4C2-- From gregb@grotto-networking.com Wed Dec 9 14:34:15 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6183A692F for ; Wed, 9 Dec 2009 14:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=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 rEYRpCq4Ljm0 for ; Wed, 9 Dec 2009 14:34:14 -0800 (PST) Received: from mail16c40.carrierzone.com (mail16c40.carrierzone.com [209.235.156.156]) by core3.amsl.com (Postfix) with ESMTP id C1E823A694A for ; Wed, 9 Dec 2009 14:34:13 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail16c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id nB9MY3Vd012582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2009 22:34:07 GMT Message-ID: <4B2025D3.3090208@grotto-networking.com> Date: Wed, 09 Dec 2009 14:33:55 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Evelyne Roch References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com> <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> <4B197A79.1020301@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com> <4B1E9508.1010502@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com> In-Reply-To: <90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com> Content-Type: multipart/alternative; boundary="------------070009070407090809080807" Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 22:34:15 -0000 This is a multi-part message in MIME format. --------------070009070407090809080807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Evelyne, the common pool is a set of potential member signals that have been set up using the mechanisms defined in the draft, particularly the VCAT call procedures. The draft allows these to be "shared" amongst different VCGs over time. Note that at any given point in time a member signal can belong to only one VCG. Note that by the nature of VCAT that these are signals that have the same source and destination. The procedures section makes this fairly clear. Greg Evelyne Roch wrote: > Greg, > > First, I think we need to further clarify the requirements as I'm not > sure all the readers will interpret the requirements the same way. > What exactly does it mean to be "in a common pool"? > > Evelyne > > ------------------------------------------------------------------------ > *From:* Greg Bernstein [mailto:gregb@grotto-networking.com] > *Sent:* Tuesday, December 08, 2009 1:04 PM > *To:* Roch, Evelyne (CAR:Q840) > *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP > *Subject:* Re: [CCAMP] Working group > lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 > > Hi Evelyne, the main focus on this work was to support VCGs with > diversely routed routed members. We were asked to include the member > sharing scenario and formulated a method to accommodate it without > significantly increasing the complexity of the messages involved. It > seems to us that the solution included in this draft provides > sufficient functionality to meet the requirements in the document. Is > there a scenario you think is within the scope of the draft that is > not addressed? > > Greg > > Evelyne Roch wrote: >> Greg, see below. >> >> >>> -----Original Message----- >>> From: Greg Bernstein [mailto:gregb@grotto-networking.com] >>> Sent: Friday, December 04, 2009 4:09 PM >>> To: Roch, Evelyne (CAR:Q840) >>> Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP >>> Subject: Re: [CCAMP] Working group >>> >> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 >> >> >> >> >>> I'm not sure that we have calls of calls in GMPLS. At the time this >>> was written this wasn't deemed desirable. >>> >> >> The model of calls being supported by calls is clearly support by ASON, >> whether at the same layer (see G.8080 section 6.7) or different layer >> (section 6.6). I find it highly desirable. >> >> >> >> Evelyne >> >> >> > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------070009070407090809080807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Evelyne, the common pool is a set of potential member signals that have been set up using the mechanisms defined in the draft, particularly the VCAT call procedures. The draft allows these to be "shared" amongst different VCGs over time. Note that at any given point in time a member signal can belong to only one VCG. Note that by the nature of VCAT that these are signals that have the same source and destination. The procedures section makes this fairly clear.

Greg



Evelyne Roch wrote:
Greg,
 
First, I think we need to further clarify the requirements as I'm not sure all the readers will interpret the requirements the same way. What exactly does it mean to be "in a common pool"?
 
Evelyne

From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Tuesday, December 08, 2009 1:04 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, the main focus on this work was to support VCGs with diversely routed routed members. We were asked to include the member sharing scenario and formulated a method to accommodate it without significantly increasing the complexity of the messages involved.  It seems to us that the solution included in this draft provides sufficient functionality to meet the requirements in the document. Is there a scenario you think is within the scope of the draft that is not addressed?

Greg

Evelyne Roch wrote: 
Greg, see below.

  
-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com] 
Sent: Friday, December 04, 2009 4:09 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
    
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

<snip>

  
I'm not sure that we have calls of calls in GMPLS. At the time this
was written this wasn't deemed desirable.
    

The model of calls being supported by calls is clearly support by ASON,
whether at the same layer (see G.8080 section 6.7) or different layer
(section 6.6). I find it highly desirable.

<snip>

Evelyne


  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------070009070407090809080807-- From EROCH@nortel.com Thu Dec 10 07:53:57 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804433A6ABA for ; Thu, 10 Dec 2009 07:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 7l5TwkQcjjIf for ; Thu, 10 Dec 2009 07:53:56 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0DE013A6AB3 for ; Thu, 10 Dec 2009 07:53:55 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nBAFrVj17931; Thu, 10 Dec 2009 15:53:31 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_01CA79B0.BDEAD188" Date: Thu, 10 Dec 2009 10:52:13 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02BC96A4@zcarhxm2.corp.nortel.com> In-Reply-To: <4B2025D3.3090208@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: Acp5LNwjXQxTKuDSRRyBNgS+Nrvy2QAgXgHg References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com> <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> <4B197A79.1020301@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com> <4B1E9508.1010502@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com> <4B2025D3.3090208@grotto-networking.com> From: "Evelyne Roch" To: "Greg Bernstein" Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 15:53:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA79B0.BDEAD188 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg, =20 Normally, I would expect the requirements section to be clear enough that it helps define a proper solution mechanism and clearly sets the scope, not the other way around (i.e. you need to read the mechanism to understand how the requirements should be interpreted). =20 My main concern is how the "call concept" is being used with the member sharing scenario, as I mentioned earlier in this thread. The calls (in the draft) are really member calls, not VCAT group calls. But the call attributes contain VCAT group information. I don't want the member call to attribute carry call information for the entire VCAT group. =20 Evelyne ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Wednesday, December 09, 2009 5:34 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi Evelyne, the common pool is a set of potential member signals that have been set up using the mechanisms defined in the draft, particularly the VCAT call procedures. The draft allows these to be "shared" amongst different VCGs over time. Note that at any given point in time a member signal can belong to only one VCG. Note that by the nature of VCAT that these are signals that have the same source and destination. The procedures section makes this fairly clear. Greg Evelyne Roch wrote:=20 Greg, =20 First, I think we need to further clarify the requirements as I'm not sure all the readers will interpret the requirements the same way. What exactly does it mean to be "in a common pool"? =20 Evelyne ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Tuesday, December 08, 2009 1:04 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 Hi Evelyne, the main focus on this work was to support VCGs with diversely routed routed members. We were asked to include the member sharing scenario and formulated a method to accommodate it without significantly increasing the complexity of the messages involved. It seems to us that the solution included in this draft provides sufficient functionality to meet the requirements in the document. Is there a scenario you think is within the scope of the draft that is not addressed? =09 Greg =09 Evelyne Roch wrote:=20 Greg, see below. =09 =20 -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Friday, December 04, 2009 4:09 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group =20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 =20 I'm not sure that we have calls of calls in GMPLS. At the time this was written this wasn't deemed desirable. =20 =09 The model of calls being supported by calls is clearly support by ASON, whether at the same layer (see G.8080 section 6.7) or different layer (section 6.6). I find it highly desirable. =09 =09 Evelyne =09 =09 =20 --=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =09 =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 ------_=_NextPart_001_01CA79B0.BDEAD188 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greg,
 
Normally, I would expect the requirements = section to be=20 clear enough that it helps define a proper solution mechanism and = clearly sets=20 the scope, not the other way around (i.e. you need to read the mechanism = to=20 understand how the requirements should be = interpreted).
 
My main concern is how the "call = concept" is being=20 used with the member sharing scenario, as I mentioned earlier in this = thread.=20 The calls (in the draft) are really member calls, not VCAT group = calls. But=20 the call attributes contain VCAT group information. I don't want=20 the  member call to attribute carry call information for the = entire=20 VCAT group.
 
Evelyne

From: Greg Bernstein=20 [mailto:gregb@grotto-networking.com]
Sent: Wednesday, = December 09,=20 2009 5:34 PM
To: Roch, Evelyne (CAR:Q840)
Cc: = BRUNGARD,=20 DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group=20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, the common pool is a set of potential member = signals that=20 have been set up using the mechanisms defined in the draft, particularly = the=20 VCAT call procedures. The draft allows these to be "shared" amongst = different=20 VCGs over time. Note that at any given point in time a member signal can = belong=20 to only one VCG. Note that by the nature of VCAT that these are signals = that=20 have the same source and destination. The procedures section makes this = fairly=20 clear.

Greg



Evelyne Roch wrote:=20
Greg,
 
First, I think we need to further clarify the = requirements as I'm not sure all the readers will interpret=20 the requirements the same way. What exactly does it mean to = be "in a=20 common pool"?
 
Evelyne

From: Greg Bernstein [mailto:gregb@grotto-networkin= g.com]=20
Sent: Tuesday, December 08, 2009 1:04 PM
To: = Roch,=20 Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20 CCAMP
Subject: Re: [CCAMP] Working group=20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi = Evelyne,=20 the main focus on this work was to support VCGs with diversely routed = routed=20 members. We were asked to include the member sharing scenario and = formulated a=20 method to accommodate it without significantly increasing the = complexity of=20 the messages involved.  It seems to us that the solution included = in this=20 draft provides sufficient functionality to meet the requirements in = the=20 document. Is there a scenario you think is within the scope of the = draft that=20 is not addressed?

Greg

Evelyne Roch wrote:=20 
Greg, see below.

  
-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
Sent: Friday, December 04, 2009 4:09 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
    
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

<snip>

  
I'm not sure that we have =
calls of calls in GMPLS. At the time this
was written this wasn't deemed desirable.
    

The model of calls being supported by calls is clearly support by ASON,
whether at the same layer (see G.8080 section 6.7) or different layer
(section 6.6). I find it highly desirable.

<snip>

Evelyne


  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
------_=_NextPart_001_01CA79B0.BDEAD188-- From gregb@grotto-networking.com Thu Dec 10 08:16:46 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E633A6882 for ; Thu, 10 Dec 2009 08:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=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 XaxBO4TB2Tp8 for ; Thu, 10 Dec 2009 08:16:44 -0800 (PST) Received: from mail14c40.carrierzone.com (mail14c40.carrierzone.com [209.235.156.154]) by core3.amsl.com (Postfix) with ESMTP id 6EB453A69F9 for ; Thu, 10 Dec 2009 08:16:44 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail14c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id nBAGGTKV004411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 16:16:34 GMT Message-ID: <4B211ED9.30908@grotto-networking.com> Date: Thu, 10 Dec 2009 08:16:25 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Evelyne Roch References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com> <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> <4B197A79.1020301@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com> <4B1E9508.1010502@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com> <4B2025D3.3090208@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC96A4@zcarhxm2.corp.nortel.com> In-Reply-To: <90243C8A881F8D419D855264D9636F3A02BC96A4@zcarhxm2.corp.nortel.com> Content-Type: multipart/alternative; boundary="------------080803000700080209080001" Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 16:16:46 -0000 This is a multi-part message in MIME format. --------------080803000700080209080001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Evelyne, I'll add some text to the requirements section to clarify "common pool" per your request. The "call concept" usage and "member sharing scenario" have been previously discussed, liaised, and resolved with ITU-T. https://datatracker.ietf.org/liaison/415/ It includes: ITU: "Per Question 5: We understand that this draft is only addressing the constituent server layer call; i.e., not the ASON multilayer call supporting call construct. However, we suggest that you do not preclude extensions to use a call in the VCAT layer. CCAMP response: As noted above, this is not precluded. We look forward to future communication from you as you progress this work." Q14 later responded saying they were satisfied with the one call construct: https://datatracker.ietf.org/liaison/429/ Greg Evelyne Roch wrote: > Greg, > > Normally, I would expect the requirements section to be clear enough > that it helps define a proper solution mechanism and clearly sets the > scope, not the other way around (i.e. you need to read the mechanism > to understand how the requirements should be interpreted). > > My main concern is how the "call concept" is being used with the > member sharing scenario, as I mentioned earlier in this thread. The > calls (in the draft) are really member calls, not VCAT group > calls. But the call attributes contain VCAT group information. I don't > want the member call to attribute carry call information for the > entire VCAT group. > > Evelyne > > ------------------------------------------------------------------------ > *From:* Greg Bernstein [mailto:gregb@grotto-networking.com] > *Sent:* Wednesday, December 09, 2009 5:34 PM > *To:* Roch, Evelyne (CAR:Q840) > *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP > *Subject:* Re: [CCAMP] Working group > lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 > > Hi Evelyne, the common pool is a set of potential member signals that > have been set up using the mechanisms defined in the draft, > particularly the VCAT call procedures. The draft allows these to be > "shared" amongst different VCGs over time. Note that at any given > point in time a member signal can belong to only one VCG. Note that by > the nature of VCAT that these are signals that have the same source > and destination. The procedures section makes this fairly clear. > > Greg > > > > Evelyne Roch wrote: >> Greg, >> >> First, I think we need to further clarify the requirements as I'm not >> sure all the readers will interpret the requirements the same way. >> What exactly does it mean to be "in a common pool"? >> >> Evelyne >> >> ------------------------------------------------------------------------ >> *From:* Greg Bernstein [mailto:gregb@grotto-networking.com] >> *Sent:* Tuesday, December 08, 2009 1:04 PM >> *To:* Roch, Evelyne (CAR:Q840) >> *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP >> *Subject:* Re: [CCAMP] Working group >> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 >> >> Hi Evelyne, the main focus on this work was to support VCGs with >> diversely routed routed members. We were asked to include the member >> sharing scenario and formulated a method to accommodate it without >> significantly increasing the complexity of the messages involved. It >> seems to us that the solution included in this draft provides >> sufficient functionality to meet the requirements in the document. Is >> there a scenario you think is within the scope of the draft that is >> not addressed? >> >> Greg >> >> Evelyne Roch wrote: >>> Greg, see below. >>> >>> >>>> -----Original Message----- >>>> From: Greg Bernstein [mailto:gregb@grotto-networking.com] >>>> Sent: Friday, December 04, 2009 4:09 PM >>>> To: Roch, Evelyne (CAR:Q840) >>>> Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP >>>> Subject: Re: [CCAMP] Working group >>>> >>> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 >>> >>> >>> >>> >>>> I'm not sure that we have calls of calls in GMPLS. At the time this >>>> was written this wasn't deemed desirable. >>>> >>> >>> The model of calls being supported by calls is clearly support by ASON, >>> whether at the same layer (see G.8080 section 6.7) or different layer >>> (section 6.6). I find it highly desirable. >>> >>> >>> >>> Evelyne >>> >>> >>> >> >> -- >> =================================================== >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> >> > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------080803000700080209080001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Evelyne, I'll add some text to the requirements section to clarify "common pool" per your request.
The "call concept" usage and "member sharing scenario" have been previously discussed, liaised, and resolved with ITU-T. 
https://datatracker.ietf.org/liaison/415/

It includes:
ITU: "Per Question 5:  We understand that this draft is only addressing
the
constituent server layer call; i.e., not the ASON multilayer call
supporting call construct. However, we suggest that you do not preclude
extensions to use a call in the VCAT layer.

CCAMP response: As noted above, this is not precluded. We look forward to
future communication from you as you progress this work."

Q14 later responded saying they were satisfied with the one call
construct:
https://datatracker.ietf.org/liaison/429/
Greg

Evelyne Roch wrote:
Greg,
 
Normally, I would expect the requirements section to be clear enough that it helps define a proper solution mechanism and clearly sets the scope, not the other way around (i.e. you need to read the mechanism to understand how the requirements should be interpreted).
 
My main concern is how the "call concept" is being used with the member sharing scenario, as I mentioned earlier in this thread. The calls (in the draft) are really member calls, not VCAT group calls. But the call attributes contain VCAT group information. I don't want the  member call to attribute carry call information for the entire VCAT group.
 
Evelyne

From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Wednesday, December 09, 2009 5:34 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, the common pool is a set of potential member signals that have been set up using the mechanisms defined in the draft, particularly the VCAT call procedures. The draft allows these to be "shared" amongst different VCGs over time. Note that at any given point in time a member signal can belong to only one VCG. Note that by the nature of VCAT that these are signals that have the same source and destination. The procedures section makes this fairly clear.

Greg



Evelyne Roch wrote:
Greg,
 
First, I think we need to further clarify the requirements as I'm not sure all the readers will interpret the requirements the same way. What exactly does it mean to be "in a common pool"?
 
Evelyne

From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Tuesday, December 08, 2009 1:04 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, the main focus on this work was to support VCGs with diversely routed routed members. We were asked to include the member sharing scenario and formulated a method to accommodate it without significantly increasing the complexity of the messages involved.  It seems to us that the solution included in this draft provides sufficient functionality to meet the requirements in the document. Is there a scenario you think is within the scope of the draft that is not addressed?

Greg

Evelyne Roch wrote: 
Greg, see below.

  
-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com] 
Sent: Friday, December 04, 2009 4:09 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
    
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

<snip>

  
I'm not sure that we have calls of calls in GMPLS. At the time this
was written this wasn't deemed desirable.
    

The model of calls being supported by calls is clearly support by ASON,
whether at the same layer (see G.8080 section 6.7) or different layer
(section 6.6). I find it highly desirable.

<snip>

Evelyne


  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------080803000700080209080001-- From EROCH@nortel.com Thu Dec 10 08:47:59 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8459528C0E3 for ; Thu, 10 Dec 2009 08:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 RPIsK4S3Isgo for ; Thu, 10 Dec 2009 08:47:58 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id DFD203A67E3 for ; Thu, 10 Dec 2009 08:47:57 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nBAGlbj28660; Thu, 10 Dec 2009 16:47: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_01CA79B8.79AF50F4" Date: Thu, 10 Dec 2009 11:47:34 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02C0F95F@zcarhxm2.corp.nortel.com> In-Reply-To: <4B211ED9.30908@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: Acp5tCghWV6AxXYgRtqJpr4GCgIm+AAA3+6g References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com> <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> <4B197A79.1020301@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com> <4B1E9508.1010502@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com> <4B2025D3.3090208@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC96A4@zcarhxm2.corp.nortel.com> <4B211ED9.30908@grotto-networking.com> From: "Evelyne Roch" To: "Greg Bernstein" Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 16:47:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA79B8.79AF50F4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This liaison was referring to version 04, before the introduction of CALL_ATTRIBUTES in the draft, exactly where the problem is. =20 In the laison 429, the ITU-T agrees to one call per VCG. That is the VCAT call (not addressed in the draft right now). =20 As far as member calls, members could be in same or different calls based on application (for diverse routing -> could be same call, for protection/restoration -> could be different calls). That is the member call used in the draft.=20 =20 The problem is that CALL_ATTRIBUTES is carried in member call signaling when it pertains to the VCG, i.e. VCAT call.=20 =20 Evelyne =20 =20 =20 =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Thursday, December 10, 2009 11:16 AM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi Evelyne, I'll add some text to the requirements section to clarify "common pool" per your request. The "call concept" usage and "member sharing scenario" have been previously discussed, liaised, and resolved with ITU-T.=20 https://datatracker.ietf.org/liaison/415/ It includes: ITU: "Per Question 5: We understand that this draft is only addressing the constituent server layer call; i.e., not the ASON multilayer call supporting call construct. However, we suggest that you do not preclude extensions to use a call in the VCAT layer. CCAMP response: As noted above, this is not precluded. We look forward to future communication from you as you progress this work." Q14 later responded saying they were satisfied with the one call construct: https://datatracker.ietf.org/liaison/429/ Greg Evelyne Roch wrote:=20 Greg, =20 Normally, I would expect the requirements section to be clear enough that it helps define a proper solution mechanism and clearly sets the scope, not the other way around (i.e. you need to read the mechanism to understand how the requirements should be interpreted). =20 My main concern is how the "call concept" is being used with the member sharing scenario, as I mentioned earlier in this thread. The calls (in the draft) are really member calls, not VCAT group calls. But the call attributes contain VCAT group information. I don't want the member call to attribute carry call information for the entire VCAT group. =20 Evelyne ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Wednesday, December 09, 2009 5:34 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 Hi Evelyne, the common pool is a set of potential member signals that have been set up using the mechanisms defined in the draft, particularly the VCAT call procedures. The draft allows these to be "shared" amongst different VCGs over time. Note that at any given point in time a member signal can belong to only one VCG. Note that by the nature of VCAT that these are signals that have the same source and destination. The procedures section makes this fairly clear. =09 Greg =09 =09 =09 Evelyne Roch wrote:=20 Greg, =20 First, I think we need to further clarify the requirements as I'm not sure all the readers will interpret the requirements the same way. What exactly does it mean to be "in a common pool"? =20 Evelyne ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Tuesday, December 08, 2009 1:04 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 Hi Evelyne, the main focus on this work was to support VCGs with diversely routed routed members. We were asked to include the member sharing scenario and formulated a method to accommodate it without significantly increasing the complexity of the messages involved. It seems to us that the solution included in this draft provides sufficient functionality to meet the requirements in the document. Is there a scenario you think is within the scope of the draft that is not addressed? =09 Greg =09 Evelyne Roch wrote:=20 Greg, see below. =09 =20 -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Friday, December 04, 2009 4:09 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group =20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 =20 I'm not sure that we have calls of calls in GMPLS. At the time this was written this wasn't deemed desirable. =20 =09 The model of calls being supported by calls is clearly support by ASON, whether at the same layer (see G.8080 section 6.7) or different layer (section 6.6). I find it highly desirable. =09 =09 Evelyne =09 =09 =20 --=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =09 =20 --=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =09 =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 ------_=_NextPart_001_01CA79B8.79AF50F4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This liaison was referring to version 04, = before the=20 introduction of CALL_ATTRIBUTES in the draft, exactly where the problem=20 is.
 
In the laison 429, the ITU-T agrees to one call = per VCG.=20 That is the VCAT call (not addressed in the draft right=20 now).
 
As far as member calls, members could be in = same or=20 different calls based on application (for diverse routing -> could be = same=20 call, for protection/restoration -> could be different calls). That = is the=20 member call used in the draft.
 
The problem is that CALL_ATTRIBUTES is carried = in member=20 call signaling when it pertains to the VCG, i.e. VCAT call. =
 
Evelyne
 
 
 
 

From: Greg Bernstein=20 [mailto:gregb@grotto-networking.com]
Sent: Thursday, December = 10,=20 2009 11:16 AM
To: Roch, Evelyne (CAR:Q840)
Cc: = BRUNGARD,=20 DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group=20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, I'll add some text to the requirements section to = clarify=20 "common pool" per your request.
The "call concept" usage and "member = sharing=20 scenario" have been previously discussed, liaised, and resolved with = ITU-T. 
https://datatracker.ie=
tf.org/liaison/415/

It includes:
ITU: "Per Question 5:  We understand that this draft is only addressing
the
constituent server layer call; i.e., not the ASON multilayer call
supporting call construct. However, we suggest that you do not preclude
extensions to use a call in the VCAT layer.

CCAMP response: As noted above, this is not precluded. We look forward =
to
future communication from you as you progress this work."

Q14 later responded saying they were satisfied with the one call
construct:
https://datatracker.ie=
tf.org/liaison/429/
Greg

Evelyne=20 Roch wrote:=20
Greg,
 
Normally, I would expect the requirements = section to be=20 clear enough that it helps define a proper solution mechanism and = clearly sets=20 the scope, not the other way around (i.e. you need to read the = mechanism to=20 understand how the requirements should be = interpreted).
 
My main concern is how the "call = concept" is being=20 used with the member sharing scenario, as I mentioned earlier in this = thread.=20 The calls (in the draft) are really member calls, not VCAT group=20 calls. But the call attributes contain VCAT group information. I = don't=20 want the  member call to attribute carry call information = for the=20 entire VCAT group.
 
Evelyne

From: Greg Bernstein [mailto:gregb@grotto-networkin= g.com]=20
Sent: Wednesday, December 09, 2009 5:34 PM
To: = Roch,=20 Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20 CCAMP
Subject: Re: [CCAMP] Working group=20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi = Evelyne,=20 the common pool is a set of potential member signals that have been = set up=20 using the mechanisms defined in the draft, particularly the VCAT call=20 procedures. The draft allows these to be "shared" amongst different = VCGs over=20 time. Note that at any given point in time a member signal can belong = to only=20 one VCG. Note that by the nature of VCAT that these are signals that = have the=20 same source and destination. The procedures section makes this fairly=20 clear.

Greg



Evelyne Roch wrote:=20
Greg,
 
First, I think we need to further clarify = the=20 requirements as I'm not sure all the readers will interpret=20 the requirements the same way. What exactly does it mean = to be "in=20 a common pool"?
 
Evelyne

From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
Sent: Tuesday, December 08, 2009 1:04 PM
To: = Roch,=20 Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20 CCAMP
Subject: Re: [CCAMP] Working group=20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi = Evelyne,=20 the main focus on this work was to support VCGs with diversely = routed routed=20 members. We were asked to include the member sharing scenario and = formulated=20 a method to accommodate it without significantly increasing the = complexity=20 of the messages involved.  It seems to us that the solution = included in=20 this draft provides sufficient functionality to meet the = requirements in the=20 document. Is there a scenario you think is within the scope of the = draft=20 that is not addressed?

Greg

Evelyne Roch wrote:=20 
Greg, see below.

  
-----Original =
Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
Sent: Friday, December 04, 2009 4:09 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
    
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

<snip>

  
I'm not sure that we have =
calls of calls in GMPLS. At the time this
was written this wasn't deemed desirable.
    

The model of calls being supported by calls is clearly support by ASON,
whether at the same layer (see G.8080 section 6.7) or different layer
(section 6.6). I find it highly desirable.

<snip>

Evelyne


  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
------_=_NextPart_001_01CA79B8.79AF50F4-- From gregb@grotto-networking.com Thu Dec 10 10:29:42 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74ED3A6801 for ; Thu, 10 Dec 2009 10:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=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 itIFsGeGGi+c for ; Thu, 10 Dec 2009 10:29:41 -0800 (PST) Received: from mail30c40.carrierzone.com (mail30c40.carrierzone.com [209.235.156.170]) by core3.amsl.com (Postfix) with ESMTP id 1AAA73A659B for ; Thu, 10 Dec 2009 10:29:40 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail30c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id nBAITGVA023391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 18:29:20 GMT Message-ID: <4B213E03.70508@grotto-networking.com> Date: Thu, 10 Dec 2009 10:29:23 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Evelyne Roch References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com> <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> <4B197A79.1020301@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com> <4B1E9508.1010502@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com> <4B2025D3.3090208@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC96A4@zcarhxm2.corp.nortel.com> <4B211ED9.30908@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0F95F@zcarhxm2.corp.nortel.com> In-Reply-To: <90243C8A881F8D419D855264D9636F3A02C0F95F@zcarhxm2.corp.nortel.com> Content-Type: multipart/alternative; boundary="------------060009040006060806070601" Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 18:29:42 -0000 This is a multi-part message in MIME format. --------------060009040006060806070601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Evelyne, version 04 published in February of 2008 contained a "Call_Data_Object", with a TLV containing exactly the information and utilizing the same procedures that we are now using with the CALL_ATTRIBUTES object. It was recommended by the WG chairs to use the CALL_ATTRIBUTES object as defined in the MLN-Extensions work rather than defining another "Call_data_object". None of of the procedures were changed from 04. Is there a problem with functionality? We worked very hard to find a technique utilizing existing mechanisms to give some support forthe member sharing scenario. We do not preclude other techniques being used in the future. Greg Evelyne Roch wrote: > This liaison was referring to version 04, before the introduction of > CALL_ATTRIBUTES in the draft, exactly where the problem is. > > In the laison 429, the ITU-T agrees to one call per VCG. That is the > VCAT call (not addressed in the draft right now). > > As far as member calls, members could be in same or different calls > based on application (for diverse routing -> could be same call, for > protection/restoration -> could be different calls). That is the > member call used in the draft. > > The problem is that CALL_ATTRIBUTES is carried in member call > signaling when it pertains to the VCG, i.e. VCAT call. > > Evelyne > > > > > > ------------------------------------------------------------------------ > *From:* Greg Bernstein [mailto:gregb@grotto-networking.com] > *Sent:* Thursday, December 10, 2009 11:16 AM > *To:* Roch, Evelyne (CAR:Q840) > *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP > *Subject:* Re: [CCAMP] Working group > lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 > > Hi Evelyne, I'll add some text to the requirements section to clarify > "common pool" per your request. > The "call concept" usage and "member sharing scenario" have been > previously discussed, liaised, and resolved with ITU-T. > https://datatracker.ietf.org/liaison/415/ > > It includes: > ITU: "Per Question 5: We understand that this draft is only addressing > the > constituent server layer call; i.e., not the ASON multilayer call > supporting call construct. However, we suggest that you do not preclude > extensions to use a call in the VCAT layer. > > CCAMP response: As noted above, this is not precluded. We look forward to > future communication from you as you progress this work." > > Q14 later responded saying they were satisfied with the one call > construct: > https://datatracker.ietf.org/liaison/429/ > Greg > > Evelyne Roch wrote: >> Greg, >> >> Normally, I would expect the requirements section to be clear enough >> that it helps define a proper solution mechanism and clearly sets the >> scope, not the other way around (i.e. you need to read the mechanism >> to understand how the requirements should be interpreted). >> >> My main concern is how the "call concept" is being used with the >> member sharing scenario, as I mentioned earlier in this thread. The >> calls (in the draft) are really member calls, not VCAT group >> calls. But the call attributes contain VCAT group information. I >> don't want the member call to attribute carry call information for >> the entire VCAT group. >> >> Evelyne >> >> ------------------------------------------------------------------------ >> *From:* Greg Bernstein [mailto:gregb@grotto-networking.com] >> *Sent:* Wednesday, December 09, 2009 5:34 PM >> *To:* Roch, Evelyne (CAR:Q840) >> *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP >> *Subject:* Re: [CCAMP] Working group >> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 >> >> Hi Evelyne, the common pool is a set of potential member signals that >> have been set up using the mechanisms defined in the draft, >> particularly the VCAT call procedures. The draft allows these to be >> "shared" amongst different VCGs over time. Note that at any given >> point in time a member signal can belong to only one VCG. Note that >> by the nature of VCAT that these are signals that have the same >> source and destination. The procedures section makes this fairly clear. >> >> Greg >> >> >> >> Evelyne Roch wrote: >>> Greg, >>> >>> First, I think we need to further clarify the requirements as I'm >>> not sure all the readers will interpret the requirements the same >>> way. What exactly does it mean to be "in a common pool"? >>> >>> Evelyne >>> >>> ------------------------------------------------------------------------ >>> *From:* Greg Bernstein [mailto:gregb@grotto-networking.com] >>> *Sent:* Tuesday, December 08, 2009 1:04 PM >>> *To:* Roch, Evelyne (CAR:Q840) >>> *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP >>> *Subject:* Re: [CCAMP] Working group >>> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 >>> >>> Hi Evelyne, the main focus on this work was to support VCGs with >>> diversely routed routed members. We were asked to include the member >>> sharing scenario and formulated a method to accommodate it without >>> significantly increasing the complexity of the messages involved. >>> It seems to us that the solution included in this draft provides >>> sufficient functionality to meet the requirements in the document. >>> Is there a scenario you think is within the scope of the draft that >>> is not addressed? >>> >>> Greg >>> >>> Evelyne Roch wrote: >>>> Greg, see below. >>>> >>>> >>>>> -----Original Message----- >>>>> From: Greg Bernstein [mailto:gregb@grotto-networking.com] >>>>> Sent: Friday, December 04, 2009 4:09 PM >>>>> To: Roch, Evelyne (CAR:Q840) >>>>> Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP >>>>> Subject: Re: [CCAMP] Working group >>>>> >>>> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 >>>> >>>> >>>> >>>> >>>>> I'm not sure that we have calls of calls in GMPLS. At the time this >>>>> was written this wasn't deemed desirable. >>>>> >>>> >>>> The model of calls being supported by calls is clearly support by ASON, >>>> whether at the same layer (see G.8080 section 6.7) or different layer >>>> (section 6.6). I find it highly desirable. >>>> >>>> >>>> >>>> Evelyne >>>> >>>> >>>> >>> >>> -- >>> =================================================== >>> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >>> >>> >> >> -- >> =================================================== >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> >> > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------060009040006060806070601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Evelyne, version 04 published in February of 2008 contained a "Call_Data_Object", with a TLV containing exactly the information and utilizing the same procedures that we are now using with the CALL_ATTRIBUTES object.
It was recommended by the WG chairs to use the CALL_ATTRIBUTES object as defined in the MLN-Extensions work rather than defining another "Call_data_object". None of of the procedures were changed from 04.
Is there a problem with functionality? We worked very hard to find a technique utilizing existing mechanisms to give some support forthe member sharing scenario. We do not preclude other techniques being used in the future.

Greg

Evelyne Roch wrote:
This liaison was referring to version 04, before the introduction of CALL_ATTRIBUTES in the draft, exactly where the problem is.
 
In the laison 429, the ITU-T agrees to one call per VCG. That is the VCAT call (not addressed in the draft right now).
 
As far as member calls, members could be in same or different calls based on application (for diverse routing -> could be same call, for protection/restoration -> could be different calls). That is the member call used in the draft.
 
The problem is that CALL_ATTRIBUTES is carried in member call signaling when it pertains to the VCG, i.e. VCAT call.
 
Evelyne
 
 
 
 

From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Thursday, December 10, 2009 11:16 AM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, I'll add some text to the requirements section to clarify "common pool" per your request.
The "call concept" usage and "member sharing scenario" have been previously discussed, liaised, and resolved with ITU-T. 
https://datatracker.ietf.org/liaison/415/

It includes:
ITU: "Per Question 5:  We understand that this draft is only addressing
the
constituent server layer call; i.e., not the ASON multilayer call
supporting call construct. However, we suggest that you do not preclude
extensions to use a call in the VCAT layer.

CCAMP response: As noted above, this is not precluded. We look forward to
future communication from you as you progress this work."

Q14 later responded saying they were satisfied with the one call
construct:
https://datatracker.ietf.org/liaison/429/
Greg

Evelyne Roch wrote:
Greg,
 
Normally, I would expect the requirements section to be clear enough that it helps define a proper solution mechanism and clearly sets the scope, not the other way around (i.e. you need to read the mechanism to understand how the requirements should be interpreted).
 
My main concern is how the "call concept" is being used with the member sharing scenario, as I mentioned earlier in this thread. The calls (in the draft) are really member calls, not VCAT group calls. But the call attributes contain VCAT group information. I don't want the  member call to attribute carry call information for the entire VCAT group.
 
Evelyne

From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Wednesday, December 09, 2009 5:34 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, the common pool is a set of potential member signals that have been set up using the mechanisms defined in the draft, particularly the VCAT call procedures. The draft allows these to be "shared" amongst different VCGs over time. Note that at any given point in time a member signal can belong to only one VCG. Note that by the nature of VCAT that these are signals that have the same source and destination. The procedures section makes this fairly clear.

Greg



Evelyne Roch wrote:
Greg,
 
First, I think we need to further clarify the requirements as I'm not sure all the readers will interpret the requirements the same way. What exactly does it mean to be "in a common pool"?
 
Evelyne

From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Tuesday, December 08, 2009 1:04 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, the main focus on this work was to support VCGs with diversely routed routed members. We were asked to include the member sharing scenario and formulated a method to accommodate it without significantly increasing the complexity of the messages involved.  It seems to us that the solution included in this draft provides sufficient functionality to meet the requirements in the document. Is there a scenario you think is within the scope of the draft that is not addressed?

Greg

Evelyne Roch wrote: 
Greg, see below.

  
-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com] 
Sent: Friday, December 04, 2009 4:09 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
    
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

<snip>

  
I'm not sure that we have calls of calls in GMPLS. At the time this
was written this wasn't deemed desirable.
    

The model of calls being supported by calls is clearly support by ASON,
whether at the same layer (see G.8080 section 6.7) or different layer
(section 6.6). I find it highly desirable.

<snip>

Evelyne


  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------060009040006060806070601-- From EROCH@nortel.com Thu Dec 10 10:52:55 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8684B3A68F6 for ; Thu, 10 Dec 2009 10:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 ip1V25PEU9sj for ; Thu, 10 Dec 2009 10:52:54 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A8E893A68C8 for ; Thu, 10 Dec 2009 10:52:53 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nBAIqUG08390; Thu, 10 Dec 2009 18:52:30 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_01CA79C9.E90AC512" Date: Thu, 10 Dec 2009 13:52:22 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02C0FCF9@zcarhxm2.corp.nortel.com> In-Reply-To: <4B213E03.70508@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: Acp5xrhDqnWZO11iQG+Slvkyh9TKsAAApsfg References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com> <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> <4B197A79.1020301@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com> <4B1E9508.1010502@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com> <4B2025D3.3090208@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC96A4@zcarhxm2.corp.nortel.com> <4B211ED9.30908@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0F95F@zcarhxm2.corp.nortel.com> <4B213E03.70508@grotto-networking.com> From: "Evelyne Roch" To: "Greg Bernstein" Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 18:52:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA79C9.E90AC512 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg,=20 =20 There is a problem in the architecture because the CALL_ATTRIBUTES is carrying group info in the member call, creating a dependency on the members to achieve VCAT signaling. That dependency is problematic in a network with administrative boundaries. =20 Evelyne ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Thursday, December 10, 2009 1:29 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi Evelyne, version 04 published in February of 2008 contained a "Call_Data_Object", with a TLV containing exactly the information and utilizing the same procedures that we are now using with the CALL_ATTRIBUTES object.=20 It was recommended by the WG chairs to use the CALL_ATTRIBUTES object as defined in the MLN-Extensions work rather than defining another "Call_data_object". None of of the procedures were changed from 04.=20 Is there a problem with functionality? We worked very hard to find a technique utilizing existing mechanisms to give some support forthe member sharing scenario. We do not preclude other techniques being used in the future. Greg Evelyne Roch wrote:=20 This liaison was referring to version 04, before the introduction of CALL_ATTRIBUTES in the draft, exactly where the problem is. =20 In the laison 429, the ITU-T agrees to one call per VCG. That is the VCAT call (not addressed in the draft right now). =20 As far as member calls, members could be in same or different calls based on application (for diverse routing -> could be same call, for protection/restoration -> could be different calls). That is the member call used in the draft.=20 =20 The problem is that CALL_ATTRIBUTES is carried in member call signaling when it pertains to the VCG, i.e. VCAT call.=20 =20 Evelyne =20 =20 =20 =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Thursday, December 10, 2009 11:16 AM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 Hi Evelyne, I'll add some text to the requirements section to clarify "common pool" per your request. The "call concept" usage and "member sharing scenario" have been previously discussed, liaised, and resolved with ITU-T.=20 =09 https://datatracker.ietf.org/liaison/415/ =09 It includes: ITU: "Per Question 5: We understand that this draft is only addressing the constituent server layer call; i.e., not the ASON multilayer call supporting call construct. However, we suggest that you do not preclude extensions to use a call in the VCAT layer. =09 CCAMP response: As noted above, this is not precluded. We look forward to future communication from you as you progress this work." =09 Q14 later responded saying they were satisfied with the one call construct: https://datatracker.ietf.org/liaison/429/ Greg =09 Evelyne Roch wrote:=20 Greg, =20 Normally, I would expect the requirements section to be clear enough that it helps define a proper solution mechanism and clearly sets the scope, not the other way around (i.e. you need to read the mechanism to understand how the requirements should be interpreted). =20 My main concern is how the "call concept" is being used with the member sharing scenario, as I mentioned earlier in this thread. The calls (in the draft) are really member calls, not VCAT group calls. But the call attributes contain VCAT group information. I don't want the member call to attribute carry call information for the entire VCAT group. =20 Evelyne ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Wednesday, December 09, 2009 5:34 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 Hi Evelyne, the common pool is a set of potential member signals that have been set up using the mechanisms defined in the draft, particularly the VCAT call procedures. The draft allows these to be "shared" amongst different VCGs over time. Note that at any given point in time a member signal can belong to only one VCG. Note that by the nature of VCAT that these are signals that have the same source and destination. The procedures section makes this fairly clear. =09 Greg =09 =09 =09 Evelyne Roch wrote:=20 Greg, =20 First, I think we need to further clarify the requirements as I'm not sure all the readers will interpret the requirements the same way. What exactly does it mean to be "in a common pool"? =20 Evelyne ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Tuesday, December 08, 2009 1:04 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 Hi Evelyne, the main focus on this work was to support VCGs with diversely routed routed members. We were asked to include the member sharing scenario and formulated a method to accommodate it without significantly increasing the complexity of the messages involved. It seems to us that the solution included in this draft provides sufficient functionality to meet the requirements in the document. Is there a scenario you think is within the scope of the draft that is not addressed? =09 Greg =09 Evelyne Roch wrote:=20 Greg, see below. =09 =20 -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Friday, December 04, 2009 4:09 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group =20 =09 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 =20 I'm not sure that we have calls of calls in GMPLS. At the time this was written this wasn't deemed desirable. =20 =09 The model of calls being supported by calls is clearly support by ASON, whether at the same layer (see G.8080 section 6.7) or different layer (section 6.6). I find it highly desirable. =09 =09 Evelyne =09 =09 =20 --=20 =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =09 =20 --=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =09 =20 --=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =09 =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 ------_=_NextPart_001_01CA79C9.E90AC512 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Greg,
 
There is a problem in the architecture because = the=20 CALL_ATTRIBUTES is carrying group info in the member call, creating a = dependency=20 on the members to achieve VCAT signaling. That dependency is problematic = in a=20 network with administrative boundaries.
 
Evelyne

From: Greg Bernstein=20 [mailto:gregb@grotto-networking.com]
Sent: Thursday, December = 10,=20 2009 1:29 PM
To: Roch, Evelyne (CAR:Q840)
Cc: = BRUNGARD,=20 DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group=20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, version 04 published in February of 2008 = contained a=20 "Call_Data_Object", with a TLV containing exactly the information and = utilizing=20 the same procedures that we are now using with the CALL_ATTRIBUTES = object.=20
It was recommended by the WG chairs to use the CALL_ATTRIBUTES = object as=20 defined in the MLN-Extensions work rather than defining another=20 "Call_data_object". None of of the procedures were changed from 04. =
Is there=20 a problem with functionality? We worked very hard to find a technique = utilizing=20 existing mechanisms to give some support forthe member sharing scenario. = We do=20 not preclude other techniques being used in the=20 future.

Greg

Evelyne Roch wrote:=20
This liaison was referring to version 04, = before the=20 introduction of CALL_ATTRIBUTES in the draft, exactly where the = problem=20 is.
 
In the laison 429, the ITU-T agrees to one = call per VCG.=20 That is the VCAT call (not addressed in the draft right=20 now).
 
As far as member calls, members could be in = same or=20 different calls based on application (for diverse routing -> could = be same=20 call, for protection/restoration -> could be different calls). That = is the=20 member call used in the draft.
 
The problem is that CALL_ATTRIBUTES is = carried in member=20 call signaling when it pertains to the VCG, i.e. VCAT call.=20
 
Evelyne
 
 
 
 

From: Greg Bernstein [mailto:gregb@grotto-networkin= g.com]=20
Sent: Thursday, December 10, 2009 11:16 AM
To: = Roch,=20 Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20 CCAMP
Subject: Re: [CCAMP] Working group=20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi = Evelyne,=20 I'll add some text to the requirements section to clarify "common = pool" per=20 your request.
The "call concept" usage and "member sharing = scenario" have=20 been previously discussed, liaised, and resolved with ITU-T. 
https://datatracker.ietf.org/liaison/415/

It includes:
ITU: "Per Question 5:  We understand that this draft is only addressing
the
constituent server layer call; i.e., not the ASON multilayer call
supporting call construct. However, we suggest that you do not preclude
extensions to use a call in the VCAT layer.

CCAMP response: As noted above, this is not precluded. We look forward =
to
future communication from you as you progress this work."

Q14 later responded saying they were satisfied with the one call
construct:
https://datatracker.ietf.org/liaison/429/Greg

Evelyne=20
  Roch wrote:=20
  
    
    
Greg,

    
 

    
Normally, I would expect the requirements =
section to be=20
    clear enough that it helps define a proper solution mechanism and =
clearly=20
    sets the scope, not the other way around (i.e. you need to read the=20
    mechanism to understand how the requirements should be=20
    interpreted).

    
 

    
My main concern is how the "call =
concept" is being=20
    used with the member sharing scenario, as I mentioned earlier in =
this=20
    thread. The calls (in the draft) are really member calls, not VCAT =
group=20
    calls. But the call attributes contain VCAT group information. =
I don't=20
    want the  member call to attribute carry call information =
for the=20
    entire VCAT group.

    
 

    
Evelyne


    

    

    From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
    
Sent: Wednesday, December 09, 2009 5:34 PM
To: =
Roch,=20
    Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20
    CCAMP
Subject: Re: [CCAMP] Working group=20
    lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi =
Evelyne,=20
    the common pool is a set of potential member signals that have been =
set up=20
    using the mechanisms defined in the draft, particularly the VCAT =
call=20
    procedures. The draft allows these to be "shared" amongst different =
VCGs=20
    over time. Note that at any given point in time a member signal can =
belong=20
    to only one VCG. Note that by the nature of VCAT that these are =
signals that=20
    have the same source and destination. The procedures section makes =
this=20
    fairly clear.

Greg



Evelyne Roch wrote:=20
    
      
      
Greg,

      
 

      
First, I think we need to further clarify =
the=20
      requirements as I'm not sure all the readers will interpret=20
      the requirements the same way. What exactly does it mean =
to be=20
      "in a common pool"?

      
 

      
Evelyne


      

      

      From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
      
Sent: Tuesday, December 08, 2009 1:04 PM
To: =
Roch,=20
      Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20
      CCAMP
Subject: Re: [CCAMP] Working group=20
      =
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi=20
      Evelyne, the main focus on this work was to support VCGs with =
diversely=20
      routed routed members. We were asked to include the member sharing =

      scenario and formulated a method to accommodate it without =
significantly=20
      increasing the complexity of the messages involved.  It seems =
to us=20
      that the solution included in this draft provides sufficient =
functionality=20
      to meet the requirements in the document. Is there a scenario you =
think is=20
      within the scope of the draft that is not=20
      addressed?

Greg

Evelyne Roch wrote:=20
      
Greg, see below.

  

        
-----Original =
Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
Sent: Friday, December 04, 2009 4:09 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
    
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

<snip>

  

        
I'm not sure that we =
have calls of calls in GMPLS. At the time this
was written this wasn't deemed desirable.
    

The model of calls being supported by calls is clearly support by ASON,
whether at the same layer (see G.8080 section 6.7) or different layer
(section 6.6). I find it highly desirable.

<snip>

Evelyne


  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237




------_=_NextPart_001_01CA79C9.E90AC512--

From gregb@grotto-networking.com  Thu Dec 10 11:10:33 2009
Return-Path: 
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4143A69F0 for ; Thu, 10 Dec 2009 11:10:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level: 
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081,  BAYES_00=-2.599, HTML_MESSAGE=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 msrPEHPuHEau for ; Thu, 10 Dec 2009 11:10:27 -0800 (PST)
Received: from mail14c40.carrierzone.com (mail14c40.carrierzone.com [209.235.156.154]) by core3.amsl.com (Postfix) with ESMTP id 730353A68F6 for ; Thu, 10 Dec 2009 11:10:27 -0800 (PST)
X-Authenticated-User: gregb.grotto-networking.com
Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail14c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id nBAJAE1P007960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Dec 2009 19:10:18 GMT
Message-ID: <4B214791.3050600@grotto-networking.com>
Date: Thu, 10 Dec 2009 11:10:09 -0800
From: Greg Bernstein 
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Evelyne Roch 
References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com>		<90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com>	 <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> <4B197A79.1020301@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com> <4B1E9508.1010502@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com> <4B2025D3.3090208@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC96A4@zcarhxm2.corp.nortel.com> <4B211ED9.30908@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0F95F@zcarhxm2.corp.nortel.com> <4B213E03.70508@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0FCF9@zcarhxm2.corp.nortel.com>
In-Reply-To: <90243C8A881F8D419D855264D9636F3A02C0FCF9@zcarhxm2.corp.nortel.com>
Content-Type: multipart/alternative; boundary="------------010904040109020109030600"
Cc: CCAMP 
Subject: Re: [CCAMP] Working group	lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Dec 2009 19:10:33 -0000

This is a multi-part message in MIME format.
--------------010904040109020109030600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Evelyne, why is this dependency problematic? What are you trying to 
do and what it the context?

Greg

Evelyne Roch wrote:
> Greg,
>  
> There is a problem in the architecture because the CALL_ATTRIBUTES is 
> carrying group info in the member call, creating a dependency on the 
> members to achieve VCAT signaling. That dependency is problematic in a 
> network with administrative boundaries.
>  
> Evelyne
>
> ------------------------------------------------------------------------
> *From:* Greg Bernstein [mailto:gregb@grotto-networking.com]
> *Sent:* Thursday, December 10, 2009 1:29 PM
> *To:* Roch, Evelyne (CAR:Q840)
> *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP
> *Subject:* Re: [CCAMP] Working group 
> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>
> Hi Evelyne, version 04 published in February of 2008 contained a 
> "Call_Data_Object", with a TLV containing exactly the information and 
> utilizing the same procedures that we are now using with the 
> CALL_ATTRIBUTES object.
> It was recommended by the WG chairs to use the CALL_ATTRIBUTES object 
> as defined in the MLN-Extensions work rather than defining another 
> "Call_data_object". None of of the procedures were changed from 04.
> Is there a problem with functionality? We worked very hard to find a 
> technique utilizing existing mechanisms to give some support forthe 
> member sharing scenario. We do not preclude other techniques being 
> used in the future.
>
> Greg
>
> Evelyne Roch wrote:
>> This liaison was referring to version 04, before the introduction of 
>> CALL_ATTRIBUTES in the draft, exactly where the problem is.
>>  
>> In the laison 429, the ITU-T agrees to one call per VCG. That is the 
>> VCAT call (not addressed in the draft right now).
>>  
>> As far as member calls, members could be in same or different calls 
>> based on application (for diverse routing -> could be same call, for 
>> protection/restoration -> could be different calls). That is the 
>> member call used in the draft.
>>  
>> The problem is that CALL_ATTRIBUTES is carried in member call 
>> signaling when it pertains to the VCG, i.e. VCAT call.
>>  
>> Evelyne
>>  
>>  
>>  
>>  
>>
>> ------------------------------------------------------------------------
>> *From:* Greg Bernstein [mailto:gregb@grotto-networking.com]
>> *Sent:* Thursday, December 10, 2009 11:16 AM
>> *To:* Roch, Evelyne (CAR:Q840)
>> *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP
>> *Subject:* Re: [CCAMP] Working group 
>> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>>
>> Hi Evelyne, I'll add some text to the requirements section to clarify 
>> "common pool" per your request.
>> The "call concept" usage and "member sharing scenario" have been 
>> previously discussed, liaised, and resolved with ITU-T.
>> https://datatracker.ietf.org/liaison/415/
>>
>> It includes:
>> ITU: "Per Question 5:  We understand that this draft is only addressing
>> the
>> constituent server layer call; i.e., not the ASON multilayer call
>> supporting call construct. However, we suggest that you do not preclude
>> extensions to use a call in the VCAT layer.
>>
>> CCAMP response: As noted above, this is not precluded. We look forward to
>> future communication from you as you progress this work."
>>
>> Q14 later responded saying they were satisfied with the one call
>> construct:
>> https://datatracker.ietf.org/liaison/429/
>> Greg
>>
>> Evelyne Roch wrote:
>>> Greg,
>>>  
>>> Normally, I would expect the requirements section to be clear enough 
>>> that it helps define a proper solution mechanism and clearly sets 
>>> the scope, not the other way around (i.e. you need to read the 
>>> mechanism to understand how the requirements should be interpreted).
>>>  
>>> My main concern is how the "call concept" is being used with the 
>>> member sharing scenario, as I mentioned earlier in this thread. The 
>>> calls (in the draft) are really member calls, not VCAT group 
>>> calls. But the call attributes contain VCAT group information. I 
>>> don't want the  member call to attribute carry call information for 
>>> the entire VCAT group.
>>>  
>>> Evelyne
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Greg Bernstein [mailto:gregb@grotto-networking.com]
>>> *Sent:* Wednesday, December 09, 2009 5:34 PM
>>> *To:* Roch, Evelyne (CAR:Q840)
>>> *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP
>>> *Subject:* Re: [CCAMP] Working group 
>>> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>>>
>>> Hi Evelyne, the common pool is a set of potential member signals 
>>> that have been set up using the mechanisms defined in the draft, 
>>> particularly the VCAT call procedures. The draft allows these to be 
>>> "shared" amongst different VCGs over time. Note that at any given 
>>> point in time a member signal can belong to only one VCG. Note that 
>>> by the nature of VCAT that these are signals that have the same 
>>> source and destination. The procedures section makes this fairly clear.
>>>
>>> Greg
>>>
>>>
>>>
>>> Evelyne Roch wrote:
>>>> Greg,
>>>>  
>>>> First, I think we need to further clarify the requirements as I'm 
>>>> not sure all the readers will interpret the requirements the same 
>>>> way. What exactly does it mean to be "in a common pool"?
>>>>  
>>>> Evelyne
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* Greg Bernstein [mailto:gregb@grotto-networking.com]
>>>> *Sent:* Tuesday, December 08, 2009 1:04 PM
>>>> *To:* Roch, Evelyne (CAR:Q840)
>>>> *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP
>>>> *Subject:* Re: [CCAMP] Working group 
>>>> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>>>>
>>>> Hi Evelyne, the main focus on this work was to support VCGs with 
>>>> diversely routed routed members. We were asked to include the 
>>>> member sharing scenario and formulated a method to accommodate it 
>>>> without significantly increasing the complexity of the messages 
>>>> involved.  It seems to us that the solution included in this draft 
>>>> provides sufficient functionality to meet the requirements in the 
>>>> document. Is there a scenario you think is within the scope of the 
>>>> draft that is not addressed?
>>>>
>>>> Greg
>>>>
>>>> Evelyne Roch wrote:
>>>>> Greg, see below.
>>>>>
>>>>>   
>>>>>> -----Original Message-----
>>>>>> From: Greg Bernstein [mailto:gregb@grotto-networking.com] 
>>>>>> Sent: Friday, December 04, 2009 4:09 PM
>>>>>> To: Roch, Evelyne (CAR:Q840)
>>>>>> Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
>>>>>> Subject: Re: [CCAMP] Working group
>>>>>>     
>>>>> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>>>>>
>>>>> 
>>>>>
>>>>>   
>>>>>> I'm not sure that we have calls of calls in GMPLS. At the time this
>>>>>> was written this wasn't deemed desirable.
>>>>>>     
>>>>>
>>>>> The model of calls being supported by calls is clearly support by ASON,
>>>>> whether at the same layer (see G.8080 section 6.7) or different layer
>>>>> (section 6.6). I find it highly desirable.
>>>>>
>>>>> 
>>>>>
>>>>> Evelyne
>>>>>
>>>>>
>>>>>   
>>>>
>>>> -- 
>>>> ===================================================
>>>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>>>
>>>>   
>>>
>>> -- 
>>> ===================================================
>>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>>
>>>   
>>
>> -- 
>> ===================================================
>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>
>>   
>
> -- 
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>   

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237



--------------010904040109020109030600
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Hi Evelyne, why is this dependency problematic? What are you trying to
do and what it the context?



Greg



Evelyne Roch wrote:


  
  
  
  
Greg, 

  
 

  
There is a problem in the
architecture because the CALL_ATTRIBUTES is carrying group info in the
member call, creating a dependency on the members to achieve VCAT
signaling. That dependency is problematic in a network with
administrative boundaries.

  
 

  
Evelyne

  

  

  
From: Greg
Bernstein [mailto:gregb@grotto-networking.com] 

  Sent: Thursday, December 10, 2009 1:29 PM

  To: Roch, Evelyne (CAR:Q840)

  Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP

  Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

  

  

Hi Evelyne, version 04 published in February of 2008 contained a
"Call_Data_Object", with a TLV containing exactly the information and
utilizing the same procedures that we are now using with the
CALL_ATTRIBUTES object. 

It was recommended by the WG chairs to use the CALL_ATTRIBUTES object
as defined in the MLN-Extensions work rather than defining another
"Call_data_object". None of of the procedures were changed from 04. 

Is there a problem with functionality? We worked very hard to find a
technique utilizing existing mechanisms to give some support forthe
member sharing scenario. We do not preclude other techniques being used
in the future.

  

Greg

  

Evelyne Roch wrote:
  

    
    
This liaison was referring to
version 04, before the introduction of CALL_ATTRIBUTES in the draft,
exactly where the problem is.

    
 

    
In the laison 429, the ITU-T
agrees to one call per VCG. That is the VCAT call (not addressed in the
draft right now).

    
 

    
As far as member calls, members
could be in same or different calls based on application (for diverse
routing -> could be same call, for protection/restoration ->
could be different calls). That is the member call used in the draft. 

    
 

    
The problem is that
CALL_ATTRIBUTES is carried in member call signaling when it pertains to
the VCG, i.e. VCAT call. 

    
 

    
Evelyne

    
 

    
 

    
 

    
 

    

    

    
 From: Greg
Bernstein [mailto:gregb@grotto-networking.com]
    

    Sent: Thursday, December 10, 2009 11:16 AM

    To: Roch, Evelyne (CAR:Q840)

    Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP

    Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

    

    

Hi Evelyne, I'll add some text to the requirements section to clarify
"common pool" per your request.

The "call concept" usage and "member sharing scenario" have been
previously discussed, liaised, and resolved with ITU-T. 

    
https://datatracker.ietf.org/liaison/415/

It includes:
ITU: "Per Question 5:  We understand that this draft is only addressing
the
constituent server layer call; i.e., not the ASON multilayer call
supporting call construct. However, we suggest that you do not preclude
extensions to use a call in the VCAT layer.

CCAMP response: As noted above, this is not precluded. We look forward to
future communication from you as you progress this work."

Q14 later responded saying they were satisfied with the one call
construct:
https://datatracker.ietf.org/liaison/429/

Greg

    

Evelyne Roch wrote:
    

      
      
Greg,

      
 

      
Normally, I would expect the
requirements section to be clear enough that it helps define a proper
solution mechanism and clearly sets the scope, not the other way around
(i.e. you need to read the mechanism to understand how the requirements
should be interpreted).

      
 

      
My main concern is how the "call
concept" is being used with the member sharing scenario, as I mentioned
earlier in this thread. The calls (in the draft) are really member
calls, not VCAT group calls. But the call attributes contain VCAT group
information. I don't want the  member call to attribute carry call
information for the entire VCAT group.

      
 

      
Evelyne

      

      

      
 From:
Greg Bernstein [mailto:gregb@grotto-networking.com]
      

      Sent: Wednesday, December 09, 2009 5:34 PM

      To: Roch, Evelyne (CAR:Q840)

      Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP

      Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

      

      

Hi Evelyne, the common pool is a set of potential member signals that
have been set up using the mechanisms defined in the draft,
particularly the VCAT call procedures. The draft allows these to be
"shared" amongst different VCGs over time. Note that at any given point
in time a member signal can belong to only one VCG. Note that by the
nature of VCAT that these are signals that have the same source and
destination. The procedures section makes this fairly clear.

      

Greg

      

      

      

Evelyne Roch wrote:
      

        
        
Greg,

        
 

        
First, I think we need to
further clarify the requirements as I'm not sure all the readers will
interpret the requirements the same way. What exactly does it mean to
be "in a common pool"?

        
 

        
Evelyne

        

        

        
 From:
Greg Bernstein [mailto:gregb@grotto-networking.com]
        

        Sent: Tuesday, December 08, 2009 1:04 PM

        To: Roch, Evelyne (CAR:Q840)

        Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP

        Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

        

        

Hi Evelyne, the main focus on this work was to support VCGs with
diversely routed routed members. We were asked to include the member
sharing scenario and formulated a method to accommodate it without
significantly increasing the complexity of the messages involved.  It
seems to us that the solution included in this draft provides
sufficient functionality to meet the requirements in the document. Is
there a scenario you think is within the scope of the draft that is not
addressed?

        

Greg

        

Evelyne Roch wrote:
        

          
Greg, see below.

  

          

            
-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com] 
Sent: Friday, December 04, 2009 4:09 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
    

          

          
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

<snip>

  

          

            
I'm not sure that we have calls of calls in GMPLS. At the time this
was written this wasn't deemed desirable.
    

          

          

The model of calls being supported by calls is clearly support by ASON,
whether at the same layer (see G.8080 section 6.7) or different layer
(section 6.6). I find it highly desirable.

<snip>

Evelyne


  

        

        

        
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

      

      

      
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

    

    

    
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

  

  

  
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  






-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237






--------------010904040109020109030600--

From EROCH@nortel.com  Thu Dec 10 11:24:18 2009
Return-Path: 
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99EAE3A68F6 for ; Thu, 10 Dec 2009 11:24:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 0zkYPegvwGDQ for ; Thu, 10 Dec 2009 11:24:16 -0800 (PST)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8506E3A6958 for ; Thu, 10 Dec 2009 11:24:16 -0800 (PST)
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id nBAJNsG16635; Thu, 10 Dec 2009 19:23:54 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_01CA79CE.11F1B9C8"
Date: Thu, 10 Dec 2009 14:22:06 -0500
Message-ID: <90243C8A881F8D419D855264D9636F3A02C0FE01@zcarhxm2.corp.nortel.com>
In-Reply-To: <4B214791.3050600@grotto-networking.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [CCAMP] Working group	lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
Thread-Index: Acp5zG1NJLPkW2faTuW3ttuQEjyXZAAAHU9g
References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com>		<90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com>	 <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> <4B197A79.1020301@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com> <4B1E9508.1010502@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com> <4B2025D3.3090208@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC96A4@zcarhxm2.corp.nortel.com> <4B211ED9.30908@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0F95F@zcarhxm2.corp.nortel.com> <4B213E03.70508@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0FCF9@zcarhxm2.corp.nortel.com> <4B214791.3! 050600@gr otto-networking.com>
From: "Evelyne Roch" 
To: "Greg Bernstein" 
Cc: CCAMP 
Subject: Re: [CCAMP] Working group	lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Dec 2009 19:24:19 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA79CE.11F1B9C8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Greg,
=20
The dependency is problematic in networks that follow the ASON
architecture because of the administrative boundaries. I would like to
see implementations that are compliant with this draft and the ASON
architecture.=20
=20
Evelyne

________________________________

From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
Sent: Thursday, December 10, 2009 2:10 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08


Hi Evelyne, why is this dependency problematic? What are you trying to
do and what it the context?

Greg

Evelyne Roch wrote:=20

	Greg,=20
	=20
	There is a problem in the architecture because the
CALL_ATTRIBUTES is carrying group info in the member call, creating a
dependency on the members to achieve VCAT signaling. That dependency is
problematic in a network with administrative boundaries.
	=20
	Evelyne

________________________________

	From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
	Sent: Thursday, December 10, 2009 1:29 PM
	To: Roch, Evelyne (CAR:Q840)
	Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
	Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
=09
=09
	Hi Evelyne, version 04 published in February of 2008 contained a
"Call_Data_Object", with a TLV containing exactly the information and
utilizing the same procedures that we are now using with the
CALL_ATTRIBUTES object.=20
	It was recommended by the WG chairs to use the CALL_ATTRIBUTES
object as defined in the MLN-Extensions work rather than defining
another "Call_data_object". None of of the procedures were changed from
04.=20
	Is there a problem with functionality? We worked very hard to
find a technique utilizing existing mechanisms to give some support
forthe member sharing scenario. We do not preclude other techniques
being used in the future.
=09
	Greg
=09
	Evelyne Roch wrote:=20

		This liaison was referring to version 04, before the
introduction of CALL_ATTRIBUTES in the draft, exactly where the problem
is.
		=20
		In the laison 429, the ITU-T agrees to one call per VCG.
That is the VCAT call (not addressed in the draft right now).
		=20
		As far as member calls, members could be in same or
different calls based on application (for diverse routing -> could be
same call, for protection/restoration -> could be different calls). That
is the member call used in the draft.=20
		=20
		The problem is that CALL_ATTRIBUTES is carried in member
call signaling when it pertains to the VCG, i.e. VCAT call.=20
		=20
		Evelyne
		=20
		=20
		=20
		=20

________________________________

		From: Greg Bernstein
[mailto:gregb@grotto-networking.com]=20
		Sent: Thursday, December 10, 2009 11:16 AM
		To: Roch, Evelyne (CAR:Q840)
		Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
		Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
	=09
	=09
		Hi Evelyne, I'll add some text to the requirements
section to clarify "common pool" per your request.
		The "call concept" usage and "member sharing scenario"
have been previously discussed, liaised, and resolved with ITU-T.=20
	=09
		https://datatracker.ietf.org/liaison/415/
	=09
		It includes:
		ITU: "Per Question 5:  We understand that this draft is
only addressing
		the
		constituent server layer call; i.e., not the ASON
multilayer call
		supporting call construct. However, we suggest that you
do not preclude
		extensions to use a call in the VCAT layer.
	=09
		CCAMP response: As noted above, this is not precluded.
We look forward to
		future communication from you as you progress this
work."
	=09
		Q14 later responded saying they were satisfied with the
one call
		construct:
		https://datatracker.ietf.org/liaison/429/
		Greg
	=09
		Evelyne Roch wrote:=20

			Greg,
			=20
			Normally, I would expect the requirements
section to be clear enough that it helps define a proper solution
mechanism and clearly sets the scope, not the other way around (i.e. you
need to read the mechanism to understand how the requirements should be
interpreted).
			=20
			My main concern is how the "call concept" is
being used with the member sharing scenario, as I mentioned earlier in
this thread. The calls (in the draft) are really member calls, not VCAT
group calls. But the call attributes contain VCAT group information. I
don't want the  member call to attribute carry call information for the
entire VCAT group.
			=20
			Evelyne

________________________________

			From: Greg Bernstein
[mailto:gregb@grotto-networking.com]=20
			Sent: Wednesday, December 09, 2009 5:34 PM
			To: Roch, Evelyne (CAR:Q840)
			Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
			Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
		=09
		=09
			Hi Evelyne, the common pool is a set of
potential member signals that have been set up using the mechanisms
defined in the draft, particularly the VCAT call procedures. The draft
allows these to be "shared" amongst different VCGs over time. Note that
at any given point in time a member signal can belong to only one VCG.
Note that by the nature of VCAT that these are signals that have the
same source and destination. The procedures section makes this fairly
clear.
		=09
			Greg
		=09
		=09
		=09
			Evelyne Roch wrote:=20

				Greg,
				=20
				First, I think we need to further
clarify the requirements as I'm not sure all the readers will interpret
the requirements the same way. What exactly does it mean to be "in a
common pool"?
				=20
				Evelyne

________________________________

				From: Greg Bernstein
[mailto:gregb@grotto-networking.com]=20
				Sent: Tuesday, December 08, 2009 1:04 PM
				To: Roch, Evelyne (CAR:Q840)
				Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
				Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
			=09
			=09
				Hi Evelyne, the main focus on this work
was to support VCGs with diversely routed routed members. We were asked
to include the member sharing scenario and formulated a method to
accommodate it without significantly increasing the complexity of the
messages involved.  It seems to us that the solution included in this
draft provides sufficient functionality to meet the requirements in the
document. Is there a scenario you think is within the scope of the draft
that is not addressed?
			=09
				Greg
			=09
				Evelyne Roch wrote:=20

				Greg, see below.
			=09
				 =20

				-----Original Message-----
				From: Greg Bernstein
[mailto:gregb@grotto-networking.com]=20
				Sent: Friday, December 04, 2009 4:09 PM
				To: Roch, Evelyne (CAR:Q840)
				Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
				Subject: Re: [CCAMP] Working group
				   =20

=09
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
			=09
				
			=09
				 =20

				I'm not sure that we have calls of calls
in GMPLS. At the time this
				was written this wasn't deemed
desirable.
				   =20

			=09
				The model of calls being supported by
calls is clearly support by ASON,
				whether at the same layer (see G.8080
section 6.7) or different layer
				(section 6.6). I find it highly
desirable.
			=09
				
			=09
				Evelyne
			=09
			=09
				 =20


				--=20
=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
				Dr Greg Bernstein, Grotto Networking
(510) 573-2237
			=09
				 =20


			--=20
=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
			Dr Greg Bernstein, Grotto Networking (510)
573-2237
		=09
			 =20


		--=20
		=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
		Dr Greg Bernstein, Grotto Networking (510) 573-2237
	=09
		 =20


	--=20
	=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
	Dr Greg Bernstein, Grotto Networking (510) 573-2237
=09
	 =20


--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237


------_=_NextPart_001_01CA79CE.11F1B9C8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Greg,


 


The dependency is problematic in networks that =
follow the=20
ASON architecture because of the administrative boundaries. I would like =
to see=20
implementations that are compliant with this draft and the ASON =
architecture.=20



 


Evelyne






From: Greg Bernstein=20
[mailto:gregb@grotto-networking.com] 
Sent: Thursday, December =
10,=20
2009 2:10 PM
To: Roch, Evelyne (CAR:Q840)
Cc: =
BRUNGARD,=20
DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group=20
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08



Hi Evelyne, why is this dependency problematic? What are you =
trying=20
to do and what it the context?

Greg

Evelyne Roch wrote:=20

  
  
Greg, 

  
 

  
There is a problem in the architecture =
because the=20
  CALL_ATTRIBUTES is carrying group info in the member call, creating a=20
  dependency on the members to achieve VCAT signaling. That dependency =
is=20
  problematic in a network with administrative =
boundaries.

  
 

  
Evelyne


  

  

  From: Greg Bernstein [mailto:gregb@grotto-networkin=
g.com]=20
  
Sent: Thursday, December 10, 2009 1:29 PM
To: =
Roch,=20
  Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20
  CCAMP
Subject: Re: [CCAMP] Working group=20
  lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi =
Evelyne,=20
  version 04 published in February of 2008 contained a =
"Call_Data_Object", with=20
  a TLV containing exactly the information and utilizing the same =
procedures=20
  that we are now using with the CALL_ATTRIBUTES object. 
It was =
recommended=20
  by the WG chairs to use the CALL_ATTRIBUTES object as defined in the=20
  MLN-Extensions work rather than defining another "Call_data_object". =
None of=20
  of the procedures were changed from 04. 
Is there a problem with=20
  functionality? We worked very hard to find a technique utilizing =
existing=20
  mechanisms to give some support forthe member sharing scenario. We do =
not=20
  preclude other techniques being used in the =
future.

Greg

Evelyne=20
  Roch wrote:=20
  
    
    
This liaison was referring to version 04, =
before the=20
    introduction of CALL_ATTRIBUTES in the draft, exactly where the =
problem=20
    is.

    
 

    
In the laison 429, the ITU-T agrees to one =
call per=20
    VCG. That is the VCAT call (not addressed in the draft right=20
    now).

    
 

    
As far as member calls, members could be in =
same or=20
    different calls based on application (for diverse routing -> =
could be=20
    same call, for protection/restoration -> could be different =
calls). That=20
    is the member call used in the draft. 

    
 

    
The problem is that CALL_ATTRIBUTES is =
carried in=20
    member call signaling when it pertains to the VCG, i.e. VCAT call.=20
    

    
 

    
Evelyne

    
 

    
 

    
 

    
 


    

    

    From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
    
Sent: Thursday, December 10, 2009 11:16 AM
To: =
Roch,=20
    Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20
    CCAMP
Subject: Re: [CCAMP] Working group=20
    lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi =
Evelyne,=20
    I'll add some text to the requirements section to clarify "common =
pool" per=20
    your request.
The "call concept" usage and "member sharing =
scenario" have=20
    been previously discussed, liaised, and resolved with ITU-T. =

https://datatracker.ietf.org/liaison/415/

It includes:
ITU: "Per Question 5:  We understand that this draft is only addressing
the
constituent server layer call; i.e., not the ASON multilayer call
supporting call construct. However, we suggest that you do not preclude
extensions to use a call in the VCAT layer.

CCAMP response: As noted above, this is not precluded. We look forward =
to
future communication from you as you progress this work."

Q14 later responded saying they were satisfied with the one call
construct:
https://datatracker.ietf.org/liaison/429/Greg

Evelyne=20
    Roch wrote:=20
    
      
      
Greg,

      
 

      
Normally, I would expect the requirements =
section to=20
      be clear enough that it helps define a proper solution mechanism =
and=20
      clearly sets the scope, not the other way around (i.e. you need to =
read=20
      the mechanism to understand how the requirements should be=20
      interpreted).

      
 

      
My main concern is how the "call =
concept" is=20
      being used with the member sharing scenario, as I mentioned =
earlier in=20
      this thread. The calls (in the draft) are really member calls, not =
VCAT=20
      group calls. But the call attributes contain VCAT group =
information.=20
      I don't want the  member call to attribute carry call=20
      information for the entire VCAT group.

      
 

      
Evelyne


      

      

      From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
      
Sent: Wednesday, December 09, 2009 5:34 =
PM
To: Roch,=20
      Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20
      CCAMP
Subject: Re: [CCAMP] Working group=20
      =
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi=20
      Evelyne, the common pool is a set of potential member signals that =
have=20
      been set up using the mechanisms defined in the draft, =
particularly the=20
      VCAT call procedures. The draft allows these to be "shared" =
amongst=20
      different VCGs over time. Note that at any given point in time a =
member=20
      signal can belong to only one VCG. Note that by the nature of VCAT =
that=20
      these are signals that have the same source and destination. The=20
      procedures section makes this fairly=20
      clear.

Greg



Evelyne Roch wrote:=20
      
        
        
Greg,

        
 

        
First, I think we need to further =
clarify the=20
        requirements as I'm not sure all the readers will interpret=20
        the requirements the same way. What exactly does it =
mean to be=20
        "in a common pool"?

        
 

        
Evelyne


        

        

        From: Greg Bernstein [mailto:gregb@grotto-networking.com] =

        
Sent: Tuesday, December 08, 2009 1:04 =
PM
To: Roch,=20
        Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20
        CCAMP
Subject: Re: [CCAMP] Working group=20
        =
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi=20
        Evelyne, the main focus on this work was to support VCGs with =
diversely=20
        routed routed members. We were asked to include the member =
sharing=20
        scenario and formulated a method to accommodate it without =
significantly=20
        increasing the complexity of the messages involved.  It =
seems to us=20
        that the solution included in this draft provides sufficient=20
        functionality to meet the requirements in the document. Is there =
a=20
        scenario you think is within the scope of the draft that is not=20
        addressed?

Greg

Evelyne Roch wrote:=20
        
Greg, see below.

  

          
-----Original =
Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
Sent: Friday, December 04, 2009 4:09 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
    
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

<snip>

  

          
I'm not sure that we =
have calls of calls in GMPLS. At the time this
was written this wasn't deemed desirable.
    

The model of calls being supported by calls is clearly support by ASON,
whether at the same layer (see G.8080 section 6.7) or different layer
(section 6.6). I find it highly desirable.

<snip>

Evelyne


  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237




------_=_NextPart_001_01CA79CE.11F1B9C8--

From tnadeau@lucidvision.com  Thu Dec 10 12:28:13 2009
Return-Path: 
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86143A6A87 for ; Thu, 10 Dec 2009 12:28:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.957
X-Spam-Level: 
X-Spam-Status: No, score=-3.957 tagged_above=-999 required=5 tests=[AWL=0.641,  BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=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 lfmzNy-7yUwf for ; Thu, 10 Dec 2009 12:28:12 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 867B33A6A4F for ; Thu, 10 Dec 2009 12:28:12 -0800 (PST)
Received: from [192.168.1.120] (unknown [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 1E62F422D1E9 for ; Thu, 10 Dec 2009 15:28:01 -0500 (EST)
From: Thomas Nadeau 
Content-Type: multipart/alternative; boundary=Apple-Mail-14-849323276
Date: Thu, 10 Dec 2009 15:28:01 -0500
Message-Id: <63A69826-AED5-40FD-899B-FE7CC48BE7FD@lucidvision.com>
To: ccamp@ietf.org
Mime-Version: 1.0 (Apple Message framework v1077)
X-Mailer: Apple Mail (2.1077)
Subject: [CCAMP] ONTC-PRISM Newsletter: Call for Papers - Special Issue on Cloud Computing and Data Center Networks
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Dec 2009 20:28:13 -0000

--Apple-Mail-14-849323276
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

FYI:


ONTC-PRISM Newsletter: Call for Papers - Special Issue on Cloud Computing
and Data Center Networks

Scope: IT services have proliferated significantly through most
enterprises and even to end-users. This explosion of IT services has led
to the emergence, growth and consolidation of computationally intensive
data centers. Data centers are principle network wide entities that are
responsible for the successful provisioning and scaling of IT services
across disparate users over a heterogenous network. We seek to understand
the network-wide design, implementation, architecture and technology
aspects of data centers and of emerging applications such as cloud
computing. We seek original review articles on technologies,
architectures, implementation excercises associated with data centers
including cloud computing, distributed and virtual data centers and
applications using such infrastructures. Articles must be written as per
the format prescribed below.

Keywords: Cloud computing, data centers, Carrier Ethernet, MPLS-TP,
PBB-TE, Virtualization, Consolidation.

Format: up to 3 pages with single column format, Times new roman 10 point
font for the text and 8 point font for the figure captions.

Submission information: Please send manuscripts to
submissions@ontc-prism.org. All articles will be reviewed by the TAB
and/or external reviewers.

Timeline:
Submission Deadline: Dec 31, 2009
Notification: Feb 1, 2010
Issue date: Feb 15, 2010

TAB in-charge: Thomas Nadeau BT Group LLC.

About ONTC Prism (www.ontc-prism.org): Prism is a quarterly newsletter
aimed at the dissemination of relevant content pertaining to optical and
high-speed networks and related growth areas across industry and academia.
Prism seeks to promote the growth of optical networking activity by
creation of a unified knowledge base and aims to create a communication
bridge between industry and academia in terms of research frontiers and
complementary strategies for future growth.


--Apple-Mail-14-849323276
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

submissions@ontc-prism.org.=
 All articles will be reviewed by the TAB
and/or external =
reviewers.

Timeline:
Submission Deadline: Dec 31, =
2009
Notification: Feb 1, 2010
Issue date: Feb 15, 2010

TAB =
in-charge: Thomas Nadeau BT Group LLC.

About ONTC Prism (www.ontc-prism.org): Prism is a =
quarterly newsletter
aimed at the dissemination of relevant content =
pertaining to optical and
high-speed networks and related growth =
areas across industry and academia.
Prism seeks to promote the growth =
of optical networking activity by
creation of a unified knowledge =
base and aims to create a communication
bridge between industry and =
academia in terms of research frontiers and
complementary strategies =
for future growth.

=

--Apple-Mail-14-849323276--

From richard.rabbat@gmail.com  Thu Dec 10 20:18:23 2009
Return-Path: 
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9AF3A68AC for ; Thu, 10 Dec 2009 20:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level: 
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 DO7sFRYHK5j1 for ; Thu, 10 Dec 2009 20:18:21 -0800 (PST)
Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 49F963A68B9 for ; Thu, 10 Dec 2009 20:18:21 -0800 (PST)
Received: by iwn33 with SMTP id 33so198381iwn.29 for ; Thu, 10 Dec 2009 20:18:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=oqzUFodA/B0vQI/8TmcPczb3Tr9vpWweqyysQ5Qg8hE=; b=T3Oa3/JB4f7/dRmQkSsOn4RdxYI29z7s9qN5+mhAMKNzn/7COBHRTh7J6E+YQho658 NK/ROEFXv34ZON7+kJgaF/nUNYMfvpOq80R5sEn9+GGa6mJ7cgtMvHrbN8AGikc81Lof JVuRTrXf0OY8n64UvLDoCVgicJbOJSV7T6hy4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=AVfo6nX1U5lTTAIZMXjSeyU/qUF228Ffl+msEAplqUBMBWwSYQNzY1t9jiXsvaDKWF PN0CgSPw4vq8Asfm3uZJT0f6C0OuO1DrOtaQpoeLZTm8soEF6uI56qd2oz4zjamw8pVd kBceJBA124QKIuVhxBp+BTRlD4Qv8AYMMG/L4=
MIME-Version: 1.0
Sender: richard.rabbat@gmail.com
Received: by 10.231.125.100 with SMTP id x36mr685008ibr.52.1260505087166; Thu,  10 Dec 2009 20:18:07 -0800 (PST)
In-Reply-To: <90243C8A881F8D419D855264D9636F3A02C0FE01@zcarhxm2.corp.nortel.com>
References: <4B06FB22.8090301@labn.net> <90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com> <4B2025D3.3090208@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC96A4@zcarhxm2.corp.nortel.com> <4B211ED9.30908@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0F95F@zcarhxm2.corp.nortel.com> <4B213E03.70508@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0FCF9@zcarhxm2.corp.nortel.com> <4B214791.3050600@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0FE01@zcarhxm2.corp.nortel.com>
Date: Thu, 10 Dec 2009 20:18:07 -0800
X-Google-Sender-Auth: 5f5ffdbb2bcd1ffb
Message-ID: 
From: Richard Rabbat 
To: Evelyne Roch 
Content-Type: multipart/alternative; boundary=0016e646432cf54b7b047a6c3571
Cc: CCAMP 
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Dec 2009 04:18:23 -0000

--0016e646432cf54b7b047a6c3571
Content-Type: text/plain; charset=ISO-8859-1

Evelyne,
which specific rfc's are you concerned the draft is not compliant with?
Richard.

On Thu, Dec 10, 2009 at 11:22 AM, Evelyne Roch  wrote:

>  Greg,
>
> The dependency is problematic in networks that follow the ASON architecture
> because of the administrative boundaries. I would like to see
> implementations that are compliant with this draft and the ASON
> architecture.
>
> Evelyne
>
>  ------------------------------
> *From:* Greg Bernstein [mailto:gregb@grotto-networking.com]
> *Sent:* Thursday, December 10, 2009 2:10 PM
>
> *To:* Roch, Evelyne (CAR:Q840)
> *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP
> *Subject:* Re: [CCAMP] Working group
> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>
> Hi Evelyne, why is this dependency problematic? What are you trying to do
> and what it the context?
>
> Greg
>
> Evelyne Roch wrote:
>
> Greg,
>
> There is a problem in the architecture because the CALL_ATTRIBUTES is
> carrying group info in the member call, creating a dependency on the members
> to achieve VCAT signaling. That dependency is problematic in a network with
> administrative boundaries.
>
> Evelyne
>
>  ------------------------------
> *From:* Greg Bernstein [mailto:gregb@grotto-networking.com]
>
> *Sent:* Thursday, December 10, 2009 1:29 PM
> *To:* Roch, Evelyne (CAR:Q840)
> *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP
> *Subject:* Re: [CCAMP] Working group
> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>
> Hi Evelyne, version 04 published in February of 2008 contained a
> "Call_Data_Object", with a TLV containing exactly the information and
> utilizing the same procedures that we are now using with the CALL_ATTRIBUTES
> object.
> It was recommended by the WG chairs to use the CALL_ATTRIBUTES object as
> defined in the MLN-Extensions work rather than defining another
> "Call_data_object". None of of the procedures were changed from 04.
> Is there a problem with functionality? We worked very hard to find a
> technique utilizing existing mechanisms to give some support forthe member
> sharing scenario. We do not preclude other techniques being used in the
> future.
>
> Greg
>
> Evelyne Roch wrote:
>
> This liaison was referring to version 04, before the introduction of
> CALL_ATTRIBUTES in the draft, exactly where the problem is.
>
> In the laison 429, the ITU-T agrees to one call per VCG. That is the VCAT
> call (not addressed in the draft right now).
>
> As far as member calls, members could be in same or different calls based
> on application (for diverse routing -> could be same call, for
> protection/restoration -> could be different calls). That is the member call
> used in the draft.
>
> The problem is that CALL_ATTRIBUTES is carried in member call signaling
> when it pertains to the VCG, i.e. VCAT call.
>
> Evelyne
>
>
>
>
>
>  ------------------------------
> *From:* Greg Bernstein [mailto:gregb@grotto-networking.com]
>
> *Sent:* Thursday, December 10, 2009 11:16 AM
> *To:* Roch, Evelyne (CAR:Q840)
> *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP
> *Subject:* Re: [CCAMP] Working group
> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>
> Hi Evelyne, I'll add some text to the requirements section to clarify
> "common pool" per your request.
> The "call concept" usage and "member sharing scenario" have been previously
> discussed, liaised, and resolved with ITU-T.
>
> https://datatracker.ietf.org/liaison/415/
>
> It includes:
> ITU: "Per Question 5:  We understand that this draft is only addressing
> the
> constituent server layer call; i.e., not the ASON multilayer call
> supporting call construct. However, we suggest that you do not preclude
> extensions to use a call in the VCAT layer.
>
> CCAMP response: As noted above, this is not precluded. We look forward to
> future communication from you as you progress this work."
>
> Q14 later responded saying they were satisfied with the one call
> construct:https://datatracker.ietf.org/liaison/429/
>
> Greg
>
> Evelyne Roch wrote:
>
> Greg,
>
> Normally, I would expect the requirements section to be clear enough that
> it helps define a proper solution mechanism and clearly sets the scope, not
> the other way around (i.e. you need to read the mechanism to understand how
> the requirements should be interpreted).
>
> My main concern is how the "call concept" is being used with the member
> sharing scenario, as I mentioned earlier in this thread. The calls (in the
> draft) are really member calls, not VCAT group calls. But the call
> attributes contain VCAT group information. I don't want the  member call to
> attribute carry call information for the entire VCAT group.
>
> Evelyne
>
>  ------------------------------
> *From:* Greg Bernstein [mailto:gregb@grotto-networking.com]
>
> *Sent:* Wednesday, December 09, 2009 5:34 PM
> *To:* Roch, Evelyne (CAR:Q840)
> *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP
> *Subject:* Re: [CCAMP] Working group
> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>
> Hi Evelyne, the common pool is a set of potential member signals that have
> been set up using the mechanisms defined in the draft, particularly the VCAT
> call procedures. The draft allows these to be "shared" amongst different
> VCGs over time. Note that at any given point in time a member signal can
> belong to only one VCG. Note that by the nature of VCAT that these are
> signals that have the same source and destination. The procedures section
> makes this fairly clear.
>
> Greg
>
>
>
> Evelyne Roch wrote:
>
> Greg,
>
> First, I think we need to further clarify the requirements as I'm not sure
> all the readers will interpret the requirements the same way. What exactly
> does it mean to be "in a common pool"?
>
> Evelyne
>
>  ------------------------------
> *From:* Greg Bernstein [mailto:gregb@grotto-networking.com]
>
> *Sent:* Tuesday, December 08, 2009 1:04 PM
> *To:* Roch, Evelyne (CAR:Q840)
> *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP
> *Subject:* Re: [CCAMP] Working group
> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>
> Hi Evelyne, the main focus on this work was to support VCGs with diversely
> routed routed members. We were asked to include the member sharing scenario
> and formulated a method to accommodate it without significantly increasing
> the complexity of the messages involved.  It seems to us that the solution
> included in this draft provides sufficient functionality to meet the
> requirements in the document. Is there a scenario you think is within the
> scope of the draft that is not addressed?
>
> Greg
>
> Evelyne Roch wrote:
>
> Greg, see below.
>
>
>
> -----Original Message-----
> From: Greg Bernstein [mailto:gregb@grotto-networking.com ]
> Sent: Friday, December 04, 2009 4:09 PM
> To: Roch, Evelyne (CAR:Q840)
> Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
> Subject: Re: [CCAMP] Working group
>
>
> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>
> 
>
>
>
> I'm not sure that we have calls of calls in GMPLS. At the time this
> was written this wasn't deemed desirable.
>
>
> The model of calls being supported by calls is clearly support by ASON,
> whether at the same layer (see G.8080 section 6.7) or different layer
> (section 6.6). I find it highly desirable.
>
> 
>
> Evelyne
>
>
>
>
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>
>

--0016e646432cf54b7b047a6c3571
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Evelyne,
which specific rfc's are you concerned the draft is not com=
pliant with?
Richard.

On Thu, Dec 10, =
2009 at 11:22 AM, Evelyne Roch <eroch@nortel.com> wrote:









Greg,


=A0


The dependency is problematic in networks that follow the=20
ASON architecture because of the administrative boundaries. I would like to=
 see=20
implementations that are compliant with this draft and the ASON architectur=
e.=20



=A0


Evelyne







From: Greg Bernst=
ein=20
[mailto:gr=
egb@grotto-networking.com] 
Sent: Thursday, December 10=
,=20
2009 2:10 PM

To: Roch, Evelyne =
(CAR:Q840)
Cc: BRUNGARD,=20
DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group=20
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08



Hi Evelyne, why is this dependency problematic? What are you try=
ing=20
to do and what it the context?

Greg

Evelyne Roch wrote:=20


 =20
  
Greg, 

  
=A0

  
There is a problem in the architecture because the=20
  CALL_ATTRIBUTES is carrying group info in the member call, creating a=20
  dependency on the members to achieve VCAT signaling. That dependency is=
=20
  problematic in a network with administrative boundaries.
  
=A0

  
Evelyne


  

  

  From: Greg Bernstein [mailto:gregb@grotto-n=
etworking.com]=20
  
Sent: Thursday, December 10, 2009 1:29 PM
To: Roch,=
=20
  Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20
  CCAMP
Subject: Re: [CCAMP] Working group=20
  lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evely=
ne,=20
  version 04 published in February of 2008 contained a "Call_Data_Obje=
ct", with=20
  a TLV containing exactly the information and utilizing the same procedure=
s=20
  that we are now using with the CALL_ATTRIBUTES object. 
It was recomme=
nded=20
  by the WG chairs to use the CALL_ATTRIBUTES object as defined in the=20
  MLN-Extensions work rather than defining another "Call_data_object&q=
uot;. None of=20
  of the procedures were changed from 04. 
Is there a problem with=20
  functionality? We worked very hard to find a technique utilizing existing=
=20
  mechanisms to give some support forthe member sharing scenario. We do not=
=20
  preclude other techniques being used in the future.

Greg

Ev=
elyne=20
  Roch wrote:=20
  

   =20
    
This liaison was referring to version 04, before the=20
    introduction of CALL_ATTRIBUTES in the draft, exactly where the problem=
=20
    is.

    
=A0

    
In the laison 429, the ITU-T agrees to one call per=20
    VCG. That is the VCAT call (not addressed in the draft right=20
    now).

    
=A0

    
As far as member calls, members could be in same or=20
    different calls based on application (for diverse routing -> could b=
e=20
    same call, for protection/restoration -> could be different calls). =
That=20
    is the member call used in the draft. 

    
=A0

    
The problem is that CALL_ATTRIBUTES is carried in=20
    member call signaling when it pertains to the VCG, i.e. VCAT call.=20
    

    
=A0

    
Evelyne

    
=A0

    
=A0

    
=A0

    
=A0


    

    

    From: Greg Bernstein [mailto:gregb@grot=
to-networking.com]=20
    
Sent: Thursday, December 10, 2009 11:16 AM
To: Roc=
h,=20
    Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20
    CCAMP
Subject: Re: [CCAMP] Working group=20
    lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Eve=
lyne,=20
    I'll add some text to the requirements section to clarify "com=
mon pool" per=20
    your request.
The "call concept" usage and "member sh=
aring scenario" have=20
    been previously discussed, liaised, and resolved with ITU-T. 
<=
a href=3D"https://datatracker.ietf.org/liaison/415/" target=3D"_blank">http=
s://datatracker.ietf.org/liaison/415/

It includes:
ITU: "Per Question 5:  We understand that this draft is only addressin=
g
the
constituent server layer call; i.e., not the ASON multilayer call
supporting call construct. However, we suggest that you do not preclude
extensions to use a call in the VCAT layer.

CCAMP response: As noted above, this is not precluded. We look forward to
future communication from you as you progress this work."

Q14 later responded saying they were satisfied with the one call
construct:
htt=
ps://datatracker.ietf.org/liaison/429/
Greg

Evelyne=20
    Roch wrote:=20
    

     =20
      
Greg,

      
=A0

      
Normally, I would expect the requirements section to=20
      be clear enough that it helps define a proper solution mechanism and=
=20
      clearly sets the scope, not the other way around (i.e. you need to re=
ad=20
      the mechanism to understand how the requirements should be=20
      interpreted).

      
=A0

      
My main concern is how the "call concept"=A0is=
=20
      being used with the member sharing scenario, as I mentioned earlier i=
n=20
      this thread. The calls (in the draft) are really member calls, not VC=
AT=20
      group calls.=A0But the call attributes contain VCAT group information=
.=20
      I don't want the=A0=A0member call to attribute carry call=20
      information for the entire VCAT group.

      
=A0

      
Evelyne


      

      

      From: Greg Bernstein [mailto:gregb@grot=
to-networking.com]=20
      
Sent: Wednesday, December 09, 2009 5:34 PM
To: R=
och,=20
      Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20
      CCAMP
Subject: Re: [CCAMP] Working group=20
      lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi=
=20
      Evelyne, the common pool is a set of potential member signals that ha=
ve=20
      been set up using the mechanisms defined in the draft, particularly t=
he=20
      VCAT call procedures. The draft allows these to be "shared"=
 amongst=20
      different VCGs over time. Note that at any given point in time a memb=
er=20
      signal can belong to only one VCG. Note that by the nature of VCAT th=
at=20
      these are signals that have the same source and destination. The=20
      procedures section makes this fairly=20
      clear.

Greg



Evelyne Roch wrote:=20
      

       =20
        
Greg,

        
=A0

        
First, I think we need to further clarify the=20
        requirements as I'm not sure all the readers will interpret=20
        the=A0requirements the same way. What=A0exactly does it mean to be=
=20
        "in a common pool"?

        
=A0

        
Evelyne


        

        

        From: Greg Bernstein [mailto:gregb@gr=
otto-networking.com]=20
        
Sent: Tuesday, December 08, 2009 1:04 PM
To: R=
och,=20
        Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20
        CCAMP
Subject: Re: [CCAMP] Working group=20
        lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi=
=20
        Evelyne, the main focus on this work was to support VCGs with diver=
sely=20
        routed routed members. We were asked to include the member sharing=
=20
        scenario and formulated a method to accommodate it without signific=
antly=20
        increasing the complexity of the messages involved.=A0 It seems to =
us=20
        that the solution included in this draft provides sufficient=20
        functionality to meet the requirements in the document. Is there a=
=20
        scenario you think is within the scope of the draft that is not=20
        addressed?

Greg

Evelyne Roch wrote:=20
        
Greg, see below.

  

          
-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
Sent: Friday, December 04, 2009 4:09 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
    
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

<snip>

  

          
I'm not sure that we have call=
s of calls in GMPLS. At the time this
was written this wasn't deemed desirable.
    
The model of calls being supported by calls is =
clearly support by ASON,
whether at the same layer (see G.8080 section 6.7) or different layer
(section 6.6). I find it highly desirable.

<snip>

Evelyne


  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237




_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/ccamp





--0016e646432cf54b7b047a6c3571--

From jcucchiara@mindspring.com  Fri Dec 11 07:22:16 2009
Return-Path: 
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C20B3A6AEE; Fri, 11 Dec 2009 07:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 B9PO2Jnjge6u; Fri, 11 Dec 2009 07:22:15 -0800 (PST)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id B8D593A69D1; Fri, 11 Dec 2009 07:22:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=l/2fOnV8pSqgglfWu33aG6C5gEPcKtCvYgPKUNNOl0vLK4Emc95xOOWgpatiB3Yd; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [108.1.135.222] (helo=JoanPC) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NJ7Jh-0002II-Qi; Fri, 11 Dec 2009 10:22:02 -0500
Message-ID: <00aa01ca7a75$66036020$6601a8c0@JoanPC>
From: "Joan Cucchiara" 
To: "Lou Berger" , "CCAMP" , "MIB Doctors \(E-mail\)" , "Thomas D. Nadeau" , "Masanori Miyazawa" , "Tomohiro Otani" , 
References: <49F8E7CA.6010902@labn.net> <00c601c9ca3e$347d4da0$6501a8c0@JoanPC> <49FAD79A.2090805@labn.net> <015c01c9d22e$13963730$6501a8c0@JoanPC> <4A40C6DD.2000002@labn.net>  <00a401c9f4ce$aa644c70$6501a8c0@JoanPC> <4AEAF58A.5020000@labn.net> <002c01ca596c$ed6798d0$6401a8c0@JoanPC> <4AFA2836.9030102@labn.net> <4B1D61C9.5080204@labn.net>  <00a201ca7814$a1c9b3b0$6601a8c0@JoanPC> <4B1E66F2.1050606@labn.net>
Date: Fri, 11 Dec 2009 10:19:56 -0500
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.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26540bec4ab79ec2c1701bcef5b633ffd38ea2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 108.1.135.222
Cc: "Romascanu, Dan \(Dan\)" , Adrian Farrel , "Brungard, Deborah A, ALABS" 
Subject: [CCAMP] MIB Dr. review of draft-ietf-gmpls-ted-mib-06.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Dec 2009 15:22:16 -0000

Folks,

Please excuse the lateness of the review.  I apologize.

Please lets discuss the comments numbered below and reach convergence
prior to another respin of the MIB.

Thanks,
   -Joan

PS. A comment with a NIT does not need discussion per se, it is more
a minor editorial issue and would be nice if it were fixed, but it is not
necessary to fix for MIB review purposes.



OUTPUT from SMICngPRO
---------------------
W: f(TED-MIB.my), (777,10) Variable "tedAreaId" in notification 
"tedStatusChange" is an index for a table
W: f(TED-MIB.my), (777,21) Variable "tedRouterId" in notification 
"tedStatusChange" is an index for a table
W: f(TED-MIB.my), (777,34) Variable "tedLinkStateId" in notification 
"tedStatusChange" is an index for a table
W: f(TED-MIB.my), (791,10) Variable "tedAreaId" in notification 
"tedCreation" is an index for a table
W: f(TED-MIB.my), (791,21) Variable "tedRouterId" in notification 
"tedCreation" is an index for a table
W: f(TED-MIB.my), (791,34) Variable "tedLinkStateId" in notification 
"tedCreation" is an index for a table
W: f(TED-MIB.my), (803,10) Variable "tedAreaId" in notification 
"tedDeletion" is an index for a table
W: f(TED-MIB.my), (803,21) Variable "tedRouterId" in notification 
"tedDeletion" is an index for a table
W: f(TED-MIB.my), (803,34) Variable "tedLinkStateId" in notification 
"tedDeletion" is an index for a table



OUTPUT from SmiLint
--------------------
File: TED-MIB.my
Severity level requested: 6

Line  Severity  Problem

105 5 warning: index element `tedAreaId' of row `tedEntry' should be
                not-accessible in SMIv2 MIB
        5 warning: index element `tedRouterId' of row `tedEntry' should be
                not-accessible in SMIv2 MIB
        5 warning: index element `tedLinkStateId' of row `tedEntry' should 
be
                not-accessible in SMIv2 MIB


Comments on the Text of the Document
-------------------------------------
Once comments on the MIB module are converged then I'll do a more
thorough review of this text.

* Renaming of "te" to "ted" has not propogated completely thorough the
text.


* Security Considerations

I disagree with the first paragraph.  First, there are no read-create
objects.  Second, the MIB module may be implemented correctly, but
there could be a risk if objects were set.






Comments on MIB Module
----------------------

1) The warnings above were previously noted in the v5 MIB
review. These warnings should be fixed in my opinion.
Please discuss.

2)(NIT) Cannot extract MIB using mstrip

3) LAST-UPDATED and REVISION dates are incorrect.

4) Comment
-- assigned by IANA, see section 8.1 for details
but the section is 9.1, please say, see "IANA Considerations for TED-MIB" 
section

5) There is not one REFERENCE clause in this MIB.  As I requested in
the version 5 MIB review, given the nature of this MIB where it draws from
documents in several different WGs, I believe REFERENCE clauses should be 
given.
As an agent developer, trying to implement these objects without a pointer
to an RFC would be difficult and potentially error-prone.

Granted there are references to entire RFCs within the DESCRIPTION clauses
but the REFERENCE Clause should be more specific with a section and
sub-section.


6) Although this MIB did go through a LC in the CCAMP, there are
other WGs where this MIB should probably also have a LC.
Please discuss.



7) OID layout, while there were some improvements here, the oid layout as
suggested by Appendix D of RFC4181 (Guidelines for MIB Documents)
was not completely followed.  Was this an oversight or is there a
reason that it was not followed?

Suggested OID Layout

         xxxMIB
         |
         +-- xxxNotifications(0)
         +-- xxxObjects(1)
         +-- xxxConformance(2)
             |
             +-- xxxCompliances(1)
             +-- xxxGroups(2)


This MIB:

- tedMIB
 \-v-0 tedNotifications

   |-1 tedObjects

   \-2 tedConformance
     \-v-1 tedGroups
       \-2 tedCompliances


Compliances and Groups do not follow the "Guidelines for MIB Documents"


8) The overall structure of the tables is a concern. Several indexes are
Unsigned32(0..4294967295) but there is no need to have such a large index
as far as I can tell.  Further, the use of 0 does not appear to be 
warrented.
(Please see rfc4181, section 4.6.1 and discuss why these indexes need to
be Unsigned32(0..4294967295).


The SwCapTable claims to give additional information about local or
remote TE links but the indexing makes that untennable as far as I can tell.
How does one know if they are looking at a local or remote link?

The tedSwCapIndex has nothing to do with RFC4801 as far as I can tell, so
don't understand what the index (tedSwCapIndex) is really supposed to be.


Additionally, the tedAreaId DESCRIPTION mentions using 0, but the range does 
not
include 0.   Again, a REFERENCE clause to each of the 3 or 4 documents
that this one object draws from (depending on the protocol),
would really be helpful.

Wrt tedLocalIfAdrEntry indexes, why does the tedLocalIfAddrIndex
need to be Unsigned32(0..4294967295), similarly why is the
tedRemoteIfAddrEntry tedRemoteIfAddrIndex Unsigned32(0..4294967295) ?



9) There was some emails back and forth on the MIB v5 review about
adding objects to give the state of the data in this MIB.
That was not done.
To recap an entry is created by local configuration,
then routing (or the specific link?) is supposed to be triggered,
then what is the state of the data in this MIB?

The MIB is NOT viable unless the state of the data can be understood
by an operator.

Please see the Aug 28th email discussion on version 5 MIB.


10) tedNotificationEnabled

Why is this object needed?  Please answer the question wrt rfc3413.


11) tedNotificationMaxRate

This one throttling mechanism is used to control 3 different notifications.
I would think that the status change notification would be sent so much more
often than a create/delete notification, so why is only one value used for
3 notifications?

Additionally, I would expect that the create and delete notifications should
probably be at a higher priority.  In other words, could you discuss why
the one throttle object?



12) tedLinkInformationSource and tedLinkInformationData

Which version of OSPF is being supported?  Looks to be ospfv2.

There may be a desire in the future to also support ospfv3, so
would be best to specify.  Also, this MIB says that it supports
ipv6 and that would be ospfv3.

13) Please change the name of "tedSwCap" to "tedSwitchCapacity".


14) Conformance statements are missing the restrictions for
IpAddress and IpAddressType objects in this MIB.
Please correct this.

Additionally, some of the DESCRIPTION clauses makes it seem that
some objects are optional, but this is not reflected in the Conformance
statements.  Please discuss wrt the following objects:



15) FullCompliance and ReadOnlyCompliance do not contain all of the
groups.  Neither compliance includes the Notifications group.

16) The DESCRIPTION of the Notifications Group states:
   "This group is mandatory for those implementations that can implement
   the notifications contained in this group."

So, why would these not be implementable?  I'm not sure this sort of
DESCRIPTION belongs in a standard's document.  If the intention is to
make these Notifications optional and this is okay with the wg, fine,
but this DESCRIPTION needs to be improved.

---


From lberger@labn.net  Fri Dec 11 07:33:59 2009
Return-Path: 
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1F93A679C for ; Fri, 11 Dec 2009 07:33:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level: 
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 FK35juRsiGX0 for ; Fri, 11 Dec 2009 07:33:58 -0800 (PST)
Received: from outbound-mail-304.bluehost.com (outbound-mail-304.bluehost.com [67.222.53.250]) by core3.amsl.com (Postfix) with SMTP id 38A9E3A67A3 for ; Fri, 11 Dec 2009 07:33:58 -0800 (PST)
Received: (qmail 3802 invoked by uid 0); 11 Dec 2009 15:33:46 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy6.bluehost.com with SMTP; 11 Dec 2009 15:33:46 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=m40cAfTV9A4vqV5QHlmLqtJsamXk3aN8OCV2G1Isf9u1dah3x57102zl45ClEh5WEK107NHyBx0Yb/NQbK0ToeLsdilIns2BBcy+qvfDbbdVgQWJAtwsdIeT6K6zils5;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NJ7V4-0007fU-Fw; Fri, 11 Dec 2009 08:33:46 -0700
Message-ID: <4B22666B.1070106@labn.net>
Date: Fri, 11 Dec 2009 10:34:03 -0500
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3
MIME-Version: 1.0
To: Joan Cucchiara 
References: <49F8E7CA.6010902@labn.net> <00c601c9ca3e$347d4da0$6501a8c0@JoanPC> <49FAD79A.2090805@labn.net> <015c01c9d22e$13963730$6501a8c0@JoanPC> <4A40C6DD.2000002@labn.net>  <00a401c9f4ce$aa644c70$6501a8c0@JoanPC> <4AEAF58A.5020000@labn.net> <002c01ca596c$ed6798d0$6401a8c0@JoanPC> <4AFA2836.9030102@labn.net> <4B1D61C9.5080204@labn.net>  <00a201ca7814$a1c9b3b0$6601a8c0@JoanPC> <4B1E66F2.1050606@labn.net> <00aa01ca7a75$66036020$6601a8c0@JoanPC>
In-Reply-To: <00aa01ca7a75$66036020$6601a8c0@JoanPC>
X-Enigmail-Version: 0.96a
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "MIB Doctors \(E-mail\)" , CCAMP , "Romascanu, Dan \(Dan\)" , Adrian Farrel , ke-kumaki@kddilabs.jp, "Brungard, Deborah A, ALABS" 
Subject: Re: [CCAMP] MIB Dr. review of draft-ietf-gmpls-ted-mib-06.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Dec 2009 15:33:59 -0000

Joan,
	Thank you very much for your (usual) thorough review.  You mention that 
you'd like to see the document last called in additional WGs.  Our 
current plan is to issue a new LC once your review is complete and to 
notify both the OSPF and ISIS WGs of this LC (but not a joint LC).  Do 
you think there are any other WGs that should be notified/included?

Also, I regret that you had to repeat comments made on the previous 
version.

Authors,

Please reach closure/agreement with Joan on her comments before 
publishing the next version.  This includes addressing issues raised, 
but not addressed, in the prior version. (The WG mail list is a fine 
place for the discussion.)

Lou

On 12/11/2009 10:19 AM, Joan Cucchiara wrote:
> Folks,
>
> Please excuse the lateness of the review.  I apologize.
>
> Please lets discuss the comments numbered below and reach convergence
> prior to another respin of the MIB.
>
> Thanks,
>     -Joan
>
> PS. A comment with a NIT does not need discussion per se, it is more
> a minor editorial issue and would be nice if it were fixed, but it is not
> necessary to fix for MIB review purposes.
>
>
>
> OUTPUT from SMICngPRO
> ---------------------
> W: f(TED-MIB.my), (777,10) Variable "tedAreaId" in notification
> "tedStatusChange" is an index for a table
> W: f(TED-MIB.my), (777,21) Variable "tedRouterId" in notification
> "tedStatusChange" is an index for a table
> W: f(TED-MIB.my), (777,34) Variable "tedLinkStateId" in notification
> "tedStatusChange" is an index for a table
> W: f(TED-MIB.my), (791,10) Variable "tedAreaId" in notification
> "tedCreation" is an index for a table
> W: f(TED-MIB.my), (791,21) Variable "tedRouterId" in notification
> "tedCreation" is an index for a table
> W: f(TED-MIB.my), (791,34) Variable "tedLinkStateId" in notification
> "tedCreation" is an index for a table
> W: f(TED-MIB.my), (803,10) Variable "tedAreaId" in notification
> "tedDeletion" is an index for a table
> W: f(TED-MIB.my), (803,21) Variable "tedRouterId" in notification
> "tedDeletion" is an index for a table
> W: f(TED-MIB.my), (803,34) Variable "tedLinkStateId" in notification
> "tedDeletion" is an index for a table
>
>
>
> OUTPUT from SmiLint
> --------------------
> File: TED-MIB.my
> Severity level requested: 6
>
> Line  Severity  Problem
>
> 105 5 warning: index element `tedAreaId' of row `tedEntry' should be
>                  not-accessible in SMIv2 MIB
>          5 warning: index element `tedRouterId' of row `tedEntry' should be
>                  not-accessible in SMIv2 MIB
>          5 warning: index element `tedLinkStateId' of row `tedEntry' should
> be
>                  not-accessible in SMIv2 MIB
>
>
> Comments on the Text of the Document
> -------------------------------------
> Once comments on the MIB module are converged then I'll do a more
> thorough review of this text.
>
> * Renaming of "te" to "ted" has not propogated completely thorough the
> text.
>
>
> * Security Considerations
>
> I disagree with the first paragraph.  First, there are no read-create
> objects.  Second, the MIB module may be implemented correctly, but
> there could be a risk if objects were set.
>
>
>
>
>
>
> Comments on MIB Module
> ----------------------
>
> 1) The warnings above were previously noted in the v5 MIB
> review. These warnings should be fixed in my opinion.
> Please discuss.
>
> 2)(NIT) Cannot extract MIB using mstrip
>
> 3) LAST-UPDATED and REVISION dates are incorrect.
>
> 4) Comment
> -- assigned by IANA, see section 8.1 for details
> but the section is 9.1, please say, see "IANA Considerations for TED-MIB"
> section
>
> 5) There is not one REFERENCE clause in this MIB.  As I requested in
> the version 5 MIB review, given the nature of this MIB where it draws from
> documents in several different WGs, I believe REFERENCE clauses should be
> given.
> As an agent developer, trying to implement these objects without a pointer
> to an RFC would be difficult and potentially error-prone.
>
> Granted there are references to entire RFCs within the DESCRIPTION clauses
> but the REFERENCE Clause should be more specific with a section and
> sub-section.
>
>
> 6) Although this MIB did go through a LC in the CCAMP, there are
> other WGs where this MIB should probably also have a LC.
> Please discuss.
>
>
>
> 7) OID layout, while there were some improvements here, the oid layout as
> suggested by Appendix D of RFC4181 (Guidelines for MIB Documents)
> was not completely followed.  Was this an oversight or is there a
> reason that it was not followed?
>
> Suggested OID Layout
>
>           xxxMIB
>           |
>           +-- xxxNotifications(0)
>           +-- xxxObjects(1)
>           +-- xxxConformance(2)
>               |
>               +-- xxxCompliances(1)
>               +-- xxxGroups(2)
>
>
> This MIB:
>
> - tedMIB
>   \-v-0 tedNotifications
>
>     |-1 tedObjects
>
>     \-2 tedConformance
>       \-v-1 tedGroups
>         \-2 tedCompliances
>
>
> Compliances and Groups do not follow the "Guidelines for MIB Documents"
>
>
> 8) The overall structure of the tables is a concern. Several indexes are
> Unsigned32(0..4294967295) but there is no need to have such a large index
> as far as I can tell.  Further, the use of 0 does not appear to be
> warrented.
> (Please see rfc4181, section 4.6.1 and discuss why these indexes need to
> be Unsigned32(0..4294967295).
>
>
> The SwCapTable claims to give additional information about local or
> remote TE links but the indexing makes that untennable as far as I can tell.
> How does one know if they are looking at a local or remote link?
>
> The tedSwCapIndex has nothing to do with RFC4801 as far as I can tell, so
> don't understand what the index (tedSwCapIndex) is really supposed to be.
>
>
> Additionally, the tedAreaId DESCRIPTION mentions using 0, but the range does
> not
> include 0.   Again, a REFERENCE clause to each of the 3 or 4 documents
> that this one object draws from (depending on the protocol),
> would really be helpful.
>
> Wrt tedLocalIfAdrEntry indexes, why does the tedLocalIfAddrIndex
> need to be Unsigned32(0..4294967295), similarly why is the
> tedRemoteIfAddrEntry tedRemoteIfAddrIndex Unsigned32(0..4294967295) ?
>
>
>
> 9) There was some emails back and forth on the MIB v5 review about
> adding objects to give the state of the data in this MIB.
> That was not done.
> To recap an entry is created by local configuration,
> then routing (or the specific link?) is supposed to be triggered,
> then what is the state of the data in this MIB?
>
> The MIB is NOT viable unless the state of the data can be understood
> by an operator.
>
> Please see the Aug 28th email discussion on version 5 MIB.
>
>
> 10) tedNotificationEnabled
>
> Why is this object needed?  Please answer the question wrt rfc3413.
>
>
> 11) tedNotificationMaxRate
>
> This one throttling mechanism is used to control 3 different notifications.
> I would think that the status change notification would be sent so much more
> often than a create/delete notification, so why is only one value used for
> 3 notifications?
>
> Additionally, I would expect that the create and delete notifications should
> probably be at a higher priority.  In other words, could you discuss why
> the one throttle object?
>
>
>
> 12) tedLinkInformationSource and tedLinkInformationData
>
> Which version of OSPF is being supported?  Looks to be ospfv2.
>
> There may be a desire in the future to also support ospfv3, so
> would be best to specify.  Also, this MIB says that it supports
> ipv6 and that would be ospfv3.
>
> 13) Please change the name of "tedSwCap" to "tedSwitchCapacity".
>
>
> 14) Conformance statements are missing the restrictions for
> IpAddress and IpAddressType objects in this MIB.
> Please correct this.
>
> Additionally, some of the DESCRIPTION clauses makes it seem that
> some objects are optional, but this is not reflected in the Conformance
> statements.  Please discuss wrt the following objects:
>
>
>
> 15) FullCompliance and ReadOnlyCompliance do not contain all of the
> groups.  Neither compliance includes the Notifications group.
>
> 16) The DESCRIPTION of the Notifications Group states:
>     "This group is mandatory for those implementations that can implement
>     the notifications contained in this group."
>
> So, why would these not be implementable?  I'm not sure this sort of
> DESCRIPTION belongs in a standard's document.  If the intention is to
> make these Notifications optional and this is okay with the wg, fine,
> but this DESCRIPTION needs to be improved.
>
> ---
>
>
>
>

From jcucchiara@mindspring.com  Fri Dec 11 07:44:33 2009
Return-Path: 
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E012F28C116; Fri, 11 Dec 2009 07:44:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300,  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 eU4JYkLfpB5T; Fri, 11 Dec 2009 07:44:32 -0800 (PST)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 634293A687B; Fri, 11 Dec 2009 07:44:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dHDMoPVEXgLfQzzIdvtphlL6yQYXhYr/XO1kZ6kO+LfFZNix9gYqkYxTYJK6hGYD; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [108.1.135.222] (helo=JoanPC) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1NJ7fE-0000OK-U1; Fri, 11 Dec 2009 10:44:18 -0500
Message-ID: <00b901ca7a78$81d1b970$6601a8c0@JoanPC>
From: "Joan Cucchiara" 
To: "Lou Berger" 
References: <49F8E7CA.6010902@labn.net> <00c601c9ca3e$347d4da0$6501a8c0@JoanPC> <49FAD79A.2090805@labn.net> <015c01c9d22e$13963730$6501a8c0@JoanPC> <4A40C6DD.2000002@labn.net>  <00a401c9f4ce$aa644c70$6501a8c0@JoanPC> <4AEAF58A.5020000@labn.net> <002c01ca596c$ed6798d0$6401a8c0@JoanPC> <4AFA2836.9030102@labn.net> <4B1D61C9.5080204@labn.net>  <00a201ca7814$a1c9b3b0$6601a8c0@JoanPC> <4B1E66F2.1050606@labn.net> <00aa01ca7a75$66036020$6601a8c0@JoanPC> <4B22666B.1070106@labn.net>
Date: Fri, 11 Dec 2009 10:42:12 -0500
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.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26540bec4ab79ec2c1702e743d821b21011f666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 108.1.135.222
Cc: "MIB Doctors \(E-mail\)" , CCAMP , "Romascanu, Dan \(Dan\)" , Adrian Farrel , ke-kumaki@kddilabs.jp, "Brungard, Deborah A, ALABS" 
Subject: Re: [CCAMP] MIB Dr. review of draft-ietf-gmpls-ted-mib-06.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Dec 2009 15:44:34 -0000

Lou,

I think MPLS should also be notified.

Thanks,
  -Joan


----- Original Message ----- 
From: "Lou Berger" 
To: "Joan Cucchiara" 
Cc: "CCAMP" ; "MIB Doctors (E-mail)" ; 
"Thomas D. Nadeau" ; "Masanori Miyazawa" 
; "Tomohiro Otani" ; 
; "Romascanu, Dan (Dan)" ; 
"Brungard, Deborah A, ALABS" ; "Adrian Farrel" 

Sent: Friday, December 11, 2009 10:34 AM
Subject: Re: MIB Dr. review of draft-ietf-gmpls-ted-mib-06.txt


> Joan,
> Thank you very much for your (usual) thorough review.  You mention that 
> you'd like to see the document last called in additional WGs.  Our current 
> plan is to issue a new LC once your review is complete and to notify both 
> the OSPF and ISIS WGs of this LC (but not a joint LC).  Do you think there 
> are any other WGs that should be notified/included?
>
> Also, I regret that you had to repeat comments made on the previous 
> version.
>
> Authors,
>
> Please reach closure/agreement with Joan on her comments before publishing 
> the next version.  This includes addressing issues raised, but not 
> addressed, in the prior version. (The WG mail list is a fine place for the 
> discussion.)
>
> Lou
>
> On 12/11/2009 10:19 AM, Joan Cucchiara wrote:
>> Folks,
>>
>> Please excuse the lateness of the review.  I apologize.
>>
>> Please lets discuss the comments numbered below and reach convergence
>> prior to another respin of the MIB.
>>
>> Thanks,
>>     -Joan
>>
>> PS. A comment with a NIT does not need discussion per se, it is more
>> a minor editorial issue and would be nice if it were fixed, but it is not
>> necessary to fix for MIB review purposes.
>>
>>
>>
>> OUTPUT from SMICngPRO
>> ---------------------
>> W: f(TED-MIB.my), (777,10) Variable "tedAreaId" in notification
>> "tedStatusChange" is an index for a table
>> W: f(TED-MIB.my), (777,21) Variable "tedRouterId" in notification
>> "tedStatusChange" is an index for a table
>> W: f(TED-MIB.my), (777,34) Variable "tedLinkStateId" in notification
>> "tedStatusChange" is an index for a table
>> W: f(TED-MIB.my), (791,10) Variable "tedAreaId" in notification
>> "tedCreation" is an index for a table
>> W: f(TED-MIB.my), (791,21) Variable "tedRouterId" in notification
>> "tedCreation" is an index for a table
>> W: f(TED-MIB.my), (791,34) Variable "tedLinkStateId" in notification
>> "tedCreation" is an index for a table
>> W: f(TED-MIB.my), (803,10) Variable "tedAreaId" in notification
>> "tedDeletion" is an index for a table
>> W: f(TED-MIB.my), (803,21) Variable "tedRouterId" in notification
>> "tedDeletion" is an index for a table
>> W: f(TED-MIB.my), (803,34) Variable "tedLinkStateId" in notification
>> "tedDeletion" is an index for a table
>>
>>
>>
>> OUTPUT from SmiLint
>> --------------------
>> File: TED-MIB.my
>> Severity level requested: 6
>>
>> Line  Severity  Problem
>>
>> 105 5 warning: index element `tedAreaId' of row `tedEntry' should be
>>                  not-accessible in SMIv2 MIB
>>          5 warning: index element `tedRouterId' of row `tedEntry' should 
>> be
>>                  not-accessible in SMIv2 MIB
>>          5 warning: index element `tedLinkStateId' of row `tedEntry' 
>> should
>> be
>>                  not-accessible in SMIv2 MIB
>>
>>
>> Comments on the Text of the Document
>> -------------------------------------
>> Once comments on the MIB module are converged then I'll do a more
>> thorough review of this text.
>>
>> * Renaming of "te" to "ted" has not propogated completely thorough the
>> text.
>>
>>
>> * Security Considerations
>>
>> I disagree with the first paragraph.  First, there are no read-create
>> objects.  Second, the MIB module may be implemented correctly, but
>> there could be a risk if objects were set.
>>
>>
>>
>>
>>
>>
>> Comments on MIB Module
>> ----------------------
>>
>> 1) The warnings above were previously noted in the v5 MIB
>> review. These warnings should be fixed in my opinion.
>> Please discuss.
>>
>> 2)(NIT) Cannot extract MIB using mstrip
>>
>> 3) LAST-UPDATED and REVISION dates are incorrect.
>>
>> 4) Comment
>> -- assigned by IANA, see section 8.1 for details
>> but the section is 9.1, please say, see "IANA Considerations for TED-MIB"
>> section
>>
>> 5) There is not one REFERENCE clause in this MIB.  As I requested in
>> the version 5 MIB review, given the nature of this MIB where it draws 
>> from
>> documents in several different WGs, I believe REFERENCE clauses should be
>> given.
>> As an agent developer, trying to implement these objects without a 
>> pointer
>> to an RFC would be difficult and potentially error-prone.
>>
>> Granted there are references to entire RFCs within the DESCRIPTION 
>> clauses
>> but the REFERENCE Clause should be more specific with a section and
>> sub-section.
>>
>>
>> 6) Although this MIB did go through a LC in the CCAMP, there are
>> other WGs where this MIB should probably also have a LC.
>> Please discuss.
>>
>>
>>
>> 7) OID layout, while there were some improvements here, the oid layout as
>> suggested by Appendix D of RFC4181 (Guidelines for MIB Documents)
>> was not completely followed.  Was this an oversight or is there a
>> reason that it was not followed?
>>
>> Suggested OID Layout
>>
>>           xxxMIB
>>           |
>>           +-- xxxNotifications(0)
>>           +-- xxxObjects(1)
>>           +-- xxxConformance(2)
>>               |
>>               +-- xxxCompliances(1)
>>               +-- xxxGroups(2)
>>
>>
>> This MIB:
>>
>> - tedMIB
>>   \-v-0 tedNotifications
>>
>>     |-1 tedObjects
>>
>>     \-2 tedConformance
>>       \-v-1 tedGroups
>>         \-2 tedCompliances
>>
>>
>> Compliances and Groups do not follow the "Guidelines for MIB Documents"
>>
>>
>> 8) The overall structure of the tables is a concern. Several indexes are
>> Unsigned32(0..4294967295) but there is no need to have such a large index
>> as far as I can tell.  Further, the use of 0 does not appear to be
>> warrented.
>> (Please see rfc4181, section 4.6.1 and discuss why these indexes need to
>> be Unsigned32(0..4294967295).
>>
>>
>> The SwCapTable claims to give additional information about local or
>> remote TE links but the indexing makes that untennable as far as I can 
>> tell.
>> How does one know if they are looking at a local or remote link?
>>
>> The tedSwCapIndex has nothing to do with RFC4801 as far as I can tell, so
>> don't understand what the index (tedSwCapIndex) is really supposed to be.
>>
>>
>> Additionally, the tedAreaId DESCRIPTION mentions using 0, but the range 
>> does
>> not
>> include 0.   Again, a REFERENCE clause to each of the 3 or 4 documents
>> that this one object draws from (depending on the protocol),
>> would really be helpful.
>>
>> Wrt tedLocalIfAdrEntry indexes, why does the tedLocalIfAddrIndex
>> need to be Unsigned32(0..4294967295), similarly why is the
>> tedRemoteIfAddrEntry tedRemoteIfAddrIndex Unsigned32(0..4294967295) ?
>>
>>
>>
>> 9) There was some emails back and forth on the MIB v5 review about
>> adding objects to give the state of the data in this MIB.
>> That was not done.
>> To recap an entry is created by local configuration,
>> then routing (or the specific link?) is supposed to be triggered,
>> then what is the state of the data in this MIB?
>>
>> The MIB is NOT viable unless the state of the data can be understood
>> by an operator.
>>
>> Please see the Aug 28th email discussion on version 5 MIB.
>>
>>
>> 10) tedNotificationEnabled
>>
>> Why is this object needed?  Please answer the question wrt rfc3413.
>>
>>
>> 11) tedNotificationMaxRate
>>
>> This one throttling mechanism is used to control 3 different 
>> notifications.
>> I would think that the status change notification would be sent so much 
>> more
>> often than a create/delete notification, so why is only one value used 
>> for
>> 3 notifications?
>>
>> Additionally, I would expect that the create and delete notifications 
>> should
>> probably be at a higher priority.  In other words, could you discuss why
>> the one throttle object?
>>
>>
>>
>> 12) tedLinkInformationSource and tedLinkInformationData
>>
>> Which version of OSPF is being supported?  Looks to be ospfv2.
>>
>> There may be a desire in the future to also support ospfv3, so
>> would be best to specify.  Also, this MIB says that it supports
>> ipv6 and that would be ospfv3.
>>
>> 13) Please change the name of "tedSwCap" to "tedSwitchCapacity".
>>
>>
>> 14) Conformance statements are missing the restrictions for
>> IpAddress and IpAddressType objects in this MIB.
>> Please correct this.
>>
>> Additionally, some of the DESCRIPTION clauses makes it seem that
>> some objects are optional, but this is not reflected in the Conformance
>> statements.  Please discuss wrt the following objects:
>>
>>
>>
>> 15) FullCompliance and ReadOnlyCompliance do not contain all of the
>> groups.  Neither compliance includes the Notifications group.
>>
>> 16) The DESCRIPTION of the Notifications Group states:
>>     "This group is mandatory for those implementations that can implement
>>     the notifications contained in this group."
>>
>> So, why would these not be implementable?  I'm not sure this sort of
>> DESCRIPTION belongs in a standard's document.  If the intention is to
>> make these Notifications optional and this is okay with the wg, fine,
>> but this DESCRIPTION needs to be improved.
>>
>> ---
>>
>>
>>
>> 


From lberger@labn.net  Fri Dec 11 07:51:25 2009
Return-Path: 
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1F23A683B for ; Fri, 11 Dec 2009 07:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level: 
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 IgsmPhCNUAZH for ; Fri, 11 Dec 2009 07:51:25 -0800 (PST)
Received: from outbound-mail-149.bluehost.com (outbound-mail-149.bluehost.com [67.222.38.39]) by core3.amsl.com (Postfix) with SMTP id 190013A6405 for ; Fri, 11 Dec 2009 07:51:25 -0800 (PST)
Received: (qmail 4557 invoked by uid 0); 11 Dec 2009 15:51:13 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy5.bluehost.com with SMTP; 11 Dec 2009 15:51:13 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=L0pk9itLq7lBOLF98FZjBy8LxkaBaptDATk4DeWPf2b0kbDzQVdbKQMs7kCdEaDqbkTGIuDV7DVgSs+/kNABZQyat5RjJxhW5DwgHHGro0lalfO9wVlT6nxw0E55eGu7;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NJ7lx-00031C-77; Fri, 11 Dec 2009 08:51:13 -0700
Message-ID: <4B226A82.9000506@labn.net>
Date: Fri, 11 Dec 2009 10:51:30 -0500
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3
MIME-Version: 1.0
To: Joan Cucchiara 
References: <49F8E7CA.6010902@labn.net> <00c601c9ca3e$347d4da0$6501a8c0@JoanPC> <49FAD79A.2090805@labn.net> <015c01c9d22e$13963730$6501a8c0@JoanPC> <4A40C6DD.2000002@labn.net>  <00a401c9f4ce$aa644c70$6501a8c0@JoanPC> <4AEAF58A.5020000@labn.net> <002c01ca596c$ed6798d0$6401a8c0@JoanPC> <4AFA2836.9030102@labn.net> <4B1D61C9.5080204@labn.net>  <00a201ca7814$a1c9b3b0$6601a8c0@JoanPC> <4B1E66F2.1050606@labn.net> <00aa01ca7a75$66036020$6601a8c0@JoanPC> <4B22666B.1070106@labn.net> <00b901ca7a78$81d1b970$6601a8c0@JoanPC>
In-Reply-To: <00b901ca7a78$81d1b970$6601a8c0@JoanPC>
X-Enigmail-Version: 0.96a
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "MIB Doctors \(E-mail\)" , CCAMP , "Romascanu, Dan \(Dan\)" , Adrian Farrel , ke-kumaki@kddilabs.jp, "Brungard, Deborah A, ALABS" 
Subject: Re: [CCAMP] MIB Dr. review of draft-ietf-gmpls-ted-mib-06.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Dec 2009 15:51:25 -0000

Sounds sensible.  Much thanks.

Lou

On 12/11/2009 10:42 AM, Joan Cucchiara wrote:
> Lou,
>
> I think MPLS should also be notified.
>
> Thanks,
>    -Joan
>

From Jonathan.Sadler@tellabs.com  Fri Dec 11 11:50:47 2009
Return-Path: 
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC163A6890 for ; Fri, 11 Dec 2009 11:50:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.993
X-Spam-Level: 
X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.605,  BAYES_00=-2.599, HTML_MESSAGE=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 Hc6Gerr0iGU4 for ; Fri, 11 Dec 2009 11:50:34 -0800 (PST)
Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id 1385B3A67F0 for ; Fri, 11 Dec 2009 11:50:34 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.47,384,1257120000";  d="scan'208,217";a="1304843948"
Received: from usnvwwmspht01.hq.tellabs.com (HELO usnvwwmspht01.tellabs-west.tellabsinc.net) ([172.23.211.69]) by mx4-priv.tellabs.com with ESMTP; 11 Dec 2009 19:49:18 +0000
Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht01.tellabs-west.tellabsinc.net ([172.23.211.69]) with mapi; Fri, 11 Dec 2009 13:49:18 -0600
From: "Sadler, Jonathan B." 
To: Evelyne Roch , Greg Bernstein 
Date: Fri, 11 Dec 2009 13:49:17 -0600
Thread-Topic: [CCAMP] Working	group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
Thread-Index: Acp5zG1NJLPkW2faTuW3ttuQEjyXZAAAHU9gADN/TAA=
Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2B83911861A2@EX-NAP.tellabs-west.tellabsinc.net>
References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com>  <90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com>  <90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com> <4B197A79.1020301@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com> <4B1E9508.1010502@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com> <4B2025D3.3090208@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC96A4@zcarhxm2.corp.nortel.com> <4B211ED9.30908@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0F95F@zcarhxm2.corp.nortel.com> <4B213E03.70508@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0FCF9@zcarhxm2.corp.nortel.com> <4B214791.3! 050600@gr otto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0FE01@zcarhxm2.corp.nortel.com>
In-Reply-To: <90243C8A881F8D419D855264D9636F3A02C0FE01@zcarhxm2.corp.nortel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5292FFA96EC22A4386067E9DBCC0CD2B83911861A2EXNAPtellabsw_"
MIME-Version: 1.0
Cc: CCAMP 
Subject: Re: [CCAMP] Working	group	lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Dec 2009 19:50:47 -0000

--_000_5292FFA96EC22A4386067E9DBCC0CD2B83911861A2EXNAPtellabsw_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Greg,

There have been a number of different liaisons from ITU that have talked ab=
out the separation of control plane instances on a layer-by-layer basis and=
 the limits this places on what signaling information can be carried by the=
 other instance.  Three that are quite pertinent to this discussion are as =
follows:

  https://datatracker.ietf.org/documents/LIAISON/file537.pdf - states "VCAT=
 is viewed as a layer of its own and has its own call controller. As per th=
e interlayer architecture in G.8080 section 6.6, the VCAT call would be ass=
ociated with a server layer call or calls, each of which would have/own one=
 or more server layer connections.  It is these connections that are part o=
f the VCG. "
  https://datatracker.ietf.org/documents/LIAISON/file419.doc - states "sign=
alling messages are always scoped to a specific layer - the information ele=
ments in the server layer signalling messages are specific to the server la=
yer (e.g. containing only server layer resources in the ERO) and the inform=
ation elements in the client layer signalling messages are specific to the =
client layer (e.g. containing only client layer resources in the ERO)."
  https://datatracker.ietf.org/documents/LIAISON/file432.doc - states "if t=
wo layers are under different administrative domains because they belong to=
 two different providers, the amount of information that can be shared betw=
een the two domains is more limited than in the case where a single provide=
r network provides resources at all layers"



As pointed out by Evelyne, the MLN/MRN drafts/RFCs place the CALL_ATTRIBUTE=
S object in the server layer (i.e. STS/VC) signaling messages, while it is =
being used to carry client layer (i.e. VCAT) detail.  This is the piggyback=
ing issue (i.e. carrying client layer data in the server layer signaling) t=
hat I referenced in the comment I made earlier.



Why is this not good?  Well, if the client layer and server layer are in di=
fferent control contexts, it becomes unsafe to assume what service the othe=
r control context will provide.  For example:

 - the client layer could be using a control plane protocol while the serve=
r layer is being manually/statically configured

 - the client layer doesn't have access to the information being exchanged =
by a server layer control plane instance

 - the server layer network utilizes a control plane protocol other than on=
e specified by the IETF

 - the server layer network's policy is to not allow the passing of arbitra=
ry data in its control plane



In all of these cases, the CALL_ATTRIBUTES object would not make it between=
 the endpoints, causing the VCAT to not be established.



This sort of separation information has been provided in other IETF protoco=
ls (e.g. T-LDP used for PW setup - it's separate from the RSVP-TE setup don=
e in for the Tunnel LSP) - we're just looking for the same sort of separati=
on to be provided for inverse multiplexing configuration mechanisms.



Jonathan Sadler


________________________________
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of E=
velyne Roch
Sent: Thursday, December 10, 2009 1:22 PM
To: Greg Bernstein
Cc: CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lca=
s-08

Greg,

The dependency is problematic in networks that follow the ASON architecture=
 because of the administrative boundaries. I would like to see implementati=
ons that are compliant with this draft and the ASON architecture.

Evelyne

________________________________
From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Thursday, December 10, 2009 2:10 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lca=
s-08
Hi Evelyne, why is this dependency problematic? What are you trying to do a=
nd what it the context?

Greg

Evelyne Roch wrote:
Greg,

There is a problem in the architecture because the CALL_ATTRIBUTES is carry=
ing group info in the member call, creating a dependency on the members to =
achieve VCAT signaling. That dependency is problematic in a network with ad=
ministrative boundaries.

Evelyne

________________________________
From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Thursday, December 10, 2009 1:29 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lca=
s-08
Hi Evelyne, version 04 published in February of 2008 contained a "Call_Data=
_Object", with a TLV containing exactly the information and utilizing the s=
ame procedures that we are now using with the CALL_ATTRIBUTES object.
It was recommended by the WG chairs to use the CALL_ATTRIBUTES object as de=
fined in the MLN-Extensions work rather than defining another "Call_data_ob=
ject". None of of the procedures were changed from 04.
Is there a problem with functionality? We worked very hard to find a techni=
que utilizing existing mechanisms to give some support forthe member sharin=
g scenario. We do not preclude other techniques being used in the future.

Greg

Evelyne Roch wrote:
This liaison was referring to version 04, before the introduction of CALL_A=
TTRIBUTES in the draft, exactly where the problem is.

In the laison 429, the ITU-T agrees to one call per VCG. That is the VCAT c=
all (not addressed in the draft right now).

As far as member calls, members could be in same or different calls based o=
n application (for diverse routing -> could be same call, for protection/re=
storation -> could be different calls). That is the member call used in the=
 draft.

The problem is that CALL_ATTRIBUTES is carried in member call signaling whe=
n it pertains to the VCG, i.e. VCAT call.

Evelyne





________________________________
From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Thursday, December 10, 2009 11:16 AM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lca=
s-08
Hi Evelyne, I'll add some text to the requirements section to clarify "comm=
on pool" per your request.
The "call concept" usage and "member sharing scenario" have been previously=
 discussed, liaised, and resolved with ITU-T.


https://datatracker.ietf.org/liaison/415/



It includes:

ITU: "Per Question 5:  We understand that this draft is only addressing

the

constituent server layer call; i.e., not the ASON multilayer call

supporting call construct. However, we suggest that you do not preclude

extensions to use a call in the VCAT layer.



CCAMP response: As noted above, this is not precluded. We look forward to

future communication from you as you progress this work."



Q14 later responded saying they were satisfied with the one call

construct:

https://datatracker.ietf.org/liaison/429/
Greg

Evelyne Roch wrote:
Greg,

Normally, I would expect the requirements section to be clear enough that i=
t helps define a proper solution mechanism and clearly sets the scope, not =
the other way around (i.e. you need to read the mechanism to understand how=
 the requirements should be interpreted).

My main concern is how the "call concept" is being used with the member sha=
ring scenario, as I mentioned earlier in this thread. The calls (in the dra=
ft) are really member calls, not VCAT group calls. But the call attributes =
contain VCAT group information. I don't want the  member call to attribute =
carry call information for the entire VCAT group.

Evelyne

________________________________
From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Wednesday, December 09, 2009 5:34 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lca=
s-08
Hi Evelyne, the common pool is a set of potential member signals that have =
been set up using the mechanisms defined in the draft, particularly the VCA=
T call procedures. The draft allows these to be "shared" amongst different =
VCGs over time. Note that at any given point in time a member signal can be=
long to only one VCG. Note that by the nature of VCAT that these are signal=
s that have the same source and destination. The procedures section makes t=
his fairly clear.

Greg



Evelyne Roch wrote:
Greg,

First, I think we need to further clarify the requirements as I'm not sure =
all the readers will interpret the requirements the same way. What exactly =
does it mean to be "in a common pool"?

Evelyne

________________________________
From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Tuesday, December 08, 2009 1:04 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lca=
s-08
Hi Evelyne, the main focus on this work was to support VCGs with diversely =
routed routed members. We were asked to include the member sharing scenario=
 and formulated a method to accommodate it without significantly increasing=
 the complexity of the messages involved.  It seems to us that the solution=
 included in this draft provides sufficient functionality to meet the requi=
rements in the document. Is there a scenario you think is within the scope =
of the draft that is not addressed?

Greg

Evelyne Roch wrote:

Greg, see below.





-----Original Message-----

From: Greg Bernstein [mailto:gregb@grotto-networking.com]

Sent: Friday, December 04, 2009 4:09 PM

To: Roch, Evelyne (CAR:Q840)

Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP

Subject: Re: [CCAMP] Working group



lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08









I'm not sure that we have calls of calls in GMPLS. At the time this

was written this wasn't deemed desirable.





The model of calls being supported by calls is clearly support by ASON,

whether at the same layer (see G.8080 section 6.7) or different layer

(section 6.6). I find it highly desirable.







Evelyne









--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

Dr Greg Bernstein, Grotto Networking (510) 573-2237







--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

Dr Greg Bernstein, Grotto Networking (510) 573-2237







--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

Dr Greg Bernstein, Grotto Networking (510) 573-2237







--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

Dr Greg Bernstein, Grotto Networking (510) 573-2237







--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

Dr Greg Bernstein, Grotto Networking (510) 573-2237



--_000_5292FFA96EC22A4386067E9DBCC0CD2B83911861A2EXNAPtellabsw_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


















Hi Greg,



 



There have been a number of different =
liaisons
from ITU that have talked about the separation of control plane instances o=
n a
layer-by-layer basis and the limits this places on what signaling informati=
on
can be carried by the other instance.  Three that are quite pertinent =
to
this discussion are as follows:



  https://datatracker.ietf.org/documents/LIAISON/=
file537.pdf - s=
tates R=
20;VCAT is viewed as a layer of its own and has its own =
call controller. As per the interlayer architecture in G.8080 section 6.6, =
the VCAT call would be associated with a =
server layer call or calls, each of which would have/own one or more server=
 layer connections.  It is these connections that are part of the VCG.=
 R=
20;



  https:=
//datatracker.ietf.org/documents/LIAISON/file419.doc
- states “signalling messages are always scoped to a
specific layer – the information elements in the server layer signall=
ing
messages are specific to the server layer (e.g. containing only server laye=
r
resources in the ERO) and the information elements in the client layer
signalling messages are specific to the client layer (e.g. containing only
client layer resources in the ERO).“<=
/span>



  https:=
//datatracker.ietf.org/documents/LIAISON/file432.doc
- states “if two layers are under different administrat=
ive
domains because they belong to two different providers, the amount of
information that can be shared between the two domains is more limited than=
 in
the case where a single provider network provides resources at all layers“



 
As pointed out by Evelyne, the MLN/MRN drafts/RFCs place the CA=
LL_ATTRIBUTES object in the server layer (i.e. STS/VC) signaling messages, =
while it is being used to carry client layer (i.e. VCAT) detail.  This=
 is the piggybacking issue (i.e. carrying client layer data in the server l=
ayer signaling) that I referenced in the comment I made earlier.=

 
=
Why is this not good?  Well, if the client layer and server layer are =
in different control contexts, it becomes unsafe to assume what service the=
 other control context will provide.  For example:
 - the client layer could be using a control plane protocol whi=
le the server layer is being manually/statically configured
 - the client layer doesn’t have access to the informatio=
n being exchanged by a server layer control plane instance
 - the server layer network utilizes a control plane protocol o=
ther than one specified by the IETF
 - the server layer network’s policy is to not allow the =
passing of arbitrary data in its control plane
 
=
In all of these cases, the CALL_ATTRIBUTES object would not make it between=
 the endpoints, causing the VCAT to not be established.
 
=
This sort of separation information has been provided in other IETF protoco=
ls (e.g. T-LDP used for PW setup – it’s separate from the RSVP-=
TE setup done in for the Tunnel LSP) – we’re just looking for t=
he same sort of separation to be provided for inverse multiplexing configur=
ation mechanisms.
 
=
Jonathan Sadler



 



 















From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <=
b>On Behalf Of Evelyne
 Roch

Sent: Thursday, December 10,=
 2009
1:22 PM

To: Greg Bernstein

Cc: CCAMP

Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08






=
 



Greg,



=
 



The dependency is problematic in netwo=
rks
that follow the ASON architecture because of the administrative boundaries.=
 I
would like to see implementations that are compliant with this draft and th=
e
ASON architecture. 



=
 



Evelyne



=
 












From:=
 Greg
Bernstein [mailto:gregb@grotto-networking.com] 

Sent: Thursday, December 10,=
 2009
2:10 PM

To: Roch, Evelyne (CAR:Q840)=


Cc: BRUNGARD, DEBORAH A (ATT=
LABS);
CCAMP

Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp=
-gmpls-vcat-lcas-08



=
Hi Evelyne, why is this dependency problematic? =
What
are you trying to do and what it the context?



Greg



Evelyne Roch wrote: 



Greg, 



=
 



There is a problem in the architecture
because the CALL_ATTRIBUTES is carrying group info in the member call, crea=
ting
a dependency on the members to achieve VCAT signaling. That dependency is
problematic in a network with administrative boundaries.=




=
 



Evelyne



=
 












From:=
 Greg
Bernstein [mailto:gregb@grot=
to-networking.com]


Sent: Thursday, December 10,=
 2009
1:29 PM

To: Roch, Evelyne (CAR:Q840)=


Cc: BRUNGARD, DEBORAH A (ATT=
LABS);
CCAMP

Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08



=
Hi Evelyne, version 04 published in February of =
2008
contained a "Call_Data_Object", with a TLV containing exactly the
information and utilizing the same procedures that we are now using with th=
e
CALL_ATTRIBUTES object. 

It was recommended by the WG chairs to use the CALL_ATTRIBUTES object as
defined in the MLN-Extensions work rather than defining another
"Call_data_object". None of of the procedures were changed from 0=
4. 

Is there a problem with functionality? We worked very hard to find a techni=
que
utilizing existing mechanisms to give some support forthe member sharing
scenario. We do not preclude other techniques being used in the future.



Greg



Evelyne Roch wrote: 



This liaison was referring to version =
04,
before the introduction of CALL_ATTRIBUTES in the draft, exactly where the
problem is.



=
 



In the laison 429, the ITU-T agrees to=
 one
call per VCG. That is the VCAT call (not addressed in the draft right now).=




=
 



As far as member calls, members could =
be
in same or different calls based on application (for diverse routing ->
could be same call, for protection/restoration -> could be different cal=
ls).
That is the member call used in the draft. 



=
 



The problem is that CALL_ATTRIBUTES is
carried in member call signaling when it pertains to the VCG, i.e. VCAT cal=
l. 



=
 



Evelyne



=
 



=
 



=
 



=
 



=
 












From:=
 Greg
Bernstein [mailto:gregb@grotto-networking.com]


Sent: Thursday, December 10,=
 2009
11:16 AM

To: Roch, Evelyne (CAR:Q840)=


Cc: BRUNGARD, DEBORAH A (ATT=
LABS);
CCAMP

Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08



=
Hi Evelyne, I'll add some text to the requiremen=
ts
section to clarify "common pool" per your request.

The "call concept" usage and "member sharing scenario" =
have
been previously discussed, liaised, and resolved with ITU-T. 







h=
ttps://datatracker.ietf.org/liaison/415/
=

 
It includes:
ITU: "Per Question 5:  We understand that this draft is only ad=
dressing
the
constituent server layer call; i.e., not the ASON multilayer call
supporting call construct. However, we suggest that you do not preclude
extensions to use a call in the VCAT layer.
 
CCAMP response: As noted above, thi=
s is not precluded. We look forward to
future communication from you as you progress this work."=

 
Q14 later responded saying they were satisfied with the one call
construct:
h=
ttps://datatracker.ietf.org/liaison/429/



=
Greg



Evelyne Roch wrote: 



Greg,



=
 



Normally, I would expect the requireme=
nts
section to be clear enough that it helps define a proper solution mechanism=
 and
clearly sets the scope, not the other way around (i.e. you need to read the
mechanism to understand how the requirements should be interpreted).=




=
 



My main concern is how the "call
concept" is being used with the member sharing scenario, as I
mentioned earlier in this thread. The calls (in the draft) are really membe=
r
calls, not VCAT group calls. But the call attributes contain VCAT grou=
p
information. I don't want the  member call to attribute carry cal=
l
information for the entire VCAT group.



=
 



Evelyne



=
 












From:=
 Greg
Bernstein [mailto:gregb@grotto-networking.com]


Sent: Wednesday, December 09=
, 2009
5:34 PM

To: Roch, Evelyne (CAR:Q840)=


Cc: BRUNGARD, DEBORAH A (ATT=
LABS);
CCAMP

Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08



=
Hi Evelyne, the common pool is a set of potentia=
l
member signals that have been set up using the mechanisms defined in the dr=
aft,
particularly the VCAT call procedures. The draft allows these to be
"shared" amongst different VCGs over time. Note that at any given
point in time a member signal can belong to only one VCG. Note that by the
nature of VCAT that these are signals that have the same source and
destination. The procedures section makes this fairly clear.



Greg







Evelyne Roch wrote: 



Greg,



=
 



First, I think we need to further clar=
ify
the requirements as I'm not sure all the readers will interpret
the requirements the same way. What exactly does it mean to be
"in a common pool"?



=
 



Evelyne



=
 












From:=
 Greg
Bernstein [mailto:gregb@grotto-networking.com]


Sent: Tuesday, December 08, =
2009
1:04 PM

To: Roch, Evelyne (CAR:Q840)=


Cc: BRUNGARD, DEBORAH A (ATT=
LABS);
CCAMP

Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08



=
Hi Evelyne, the main focus on this work was to s=
upport
VCGs with diversely routed routed members. We were asked to include the mem=
ber
sharing scenario and formulated a method to accommodate it without
significantly increasing the complexity of the messages involved.  It
seems to us that the solution included in this draft provides sufficient
functionality to meet the requirements in the document. Is there a scenario=
 you
think is within the scope of the draft that is not addressed?



Greg



Evelyne Roch wrote: 



Greg, see below.
<=
pre> 
  



-----Original Message-----
From: Greg Bernstein [mailto:g=
regb@grotto-networking.com] 
Sent: Friday, December 04, 2009 4:09 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group<=
/pre>
    



lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
 
<snip>
 
  



I'm not sure that we have calls of calls in GMPLS. At the time this<=
/o:p>
was written this wasn't deemed desirable.
<= pre>    
 
The model of calls being supported by calls is clearly support by ASON,
whether at the same layer (see G.8080 section 6.7) or different layer
(section 6.6). I find it highly desirable.
= 
 
<snip>
 
Evelyne
 
 
 

= 

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 
 

= 

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 
 

= 

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 
 

= 

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 
 

= 

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237
 
--_000_5292FFA96EC22A4386067E9DBCC0CD2B83911861A2EXNAPtellabsw_-- From root@core3.amsl.com Sun Dec 13 18:30:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AE49E28C0E6; Sun, 13 Dec 2009 18:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091214023001.AE49E28C0E6@core3.amsl.com> Date: Sun, 13 Dec 2009 18:30:01 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-confirm-data-channel-status-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 02:30:01 -0000 --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 : Data Channel Status Confirmation Extensions for the Link Management Protocol Author(s) : D. Li, et al. Filename : draft-ietf-ccamp-confirm-data-channel-status-09.txt Pages : 16 Date : 2009-12-13 This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label- Switching Routers (LSRs) to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane Li Expires June 2010 [page 1] draft-ietf-ccamp-confirm-data-channel-status-09.txt December 2009 connectivity, it is considered to be an appropriate candidate to support this feature. 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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-confirm-data-channel-status-09.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-confirm-data-channel-status-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-13181947.I-D@ietf.org> --NextPart-- From danli@huawei.com Sun Dec 13 18:45:16 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059D828C0F4; Sun, 13 Dec 2009 18:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.824 X-Spam-Level: X-Spam-Status: No, score=0.824 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 XxxYP2TaH8P5; Sun, 13 Dec 2009 18:45:14 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 2569428C0FB; Sun, 13 Dec 2009 18:45:09 -0800 (PST) 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 <0KUM00I7HFML1D@szxga01-in.huawei.com>; Mon, 14 Dec 2009 10:44:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUM00F40FML3K@szxga01-in.huawei.com>; Mon, 14 Dec 2009 10:44:45 +0800 (CST) Received: from l37133a ([10.70.77.79]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUM00CAZFMKT7@szxml06-in.huawei.com>; Mon, 14 Dec 2009 10:44:45 +0800 (CST) Date: Mon, 14 Dec 2009 10:44:43 +0800 From: Dan Li To: Adrian.Farrel@huawei.com, lberger@labn.net, diego.caviglia@ericsson.com, julien.meuric@orange-ftgroup.com, snigdho.bardalai@us.fujitsu.com, zhangfatai@huawei.com, xuhuiying@huawei.com, "Miguel A. Garcia" Message-id: <002b01ca7c67$648c6a40$4f4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_B4PNyi5+IIXsT6zB9HqgXA)" X-Priority: 3 X-MSMail-priority: Normal References: <4B20CE70.3040104@ericsson.com> Cc: ccamp@ietf.org, General Area Review Team Subject: Re: [CCAMP] Gen-ART review of draft-ietf-ccamp-confirm-data-channel-status-08.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 02:45:16 -0000 This is a multi-part message in MIME format. --Boundary_(ID_B4PNyi5+IIXsT6zB9HqgXA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi all, We appreciate Miguel's careful review for this draft! Thanks Miguel! We have updated this draft according to the comments we have received during the IESG LC. The lastest version of this draft has been posted. http://www.ietf.org/id/draft-ietf-ccamp-confirm-data-channel-status-09.txt Please see below for detailed changes. Thanks, Co-authors ----- Original Message ----- From: Miguel A. Garcia To: danli@huawei.com ; xuhuiying@huawei.com ; zhangfatai@huawei.com ; snigdho.bardalai@us.fujitsu.com ; julien.meuric@orange-ftgroup.com ; diego.caviglia@ericsson.com ; lberger@labn.net ; Adrian.Farrel@huawei.com Cc: General Area Review Team Sent: Thursday, December 10, 2009 6:33 PM Subject: Gen-ART review of draft-ietf-ccamp-confirm-data-channel-status-08.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ccamp-confirm-data-channel-status-08.txt Reviewer: Miguel Garcia Review Date: 2009-12-10 IETF LC End Date: 2009-12-16 IESG Telechat date: 2009-12-17 Summary: The document is ready for publication as a standards track RFC. Nits/editorial comments: In general, I have found problems with the English language. Perhaps you should get some English native speaker to give a pass to the draft to increase the readability. Now, let me give you some small details that you may want to fix: - The second paragraph of Section 4.1 acknowledges the existence of three types of Confirm Data Channel Status messages without naming them, but instead, referring to Section 7.1. In the sake of clarity of the content that goes in sections 4.1.1, 4.1.2, and 4.1.3, I would suggest to add the names of the messages to that paragraph, for example: Three new messages are defined to check data channel status: ConfirmDataChannelStatus, ConfirmDataChannelStatusAck, ConfirmDataChannelStatusNack, which are described in detail in the following sections. Message Type numbers are found in Section 7.1. Accepted. The proposed text is adopted. - In the last paragraph of Section 4.1, I found the text a bit misleading. This paragraph is describing the generalities that are applicable to all three types of ConfirmDataChannelStatus messages. However, the last paragraph reads: If the message is a Confirm Data Channel Status message... Obviously this test only applies to one of the types of messages, so I would consider more appropriate to move this paragraph to Section 4.1.1, which describes the Confirm Data Channel Status message. The last paragraph is moved to the end of Section 4.1.1. - Section 4.3, at the end of the second paragraph, the text discusses the Data Channel Status subobject, and the text reads: The new subobject MUST be part of Data_Link Class. I thought this text belongs to Section 4.2, which discusses in detail the Data Channel Status Subobject. In Section 4.3, the focus is the Data_Link Class. The last sentence of the second pragraph is trying to tell the reader that how the Data_Link Class is constructed. So we want to keep this sentence as is. - Section 5, first paragraph. The text is unparsable. It would be easier to read if it were written in active form and in separated sentences, for example: Adjacent nodes MAY send data channel status confirmation related LMP messages. Periodical timers or some other events requesting the confirmation of channel status for the data link may trigger these messages. Accepted. The proposed text is adopted. - Section 5, each of the bullet points: I would suggest to give a bit more of context to the text, by indicating when the action begins. For example, take the second bullet point; You can start it by saying: # Upon reception of a ConfirmDataChannelStatus message, the RECEIVER MUST extract the data channel status from the message and SHOULD compare.... Accepted. each of the bullet points is changed to: - Initially, the SENDER constructs.... - Upon reception of a ConfirmDataChannelStatus message, the RECEIVER MUST extract... - If the RECEIVER is... - Upon reception of a ConfirmDataChannelStatusAck message, the SENDER MUST compare... - Expand acronyms at first occurrence, e.g., LSR. Accepted. The following acronyms are expanded at their first occurrence: LSR, LSP, RSVP-TE. - Nit in the first paragraph of Section 4.4. s/This document's defined mechanisms/These document's defined mechanisms ^^^^^ s/To use this mechanisms/To use these mechanisms ^^^^^^ Replaced by the following text: The mechanism defined in this document presumes a certain non-standard behavior of existing/non-document supporting nodes. To use this mechanism all nodes MUST have the extensions described in this document for compatibility. - Section 5, typo s/It's a local police decision/It's a local policy decision ^^^^^^ Accepted. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain --Boundary_(ID_B4PNyi5+IIXsT6zB9HqgXA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi all,
 
We appreciate Miguel's careful review for this draft! Thanks Miguel!
 
We have updated this draft according to the comments we have received during the IESG LC. The lastest version of this draft has been posted. http://www.ietf.org/id/draft-ietf-ccamp-confirm-data-channel-status-09.txt
 
Please see below for detailed changes.
 
Thanks,
 
Co-authors
 
 

----- Original Message -----
From: Miguel A. Garcia
To: danli@huawei.com ; xuhuiying@huawei.com ; zhangfatai@huawei.com ; snigdho.bardalai@us.fujitsu.com ; julien.meuric@orange-ftgroup.com ; diego.caviglia@ericsson.com ; lberger@labn.net ; Adrian.Farrel@huawei.com
Cc: General Area Review Team
Sent: Thursday, December 10, 2009 6:33 PM
Subject: Gen-ART review of draft-ietf-ccamp-confirm-data-channel-status-08.txt


I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ccamp-confirm-data-channel-status-08.txt
Reviewer: Miguel Garcia <miguel.a.garcia@ericsson.com>
Review Date: 2009-12-10
IETF LC End Date: 2009-12-16
IESG Telechat date: 2009-12-17

Summary: The document is ready for publication as a standards track RFC.


Nits/editorial comments:

In general, I have found problems with the English language. Perhaps you
should get some English native speaker to give a pass to the draft to
increase the readability. Now, let me give you some small details that
you may want to fix:

- The second paragraph of Section 4.1 acknowledges the existence of three
types of Confirm Data Channel Status messages without naming them, but
instead, referring to Section 7.1. In the sake of clarity of the content
that goes in sections 4.1.1, 4.1.2, and 4.1.3, I would suggest to add the
names of the messages to that paragraph, for example:

    Three new messages are defined to check data channel status:
ConfirmDataChannelStatus, ConfirmDataChannelStatusAck,
ConfirmDataChannelStatusNack, which are described in detail in the
following sections. Message Type numbers are found in Section 7.1.

Accepted. The proposed text is adopted.

- In the last paragraph of Section 4.1, I found the text a bit
misleading. This paragraph is describing the generalities that are
applicable to all three types of ConfirmDataChannelStatus messages.
However, the last paragraph reads:

    If the message is a Confirm Data Channel Status message...

Obviously this test only applies to one of the types of messages, so I
would consider more appropriate to move this paragraph to Section 4.1.1,
which describes the Confirm Data Channel Status message.

The last paragraph is moved to the end of Section 4.1.1.

- Section 4.3, at the end of the second paragraph, the text discusses the
Data Channel Status subobject, and the text reads:

    The new subobject MUST be part of Data_Link Class.

I thought this text belongs to Section 4.2, which discusses in detail the
Data Channel Status Subobject.

In Section 4.3, the focus is the Data_Link Class. The last sentence of the second pragraph is trying to tell the reader that how the Data_Link Class is constructed. So we want to keep this sentence as is.

- Section 5, first paragraph. The text is unparsable. It would be easier
to read if it were written in active form and in separated sentences, for
example:

    Adjacent nodes MAY send data channel status confirmation related LMP
messages. Periodical timers or some other events requesting the
confirmation of channel status for the data link may trigger these messages.

Accepted. The proposed text is adopted.

- Section 5, each of the bullet points: I would suggest to give a bit
more of context to the text, by indicating when the action begins. For
example, take the second bullet point; You can start it by saying:

   # Upon reception of a ConfirmDataChannelStatus message, the RECEIVER
MUST extract the data channel status from the message and SHOULD compare....

Accepted. each of the bullet points is changed to:
- Initially, the SENDER constructs....
- Upon reception of a ConfirmDataChannelStatus message, the RECEIVER MUST extract...
- If the RECEIVER is...
- Upon reception of a ConfirmDataChannelStatusAck message, the SENDER MUST compare...

- Expand acronyms at first occurrence, e.g., LSR.
 
Accepted. The following acronyms are expanded at their first occurrence:
LSR, LSP, RSVP-TE.

- Nit in the first paragraph of Section 4.4.

s/This document's defined mechanisms/These document's defined mechanisms
                                      ^^^^^

s/To use this mechanisms/To use these mechanisms

                                 ^^^^^^
Replaced by the following text:
The mechanism defined in this document presumes a certain non-standard behavior of existing/non-document supporting nodes. To use this mechanism all nodes MUST have the extensions described in this document for compatibility.

- Section 5, typo

s/It's a local police decision/It's a local policy decision
                                             ^^^^^^
Accepted.


/Miguel

--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
--Boundary_(ID_B4PNyi5+IIXsT6zB9HqgXA)-- From EROCH@nortel.com Mon Dec 14 06:55:54 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F26A3A684C for ; Mon, 14 Dec 2009 06:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 J41o7bYxDi9Q for ; Mon, 14 Dec 2009 06:55:52 -0800 (PST) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E52E43A6774 for ; Mon, 14 Dec 2009 06:55:51 -0800 (PST) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id nBEEtU214858; Mon, 14 Dec 2009 14:55:30 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_01CA7CCD.7AE2108E" Date: Mon, 14 Dec 2009 09:55:29 -0500 Message-ID: <90243C8A881F8D419D855264D9636F3A02CBBEDC@zcarhxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: Acp6GPawFUdtWRtJR6+uvkEIl38YlACtDNHw References: <4B06FB22.8090301@labn.net> <90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com> <4B2025D3.3090208@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02BC96A4@zcarhxm2.corp.nortel.com> <4B211ED9.30908@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0F95F@zcarhxm2.corp.nortel.com> <4B213E03.70508@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0FCF9@zcarhxm2.corp.nortel.com> <4B214791.3050600@grotto-networking.com> <90243C8A881F8D419D855264D9636F3A02C0FE01@zcarhxm2.corp.nortel.com> From: "Evelyne Roch" To: "Richard Rabbat" Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 14:55:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7CCD.7AE2108E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Richard, =20 The ASON architecture is defined in ITU-T Recommendation G.8080, available free of charge, at the following URL: http://www.itu.int/rec/T-REC-G.8080/en =20 Evelyne ________________________________ From: richard.rabbat@gmail.com [mailto:richard.rabbat@gmail.com] On Behalf Of Richard Rabbat Sent: Thursday, December 10, 2009 11:18 PM To: Roch, Evelyne (CAR:Q840) Cc: Greg Bernstein; CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Evelyne, which specific rfc's are you concerned the draft is not compliant with? Richard. On Thu, Dec 10, 2009 at 11:22 AM, Evelyne Roch wrote: Greg, =20 The dependency is problematic in networks that follow the ASON architecture because of the administrative boundaries. I would like to see implementations that are compliant with this draft and the ASON architecture.=20 =20 Evelyne ________________________________ =09 From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 =09 Sent: Thursday, December 10, 2009 2:10 PM=20 To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 Hi Evelyne, why is this dependency problematic? What are you trying to do and what it the context? =09 Greg =09 Evelyne Roch wrote:=20 Greg,=20 =20 There is a problem in the architecture because the CALL_ATTRIBUTES is carrying group info in the member call, creating a dependency on the members to achieve VCAT signaling. That dependency is problematic in a network with administrative boundaries. =20 Evelyne ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Thursday, December 10, 2009 1:29 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 Hi Evelyne, version 04 published in February of 2008 contained a "Call_Data_Object", with a TLV containing exactly the information and utilizing the same procedures that we are now using with the CALL_ATTRIBUTES object.=20 It was recommended by the WG chairs to use the CALL_ATTRIBUTES object as defined in the MLN-Extensions work rather than defining another "Call_data_object". None of of the procedures were changed from 04.=20 Is there a problem with functionality? We worked very hard to find a technique utilizing existing mechanisms to give some support forthe member sharing scenario. We do not preclude other techniques being used in the future. =09 Greg =09 Evelyne Roch wrote:=20 This liaison was referring to version 04, before the introduction of CALL_ATTRIBUTES in the draft, exactly where the problem is. =20 In the laison 429, the ITU-T agrees to one call per VCG. That is the VCAT call (not addressed in the draft right now). =20 As far as member calls, members could be in same or different calls based on application (for diverse routing -> could be same call, for protection/restoration -> could be different calls). That is the member call used in the draft.=20 =20 The problem is that CALL_ATTRIBUTES is carried in member call signaling when it pertains to the VCG, i.e. VCAT call.=20 =20 Evelyne =20 =20 =20 =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Thursday, December 10, 2009 11:16 AM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 Hi Evelyne, I'll add some text to the requirements section to clarify "common pool" per your request. The "call concept" usage and "member sharing scenario" have been previously discussed, liaised, and resolved with ITU-T.=20 =09 https://datatracker.ietf.org/liaison/415/ =09 It includes: ITU: "Per Question 5: We understand that this draft is only addressing the constituent server layer call; i.e., not the ASON multilayer call supporting call construct. However, we suggest that you do not preclude extensions to use a call in the VCAT layer. =09 CCAMP response: As noted above, this is not precluded. We look forward to future communication from you as you progress this work." =09 Q14 later responded saying they were satisfied with the one call construct: https://datatracker.ietf.org/liaison/429/ Greg =09 Evelyne Roch wrote:=20 Greg, =20 Normally, I would expect the requirements section to be clear enough that it helps define a proper solution mechanism and clearly sets the scope, not the other way around (i.e. you need to read the mechanism to understand how the requirements should be interpreted). =20 My main concern is how the "call concept" is being used with the member sharing scenario, as I mentioned earlier in this thread. The calls (in the draft) are really member calls, not VCAT group calls. But the call attributes contain VCAT group information. I don't want the member call to attribute carry call information for the entire VCAT group. =20 Evelyne ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Wednesday, December 09, 2009 5:34 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 Hi Evelyne, the common pool is a set of potential member signals that have been set up using the mechanisms defined in the draft, particularly the VCAT call procedures. The draft allows these to be "shared" amongst different VCGs over time. Note that at any given point in time a member signal can belong to only one VCG. Note that by the nature of VCAT that these are signals that have the same source and destination. The procedures section makes this fairly clear. =09 Greg =09 =09 =09 Evelyne Roch wrote:=20 Greg, =20 First, I think we need to further clarify the requirements as I'm not sure all the readers will interpret the requirements the same way. What exactly does it mean to be "in a common pool"? =20 Evelyne ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Tuesday, December 08, 2009 1:04 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 Hi Evelyne, the main focus on this work was to support VCGs with diversely routed routed members. We were asked to include the member sharing scenario and formulated a method to accommodate it without significantly increasing the complexity of the messages involved. It seems to us that the solution included in this draft provides sufficient functionality to meet the requirements in the document. Is there a scenario you think is within the scope of the draft that is not addressed? =09 Greg =09 Evelyne Roch wrote:=20 Greg, see below. =09 =20 -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Friday, December 04, 2009 4:09 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group =20 =09 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =09 =09 =20 I'm not sure that we have calls of calls in GMPLS. At the time this was written this wasn't deemed desirable. =20 The model of calls being supported by calls is clearly support by ASON, whether at the same layer (see G.8080 section 6.7) or different layer (section 6.6). I find it highly desirable. =09 =09 Evelyne =09 =09 =20 --=20 =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =09 =20 --=20 =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =09 =20 --=20 =09 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =09 =20 --=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =09 =20 --=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =09 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp =09 =09 ------_=_NextPart_001_01CA7CCD.7AE2108E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Richard,
 
The ASON architecture is defined in=20 ITU-T Recommendation G.8080, available free of charge, at the=20 following URL:
http://www.itu.int/rec/T-= REC-G.8080/en
 
Evelyne

From: richard.rabbat@gmail.com=20 [mailto:richard.rabbat@gmail.com] On Behalf Of Richard=20 Rabbat
Sent: Thursday, December 10, 2009 11:18 = PM
To: Roch,=20 Evelyne (CAR:Q840)
Cc: Greg Bernstein; = CCAMP
Subject: Re:=20 [CCAMP] Working group=20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Evelyne,
which specific rfc's are you concerned the draft = is not=20 compliant with?
Richard.

On Thu, Dec 10, 2009 at 11:22 AM, Evelyne Roch = <eroch@nortel.com>=20 wrote:
Greg,
 
The=20 dependency is problematic in networks that follow the ASON = architecture=20 because of the administrative boundaries. I would like to see = implementations=20 that are compliant with this draft and the ASON architecture.=20
 
Evelyne

From: Greg Bernstein [mailto:gregb@grotto-networking.com] =
Sent:=20 Thursday, December 10, 2009 2:10 PM

To: Roch, Evelyne (CAR:Q840)
Cc: = BRUNGARD,=20 DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working = group=20 = lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, why is this dependency problematic? What are = you trying=20 to do and what it the context?

Greg

Evelyne Roch wrote:=20
Greg,=20
 
There is=20 a problem in the architecture because the CALL_ATTRIBUTES is = carrying group=20 info in the member call, creating a dependency on the members to = achieve=20 VCAT signaling. That dependency is problematic in a network with=20 administrative boundaries.
 
Evelyne

From: Greg Bernstein [mailto:gregb@grotto-networking.com] =
Sent:=20 Thursday, December 10, 2009 1:29 PM
To: Roch, Evelyne=20 (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20 CCAMP
Subject: Re: [CCAMP] Working group=20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi = Evelyne,=20 version 04 published in February of 2008 contained a = "Call_Data_Object",=20 with a TLV containing exactly the information and utilizing the same = procedures that we are now using with the CALL_ATTRIBUTES object. =
It was=20 recommended by the WG chairs to use the CALL_ATTRIBUTES object as = defined in=20 the MLN-Extensions work rather than defining another = "Call_data_object".=20 None of of the procedures were changed from 04.
Is there a = problem with=20 functionality? We worked very hard to find a technique utilizing = existing=20 mechanisms to give some support forthe member sharing scenario. We = do not=20 preclude other techniques being used in the=20 future.

Greg

Evelyne Roch wrote:=20
This=20 liaison was referring to version 04, before the introduction of=20 CALL_ATTRIBUTES in the draft, exactly where the problem=20 is.
 
In the=20 laison 429, the ITU-T agrees to one call per VCG. That is the VCAT = call=20 (not addressed in the draft right now).
 
As far=20 as member calls, members could be in same or different calls based = on=20 application (for diverse routing -> could be same call, for=20 protection/restoration -> could be different calls). That is = the member=20 call used in the draft.
 
The=20 problem is that CALL_ATTRIBUTES is carried in member call = signaling when=20 it pertains to the VCG, i.e. VCAT call.
 
Evelyne
 
 
 
 

From: Greg Bernstein [mailto:gregb@grotto-networking.com] =
Sent:=20 Thursday, December 10, 2009 11:16 AM
To: Roch, Evelyne=20 (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20 CCAMP
Subject: Re: [CCAMP] Working group=20 = lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi=20 Evelyne, I'll add some text to the requirements section to clarify = "common=20 pool" per your request.
The "call concept" usage and "member = sharing=20 scenario" have been previously discussed, liaised, and resolved = with=20 ITU-T. 
https://datatracker.ietf.org/liaison/415/

It includes:
ITU: "Per Question 5:  We understand that this draft is only addressing
the
constituent server layer call; i.e., not the ASON multilayer call
supporting call construct. However, we suggest that you do not preclude
extensions to use a call in the VCAT layer.

CCAMP response: As noted above, this is not precluded. We look forward =
to
future communication from you as you progress this work."

Q14 later responded saying they were satisfied with the one call
construct:
https://datatracker.ietf.org/liaison/429/
Greg
Evelyne=20 Roch wrote:=20
Greg,
 
Normally, I would expect the requirements section to be = clear=20 enough that it helps define a proper solution mechanism and = clearly sets=20 the scope, not the other way around (i.e. you need to read the = mechanism=20 to understand how the requirements should be=20 interpreted).
 
My=20 main concern is how the "call concept" is being used with = the=20 member sharing scenario, as I mentioned earlier in this thread. = The=20 calls (in the draft) are really member calls, not VCAT group=20 calls. But the call attributes contain VCAT group = information. I=20 don't want the  member call to attribute carry call=20 information for the entire VCAT group.
 
Evelyne

From: Greg Bernstein [mailto:gregb@grotto-networking.com] =
Sent:=20 Wednesday, December 09, 2009 5:34 PM
To: Roch, Evelyne = (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20 CCAMP
Subject: Re: [CCAMP] Working group=20 = lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi=20 Evelyne, the common pool is a set of potential member signals = that have=20 been set up using the mechanisms defined in the draft, = particularly the=20 VCAT call procedures. The draft allows these to be "shared" = amongst=20 different VCGs over time. Note that at any given point in time a = member=20 signal can belong to only one VCG. Note that by the nature of = VCAT that=20 these are signals that have the same source and destination. The = procedures section makes this fairly=20 clear.

Greg



Evelyne Roch wrote:=20
Greg,
 
First, I think we need to further clarify the = requirements as=20 I'm not sure all the readers will interpret = the requirements the=20 same way. What exactly does it mean to be "in a common=20 pool"?
 
Evelyne

From: Greg Bernstein [mailto:gregb@grotto-networking.com] =
Sent:=20 Tuesday, December 08, 2009 1:04 PM
To: Roch, Evelyne = (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS);=20 CCAMP
Subject: Re: [CCAMP] Working group=20 = lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi=20 Evelyne, the main focus on this work was to support VCGs with=20 diversely routed routed members. We were asked to include the = member=20 sharing scenario and formulated a method to accommodate it = without=20 significantly increasing the complexity of the messages=20 involved.  It seems to us that the solution included in = this=20 draft provides sufficient functionality to meet the = requirements in=20 the document. Is there a scenario you think is within the = scope of the=20 draft that is not addressed?

Greg

Evelyne Roch = wrote:=20 
Greg, see below.

  
-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20
Sent: Friday, December 04, 2009 4:09 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
    
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

<snip>

  
I'm not sure that we have =
calls of calls in GMPLS. At the time this
was written this wasn't deemed desirable.
    
The model of calls being supported by calls =
is clearly support by ASON,
whether at the same layer (see G.8080 section 6.7) or different layer
(section 6.6). I find it highly desirable.

<snip>

Evelyne


  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

  

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

_____________________________________________= __
CCAMP=20 mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp


------_=_NextPart_001_01CA7CCD.7AE2108E-- From Lyong@Ciena.com Mon Dec 14 09:27:50 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F1A3A67EE for ; Mon, 14 Dec 2009 09:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=1.116, BAYES_00=-2.599, HTML_MESSAGE=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 wXKpNGNX1u1K for ; Mon, 14 Dec 2009 09:27:49 -0800 (PST) Received: from hicks.ciena.com (hicks.ciena.com [63.118.34.22]) by core3.amsl.com (Postfix) with ESMTP id 75A433A67E2 for ; Mon, 14 Dec 2009 09:27:48 -0800 (PST) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Dec 2009 12:26:39 -0500 Content-Type: multipart/related; boundary="----=_NextPart_000_32FD_01CA7CB8.B057A100" Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD901390978@mdmxm03.ciena.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Local Connection Type Thread-Index: Acp84phsKiCJbWXZTuO2s41b6sjddQ== From: "Ong, Lyndon" Importance: normal Priority: normal To: Subject: [CCAMP] Local Connection Type X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 17:27:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_32FD_01CA7CB8.B057A100 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA7CE2.99078F06" ------_=_NextPart_001_01CA7CE2.99078F06 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Folks, =20 Can we start up a thread on the proposal for Local Connection Type in draft-theillaud-gmpls-ason-routing-add-fcts-01.txt? =20 I would also like to start up a thread on the layer-scoped attributes proposal in that draft, but as a second step since that is a more complex issue. =20 draft-theillaud-gmpls-ason-routing-add-fcts-01.txt proposes that an additional link attribute for GMPLS routing be defined that identifies if the far end interface of the link supports access to its switching function (which may be specific to a particular layer). If access is not supported, then the link would be pruned from the topology for computation of paths that do not terminate at the far end node (i.e., would transit through the far end node). =20 This functionality has been previously identified in ITU-T Recommendation G.7715.1 as local connection type. =20 One possible method is to use the presence or absence of the ISCD to imply whether or not switching is supported, however two cases have come up where this may not be sufficient: =20 It is very possible that a switch could be constrained by policy to support only termination of connections and not access to its switching function. An example might be a carrier switch located on customer premises. If this switch (switch X) is connected by links to two other switches A and B as in the topology A----X----B, then from a topology standpoint it looks like you could switch connections through X, however this is not allowed by policy. If no ISCD is advertised by X for the link, it sounds from reading of RFC 4202 section 2.4 that the absence of the ISCD completely is interpreted as support of packet switching capability, which would not be correct in this case. No information would be provided as to what types of signals could be terminated at the far end. =20 Another case is a switch that supports termination of high order VC-4 and switching of low order VC-3, but not directly switching of VC-4. ISCD for VC-3 and VC-4 could be advertised, but this does not distinguish the case from the case where the switch has both VC-3 and VC-4 capability in its fabric. ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection.=20 =20 Addition of a link attribute that explicitly identifies when access to switching at a particular signal type is supported would support the missing functionality. =20 Comments welcome. =20 Cheers, =20 Lyndon ------_=_NextPart_001_01CA7CE2.99078F06 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

Can we start up a thread on the proposal for Local Connection Type in = draft-theillaud-gmpls-ason-routing-add-fcts-01.txt?

 

I would also like to start up a thread on the = layer-scoped attributes proposal in that draft, but as a second step since that is a = more complex issue.

 

draft-theillaud-gmpls-ason-routing-add-fcts-01.txt = proposes that an additional link attribute for GMPLS routing be defined that = identifies if the far end interface of the link supports access to its switching = function (which may be specific to a particular layer).  If access is not supported, then the link would be pruned from the topology for = computation of paths that do not terminate at the far end node (i.e., would transit = through the far end node).

 

This functionality has been previously identified = in ITU-T Recommendation G.7715.1 as local connection type.

 

One possible method is to use the presence or = absence of the ISCD to imply whether or not switching is supported, however two cases = have come up where this may not be sufficient:

 

It is very = possible that a switch could be constrained by policy to support only termination of connections and not access to its switching function.  An example = might be a carrier switch located on customer premises.  If this switch = (switch X) is connected by links to two other switches A and B as in the topology   A----X----B, then from a topology standpoint it = looks like you could switch connections through X, however this is not allowed by policy.  If no ISCD is advertised by X for the link, it sounds from reading of RFC 4202 section 2.4 that the absence of the ISCD completely = is interpreted as support of packet switching capability, which would not = be correct in this case.  No information would be provided as to what = types of signals could be terminated at the far end.

 

 Another = case is a switch that supports termination of high order VC-4 and switching of low = order VC-3, but not directly switching of VC-4.  ISCD for VC-3 and VC-4 = could be advertised, but this does not distinguish the case from the case where = the switch has both VC-3 and VC-4 capability in its fabric.  ISCD for = VC-3 could be advertised, but this does not distinguish the case where the = switch only supports VC-3 connection.

 

Addition of a link attribute that explicitly = identifies when access to switching at a particular signal type is supported would = support the missing functionality.

 

Comments welcome.

 

Cheers,

 

Lyndon




------_=_NextPart_001_01CA7CE2.99078F06-- ------=_NextPart_000_32FD_01CA7CB8.B057A100 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------=_NextPart_000_32FD_01CA7CB8.B057A100-- From root@core3.amsl.com Mon Dec 14 11:15:08 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D1A743A6A27; Mon, 14 Dec 2009 11:15:06 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091214191506.D1A743A6A27@core3.amsl.com> Date: Mon, 14 Dec 2009 11:15:06 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D ACTION:draft-ietf-ccamp-gmpls-mln-extensions-10.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 19:15:08 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) Author(s) : D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, J. Le Roux Filename : draft-ietf-ccamp-gmpls-mln-extensions-10.txt Pages : 24 Date : 2009-12-14 There are specific requirements for the support of networks comprising Label Switching Routers (LSR) participating in different data plane switching layers controlled by a single Generalized Multi Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks/ Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi- Layer/Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple LSP regions or layers within a single TE domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-extensions-10.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-mln-extensions-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-14110138.I-D@ietf.org> --NextPart-- From db3546@att.com Mon Dec 14 11:57:50 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B634E3A6855 for ; Mon, 14 Dec 2009 11:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.397 X-Spam-Level: X-Spam-Status: No, score=-106.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 MKgq-C5fmOlo for ; Mon, 14 Dec 2009 11:57:36 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 640C23A681A for ; Mon, 14 Dec 2009 11:57:36 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1260820641!37448528!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 31277 invoked from network); 14 Dec 2009 19:57:22 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-6.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Dec 2009 19:57:22 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBEJvHYK017387 for ; Mon, 14 Dec 2009 14:57:17 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBEJvFXZ017377 for ; Mon, 14 Dec 2009 14:57:15 -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_01CA7CF7.A3D80ADE" Date: Mon, 14 Dec 2009 14:57:18 -0500 Message-ID: In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2B83911861A2@EX-NAP.tellabs-west.tellabsinc.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP]Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Thread-Index: Acp5zG1NJLPkW2faTuW3ttuQEjyXZAAAHU9gADN/TAAAk1YTcA== References: <4B06FB22.8090301@labn.net><5292FFA96EC22A4386067E9DBCC0CD2B838FD38B40@EX-NAP.tellabs-west.tellabsinc.net><4B170AF8.1080900@grotto-networking.com><90243C8A881F8D419D855264D9636F3A029F37B1@zcarhxm2.corp.nortel.com><90243C8A881F8D419D855264D9636F3A02A3D2D6@zcarhxm2.corp.nortel.com><4B197A79.1020301@grotto-networking.com><90243C8A881F8D419D855264D9636F3A02A3D956@zcarhxm2.corp.nortel.com><4B1E9508.1010502@grotto-networking.com><90243C8A881F8D419D855264D9636F3A02BC8AA1@zcarhxm2.corp.nortel.com><4B2025D3.3090208@grotto-networking.com><90243C8A881F8D419D855264D9636F3A02BC96A4@zcarhxm2.corp.nortel.com><4B211ED9.30908@grotto-networking.com><90243C8A881F8D419D855264D9636F3A02C0F95F@zcarhxm2.corp.nortel.com><4B213E03.70508@grotto-networking.com><90243C8A881F8D419D855264D9636F3A02C0FCF9@zcarhxm2.corp.nortel.com><4B214791.3! 050600@gr otto -network ing.com><902 43C8A881F8D419D855264D9636F3A02C0FE01@zcarhxm2.corp.nortel.com> <5292FFA96EC22A4386067E9DBCC0CD2B83911861A2@EX-NAP.tellabs-west.tellabsinc.net> From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "Sadler, Jonathan B." , "Evelyne Roch" , "Greg Bernstein" Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 19:57:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7CF7.A3D80ADE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jonathan and Evelyne, =20 As Greg has noted, this discussion is repeating previous discussions both on the mailing list and liaisons. The conclusion was as Greg has already noted - the scenarios below are outside the scope of this document. =20 Specifically, this ccamp response to OIF covers your comments on the use of separate signaling exchanges and your concerns on e-2-e transport of signaling information: https://ops.ietf.org/lists/ccamp/ccamp.2008/msg00741.html =20 Several liaisons were with ITU covering your comments, including: https://datatracker.ietf.org/liaison/415/ https://datatracker.ietf.org/liaison/468/ =20 If you have specific wording proposals for this document, please provide them so as to help the editor complete the last call revisions and progress the document. =20 Regards, Deborah =20 =20 =20 From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Sadler, Jonathan B. Sent: Friday, December 11, 2009 2:49 PM To: Evelyne Roch; Greg Bernstein Cc: CCAMP Subject: Re: [CCAMP]Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =20 Hi Greg, =20 There have been a number of different liaisons from ITU that have talked about the separation of control plane instances on a layer-by-layer basis and the limits this places on what signaling information can be carried by the other instance. Three that are quite pertinent to this discussion are as follows: https://datatracker.ietf.org/documents/LIAISON/file537.pdf - states "VCAT is viewed as a layer of its own and has its own call controller. As per the interlayer architecture in G.8080 section 6.6, the VCAT call would be associated with a server layer call or calls, each of which would have/own one or more server layer connections. It is these connections that are part of the VCG. " https://datatracker.ietf.org/documents/LIAISON/file419.doc - states "signalling messages are always scoped to a specific layer - the information elements in the server layer signalling messages are specific to the server layer (e.g. containing only server layer resources in the ERO) and the information elements in the client layer signalling messages are specific to the client layer (e.g. containing only client layer resources in the ERO)." https://datatracker.ietf.org/documents/LIAISON/file432.doc - states "if two layers are under different administrative domains because they belong to two different providers, the amount of information that can be shared between the two domains is more limited than in the case where a single provider network provides resources at all layers" =20 As pointed out by Evelyne, the MLN/MRN drafts/RFCs place the CALL_ATTRIBUTES object in the server layer (i.e. STS/VC) signaling messages, while it is being used to carry client layer (i.e. VCAT) detail. This is the piggybacking issue (i.e. carrying client layer data in the server layer signaling) that I referenced in the comment I made earlier. =20 Why is this not good? Well, if the client layer and server layer are in different control contexts, it becomes unsafe to assume what service the other control context will provide. For example: - the client layer could be using a control plane protocol while the server layer is being manually/statically configured - the client layer doesn't have access to the information being exchanged by a server layer control plane instance - the server layer network utilizes a control plane protocol other than one specified by the IETF - the server layer network's policy is to not allow the passing of arbitrary data in its control plane =20 In all of these cases, the CALL_ATTRIBUTES object would not make it between the endpoints, causing the VCAT to not be established. =20 This sort of separation information has been provided in other IETF protocols (e.g. T-LDP used for PW setup - it's separate from the RSVP-TE setup done in for the Tunnel LSP) - we're just looking for the same sort of separation to be provided for inverse multiplexing configuration mechanisms. =20 Jonathan Sadler =20 =20 ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Evelyne Roch Sent: Thursday, December 10, 2009 1:22 PM To: Greg Bernstein Cc: CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =20 Greg, =20 The dependency is problematic in networks that follow the ASON architecture because of the administrative boundaries. I would like to see implementations that are compliant with this draft and the ASON architecture.=20 =20 Evelyne =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Thursday, December 10, 2009 2:10 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi Evelyne, why is this dependency problematic? What are you trying to do and what it the context? Greg Evelyne Roch wrote:=20 Greg,=20 =20 There is a problem in the architecture because the CALL_ATTRIBUTES is carrying group info in the member call, creating a dependency on the members to achieve VCAT signaling. That dependency is problematic in a network with administrative boundaries. =20 Evelyne =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Thursday, December 10, 2009 1:29 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi Evelyne, version 04 published in February of 2008 contained a "Call_Data_Object", with a TLV containing exactly the information and utilizing the same procedures that we are now using with the CALL_ATTRIBUTES object.=20 It was recommended by the WG chairs to use the CALL_ATTRIBUTES object as defined in the MLN-Extensions work rather than defining another "Call_data_object". None of of the procedures were changed from 04.=20 Is there a problem with functionality? We worked very hard to find a technique utilizing existing mechanisms to give some support forthe member sharing scenario. We do not preclude other techniques being used in the future. Greg Evelyne Roch wrote:=20 This liaison was referring to version 04, before the introduction of CALL_ATTRIBUTES in the draft, exactly where the problem is. =20 In the laison 429, the ITU-T agrees to one call per VCG. That is the VCAT call (not addressed in the draft right now). =20 As far as member calls, members could be in same or different calls based on application (for diverse routing -> could be same call, for protection/restoration -> could be different calls). That is the member call used in the draft.=20 =20 The problem is that CALL_ATTRIBUTES is carried in member call signaling when it pertains to the VCG, i.e. VCAT call.=20 =20 Evelyne =20 =20 =20 =20 =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Thursday, December 10, 2009 11:16 AM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi Evelyne, I'll add some text to the requirements section to clarify "common pool" per your request. The "call concept" usage and "member sharing scenario" have been previously discussed, liaised, and resolved with ITU-T.=20 https://datatracker.ietf.org/liaison/415/ =20 It includes: ITU: "Per Question 5: We understand that this draft is only addressing the constituent server layer call; i.e., not the ASON multilayer call supporting call construct. However, we suggest that you do not preclude extensions to use a call in the VCAT layer. =20 CCAMP response: As noted above, this is not precluded. We look forward to future communication from you as you progress this work." =20 Q14 later responded saying they were satisfied with the one call construct: https://datatracker.ietf.org/liaison/429/ Greg Evelyne Roch wrote:=20 Greg, =20 Normally, I would expect the requirements section to be clear enough that it helps define a proper solution mechanism and clearly sets the scope, not the other way around (i.e. you need to read the mechanism to understand how the requirements should be interpreted). =20 My main concern is how the "call concept" is being used with the member sharing scenario, as I mentioned earlier in this thread. The calls (in the draft) are really member calls, not VCAT group calls. But the call attributes contain VCAT group information. I don't want the member call to attribute carry call information for the entire VCAT group. =20 Evelyne =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Wednesday, December 09, 2009 5:34 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi Evelyne, the common pool is a set of potential member signals that have been set up using the mechanisms defined in the draft, particularly the VCAT call procedures. The draft allows these to be "shared" amongst different VCGs over time. Note that at any given point in time a member signal can belong to only one VCG. Note that by the nature of VCAT that these are signals that have the same source and destination. The procedures section makes this fairly clear. Greg Evelyne Roch wrote:=20 Greg, =20 First, I think we need to further clarify the requirements as I'm not sure all the readers will interpret the requirements the same way. What exactly does it mean to be "in a common pool"? =20 Evelyne =20 ________________________________ From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Tuesday, December 08, 2009 1:04 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 Hi Evelyne, the main focus on this work was to support VCGs with diversely routed routed members. We were asked to include the member sharing scenario and formulated a method to accommodate it without significantly increasing the complexity of the messages involved. It seems to us that the solution included in this draft provides sufficient functionality to meet the requirements in the document. Is there a scenario you think is within the scope of the draft that is not addressed? Greg Evelyne Roch wrote:=20 Greg, see below. =20 =20 -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Friday, December 04, 2009 4:09 PM To: Roch, Evelyne (CAR:Q840) Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP Subject: Re: [CCAMP] Working group =20 lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08 =20 =20 =20 I'm not sure that we have calls of calls in GMPLS. At the time this was written this wasn't deemed desirable. =20 =20 The model of calls being supported by calls is clearly support by ASON, whether at the same layer (see G.8080 section 6.7) or different layer (section 6.6). I find it highly desirable. =20 =20 Evelyne =20 =20 =20 =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =20 =20 =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =20 =20 =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =20 =20 =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =20 =20 =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =20 ------_=_NextPart_001_01CA7CF7.A3D80ADE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jonathan and Evelyne,

 

As Greg has noted, this discussion is repeating previous discussions both on the mailing list and liaisons. The conclusion was as = Greg has already noted  – the scenarios below are outside the = scope of this document.

 

Specifically, this ccamp response to OIF covers your = comments on the use of separate signaling exchanges and your concerns on e-2-e = transport of signaling information:

https:= //ops.ietf.org/lists/ccamp/ccamp.2008/msg00741.html=

 

 Several liaisons were with ITU covering your = comments, including:

https://datatracker.ie= tf.org/liaison/415/

https://datatracker.ie= tf.org/liaison/468/

 

If you have specific wording proposals for this document, = please provide them so as to help the editor complete the last call revisions = and progress the document.

 

Regards,

Deborah

 

 

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Sadler, Jonathan = B.
Sent: Friday, December 11, 2009 2:49 PM
To: Evelyne Roch; Greg Bernstein
Cc: CCAMP
Subject: Re: [CCAMP]Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

 

Hi Greg,

 

There have been a number of different liaisons from ITU that = have talked about the separation of control plane instances on a = layer-by-layer basis and the limits this places on what signaling information can be = carried by the other instance.  Three that are quite pertinent to this = discussion are as follows:

  https://datatracker.ietf.org/d=
ocuments/LIAISON/file537.pdf - states =
“VCAT is =
viewed as a layer of its own and has its own call controller. As per the =
interlayer architecture in G.8080 section 6.6, the VCAT call =
would be associated with a server layer =
call or calls, each of which would have/own one or more server layer =
connections.  It is these connections that are part of the =
VCG. =
“<=
/span>

  http= s://datatracker.ietf.org/documents/LIAISON/file419.doc - states “signalling messages are always scoped to a = specific layer – the information elements in the server layer signalling = messages are specific to the server layer (e.g. containing only server layer = resources in the ERO) and the information elements in the client layer signalling messages are specific to the client layer (e.g. containing only client = layer resources in the ERO).“

  http= s://datatracker.ietf.org/documents/LIAISON/file432.doc - states “if two layers are under different administrative = domains because they belong to two different providers, the amount of = information that can be shared between the two domains is more limited than in the case = where a single provider network provides resources at all layers“

 
As pointed out by =
Evelyne, the MLN/MRN drafts/RFCs place the CALL_ATTRIBUTES object in the =
server layer (i.e. STS/VC) signaling messages, while it is being used to =
carry client layer (i.e. VCAT) detail.  This is the piggybacking =
issue (i.e. carrying client layer data in the server layer signaling) =
that I referenced in the comment I made =
earlier.
 
Why is this not =
good?  Well, if the client layer and server layer are in different =
control contexts, it becomes unsafe to assume what service the other =
control context will provide.  For =
example:
 - the client =
layer could be using a control plane protocol while the server layer is =
being manually/statically configured
 - the client =
layer doesn’t have access to the information being exchanged by a =
server layer control plane instance
 - the server =
layer network utilizes a control plane protocol other than one specified =
by the IETF
 - the server =
layer network’s policy is to not allow the passing of arbitrary =
data in its control plane
 
In all of these =
cases, the CALL_ATTRIBUTES object would not make it between the =
endpoints, causing the VCAT to not be =
established.
 
This sort of =
separation information has been provided in other IETF protocols (e.g. =
T-LDP used for PW setup – it’s separate from the RSVP-TE =
setup done in for the Tunnel LSP) – we’re just looking for =
the same sort of separation to be provided for inverse multiplexing =
configuration mechanisms.
 
Jonathan =
Sadler

 

 

From: ccamp-bounces@ietf.org = [mailto:ccamp-bounces@ietf.org] On Behalf Of Evelyne Roch
Sent: Thursday, December 10, 2009 1:22 PM
To: Greg Bernstein
Cc: CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

 

Greg,

 

The dependency is problematic in networks that follow the = ASON architecture because of the administrative boundaries. I would like to = see implementations that are compliant with this draft and the ASON = architecture.

 

Evelyne

 

From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Thursday, December 10, 2009 2:10 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, why is this dependency problematic? = What are you trying to do and what it the context?

Greg

Evelyne Roch wrote:

Greg,

 

There is a problem in the architecture because the = CALL_ATTRIBUTES is carrying group info in the member call, creating a dependency on the = members to achieve VCAT signaling. That dependency is problematic in a network = with administrative boundaries.

 

Evelyne

 

From: Greg Bernstein [mailto:gregb@grotto-networkin= g.com]
Sent: Thursday, December 10, 2009 1:29 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, version 04 published in February of = 2008 contained a "Call_Data_Object", with a TLV containing exactly = the information and utilizing the same procedures that we are now using with = the CALL_ATTRIBUTES object.
It was recommended by the WG chairs to use the CALL_ATTRIBUTES object as defined in the MLN-Extensions work rather than defining another "Call_data_object". None of of the procedures were changed = from 04.
Is there a problem with functionality? We worked very hard to find a = technique utilizing existing mechanisms to give some support forthe member sharing scenario. We do not preclude other techniques being used in the = future.

Greg

Evelyne Roch wrote:

This liaison was referring to version 04, before the = introduction of CALL_ATTRIBUTES in the draft, exactly where the problem = is.

 

In the laison 429, the ITU-T agrees to one call per VCG. = That is the VCAT call (not addressed in the draft right = now).

 

As far as member calls, members could be in same or = different calls based on application (for diverse routing -> could be same call, for protection/restoration -> could be different calls). That is the = member call used in the draft.

 

The problem is that CALL_ATTRIBUTES is carried in member = call signaling when it pertains to the VCG, i.e. VCAT call. =

 

Evelyne

 

 

 

 

 

From: Greg Bernstein [mailto:gregb@grotto-networkin= g.com]
Sent: Thursday, December 10, 2009 11:16 AM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, I'll add = some text to the requirements section to clarify "common pool" per your request.
The "call concept" usage and "member sharing = scenario" have been previously discussed, liaised, and resolved with ITU-T. = 

https://datatracker.ie=
tf.org/liaison/415/
 
=
It includes:
ITU: "Per Question 5:  We =
understand that this draft is only =
addressing
the
constituent =
server layer call; i.e., not the ASON multilayer =
call
supporting call construct. However, we suggest =
that you do not preclude
extensions to use a call =
in the VCAT =
layer.
 
CCAMP response: =
As noted above, this is not precluded. We look forward =
to
future communication from you as you progress =
this work."
 
Q14 =
later responded saying they were satisfied with the one =
call
construct:
https://datatracker.ie=
tf.org/liaison/429/

Greg

Evelyne Roch wrote:

Greg,

 

Normally, I would expect the requirements section to be = clear enough that it helps define a proper solution mechanism and clearly sets = the scope, not the other way around (i.e. you need to read the mechanism to understand how the requirements should be = interpreted).

 

My main concern is how the "call concept" is = being used with the member sharing scenario, as I mentioned earlier in this = thread. The calls (in the draft) are really member calls, not VCAT group calls. But the call attributes contain VCAT group information. I = don't want the  member call to attribute carry call information for = the entire VCAT group.

 

Evelyne

 

From: Greg Bernstein [mailto:gregb@grotto-networkin= g.com]
Sent: Wednesday, December 09, 2009 5:34 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, the common pool is a set of potential = member signals that have been set up using the mechanisms defined in the draft, particularly the VCAT call procedures. The draft allows these to be "shared" amongst different VCGs over time. Note that at any = given point in time a member signal can belong to only one VCG. Note that by = the nature of VCAT that these are signals that have the same source and = destination. The procedures section makes this fairly clear.

Greg



Evelyne Roch wrote:

Greg,

 

First, I think we need to further clarify the requirements = as I'm not sure all the readers will interpret the requirements the same = way. What exactly does it mean to be "in a common = pool"?

 

Evelyne

 

From: Greg Bernstein [mailto:gregb@grotto-networkin= g.com]
Sent: Tuesday, December 08, 2009 1:04 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Evelyne, the main focus on this work was to = support VCGs with diversely routed routed members. We were asked to include the = member sharing scenario and formulated a method to accommodate it without significantly increasing the complexity of the messages involved.  = It seems to us that the solution included in this draft provides sufficient functionality to meet the requirements in the document. Is there a = scenario you think is within the scope of the draft that is not addressed?

Greg

Evelyne Roch wrote: 

Greg, see =
below.
 
  =

-----Original =
Message-----
From: Greg Bernstein [mailto:gregb@grotto-networkin=
g.com] 
Sent: Friday, December 04, 2009 4:09 =
PM
To: Roch, Evelyne =
(CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); =
CCAMP
Subject: Re: [CCAMP] Working =
group
    =

lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
 
<snip>
 
  
I'm not =
sure that we have calls of calls in GMPLS. At the time =
this
was written this wasn't deemed =
desirable.
    =

 
The model of calls being supported by =
calls is clearly support by ASON,
whether at the =
same layer (see G.8080 section 6.7) or different =
layer
(section 6.6). I find it highly =
desirable.
 
<snip><=
o:p>
 
Evelyne
= 
 
 
  =

 

-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, =
Grotto Networking (510) =
573-2237
 
  =

 

-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, =
Grotto Networking (510) =
573-2237
 
  =

 

-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, =
Grotto Networking (510) =
573-2237
 
  =

 

-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, =
Grotto Networking (510) =
573-2237
 
  =

 

-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, =
Grotto Networking (510) =
573-2237
 
------_=_NextPart_001_01CA7CF7.A3D80ADE-- From root@core3.amsl.com Tue Dec 15 05:00:02 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 226FE3A69FC; Tue, 15 Dec 2009 05:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091215130002.226FE3A69FC@core3.amsl.com> Date: Tue, 15 Dec 2009 05:00:02 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 13:00:02 -0000 --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) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks Author(s) : W. Sun, et al. Filename : draft-ietf-ccamp-lsp-dppm-11.txt Pages : 52 Date : 2009-12-15 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. The 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 areas. 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 Label Switched Path (LSP) provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 17, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-11.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-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-15044946.I-D@ietf.org> --NextPart-- From Dimitri.Papadimitriou@alcatel-lucent.com Wed Dec 16 09:34:54 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C12F3A6977 for ; Wed, 16 Dec 2009 09:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.864 X-Spam-Level: X-Spam-Status: No, score=-3.864 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] 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 b+xUO2SDww7j for ; Wed, 16 Dec 2009 09:34:53 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 7DCD83A682C for ; Wed, 16 Dec 2009 09:34:51 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nBGHYW64020808; Wed, 16 Dec 2009 18:34:32 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 16 Dec 2009 18:34:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA7E76.06B9E45F" Date: Wed, 16 Dec 2009 18:34:31 +0100 Message-ID: <00275A5B436CA441900CB10936742A38039FBF6E@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <0AFD1B67B949784DA087CDA9F0DD4AD901390978@mdmxm03.ciena.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Local Connection Type Thread-Index: Acp84phsKiCJbWXZTuO2s41b6sjddQBkfQbw References: <0AFD1B67B949784DA087CDA9F0DD4AD901390978@mdmxm03.ciena.com> From: "PAPADIMITRIOU Dimitri" To: "Ong, Lyndon" , X-OriginalArrivalTime: 16 Dec 2009 17:34:32.0154 (UTC) FILETIME=[06F683A0:01CA7E76] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: Re: [CCAMP] Local Connection Type X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 17:34:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7E76.06B9E45F Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA7E76.06B9E45F" ------_=_NextPart_002_01CA7E76.06B9E45F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lyndon, =20 for the case a) One sets the SC to lower SC capability value (on X ends, using the Figure). The Max and Min LSP Bw tells the range of "signals" that can be terminated. =20 for the case b) you stated "ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection." In this case, setting Min LSP Bw =3D VC3 and Max LSP Bw =3D = VC4 and Min LSP Bw =3D VC3 and Max LSP Bw =3D VC3 allows that "distinction" = and you can advertized two separate ISCD's for this purpose. The structure of the mux.tree being implicit I am not sure to see the issue.=20 =20 Hope this helps, -dimitri. ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Ong, Lyndon Sent: Monday, December 14, 2009 6:27 PM To: ccamp@ietf.org Subject: [CCAMP] Local Connection Type =09 =09 Hi Folks, =20 Can we start up a thread on the proposal for Local Connection Type in draft-theillaud-gmpls-ason-routing-add-fcts-01.txt? =20 I would also like to start up a thread on the layer-scoped attributes proposal in that draft, but as a second step since that is a more complex issue. =20 draft-theillaud-gmpls-ason-routing-add-fcts-01.txt proposes that an additional link attribute for GMPLS routing be defined that identifies if the far end interface of the link supports access to its switching function (which may be specific to a particular layer). If access is not supported, then the link would be pruned from the topology for computation of paths that do not terminate at the far end node (i.e., would transit through the far end node). =20 This functionality has been previously identified in ITU-T Recommendation G.7715.1 as local connection type. =20 One possible method is to use the presence or absence of the ISCD to imply whether or not switching is supported, however two cases have come up where this may not be sufficient: =20 It is very possible that a switch could be constrained by policy to support only termination of connections and not access to its switching function. An example might be a carrier switch located on customer premises. If this switch (switch X) is connected by links to two other switches A and B as in the topology A----X----B, then from a topology standpoint it looks like you could switch connections through X, however this is not allowed by policy. If no ISCD is advertised by X for the link, it sounds from reading of RFC 4202 section 2.4 that the absence of the ISCD completely is interpreted as support of packet switching capability, which would not be correct in this case. No information would be provided as to what types of signals could be terminated at the far end. =20 Another case is a switch that supports termination of high order VC-4 and switching of low order VC-3, but not directly switching of VC-4. ISCD for VC-3 and VC-4 could be advertised, but this does not distinguish the case from the case where the switch has both VC-3 and VC-4 capability in its fabric. ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection.=20 =20 Addition of a link attribute that explicitly identifies when access to switching at a particular signal type is supported would support the missing functionality. =20 Comments welcome. =20 Cheers, =20 Lyndon =20 =09 =09 ------_=_NextPart_002_01CA7E76.06B9E45F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Lyndon,
 
for the case a) One sets the SC to lower SC capability value = (on X ends,=20 using the Figure). The Max and Min LSP Bw tells the range of "signals" = that can=20 be terminated.
 
for the case b) you stated "ISCD for VC-3 could be advertised, = but this=20 does not distinguish the case where the switch only supports VC-3 = connection."=20 In this case, setting Min LSP Bw =3D VC3 and Max LSP Bw =3D = VC4 and Min LSP=20 Bw =3D VC3 and Max LSP Bw =3D VC3 allows that "distinction" and you can = advertized=20 two separate ISCD's for this purpose. The structure of the mux.tree = being=20 implicit I am not sure to see the issue.
 
Hope this helps,
-dimitri.

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of Ong,=20 Lyndon
Sent: Monday, December 14, 2009 6:27 PM
To: = ccamp@ietf.org
Subject: [CCAMP] Local Connection=20 Type

Hi Folks,

 

Can we start up a thread on the proposal for = Local=20 Connection Type in=20 draft-theillaud-gmpls-ason-routing-add-fcts-01.txt?

 

I would also like to start up a thread on the = layer-scoped=20 attributes proposal in that draft, but as a second step since that is = a more=20 complex issue.

 

draft-theillaud-gmpls-ason-routing-add-fcts-01.txt = proposes=20 that an additional link attribute for GMPLS routing be defined that = identifies=20 if the far end interface of the link supports access to its switching = function=20 (which may be specific to a particular layer).  If access is not=20 supported, then the link would be pruned from the topology for = computation of=20 paths that do not terminate at the far end node (i.e., would transit = through=20 the far end node).

 

This functionality has been previously identified = in ITU-T=20 Recommendation G.7715.1 as local connection type.

 

One possible method is to use the presence or = absence of=20 the ISCD to imply whether or not switching is supported, however two = cases=20 have come up where this may not be sufficient:

 

It is very = possible=20 that a switch could be constrained by policy to support only = termination of=20 connections and not access to its switching function.  An example = might=20 be a carrier switch located on customer premises.  If this switch = (switch=20 X) is connected by links to two other switches A and B as in the=20 topology   A----X----B, then from a topology standpoint it = looks=20 like you could switch connections through X, however this is not = allowed by=20 policy.  If no ISCD is advertised by X for the link, it sounds = from=20 reading of RFC 4202 section 2.4 that the absence of the ISCD = completely is=20 interpreted as support of packet switching capability, which would not = be=20 correct in this case.  No information would be provided as to = what types=20 of signals could be terminated at the far end.

 

 Another case is a=20 switch that supports termination of high order VC-4 and switching of = low order=20 VC-3, but not directly switching of VC-4.  ISCD for VC-3 and VC-4 = could=20 be advertised, but this does not distinguish the case from the case = where the=20 switch has both VC-3 and VC-4 capability in its fabric.  ISCD for = VC-3=20 could be advertised, but this does not distinguish the case where the = switch=20 only supports VC-3 connection.

 

Addition of a link attribute that explicitly = identifies=20 when access to switching at a particular signal type is supported = would=20 support the missing functionality.

 

Comments welcome.

 

Cheers,

 

Lyndon


3D""

------_=_NextPart_002_01CA7E76.06B9E45F-- ------_=_NextPart_001_01CA7E76.06B9E45F Content-Type: image/gif; name="ATT466938.gif" Content-Transfer-Encoding: base64 Content-ID: <262572317@16122009-2D58> Content-Description: ATT466938.gif Content-Location: ATT466938.gif R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------_=_NextPart_001_01CA7E76.06B9E45F-- From Lyong@Ciena.com Wed Dec 16 14:43:07 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8BA13A6A9D for ; Wed, 16 Dec 2009 14:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SARE_GIF_ATTACH=1.42] 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 hkQruecPPmv2 for ; Wed, 16 Dec 2009 14:43:01 -0800 (PST) Received: from ripley.ciena.com (ripley.ciena.com [63.118.34.24]) by core3.amsl.com (Postfix) with ESMTP id AE02C3A6A8F for ; Wed, 16 Dec 2009 14:43:00 -0800 (PST) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA7EA1.162EF1B9" Date: Wed, 16 Dec 2009 17:42:43 -0500 Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD901390E21@mdmxm03.ciena.com> Content-Transfer-Encoding: 7bit In-Reply-To: <00275A5B436CA441900CB10936742A38039FBF6E@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Local Connection Type Thread-Index: Acp84phsKiCJbWXZTuO2s41b6sjddQBkfQbwAAsF37A= References: <0AFD1B67B949784DA087CDA9F0DD4AD901390978@mdmxm03.ciena.com> <00275A5B436CA441900CB10936742A38039FBF6E@FRVELSMBS22.ad2.ad.alcatel.com> Importance: normal Priority: normal From: "Ong, Lyndon" To: "PAPADIMITRIOU Dimitri" , Subject: Re: [CCAMP] Local Connection Type X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 22:43:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7EA1.162EF1B9 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA7EA1.162EF1B9" ------_=_NextPart_002_01CA7EA1.162EF1B9 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Dimitri, =20 Thanks for your response, if there is already a way to do this, that would be great. However, I'm not sure what you mean by "lower SC capability value" - for example, if node X can terminate VC-3 and VC-4 connections but not switch them through, what SC capability would be advertised for its end of the links? I presume "lower" does not mean lower layer, such as lambda capable or fiber capable. =20 Thanks, =20 Lyndon =20 From: PAPADIMITRIOU Dimitri [mailto:Dimitri.Papadimitriou@alcatel-lucent.com]=20 Sent: Wednesday, December 16, 2009 9:35 AM To: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] Local Connection Type =20 Lyndon, =20 for the case a) One sets the SC to lower SC capability value (on X ends, using the Figure). The Max and Min LSP Bw tells the range of "signals" that can be terminated. =20 for the case b) you stated "ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection." In this case, setting Min LSP Bw =3D VC3 and Max LSP Bw =3D = VC4 and Min LSP Bw =3D VC3 and Max LSP Bw =3D VC3 allows that "distinction" = and you can advertized two separate ISCD's for this purpose. The structure of the mux.tree being implicit I am not sure to see the issue.=20 =20 Hope this helps, -dimitri. =20 =09 ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Ong, Lyndon Sent: Monday, December 14, 2009 6:27 PM To: ccamp@ietf.org Subject: [CCAMP] Local Connection Type Hi Folks, =20 Can we start up a thread on the proposal for Local Connection Type in draft-theillaud-gmpls-ason-routing-add-fcts-01.txt? =20 I would also like to start up a thread on the layer-scoped attributes proposal in that draft, but as a second step since that is a more complex issue. =20 draft-theillaud-gmpls-ason-routing-add-fcts-01.txt proposes that an additional link attribute for GMPLS routing be defined that identifies if the far end interface of the link supports access to its switching function (which may be specific to a particular layer). If access is not supported, then the link would be pruned from the topology for computation of paths that do not terminate at the far end node (i.e., would transit through the far end node). =20 This functionality has been previously identified in ITU-T Recommendation G.7715.1 as local connection type. =20 One possible method is to use the presence or absence of the ISCD to imply whether or not switching is supported, however two cases have come up where this may not be sufficient: =20 It is very possible that a switch could be constrained by policy to support only termination of connections and not access to its switching function. An example might be a carrier switch located on customer premises. If this switch (switch X) is connected by links to two other switches A and B as in the topology A----X----B, then from a topology standpoint it looks like you could switch connections through X, however this is not allowed by policy. If no ISCD is advertised by X for the link, it sounds from reading of RFC 4202 section 2.4 that the absence of the ISCD completely is interpreted as support of packet switching capability, which would not be correct in this case. No information would be provided as to what types of signals could be terminated at the far end. =20 Another case is a switch that supports termination of high order VC-4 and switching of low order VC-3, but not directly switching of VC-4. ISCD for VC-3 and VC-4 could be advertised, but this does not distinguish the case from the case where the switch has both VC-3 and VC-4 capability in its fabric. ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection.=20 =20 Addition of a link attribute that explicitly identifies when access to switching at a particular signal type is supported would support the missing functionality. =20 Comments welcome. =20 Cheers, =20 Lyndon =09 =20 ------_=_NextPart_002_01CA7EA1.162EF1B9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Dimitri,

 

Thanks for your = response, if there is already a way to do this, that would be great.  However, = I’m not sure what you mean by “lower SC capability value” = – for example, if node X can terminate VC-3 and VC-4 connections but not switch them = through, what SC capability would be advertised for its end of the links?  I presume “lower” does not mean lower layer, such as lambda = capable or fiber capable.

 

Thanks,

 

Lyndon

 



From: PAPADIMITRIOU Dimitri [mailto:Dimitri.Papadimitriou@alcatel-lucent.com]
Sent: Wednesday, December 16, 2009 9:35 AM
To: Ong, Lyndon; ccamp@ietf.org
Subject: RE: [CCAMP] Local Connection Type

 

Lyndon,

 

for the case a) One sets the SC to lower SC capability = value (on X ends, using the Figure). The Max and Min LSP Bw tells the range of "signals" that can be terminated.

 

for the case b) you stated "ISCD for VC-3 could = be advertised, but this does not distinguish the case where the switch only supports VC-3 connection." In this case, setting Min LSP Bw =3D VC3 = and Max LSP Bw =3D VC4 and Min LSP Bw =3D VC3 and Max LSP Bw =3D VC3 allows = that "distinction" and you can advertized two separate ISCD's for = this purpose. The structure of the mux.tree being implicit I am not sure to = see the issue.

 

Hope this helps,

-dimitri.

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = Ong, Lyndon
Sent: Monday, December 14, 2009 6:27 PM
To: ccamp@ietf.org
Subject: [CCAMP] Local Connection Type

Hi Folks,

 

Can we start up a thread on the proposal for Local Connection Type in = draft-theillaud-gmpls-ason-routing-add-fcts-01.txt?

 

I would also like to start up a thread on the = layer-scoped attributes proposal in that draft, but as a second step since that is a = more complex issue.

 

draft-theillaud-gmpls-ason-routing-add-fcts-01.txt = proposes that an additional link attribute for GMPLS routing be defined that = identifies if the far end interface of the link supports access to its switching = function (which may be specific to a particular layer).  If access is not supported, then the link would be pruned from the topology for = computation of paths that do not terminate at the far end node (i.e., would transit = through the far end node).

 

This functionality has been previously identified = in ITU-T Recommendation G.7715.1 as local connection type.

 

One possible method is to use the presence or = absence of the ISCD to imply whether or not switching is supported, however two cases = have come up where this may not be sufficient:

 

It is very = possible that a switch could be constrained by policy to support only termination of connections and not access to its switching function.  An example = might be a carrier switch located on customer premises.  If this switch = (switch X) is connected by links to two other switches A and B as in the topology   A----X----B, then from a topology standpoint it = looks like you could switch connections through X, however this is not allowed by policy.  If no ISCD is advertised by X for the link, it sounds from reading of RFC 4202 section 2.4 that the absence of the ISCD completely = is interpreted as support of packet switching capability, which would not = be correct in this case.  No information would be provided as to what = types of signals could be terminated at the far end.

 

 Another = case is a switch that supports termination of high order VC-4 and switching of low = order VC-3, but not directly switching of VC-4.  ISCD for VC-3 and VC-4 = could be advertised, but this does not distinguish the case from the case where = the switch has both VC-3 and VC-4 capability in its fabric.  ISCD for = VC-3 could be advertised, but this does not distinguish the case where the = switch only supports VC-3 connection.

 

Addition of a link attribute that explicitly = identifies when access to switching at a particular signal type is supported would = support the missing functionality.

 

Comments welcome.

 

Cheers,

 

Lyndon



------_=_NextPart_002_01CA7EA1.162EF1B9-- ------_=_NextPart_001_01CA7EA1.162EF1B9 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------_=_NextPart_001_01CA7EA1.162EF1B9 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------_=_NextPart_001_01CA7EA1.162EF1B9-- From Dimitri.Papadimitriou@alcatel-lucent.com Wed Dec 16 15:25:48 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0383A68C8 for ; Wed, 16 Dec 2009 15:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] 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 VJzHF90Jxcl1 for ; Wed, 16 Dec 2009 15:25:40 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 430893A67AF for ; Wed, 16 Dec 2009 15:25:39 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nBGNP0ib013263; Thu, 17 Dec 2009 00:25:00 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 00:25:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA7EA6.FC52F4AD" Date: Thu, 17 Dec 2009 00:24:58 +0100 Message-ID: <00275A5B436CA441900CB10936742A38039FBFCE@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <0AFD1B67B949784DA087CDA9F0DD4AD901390E21@mdmxm03.ciena.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Local Connection Type Thread-Index: Acp84phsKiCJbWXZTuO2s41b6sjddQBkfQbwAAsF37AAAFwXIA== References: <0AFD1B67B949784DA087CDA9F0DD4AD901390978@mdmxm03.ciena.com> <00275A5B436CA441900CB10936742A38039FBF6E@FRVELSMBS22.ad2.ad.alcatel.com> <0AFD1B67B949784DA087CDA9F0DD4AD901390E21@mdmxm03.ciena.com> From: "PAPADIMITRIOU Dimitri" To: "Ong, Lyndon" , X-OriginalArrivalTime: 16 Dec 2009 23:25:00.0057 (UTC) FILETIME=[FC91E090:01CA7EA6] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [CCAMP] Local Connection Type X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 23:25:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7EA6.FC52F4AD Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA7EA6.FC52F4AD" ------_=_NextPart_002_01CA7EA6.FC52F4AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lyndon, =20 RFC 4203 defines values associated to SC hence my reference to "lower SC capability value" for instance L2SC (=3D 51), TDM (=3D 100) as lower SC value than LSC (=3D 150). =20 Using your example if VC-3 and VC-4 are both "terminated" they refer to a lower SC value (from X side) - for instance L2SC (if Eth over SDH) or PSC (if IP/MPLS over SDH) and one sets the Min LSP Bw corr. to VC3 and Max LSP Bw corr. to VC-4. So, in this example, X indicates in the ISCD (Switching Capability field) the "upper" SC value.=20 =20 Thanks, -dimitri. ________________________________ From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20 Sent: Wednesday, December 16, 2009 11:43 PM To: PAPADIMITRIOU Dimitri; ccamp@ietf.org Subject: RE: [CCAMP] Local Connection Type =09 =09 Hi Dimitri, =20 Thanks for your response, if there is already a way to do this, that would be great. However, I'm not sure what you mean by "lower SC capability value" - for example, if node X can terminate VC-3 and VC-4 connections but not switch them through, what SC capability would be advertised for its end of the links? I presume "lower" does not mean lower layer, such as lambda capable or fiber capable. =20 Thanks, =20 Lyndon =20 =20 =09 From: PAPADIMITRIOU Dimitri [mailto:Dimitri.Papadimitriou@alcatel-lucent.com]=20 Sent: Wednesday, December 16, 2009 9:35 AM To: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] Local Connection Type =20 Lyndon, =20 for the case a) One sets the SC to lower SC capability value (on X ends, using the Figure). The Max and Min LSP Bw tells the range of "signals" that can be terminated. =20 for the case b) you stated "ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection." In this case, setting Min LSP Bw =3D VC3 and Max LSP = Bw =3D VC4 and Min LSP Bw =3D VC3 and Max LSP Bw =3D VC3 allows that "distinction" and you can advertized two separate ISCD's for this purpose. The structure of the mux.tree being implicit I am not sure to see the issue.=20 =20 Hope this helps, -dimitri. =20 =09 ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Ong, Lyndon Sent: Monday, December 14, 2009 6:27 PM To: ccamp@ietf.org Subject: [CCAMP] Local Connection Type Hi Folks, =20 Can we start up a thread on the proposal for Local Connection Type in draft-theillaud-gmpls-ason-routing-add-fcts-01.txt? =20 I would also like to start up a thread on the layer-scoped attributes proposal in that draft, but as a second step since that is a more complex issue. =20 draft-theillaud-gmpls-ason-routing-add-fcts-01.txt proposes that an additional link attribute for GMPLS routing be defined that identifies if the far end interface of the link supports access to its switching function (which may be specific to a particular layer). If access is not supported, then the link would be pruned from the topology for computation of paths that do not terminate at the far end node (i.e., would transit through the far end node). =20 This functionality has been previously identified in ITU-T Recommendation G.7715.1 as local connection type. =20 One possible method is to use the presence or absence of the ISCD to imply whether or not switching is supported, however two cases have come up where this may not be sufficient: =20 It is very possible that a switch could be constrained by policy to support only termination of connections and not access to its switching function. An example might be a carrier switch located on customer premises. If this switch (switch X) is connected by links to two other switches A and B as in the topology A----X----B, then from a topology standpoint it looks like you could switch connections through X, however this is not allowed by policy. If no ISCD is advertised by X for the link, it sounds from reading of RFC 4202 section 2.4 that the absence of the ISCD completely is interpreted as support of packet switching capability, which would not be correct in this case. No information would be provided as to what types of signals could be terminated at the far end. =20 Another case is a switch that supports termination of high order VC-4 and switching of low order VC-3, but not directly switching of VC-4. ISCD for VC-3 and VC-4 could be advertised, but this does not distinguish the case from the case where the switch has both VC-3 and VC-4 capability in its fabric. ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection.=20 =20 Addition of a link attribute that explicitly identifies when access to switching at a particular signal type is supported would support the missing functionality. =20 Comments welcome. =20 Cheers, =20 Lyndon =09 =20 ------_=_NextPart_002_01CA7EA6.FC52F4AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Lyndon,
 
RFC 4203 defines values associated to SC hence my reference to = “lower SC capability value” for instance = L2SC (=3D 51), TDM (=3D 100)=20 as lower SC value than LSC (=3D 150).
 
Using your example if VC-3 and VC-4 are = both=20 "terminated" they refer to a lower SC value (from X side) - for instance = L2SC=20 (if Eth over SDH) or PSC (if IP/MPLS over SDH) and one = sets the=20 Min LSP Bw corr. to VC3 and Max LSP Bw corr. to VC-4. So, in=20 this example, X indicates in the ISCD (Switching = Capability=20 field) the "upper" SC value. 
 
Thanks,
-dimitri.
=
From: Ong, Lyndon = [mailto:Lyong@Ciena.com]=20
Sent: Wednesday, December 16, 2009 11:43 PM
To:=20 PAPADIMITRIOU Dimitri; ccamp@ietf.org
Subject: RE: [CCAMP] = Local=20 Connection Type

Hi=20 Dimitri,

 

Thanks for your = response, if=20 there is already a way to do this, that would be great.  However, = I’m not=20 sure what you mean by “lower SC capability value” – = for example, if node X can=20 terminate VC-3 and VC-4 connections but not switch them through, what = SC=20 capability would be advertised for its end of the links?  I = presume=20 “lower” does not mean lower layer, such as lambda capable = or fiber=20 capable.

 

Thanks,

 

Lyndon

 


3D""

From:=20 PAPADIMITRIOU Dimitri = [mailto:Dimitri.Papadimitriou@alcatel-lucent.com]=20
Sent: Wednesday, December 16, 2009 9:35 AM
To: = Ong,=20 Lyndon; ccamp@ietf.org
Subject: RE: [CCAMP] Local Connection = Type

 

Lyndon,

 

for the=20 case a) One sets the SC to lower SC capability value (on X ends, using = the=20 Figure). The Max and Min LSP Bw tells the range of "signals" that can = be=20 terminated.

 

for the=20 case b) you stated "ISCD for VC-3 could be advertised, but this does = not=20 distinguish the case where the switch only supports VC-3 connection." = In this=20 case, setting Min LSP Bw =3D VC3 and Max LSP Bw =3D VC4 and Min = LSP Bw =3D VC3=20 and Max LSP Bw =3D VC3 allows that "distinction" and you can = advertized two=20 separate ISCD's for this purpose. The structure of the mux.tree being = implicit=20 I am not sure to see the issue.

 

Hope=20 this helps,

-dimitri.

 

From:=20 ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of=20 Ong, Lyndon
Sent: Monday, December 14, 2009 6:27=20 PM
To: ccamp@ietf.org
Subject: [CCAMP] Local = Connection=20 Type

Hi Folks,

 

Can we start up a thread on the proposal for = Local=20 Connection Type in=20 draft-theillaud-gmpls-ason-routing-add-fcts-01.txt?

 

I would also like to start up a thread on the=20 layer-scoped attributes proposal in that draft, but as a second step = since=20 that is a more complex issue.

 

draft-theillaud-gmpls-ason-routing-add-fcts-01.txt=20 proposes that an additional link attribute for GMPLS routing be = defined that=20 identifies if the far end interface of the link supports access to = its=20 switching function (which may be specific to a particular = layer).  If=20 access is not supported, then the link would be pruned from the = topology for=20 computation of paths that do not terminate at the far end node = (i.e., would=20 transit through the far end node).

 

This functionality has been previously = identified in=20 ITU-T Recommendation G.7715.1 as local connection = type.

 

One possible method is to use the presence or = absence of=20 the ISCD to imply whether or not switching is supported, however two = cases=20 have come up where this may not be sufficient:

 

It is = very possible=20 that a switch could be constrained by policy to support only = termination of=20 connections and not access to its switching function.  An = example might=20 be a carrier switch located on customer premises.  If this = switch=20 (switch X) is connected by links to two other switches A and B as in = the=20 topology   A----X----B, then from a topology standpoint it = looks=20 like you could switch connections through X, however this is not = allowed by=20 policy.  If no ISCD is advertised by X for the link, it sounds = from=20 reading of RFC 4202 section 2.4 that the absence of the ISCD = completely is=20 interpreted as support of packet switching capability, which would = not be=20 correct in this case.  No information would be provided as to = what=20 types of signals could be terminated at the far end.

 

 Another case is=20 a switch that supports termination of high order VC-4 and switching = of low=20 order VC-3, but not directly switching of VC-4.  ISCD for VC-3 = and VC-4=20 could be advertised, but this does not distinguish the case from the = case=20 where the switch has both VC-3 and VC-4 capability in its = fabric.  ISCD=20 for VC-3 could be advertised, but this does not distinguish the case = where=20 the switch only supports VC-3 connection.

 

Addition of a link attribute that explicitly = identifies=20 when access to switching at a particular signal type is supported = would=20 support the missing functionality.

 

Comments welcome.

 

Cheers,

 

Lyndon



------_=_NextPart_002_01CA7EA6.FC52F4AD-- ------_=_NextPart_001_01CA7EA6.FC52F4AD Content-Type: image/gif; name="ATT1555959.gif" Content-Transfer-Encoding: base64 Content-ID: <505524922@16122009-2D66> Content-Description: ATT1555959.gif Content-Location: ATT1555959.gif R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------_=_NextPart_001_01CA7EA6.FC52F4AD Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: <505524922@16122009-2D6D> Content-Description: image001.gif Content-Location: image001.gif R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------_=_NextPart_001_01CA7EA6.FC52F4AD-- From loa@pi.nu Wed Dec 16 20:36:25 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99A33A6936; Wed, 16 Dec 2009 20:36:25 -0800 (PST) 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 rcOx+LH+QP1J; Wed, 16 Dec 2009 20:36:24 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id C19E23A68F1; Wed, 16 Dec 2009 20:36:24 -0800 (PST) Received: from [172.17.165.88] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id E05A2D4052; Thu, 17 Dec 2009 05:36:07 +0100 (CET) Message-ID: <4B29B534.8040906@pi.nu> Date: Thu, 17 Dec 2009 05:36:04 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org, "ccamp@ietf.org" , pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] Poll om making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 04:36:25 -0000 All, this is to start a two week poll on making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Friday 15 Jan, 2010. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From remi.theillaud@marben-products.com Thu Dec 17 02:46:35 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9188428C0F7 for ; Thu, 17 Dec 2009 02:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] 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 xUmoBzWNATVj for ; Thu, 17 Dec 2009 02:46:34 -0800 (PST) Received: from bizpsie4.9services.com (bizpsie4.9services.com [84.96.93.162]) by core3.amsl.com (Postfix) with ESMTP id 4A89128C0F0 for ; Thu, 17 Dec 2009 02:46:32 -0800 (PST) Received: from [192.168.7.156] ([86.65.15.130]) by bizpsie4.9services.com with 9services id JAmH1d0022oN1dS04AmH4y; Thu, 17 Dec 2009 11:46:17 +0100 X-Biz3: ?? X-VRSPAM-SCORE: -130.00 Message-ID: <4B2A0BF8.9060201@marben-products.com> Date: Thu, 17 Dec 2009 11:46:16 +0100 From: Remi Theillaud User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri References: <0AFD1B67B949784DA087CDA9F0DD4AD901390978@mdmxm03.ciena.com> <00275A5B436CA441900CB10936742A38039FBF6E@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A38039FBF6E@FRVELSMBS22.ad2.ad.alcatel.com> Content-Type: multipart/mixed; boundary="------------050500050805060409010406" Cc: "Ong, Lyndon" , ccamp@ietf.org Subject: Re: [CCAMP] Local Connection Type X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 10:46:35 -0000 This is a multi-part message in MIME format. --------------050500050805060409010406 Content-Type: multipart/alternative; boundary="------------040303040103040501040808" --------------040303040103040501040808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Dimitri, When you write "Max LSP Bw", are you referring to the ISCD per-priority Maximum LSP Bandwidth? If you are, then it's not clear to me how a field whose value can be different per priority can be used to identify the kind of signal that can be switched on a link. Can you clarify? Nevertheless, can you also provide the settings of the ISCDs advertised by X in the two following cases: 1. X can switch both HO VC-4 and HO VC-3. 2. X can switch HO VC-4 and LO VC-3. Thanks, Rémi -------- Original Message -------- Subject: Re: [CCAMP] Local Connection Type From: PAPADIMITRIOU Dimitri To: Ong, Lyndon , ccamp@ietf.org Date: 16/12/2009 18:34 > Lyndon, > > for the case a) One sets the SC to lower SC capability value (on X > ends, using the Figure). The Max and Min LSP Bw tells the range of > "signals" that can be terminated. > > for the case b) you stated "ISCD for VC-3 could be advertised, but > this does not distinguish the case where the switch only supports VC-3 > connection." In this case, setting Min LSP Bw = VC3 and Max LSP Bw = > VC4 and Min LSP Bw = VC3 and Max LSP Bw = VC3 allows that > "distinction" and you can advertized two separate ISCD's for this > purpose. The structure of the mux.tree being implicit I am not sure to > see the issue. > > Hope this helps, > -dimitri. > > ------------------------------------------------------------------------ > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On > Behalf Of *Ong, Lyndon > *Sent:* Monday, December 14, 2009 6:27 PM > *To:* ccamp@ietf.org > *Subject:* [CCAMP] Local Connection Type > > Hi Folks, > > > > Can we start up a thread on the proposal for Local Connection Type > in draft-theillaud-gmpls-ason-routing-add-fcts-01.txt? > > > > I would also like to start up a thread on the layer-scoped > attributes proposal in that draft, but as a second step since that > is a more complex issue. > > > > draft-theillaud-gmpls-ason-routing-add-fcts-01.txt proposes that > an additional link attribute for GMPLS routing be defined that > identifies if the far end interface of the link supports access to > its switching function (which may be specific to a particular > layer). If access is not supported, then the link would be pruned > from the topology for computation of paths that do not terminate > at the far end node (i.e., would transit through the far end node). > > > > This functionality has been previously identified in ITU-T > Recommendation G.7715.1 as local connection type. > > > > One possible method is to use the presence or absence of the ISCD > to imply whether or not switching is supported, however two cases > have come up where this may not be sufficient: > > > > It is very possible that a switch could be constrained by policy > to support only termination of connections and not access to its > switching function. An example might be a carrier switch located > on customer premises. If this switch (switch X) is connected by > links to two other switches A and B as in the topology > A----X----B, then from a topology standpoint it looks like you > could switch connections through X, however this is not allowed by > policy. If no ISCD is advertised by X for the link, it sounds > from reading of RFC 4202 section 2.4 that the absence of the ISCD > completely is interpreted as support of packet switching > capability, which would not be correct in this case. No > information would be provided as to what types of signals could be > terminated at the far end. > > > > Another case is a switch that supports termination of high order > VC-4 and switching of low order VC-3, but not directly switching > of VC-4. ISCD for VC-3 and VC-4 could be advertised, but this > does not distinguish the case from the case where the switch has > both VC-3 and VC-4 capability in its fabric. ISCD for VC-3 could > be advertised, but this does not distinguish the case where the > switch only supports VC-3 connection. > > > > Addition of a link attribute that explicitly identifies when > access to switching at a particular signal type is supported would > support the missing functionality. > > > > Comments welcome. > > > > Cheers, > > > > Lyndon > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --------------040303040103040501040808 Content-Type: multipart/related; boundary="------------070004060301080800020600" --------------070004060301080800020600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit    Hi Dimitri,

   When you write "Max LSP Bw", are you referring to the ISCD per-priority Maximum LSP Bandwidth?
   If you are, then it's not clear to me how a field whose value can be different per priority can be used to identify the kind of signal that can be switched on a link.
   Can you clarify?

   Nevertheless, can you also provide the settings of the ISCDs advertised by X in the two following cases:
   1. X can switch both HO VC-4 and HO VC-3.
   2. X can switch HO VC-4 and LO VC-3.

   Thanks,
   Rémi

-------- Original Message --------
Subject: Re: [CCAMP] Local Connection Type
From: PAPADIMITRIOU Dimitri <Dimitri.Papadimitriou@alcatel-lucent.com>
To: Ong, Lyndon <Lyong@Ciena.com>, ccamp@ietf.org
Date: 16/12/2009 18:34
Lyndon,
 
for the case a) One sets the SC to lower SC capability value (on X ends, using the Figure). The Max and Min LSP Bw tells the range of "signals" that can be terminated.
 
for the case b) you stated "ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection." In this case, setting Min LSP Bw = VC3 and Max LSP Bw = VC4 and Min LSP Bw = VC3 and Max LSP Bw = VC3 allows that "distinction" and you can advertized two separate ISCD's for this purpose. The structure of the mux.tree being implicit I am not sure to see the issue.
 
Hope this helps,
-dimitri.

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Ong, Lyndon
Sent: Monday, December 14, 2009 6:27 PM
To: ccamp@ietf.org
Subject: [CCAMP] Local Connection Type

Hi Folks,

 

Can we start up a thread on the proposal for Local Connection Type in draft-theillaud-gmpls-ason-routing-add-fcts-01.txt?

 

I would also like to start up a thread on the layer-scoped attributes proposal in that draft, but as a second step since that is a more complex issue.

 

draft-theillaud-gmpls-ason-routing-add-fcts-01.txt proposes that an additional link attribute for GMPLS routing be defined that identifies if the far end interface of the link supports access to its switching function (which may be specific to a particular layer).  If access is not supported, then the link would be pruned from the topology for computation of paths that do not terminate at the far end node (i.e., would transit through the far end node).

 

This functionality has been previously identified in ITU-T Recommendation G.7715.1 as local connection type.

 

One possible method is to use the presence or absence of the ISCD to imply whether or not switching is supported, however two cases have come up where this may not be sufficient:

 

It is very possible that a switch could be constrained by policy to support only termination of connections and not access to its switching function.  An example might be a carrier switch located on customer premises.  If this switch (switch X) is connected by links to two other switches A and B as in the topology   A----X----B, then from a topology standpoint it looks like you could switch connections through X, however this is not allowed by policy.  If no ISCD is advertised by X for the link, it sounds from reading of RFC 4202 section 2.4 that the absence of the ISCD completely is interpreted as support of packet switching capability, which would not be correct in this case.  No information would be provided as to what types of signals could be terminated at the far end.

 

 Another case is a switch that supports termination of high order VC-4 and switching of low order VC-3, but not directly switching of VC-4.  ISCD for VC-3 and VC-4 could be advertised, but this does not distinguish the case from the case where the switch has both VC-3 and VC-4 capability in its fabric.  ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection.

 

Addition of a link attribute that explicitly identifies when access to switching at a particular signal type is supported would support the missing functionality.

 

Comments welcome.

 

Cheers,

 

Lyndon





_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

--------------070004060301080800020600 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gA B/3///TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEI PtrZ1vG9y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE 0fjl6umNps8ALeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoy Wc7OytosWd5BbPLx8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIF PDUzIc8AMPGzus0AIOh+mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSU itgeUOqKpPry9u7u7L6+uPnx8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe 5Pfi5uNmiMTEvuNqidEAOO+jqvz+/JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVW ZeRpivff5dcbTdckTdjX0/PI0+VvjdMOQ7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3 a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMS RdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBOdOqPp6ion6Sim/PM18jHwt09Z5mZj15d TtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTDvvz19//9/4B/dNzb2ZSTidIBO/f3 9rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lIOdEDO+yYr/C4xlBOP7i3sfz9 /FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tknV+qRqO6dpfv7+pOUi8jI xOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4AAAj/AP8JHEiw4MAO bUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriTMGPKnEkzpDtF LTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQhGAvg49ez aNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpjRLMR Mk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+ eC+SX1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKF HW4IhAEBJoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCR QjJ9RGeHHxt8YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBw UUUibU4C5wbEIDBKkYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ 1GEmmmoCoOkVfnxIiDCgmP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDD DGNA9wAAlV6ZJRNCpKATDWjM+g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgA rpgbVPGChcQGPFAMO8Dy4SQvMMHaQJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ 9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACGCRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH 0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDwSS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAa BHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMDDCvusIOB0mzA4AY2t+32sODK/QK8Q0/5 yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C/POFMS8m+AIN8F2RbOe7w9T85yet cvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+jxFZaEuIJVIoopsUxmjLPEYj /IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o3SnStAPrheAUidBJCmDx gUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW/+hBkHiIoBT/oEYX KCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2amwpd/mEETrdqA CYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5Hl4kD2LY QgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8IwCY EEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPW EAYe6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4 KMMebDhAKw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCC KcQBGcFYQwJucYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5Cg gWkYogStCAUqgKCMd0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAK lz/NyY9BhBCEEx6RiCv/NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDI NAJxAA2AwAsXSIISLiAKVrBDCSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4 hgUygYwpKFMOP+jCDdiAiFaYIxabWMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZx wIYontEJdlCDFVaYQwvGkQB2WEEENSDCLW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvH wvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA /4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqAAlsc4xhIaMEN/kGLWwgECQfAgQVacAtT EGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9OWEEDB7AFEIoBBMQORAmtuAMQkiCC ZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjGAYMI7aM0RQMhVCEXv8iCEFhV hSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7yII88vlu0eLhH/gwAekm EgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4hwa6YIgIkAEZXUhA ILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8ogPEMMoigC0D4 gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTowDynIQhMA EMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0mNCIE 86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1Nkdhz WoAd7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9 YT4C0QxuUAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIq qBmAMAJQ1BCYJEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/G JBA14HHlUAv8AIXTAAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o 0A1ieA930AT1oAqvL7QGhUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJ lGBKThEQADs= --------------070004060301080800020600-- --------------040303040103040501040808-- --------------050500050805060409010406 Content-Type: text/x-vcard; charset=utf-8; name="remi_theillaud.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="remi_theillaud.vcf" begin:vcard fn:Remi Theillaud n:Theillaud;Remi org:Marben Products adr:;;176 rue Jean Jaures;Puteaux;;92800;France email;internet:remi.theillaud@marben-products.com tel;work:+33 1 79 62 10 22 tel;fax:+33 1 79 62 10 01 x-mozilla-html:TRUE version:2.1 end:vcard --------------050500050805060409010406-- From Dimitri.Papadimitriou@alcatel-lucent.com Thu Dec 17 03:30:58 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E053528C101 for ; Thu, 17 Dec 2009 03:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.051 X-Spam-Level: X-Spam-Status: No, score=-5.051 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] 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 hEnufzGScNa1 for ; Thu, 17 Dec 2009 03:30:57 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 63DAA28C0F0 for ; Thu, 17 Dec 2009 03:30:57 -0800 (PST) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nBHBUcJ9004773; Thu, 17 Dec 2009 12:30:38 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 12:30:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Dec 2009 12:30:37 +0100 Message-ID: <00275A5B436CA441900CB10936742A38039FC2A1@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <4B2A0BF8.9060201@marben-products.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Local Connection Type Thread-Index: Acp/Bi1rZ5sy7Y2sSTGQnyPvjremsgAAcjQg References: <0AFD1B67B949784DA087CDA9F0DD4AD901390978@mdmxm03.ciena.com> <00275A5B436CA441900CB10936742A38039FBF6E@FRVELSMBS22.ad2.ad.alcatel.com> <4B2A0BF8.9060201@marben-products.com> From: "PAPADIMITRIOU Dimitri" To: "Remi Theillaud" X-OriginalArrivalTime: 17 Dec 2009 11:30:38.0034 (UTC) FILETIME=[5B39F320:01CA7F0C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "Ong, Lyndon" , ccamp@ietf.org Subject: Re: [CCAMP] Local Connection Type X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 11:30:59 -0000 Remi: ________________________________ From: Remi Theillaud [mailto:remi.theillaud@marben-products.com]=20 Sent: Thursday, December 17, 2009 11:46 AM To: PAPADIMITRIOU Dimitri Cc: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] Local Connection Type =09 =09 Hi Dimitri, =09 When you write "Max LSP Bw", are you referring to the ISCD = per-priority Maximum LSP Bandwidth?=20 [dp] Yes. If you are, then it's not clear to me how a field whose value can be = different per priority can be used to identify the kind of signal that = can be switched on a link. Can you clarify? [dp] This value field is not associated to a "capacity amount" attribute = but a "capability" attribute: the "max. granularity" that an LSP can = take for that interface. This capability has been defined per priority = p, thus set a given value in the IGP-TE domain to have a priority = "agnostic" processing of the value. Nevertheless, can you also provide the settings of the ISCDs = advertised by X in the two following cases: 1. X can switch both HO VC-4 and HO VC-3. 2. X can switch HO VC-4 and LO VC-3. [dp] You would typically use the following setting for 1) ISCD: SC Capability <- TDM; Min LSP Bw <- VC3 and Max LSP Bw <- = VC4=09 for 2) ISCD_1: SC Capability <- TDM; Min LSP Bw <- VC4 and Max LSP Bw <- = VC4 ISCD_2: SC Capability <- TDM; Min LSP Bw <- VC3 and Max LSP Bw <- = VC3 Hope this helps, -dimitri. Thanks, R=E9mi =09 -------- Original Message -------- Subject: Re: [CCAMP] Local Connection Type From: PAPADIMITRIOU Dimitri = =20 To: Ong, Lyndon , = ccamp@ietf.org Date: 16/12/2009 18:34 =09 Lyndon, =20 for the case a) One sets the SC to lower SC capability value (on X = ends, using the Figure). The Max and Min LSP Bw tells the range of = "signals" that can be terminated. =20 for the case b) you stated "ISCD for VC-3 could be advertised, but = this does not distinguish the case where the switch only supports VC-3 = connection." In this case, setting Min LSP Bw =3D VC3 and Max LSP Bw =3D = VC4 and Min LSP Bw =3D VC3 and Max LSP Bw =3D VC3 allows that = "distinction" and you can advertized two separate ISCD's for this = purpose. The structure of the mux.tree being implicit I am not sure to = see the issue.=20 =20 Hope this helps, -dimitri. ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On = Behalf Of Ong, Lyndon Sent: Monday, December 14, 2009 6:27 PM To: ccamp@ietf.org Subject: [CCAMP] Local Connection Type =09 =09 Hi Folks, Can we start up a thread on the proposal for Local Connection Type = in draft-theillaud-gmpls-ason-routing-add-fcts-01.txt? I would also like to start up a thread on the layer-scoped = attributes proposal in that draft, but as a second step since that is a = more complex issue. draft-theillaud-gmpls-ason-routing-add-fcts-01.txt proposes that = an additional link attribute for GMPLS routing be defined that = identifies if the far end interface of the link supports access to its = switching function (which may be specific to a particular layer). If = access is not supported, then the link would be pruned from the topology = for computation of paths that do not terminate at the far end node = (i.e., would transit through the far end node). This functionality has been previously identified in ITU-T = Recommendation G.7715.1 as local connection type. One possible method is to use the presence or absence of the ISCD = to imply whether or not switching is supported, however two cases have = come up where this may not be sufficient: It is very possible that a switch could be constrained by policy = to support only termination of connections and not access to its = switching function. An example might be a carrier switch located on = customer premises. If this switch (switch X) is connected by links to = two other switches A and B as in the topology A----X----B, then from a = topology standpoint it looks like you could switch connections through = X, however this is not allowed by policy. If no ISCD is advertised by X = for the link, it sounds from reading of RFC 4202 section 2.4 that the = absence of the ISCD completely is interpreted as support of packet = switching capability, which would not be correct in this case. No = information would be provided as to what types of signals could be = terminated at the far end. Another case is a switch that supports termination of high order = VC-4 and switching of low order VC-3, but not directly switching of = VC-4. ISCD for VC-3 and VC-4 could be advertised, but this does not = distinguish the case from the case where the switch has both VC-3 and = VC-4 capability in its fabric. ISCD for VC-3 could be advertised, but = this does not distinguish the case where the switch only supports VC-3 = connection.=20 Addition of a link attribute that explicitly identifies when = access to switching at a particular signal type is supported would = support the missing functionality. Comments welcome. Cheers, Lyndon =09 =09 =09 ________________________________ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp =20 From Lyong@Ciena.com Thu Dec 17 05:02:13 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F523A69A6 for ; Thu, 17 Dec 2009 05:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.116 X-Spam-Level: X-Spam-Status: No, score=-0.116 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SARE_GIF_ATTACH=1.42] 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 CG8nt6gcqZue for ; Thu, 17 Dec 2009 05:02:05 -0800 (PST) Received: from ripley.ciena.com (ripley.ciena.com [63.118.34.24]) by core3.amsl.com (Postfix) with ESMTP id 91A583A6A8F for ; Thu, 17 Dec 2009 05:01:45 -0800 (PST) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA7F19.0A830F83" Date: Thu, 17 Dec 2009 08:01:25 -0500 Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD901390E44@mdmxm03.ciena.com> Content-Transfer-Encoding: 7bit In-Reply-To: <00275A5B436CA441900CB10936742A38039FBFCE@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Local Connection Type Thread-Index: Acp84phsKiCJbWXZTuO2s41b6sjddQBkfQbwAAsF37AAAFwXIAAdl5Tw References: <0AFD1B67B949784DA087CDA9F0DD4AD901390978@mdmxm03.ciena.com> <00275A5B436CA441900CB10936742A38039FBF6E@FRVELSMBS22.ad2.ad.alcatel.com> <0AFD1B67B949784DA087CDA9F0DD4AD901390E21@mdmxm03.ciena.com> <00275A5B436CA441900CB10936742A38039FBFCE@FRVELSMBS22.ad2.ad.alcatel.com> Importance: normal Priority: normal From: "Ong, Lyndon" To: "PAPADIMITRIOU Dimitri" , Subject: Re: [CCAMP] Local Connection Type X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 13:02:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7F19.0A830F83 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA7F19.0A830F83" ------_=_NextPart_002_01CA7F19.0A830F83 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Dimitri, =20 Thanks for the added information, it's clear what you mean by "lower" now. However, can this be done in a case where the link endpoint is used to terminate a TDM bandwidth on demand type of service? In that case the end node (X) may not in fact be part of a different layer network, Ethernet or IP/MPLS, and advertising L2SC or PSC would be implying some functionality that is not there. =20 Thanks, =20 Lyndon =20 From: PAPADIMITRIOU Dimitri [mailto:Dimitri.Papadimitriou@alcatel-lucent.com]=20 Sent: Wednesday, December 16, 2009 3:25 PM To: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] Local Connection Type =20 Lyndon, =20 RFC 4203 defines values associated to SC hence my reference to "lower SC capability value" for instance L2SC (=3D 51), TDM (=3D 100) as lower SC value than LSC (=3D 150). =20 Using your example if VC-3 and VC-4 are both "terminated" they refer to a lower SC value (from X side) - for instance L2SC (if Eth over SDH) or PSC (if IP/MPLS over SDH) and one sets the Min LSP Bw corr. to VC3 and Max LSP Bw corr. to VC-4. So, in this example, X indicates in the ISCD (Switching Capability field) the "upper" SC value.=20 =20 Thanks, -dimitri. =09 ________________________________ From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20 Sent: Wednesday, December 16, 2009 11:43 PM To: PAPADIMITRIOU Dimitri; ccamp@ietf.org Subject: RE: [CCAMP] Local Connection Type Hi Dimitri, =20 Thanks for your response, if there is already a way to do this, that would be great. However, I'm not sure what you mean by "lower SC capability value" - for example, if node X can terminate VC-3 and VC-4 connections but not switch them through, what SC capability would be advertised for its end of the links? I presume "lower" does not mean lower layer, such as lambda capable or fiber capable. =20 Thanks, =20 Lyndon =20 =09 =20 From: PAPADIMITRIOU Dimitri [mailto:Dimitri.Papadimitriou@alcatel-lucent.com]=20 Sent: Wednesday, December 16, 2009 9:35 AM To: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] Local Connection Type =20 Lyndon, =20 for the case a) One sets the SC to lower SC capability value (on X ends, using the Figure). The Max and Min LSP Bw tells the range of "signals" that can be terminated. =20 for the case b) you stated "ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection." In this case, setting Min LSP Bw =3D VC3 and Max LSP = Bw =3D VC4 and Min LSP Bw =3D VC3 and Max LSP Bw =3D VC3 allows that "distinction" and you can advertized two separate ISCD's for this purpose. The structure of the mux.tree being implicit I am not sure to see the issue.=20 =20 Hope this helps, -dimitri. =20 =09 ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Ong, Lyndon Sent: Monday, December 14, 2009 6:27 PM To: ccamp@ietf.org Subject: [CCAMP] Local Connection Type Hi Folks, =20 Can we start up a thread on the proposal for Local Connection Type in draft-theillaud-gmpls-ason-routing-add-fcts-01.txt? =20 I would also like to start up a thread on the layer-scoped attributes proposal in that draft, but as a second step since that is a more complex issue. =20 draft-theillaud-gmpls-ason-routing-add-fcts-01.txt proposes that an additional link attribute for GMPLS routing be defined that identifies if the far end interface of the link supports access to its switching function (which may be specific to a particular layer). If access is not supported, then the link would be pruned from the topology for computation of paths that do not terminate at the far end node (i.e., would transit through the far end node). =20 This functionality has been previously identified in ITU-T Recommendation G.7715.1 as local connection type. =20 One possible method is to use the presence or absence of the ISCD to imply whether or not switching is supported, however two cases have come up where this may not be sufficient: =20 It is very possible that a switch could be constrained by policy to support only termination of connections and not access to its switching function. An example might be a carrier switch located on customer premises. If this switch (switch X) is connected by links to two other switches A and B as in the topology A----X----B, then from a topology standpoint it looks like you could switch connections through X, however this is not allowed by policy. If no ISCD is advertised by X for the link, it sounds from reading of RFC 4202 section 2.4 that the absence of the ISCD completely is interpreted as support of packet switching capability, which would not be correct in this case. No information would be provided as to what types of signals could be terminated at the far end. =20 Another case is a switch that supports termination of high order VC-4 and switching of low order VC-3, but not directly switching of VC-4. ISCD for VC-3 and VC-4 could be advertised, but this does not distinguish the case from the case where the switch has both VC-3 and VC-4 capability in its fabric. ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection.=20 =20 Addition of a link attribute that explicitly identifies when access to switching at a particular signal type is supported would support the missing functionality. =20 Comments welcome. =20 Cheers, =20 Lyndon =09 =09 =20 ------_=_NextPart_002_01CA7F19.0A830F83 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Dimitri,

 

Thanks for the added information, it’s clear what you mean by “lower” = now.  However, can this be done in a case where the link endpoint is used to terminate a TDM = bandwidth on demand type of service?  In that case the end node (X) may not in = fact be part of a different layer network, Ethernet or IP/MPLS, and advertising L2SC = or PSC would be implying some functionality that is not = there.

 

Thanks,

 

Lyndon

 



From: PAPADIMITRIOU Dimitri [mailto:Dimitri.Papadimitriou@alcatel-lucent.com]
Sent: Wednesday, December 16, 2009 3:25 PM
To: Ong, Lyndon; ccamp@ietf.org
Subject: RE: [CCAMP] Local Connection Type

 

Lyndon,

 

RFC 4203 defines values associated to SC hence my = reference to “lower SC capability value” for instance L2SC (=3D 51), TDM (=3D 100) as = lower SC value than LSC (=3D 150).

 

Using your example if VC-3 and VC-4 are both = "terminated" they refer to a lower SC value (from X side) - for instance L2SC (if Eth = over SDH) or PSC (if IP/MPLS over SDH) and one sets the Min = LSP Bw corr. to VC3 and Max LSP Bw corr. to VC-4. So, in = this example, X indicates in the ISCD (Switching Capability field) the "upper" SC value. 

 

Thanks,

-dimitri.

From: Ong, Lyndon [mailto:Lyong@Ciena.com]
Sent: Wednesday, December 16, 2009 11:43 PM
To: PAPADIMITRIOU Dimitri; ccamp@ietf.org
Subject: RE: [CCAMP] Local Connection Type

Hi = Dimitri,

 

Thanks for your = response, if there is already a way to do this, that would be great.  However, = I’m not sure what you mean by “lower SC capability value” – = for example, if node X can terminate VC-3 and VC-4 connections but not switch them through, what SC capability would be advertised for its end of the links?  I presume “lower” does not mean lower layer, such as lambda capable or = fiber capable.

 

Thanks,

 

Lyndon

 


From: PAPADIMITRIOU Dimitri [mailto:Dimitri.Papadimitriou@alcatel-lucent.com]
Sent: Wednesday, December 16, 2009 9:35 AM
To: Ong, Lyndon; ccamp@ietf.org
Subject: RE: [CCAMP] Local Connection Type

 

Lyndon,

 

for the case a) One sets the SC to lower SC capability = value (on X ends, using the Figure). The Max and Min LSP Bw tells the range of "signals" that can be terminated.

 

for the case b) you stated "ISCD for VC-3 could = be advertised, but this does not distinguish the case where the switch only supports VC-3 connection." In this case, setting Min LSP Bw =3D VC3 = and Max LSP Bw =3D VC4 and Min LSP Bw =3D VC3 and Max LSP Bw =3D VC3 allows = that "distinction" and you can advertized two separate ISCD's for = this purpose. The structure of the mux.tree being implicit I am not sure to see the = issue.

 

Hope this helps,

-dimitri.

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = Ong, Lyndon
Sent: Monday, December 14, 2009 6:27 PM
To: ccamp@ietf.org
Subject: [CCAMP] Local Connection Type

Hi Folks,

 

Can we start up a thread on the proposal for Local Connection Type in = draft-theillaud-gmpls-ason-routing-add-fcts-01.txt?

 

I would also like to start up a thread on the = layer-scoped attributes proposal in that draft, but as a second step since that is a = more complex issue.

 

draft-theillaud-gmpls-ason-routing-add-fcts-01.txt = proposes that an additional link attribute for GMPLS routing be defined that = identifies if the far end interface of the link supports access to its switching = function (which may be specific to a particular layer).  If access is not supported, then the link would be pruned from the topology for = computation of paths that do not terminate at the far end node (i.e., would transit = through the far end node).

 

This functionality has been previously identified = in ITU-T Recommendation G.7715.1 as local connection type.

 

One possible method is to use the presence or = absence of the ISCD to imply whether or not switching is supported, however two cases = have come up where this may not be sufficient:

 

It is very = possible that a switch could be constrained by policy to support only termination of connections and not access to its switching function.  An example = might be a carrier switch located on customer premises.  If this switch = (switch X) is connected by links to two other switches A and B as in the topology   A----X----B, then from a topology standpoint it = looks like you could switch connections through X, however this is not allowed by policy.  If no ISCD is advertised by X for the link, it sounds from reading of RFC 4202 section 2.4 that the absence of the ISCD completely = is interpreted as support of packet switching capability, which would not = be correct in this case.  No information would be provided as to what = types of signals could be terminated at the far end.

 

 Another = case is a switch that supports termination of high order VC-4 and switching of low = order VC-3, but not directly switching of VC-4.  ISCD for VC-3 and VC-4 = could be advertised, but this does not distinguish the case from the case where = the switch has both VC-3 and VC-4 capability in its fabric.  ISCD for = VC-3 could be advertised, but this does not distinguish the case where the = switch only supports VC-3 connection.

 

Addition of a link attribute that explicitly = identifies when access to switching at a particular signal type is supported would = support the missing functionality.

 

Comments welcome.

 

Cheers,

 

Lyndon


 


------_=_NextPart_002_01CA7F19.0A830F83-- ------_=_NextPart_001_01CA7F19.0A830F83 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------_=_NextPart_001_01CA7F19.0A830F83 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------_=_NextPart_001_01CA7F19.0A830F83-- From Dimitri.Papadimitriou@alcatel-lucent.com Thu Dec 17 05:28:25 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800BF3A693D for ; Thu, 17 Dec 2009 05:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] 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 7X1kmvGQGlCH for ; Thu, 17 Dec 2009 05:28:16 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 619E93A69E0 for ; Thu, 17 Dec 2009 05:28:14 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nBHDRtGi026427; Thu, 17 Dec 2009 14:27:56 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 14:27:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA7F1C.B2159653" Date: Thu, 17 Dec 2009 14:27:35 +0100 Message-ID: <00275A5B436CA441900CB10936742A38039FC3B4@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <0AFD1B67B949784DA087CDA9F0DD4AD901390E44@mdmxm03.ciena.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Local Connection Type Thread-Index: Acp84phsKiCJbWXZTuO2s41b6sjddQBkfQbwAAsF37AAAFwXIAAdl5TwAAA58/A= References: <0AFD1B67B949784DA087CDA9F0DD4AD901390978@mdmxm03.ciena.com> <00275A5B436CA441900CB10936742A38039FBF6E@FRVELSMBS22.ad2.ad.alcatel.com> <0AFD1B67B949784DA087CDA9F0DD4AD901390E21@mdmxm03.ciena.com> <00275A5B436CA441900CB10936742A38039FBFCE@FRVELSMBS22.ad2.ad.alcatel.com> <0AFD1B67B949784DA087CDA9F0DD4AD901390E44@mdmxm03.ciena.com> From: "PAPADIMITRIOU Dimitri" To: "Ong, Lyndon" , X-OriginalArrivalTime: 17 Dec 2009 13:27:36.0064 (UTC) FILETIME=[B24C5800:01CA7F1C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [CCAMP] Local Connection Type X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 13:28:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA7F1C.B2159653 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA7F1C.B2159653" ------_=_NextPart_002_01CA7F1C.B2159653 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lyndon: =20 You state: "and advertising L2SC or PSC would be implying some functionality that is not there." =20 well it indicates "terminate" but instead of a bit indication you have an indication on which SC it "terminates". Meaning this information can be processed into two ways i) "different" from TDM and then one simply assumes "terminates" or ii) "different" from TDM with value e.g. PSC (processed per RFC 4202/4203) in context of unified traffic engineering. =20 -> So the answer is NO (it does not mean that it "may not in fact be part of a different layer network") as the demarcation is on the [TDM (A side); PSC (X side)] link connecting A to X. =20 In brief, "qui peut le plus peut le moins" (meaning if one can do more one can certainly do less). =20 Thanks, -dimitri. =20 ________________________________ From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20 Sent: Thursday, December 17, 2009 2:01 PM To: PAPADIMITRIOU Dimitri; ccamp@ietf.org Subject: RE: [CCAMP] Local Connection Type =09 =09 Hi Dimitri, =20 Thanks for the added information, it's clear what you mean by "lower" now. However, can this be done in a case where the link endpoint is used to terminate a TDM bandwidth on demand type of service? In that case the end node (X) may not in fact be part of a different layer network, Ethernet or IP/MPLS, and advertising L2SC or PSC would be implying some functionality that is not there. =20 Thanks, =20 Lyndon =20 =20 =09 From: PAPADIMITRIOU Dimitri [mailto:Dimitri.Papadimitriou@alcatel-lucent.com]=20 Sent: Wednesday, December 16, 2009 3:25 PM To: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] Local Connection Type =20 Lyndon, =20 RFC 4203 defines values associated to SC hence my reference to "lower SC capability value" for instance L2SC (=3D 51), TDM (=3D 100) as lower SC value than LSC (=3D 150). =20 Using your example if VC-3 and VC-4 are both "terminated" they refer to a lower SC value (from X side) - for instance L2SC (if Eth over SDH) or PSC (if IP/MPLS over SDH) and one sets the Min LSP Bw corr. to VC3 and Max LSP Bw corr. to VC-4. So, in this example, X indicates in the ISCD (Switching Capability field) the "upper" SC value.=20 =20 Thanks, -dimitri. =09 ________________________________ From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20 Sent: Wednesday, December 16, 2009 11:43 PM To: PAPADIMITRIOU Dimitri; ccamp@ietf.org Subject: RE: [CCAMP] Local Connection Type Hi Dimitri, =20 Thanks for your response, if there is already a way to do this, that would be great. However, I'm not sure what you mean by "lower SC capability value" - for example, if node X can terminate VC-3 and VC-4 connections but not switch them through, what SC capability would be advertised for its end of the links? I presume "lower" does not mean lower layer, such as lambda capable or fiber capable. =20 Thanks, =20 Lyndon =20 =09 =20 From: PAPADIMITRIOU Dimitri [mailto:Dimitri.Papadimitriou@alcatel-lucent.com]=20 Sent: Wednesday, December 16, 2009 9:35 AM To: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] Local Connection Type =20 Lyndon, =20 for the case a) One sets the SC to lower SC capability value (on X ends, using the Figure). The Max and Min LSP Bw tells the range of "signals" that can be terminated. =20 for the case b) you stated "ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection." In this case, setting Min LSP Bw =3D VC3 and Max LSP Bw =3D VC4 and Min LSP Bw =3D VC3 and Max LSP Bw =3D VC3 allows = that "distinction" and you can advertized two separate ISCD's for this purpose. The structure of the mux.tree being implicit I am not sure to see the issue.=20 =20 Hope this helps, -dimitri. =20 =09 ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Ong, Lyndon Sent: Monday, December 14, 2009 6:27 PM To: ccamp@ietf.org Subject: [CCAMP] Local Connection Type Hi Folks, =20 Can we start up a thread on the proposal for Local Connection Type in draft-theillaud-gmpls-ason-routing-add-fcts-01.txt? =20 I would also like to start up a thread on the layer-scoped attributes proposal in that draft, but as a second step since that is a more complex issue. =20 =09 draft-theillaud-gmpls-ason-routing-add-fcts-01.txt proposes that an additional link attribute for GMPLS routing be defined that identifies if the far end interface of the link supports access to its switching function (which may be specific to a particular layer). If access is not supported, then the link would be pruned from the topology for computation of paths that do not terminate at the far end node (i.e., would transit through the far end node). =20 This functionality has been previously identified in ITU-T Recommendation G.7715.1 as local connection type. =20 One possible method is to use the presence or absence of the ISCD to imply whether or not switching is supported, however two cases have come up where this may not be sufficient: =20 It is very possible that a switch could be constrained by policy to support only termination of connections and not access to its switching function. An example might be a carrier switch located on customer premises. If this switch (switch X) is connected by links to two other switches A and B as in the topology A----X----B, then from a topology standpoint it looks like you could switch connections through X, however this is not allowed by policy. If no ISCD is advertised by X for the link, it sounds from reading of RFC 4202 section 2.4 that the absence of the ISCD completely is interpreted as support of packet switching capability, which would not be correct in this case. No information would be provided as to what types of signals could be terminated at the far end. =20 Another case is a switch that supports termination of high order VC-4 and switching of low order VC-3, but not directly switching of VC-4. ISCD for VC-3 and VC-4 could be advertised, but this does not distinguish the case from the case where the switch has both VC-3 and VC-4 capability in its fabric. ISCD for VC-3 could be advertised, but this does not distinguish the case where the switch only supports VC-3 connection.=20 =20 Addition of a link attribute that explicitly identifies when access to switching at a particular signal type is supported would support the missing functionality. =20 Comments welcome. =20 Cheers, =20 Lyndon =09 =09 =20 ------_=_NextPart_002_01CA7F1C.B2159653 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Lyndon:
 
You state:
"and advertising L2SC or PSC would be = implying some=20 functionality that is not there."
 
well it indicates "terminate" but instead of = a bit=20 indication you have an indication on which SC it "terminates". = Meaning this=20 information can be processed into two ways i) "different" from TDM = and then=20 one simply assumes "terminates" or ii) "different" from TDM = with value=20 e.g. PSC (processed per RFC 4202/4203) in context of unified = traffic=20 engineering.
 
-> So the answer is NO (it does not mean = that it=20 "may not in fact be part of a different layer network") as the = demarcation is on=20 the [TDM (A side); PSC (X side)] link connecting A to = X.
 
In brief, "qui peut le plus peut le moins" = (meaning if=20 one can do more one can certainly do less).
 
Thanks,
-dimitri.
 

From: Ong, Lyndon = [mailto:Lyong@Ciena.com]=20
Sent: Thursday, December 17, 2009 2:01 PM
To:=20 PAPADIMITRIOU Dimitri; ccamp@ietf.org
Subject: RE: [CCAMP] = Local=20 Connection Type

Hi=20 Dimitri,

 

Thanks for the = added=20 information, it’s clear what you mean by “lower” = now.  However, can this=20 be done in a case where the link endpoint is used to terminate a TDM = bandwidth=20 on demand type of service?  In that case the end node (X) may not = in fact=20 be part of a different layer network, Ethernet or IP/MPLS, and = advertising=20 L2SC or PSC would be implying some functionality that is not=20 there.

 

Thanks,

 

Lyndon

 


3D""

From:=20 PAPADIMITRIOU Dimitri = [mailto:Dimitri.Papadimitriou@alcatel-lucent.com]=20
Sent: Wednesday, December 16, 2009 3:25 PM
To: = Ong,=20 Lyndon; ccamp@ietf.org
Subject: RE: [CCAMP] Local Connection = Type

 

Lyndon,

 

RFC=20 4203 defines values associated to SC hence my reference to = “lower SC=20 capability value” for instance L2SC (=3D 51), TDM (=3D 100) as = lower SC value than=20 LSC (=3D 150).

 

Using your=20 example if VC-3 and VC-4 are both "terminated" they refer to a lower = SC value=20 (from X side) - for instance L2SC (if Eth over SDH) or PSC (if = IP/MPLS=20 over SDH) and one sets the Min LSP Bw corr. to VC3 and Max = LSP Bw=20 corr. to VC-4. So, in this example, X indicates in the=20 ISCD (Switching Capability field) the "upper" SC = value. 

 

Thanks,

-dimitri.

From:=20 Ong, Lyndon [mailto:Lyong@Ciena.com]
Sent: Wednesday, = December=20 16, 2009 11:43 PM
To: PAPADIMITRIOU Dimitri;=20 ccamp@ietf.org
Subject: RE: [CCAMP] Local Connection=20 Type

Hi=20 Dimitri,

 

Thanks for your = response, if=20 there is already a way to do this, that would be great.  = However, I’m=20 not sure what you mean by “lower SC capability value” = – for example, if node=20 X can terminate VC-3 and VC-4 connections but not switch them = through, what=20 SC capability would be advertised for its end of the links?  I = presume=20 “lower” does not mean lower layer, such as lambda = capable or fiber=20 capable.

 

Thanks,

 

Lyndon

 


From:=20 PAPADIMITRIOU Dimitri = [mailto:Dimitri.Papadimitriou@alcatel-lucent.com]=20
Sent: Wednesday, December 16, 2009 9:35 AM
To: = Ong,=20 Lyndon; ccamp@ietf.org
Subject: RE: [CCAMP] Local = Connection=20 Type

 

Lyndon,

 

for=20 the case a) One sets the SC to lower SC capability value (on X ends, = using=20 the Figure). The Max and Min LSP Bw tells the range of "signals" = that can be=20 terminated.

 

for=20 the case b) you stated "ISCD for VC-3 could be advertised, but this = does not=20 distinguish the case where the switch only supports VC-3 = connection." In=20 this case, setting Min LSP Bw =3D VC3 and Max LSP Bw =3D = VC4 and Min LSP Bw=20 =3D VC3 and Max LSP Bw =3D VC3 allows that "distinction" and you can = advertized=20 two separate ISCD's for this purpose. The structure of the mux.tree = being=20 implicit I am not sure to see the issue.

 

Hope=20 this helps,

-dimitri.

 

From:=20 ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On = Behalf Of=20 Ong, Lyndon
Sent: Monday, December 14, 2009 6:27=20 PM
To: ccamp@ietf.org
Subject: [CCAMP] Local=20 Connection Type

Hi Folks,

 

Can we start up a thread on the proposal for = Local=20 Connection Type in=20 draft-theillaud-gmpls-ason-routing-add-fcts-01.txt?

 

I would also like to start up a thread on the = layer-scoped attributes proposal in that draft, but as a second = step since=20 that is a more complex issue.

 

draft-theillaud-gmpls-ason-routing-add-fcts-01.txt=20 proposes that an additional link attribute for GMPLS routing be = defined=20 that identifies if the far end interface of the link supports = access to=20 its switching function (which may be specific to a particular=20 layer).  If access is not supported, then the link would be = pruned=20 from the topology for computation of paths that do not terminate = at the=20 far end node (i.e., would transit through the far end=20 node).

 

This functionality has been previously = identified in=20 ITU-T Recommendation G.7715.1 as local connection = type.

 

One possible method is to use the presence or = absence=20 of the ISCD to imply whether or not switching is supported, = however two=20 cases have come up where this may not be = sufficient:

 

It is = very possible=20 that a switch could be constrained by policy to support only = termination=20 of connections and not access to its switching function.  An = example=20 might be a carrier switch located on customer premises.  If = this=20 switch (switch X) is connected by links to two other switches A = and B as=20 in the topology   A----X----B, then from a topology = standpoint=20 it looks like you could switch connections through X, however this = is not=20 allowed by policy.  If no ISCD is advertised by X for the = link, it=20 sounds from reading of RFC 4202 section 2.4 that the absence of = the ISCD=20 completely is interpreted as support of packet switching = capability, which=20 would not be correct in this case.  No information would be = provided=20 as to what types of signals could be terminated at the far=20 end.

 

 Another case=20 is a switch that supports termination of high order VC-4 and = switching of=20 low order VC-3, but not directly switching of VC-4.  ISCD for = VC-3=20 and VC-4 could be advertised, but this does not distinguish the = case from=20 the case where the switch has both VC-3 and VC-4 capability in its = fabric.  ISCD for VC-3 could be advertised, but this does not = distinguish the case where the switch only supports VC-3 = connection.=20

 

Addition of a link attribute that explicitly = identifies=20 when access to switching at a particular signal type is supported = would=20 support the missing functionality.

 

Comments welcome.

 

Cheers,

 

Lyndon


 


------_=_NextPart_002_01CA7F1C.B2159653-- ------_=_NextPart_001_01CA7F1C.B2159653 Content-Type: image/gif; name="ATT1851653.gif" Content-Transfer-Encoding: base64 Content-ID: <259400313@17122009-2D9E> Content-Description: ATT1851653.gif Content-Location: ATT1851653.gif R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------_=_NextPart_001_01CA7F1C.B2159653 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: <259400313@17122009-2DA5> Content-Description: image001.gif Content-Location: image001.gif R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= ------_=_NextPart_001_01CA7F1C.B2159653-- From John.E.Drake2@boeing.com Thu Dec 17 05:49:58 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4C8C3A69E0; Thu, 17 Dec 2009 05:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Vl0k2xo8sfID; Thu, 17 Dec 2009 05:49:58 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id DDC993A685A; Thu, 17 Dec 2009 05:49:57 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nBHDnLCZ001503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Dec 2009 05:49:22 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nBHDnLXE017882; Thu, 17 Dec 2009 07:49:21 -0600 (CST) Received: from xch-swht-01.sw.nos.boeing.com (xch-swht-01.sw.nos.boeing.com [129.172.142.4]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nBHDnK6c017877 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 17 Dec 2009 07:49:21 -0600 (CST) Received: from XCH-SW-03V.sw.nos.boeing.com ([129.172.197.23]) by xch-swht-01.sw.nos.boeing.com ([129.172.142.4]) with mapi; Thu, 17 Dec 2009 05:49:20 -0800 From: "Drake, John E" To: Maarten Vissers , "'Loa Andersson'" , "mpls-tp@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Date: Thu, 17 Dec 2009 05:49:22 -0800 Thread-Topic: [PWE3] [mpls-tp] Poll om makinghttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working groupdocument Thread-Index: Acp+0nx4dPl6Lc1rTuiovDVmelzglwAGehogAAzU+gA= Message-ID: <83C701404B004C4094B604670B3F5FFA395C58AAFA@XCH-SW-03V.sw.nos.boeing.com> References: <4B29B534.8040906@pi.nu> <001801ca7eec$8e352670$6c02a8c0@china.huawei.com> In-Reply-To: <001801ca7eec$8e352670$6c02a8c0@china.huawei.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 Subject: Re: [CCAMP] [PWE3] [mpls-tp] Poll om makinghttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working groupdocument X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 13:49:58 -0000 Support=20 > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of Maarten Vissers > Sent: Wednesday, December 16, 2009 11:43 PM > To: 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org;=20 > ccamp@ietf.org; pwe3@ietf.org > Subject: Re: [PWE3] [mpls-tp] Poll om=20 > makinghttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a=20 > working groupdocument >=20 > No/do not support. >=20 > Maarten=20 >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: donderdag 17 december 2009 5:36 > To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org > Subject: [mpls-tp] Poll om making > http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a=20 > working group document >=20 > All, >=20 > this is to start a two week poll on making >=20 > http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt >=20 > an MPLS working group document. >=20 > Send a mail to the mpls-tp@ietf.org mailing list, indicating=20 > "yes/support" > or "no/do not support". >=20 > Comments on the content of the draft should be sent to the=20 > same mailing list with a different subject line. >=20 > The poll ends Friday 15 Jan, 2010. >=20 > /Loa > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92=20 > 13 _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > = From maarten.vissers@huawei.com Wed Dec 16 23:43:26 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91E063A6835; Wed, 16 Dec 2009 23:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.082 X-Spam-Level: X-Spam-Status: No, score=-0.082 tagged_above=-999 required=5 tests=[AWL=0.413, 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 UZHadskwU5hD; Wed, 16 Dec 2009 23:43:25 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 72C2D3A6831; Wed, 16 Dec 2009 23:43:25 -0800 (PST) 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 <0KUS00104DFO0L@szxga03-in.huawei.com>; Thu, 17 Dec 2009 15:43:01 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS00APSDFO09@szxga03-in.huawei.com>; Thu, 17 Dec 2009 15:43:00 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUS00J69DFJMR@szxml02-in.huawei.com>; Thu, 17 Dec 2009 15:43:00 +0800 (CST) Date: Thu, 17 Dec 2009 08:42:54 +0100 From: Maarten Vissers In-reply-to: <4B29B534.8040906@pi.nu> To: 'Loa Andersson' , mpls-tp@ietf.org, mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org Message-id: <001801ca7eec$8e352670$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acp+0nx4dPl6Lc1rTuiovDVmelzglwAGehog X-Mailman-Approved-At: Thu, 17 Dec 2009 10:33:01 -0800 Subject: Re: [CCAMP] [mpls-tp] Poll om making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 07:43:26 -0000 No/do not support. Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: donderdag 17 december 2009 5:36 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] Poll om making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group document All, this is to start a two week poll on making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Friday 15 Jan, 2010. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From maarten.vissers@huawei.com Wed Dec 16 23:45:49 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0B43A6835; Wed, 16 Dec 2009 23:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[AWL=0.354, 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 ObU-8AABAKQG; Wed, 16 Dec 2009 23:45:48 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id F03B23A6831; Wed, 16 Dec 2009 23:45:47 -0800 (PST) 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 <0KUS00C1QDJLY4@szxga01-in.huawei.com>; Thu, 17 Dec 2009 15:45:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUS00JXVDJLOM@szxga01-in.huawei.com>; Thu, 17 Dec 2009 15:45:21 +0800 (CST) Received: from M00900002 (vissersm.demon.nl [83.160.252.43]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUS00JBFDJGMR@szxml02-in.huawei.com>; Thu, 17 Dec 2009 15:45:21 +0800 (CST) Date: Thu, 17 Dec 2009 08:45:15 +0100 From: Maarten Vissers In-reply-to: <4B29B534.8040906@pi.nu> To: 'Loa Andersson' , mpls-tp@ietf.org, mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org Message-id: <001901ca7eec$e2179b60$6c02a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acp+0nx4dPl6Lc1rTuiovDVmelzglwAFWAQg X-Mailman-Approved-At: Thu, 17 Dec 2009 10:33:01 -0800 Subject: [CCAMP] Comment on http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 07:45:49 -0000 Some comments on the content of this draft: In section 2.1 it is stated: " <..> For example an AIS message may be sent during a protection switching event and would cease being sent if the protection switch was successful in restoring the link. Its primary purpose is to suppress alarms in the MPLS-TP layer network above the level at which the defect occurs. The AIS message MAY be used to trigger recovery mechanisms. It should be noted that such use would be subject to false positives, e.g. unnecessary protection switching events in the client layer." It is not correct to state that AIS sending is stopped if the protection switch was succesful. The reason is that the AIS insertion is done by a MEP Sink function that is upstream of the protection switch selector process, and this MEP Sink function is as such unaware of the presence of a protection switch process and of the state of the protection switch process. AIS in packet transport networks must **not** used to trigger recovery mechanisms. Reason is that AIS OAM messages in packet transport network are to be generated within 1 second after the detection of the signal fail type defect detection and be generated with a periodicity of 1 second. These times are much too long to trigger any recovery mechanism. The 1 second time requirement to generate the first AIS message is derived from the 2.5 +/- 0.5 second fault cause to failure integration timer as specified in G.7710. Generation of the first AIS message within a period of 1 second will leave enough time to reach the downstream MEP Sink function and suppress the fault cause that report the interruption of the connection. Protection switching in packet transport networks is triggered by e.g. loss of continuity and misconnection defects. In section 2.2 it is stated: " The LDI message is generated in response to detecting a fatal failure in the server layer. The LDI message MUST NOT be sent until the defect has been determined to be fatal. For example during a protection switching event LDI messages are not sent. However if the protection switch was unsuccessful in restoring the link within the expected repair time, an LDI message MUST be sent." and in section 2.1 it is stated: " The MPLS-TP Alarm Indication Signal (AIS) message is generated in response to detecting defects in the server layer. The AIS message SHOULD be sent as soon is the condition is detected, that is before any determination has been made as to whether the condition is fatal." This draft suggest that it is possible for a MEP Sink function to determine if the fault is *fatal* or *not fatal*. This is not possible for a MEP Sink function. The reason is that a MEP Sink function has no knowledge of the presence or state of a protection switch process associated with the connection. E.g. the protection switch process may be in a downstream node. It is also not necessary to make AIS generation conditional on e.g. protection switch actions. Reason is that a protection switch process will select traffic from either a working connection input port, or a protection connection input port. Any traffic present on the not selected input port will drop at this input port and not be forwarded to the protection switch process output port. At the output port AIS messages will be present as long as the protection switch process selects its traffic from the failed connection; once the protection switch process selects its traffic from the non-failed connection AIS messages will not longer be forwarded to the output port. This draft should as such not become a WG document. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: donderdag 17 december 2009 5:36 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] Poll om making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group document All, this is to start a two week poll on making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Friday 15 Jan, 2010. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From lufang@cisco.com Thu Dec 17 06:34:00 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B4928C123; Thu, 17 Dec 2009 06:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 IxP2FsZxO5bH; Thu, 17 Dec 2009 06:33:59 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 66E2F28C12D; Thu, 17 Dec 2009 06:33:59 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACvQKUutJV2a/2dsb2JhbAC/U5cgAoQrBIFj X-IronPort-AV: E=Sophos;i="4.47,413,1257120000"; d="scan'208";a="74868378" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 17 Dec 2009 14:33:44 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id nBHEXivr021633; Thu, 17 Dec 2009 14:33:44 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Dec 2009 08:33:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Dec 2009 08:33:42 -0600 Message-ID: <238542D917511A45B6B8AA806E875E251BCBFF@XMB-RCD-201.cisco.com> In-Reply-To: <4B29B534.8040906@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] Poll om making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group document Thread-Index: Acp+0niC1zz7gwgGS2eqV84hf1kMSAAUwJZg References: <4B29B534.8040906@pi.nu> From: "Luyuan Fang (lufang)" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 17 Dec 2009 14:33:44.0262 (UTC) FILETIME=[EF874E60:01CA7F25] X-Mailman-Approved-At: Thu, 17 Dec 2009 10:33:01 -0800 Subject: Re: [CCAMP] [mpls-tp] Poll om making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 14:34:00 -0000 yes/support.=20 Luyuan=20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: 16 December 2009 23:36 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] Poll om making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group document All, this is to start a two week poll on making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Friday 15 Jan, 2010. /Loa --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From david.sinicrope@ericsson.com Fri Dec 18 01:02:50 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378C33A683F; Fri, 18 Dec 2009 01:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 FzUz9taZpQhp; Fri, 18 Dec 2009 01:02:49 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 52C223A6855; Fri, 18 Dec 2009 01:02:49 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nBI93J2k019336; Fri, 18 Dec 2009 03:03:21 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.228]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 18 Dec 2009 04:02:31 -0500 From: David Sinicrope To: Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" , "IETF.PWE3" Date: Fri, 18 Dec 2009 04:02:36 -0500 Thread-Topic: [mpls-tp] Poll om making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group document Thread-Index: Acp+0nepJvwUccU/R2qmyTeUFimkFAA7l/cR Message-ID: In-Reply-To: <4B29B534.8040906@pi.nu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] [mpls-tp] Poll om making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 09:02:50 -0000 Support On 12/16/09 11:36 PM, "Loa Andersson" wrote: All, this is to start a two week poll on making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Friday 15 Jan, 2010. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From liu.guoman@zte.com.cn Thu Dec 17 17:43:42 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69FCC3A6860; Thu, 17 Dec 2009 17:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.915 X-Spam-Level: X-Spam-Status: No, score=-96.915 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 yvXFu3tZdTij; Thu, 17 Dec 2009 17:43:41 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 8228A3A6824; Thu, 17 Dec 2009 17:43:39 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111643782249529; Fri, 18 Dec 2009 09:12:13 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 75400.4792141558; Fri, 18 Dec 2009 09:31:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id nBI1hEtI023405; Fri, 18 Dec 2009 09:43:14 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <001901ca7eec$e2179b60$6c02a8c0@china.huawei.com> To: Maarten Vissers MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Fri, 18 Dec 2009 09:43:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-12-18 09:43:12, Serialize complete at 2009-12-18 09:43:12 Content-Type: multipart/alternative; boundary="=_alternative 000976A748257690_=" X-MAIL: mse1.zte.com.cn nBI1hEtI023405 X-Mailman-Approved-At: Fri, 18 Dec 2009 04:15:01 -0800 Cc: mpls@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org, pwe3@ietf.org, mpls-tp-bounces@ietf.org Subject: Re: [CCAMP] [mpls-tp] Comment on http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 01:43:42 -0000 This is a multipart message in MIME format. --=_alternative 000976A748257690_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 IEkgdGhpbmsgdGhhdCBNYWFydGVuJ3MgY29tbWVudHMgd2lsbCBiZSBnb29kLiBJIGhvcGUgdGhl IGF1dGhvcnMgb2YgdGhlIA0KZHJhZnQgY2FuIGNsYXJpZnkgdGhlIHByb2JsZW1zIGFjY29yZGlu ZyB0byB0aGVzZSBjb21tZW50cy4NCklNTywgb25seSBhbGwgdW5kZXJzdGFuZCAgdGhlIGFuc3dl cnMgdG8gdGhlc2UgcHJvYmxlbXMuIHRoZW4gY29udGludWUgdG8gDQpuZXh0IHN0ZXBzIGZvciB0 aGlzIGRyYWZ0LiBpdCBpcyB0aGUgYmVzdCB3YXkuDQoNCmJlc3QgIHJlZ2FyZHMNCmxpdQ0KDQoN Cg0KDQoNCg0KDQpNYWFydGVuIFZpc3NlcnMgPG1hYXJ0ZW4udmlzc2Vyc0BodWF3ZWkuY29tPiAN CreivP7IyzogIG1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZw0KMjAwOS0xMi0xNyAxNTo0NQ0KDQrK 1bz+yMsNCidMb2EgQW5kZXJzc29uJyA8bG9hQHBpLm51PiwgbXBscy10cEBpZXRmLm9yZywgbXBs c0BpZXRmLm9yZywgDQpjY2FtcEBpZXRmLm9yZywgcHdlM0BpZXRmLm9yZw0Ks63LzQ0KDQrW98zi DQpbbXBscy10cF0gQ29tbWVudCBvbiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXNmdi1t cGxzLXRwLWZhdWx0LTAxLnR4dA0KDQoNCg0KDQoNCg0KDQpTb21lIGNvbW1lbnRzIG9uIHRoZSBj b250ZW50IG9mIHRoaXMgZHJhZnQ6DQoNCkluIHNlY3Rpb24gMi4xIGl0IGlzIHN0YXRlZDogDQoi ICA8Li4+DQogICBGb3IgZXhhbXBsZSBhbiBBSVMgbWVzc2FnZSBtYXkgYmUgc2VudCBkdXJpbmcg YSBwcm90ZWN0aW9uIHN3aXRjaGluZw0KICAgZXZlbnQgYW5kIHdvdWxkIGNlYXNlIGJlaW5nIHNl bnQgaWYgdGhlIHByb3RlY3Rpb24gc3dpdGNoIHdhcw0KICAgc3VjY2Vzc2Z1bCBpbiByZXN0b3Jp bmcgdGhlIGxpbmsuDQoNCiAgIEl0cyBwcmltYXJ5IHB1cnBvc2UgaXMgdG8gc3VwcHJlc3MgYWxh cm1zIGluIHRoZSBNUExTLVRQIGxheWVyDQogICBuZXR3b3JrIGFib3ZlIHRoZSBsZXZlbCBhdCB3 aGljaCB0aGUgZGVmZWN0IG9jY3Vycy4gIFRoZSBBSVMgbWVzc2FnZQ0KICAgTUFZIGJlIHVzZWQg dG8gdHJpZ2dlciByZWNvdmVyeSBtZWNoYW5pc21zLiAgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQN CiAgIHN1Y2ggdXNlIHdvdWxkIGJlIHN1YmplY3QgdG8gZmFsc2UgcG9zaXRpdmVzLCBlLmcuIHVu bmVjZXNzYXJ5DQogICBwcm90ZWN0aW9uIHN3aXRjaGluZyBldmVudHMgaW4gdGhlIGNsaWVudCBs YXllci4iDQoNCkl0IGlzIG5vdCBjb3JyZWN0IHRvIHN0YXRlIHRoYXQgQUlTIHNlbmRpbmcgaXMg c3RvcHBlZCBpZiB0aGUgcHJvdGVjdGlvbg0Kc3dpdGNoIHdhcyBzdWNjZXNmdWwuIFRoZSByZWFz b24gaXMgdGhhdCB0aGUgQUlTIGluc2VydGlvbiBpcyBkb25lIGJ5IGEgDQpNRVANClNpbmsgZnVu Y3Rpb24gdGhhdCBpcyB1cHN0cmVhbSBvZiB0aGUgcHJvdGVjdGlvbiBzd2l0Y2ggc2VsZWN0b3Ig cHJvY2VzcywNCmFuZCB0aGlzIE1FUCBTaW5rIGZ1bmN0aW9uIGlzIGFzIHN1Y2ggdW5hd2FyZSBv ZiB0aGUgcHJlc2VuY2Ugb2YgYQ0KcHJvdGVjdGlvbiBzd2l0Y2ggcHJvY2VzcyBhbmQgb2YgdGhl IHN0YXRlIG9mIHRoZSBwcm90ZWN0aW9uIHN3aXRjaCANCnByb2Nlc3MuDQoNCkFJUyBpbiBwYWNr ZXQgdHJhbnNwb3J0IG5ldHdvcmtzIG11c3QgKipub3QqKiB1c2VkIHRvIHRyaWdnZXIgcmVjb3Zl cnkNCm1lY2hhbmlzbXMuIFJlYXNvbiBpcyB0aGF0IEFJUyBPQU0gbWVzc2FnZXMgaW4gcGFja2V0 IHRyYW5zcG9ydCBuZXR3b3JrIA0KYXJlDQp0byBiZSBnZW5lcmF0ZWQgd2l0aGluIDEgc2Vjb25k IGFmdGVyIHRoZSBkZXRlY3Rpb24gb2YgdGhlIHNpZ25hbCBmYWlsIA0KdHlwZQ0KZGVmZWN0IGRl dGVjdGlvbiBhbmQgYmUgZ2VuZXJhdGVkIHdpdGggYSBwZXJpb2RpY2l0eSBvZiAxIHNlY29uZC4g VGhlc2UNCnRpbWVzIGFyZSBtdWNoIHRvbyBsb25nIHRvIHRyaWdnZXIgYW55IHJlY292ZXJ5IG1l Y2hhbmlzbS4NCg0KVGhlIDEgc2Vjb25kIHRpbWUgcmVxdWlyZW1lbnQgdG8gZ2VuZXJhdGUgdGhl IGZpcnN0IEFJUyBtZXNzYWdlIGlzIGRlcml2ZWQNCmZyb20gdGhlIDIuNSArLy0gMC41IHNlY29u ZCBmYXVsdCBjYXVzZSB0byBmYWlsdXJlIGludGVncmF0aW9uIHRpbWVyIGFzDQpzcGVjaWZpZWQg aW4gRy43NzEwLiBHZW5lcmF0aW9uIG9mIHRoZSBmaXJzdCBBSVMgbWVzc2FnZSB3aXRoaW4gYSBw ZXJpb2QgDQpvZg0KMSBzZWNvbmQgd2lsbCBsZWF2ZSBlbm91Z2ggdGltZSB0byByZWFjaCB0aGUg ZG93bnN0cmVhbSBNRVAgU2luayBmdW5jdGlvbg0KYW5kIHN1cHByZXNzIHRoZSBmYXVsdCBjYXVz ZSB0aGF0IHJlcG9ydCB0aGUgaW50ZXJydXB0aW9uIG9mIHRoZSANCmNvbm5lY3Rpb24uDQoNClBy b3RlY3Rpb24gc3dpdGNoaW5nIGluIHBhY2tldCB0cmFuc3BvcnQgbmV0d29ya3MgaXMgdHJpZ2dl cmVkIGJ5IGUuZy4gDQpsb3NzDQpvZiBjb250aW51aXR5IGFuZCBtaXNjb25uZWN0aW9uIGRlZmVj dHMuDQoNCkluIHNlY3Rpb24gMi4yIGl0IGlzIHN0YXRlZDoNCiIgIFRoZSBMREkgbWVzc2FnZSBp cyBnZW5lcmF0ZWQgaW4gcmVzcG9uc2UgdG8gZGV0ZWN0aW5nIGEgZmF0YWwgZmFpbHVyZQ0KICAg aW4gdGhlIHNlcnZlciBsYXllci4gIFRoZSBMREkgbWVzc2FnZSBNVVNUIE5PVCBiZSBzZW50IHVu dGlsIHRoZQ0KICAgZGVmZWN0IGhhcyBiZWVuIGRldGVybWluZWQgdG8gYmUgZmF0YWwuICBGb3Ig ZXhhbXBsZSBkdXJpbmcgYQ0KICAgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgZXZlbnQgTERJIG1lc3Nh Z2VzIGFyZSBub3Qgc2VudC4gIEhvd2V2ZXIgaWYgdGhlDQogICBwcm90ZWN0aW9uIHN3aXRjaCB3 YXMgdW5zdWNjZXNzZnVsIGluIHJlc3RvcmluZyB0aGUgbGluayB3aXRoaW4gdGhlDQogICBleHBl Y3RlZCByZXBhaXIgdGltZSwgYW4gTERJIG1lc3NhZ2UgTVVTVCBiZSBzZW50LiINCmFuZCBpbiBz ZWN0aW9uIDIuMSBpdCBpcyBzdGF0ZWQ6DQoiICBUaGUgTVBMUy1UUCBBbGFybSBJbmRpY2F0aW9u IFNpZ25hbCAoQUlTKSBtZXNzYWdlIGlzIGdlbmVyYXRlZCBpbg0KICAgcmVzcG9uc2UgdG8gZGV0 ZWN0aW5nIGRlZmVjdHMgaW4gdGhlIHNlcnZlciBsYXllci4gIFRoZSBBSVMgbWVzc2FnZQ0KICAg U0hPVUxEIGJlIHNlbnQgYXMgc29vbiBpcyB0aGUgY29uZGl0aW9uIGlzIGRldGVjdGVkLCB0aGF0 IGlzIGJlZm9yZQ0KICAgYW55IGRldGVybWluYXRpb24gaGFzIGJlZW4gbWFkZSBhcyB0byB3aGV0 aGVyIHRoZSBjb25kaXRpb24gaXMgZmF0YWwuIg0KDQpUaGlzIGRyYWZ0IHN1Z2dlc3QgdGhhdCBp dCBpcyBwb3NzaWJsZSBmb3IgYSBNRVAgU2luayBmdW5jdGlvbiB0byANCmRldGVybWluZQ0KaWYg dGhlIGZhdWx0IGlzICpmYXRhbCogb3IgKm5vdCBmYXRhbCouIFRoaXMgaXMgbm90IHBvc3NpYmxl IGZvciBhIE1FUCANClNpbmsNCmZ1bmN0aW9uLiBUaGUgcmVhc29uIGlzIHRoYXQgYSBNRVAgU2lu ayBmdW5jdGlvbiBoYXMgbm8ga25vd2xlZGdlIG9mIHRoZQ0KcHJlc2VuY2Ugb3Igc3RhdGUgb2Yg YSBwcm90ZWN0aW9uIHN3aXRjaCBwcm9jZXNzIGFzc29jaWF0ZWQgd2l0aCB0aGUNCmNvbm5lY3Rp b24uIEUuZy4gdGhlIHByb3RlY3Rpb24gc3dpdGNoIHByb2Nlc3MgbWF5IGJlIGluIGEgZG93bnN0 cmVhbSANCm5vZGUuDQoNCkl0IGlzIGFsc28gbm90IG5lY2Vzc2FyeSB0byBtYWtlIEFJUyBnZW5l cmF0aW9uIGNvbmRpdGlvbmFsIG9uIGUuZy4NCnByb3RlY3Rpb24gc3dpdGNoIGFjdGlvbnMuIFJl YXNvbiBpcyB0aGF0IGEgcHJvdGVjdGlvbiBzd2l0Y2ggcHJvY2VzcyB3aWxsDQpzZWxlY3QgdHJh ZmZpYyBmcm9tIGVpdGhlciBhIHdvcmtpbmcgY29ubmVjdGlvbiBpbnB1dCBwb3J0LCBvciBhIA0K cHJvdGVjdGlvbg0KY29ubmVjdGlvbiBpbnB1dCBwb3J0LiBBbnkgdHJhZmZpYyBwcmVzZW50IG9u IHRoZSBub3Qgc2VsZWN0ZWQgaW5wdXQgcG9ydA0Kd2lsbCBkcm9wIGF0IHRoaXMgaW5wdXQgcG9y dCBhbmQgbm90IGJlIGZvcndhcmRlZCB0byB0aGUgcHJvdGVjdGlvbiBzd2l0Y2gNCnByb2Nlc3Mg b3V0cHV0IHBvcnQuIEF0IHRoZSBvdXRwdXQgcG9ydCBBSVMgbWVzc2FnZXMgd2lsbCBiZSBwcmVz ZW50IGFzIA0KbG9uZw0KYXMgdGhlIHByb3RlY3Rpb24gc3dpdGNoIHByb2Nlc3Mgc2VsZWN0cyBp dHMgdHJhZmZpYyBmcm9tIHRoZSBmYWlsZWQNCmNvbm5lY3Rpb247IG9uY2UgdGhlIHByb3RlY3Rp b24gc3dpdGNoIHByb2Nlc3Mgc2VsZWN0cyBpdHMgdHJhZmZpYyBmcm9tIA0KdGhlDQpub24tZmFp bGVkIGNvbm5lY3Rpb24gQUlTIG1lc3NhZ2VzIHdpbGwgbm90IGxvbmdlciBiZSBmb3J3YXJkZWQg dG8gdGhlDQpvdXRwdXQgcG9ydC4NCg0KVGhpcyBkcmFmdCBzaG91bGQgYXMgc3VjaCBub3QgYmVj b21lIGEgV0cgZG9jdW1lbnQuDQoNClJlZ2FyZHMsDQpNYWFydGVuDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxz LXRwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KT2YgTG9hIEFuZGVyc3Nvbg0KU2VudDog ZG9uZGVyZGFnIDE3IGRlY2VtYmVyIDIwMDkgNTozNg0KVG86IG1wbHMtdHBAaWV0Zi5vcmc7IG1w bHNAaWV0Zi5vcmc7IGNjYW1wQGlldGYub3JnOyBwd2UzQGlldGYub3JnDQpTdWJqZWN0OiBbbXBs cy10cF0gUG9sbCBvbSBtYWtpbmcNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtc2Z2LW1w bHMtdHAtZmF1bHQtMDEudHh0IGEgd29ya2luZyBncm91cA0KZG9jdW1lbnQNCg0KQWxsLA0KDQp0 aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtpbmcNCg0KaHR0cDovL3d3dy5p ZXRmLm9yZy9pZC9kcmFmdC1zZnYtbXBscy10cC1mYXVsdC0wMS50eHQNCg0KYW4gTVBMUyB3b3Jr aW5nIGdyb3VwIGRvY3VtZW50Lg0KDQpTZW5kIGEgbWFpbCB0byB0aGUgbXBscy10cEBpZXRmLm9y ZyBtYWlsaW5nIGxpc3QsIGluZGljYXRpbmcgInllcy9zdXBwb3J0Ig0Kb3IgIm5vL2RvIG5vdCBz dXBwb3J0Ii4NCg0KQ29tbWVudHMgb24gdGhlIGNvbnRlbnQgb2YgdGhlIGRyYWZ0IHNob3VsZCBi ZSBzZW50IHRvIHRoZSBzYW1lIG1haWxpbmcgDQpsaXN0DQp3aXRoIGEgZGlmZmVyZW50IHN1Ympl Y3QgbGluZS4NCg0KVGhlIHBvbGwgZW5kcyBGcmlkYXkgMTUgSmFuLCAyMDEwLg0KDQovTG9hDQot LSANCg0KDQpMb2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2Eu YW5kZXJzc29uQGVyaWNzc29uLmNvbQ0KU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2Vy ICAgICAgICAgICAgbG9hQHBpLm51DQpFcmljc3NvbiBJbmMgICAgICAgICAgICAgICAgICAgICAg ICAgIHBob25lOiArNDYgMTAgNzE3IDUyIDEzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKzQ2IDc2NyA3MiA5MiAxMw0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMtdHAgbWFpbGluZyBsaXN0DQptcGxzLXRw QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMtdHAN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMt dHAgbWFpbGluZyBsaXN0DQptcGxzLXRwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21wbHMtdHANCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29s ZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21t dW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2Js aWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Ns b3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBl bWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBh bmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0 eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdl LiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGlu ZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVz ZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 000976A748257690_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO0kgdGhpbmsgdGhhdCBN YWFydGVuJ3MgY29tbWVudHMNCndpbGwgYmUgZ29vZC4gSSBob3BlIHRoZSBhdXRob3JzIG9mIHRo ZSBkcmFmdCBjYW4gY2xhcmlmeSB0aGUgcHJvYmxlbXMNCmFjY29yZGluZyB0byB0aGVzZSBjb21t ZW50cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklNTywgb25s eSBhbGwgdW5kZXJzdGFuZCAmbmJzcDt0aGUgYW5zd2Vycw0KdG8gdGhlc2UgcHJvYmxlbXMuIHRo ZW4gY29udGludWUgdG8gbmV4dCBzdGVwcyBmb3IgdGhpcyBkcmFmdC4gaXQgaXMgdGhlDQpiZXN0 IHdheS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmJl c3QgJm5ic3A7cmVnYXJkczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+bGl1PGJyPg0KPC9mb250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRpdiBhbGlnbj1jZW50 ZXI+PC9kaXY+DQo8dGQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj5NYWFydGVuIFZpc3NlcnMgJmx0O21hYXJ0ZW4udmlzc2Vyc0Bo dWF3ZWkuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+t6K8/sjLOiAmbmJzcDttcGxzLXRwLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0xMi0xNyAxNTo0NTwvZm9udD4NCjx0 ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4nTG9hIEFuZGVy c3NvbicgJmx0O2xvYUBwaS5udSZndDssIG1wbHMtdHBAaWV0Zi5vcmcsDQptcGxzQGlldGYub3Jn LCBjY2FtcEBpZXRmLm9yZywgcHdlM0BpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63L zTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W21wbHMtdHBdIENvbW1lbnQgb24gJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwO2h0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtc2Z2 LW1wbHMtdHAtZmF1bHQtMDEudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQpTb21lIGNvbW1lbnRzIG9uIHRoZSBjb250ZW50 IG9mIHRoaXMgZHJhZnQ6PGJyPg0KPGJyPg0KSW4gc2VjdGlvbiAyLjEgaXQgaXMgc3RhdGVkOiA8 YnI+DQomcXVvdDsgJm5ic3A7Jmx0Oy4uJmd0Ozxicj4NCiAmbmJzcDsgRm9yIGV4YW1wbGUgYW4g QUlTIG1lc3NhZ2UgbWF5IGJlIHNlbnQgZHVyaW5nIGEgcHJvdGVjdGlvbiBzd2l0Y2hpbmc8YnI+ DQogJm5ic3A7IGV2ZW50IGFuZCB3b3VsZCBjZWFzZSBiZWluZyBzZW50IGlmIHRoZSBwcm90ZWN0 aW9uIHN3aXRjaCB3YXM8YnI+DQogJm5ic3A7IHN1Y2Nlc3NmdWwgaW4gcmVzdG9yaW5nIHRoZSBs aW5rLjxicj4NCjxicj4NCiAmbmJzcDsgSXRzIHByaW1hcnkgcHVycG9zZSBpcyB0byBzdXBwcmVz cyBhbGFybXMgaW4gdGhlIE1QTFMtVFAgbGF5ZXI8YnI+DQogJm5ic3A7IG5ldHdvcmsgYWJvdmUg dGhlIGxldmVsIGF0IHdoaWNoIHRoZSBkZWZlY3Qgb2NjdXJzLiAmbmJzcDtUaGUgQUlTDQptZXNz YWdlPGJyPg0KICZuYnNwOyBNQVkgYmUgdXNlZCB0byB0cmlnZ2VyIHJlY292ZXJ5IG1lY2hhbmlz bXMuICZuYnNwO0l0IHNob3VsZCBiZQ0Kbm90ZWQgdGhhdDxicj4NCiAmbmJzcDsgc3VjaCB1c2Ug d291bGQgYmUgc3ViamVjdCB0byBmYWxzZSBwb3NpdGl2ZXMsIGUuZy4gdW5uZWNlc3Nhcnk8YnI+ DQogJm5ic3A7IHByb3RlY3Rpb24gc3dpdGNoaW5nIGV2ZW50cyBpbiB0aGUgY2xpZW50IGxheWVy LiZxdW90Ozxicj4NCjxicj4NCkl0IGlzIG5vdCBjb3JyZWN0IHRvIHN0YXRlIHRoYXQgQUlTIHNl bmRpbmcgaXMgc3RvcHBlZCBpZiB0aGUgcHJvdGVjdGlvbjxicj4NCnN3aXRjaCB3YXMgc3VjY2Vz ZnVsLiBUaGUgcmVhc29uIGlzIHRoYXQgdGhlIEFJUyBpbnNlcnRpb24gaXMgZG9uZSBieSBhDQpN RVA8YnI+DQpTaW5rIGZ1bmN0aW9uIHRoYXQgaXMgdXBzdHJlYW0gb2YgdGhlIHByb3RlY3Rpb24g c3dpdGNoIHNlbGVjdG9yIHByb2Nlc3MsPGJyPg0KYW5kIHRoaXMgTUVQIFNpbmsgZnVuY3Rpb24g aXMgYXMgc3VjaCB1bmF3YXJlIG9mIHRoZSBwcmVzZW5jZSBvZiBhPGJyPg0KcHJvdGVjdGlvbiBz d2l0Y2ggcHJvY2VzcyBhbmQgb2YgdGhlIHN0YXRlIG9mIHRoZSBwcm90ZWN0aW9uIHN3aXRjaCBw cm9jZXNzLjxicj4NCjxicj4NCkFJUyBpbiBwYWNrZXQgdHJhbnNwb3J0IG5ldHdvcmtzIG11c3Qg Kipub3QqKiB1c2VkIHRvIHRyaWdnZXIgcmVjb3Zlcnk8YnI+DQptZWNoYW5pc21zLiBSZWFzb24g aXMgdGhhdCBBSVMgT0FNIG1lc3NhZ2VzIGluIHBhY2tldCB0cmFuc3BvcnQgbmV0d29yaw0KYXJl PGJyPg0KdG8gYmUgZ2VuZXJhdGVkIHdpdGhpbiAxIHNlY29uZCBhZnRlciB0aGUgZGV0ZWN0aW9u IG9mIHRoZSBzaWduYWwgZmFpbA0KdHlwZTxicj4NCmRlZmVjdCBkZXRlY3Rpb24gYW5kIGJlIGdl bmVyYXRlZCB3aXRoIGEgcGVyaW9kaWNpdHkgb2YgMSBzZWNvbmQuIFRoZXNlPGJyPg0KdGltZXMg YXJlIG11Y2ggdG9vIGxvbmcgdG8gdHJpZ2dlciBhbnkgcmVjb3ZlcnkgbWVjaGFuaXNtLjxicj4N Cjxicj4NClRoZSAxIHNlY29uZCB0aW1lIHJlcXVpcmVtZW50IHRvIGdlbmVyYXRlIHRoZSBmaXJz dCBBSVMgbWVzc2FnZSBpcyBkZXJpdmVkPGJyPg0KZnJvbSB0aGUgMi41ICsvLSAwLjUgc2Vjb25k IGZhdWx0IGNhdXNlIHRvIGZhaWx1cmUgaW50ZWdyYXRpb24gdGltZXIgYXM8YnI+DQpzcGVjaWZp ZWQgaW4gRy43NzEwLiBHZW5lcmF0aW9uIG9mIHRoZSBmaXJzdCBBSVMgbWVzc2FnZSB3aXRoaW4g YSBwZXJpb2QNCm9mPGJyPg0KMSBzZWNvbmQgd2lsbCBsZWF2ZSBlbm91Z2ggdGltZSB0byByZWFj aCB0aGUgZG93bnN0cmVhbSBNRVAgU2luayBmdW5jdGlvbjxicj4NCmFuZCBzdXBwcmVzcyB0aGUg ZmF1bHQgY2F1c2UgdGhhdCByZXBvcnQgdGhlIGludGVycnVwdGlvbiBvZiB0aGUgY29ubmVjdGlv bi48YnI+DQo8YnI+DQpQcm90ZWN0aW9uIHN3aXRjaGluZyBpbiBwYWNrZXQgdHJhbnNwb3J0IG5l dHdvcmtzIGlzIHRyaWdnZXJlZCBieSBlLmcuDQpsb3NzPGJyPg0Kb2YgY29udGludWl0eSBhbmQg bWlzY29ubmVjdGlvbiBkZWZlY3RzLjxicj4NCjxicj4NCkluIHNlY3Rpb24gMi4yIGl0IGlzIHN0 YXRlZDo8YnI+DQomcXVvdDsgJm5ic3A7VGhlIExESSBtZXNzYWdlIGlzIGdlbmVyYXRlZCBpbiBy ZXNwb25zZSB0byBkZXRlY3RpbmcgYSBmYXRhbA0KZmFpbHVyZTxicj4NCiAmbmJzcDsgaW4gdGhl IHNlcnZlciBsYXllci4gJm5ic3A7VGhlIExESSBtZXNzYWdlIE1VU1QgTk9UIGJlIHNlbnQgdW50 aWwNCnRoZTxicj4NCiAmbmJzcDsgZGVmZWN0IGhhcyBiZWVuIGRldGVybWluZWQgdG8gYmUgZmF0 YWwuICZuYnNwO0ZvciBleGFtcGxlIGR1cmluZw0KYTxicj4NCiAmbmJzcDsgcHJvdGVjdGlvbiBz d2l0Y2hpbmcgZXZlbnQgTERJIG1lc3NhZ2VzIGFyZSBub3Qgc2VudC4gJm5ic3A7SG93ZXZlcg0K aWYgdGhlPGJyPg0KICZuYnNwOyBwcm90ZWN0aW9uIHN3aXRjaCB3YXMgdW5zdWNjZXNzZnVsIGlu IHJlc3RvcmluZyB0aGUgbGluayB3aXRoaW4NCnRoZTxicj4NCiAmbmJzcDsgZXhwZWN0ZWQgcmVw YWlyIHRpbWUsIGFuIExESSBtZXNzYWdlIE1VU1QgYmUgc2VudC4mcXVvdDs8YnI+DQphbmQgaW4g c2VjdGlvbiAyLjEgaXQgaXMgc3RhdGVkOjxicj4NCiZxdW90OyAmbmJzcDtUaGUgTVBMUy1UUCBB bGFybSBJbmRpY2F0aW9uIFNpZ25hbCAoQUlTKSBtZXNzYWdlIGlzIGdlbmVyYXRlZA0KaW48YnI+ DQogJm5ic3A7IHJlc3BvbnNlIHRvIGRldGVjdGluZyBkZWZlY3RzIGluIHRoZSBzZXJ2ZXIgbGF5 ZXIuICZuYnNwO1RoZSBBSVMNCm1lc3NhZ2U8YnI+DQogJm5ic3A7IFNIT1VMRCBiZSBzZW50IGFz IHNvb24gaXMgdGhlIGNvbmRpdGlvbiBpcyBkZXRlY3RlZCwgdGhhdCBpcyBiZWZvcmU8YnI+DQog Jm5ic3A7IGFueSBkZXRlcm1pbmF0aW9uIGhhcyBiZWVuIG1hZGUgYXMgdG8gd2hldGhlciB0aGUg Y29uZGl0aW9uIGlzDQpmYXRhbC4mcXVvdDs8YnI+DQo8YnI+DQpUaGlzIGRyYWZ0IHN1Z2dlc3Qg dGhhdCBpdCBpcyBwb3NzaWJsZSBmb3IgYSBNRVAgU2luayBmdW5jdGlvbiB0byBkZXRlcm1pbmU8 YnI+DQppZiB0aGUgZmF1bHQgaXMgKmZhdGFsKiBvciAqbm90IGZhdGFsKi4gVGhpcyBpcyBub3Qg cG9zc2libGUgZm9yIGEgTUVQDQpTaW5rPGJyPg0KZnVuY3Rpb24uIFRoZSByZWFzb24gaXMgdGhh dCBhIE1FUCBTaW5rIGZ1bmN0aW9uIGhhcyBubyBrbm93bGVkZ2Ugb2YgdGhlPGJyPg0KcHJlc2Vu Y2Ugb3Igc3RhdGUgb2YgYSBwcm90ZWN0aW9uIHN3aXRjaCBwcm9jZXNzIGFzc29jaWF0ZWQgd2l0 aCB0aGU8YnI+DQpjb25uZWN0aW9uLiBFLmcuIHRoZSBwcm90ZWN0aW9uIHN3aXRjaCBwcm9jZXNz IG1heSBiZSBpbiBhIGRvd25zdHJlYW0gbm9kZS48YnI+DQo8YnI+DQpJdCBpcyBhbHNvIG5vdCBu ZWNlc3NhcnkgdG8gbWFrZSBBSVMgZ2VuZXJhdGlvbiBjb25kaXRpb25hbCBvbiBlLmcuPGJyPg0K cHJvdGVjdGlvbiBzd2l0Y2ggYWN0aW9ucy4gUmVhc29uIGlzIHRoYXQgYSBwcm90ZWN0aW9uIHN3 aXRjaCBwcm9jZXNzIHdpbGw8YnI+DQpzZWxlY3QgdHJhZmZpYyBmcm9tIGVpdGhlciBhIHdvcmtp bmcgY29ubmVjdGlvbiBpbnB1dCBwb3J0LCBvciBhIHByb3RlY3Rpb248YnI+DQpjb25uZWN0aW9u IGlucHV0IHBvcnQuIEFueSB0cmFmZmljIHByZXNlbnQgb24gdGhlIG5vdCBzZWxlY3RlZCBpbnB1 dCBwb3J0PGJyPg0Kd2lsbCBkcm9wIGF0IHRoaXMgaW5wdXQgcG9ydCBhbmQgbm90IGJlIGZvcndh cmRlZCB0byB0aGUgcHJvdGVjdGlvbiBzd2l0Y2g8YnI+DQpwcm9jZXNzIG91dHB1dCBwb3J0LiBB dCB0aGUgb3V0cHV0IHBvcnQgQUlTIG1lc3NhZ2VzIHdpbGwgYmUgcHJlc2VudCBhcw0KbG9uZzxi cj4NCmFzIHRoZSBwcm90ZWN0aW9uIHN3aXRjaCBwcm9jZXNzIHNlbGVjdHMgaXRzIHRyYWZmaWMg ZnJvbSB0aGUgZmFpbGVkPGJyPg0KY29ubmVjdGlvbjsgb25jZSB0aGUgcHJvdGVjdGlvbiBzd2l0 Y2ggcHJvY2VzcyBzZWxlY3RzIGl0cyB0cmFmZmljIGZyb20NCnRoZTxicj4NCm5vbi1mYWlsZWQg Y29ubmVjdGlvbiBBSVMgbWVzc2FnZXMgd2lsbCBub3QgbG9uZ2VyIGJlIGZvcndhcmRlZCB0byB0 aGU8YnI+DQpvdXRwdXQgcG9ydC48YnI+DQo8YnI+DQpUaGlzIGRyYWZ0IHNob3VsZCBhcyBzdWNo IG5vdCBiZWNvbWUgYSBXRyBkb2N1bWVudC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCk1hYXJ0 ZW48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IG1wbHMt dHAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1wbHMtdHAtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmPGJyPg0KT2YgTG9hIEFuZGVyc3Nvbjxicj4NClNlbnQ6IGRvbmRlcmRhZyAxNyBkZWNl bWJlciAyMDA5IDU6MzY8YnI+DQpUbzogbXBscy10cEBpZXRmLm9yZzsgbXBsc0BpZXRmLm9yZzsg Y2NhbXBAaWV0Zi5vcmc7IHB3ZTNAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBbbXBscy10cF0gUG9s bCBvbSBtYWtpbmc8YnI+DQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXNmdi1tcGxzLXRw LWZhdWx0LTAxLnR4dCBhIHdvcmtpbmcgZ3JvdXA8YnI+DQpkb2N1bWVudDxicj4NCjxicj4NCkFs bCw8YnI+DQo8YnI+DQp0aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtpbmc8 YnI+DQo8YnI+DQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXNmdi1tcGxzLXRwLWZhdWx0 LTAxLnR4dDxicj4NCjxicj4NCmFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVudC48YnI+DQo8 YnI+DQpTZW5kIGEgbWFpbCB0byB0aGUgbXBscy10cEBpZXRmLm9yZyBtYWlsaW5nIGxpc3QsIGlu ZGljYXRpbmcgJnF1b3Q7eWVzL3N1cHBvcnQmcXVvdDs8YnI+DQpvciAmcXVvdDtuby9kbyBub3Qg c3VwcG9ydCZxdW90Oy48YnI+DQo8YnI+DQpDb21tZW50cyBvbiB0aGUgY29udGVudCBvZiB0aGUg ZHJhZnQgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIHNhbWUgbWFpbGluZw0KbGlzdDxicj4NCndpdGgg YSBkaWZmZXJlbnQgc3ViamVjdCBsaW5lLjxicj4NCjxicj4NClRoZSBwb2xsIGVuZHMgRnJpZGF5 IDE1IEphbiwgMjAxMC48YnI+DQo8YnI+DQovTG9hPGJyPg0KLS0gPGJyPg0KPGJyPg0KPGJyPg0K TG9hIEFuZGVyc3NvbiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW1haWw6IGxvYS5hbmRl cnNzb25AZXJpY3Nzb24uY29tPGJyPg0KU3IgU3RyYXRlZ3kgYW5kIFN0YW5kYXJkcyBNYW5hZ2Vy ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bG9hQHBpLm51PGJyPg0K RXJpY3Nzb24gSW5jICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwaG9uZTogKzQ2 IDEwIDcxNyA1MiAxMzxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsrNDYgNzY3IDcyIDkyIDEzPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzLXRwIG1haWxpbmcgbGlzdDxicj4NCm1w bHMtdHBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMtdHA8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCm1wbHMtdHAgbWFpbGluZyBsaXN0PGJyPg0KbXBscy10cEBpZXRmLm9y Zzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscy10cDxicj4N Cjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRp b24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZu YnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3Nv bGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29y Z2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtp cyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92 ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNy ZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJz cDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7 Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7 YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtp dCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7 c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtp bmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5 Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNw O3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3Bs ZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtp biZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNw O2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2Fu ZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4N CjwvcHJlPg== --=_alternative 000976A748257690_=-- From maarten.vissers@huawei.com Fri Dec 18 03:30:18 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D5FA3A6AC5; Fri, 18 Dec 2009 03:30:18 -0800 (PST) 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 CssagUjWcdtP; Fri, 18 Dec 2009 03:30:16 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6558F3A6AA1; Fri, 18 Dec 2009 03:30:16 -0800 (PST) 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 <0KUU00I7HILUNW@szxga03-in.huawei.com>; Fri, 18 Dec 2009 19:29:54 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUU00ABTILUJF@szxga03-in.huawei.com>; Fri, 18 Dec 2009 19:29:54 +0800 (CST) Received: from M00900002 ([10.202.112.160]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUU00IPXILQX7@szxml04-in.huawei.com>; Fri, 18 Dec 2009 19:29:54 +0800 (CST) Date: Fri, 18 Dec 2009 12:29:50 +0100 From: Maarten Vissers In-reply-to: <001901ca7eec$e2179b60$6c02a8c0@china.huawei.com> To: mpls-tp@ietf.org, mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org Message-id: <001a01ca7fd5$6ac557c0$a070ca0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acp+0nx4dPl6Lc1rTuiovDVmelzglwAFWAQgADmfjCA= X-Mailman-Approved-At: Fri, 18 Dec 2009 04:15:01 -0800 Subject: Re: [CCAMP] [mpls-tp] Comment onhttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 11:30:18 -0000 I would like to raise three additional issues in this draft. 1) in section 3 it is stated "The FM Channel uses ACH TLVs and MUST include the ACH TLV header." and "The ACH TLVs may include (but are not limited to) IF-ID, Global-ID, and ICC." AIS and LCK OAM messages should not carry any identifiers, as such identifiers are not read by the receiving MEP. Those identifiers are not providing any useful information to network management or detector circuits. Addition of such identifiers to the AIS and LCK frames adds unnecessary complexities to the designs. 2) In section 4 it is stated "R-flag The R-flag is normally set to zero. A setting of one indicates the removal of a previously sent FM condition." This R-flag is not a helpful feature in AIS and LCK messages. Addition of such flag only increases complexity of the solution and designs. It is a classical item, discussed in previous OAM developments as well. The idea is that the receiver can be explicitly informed about the end of the AIS or LCK condition. Unfortunately it is necessary to take into account that a packet may be dropped due to congestion or bit errors. As such, the AIS and LCK detector circuits in the MEP Sink fucntions must be able to clear the AIS and LCK defects also when such packet with R-flag was lost (which is foreseen in the specification in section 5.3). It is therefore less complex to have the absence of three AIS or LCK packets being used as clearing condition for the AIS and LCK defects. 3) In section 4 it is stated "Refresh Timer The maximum time between successive FM messages specified in seconds. The range is 1 to 65535. The value 0 is not permitted. The default value is 60." The default AIS and LCK repetition period is generically 1-second, not 60-seconds. There is no need for a range of AIS and LCK repetition periods. The first AIS packet for each LSP/PW impacted by the fault has to be generated within 1 second after a signal fail type defect is detected and the next one has to be generated 1-second later. This 1 second period is necessary in order to prevent that downstream the alarms are raised (which happens after 2.5 +/- 0.5 seconds). If the first AIS packet was lost (due to congestion or bit errors) then there is a second AIS packet that will be received by the MEP Sink fucntion before the 2.5 +/- 0.5 second fault cause to failure filter will expire. Either the first or second AIS packet will clear the fault cause and prevent the alarm from being raised. MPLS-TP AIS and LCK OAM packets should be very simple OAM packets including only a Version number and OAM Type (MsgType or OpCode). AIS and LCK OAM packets should be inserted within 1 second after the condition to generate those packets became active and these OAM packets must be send with a 1 second repetition rate. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: donderdag 17 december 2009 8:45 To: 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] Comment onhttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt Some comments on the content of this draft: In section 2.1 it is stated: " <..> For example an AIS message may be sent during a protection switching event and would cease being sent if the protection switch was successful in restoring the link. Its primary purpose is to suppress alarms in the MPLS-TP layer network above the level at which the defect occurs. The AIS message MAY be used to trigger recovery mechanisms. It should be noted that such use would be subject to false positives, e.g. unnecessary protection switching events in the client layer." It is not correct to state that AIS sending is stopped if the protection switch was succesful. The reason is that the AIS insertion is done by a MEP Sink function that is upstream of the protection switch selector process, and this MEP Sink function is as such unaware of the presence of a protection switch process and of the state of the protection switch process. AIS in packet transport networks must **not** used to trigger recovery mechanisms. Reason is that AIS OAM messages in packet transport network are to be generated within 1 second after the detection of the signal fail type defect detection and be generated with a periodicity of 1 second. These times are much too long to trigger any recovery mechanism. The 1 second time requirement to generate the first AIS message is derived from the 2.5 +/- 0.5 second fault cause to failure integration timer as specified in G.7710. Generation of the first AIS message within a period of 1 second will leave enough time to reach the downstream MEP Sink function and suppress the fault cause that report the interruption of the connection. Protection switching in packet transport networks is triggered by e.g. loss of continuity and misconnection defects. In section 2.2 it is stated: " The LDI message is generated in response to detecting a fatal failure in the server layer. The LDI message MUST NOT be sent until the defect has been determined to be fatal. For example during a protection switching event LDI messages are not sent. However if the protection switch was unsuccessful in restoring the link within the expected repair time, an LDI message MUST be sent." and in section 2.1 it is stated: " The MPLS-TP Alarm Indication Signal (AIS) message is generated in response to detecting defects in the server layer. The AIS message SHOULD be sent as soon is the condition is detected, that is before any determination has been made as to whether the condition is fatal." This draft suggest that it is possible for a MEP Sink function to determine if the fault is *fatal* or *not fatal*. This is not possible for a MEP Sink function. The reason is that a MEP Sink function has no knowledge of the presence or state of a protection switch process associated with the connection. E.g. the protection switch process may be in a downstream node. It is also not necessary to make AIS generation conditional on e.g. protection switch actions. Reason is that a protection switch process will select traffic from either a working connection input port, or a protection connection input port. Any traffic present on the not selected input port will drop at this input port and not be forwarded to the protection switch process output port. At the output port AIS messages will be present as long as the protection switch process selects its traffic from the failed connection; once the protection switch process selects its traffic from the non-failed connection AIS messages will not longer be forwarded to the output port. This draft should as such not become a WG document. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: donderdag 17 december 2009 5:36 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] Poll om making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group document All, this is to start a two week poll on making http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Friday 15 Jan, 2010. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From root@core3.amsl.com Fri Dec 18 12:45:02 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2BF023A6AC8; Fri, 18 Dec 2009 12:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091218204502.2BF023A6AC8@core3.amsl.com> Date: Fri, 18 Dec 2009 12:45:02 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-08.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 20:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework Author(s) : D. Fedyk, et al. Filename : draft-ietf-ccamp-gmpls-ethernet-arch-08.txt Pages : 21 Date : 2009-12-18 There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized MPLS based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed and this document provides a framework for these extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ethernet-arch-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-18123059.I-D@ietf.org> --NextPart-- From neil.2.harrison@bt.com Sat Dec 19 06:03:00 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF39A3A69D1; Sat, 19 Dec 2009 06:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 Uv6YN6nNmXbD; Sat, 19 Dec 2009 06:02:59 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 07F533A6825; Sat, 19 Dec 2009 06:02:58 -0800 (PST) Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 19 Dec 2009 14:02:43 +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 Date: Sat, 19 Dec 2009 13:54:38 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C05714578@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <001901ca7eec$e2179b60$6c02a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Comment onhttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt Thread-Index: Acp+0nx4dPl6Lc1rTuiovDVmelzglwAFWAQgAHAay+A= From: To: , , , , , X-OriginalArrivalTime: 19 Dec 2009 14:02:43.0326 (UTC) FILETIME=[EF2681E0:01CA80B3] Subject: Re: [CCAMP] [mpls] Comment onhttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 14:03:01 -0000 I also have some comments on this draft. =20 Major Arch point: ---------------- The key issue here is that the co-ps mode should not be using AIS. It is a mistake to try and copy the co-cs mode. In the co-cs mode labelling and resource allocation are fixed and intrinsically bound together (this is a consequence of using regular fixed-size time-slices of resource). When such a co-cs mode signal 'dies' one simply has to replace it with something (ie a 'resource hole' must be filled with something)...and if we delve back into the history of early PDH path layer networks one will find a binary all 1s signal was the natural traffic signal replacement. In the cl-ps mode we do not have a connection and we thus do not have an a priori fixed client/server relationship...which as an aside is also why we must have a PID label in all cl-ps mode traffic units but we do not require a PID function in co-cs/ps mode traffic units when carrying a single client. However, the key point here is that AIS makes no sense whatsoever for the cl-ps mode. But of course we already know that...if it were not true IP would have adopted it years ago. We can do everything we need using CV for defect detection in the co-ps mode (and where BDI is useful for single ended monitoring and effecting some simple protection-switching cases). We do not require AIS in the co-ps mode. It is just something else that must be consciously generated and thus can go wrong. I do not make the above observation lightly. We have had much internal discussion on this topic several years ago (I started off in favour of co-ps mode AIS) before reaching a somewhat counter-intuitive conclusion that AIS should not be used in co-ps mode layer networks. We should not therefore make this mistake in MPLS-TP IMO...but also see next point. Some related observations: ------------------------- AIS in the co-cs mode is a *replacement for the DP traffic signal*. If one really wanted to emulate the co-cs mode here, the co-ps mode AIS must look as identical as possible to the normal co-ps mode DP traffic unit. In the draft the AIS is using a reserved label (the GAL) that does not normally appear in the *traffic DP*. In fact we should have only allowed the GAL to be used for logically OOB CP/MP protocols and not any OAM DP functions. There are some related issues here that I will not expand on but simply mention in passing as they are germane to fixing MPLS-TP properly: - there should not be a PW layer network above MPLS-TP....PWs are an artefact of the arch problems of LDP and in MPLS-TP would simply represent an unnecessary cost - there should not be arbitrary sublayering in a co-ps mode transport network, ie the S-bit issue...all MPLS-TP LSPs should represent their own layer network. This (and the prior comment on PWs) is important looking ahead to getting the key MPLS-TPoverMPLS-TP client/server relationship correct. - the OAM indicate function should be a part of the normal DP traffic header (and not indicated by adding a further reserved label...esp one that should only be used with the logically OOB CP/MP protocols) - a co-ps mode network has no need for a TTL function in the child traffic units of a parent connection. There is of course still time to get MPLS-TP right in these respects, however I sadly don't see it happening now....which is why, if I am honest, I can't get too excited about whether this draft progresses or not. regards, Neil > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Maarten Vissers > Sent: 17 December 2009 07:45 > To: 'Loa Andersson'; mpls-tp@ietf.org; mpls@ietf.org;=20 > ccamp@ietf.org; pwe3@ietf.org > Subject: [mpls] Comment=20 > onhttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt >=20 >=20 > Some comments on the content of this draft: >=20 > In section 2.1 it is stated:=20 > " <..> > For example an AIS message may be sent during a protection=20 > switching > event and would cease being sent if the protection switch was > successful in restoring the link. >=20 > Its primary purpose is to suppress alarms in the MPLS-TP layer > network above the level at which the defect occurs. The=20 > AIS message > MAY be used to trigger recovery mechanisms. It should be=20 > noted that > such use would be subject to false positives, e.g. unnecessary > protection switching events in the client layer." >=20 > It is not correct to state that AIS sending is stopped if the=20 > protection switch was succesful. The reason is that the AIS=20 > insertion is done by a MEP Sink function that is upstream of=20 > the protection switch selector process, and this MEP Sink=20 > function is as such unaware of the presence of a protection=20 > switch process and of the state of the protection switch process. >=20 > AIS in packet transport networks must **not** used to trigger=20 > recovery mechanisms. Reason is that AIS OAM messages in=20 > packet transport network are to be generated within 1 second=20 > after the detection of the signal fail type defect detection=20 > and be generated with a periodicity of 1 second. These times=20 > are much too long to trigger any recovery mechanism. >=20 > The 1 second time requirement to generate the first AIS=20 > message is derived from the 2.5 +/- 0.5 second fault cause to=20 > failure integration timer as specified in G.7710. Generation=20 > of the first AIS message within a period of > 1 second will leave enough time to reach the downstream MEP=20 > Sink function and suppress the fault cause that report the=20 > interruption of the connection. >=20 > Protection switching in packet transport networks is=20 > triggered by e.g. loss of continuity and misconnection defects. >=20 > In section 2.2 it is stated: > " The LDI message is generated in response to detecting a=20 > fatal failure > in the server layer. The LDI message MUST NOT be sent until the > defect has been determined to be fatal. For example during a > protection switching event LDI messages are not sent. =20 > However if the > protection switch was unsuccessful in restoring the link within the > expected repair time, an LDI message MUST be sent." > and in section 2.1 it is stated: > " The MPLS-TP Alarm Indication Signal (AIS) message is generated in > response to detecting defects in the server layer. The AIS message > SHOULD be sent as soon is the condition is detected, that is before > any determination has been made as to whether the=20 > condition is fatal." >=20 > This draft suggest that it is possible for a MEP Sink=20 > function to determine if the fault is *fatal* or *not fatal*.=20 > This is not possible for a MEP Sink function. The reason is=20 > that a MEP Sink function has no knowledge of the presence or=20 > state of a protection switch process associated with the=20 > connection. E.g. the protection switch process may be in a=20 > downstream node. >=20 > It is also not necessary to make AIS generation conditional on e.g. > protection switch actions. Reason is that a protection switch=20 > process will select traffic from either a working connection=20 > input port, or a protection connection input port. Any=20 > traffic present on the not selected input port will drop at=20 > this input port and not be forwarded to the protection switch=20 > process output port. At the output port AIS messages will be=20 > present as long as the protection switch process selects its=20 > traffic from the failed connection; once the protection=20 > switch process selects its traffic from the non-failed=20 > connection AIS messages will not longer be forwarded to the=20 > output port. >=20 > This draft should as such not become a WG document. >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: donderdag 17 december 2009 5:36 > To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org > Subject: [mpls-tp] Poll om making > http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a=20 > working group document >=20 > All, >=20 > this is to start a two week poll on making >=20 > http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt >=20 > an MPLS working group document. >=20 > Send a mail to the mpls-tp@ietf.org mailing list, indicating=20 > "yes/support" > or "no/do not support". >=20 > Comments on the content of the draft should be sent to the=20 > same mailing list with a different subject line. >=20 > The poll ends Friday 15 Jan, 2010. >=20 > /Loa > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92=20 > 13 _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From zhangfatai@huawei.com Sun Dec 20 19:18:17 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ABAA3A692F for ; Sun, 20 Dec 2009 19:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.194 X-Spam-Level: X-Spam-Status: No, score=-0.194 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 DvXiL5bzm0FL for ; Sun, 20 Dec 2009 19:18:16 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 096E33A68F5 for ; Sun, 20 Dec 2009 19:18:14 -0800 (PST) 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 <0KUZ005RJFTN8K@szxga03-in.huawei.com> for ccamp@ietf.org; Mon, 21 Dec 2009 11:17:47 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUZ00EDUFTN4Y@szxga03-in.huawei.com> for ccamp@ietf.org; Mon, 21 Dec 2009 11:17:47 +0800 (CST) Received: from Z41162C ([10.70.76.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUZ0065ZFTM3L@szxml04-in.huawei.com> for ccamp@ietf.org; Mon, 21 Dec 2009 11:17:47 +0800 (CST) Date: Mon, 21 Dec 2009 11:17:46 +0800 From: Fatai Zhang To: ccamp@ietf.org Message-id: <045501ca81ec$2b35c6d0$604c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: multipart/alternative; boundary="Boundary_(ID_fZqF/CJdDcJO1GXvxYOOLw)" X-Priority: 3 X-MSMail-priority: Normal References: <20091218032629.3BFAC3A685B@core3.amsl.com> Cc: eve.varma@alcatel-lucent.com, malcolm.betts@huawei.com, sergio.belotti@alcatel-lucent.it, pietro_vittorio.grandi@alcatel-lucent.it Subject: [CCAMP] New version for OTN Control Framework //Re: New Version Notification for draft-zhang-ccamp-gmpls-g709-framework-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 03:18:17 -0000 This is a multi-part message in MIME format. --Boundary_(ID_fZqF/CJdDcJO1GXvxYOOLw) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Hi CCAMPers, We have made some significant changes to refine this draft according to the comments from the IETF 76th meeting and CCAMP mailing list. For you convenience, we try to make a summary about the changes as follows: (1) Re-describe Section 3 from the perspective of Control Plane and reference to ITU-T recommendations. (2) Add an appendix to describe LO ODU terminology and ODU connection examples. (3) Re-describe Section 4 (Connection Mangement) and take some contents to the appendix. (4) Remove non-normative stuff, e.g., ODU3ex. (5) Add some editor's notes to clarify some disputes or unclear stuff. We would like to appreciate your comments or suggestions. Thanks with Merry Christmas. Co-authors of this draft ----- Original Message ----- From: "IETF I-D Submission Tool" To: Cc: ; ; ; ; ; ; Sent: Friday, December 18, 2009 11:26 AM Subject: New Version Notification for draft-zhang-ccamp-gmpls-g709-framework-01 > > A new version of I-D, draft-zhang-ccamp-gmpls-g709-framework-01.txt has been successfuly submitted by Fatai Zhang and posted to the IETF repository. > > Filename: draft-zhang-ccamp-gmpls-g709-framework > Revision: 01 > Title: Framework for GMPLS and PCE Control of G.709 Optical Transport Networks > Creation_date: 2009-12-18 > WG ID: Independent Submission > Number_of_pages: 23 > > Abstract: > This document provides a framework to allow the development of > protocol extensions to support Generalized Mulit-Protocol Label > Switching (GMPLS) and Path Computation Element (PCE) control of > Optical Transport Networks (OTN) as specified in ITU-T Recommendation > G.709. > > > > zhang > > > > > > Expires June 2010 > > > > > > [page 1] > > draft-zhang-ccamp-gmpls-g709-framework-01.txt > > > > December 2009 > > > [Note: including the enhanced functionality in the version consented > 10/2009.] > > 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 [RFC2119]. > > > > The IETF Secretariat. > > > --Boundary_(ID_fZqF/CJdDcJO1GXvxYOOLw) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMjkxMiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkhpIENDQU1QZXJzLDwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWw+V2UgaGF2ZSBtYWRlIHNvbWUgc2lnbmlmaWNhbnQgY2hhbmdlcyB0byByZWZpbmUg dGhpcyBkcmFmdCANCmFjY29yZGluZyB0byB0aGUgY29tbWVudHMgZnJvbSB0aGUgSUVURiA3NnRo IG1lZXRpbmcgYW5kIENDQU1QIG1haWxpbmcgDQpsaXN0LjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+ Rm9yIHlvdSBjb252ZW5pZW5jZSwmbmJzcDt3ZSB0cnkgdG8gbWFrZSBhIHN1bW1hcnkgYWJvdXQg DQp0aGUgY2hhbmdlcyBhcyBmb2xsb3dzOjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+KDEpIFJlLWRl c2NyaWJlIFNlY3Rpb24gMyBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBDb250cm9sIA0KUGxhbmUg YW5kIHJlZmVyZW5jZSB0byBJVFUtVCByZWNvbW1lbmRhdGlvbnMuPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsPigyKSBBZGQgYW4gYXBwZW5kaXggdG8gZGVzY3JpYmUgTE8gT0RV IHRlcm1pbm9sb2d5IGFuZCBPRFUgDQpjb25uZWN0aW9uIGV4YW1wbGVzLjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbD4oMykgUmUtZGVzY3JpYmUgU2VjdGlvbiA0IChDb25uZWN0 aW9uIE1hbmdlbWVudCkgYW5kIHRha2UgDQpzb21lIGNvbnRlbnRzIHRvIHRoZSBhcHBlbmRpeC48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+KDQpIFJlbW92ZSBub24tbm9ybWF0 aXZlIHN0dWZmLCBlLmcuLCBPRFUzZXguPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsPig1KSBBZGQgc29tZSBlZGl0b3IncyBub3RlcyB0byBjbGFyaWZ5IHNvbWUgZGlzcHV0ZXMg b3IgDQp1bmNsZWFyIHN0dWZmLjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQt U0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IG1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OiDlrovkvZM7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxGT05UIA0KZmFjZT1Bcmlh bD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWw+V2Ugd291bGQgbGlrZSB0byBhcHByZWNpYXRlIHlvdXIgY29tbWVu dHMgb3IgDQpzdWdnZXN0aW9ucy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+PEZPTlQgZmFj ZT1BcmlhbD48L0ZPTlQ+PEZPTlQgDQpmYWNlPUFyaWFsPjwvRk9OVD4NCjxESVY+PEJSPjxGT05U IGZhY2U9QXJpYWw+VGhhbmtzIHdpdGggTWVycnkgQ2hyaXN0bWFzLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbD48QlI+Jm5ic3A7PEJSPkNvLWF1dGhvcnMgb2YgdGhpcyBkcmFm dDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PEJSPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbD4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRk9OVD4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbD5Gcm9tOiAiSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIiAmbHQ7PC9G T05UPjxBIA0KaHJlZj0ibWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZyI+PEZPTlQgDQpmYWNl PUFyaWFsPmlkc3VibWlzc2lvbkBpZXRmLm9yZzwvRk9OVD48L0E+PEZPTlQgZmFjZT1BcmlhbD4m Z3Q7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPlRvOiAmbHQ7PC9GT05UPjxB IA0KaHJlZj0ibWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbSI+PEZPTlQgDQpmYWNlPUFyaWFs PnpoYW5nZmF0YWlAaHVhd2VpLmNvbTwvRk9OVD48L0E+PEZPTlQgZmFjZT1BcmlhbD4mZ3Q7PC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkNjOiAmbHQ7PC9GT05UPjxBIA0KaHJl Zj0ibWFpbHRvOm1hbGNvbG0uYmV0dHNAaHVhd2VpLmNvbSI+PEZPTlQgDQpmYWNlPUFyaWFsPm1h bGNvbG0uYmV0dHNAaHVhd2VpLmNvbTwvRk9OVD48L0E+PEZPTlQgZmFjZT1BcmlhbD4mZ3Q7OyAN CiZsdDs8L0ZPTlQ+PEEgaHJlZj0ibWFpbHRvOmhhbmppYW5ydWlAaHVhd2VpLmNvbSI+PEZPTlQg DQpmYWNlPUFyaWFsPmhhbmppYW5ydWlAaHVhd2VpLmNvbTwvRk9OVD48L0E+PEZPTlQgZmFjZT1B cmlhbD4mZ3Q7OyAmbHQ7PC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOnNlcmdpby5iZWxvdHRpQGFs Y2F0ZWwtbHVjZW50Lml0Ij48Rk9OVCANCmZhY2U9QXJpYWw+c2VyZ2lvLmJlbG90dGlAYWxjYXRl bC1sdWNlbnQuaXQ8L0ZPTlQ+PC9BPjxGT05UIGZhY2U9QXJpYWw+Jmd0OzsgDQombHQ7PC9GT05U PjxBIGhyZWY9Im1haWx0bzpsaWhhbkBjaGluYW1vYmlsZS5jb20iPjxGT05UIA0KZmFjZT1Bcmlh bD5saWhhbkBjaGluYW1vYmlsZS5jb208L0ZPTlQ+PC9BPjxGT05UIGZhY2U9QXJpYWw+Jmd0Ozsg Jmx0OzwvRk9OVD48QSANCmhyZWY9Im1haWx0bzpkYW5saUBodWF3ZWkuY29tIj48Rk9OVCBmYWNl PUFyaWFsPmRhbmxpQGh1YXdlaS5jb208L0ZPTlQ+PC9BPjxGT05UIA0KZmFjZT1BcmlhbD4mZ3Q7 OyAmbHQ7PC9GT05UPjxBIA0KaHJlZj0ibWFpbHRvOnBpZXRyb192aXR0b3Jpby5ncmFuZGlAYWxj YXRlbC1sdWNlbnQuaXQiPjxGT05UIA0KZmFjZT1BcmlhbD5waWV0cm9fdml0dG9yaW8uZ3JhbmRp QGFsY2F0ZWwtbHVjZW50Lml0PC9GT05UPjwvQT48Rk9OVCANCmZhY2U9QXJpYWw+Jmd0OzsgJmx0 OzwvRk9OVD48QSBocmVmPSJtYWlsdG86ZXZlLnZhcm1hQGFsY2F0ZWwtbHVjZW50LmNvbSI+PEZP TlQgDQpmYWNlPUFyaWFsPmV2ZS52YXJtYUBhbGNhdGVsLWx1Y2VudC5jb208L0ZPTlQ+PC9BPjxG T05UIA0KZmFjZT1BcmlhbD4mZ3Q7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs PlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMTgsIDIwMDkgMTE6MjYgQU08L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWw+U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciANCmRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAxPC9GT05UPjwvRElW PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjxCUj48L0ZPTlQ+PC9ESVY+PEZPTlQgZmFj ZT1BcmlhbD4mZ3Q7IDxCUj4mZ3Q7IEEgbmV3IA0KdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpoYW5n LWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAxLnR4dCBoYXMgYmVlbiANCnN1Y2Nlc3NmdWx5 IHN1Ym1pdHRlZCBieSBGYXRhaSBaaGFuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuPEJSPiZndDsgDQo8QlI+Jmd0OyBGaWxlbmFtZTogZHJhZnQtemhhbmctY2NhbXAtZ21wbHMt ZzcwOS1mcmFtZXdvcms8QlI+Jmd0OyBSZXZpc2lvbjogDQowMTxCUj4mZ3Q7IFRpdGxlOiBGcmFt ZXdvcmsgZm9yIEdNUExTIGFuZCBQQ0UgQ29udHJvbCBvZiBHLjcwOSBPcHRpY2FsIFRyYW5zcG9y dCANCk5ldHdvcmtzPEJSPiZndDsgQ3JlYXRpb25fZGF0ZTogMjAwOS0xMi0xODxCUj4mZ3Q7IFdH IElEOiBJbmRlcGVuZGVudCANClN1Ym1pc3Npb248QlI+Jmd0OyBOdW1iZXJfb2ZfcGFnZXM6IDIz PEJSPiZndDsgPEJSPiZndDsgQWJzdHJhY3Q6PEJSPiZndDsgVGhpcyANCmRvY3VtZW50IHByb3Zp ZGVzIGEgZnJhbWV3b3JrIHRvIGFsbG93IHRoZSBkZXZlbG9wbWVudCBvZiA8QlI+Jmd0OyBwcm90 b2NvbCANCmV4dGVuc2lvbnMgdG8gc3VwcG9ydCBHZW5lcmFsaXplZCBNdWxpdC1Qcm90b2NvbCBM YWJlbCA8QlI+Jmd0OyBTd2l0Y2hpbmcgDQooR01QTFMpIGFuZCBQYXRoIENvbXB1dGF0aW9uIEVs ZW1lbnQgKFBDRSkgY29udHJvbCBvZiA8QlI+Jmd0OyBPcHRpY2FsIFRyYW5zcG9ydCANCk5ldHdv cmtzIChPVE4pIGFzIHNwZWNpZmllZCBpbiBJVFUtVCBSZWNvbW1lbmRhdGlvbiA8QlI+Jmd0OyBH LjcwOS4gDQo8QlI+Jmd0OyZuYnNwOzxCUj4mZ3Q7Jm5ic3A7PEJSPiZndDsmbmJzcDs8QlI+Jmd0 OyB6aGFuZzxCUj4mZ3Q7IDxCUj4mZ3Q7IA0KPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDsgPEJS PiZndDsmbmJzcDsgRXhwaXJlcyBKdW5lIDIwMTA8QlI+Jmd0OyA8QlI+Jmd0OyANCjxCUj4mZ3Q7 IDxCUj4mZ3Q7IDxCUj4mZ3Q7IDxCUj4mZ3Q7Jm5ic3A7W3BhZ2UgMV0gPEJSPiZndDsgPEJSPiZn dDsgDQpkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wMS50eHQ8QlI+Jmd0 OyA8QlI+Jmd0OyA8QlI+Jmd0OyANCjxCUj4mZ3Q7Jm5ic3A7RGVjZW1iZXIgMjAwOSA8QlI+Jmd0 OyZuYnNwOzxCUj4mZ3Q7IDxCUj4mZ3Q7IFtOb3RlOiBpbmNsdWRpbmcgdGhlIA0KZW5oYW5jZWQg ZnVuY3Rpb25hbGl0eSBpbiB0aGUgdmVyc2lvbiBjb25zZW50ZWQgPEJSPiZndDsgMTAvMjAwOS5d IDxCUj4mZ3Q7IA0KPEJSPiZndDsgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IDxC Uj4mZ3Q7IDxCUj4mZ3Q7IFRoZSBrZXkgd29yZHMgDQoiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFV SVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCA8QlI+Jmd0OyAiU0hPVUxEIiwgIlNIT1VMRCAN Ck5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIDxCUj4m Z3Q7IGRvY3VtZW50IGFyZSB0byBiZSANCmludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiANCltS RkMyMTE5XS48QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjxCUj4mZ3Q7 IDxCUj4mZ3Q7IDxCUj4mZ3Q7IFRoZSBJRVRGIFNlY3JldGFyaWF0LjxCUj4mZ3Q7IDxCUj4mZ3Q7 IA0KPEJSPiZndDs8L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_fZqF/CJdDcJO1GXvxYOOLw)-- From hhelvoort@chello.nl Mon Dec 21 08:48:33 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E436828C127; Mon, 21 Dec 2009 08:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.077 X-Spam-Level: * X-Spam-Status: No, score=1.077 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] 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 sPIaeKlrGwd1; Mon, 21 Dec 2009 08:48:33 -0800 (PST) Received: from viefep17-int.chello.at (viefep17-int.chello.at [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id 7B6F128C147; Mon, 21 Dec 2009 08:48:30 -0800 (PST) Received: from edge03.upc.biz ([192.168.13.238]) by viefep17-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091221164812.GPHD18225.viefep17-int.chello.at@edge03.upc.biz>; Mon, 21 Dec 2009 17:48:12 +0100 Received: from McAsterix.local ([24.132.228.153]) by edge03.upc.biz with edge id Kso61d04b3KDBhC03so7AB; Mon, 21 Dec 2009 17:48:12 +0100 X-SourceIP: 24.132.228.153 Message-ID: <4B2FA6C6.4030602@chello.nl> Date: Mon, 21 Dec 2009 17:48:06 +0100 From: Huub van Helvoort User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Maarten Vissers References: <001901ca7eec$e2179b60$6c02a8c0@china.huawei.com> In-Reply-To: <001901ca7eec$e2179b60$6c02a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org, pwe3@ietf.org Subject: Re: [CCAMP] [mpls-tp] Comment on http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hhelvoort@chello.nl List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 16:48:34 -0000 I support the following comments. Regards, Huub. ===================== Maarten Vissers wrote: > Some comments on the content of this draft: > > In section 2.1 it is stated: > " <..> > For example an AIS message may be sent during a protection switching > event and would cease being sent if the protection switch was > successful in restoring the link. > > Its primary purpose is to suppress alarms in the MPLS-TP layer > network above the level at which the defect occurs. The AIS message > MAY be used to trigger recovery mechanisms. It should be noted that > such use would be subject to false positives, e.g. unnecessary > protection switching events in the client layer." > > It is not correct to state that AIS sending is stopped if the protection > switch was succesful. The reason is that the AIS insertion is done by a MEP > Sink function that is upstream of the protection switch selector process, > and this MEP Sink function is as such unaware of the presence of a > protection switch process and of the state of the protection switch process. > > AIS in packet transport networks must **not** used to trigger recovery > mechanisms. Reason is that AIS OAM messages in packet transport network are > to be generated within 1 second after the detection of the signal fail type > defect detection and be generated with a periodicity of 1 second. These > times are much too long to trigger any recovery mechanism. > > The 1 second time requirement to generate the first AIS message is derived > from the 2.5 +/- 0.5 second fault cause to failure integration timer as > specified in G.7710. Generation of the first AIS message within a period of > 1 second will leave enough time to reach the downstream MEP Sink function > and suppress the fault cause that report the interruption of the connection. > > Protection switching in packet transport networks is triggered by e.g. loss > of continuity and misconnection defects. > > In section 2.2 it is stated: > " The LDI message is generated in response to detecting a fatal failure > in the server layer. The LDI message MUST NOT be sent until the > defect has been determined to be fatal. For example during a > protection switching event LDI messages are not sent. However if the > protection switch was unsuccessful in restoring the link within the > expected repair time, an LDI message MUST be sent." > and in section 2.1 it is stated: > " The MPLS-TP Alarm Indication Signal (AIS) message is generated in > response to detecting defects in the server layer. The AIS message > SHOULD be sent as soon is the condition is detected, that is before > any determination has been made as to whether the condition is fatal." > > This draft suggest that it is possible for a MEP Sink function to determine > if the fault is *fatal* or *not fatal*. This is not possible for a MEP Sink > function. The reason is that a MEP Sink function has no knowledge of the > presence or state of a protection switch process associated with the > connection. E.g. the protection switch process may be in a downstream node. > > It is also not necessary to make AIS generation conditional on e.g. > protection switch actions. Reason is that a protection switch process will > select traffic from either a working connection input port, or a protection > connection input port. Any traffic present on the not selected input port > will drop at this input port and not be forwarded to the protection switch > process output port. At the output port AIS messages will be present as long > as the protection switch process selects its traffic from the failed > connection; once the protection switch process selects its traffic from the > non-failed connection AIS messages will not longer be forwarded to the > output port. > > This draft should as such not become a WG document. > > Regards, > Maarten > > -----Original Message----- > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf > Of Loa Andersson > Sent: donderdag 17 december 2009 5:36 > To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org > Subject: [mpls-tp] Poll om making > http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group > document > > All, > > this is to start a two week poll on making > > http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt > > an MPLS working group document. > > Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" > or "no/do not support". > > Comments on the content of the draft should be sent to the same mailing list > with a different subject line. > > The poll ends Friday 15 Jan, 2010. > > /Loa -- ================================================================ http://www.van-helvoort.eu/ ================================================================ Always remember that you are unique...just like everyone else... From web-usrn@ISI.EDU Thu Dec 24 18:31:27 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98EB3A697B for ; Thu, 24 Dec 2009 18:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.982 X-Spam-Level: X-Spam-Status: No, score=-16.982 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_DEF_WHITELIST=-15] 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 7BtGnFXOloDT for ; Thu, 24 Dec 2009 18:31:27 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 07B833A67A3 for ; Thu, 24 Dec 2009 18:31:26 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBP2UbkF016541; Thu, 24 Dec 2009 18:30:38 -0800 (PST) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBP2UabE016539; Thu, 24 Dec 2009 18:30:36 -0800 (PST) Date: Thu, 24 Dec 2009 18:30:36 -0800 (PST) Message-Id: <200912250230.nBP2UabE016539@boreas.isi.edu> To: lberger@movaz.com, rcallon@juniper.net, adrian.farrel@huawei.com, lberger@labn.net, dbrungard@att.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ccamp@ietf.org, duzongpeng@gmail.com, rfc-editor@rfc-editor.org Subject: [CCAMP] [Editorial Errata Reported] RFC3471 (1977) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2009 02:31:27 -0000 The following errata report has been submitted for RFC3471, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3471&eid=1977 -------------------------------------- Type: Editorial Reported by: Zongpeng Du Section: 2 Original Text ------------- Another basic difference between traditional and non-PSC types of generalized MPLS LSPs, is that bandwidth allocation for an LSP can be performed only in discrete units, see Section 3.1.3. Corrected Text -------------- Another basic difference between traditional and non-PSC types of generalized MPLS LSPs, is that bandwidth allocation for an LSP can be performed only in discrete units, see Section 3.1.2. Notes ----- Section 3.1.3 does not exist in the RFC. I guess it should be Section 3.1.2. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3471 (draft-ietf-mpls-generalized-signaling-09) -------------------------------------- Title : Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description Publication Date : January 2003 Author(s) : L. Berger, Ed. Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From db3546@att.com Thu Dec 31 13:14:54 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714563A6831; Thu, 31 Dec 2009 13:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ZrfawpbtPTDr; Thu, 31 Dec 2009 13:14:53 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id A32953A67B6; Thu, 31 Dec 2009 13:14:52 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1262294070!36155397!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 20378 invoked from network); 31 Dec 2009 21:14:31 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2009 21:14:31 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBVLER7s014264; Thu, 31 Dec 2009 16:14:27 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBVLENhK014248; Thu, 31 Dec 2009 16:14:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Dec 2009 16:14:24 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ccamp-gmpls-ether-svcs-04.txt Thread-Index: AcqKXjphiJJxlqi9RuWGfnuq1cU4dA== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "Adrian Farrel" Cc: CCAMP , iesg-secretary@ietf.org Subject: [CCAMP] draft-ietf-ccamp-gmpls-ether-svcs-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 21:14:54 -0000 Proto-write-up for draft-ietf-ccamp-gmpls-ether-svcs-04.txt Intended status: Proposed Standard (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 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. =20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that have been performed? The I-D has had a good level of discussion and review. Several liaisons were exchanged with IEEE, ITU, and MEF during CCAMP's Ethernet work to ensure compatibility and cooperation between the SDOs. (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML? No concerns. =20 (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20 has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue. No concerns. No IPR disclosures have been filed. =20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? WG consensus is solid. =20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.) No threats. =20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts Checklist =20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews? All checks made.=20 =20 (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967]. Three references are in the publication process. References split. No downrefs.=20 =20 (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation? =20 The IANA section looks good. =20 (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker? =20 No formal language is used. =20 (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 Relevant content can frequently be found in the abstract=20 and/or introduction of the document. If not, this may be=20 an indication that there are deficiencies in the abstract=20 or introduction. 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 corresponding to the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line and Ethernet virtual private line services are covered. Support for MEF and ITU defined parameters is also covered. Working Group Summary=20 Was there anything in WG process that is worth noting? For=20 example, was there controversy about particular points or=20 were there decisions where the consensus was particularly=20 rough? No. =20 Document Quality=20 Are there existing implementations of the protocol? Have a=20 significant number of vendors indicated their plan to=20 implement the specification? Are there any reviewers that=20 merit special mention as having done a thorough review,=20 e.g., one that resulted in important changes or a=20 conclusion that the document had no substantive issues? If=20 there was a MIB Doctor, Media Type or other expert review,=20 what was its course (briefly)? In the case of a Media Type=20 review, on what date was the request posted? There are no known implementations, but it is expected that several vendors plan to implement. From db3546@att.com Thu Dec 31 13:24:45 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86F363A688F; Thu, 31 Dec 2009 13:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.426 X-Spam-Level: X-Spam-Status: No, score=-106.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 HJEV1cWGZ7ok; Thu, 31 Dec 2009 13:24:44 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 444E73A68E5; Thu, 31 Dec 2009 13:24:44 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-7.tower-161.messagelabs.com!1262294662!23451765!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 15793 invoked from network); 31 Dec 2009 21:24:23 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2009 21:24:23 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBVLOIjR016957; Thu, 31 Dec 2009 16:24:18 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBVLOE4k016942; Thu, 31 Dec 2009 16:24:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {37B077DF-967C-40E0-8617-94089D4759CA} x-cr-hashedpuzzle: DHA6 GQoV GZbQ GoCn LFAt P9z/ R4q5 Uf1S VFZr WXWz WfDN Z9Cw aLsi bRb/ b/43 coAy; 3; YQBkAHIAaQBhAG4ALgBmAGEAcgByAGUAbABAAGgAdQBhAHcAZQBpAC4AYwBvAG0AOwBjAGMAYQBtAHAAQABpAGUAdABmAC4AbwByAGcAOwBpAGUAcwBnAC0AcwBlAGMAcgBlAHQAYQByAHkAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {37B077DF-967C-40E0-8617-94089D4759CA}; ZABiADMANQA0ADYAQABhAHQAdAAuAGMAbwBtAA==; Thu, 31 Dec 2009 21:24:10 GMT; UABsAGUAYQBzAGUAIABwAHUAYgBsAGkAcwBoACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAGUAdABoAGUAcgBuAGUAdAAtAHQAcgBhAGYAZgBpAGMALQBwAGEAcgBhAG0AZQB0AGUAcgBzAC0AMAA5AC4AdAB4AHQA Content-class: urn:content-classes:message Date: Thu, 31 Dec 2009 16:24:10 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please publish draft-ietf-ccamp-ethernet-traffic-parameters-09.txt Thread-Index: AcqKX5esYn1UKlNxTVWGsEjU8E+yaA== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "Adrian Farrel" Cc: CCAMP , iesg-secretary@ietf.org Subject: [CCAMP] Please publish draft-ietf-ccamp-ethernet-traffic-parameters-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 21:24:45 -0000 Proto-write-up for draft-ietf-ccamp-ethernet-traffic parameters-09.txt =09 Intended status: Proposed Standard (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 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. =20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that have been performed? The I-D has had a good level of discussion and review. Several liaisons were exchanged with IEEE, ITU-T, and MEF during CCAMP's Ethernet work to ensure compatibility and cooperation between the SDOs. (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML? No concerns. =20 (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20 has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue. No concerns. No IPR disclosures have been filed. =20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? WG consensus is solid. =20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.) No threats. =20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts Checklist =20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews? All checks made. A verbose check error on lines being too long. =20 (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967]. One reference to a document in the process of publication. References split. No downrefs.=20 =20 (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation? =20 The IANA section looks good. =20 (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker? =20 No formal language is used. =20 (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 Relevant content can frequently be found in the abstract=20 and/or introduction of the document. If not, this may be=20 an indication that there are deficiencies in the abstract=20 or introduction. This document describes the support of Metro Ethernet Forum (MEF) Ethernet Traffic Parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. Working Group Summary=20 Was there anything in WG process that is worth noting? For=20 example, was there controversy about particular points or=20 were there decisions where the consensus was particularly=20 rough? No. =20 Document Quality=20 Are there existing implementations of the protocol? Have a=20 significant number of vendors indicated their plan to=20 implement the specification? Are there any reviewers that=20 merit special mention as having done a thorough review,=20 e.g., one that resulted in important changes or a=20 conclusion that the document had no substantive issues? If=20 there was a MIB Doctor, Media Type or other expert review,=20 what was its course (briefly)? In the case of a Media Type=20 review, on what date was the request posted? There are no known implementations, but it is expected that several vendors plan to implement. From db3546@att.com Thu Dec 31 13:35:42 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8423A6829; Thu, 31 Dec 2009 13:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.438 X-Spam-Level: X-Spam-Status: No, score=-106.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 yqKqxsAAoc2Y; Thu, 31 Dec 2009 13:35:41 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id F168B3A67B6; Thu, 31 Dec 2009 13:35:40 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1262295319!29844991!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 27004 invoked from network); 31 Dec 2009 21:35:19 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2009 21:35:19 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBVLZF36020073; Thu, 31 Dec 2009 16:35:15 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBVLZBsF020045; Thu, 31 Dec 2009 16:35:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {7E4E42C4-E5FF-4EE3-BFEE-9EB500FC3C3B} x-cr-hashedpuzzle: IgWZ RZEC SKdN Sdq3 S5bj WZal Wf7J X21u YnxU ZQzQ aAd2 abKI ddWQ eHdh hkgc jsnd; 3; YQBkAHIAaQBhAG4ALgBmAGEAcgByAGUAbABAAGgAdQBhAHcAZQBpAC4AYwBvAG0AOwBjAGMAYQBtAHAAQABpAGUAdABmAC4AbwByAGcAOwBpAGUAcwBnAC0AcwBlAGMAcgBlAHQAYQByAHkAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {7E4E42C4-E5FF-4EE3-BFEE-9EB500FC3C3B}; ZABiADMANQA0ADYAQABhAHQAdAAuAGMAbwBtAA==; Thu, 31 Dec 2009 21:35:05 GMT; UABsAGUAYQBzAGUAIABwAHUAYgBsAGkAcwBoACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAGcAbQBwAGwAcwAtAGQAYwBzAGMALQBjAGgAYQBuAG4AZQBsAC0AZQB4AHQALQAwADIALgB0AHgAdAA= Content-class: urn:content-classes:message Date: Thu, 31 Dec 2009 16:35:05 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please publish draft-ietf-ccamp-gmpls-dcsc-channel-ext-02.txt Thread-Index: AcqKYR5G6PFIrP74TdS8S+ywmzi3Pg== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "Adrian Farrel" Cc: CCAMP , iesg-secretary@ietf.org Subject: [CCAMP] Please publish draft-ietf-ccamp-gmpls-dcsc-channel-ext-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 21:35:42 -0000 Proto-write-up for draft-ietf-ccamp-gmpls-dcsc-channel-ext-02.txt Intended status: Proposed Standard (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 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. =20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that have been performed? The I-D has had a good level of discussion and review. (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML? No concerns. =20 (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20 has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue. No concerns. No IPR disclosures have been filed. =20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? WG consensus is solid. =20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.) No threats. =20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts Checklist =20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews? All checks made.=20 =20 (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967]. References split. No downrefs.=20 =20 (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation? =20 The IANA section looks good. =20 (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker? =20 No formal language is used. =20 (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 Relevant content can frequently be found in the abstract=20 and/or introduction of the document. If not, this may be=20 an indication that there are deficiencies in the abstract=20 or introduction. This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching. The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of an LSP. Working Group Summary=20 Was there anything in WG process that is worth noting? For=20 example, was there controversy about particular points or=20 were there decisions where the consensus was particularly=20 rough? No. =20 Document Quality=20 Are there existing implementations of the protocol? Have a=20 significant number of vendors indicated their plan to=20 implement the specification? Are there any reviewers that=20 merit special mention as having done a thorough review,=20 e.g., one that resulted in important changes or a=20 conclusion that the document had no substantive issues? If=20 there was a MIB Doctor, Media Type or other expert review,=20 what was its course (briefly)? In the case of a Media Type=20 review, on what date was the request posted? There are no known implementations, but it is expected that several vendors plan to implement. From db3546@att.com Thu Dec 31 13:44:45 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0133A6831; Thu, 31 Dec 2009 13:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.448 X-Spam-Level: X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 n5aR1B2BchT3; Thu, 31 Dec 2009 13:44:44 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id A2FF03A67E1; Thu, 31 Dec 2009 13:44:44 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-2.tower-161.messagelabs.com!1262295862!16337061!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 13177 invoked from network); 31 Dec 2009 21:44:23 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2009 21:44:23 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBVLiJJE022464; Thu, 31 Dec 2009 16:44:19 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBVLiGV7022459; Thu, 31 Dec 2009 16:44:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {28D4FF23-E17C-443A-BFD3-B4C5CCB53C55} x-cr-hashedpuzzle: ATqK Cp8O DeQI HA0W Hr9Q IxCg KhXg LndA Pw9H TiVz aVWM cLjd ejXa fUFU fWS0 f/6G; 3; YQBkAHIAaQBhAG4ALgBmAGEAcgByAGUAbABAAGgAdQBhAHcAZQBpAC4AYwBvAG0AOwBjAGMAYQBtAHAAQABpAGUAdABmAC4AbwByAGcAOwBpAGUAcwBnAC0AcwBlAGMAcgBlAHQAYQByAHkAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {28D4FF23-E17C-443A-BFD3-B4C5CCB53C55}; ZABiADMANQA0ADYAQABhAHQAdAAuAGMAbwBtAA==; Thu, 31 Dec 2009 21:44:11 GMT; UABsAGUAYQBzAGUAIABwAHUAYgBsAGkAcwBoACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAGcAbQBwAGwAcwAtAG0AZQBmAC0AdQBuAGkALQAwADMALgB0AHgAdAA= Content-class: urn:content-classes:message Date: Thu, 31 Dec 2009 16:44:11 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please publish draft-ietf-ccamp-gmpls-mef-uni-03.txt Thread-Index: AcqKYmPMzGE9tubcS1C62KZN+MC/nQ== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "Adrian Farrel" Cc: CCAMP , iesg-secretary@ietf.org Subject: [CCAMP] Please publish draft-ietf-ccamp-gmpls-mef-uni-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 21:44:46 -0000 Proto-write-up for draft-ietf-ccamp-gmpls-mef-uni-03.txt Intended status: Proposed Standard (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 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. =20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that have been performed? The I-D has had a good level of discussion and review. Several liaisons were exchanged with IEEE, ITU, and MEF during CCAMP's Ethernet work to ensure compatibility and cooperation between the SDOs. (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML? No concerns. =20 (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20 has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue. No concerns. No IPR disclosures have been filed. =20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? WG consensus is solid. =20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.) No threats. =20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts Checklist =20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews? All checks made.=20 =20 (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967]. Two references are in the publication process. References split. No downrefs.=20 =20 (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation? =20 The IANA section looks good. =20 (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker? =20 No formal language is used. =20 (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 Relevant content can frequently be found in the abstract=20 and/or introduction of the document. If not, this may be=20 an indication that there are deficiencies in the abstract=20 or introduction. This document describes a method for controlling two specific types of Ethernet switching via a Generalized Multi-Protocol Label Switching (GMPLS) based User-Network Interface (UNI). This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. Working Group Summary=20 Was there anything in WG process that is worth noting? For=20 example, was there controversy about particular points or=20 were there decisions where the consensus was particularly=20 rough? No. =20 Document Quality=20 Are there existing implementations of the protocol? Have a=20 significant number of vendors indicated their plan to=20 implement the specification? Are there any reviewers that=20 merit special mention as having done a thorough review,=20 e.g., one that resulted in important changes or a=20 conclusion that the document had no substantive issues? If=20 there was a MIB Doctor, Media Type or other expert review,=20 what was its course (briefly)? In the case of a Media Type=20 review, on what date was the request posted? There are no known implementations, but it is expected that several vendors plan to implement. From db3546@att.com Thu Dec 31 14:14:22 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D15063A67B6; Thu, 31 Dec 2009 14:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.457 X-Spam-Level: X-Spam-Status: No, score=-106.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 79EWYTh01QaH; Thu, 31 Dec 2009 14:14:21 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 0828C3A67B5; Thu, 31 Dec 2009 14:14:20 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-2.tower-146.messagelabs.com!1262297640!21614330!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 24481 invoked from network); 31 Dec 2009 22:14:01 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2009 22:14:01 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBVMDtOv029784; Thu, 31 Dec 2009 17:13:55 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id nBVMDqnk029775; Thu, 31 Dec 2009 17:13:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {8728BAE3-29AB-4EA5-AA91-07A6794789E8} x-cr-hashedpuzzle: CefQ CefX DZ6s EI4w HlOP HwRJ KT6c Mz9N PRHo PiJz QFpp QbJC VlbO bVC1 cIuq fWfw; 3; YQBkAHIAaQBhAG4ALgBmAGEAcgByAGUAbABAAGgAdQBhAHcAZQBpAC4AYwBvAG0AOwBjAGMAYQBtAHAAQABpAGUAdABmAC4AbwByAGcAOwBpAGUAcwBnAC0AcwBlAGMAcgBlAHQAYQByAHkAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {8728BAE3-29AB-4EA5-AA91-07A6794789E8}; ZABiADMANQA0ADYAQABhAHQAdAAuAGMAbwBtAA==; Thu, 31 Dec 2009 22:13:47 GMT; UABsAGUAYQBzAGUAIABwAHUAYgBsAGkAcwBoACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAGwAcwBwAC0AaABpAGUAcgBhAHIAYwBoAHkALQBiAGkAcwAtADAANwAuAHQAeAB0AA== Content-class: urn:content-classes:message Date: Thu, 31 Dec 2009 17:13:47 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please publish draft-ietf-ccamp-lsp-hierarchy-bis-07.txt Thread-Index: AcqKZoYK7xUm0xwkQk2YHzMBRD+jXA== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "Adrian Farrel" Cc: CCAMP , iesg-secretary@ietf.org Subject: [CCAMP] Please publish draft-ietf-ccamp-lsp-hierarchy-bis-07.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2009 22:14:22 -0000 Proto-write-up for draft-ietf-ccamp-lsp-hierarchy-bis-07.txt Intended status: Proposed Standard (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 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. =20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that have been performed? The I-D has had a good level of discussion and review. (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML? No concerns. =20 (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20 has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue. No concerns. No IPR disclosures have been filed. =20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? WG consensus is solid. =20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20 discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.) No threats. =20 (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts Checklist =20 and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews? All checks made.=20 =20 (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967]. References split. No downrefs.=20 =20 (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation? =20 The IANA section looks good. =20 (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker? =20 No formal language is used. =20 (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 Relevant content can frequently be found in the abstract=20 and/or introduction of the document. If not, this may be=20 an indication that there are deficiencies in the abstract=20 or introduction. Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks. Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle TE links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. The mechanisms defined in this document deprecates the technique for the signaling of LSPs that are to be used as numbered TE links described in RFC 4206. Working Group Summary=20 Was there anything in WG process that is worth noting? For=20 example, was there controversy about particular points or=20 were there decisions where the consensus was particularly=20 rough? No. As this document deprecates a technique used in RFC4206, an informal survey was done and it was established that no implementations exist using that technique. =20 Document Quality=20 Are there existing implementations of the protocol? Have a=20 significant number of vendors indicated their plan to=20 implement the specification? Are there any reviewers that=20 merit special mention as having done a thorough review,=20 e.g., one that resulted in important changes or a=20 conclusion that the document had no substantive issues? If=20 there was a MIB Doctor, Media Type or other expert review,=20 what was its course (briefly)? In the case of a Media Type=20 review, on what date was the request posted? There are no known implementations, but it is expected that several vendors plan to implement.