From daniele.ceccarelli@ericsson.com Mon Feb 1 06:53:20 2010 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 7D6FF28C0E4 for ; Mon, 1 Feb 2010 06:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 ispilq5X5-ew for ; Mon, 1 Feb 2010 06:53:18 -0800 (PST) Received: from mailgw10.se.ericsson.net (unknown [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id EB6B23A6946 for ; Mon, 1 Feb 2010 06:53:17 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-c1-4b66eafe28b9 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id DA.4A.02429.EFAE66B4; Mon, 1 Feb 2010 15:53:51 +0100 (CET) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 15:53:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAA34E.5CD2E1DF" Date: Mon, 1 Feb 2010 15:53:49 +0100 Message-ID: In-Reply-To: <11DE3EEC54A8A44EAD99D8C0D3FD7207951DA198F9@ENFIMBOX1.ad.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Comments on draft draft-ietf-ccamp-pc-spc-rsvpte-ext-06 Thread-Index: AcqZA2vCyTtNSlvFTzWPr3zR3WKwzQAv68RQAG2DArAAAngjEAHymLwA References: <11DE3EEC54A8A44EAD99D8C0D3FD7207951D944BDA@ENFIMBOX1.ad.datcon.co.uk> <11DE3EEC54A8A44EAD99D8C0D3FD7207951DA198F9@ENFIMBOX1.ad.datcon.co.uk> From: "Daniele Ceccarelli" To: "Alan Elder" X-OriginalArrivalTime: 01 Feb 2010 14:53:50.0221 (UTC) FILETIME=[5D568BD0:01CAA34E] X-Brightmail-Tracker: AAAAAA== Cc: ccamp@ietf.org Subject: Re: [CCAMP] Comments on draft draft-ietf-ccamp-pc-spc-rsvpte-ext-06 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, 01 Feb 2010 14:53:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA34E.5CD2E1DF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alan, =20 yes, i think the discussion must be kept public on the mailing list but = i simply made a mistake pressing Reply, instead of Reply to All. =20 Just few further comments to conclude our discussion: =20 - Bullets 2) and 3): I think you're right. I hope it is still possible = to modify the ID. If so i'll introduce the piece of text you suggest. =20 "While the H bit is set in Path state, a node MUST NOT send a PathTear = when a failure is detected. Instead, the failure is reported upstream = using a PathErr. The only node that can send a PathTear is the ingress = node, and it can only do this as a step in the procedures specified in = this document. This applies to both MP to CP and CP to MP handover."=20 =20 - Bullet 4): Last time i said you were right, an indeed you wuold be if = the sentence you're referring to was not inside section 4.1: 4.1. MP to CP handover: LSP Ownership Transfer From Management Plane To Control Plane =20 so it is correct that it only refers to MP to CP handover and not to CP = to MP :-) =20 Thank you once again for you comments =20 BR Daniele ________________________________ From: Alan Elder [mailto:Alan.Elder@metaswitch.com]=20 Sent: venerd=EC 22 gennaio 2010 18.00 To: Daniele Ceccarelli Subject: RE: [CCAMP] Comments on draft = draft-ietf-ccamp-pc-spc-rsvpte-ext-06 Hi Daniele, =20 Thanks for your comments - see answers to your specific questions = in-line [ADE]. I would summarise my comments as: =20 CP to MP handover has some bugs with regard to handover failure. The = principle for how this should work as described in the draft (failure = results in state returning to how it was before the handover) is good - = the bugs just need ironing out. =20 >From your comments below it looks like you agree with this. =20 =20 I'm new to CCAMP, so am not quite up with procedures yet - should we be = having this discussion on the mailing list? =20 Cheers, =20 Alan =20 ________________________________ From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]=20 Sent: 21 January 2010 16:43 To: Alan Elder Subject: RE: [CCAMP] Comments on draft = draft-ietf-ccamp-pc-spc-rsvpte-ext-06 Hi Alan, =20 please find my answers inline [DC]. =20 Best regards Daniele ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Alan Elder Sent: marted=EC 19 gennaio 2010 13.32 To: ccamp@ietf.org Subject: [CCAMP] Comments on draft draft-ietf-ccamp-pc-spc-rsvpte-ext-06 ccamp, =20 The main MP to CP procedure looks good. It's not clear whether the = secondary MP to CP procedure is a core requirement or an optional extra. =20 I think CP to MP handover has some bugs, relating to when PathTears are = sent. Detailed comments and suggestions below. =20 Cheers, Alan. =20 =20 1) Is the alternative MP to CP procedure MUST or MAY? I suggest "MAY" Section 4 describes "primary" and "alternative" MP to CP procedures. I = suggest we should mark these respectively as MUST and MAY, as indicated = in Section 3. It's good to have a minimal subset of procedures marked = as MUST. =20 A note in section 5 gives both alternatives equal weight. This doesn't = seem right - we don't want some implementations doing one and some doing = the other. I suggest we remove this: "The full ERO method and the partial/no ERO one do not exclude each = other; both methods are required." =20 If the alternative method MAY be implemented, we need to clarify the = error reported by a transit node that does not support the alternative = mechanism. I suggest using a PathErr with the Handover Failed error = code, this could be added to Section 4.1. =20 [DC] The utilization of the full ERO is considered as an optional from = the WG consensus. This is why both procedures are required. =20 =20 2) Where can PathTear flow during CP to MP handover? I suggest = "nowhere" Section 4.4 states: "...the ingress node MUST NOT send a PathTear = message before a Resv message containing the H bit is received." This is right - a PathTear would transfer resources to the management = plane prematurely. But why does this apply specially to ingress? A = PathTear originated from a transit node would also cause premature = transfer of LSP ownership. I suggest PathTear should not be sent by any = node during handover (see text below).=20 [DC] Could you please provide an example? In which case a transit LSR = sends a PathTear after the Handover procedure is in progress? (i.e. Path = message with R, H and D flags already processed)=20 [ADE] See the attached diagram. This failure mode is similar to that = described in section 4.2.2.1 of the draft for MP to CP handover. The = cause of the failure could be, for example, an upstream interface = failure. =20 =20 3) CP to MP handover procedures do not maintain the LSP on failure The procedure in section 7.2 is good for MP to CP handover. But for CP = to MP handover, sending a PathTear will not achieve the stated objective = of keeping the LSP in place and CP owned. In order to do that, the = PathErr/PathTear procedures need to be modified so that the ingress node = receives PathErr and resignals the Path with H clear.=20 =20 I suggest the following as the definition for PathErr/PathTear = procedures, covering points (2) and (3). =20 "While the H bit is set in Path state, a node MUST NOT send a PathTear = when a failure is detected. Instead, the failure is reported upstream = using a PathErr. The only node that can send a PathTear is the ingress = node, and it can only do this as a step in the procedures specified in = this document. This applies to both MP to CP and CP to MP handover." =20 [DC] you're probably right, i was wondering if this changes legacy RSVP = behavior. Does it? =20 [ADE] I'm only proposing changing PathTear/PathErr processing when the H = bit is set - so this does not affect legacy RSVP behaviour. How RSVP = behaves for transit nodes sending PathTears is described in = http://tools.ietf.org/html/rfc3473#section-4.4. =20 4) Bug in CP to MP procedures, introduced in -05 This was added to Section 4.1 as part of revision -05 " Each LSR that receives a Path message with the H bit set checks to see = whether there is any matching Path state. - If matching Path state is found with the H bit set, this is a Path = refresh and should be treated accordingly [RFC3473]. - If matching Path state is found with the H bit clear, this is an error = and MUST be treated according to the error case description in Section = 4.2.1.1" =20 This is fine for MP to CP handover. But CP to MP procedures expect to = find matching Path state with the H bit clear. How can the second = bullet be supported without disabling CP to MP procedures? =20 I suggest this second bullet is updated to indicate that this case is = treated according to CP to MP procedures. If CP to MP handover is not = supported on the node then it is treated with PathErr(Handover Failed). [DC] you're right.=20 =20 5) "All nodes along the path MUST support"? This seems unusual. Section 8 states that "all nodes along the path MUST support the = extension defined in this draft". Otherwise "This may result in an = impact on data traffic during the handover procedure."=20 =20 This is unusual behaviour for a new signaling procedure. Usually, lack = of support for a signaling feature on some LSRs results in a graceful = (signaled) failure when the feature is used. In this case, it results = in undetected loss of an LSP. =20 [DC] All the nodes of the LSP must support the handover procedure = because in case of CP to MP the node not supporting the handover = procedure would delete the LSP. =20 It is worth clarifying that not all parts of this draft MUST be = supported by all nodes - rather just the mandatory parts must be = supported. For example, if some nodes support the optional CP to MP = handover and some do not, then CP to MP failure is signalled gracefully = using PathErr signalling (see point 4 above). Also if some nodes = support the alternative MP to CP method, and some do not, then MP to CP = failure is signalled gracefully (see point 1 above).=20 ------_=_NextPart_001_01CAA34E.5CD2E1DF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Alan,
 
yes, i=20 think the discussion must be kept public on the mailing list but i = simply=20 made a mistake pressing Reply, instead of Reply to = All.
 
Just=20 few further comments to conclude our discussion:
 
-=20 Bullets 2) and 3): I think you're right. I hope it is still possible to = modify=20 the ID. If so i'll introduce the piece of text you = suggest.
 
"While the H bit is set in = Path=20 state, a node MUST NOT send a PathTear when a failure is detected.  = Instead, the failure is reported upstream using a PathErr.  The = only node=20 that can send a PathTear is the ingress node, and it can only do = this as a=20 step in the procedures specified in this document. This applies to both = MP to CP=20 and CP to MP handover." 
 
- Bullet 4): Last time i said you = were right, an=20 indeed you wuold be if the sentence you're referring to was=20 not inside section 4.1:
4.1.  MP to CP handover: LSP =
Ownership Transfer From Management Plane To

      Control =
Plane
 
so it=20 is correct that it only refers to MP to CP handover and not to CP to MP=20 :-)
 
Thank=20 you once again for you comments
 
BR
Daniele

From: Alan Elder=20 [mailto:Alan.Elder@metaswitch.com]
Sent: venerd=EC 22 gennaio = 2010=20 18.00
To: Daniele Ceccarelli
Subject: RE: [CCAMP] = Comments=20 on draft draft-ietf-ccamp-pc-spc-rsvpte-ext-06

Hi=20 Daniele,
 
Thanks=20 for your comments  - see answers = to=20 your specific questions in-line=20 [ADE].  I would summarise my comments = as:
 
CP to=20 MP handover has some bugs with regard to handover = failure.  The=20 principle for how this should work as described in the draft = (failure=20 results in state returning to how it was before the handover) is good - = the bugs=20 just need ironing out.
 
From=20 your comments below it looks like you agree with = this.
 
 
I'm=20 new to CCAMP, so am not quite up with procedures yet - should we be = having this=20 discussion on the mailing list?
 
Cheers,
 
Alan
 

From: Daniele Ceccarelli=20 [mailto:daniele.ceccarelli@ericsson.com]
Sent: 21 January = 2010=20 16:43
To: Alan Elder
Subject: RE: [CCAMP] Comments = on draft=20 draft-ietf-ccamp-pc-spc-rsvpte-ext-06

Hi=20 Alan,
 
please=20 find my answers inline [DC].
 
Best=20 regards
Daniele

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of Alan = Elder
Sent:=20 marted=EC 19 gennaio 2010 13.32
To: = ccamp@ietf.org
Subject:=20 [CCAMP] Comments on draft=20 draft-ietf-ccamp-pc-spc-rsvpte-ext-06

ccamp,

 

The main MP to=20 CP procedure looks good.  It's not clear whether the = secondary MP to CP procedure is a core requirement or an optional=20 extra.

 

I think CP to MP = handover has=20 some bugs, relating to when PathTears are sent.  Detailed comments = and=20 suggestions below.

 

Cheers,

Alan.   =20

 

1)  Is the = alternative MP to CP=20 procedure MUST or MAY?  I suggest = "MAY"

Section 4 describes = "primary" and=20 "alternative" MP to CP procedures.  I suggest we should mark = these=20 respectively as MUST and MAY, as indicated in Section 3.  It's good = to=20 have a minimal subset of procedures marked as=20 MUST.

 

A note in section = 5 gives=20 both alternatives equal weight.  This doesn't seem = right -=20 we don't want some implementations doing one and some doing the = other.  I=20 suggest we remove this:

"The full ERO method and = the=20 partial/no ERO one do not exclude each other; both methods are=20 required."

 

If the alternative method = MAY be=20 implemented, we need to clarify the error reported by a = transit=20 node that does not support the alternative mechanism.  I suggest using a PathErr=20 with the Handover Failed error code, this could be added=20 to Section 4.1.  

[DC] The utilization = of the full=20 ERO is considered as an optional from the WG consensus. This is why = both=20 procedures are required.

 

 

2)  Where can = PathTear=20 flow during CP to MP handover?  I suggest=20 "nowhere"

Section 4.4 states: = "...the ingress=20 node MUST NOT send a PathTear message before a Resv message containing = the H bit=20 is received."

This is right =96 a = PathTear would=20 transfer resources to the management plane prematurely.  But why does this apply = specially to=20 ingress?  A PathTear originated from a transit node would also = cause=20 premature transfer of LSP ownership. =20 I suggest PathTear should not be sent by any node during = handover=20 (see text below). 

[DC] Could you please = provide an=20 example? In which case a transit LSR sends a PathTear after the Handover = procedure is in progress? (i.e. Path message with R, H and D flags = already=20 processed) 

[ADE] See the attached=20 diagram.  This failure mode is similar to that described = in=20 section 4.2.2.1 of the draft for MP to CP handover. The cause of = the failure=20 could be, for example, an upstream interface = failure.    

 

3)  CP to MP handover = procedures do not maintain the LSP on = failure

The procedure in section = 7.2 is=20 good for MP to CP handover.  But for CP to MP handover, = sending a=20 PathTear will not achieve the stated objective of keeping the LSP in = place and CP owned.  In order to do = that, the=20 PathErr/PathTear procedures need to be modified so that the ingress node = receives PathErr and resignals the Path with H clear. 

 

I suggest the following=20 as the definition for=20 PathErr/PathTear procedures, covering points (2) and=20 (3).

 

"While the H bit is set in = Path=20 state, a node MUST NOT send a PathTear when a failure is detected.  = Instead, the failure is reported upstream using a PathErr.  The = only node=20 that can send a PathTear is the ingress node, and it can only do = this as a=20 step in the procedures specified in this document. This applies to both = MP to CP=20 and CP to MP handover."  

[DC] you're probably right, i was wondering if this = changes=20 legacy RSVP behavior. Does it?    

[ADE] I'm only = proposing changing=20 PathTear/PathErr processing when the H bit is set - so this does not = affect=20 legacy RSVP behaviour.  How RSVP behaves for transit nodes sending=20 PathTears is described in http://tools.ietf= .org/html/rfc3473#section-4.4.

 

4)  Bug in CP to = MP=20 procedures, introduced in -05

This was added to Section = 4.1 as=20 part of revision -05
" Each LSR that receives a Path message with the = H bit=20 set checks to see whether there is any matching Path=20 state.

- If matching Path state = is found=20 with the H bit set, this is a Path refresh and should be treated = accordingly=20 [RFC3473].
- If matching Path state is found with the H bit clear, = this is an=20 error and MUST be treated according to the error case description in = Section=20 4.2.1.1"

 

This is fine for MP to CP=20 handover.  But CP to MP procedures expect to find = matching Path=20 state with the H bit clear.  How can the second bullet be supported = without=20 disabling CP to MP procedures?

 

I suggest this second = bullet is=20 updated to indicate that this case is treated according to CP to=20 MP procedures.  If CP = to MP=20 handover is not supported on the node then it=20 is treated with PathErr(Handover = Failed).

[DC] you're right.

 

5)  "All nodes along = the=20 path MUST support"? This seems unusual.

Section 8 states that=20 =93all nodes along the path MUST support the extension defined in = this=20 draft=94.  Otherwise "This may result in an impact on data traffic = during the=20 handover procedure." 

 

This is unusual behaviour = for a new=20 signaling procedure.  Usually, lack of support for a signaling = feature on=20 some LSRs results in a graceful (signaled) failure when the feature is=20 used.  In this case, it results in undetected loss of an = LSP.  

[DC] All the nodes of the LSP must support the handover = procedure=20 because in case of CP to MP the node not supporting the handover = procedure=20 would delete the LSP.

 

It=20 is worth clarifying that not all parts of this draft MUST be supported = by all=20 nodes =96 rather just the mandatory parts must be supported.  For example, if some nodes = support the=20 optional CP to MP handover and some do not, then CP to MP failure is = signalled=20 gracefully using PathErr signalling (see point 4 above).  Also if some nodes support the = alternative MP to CP method, and some do not, then MP to CP failure is = signalled=20 gracefully (see point 1 = above). 
------_=_NextPart_001_01CAA34E.5CD2E1DF-- From root@core3.amsl.com Mon Feb 1 09:00:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 496293A6975; Mon, 1 Feb 2010 09: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: <20100201170002.496293A6975@core3.amsl.com> Date: Mon, 1 Feb 2010 09:00:02 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D ACTION:draft-ietf-ccamp-gmpls-mln-extensions-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: Mon, 01 Feb 2010 17: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 : 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-11.txt Pages : 25 Date : 2010-2-1 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-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-gmpls-mln-extensions-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-2-1085731.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Feb 1 14:45:01 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 937313A6869; Mon, 1 Feb 2010 14:45: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: <20100201224501.937313A6869@core3.amsl.com> Date: Mon, 1 Feb 2010 14:45:01 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-framework-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, 01 Feb 2010 22:45: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 : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-rwa-wson-framework-05.txt Pages : 58 Date : 2010-02-01 This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. In addition, electro-optical network elements and their compatibility constraints relative to optical signal parameters are characterized. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation architectures that could be realized via various combinations of extended GMPLS and PCE protocols. This memo focuses on topological elements and path selection constraints that are common across different WSON environments as such it does not address optical impairments in any depth. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-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-rwa-wson-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-01143908.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Tue Feb 2 07:06:53 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 760B83A6B15; Tue, 2 Feb 2010 07:06:53 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100202150653.760B83A6B15@core3.amsl.com> Date: Tue, 2 Feb 2010 07:06:53 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: draft-ietf-ccamp-gmpls-mln-extensions (Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)) to Proposed Standard 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: Tue, 02 Feb 2010 15:06:53 -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) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-02-16. 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-mln-extensions-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16532&rfc_flag=0 From dschroet@cisco.com Wed Feb 3 05:35:03 2010 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 0751E3A6921 for ; Wed, 3 Feb 2010 05:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ihtELaHbiqo1 for ; Wed, 3 Feb 2010 05:35:02 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BA2393A689C for ; Wed, 3 Feb 2010 05:35:01 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEBAI4KaUuQ/uCWe2dsb2JhbACbQQEBFiQGpDSYHoRFBA X-IronPort-AV: E=Sophos;i="4.49,397,1262563200"; d="scan'208";a="56747033" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2010 13:35:42 +0000 Received: from dhcp-10-61-100-185.cisco.com (dhcp-10-61-100-185.cisco.com [10.61.100.185]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o13DZaMM015048 for ; Wed, 3 Feb 2010 13:35:41 GMT From: Dirk Schroetter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Feb 2010 14:35:35 +0100 Message-Id: <255243C7-1AD7-4F76-9744-8DDE22130674@cisco.com> To: ccamp@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [CCAMP] Q on FEC type in 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: Wed, 03 Feb 2010 13:35:03 -0000 Folks, is there a particular reason why the FEC type Sub-TLV only makes = provisions for FEC types defined in G.709/G.709V as standard FEC types ? = I understand that vendor-secific ones are supported, but why not extend = the list of "standard" ones by the FEC types defined in G.975.1 (even = though they strictly would only apply to submarine systems) ? Best Regards, /Dirk= From ylee@huawei.com Wed Feb 3 07:52:09 2010 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 E0E9F28C14D for ; Wed, 3 Feb 2010 07:52:09 -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 8XAC9TUKIctV for ; Wed, 3 Feb 2010 07:52:08 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 9E3E528C119 for ; Wed, 3 Feb 2010 07:52:08 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX900F9UW427G@usaga04-in.huawei.com> for ccamp@ietf.org; Wed, 03 Feb 2010 09:52:50 -0600 (CST) Received: from L73682 ([10.124.12.56]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KX900LNRW3YO1@usaga04-in.huawei.com> for ccamp@ietf.org; Wed, 03 Feb 2010 09:52:50 -0600 (CST) Date: Wed, 03 Feb 2010 09:52:45 -0600 From: Young Lee In-reply-to: <255243C7-1AD7-4F76-9744-8DDE22130674@cisco.com> To: 'Dirk Schroetter' , ccamp@ietf.org Message-id: <001501caa4e8$ee1b60a0$380c7c0a@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: Acqk1dOwDL8ZQiobT+aOpE6jDaEwyAAEkXww References: <255243C7-1AD7-4F76-9744-8DDE22130674@cisco.com> Subject: Re: [CCAMP] Q on FEC type indraft-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: Wed, 03 Feb 2010 15:52:10 -0000 Hi Dirk, We have updated the FEC type Sub-TLV that incorporates G.975.1. The update will be shortly published. They are at the minimum: FEC ID -------- 3 G.975.1 Concatenated FEC (RS(255,239)/CSOC(n0/k0=7/6,J=8)) 4 G.975.1 Concatenated FEC (BCH(3860,3824)/BCH(2040,1930)) 5 G.975.1 Concatenated FEC (RS(1023,1007)/BCH(2407,1952)) 6 G.975.1 Concatenated FEC (RS(1901,1855)/Extended Hamming Product Code (512,502)X(510,500)) 7 G.975.1 LDPC Code 8 G.975.1 Concatenated FEC (Two orthogonally concatenated BCH codes) 9 G.975.1 RS(2720,2550) 10 G.975.1 Concatenated FEC (Two interleaved extended BCH (1020,988) codes) Where RS stands for Reed-Solomon and BCH for Bose-Chaudhuri-Hocquengham. If you have any question, please let me know. Thanks. Regards, Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Dirk Schroetter Sent: Wednesday, February 03, 2010 7:36 AM To: ccamp@ietf.org Subject: [CCAMP] Q on FEC type indraft-ietf-ccamp-wson-signal-compatibility-ospf-00.txt Folks, is there a particular reason why the FEC type Sub-TLV only makes provisions for FEC types defined in G.709/G.709V as standard FEC types ? I understand that vendor-secific ones are supported, but why not extend the list of "standard" ones by the FEC types defined in G.975.1 (even though they strictly would only apply to submarine systems) ? Best Regards, /Dirk _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From dschroet@cisco.com Wed Feb 3 08:07:49 2010 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 D56C228C0D9 for ; Wed, 3 Feb 2010 08:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 mCtxWEYCnl9m for ; Wed, 3 Feb 2010 08:07:49 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7664C3A6864 for ; Wed, 3 Feb 2010 08:07:48 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEBANEtaUuQ/uCWe2dsb2JhbACbQQEBFiQGpR6YEYRFBA X-IronPort-AV: E=Sophos;i="4.49,399,1262563200"; d="scan'208,217";a="56753157" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2010 16:08:30 +0000 Received: from ams3-vpn-dhcp6309.cisco.com (ams3-vpn-dhcp6309.cisco.com [10.61.88.164]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o13G8PPK019761; Wed, 3 Feb 2010 16:08:28 GMT Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-4--856704686 From: Dirk Schroetter In-Reply-To: <001501caa4e8$ee1b60a0$380c7c0a@china.huawei.com> Date: Wed, 3 Feb 2010 17:08:24 +0100 Message-Id: References: <255243C7-1AD7-4F76-9744-8DDE22130674@cisco.com> <001501caa4e8$ee1b60a0$380c7c0a@china.huawei.com> To: Young Lee X-Mailer: Apple Mail (2.1077) Cc: ccamp@ietf.org Subject: Re: [CCAMP] Q on FEC type indraft-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: Wed, 03 Feb 2010 16:07:49 -0000 --Apple-Mail-4--856704686 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi YOung, perfect. That answers my question. /Dirk Am 03.02.2010 um 16:52 schrieb Young Lee: > Hi Dirk, > > We have updated the FEC type Sub-TLV that incorporates G.975.1. The update > will be shortly published. They are at the minimum: > > FEC ID > -------- > 3 G.975.1 Concatenated FEC (RS(255,239)/CSOC(n0/k0=7/6,J=8)) > 4 G.975.1 Concatenated FEC (BCH(3860,3824)/BCH(2040,1930)) > 5 G.975.1 Concatenated FEC (RS(1023,1007)/BCH(2407,1952)) > 6 G.975.1 Concatenated FEC (RS(1901,1855)/Extended Hamming > Product Code (512,502)X(510,500)) > 7 G.975.1 LDPC Code > 8 G.975.1 Concatenated FEC (Two orthogonally concatenated BCH > codes) > 9 G.975.1 RS(2720,2550) > 10 G.975.1 Concatenated FEC (Two interleaved extended BCH > (1020,988) codes) > > Where RS stands for Reed-Solomon and BCH for Bose-Chaudhuri-Hocquengham. > > If you have any question, please let me know. Thanks. > > Regards, > Young > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Dirk Schroetter > Sent: Wednesday, February 03, 2010 7:36 AM > To: ccamp@ietf.org > Subject: [CCAMP] Q on FEC type > indraft-ietf-ccamp-wson-signal-compatibility-ospf-00.txt > > Folks, > > is there a particular reason why the FEC type Sub-TLV only makes provisions > for FEC types defined in G.709/G.709V as standard FEC types ? I understand > that vendor-secific ones are supported, but why not extend the list of > "standard" ones by the FEC types defined in G.975.1 (even though they > strictly would only apply to submarine systems) ? > > Best Regards, > > /Dirk > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > --Apple-Mail-4--856704686 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi YOung,

perfect. That answers my question.

/Dirk

Am 03.02.2010 um 16:52 schrieb Young Lee:

Hi Dirk,

We have updated the FEC type Sub-TLV that incorporates G.975.1. The update
will be shortly published. They are at the minimum:

 FEC ID
--------
        3       G.975.1 Concatenated FEC (RS(255,239)/CSOC(n0/k0=7/6,J=8))
        4       G.975.1 Concatenated FEC (BCH(3860,3824)/BCH(2040,1930))
        5       G.975.1 Concatenated FEC (RS(1023,1007)/BCH(2407,1952))
        6       G.975.1 Concatenated FEC (RS(1901,1855)/Extended Hamming
Product Code (512,502)X(510,500))
        7       G.975.1 LDPC Code
        8       G.975.1 Concatenated FEC (Two orthogonally concatenated BCH
codes)
        9       G.975.1 RS(2720,2550)
        10      G.975.1 Concatenated FEC (Two interleaved extended BCH
(1020,988) codes)

Where RS stands for Reed-Solomon and BCH for Bose-Chaudhuri-Hocquengham.

If you have any question, please let me know. Thanks.

Regards,
Young

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of
Dirk Schroetter
Sent: Wednesday, February 03, 2010 7:36 AM
To: ccamp@ietf.org
Subject: [CCAMP] Q on FEC type
indraft-ietf-ccamp-wson-signal-compatibility-ospf-00.txt

Folks,

is there a particular reason why the FEC type Sub-TLV only makes provisions
for FEC types defined in G.709/G.709V as standard FEC types ? I understand
that vendor-secific ones are supported, but why not extend the list of
"standard" ones by the FEC types defined in G.975.1 (even though they
strictly would only apply to submarine systems) ?

Best Regards,

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


--Apple-Mail-4--856704686-- From db3546@att.com Wed Feb 3 12:26:57 2010 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 C1FE628C121 for ; Wed, 3 Feb 2010 12:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 HFg641dXvVGX for ; Wed, 3 Feb 2010 12:26:57 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id E9A593A6C42 for ; Wed, 3 Feb 2010 12:26:56 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1265228858!44997914!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 24134 invoked from network); 3 Feb 2010 20:27:39 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Feb 2010 20:27:39 -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 o13KRV68002098 for ; Wed, 3 Feb 2010 15:27:31 -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 o13KRSRa002067 for ; Wed, 3 Feb 2010 15:27:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {AA2E9299-D9EA-4287-A85B-DEE33AFC7AC3} MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: Arbu B24r CMUI DF4H DICW DhcT Dj/f ETq8 FmX3 Fu5c IK/t IN7L IiAj Ji7T J77Q KE/+; 1; YwBjAGEAbQBwAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {AA2E9299-D9EA-4287-A85B-DEE33AFC7AC3}; ZABiADMANQA0ADYAQABhAHQAdAAuAGMAbwBtAA==; Wed, 03 Feb 2010 20:27:32 GMT; RgBXADoAIABSAGUAdgBpAHMAZQBkACAARwB1AGkAZABlAGwAaQBuAGUAcwAgAHQAbwAgAEEAdQB0AGgAbwByAHMAIABvAGYAIABJAG4AdABlAHIAbgBlAHQALQBEAHIAYQBmAHQAcwA= Content-class: urn:content-classes:message Date: Wed, 3 Feb 2010 15:27:32 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised Guidelines to Authors of Internet-Drafts Thread-Index: Acqk9viBs6u16rgbSY2rc37zRkizLAAGEveA From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Subject: [CCAMP] FW: Revised Guidelines to Authors of Internet-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, 03 Feb 2010 20:26:57 -0000 FYI- -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of IESG Secretary Sent: Wednesday, February 03, 2010 12:32 PM To: IETF Announcement list Subject: Revised Guidelines to Authors of Internet-Drafts=20 An updated version of the Guidelines to Authors of Internet-Drafts is now available and has been posted on the IETF website: http://www.ietf.org/id-info/guidelines.html OR http://www.ietf.org/id-info/1id-guidelines.txt Summary of changes in this version: o Update the references to reflect the current BCPs. Remove the reference to rfc2333bis, which is no longer an active work item. Add a references for the I-D Submission Tool and the Data Tracker. o Rewrite of Section 3. o Structure the choices in Section 4 to match the current BCPs. o Provide two boilerplate options in Section 5, as approved by the IESG on 7 January 2010. o Remove the discussion of grace period from Section 7. With the I-D Submission Tool, there is no longer a need for one. o Include URLs that are not redirected. o Significant editorial changes. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From loa@pi.nu Thu Feb 4 07:03:27 2010 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 042753A6D54; Thu, 4 Feb 2010 07:03: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 o7G0B93Ol7eS; Thu, 4 Feb 2010 07:03:24 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id ABCA23A68A7; Thu, 4 Feb 2010 07:03:24 -0800 (PST) Received: from [192.36.158.44] (f-158-44.verkstad.net [192.36.158.44]) (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 E355FD4052; Thu, 4 Feb 2010 16:04:08 +0100 (CET) Message-ID: <4B6AE1E8.1080404@pi.nu> Date: Thu, 04 Feb 2010 16:04:08 +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] Working Group last call on draft-ietf-mpls-tp-framework-10 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, 04 Feb 2010 15:03:27 -0000 Working Group, this is to start a two week MPLS working group last call on draft-ietf-mpls-tp-framework-10 This working group last call ends eob January 19th. Please send comments to the mpls-tp@ietf.org mailing list. We would like request that special attention is focused on section 3.5 - 3.15 since it is our impression that these sections has been less well reviewed than the rest of the document, this is not to say that the earlier sections does not need review. Loa and George MPLS WG co-chairs -- 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 Thu Feb 4 09:08:20 2010 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 EA5863A6836; Thu, 4 Feb 2010 09:08: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 aCGX+MDLXSSp; Thu, 4 Feb 2010 09:08:20 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 16E9D3A6C52; Thu, 4 Feb 2010 09:08:19 -0800 (PST) Received: from [192.36.158.44] (f-158-44.verkstad.net [192.36.158.44]) (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 08463D4052; Thu, 4 Feb 2010 18:09:04 +0100 (CET) Message-ID: <4B6AFF25.5020300@pi.nu> Date: Thu, 04 Feb 2010 18:08:53 +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 References: <4B6AE1E8.1080404@pi.nu> In-Reply-To: <4B6AE1E8.1080404@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CCAMP] [mpls-tp] Working Group last call on draft-ietf-mpls-tp-framework-10 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, 04 Feb 2010 17:08:21 -0000 All, as has been pointed out be several observant working group members, I meant February 19th as the day when the wg last call ends. /Loa Loa Andersson wrote: > Working Group, > > this is to start a two week MPLS working group last call on > > draft-ietf-mpls-tp-framework-10 > > This working group last call ends eob January 19th. > > Please send comments to the mpls-tp@ietf.org mailing list. > > We would like request that special attention is focused on > section 3.5 - 3.15 since it is our impression that these > sections has been less well reviewed than the rest of the > document, this is not to say that the earlier sections does > not need review. > > Loa and George > > MPLS WG co-chairs > > > -- 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 wwwrun@core3.amsl.com Mon Feb 8 05:38:05 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2563F3A736D; Mon, 8 Feb 2010 05:38:04 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100208133805.2563F3A736D@core3.amsl.com> Date: Mon, 8 Feb 2010 05:38:04 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: draft-ietf-ccamp-ethernet-traffic-parameters (Ethernet Traffic Parameters) to Proposed Standard 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: Mon, 08 Feb 2010 13:38:05 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Ethernet Traffic Parameters ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-02-22. 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-ethernet-traffic-parameters-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14622&rfc_flag=0 From wwwrun@core3.amsl.com Mon Feb 8 05:38:40 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 67DEC3A7378; Mon, 8 Feb 2010 05:38:40 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100208133840.67DEC3A7378@core3.amsl.com> Date: Mon, 8 Feb 2010 05:38:40 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: draft-ietf-ccamp-gmpls-ether-svcs (Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching) to Proposed Standard 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: Mon, 08 Feb 2010 13:38:40 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-02-22. 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-ether-svcs-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17200&rfc_flag=0 From wwwrun@core3.amsl.com Mon Feb 8 05:39:22 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9E3F83A7392; Mon, 8 Feb 2010 05:39:22 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100208133922.9E3F83A7392@core3.amsl.com> Date: Mon, 8 Feb 2010 05:39:22 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: draft-ietf-ccamp-gmpls-mef-uni (Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)) to Proposed Standard 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: Mon, 08 Feb 2010 13:39:22 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-02-22. 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-mef-uni-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17201&rfc_flag=0 From loa@pi.nu Tue Feb 9 07:50:15 2010 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 DEB1228C127; Tue, 9 Feb 2010 07:50:15 -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 vEUxCZHNwM6o; Tue, 9 Feb 2010 07:50:15 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id DFFCD28C11E; Tue, 9 Feb 2010 07:50:14 -0800 (PST) Received: from [192.168.2.21] (unknown [194.98.133.4]) (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 2E6B9D4052; Tue, 9 Feb 2010 16:51:19 +0100 (CET) Message-ID: <4B718478.5030909@pi.nu> Date: Tue, 09 Feb 2010 16:51:20 +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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] early review of draft-ietf-mpls-tp-fault-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, 09 Feb 2010 15:50:16 -0000 All, The MPLS working group has requested an early review of draft-ietf-mpls-tp-fault-00.txt by ITU-T SG15. This is also a good time for people active in the work on MPLS in both IETF and ITU-T The draft is in a state stable enough to make an early feasible. However there is a set of comments that were received during the poll to make this document a working group document. These comments will be addressed along with any new comments. The ITU-T has been requested to send comments to the IETF by March 10, 2010. Please send your comments directly 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 root@core3.amsl.com Tue Feb 9 08:00:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 15B4028C0FE; Tue, 9 Feb 2010 08: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: <20100209160002.15B4028C0FE@core3.amsl.com> Date: Tue, 9 Feb 2010 08:00:01 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-info-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: Tue, 09 Feb 2010 16: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 : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-rwa-info-06.txt Pages : 22 Date : 2010-02-09 This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rwa-info-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-09075721.I-D@ietf.org> --NextPart-- From loa@pi.nu Tue Feb 9 08:05:00 2010 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 CF2593A7368; Tue, 9 Feb 2010 08:05:00 -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 XhEgQJ23Wn3P; Tue, 9 Feb 2010 08:05:00 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id CFB1A3A73F5; Tue, 9 Feb 2010 08:04:59 -0800 (PST) Received: from [192.168.2.21] (unknown [194.98.133.4]) (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 94CF2D4052; Tue, 9 Feb 2010 17:06:04 +0100 (CET) Message-ID: <4B7187EE.30404@pi.nu> Date: Tue, 09 Feb 2010 17:06:06 +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, Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Tue, 09 Feb 2010 16:05:00 -0000 All, This is to start two week poll on making draft-fbb-mpls-tp-data-plane-00.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". Note that this ID is a starting point for what needs to be documented on the MPLS data plane for the MPLS-TP project. The ID is largely based on the data plane specific text from the framework, together with some notes concerning how the Transport Profile of MPLS might operate over Ethernet. /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 lberger@labn.net Tue Feb 9 08:22:20 2010 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 5503128C222 for ; Tue, 9 Feb 2010 08:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, 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 r6hbJVcQDL4C for ; Tue, 9 Feb 2010 08:22:19 -0800 (PST) Received: from outbound-mail-01.bluehost.com (outbound-mail-01.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 4E1AF28C219 for ; Tue, 9 Feb 2010 08:22:19 -0800 (PST) Received: (qmail 24245 invoked by uid 0); 9 Feb 2010 16:23:26 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy4.bluehost.com with SMTP; 9 Feb 2010 16:23:26 -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:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=lHtX+TZv70V3c1Mr1tOvdiMlQA9YyltbgVDcimZ+uMqQcfKI8bwe9Cfqrpd0ROVtl0XPJmSrVz67ALl9/p0PJakUeCrUrgTScEvyW0wZbnibtdFX4cu4XXY45FxIUKnw; 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 1Ness2-00005z-4I for ccamp@ietf.org; Tue, 09 Feb 2010 09:23:26 -0700 Message-ID: <4B718C44.90001@labn.net> Date: Tue, 09 Feb 2010 11:24:36 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: CCAMP WG X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 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] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 09 Feb 2010 16:22:20 -0000 All, The authors of the drafts have stated that they are ready for this poll to resume. Therefore: This message starts a two week poll on making the documents listed below ccamp working group documents. Please send a mail to the mailing list indicating "yes/support to both" or "no/do not support either". Of course, you may also support one but not the other. (We will assume that you support/object to both if you don't specify.) Please send mail even if you expressed an opinion on the prior poll. The documents being polled are: http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext The poll ends Tuesday February 23. Much thanks, Lou -------- Original Message -------- Subject: [CCAMP] Suspended: poll on making draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document Date: Tue, 01 Dec 2009 07:07:03 -0500 From: Lou Berger To: ccamp@ietf.org 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 > > > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From Alexander.Vainshtein@ecitele.com Tue Feb 9 08:25:57 2010 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 481A23A73DC; Tue, 9 Feb 2010 08:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, 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 FMeXUEUOtUo1; Tue, 9 Feb 2010 08:25:55 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 22CFB3A7223; Tue, 9 Feb 2010 08:25:53 -0800 (PST) X-AuditID: 93eaf2e7-b7c20ae000004820-6f-4b718b6b0b83 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 9F.71.18464.B6B817B4; Tue, 9 Feb 2010 18:20:59 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Tue, 9 Feb 2010 18:26:59 +0200 From: Alexander Vainshtein To: Loa Andersson Date: Tue, 9 Feb 2010 18:26:58 +0200 Thread-Topic: [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: AcqpodBPSODLwigiRiO34TcGNLqB6QAASfLQ Message-ID: References: <4B7187EE.30404@pi.nu> In-Reply-To: <4B7187EE.30404@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_A3C5DF08D38B6049839A6F553B331C76BFDFFAB985ILPTMAIL02eci_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "mpls@ietf.org" , "Bocci, Matthew \(Matthew\)" , "ccamp@ietf.org" , "mpls-tp@ietf.org" , 'Dan Frost' , "pwe3@ietf.org" , Adrian Subject: Re: [CCAMP] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Tue, 09 Feb 2010 16:25:57 -0000 --_002_A3C5DF08D38B6049839A6F553B331C76BFDFFAB985ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Loa, I think that such a draft is absolutely required. At the same time I think the -00 revision is somewhat problematic. In particular, the proposal to use a well-known multicast MAC address for e= ncapsulation of MPLS-TP packets over Ethernet *simply will not work* together with the combination = of: (a) LAN interfaces between MPLS-TP routers (quite a common case for Etherne= t) and=20 (b) Downstream label assignment (which presumably is going to be used for P= 2P LSPs in MPLS-TP). I've already sent my comments on this (and some other points) to the author= s and the mailing lists (attached). IMHO at least the problem of Ethernet encapsulation should be acknowledged = (and resolved?) before the draft is accepted as a WG document. Regards, Sasha > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Tuesday, February 09, 2010 6:06 PM > To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org;=20 > pwe3@ietf.org; Adrian Farrel > Subject: [mpls-tp] poll on making=20 > draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document >=20 > All, >=20 > This is to start two week poll on making > draft-fbb-mpls-tp-data-plane-00.txt > an mpls working group document. >=20 > Send a mail to the mpls-tp@ietf.org mailing list, > indicating "yes/support" or "no/do not support". >=20 > Note that this ID is a starting point for what needs to > be documented on the MPLS data plane for the MPLS-TP > project. The ID is largely based on the data plane specific > text from the framework, together with some notes concerning > how the Transport Profile of MPLS might operate over Ethernet. >=20 >=20 > /Loa >=20 >=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 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > = --_002_A3C5DF08D38B6049839A6F553B331C76BFDFFAB985ILPTMAIL02eci_ Content-Type: message/rfc822 From: Alexander Vainshtein To: "stbryant@cisco.com" , 'Dan Frost' , 'BOCCI Matthew' CC: "mpls-tp@ietf.org" , "mpls@ietf.org" Date: Mon, 1 Feb 2010 18:59:57 +0200 Subject: Comments on draft-fbb-mpls-tp-data-plane-00 Thread-Topic: Comments on draft-fbb-mpls-tp-data-plane-00 Thread-Index: AcqjX/uNAs4hmNUiRSapsws4EJwU5Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6971727472716676656873657573696673797175776765797977756_" MIME-Version: 1.0 --_000_6971727472716676656873657573696673797175776765797977756_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart, Dan, Matthew and all, First of all I'd like to say that the need for clear-cut definition of the = MPLS-TP data plane architecture has been quite clear to me. The draft is clearly the necessary first step in the right direction, and I= thank you for producing it. That said, I think that quite a few issues have been left undecided in this= -00 version of the draft. I will make a (hopefully, short) list of items that IMHO require additional= clarification and, eventually, codification. 1. LSP Merge: * In MPLS, nothing prevents LSPs from merging at some point: * One well-known usage of LSP merge is FRR * PHP can be considered as a special case of LSP merge * One of the often repeated mantras of MPLS-TP is that its LSPs canno= t be merge. * It is not clear (at least, to me): * Whether this limitation has to be respected at the data plane le= vel, and if yes, then how * Whether it means that FRR cannot be used in MPLS-TP * Status of this topic in the -00 draft: not mentioned at all 2. Per-Interface Label Space: * The draft states that per-interface label space MAY be used in MPLS= -TP * AFAIK, in MPLS: * This referred to data links (including bundles, e.g., produced b= y LAG). As a consequence, the number of label contexts has been reasonably = low * This has been only allowed on P2P links * One of the problems with MPLS-TP is that in many cases it does not = differentiate between data links and lower layer LSPs (see also my notes re= garding Sections). As a consequence, it is not clear (to me) whether per-in= terface label space may become a label space per lower layer LSP. (To the b= est of my understanding this is explicitly prohibited by RFC 3031). * Status of this topic in the -00 draft: requires clarification, pref= erably aligned with RFC 3031. 3. Sections: * The draft states that Sections could be data links (level 0 section= s) or LSPs with N labels (level N Sections). * The following is not clear to me: * Can LAN-like data links be Sections in MPLS-TP (The Editors ask = this question themselves when they discuss MAC addresses) * Which types of LSPs can be Sections (e.g., can a P2P unidirectio= nal LSP be a Section? Can an associated bi-directional LSP be a section? et= c.). * If associated bi-directional LSPs can be Sections, can we treat = the LSPs rumming over these Sections as co-routed bidirectional? * Per-data link (interface) label space is supported in MPLS. Does= MPLS-Tp allow per-Section label space (see above)? * Status of this topic in the -00 draft: requires clarification, one = aspect already recognized as such by the Editors. IMHO and FWIW preferred r= esolution would be to equate Sections with data links 4. Label Allocation Schemes: * MPLS recognizes two label allocation schemes, each with its own are= a of applicability: * Downstream label allocation as per RFC 3031 * Upstream label allocation as per RFC 5331 * IMHO the label allocation scheme is essentially a data plane issue: * Label allocation scheme is reflected in the Ethertype in the cas= e of Ethernet encapsulation etc. * Packets with invalid labels must be silently discarded etc. * It is not clear to me, which label allocation schemes can be used i= n MPLS-TP. * This includes applicability of these schemes, e.g., can we use u= pstream label allocation * This issue is closely related to proposed usage of a well-known = multicast MAC destination address for P2P LSPs) * Status of this topic in the -00 draft: requires clarification 5. MAC addresses on Ethernet data links in MPLS-TP: * The draft discusses this topic, and proposes using a well-known mul= ticast DA in Ethernet encapsulations for for P2P LSPs * IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of w= ell-known multicast DA is not compatible with the downstream label allocati= on scheme. * Status of this topic in the -00-draft: partially recognized by the = Editors, there seems to be a bug in the proposed solution. Hopefully, these notes will be useful. Regards, Sasha * --_000_6971727472716676656873657573696673797175776765797977756_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Stewart, = Dan,=20 Matthew and all,
First of = all I'd=20 like to say that the need for clear-cut definition of the MPLS-TP data plan= e=20 architecture has been quite clear to me.
The draft= is clearly=20 the necessary first step in the right direction, and I thank you for produc= ing=20 it.
 
That said= , I think=20 that quite a few issues have been left undecided in this -00 version of the= =20 draft.
 
I will ma= ke a=20 (hopefully, short) list of items that IMHO require additional clarification= and,=20 eventually, codification.
 
  1. = LSP=20 Merge:
    • In MPL= S, nothing=20 prevents LSPs from merging at some point:
      • One = well-known=20 usage of LSP merge is FRR
      • PHP = can be=20 considered as a special case of LSP merge
    • One of= the often=20 repeated mantras of MPLS-TP is that its LSPs cannot be=20 merge. 
    • It is = not clear=20 (at least, to me):
      • Whet= her this=20 limitation has to be respected at the data plane level, and if yes, t= hen=20 how
      • Whet= her it=20 means that FRR cannot be used in MPLS-TP
    • Status= of this=20 topic in the -00 draft: not mentioned at all
  2. Per-Interface Label=20 Space:
    • The dr= aft states=20 that per-interface label space MAY be used in MPLS-TP
    • AFAIK,= in=20 MPLS:
      • This= referred=20 to data links (including bundles, e.g., produced by LAG). As a=20 consequence, the number of label contexts has been reasonably=20 low
      • This= has been=20 only allowed on P2P links
    • One of= the=20 problems with MPLS-TP is that in many cases it does not differenti= ate=20 between data links and lower layer LSPs (see also my notes regarding=20 Sections). As a consequence, it is not clear (to me) whether per-interf= ace=20 label space may become a label space per lower layer LSP. (To the best = of my=20 understanding this is explicitly prohibited by RFC=20 3031).
    • Status= of this=20 topic in the -00 draft: requires clarification, preferably aligned with= RFC=20 3031.
  3. Sections:
    • The dr= aft states=20 that Sections could be data links (level 0 sections) or LSPs with N lab= els=20 (level N Sections).
    • The fo= llowing=20 is not clear to me:
      • Can = LAN-like=20 data links be Sections in MPLS-TP (The Editors ask this question=20 themselves when they discuss MAC addresses)
      • Whic= h types of=20 LSPs can be Sections (e.g., can a P2P unidirectional LSP be a=20 Section? Can an associated bi-directional LSP be a section? etc.).=20
      • If a= ssociated=20 bi-directional LSPs can be Sections, can we treat the LSPs rumming ov= er=20 these Sections as co-routed bidirectional?
      • Per-= data link=20 (interface) label space is supported in MPLS. Does MPLS-Tp allow=20 per-Section label space (see above)?
    • Status= of this=20 topic in the -00 draft: requires clarification, one aspect already=20 recognized as such by the Editors. IMHO and FWIW preferred resolution w= ould=20 be to equate Sections with data links
  4. = Label=20 Allocation Schemes:
    • MPLS r= ecognizes=20 two label allocation schemes, each with its own area of=20 applicability:
      • Down= stream=20 label allocation as per RFC 3031
      • Upst= ream label=20 allocation as per RFC 5331
    • IMHO t= he label=20 allocation scheme is essentially a data plane issue:
      • Labe= l=20 allocation scheme is reflected in the Ethertype in the case of Ethern= et=20 encapsulation etc.
      • Packets with invalid labels mus= t be=20 silently discarded=20 etc.
    • It is = not clear=20 to me, which label allocation schemes can be used in= =20 MPLS-TP.
      • This= includes=20 applicability of these schemes, e.g., can we use upstream label alloc= ation=20
      • This= issue is=20 closely related to proposed usage of a well-known multicast= MAC=20 destination address for P2P LSPs)
    • Status of this topic in the -00 draft: requi= res=20 clarification
  5. MAC addresses on Ethernet data links i= n=20 MPLS-TP:
    • The draft discusses this topic, and proposes= using=20 a well-known multicast DA in Ethernet encapsulations for for P2P=20 LSPs
    • IMHO and FWIW if LAN interfaces are all= owed in=20 MPLS-TP, usage of  well-known multicast DA is not compatible with = the=20 downstream label allocation scheme.
    • Status of this topic in the -00-draft: parti= ally=20 recognized by the Editors, there seems to be a bug in the proposed=20 solution.
Hopefully, these notes will be=20 useful.
 
Regards,
    =20 Sasha
    •  
--_000_6971727472716676656873657573696673797175776765797977756_-- --_002_A3C5DF08D38B6049839A6F553B331C76BFDFFAB985ILPTMAIL02eci_-- From ylee@huawei.com Tue Feb 9 08:26:58 2010 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 639723A73F8 for ; Tue, 9 Feb 2010 08:26: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 AFyT5teU1Wf3 for ; Tue, 9 Feb 2010 08:26:57 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 7C39D3A7223 for ; Tue, 9 Feb 2010 08:26:57 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXL00D271QRLM@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 09 Feb 2010 10:28:04 -0600 (CST) Received: from L73682 ([10.124.12.56]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXL00HK21QME2@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 09 Feb 2010 10:28:03 -0600 (CST) Date: Tue, 09 Feb 2010 10:27:57 -0600 From: Young Lee In-reply-to: <20100209160002.15B4028C0FE@core3.amsl.com> To: ccamp@ietf.org Message-id: <002401caa9a4$d7ae5e60$380c7c0a@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: AcqpoaLSm3d/IZcUQq2/laSTdylEHAAAfbLA References: <20100209160002.15B4028C0FE@core3.amsl.com> Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-info-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: Tue, 09 Feb 2010 16:26:58 -0000 Hi, We have just published the latest version (06) of WSON RWA Information model draft. New changes from the previous version are: - We added signal compatibility modeling - We distinguished "general" model from "WSON-specific" model per WG chairs' suggestion. General info model can be applicable to other technologies and not limited to WSON. "WSON-specific" info model is applicable only to WSON. Thanks, Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, February 09, 2010 10:00 AM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-info-06.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 : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-rwa-info-06.txt Pages : 22 Date : 2010-02-09 This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From danfrost@cisco.com Tue Feb 9 08:52:14 2010 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 0806A28C23C; Tue, 9 Feb 2010 08:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Zu16u8nGBMMT; Tue, 9 Feb 2010 08:52:12 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A5DC828C237; Tue, 9 Feb 2010 08:52:12 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,437,1262563200"; d="scan'208";a="297457852" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2010 16:53:18 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [64.100.19.13]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o19GrIuD022527; Tue, 9 Feb 2010 16:53:18 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id o19GrIJ7017242; Tue, 9 Feb 2010 11:53:18 -0500 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id o19GrIGV017241; Tue, 9 Feb 2010 16:53:18 GMT Date: Tue, 9 Feb 2010 16:53:18 +0000 From: Dan Frost To: Alexander Vainshtein Message-ID: <20100209165318.GA9442@cisco.com> References: <4B7187EE.30404@pi.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Tue, 09 Feb 2010 09:23:17 -0800 Cc: "mpls@ietf.org" , "Bocci, Matthew \(Matthew\)" , "ccamp@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Tue, 09 Feb 2010 16:52:14 -0000 Hi Sasha, Many thanks for your comments! The authors will review them in detail when we next sit down to work on the document. Several of your points relate to open issues which we're aware need to be resolved, like the use of multipoint Ethernet interfaces and the definition and scope of MPLS-TP Sections. Your input is very helpful as always. -d On Tue, Feb 09, 2010 at 06:26:58PM +0200, Alexander Vainshtein wrote: > Loa, > I think that such a draft is absolutely required. > At the same time I think the -00 revision is somewhat problematic. > In particular, the proposal to use a well-known multicast MAC address for encapsulation of MPLS-TP > packets over Ethernet *simply will not work* together with the combination of: > (a) LAN interfaces between MPLS-TP routers (quite a common case for Ethernet) and > (b) Downstream label assignment (which presumably is going to be used for P2P LSPs in MPLS-TP). > > I've already sent my comments on this (and some other points) to the authors and the mailing lists (attached). > > IMHO at least the problem of Ethernet encapsulation should be acknowledged (and resolved?) before the draft is accepted as a WG document. > > Regards, > Sasha > > > > > -----Original Message----- > > From: mpls-tp-bounces@ietf.org > > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > > Sent: Tuesday, February 09, 2010 6:06 PM > > To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; > > pwe3@ietf.org; Adrian Farrel > > Subject: [mpls-tp] poll on making > > draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document > > > > All, > > > > This is to start two week poll on making > > draft-fbb-mpls-tp-data-plane-00.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". > > > > Note that this ID is a starting point for what needs to > > be documented on the MPLS data plane for the MPLS-TP > > project. The ID is largely based on the data plane specific > > text from the framework, together with some notes concerning > > how the Transport Profile of MPLS might operate over Ethernet. > > > > > > /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 > > > Date: Mon, 1 Feb 2010 18:59:57 +0200 > From: Alexander Vainshtein > Subject: Comments on draft-fbb-mpls-tp-data-plane-00 > To: "stbryant@cisco.com" , 'Dan Frost' > , 'BOCCI Matthew' > CC: "mpls-tp@ietf.org" , "mpls@ietf.org" > > Stewart, Dan, Matthew and all, > First of all I'd like to say that the need for clear-cut definition of the MPLS-TP data plane architecture has been quite clear to me. > The draft is clearly the necessary first step in the right direction, and I thank you for producing it. > > That said, I think that quite a few issues have been left undecided in this -00 version of the draft. > > I will make a (hopefully, short) list of items that IMHO require additional clarification and, eventually, codification. > > > 1. LSP Merge: > * In MPLS, nothing prevents LSPs from merging at some point: > * One well-known usage of LSP merge is FRR > * PHP can be considered as a special case of LSP merge > * One of the often repeated mantras of MPLS-TP is that its LSPs cannot be merge. > * It is not clear (at least, to me): > * Whether this limitation has to be respected at the data plane level, and if yes, then how > * Whether it means that FRR cannot be used in MPLS-TP > * Status of this topic in the -00 draft: not mentioned at all > 2. Per-Interface Label Space: > * The draft states that per-interface label space MAY be used in MPLS-TP > * AFAIK, in MPLS: > * This referred to data links (including bundles, e.g., produced by LAG). As a consequence, the number of label contexts has been reasonably low > * This has been only allowed on P2P links > * One of the problems with MPLS-TP is that in many cases it does not differentiate between data links and lower layer LSPs (see also my notes regarding Sections). As a consequence, it is not clear (to me) whether per-interface label space may become a label space per lower layer LSP. (To the best of my understanding this is explicitly prohibited by RFC 3031). > * Status of this topic in the -00 draft: requires clarification, preferably aligned with RFC 3031. > 3. Sections: > * The draft states that Sections could be data links (level 0 sections) or LSPs with N labels (level N Sections). > * The following is not clear to me: > * Can LAN-like data links be Sections in MPLS-TP (The Editors ask this question themselves when they discuss MAC addresses) > * Which types of LSPs can be Sections (e.g., can a P2P unidirectional LSP be a Section? Can an associated bi-directional LSP be a section? etc.). > * If associated bi-directional LSPs can be Sections, can we treat the LSPs rumming over these Sections as co-routed bidirectional? > * Per-data link (interface) label space is supported in MPLS. Does MPLS-Tp allow per-Section label space (see above)? > * Status of this topic in the -00 draft: requires clarification, one aspect already recognized as such by the Editors. IMHO and FWIW preferred resolution would be to equate Sections with data links > 4. Label Allocation Schemes: > * MPLS recognizes two label allocation schemes, each with its own area of applicability: > * Downstream label allocation as per RFC 3031 > * Upstream label allocation as per RFC 5331 > * IMHO the label allocation scheme is essentially a data plane issue: > * Label allocation scheme is reflected in the Ethertype in the case of Ethernet encapsulation etc. > * Packets with invalid labels must be silently discarded etc. > * It is not clear to me, which label allocation schemes can be used in MPLS-TP. > * This includes applicability of these schemes, e.g., can we use upstream label allocation > * This issue is closely related to proposed usage of a well-known multicast MAC destination address for P2P LSPs) > * Status of this topic in the -00 draft: requires clarification > 5. MAC addresses on Ethernet data links in MPLS-TP: > * The draft discusses this topic, and proposes using a well-known multicast DA in Ethernet encapsulations for for P2P LSPs > * IMHO and FWIW if LAN interfaces are allowed in MPLS-TP, usage of well-known multicast DA is not compatible with the downstream label allocation scheme. > * Status of this topic in the -00-draft: partially recognized by the Editors, there seems to be a bug in the proposed solution. > > Hopefully, these notes will be useful. > > Regards, > Sasha > > * From elisa.bellagamba@ericsson.com Tue Feb 9 13:53:50 2010 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 D0DFE3A7626 for ; Tue, 9 Feb 2010 13:53:50 -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 ieakDzcJQ6jY for ; Tue, 9 Feb 2010 13:53:50 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A9ED63A7288 for ; Tue, 9 Feb 2010 13:53:49 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-09-4b71d9b032d8 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 57.69.31641.0B9D17B4; Tue, 9 Feb 2010 22:54:56 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.95) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 9 Feb 2010 22:54:56 +0100 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.221]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Tue, 9 Feb 2010 22:54:55 +0100 From: Elisa Bellagamba To: Lou Berger , CCAMP WG Date: Tue, 9 Feb 2010 22:54:53 +0100 Thread-Topic: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents Thread-Index: AcqppDitcHiiPckzTgO+zJVJkUItiQALjS/g Message-ID: <55EA962132DCC84286EB4429B9CA773A1CF0011737@ESESSCMS0356.eemea.ericsson.se> References: <4B718C44.90001@labn.net> In-Reply-To: <4B718C44.90001@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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 09 Feb 2010 21:53:50 -0000 Yes/Support Ciao, Elisa -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: den 9 februari 2010 17:25 To: CCAMP WG Subject: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg document= s All, The authors of the drafts have stated that they are ready for this poll to resume. Therefore: This message starts a two week poll on making the documents listed below ccamp working group documents. Please send a mail to the mailing list indicating "yes/support to both" or "no/do not support either". Of course, you may also support one but not the other. (We will assume that you support/object to both if you don't specify.) Please send mail even if you expressed an opinion on the prior poll. The documents being polled are: http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext The poll ends Tuesday February 23. Much thanks, Lou -------- Original Message -------- Subject: [CCAMP] Suspended: poll on making draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document Date: Tue, 01 Dec 2009 07:07:03 -0500 From: Lou Berger To: ccamp@ietf.org 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 > > > _______________________________________________ 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 jeff.tantsura@ericsson.com Wed Feb 10 03:03:52 2010 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 1D0C63A72CE for ; Wed, 10 Feb 2010 03:03:52 -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 Q-148vGF9YiQ for ; Wed, 10 Feb 2010 03:03:51 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 23EE23A71D0 for ; Wed, 10 Feb 2010 03:03:51 -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 o1AB6SR3024426 for ; Wed, 10 Feb 2010 05:06:28 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.106]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 10 Feb 2010 06:04:59 -0500 From: Jeff Tantsura To: "ccamp@ietf.org" Date: Wed, 10 Feb 2010 06:04:53 -0500 Thread-Topic: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents Thread-Index: AcqppDitcHiiPckzTgO+zJVJkUItiQAmBm1gAAEaWdA= Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6047FBAFB3D@EUSAACMS0701.eamcs.ericsson.se> 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: [CCAMP] FW: (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 10 Feb 2010 11:03:52 -0000 yes/support to both Rgds, Jeff -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: den 9 februari 2010 17:25 To: CCAMP WG Subject: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg document= s All, The authors of the drafts have stated that they are ready for this poll to resume. Therefore: This message starts a two week poll on making the documents listed below ccamp working group documents. Please send a mail to the mailing list indicating "yes/support to both" or "no/do not support either". Of course, you may also support one but not the other. (We will assume that you support/object to both if you don't specify.) Please send mail even if you expressed an opinion on the prior poll. The documents being polled are: http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext The poll ends Tuesday February 23. Much thanks, Lou -------- Original Message -------- Subject: [CCAMP] Suspended: poll on making draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document Date: Tue, 01 Dec 2009 07:07:03 -0500 From: Lou Berger To: ccamp@ietf.org 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 > > > _______________________________________________ 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 Alexander.Vainshtein@ecitele.com Wed Feb 10 07:29:54 2010 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 D17313A76F6; Wed, 10 Feb 2010 07:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 0evrv3HFg39R; Wed, 10 Feb 2010 07:29:53 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id B5EDB3A73BC; Wed, 10 Feb 2010 07:29:52 -0800 (PST) X-AuditID: 93eaf2e7-b7c20ae000004820-07-4b72cfc93cd5 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id EB.E7.18464.9CFC27B4; Wed, 10 Feb 2010 17:24:57 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 10 Feb 2010 17:31:01 +0200 From: Alexander Vainshtein To: "mngpl@singnet.com.sg" Date: Wed, 10 Feb 2010 17:31:00 +0200 Thread-Topic: [PWE3] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: AcqqNdRunFpgX6gqRoCnGTyKaohzqwALnCGw Message-ID: References: <1265795114.4b72802ab7a84@discus.singnet.com.sg> In-Reply-To: <1265795114.4b72802ab7a84@discus.singnet.com.sg> 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: "mpls@ietf.org" , Loa, "ccamp@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [PWE3] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Wed, 10 Feb 2010 15:29:55 -0000 Max, The MPLS-TP framework draft is defined as Informational while the MPLS-TP d= ata plane draft is defined as Standard Track. This seems to be one good reason not to= merge them. On the other hand, it makes sense to me move all the data-plane issues from= the Framework draft to the data plane one and just to reference in in the Frame= work draft. Regards, Sasha > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On=20 > Behalf Of mngpl@singnet.com.sg > Sent: Wednesday, February 10, 2010 11:45 AM > To: Loa Andersson > Cc: mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; mpls-tp@ietf.org > Subject: Re: [PWE3] [mpls-tp] poll on making=20 > draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document >=20 > Hi Loa and the authors, >=20 > From what I read, the main key aspect of this draft defines a=20 > new ethernet MAC discovery through the use of multicast MAC.=20 > The rest of the drafts discuss about specific dataplane=20 > implementation that is align with=20 > draft-ietf-mpls-tp-framework-10, which calls it profiling. >=20 > Suggestion, why not put profile details into the framework=20 > draft? This improves readability? Or unless there can other=20 > type of profiling. >=20 > /Max=20 > --- Loa Andersson wrote: >=20 > > All, > >=20 > > This is to start two week poll on making > > draft-fbb-mpls-tp-data-plane-00.txt > > an mpls working group document. > >=20 > > Send a mail to the mpls-tp@ietf.org mailing list, > > indicating "yes/support" or "no/do not support". > >=20 > > Note that this ID is a starting point for what needs to > > be documented on the MPLS data plane for the MPLS-TP > > project. The ID is largely based on the data plane specific > > text from the framework, together with some notes concerning > > how the Transport Profile of MPLS might operate over Ethernet. > >=20 > >=20 > > /Loa > >=20 > >=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 > > _______________________________________________ > > 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 mngpl@singnet.com.sg Wed Feb 10 01:43:46 2010 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 761943A7698; Wed, 10 Feb 2010 01:43:46 -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 44lg2JH--95R; Wed, 10 Feb 2010 01:43:45 -0800 (PST) Received: from comsmtp1.singnet.com.sg (comsmtp1.singnet.com.sg [165.21.101.74]) by core3.amsl.com (Postfix) with ESMTP id 5EFD83A7670; Wed, 10 Feb 2010 01:43:45 -0800 (PST) Received: from pike.singnet.com.sg (pike.singnet.com.sg [165.21.101.112]) by comsmtp1.singnet.com.sg (8.14.1/8.13.6) with ESMTP id o1A9ioUa010166; Wed, 10 Feb 2010 17:44:50 +0800 Received: from pike.singnet.com.sg (localhost.localdomain [127.0.0.1]) by pike.singnet.com.sg (8.14.3/8.14.2) with ESMTP id o1A9igMf003363; Wed, 10 Feb 2010 17:44:52 +0800 Received: (from cooluser@localhost) by pike.singnet.com.sg (8.14.3/8.14.2/Submit) id o1A9ifoM003359; Wed, 10 Feb 2010 17:44:41 +0800 X-Authentication-Warning: pike.singnet.com.sg: cooluser set sender to mngpl@singnet.com.sg using -f To: Loa Andersson Message-ID: <1265795081.4b72800940ab5@discus.singnet.com.sg> Date: Wed, 10 Feb 2010 17:44:41 +0800 (SGT) From: mngpl@singnet.com.sg References: <4B7187EE.30404@pi.nu> In-Reply-To: <4B7187EE.30404@pi.nu> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: SingNet WebMail X-Mailman-Approved-At: Wed, 10 Feb 2010 08:37:33 -0800 Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mngpl@singnet.com.sg List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 09:43:46 -0000 Hi Loa and the authors, >From what I read, the main key aspect of this draft defines a new ethernet MAC discovery through the use of multicast MAC. The rest of the drafts discuss about specific dataplane implementation that is align with draft-ietf-mpls-tp-framework-10, which calls it profiling. Suggestion, why not put profile details into the framework draft? This improves readability? Or unless there can other type of profiling. /Max --- Loa Andersson wrote: > All, > > This is to start two week poll on making > draft-fbb-mpls-tp-data-plane-00.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". > > Note that this ID is a starting point for what needs to > be documented on the MPLS data plane for the MPLS-TP > project. The ID is largely based on the data plane specific > text from the framework, together with some notes concerning > how the Transport Profile of MPLS might operate over Ethernet. > > > /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 mngpl@singnet.com.sg Wed Feb 10 01:44:17 2010 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 921A13A6E79; Wed, 10 Feb 2010 01:44:17 -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 cdGO9SYC3iwp; Wed, 10 Feb 2010 01:44:17 -0800 (PST) Received: from comsmtp2.singnet.com.sg (comsmtp2.singnet.com.sg [165.21.101.75]) by core3.amsl.com (Postfix) with ESMTP id D84473A6B82; Wed, 10 Feb 2010 01:44:16 -0800 (PST) Received: from pike.singnet.com.sg (pike.singnet.com.sg [165.21.101.112]) by comsmtp2.singnet.com.sg (8.13.8/8.13.6) with ESMTP id o1A9jRvi028987; Wed, 10 Feb 2010 17:45:27 +0800 Received: from pike.singnet.com.sg (localhost.localdomain [127.0.0.1]) by pike.singnet.com.sg (8.14.3/8.14.2) with ESMTP id o1A9jEEv004779; Wed, 10 Feb 2010 17:45:24 +0800 Received: (from cooluser@localhost) by pike.singnet.com.sg (8.14.3/8.14.2/Submit) id o1A9jEqV004776; Wed, 10 Feb 2010 17:45:14 +0800 X-Authentication-Warning: pike.singnet.com.sg: cooluser set sender to mngpl@singnet.com.sg using -f To: Loa Andersson Message-ID: <1265795114.4b72802ab7a84@discus.singnet.com.sg> Date: Wed, 10 Feb 2010 17:45:14 +0800 (SGT) From: mngpl@singnet.com.sg MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: SingNet WebMail X-Mailman-Approved-At: Wed, 10 Feb 2010 08:37:33 -0800 Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mngpl@singnet.com.sg List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 09:44:17 -0000 Hi Loa and the authors, >From what I read, the main key aspect of this draft defines a new ethernet MAC discovery through the use of multicast MAC. The rest of the drafts discuss about specific dataplane implementation that is align with draft-ietf-mpls-tp-framework-10, which calls it profiling. Suggestion, why not put profile details into the framework draft? This improves readability? Or unless there can other type of profiling. /Max --- Loa Andersson wrote: > All, > > This is to start two week poll on making > draft-fbb-mpls-tp-data-plane-00.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". > > Note that this ID is a starting point for what needs to > be documented on the MPLS data plane for the MPLS-TP > project. The ID is largely based on the data plane specific > text from the framework, together with some notes concerning > how the Transport Profile of MPLS might operate over Ethernet. > > > /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 gregimirsky@gmail.com Wed Feb 10 14:42:28 2010 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 B1AC03A77B2 for ; Wed, 10 Feb 2010 14:42:28 -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 9m5vgk14Mirq for ; Wed, 10 Feb 2010 14:42:27 -0800 (PST) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 7FABF3A77B0 for ; Wed, 10 Feb 2010 14:42:27 -0800 (PST) Received: by bwz19 with SMTP id 19so659332bwz.28 for ; Wed, 10 Feb 2010 14:43:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=keXIJlJpTFxkkozXLYIfQ+o12UsXAXAzisTmmc6VcIc=; b=mt8oba43SGXhvaQUR3uPXAyarhQZW+/mWBKG3xACHf1JoNTN9peVZ1nvE8MmUwb/VS +YUaKsXOLstIVmIBSIvShaaEHPv7N8AQ9ztfLjUIq5XcRVJYCDVKwS3KLEoTb7dtj0tk sjeVx2fnxo8zdbTCR0rI/xD/x9P1o7VbvsPb8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=ZYHANS6IctCdziJJHMgENW/hr0NA3/aJoS90L37YyvM9un7e1btWFpiXFmc9aCwYIw OQ7aLRTdqMKTqUS5+EfMlcnuSnUc3nDeabZ6qPB7M5NwUNQ36qqLeVvluoq7lA34sXFz S3wnjqBupujR3a8xGCuLGfCw/4vAj8Jxjtm2k= MIME-Version: 1.0 Received: by 10.204.133.21 with SMTP id d21mr607289bkt.108.1265841815258; Wed, 10 Feb 2010 14:43:35 -0800 (PST) Date: Wed, 10 Feb 2010 14:43:35 -0800 Message-ID: <787be2781002101443v516bc403tdd4ec03ed17713b4@mail.gmail.com> From: Greg Mirsky To: elisa.bellagamba@ericsson.com, loa.andersson@ericsson.com Content-Type: multipart/alternative; boundary=0015174488f8bd898b047f46c323 Cc: ccamp@ietf.org Subject: [CCAMP] Questions on draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-04 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, 10 Feb 2010 22:42:28 -0000 --0015174488f8bd898b047f46c323 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, the second paragraph of Introduction says that BFD can be used to "track liveliness of MPLS-TP point-to-point and p2mp connections". I think that unless multiple BFD sessions, one per each leaf, are being established BFD cannot be used to monitor p2mp MPLS-TP connection. The main issue, as I see it, being session demultiplexing based on end node discriminator. Unless BFD changes so that ingress node can list multiple entities as Your Discriminator, BFD will remain p2p mechanism. The first paragraph of Section 3.1 says that both end nodes of BFD session "should be in active mode". Is that "SHOULD"? I think that since the BFD session is bootstrapped the ingress node SHOULD be in Passive mode and egress node MUST be in Active mode. Even more so. I think that MPLS-TP does not significantly benefit from BFD session bootstrapping, OOB exchange of discriminators, because it was added to LSP Ping to address ambiguity resulted from PHP, which is excluded from MPLS-TP. Regards, Greg --0015174488f8bd898b047f46c323 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors,
the second paragraph of Introduction says that BFD can be = used to "track liveliness of MPLS-TP point-to-point and p2mp connect= ions". I think that unless multiple BFD sessions, one per each leaf, a= re being established BFD cannot be used to monitor p2mp MPLS-TP connection.= The main issue, as I see it, being session demultiplexing based on end nod= e discriminator. Unless BFD changes so that ingress node can list multiple = entities as Your Discriminator, BFD will remain p2p mechanism.
The first paragraph of Section 3.1 says that both end nodes of BFD session = "should be in active mode". Is that "SHOULD"? I think t= hat since the BFD session is bootstrapped the ingress node SHOULD be in Pas= sive mode and egress node MUST be in Active mode.
Even more so. I think that MPLS-TP does not significantly benefit from BFD = session bootstrapping, OOB exchange of discriminators, because it was added= to LSP Ping to address ambiguity resulted from PHP, which is excluded from= MPLS-TP.


Regards,
Greg
--0015174488f8bd898b047f46c323-- From gregimirsky@gmail.com Wed Feb 10 15:05:45 2010 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 A006A3A74B6 for ; Wed, 10 Feb 2010 15:05:45 -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 p9SeWt+2Dh90 for ; Wed, 10 Feb 2010 15:05:44 -0800 (PST) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 1F4C53A72A6 for ; Wed, 10 Feb 2010 15:05:43 -0800 (PST) Received: by bwz19 with SMTP id 19so676636bwz.28 for ; Wed, 10 Feb 2010 15:06:52 -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:content-type; bh=NrWL0HZ0FUEWD7WRKwSs73ueWYlH0hEVOY0bVU3TBDo=; b=IC9XmCTc18MzYeELQpMNBbWx3IupW/U1OYV+ZB1EXLIC2RqjA5f5k98vlwJZLIiKfM j1Bp3/6wzsWDuHViae5T8ZJwRtoAV4pVdkUp7CTiTVGiFyG5SJU67hGROzb17Ph6S5Tf 4IQqwNMRuniFWvjCV0sVXH1h9GhYNogyesh78= 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 :content-type; b=NKoBSxU3g2njIBQppc02U1nEmaLLIsDk3fYS6/hLurMLI/Q+I9ovh3ZT6kgssqvyCM 5uWXVrc1PDwVOxg+eLLrltUjoqZouN/HMtEUU4Yl20aOwZ1EyhqOge+JX1zsv+bche6Y /liOUYE8lcS8ey2WNbU2jb5dVY8JJ0YrijsGI= MIME-Version: 1.0 Received: by 10.204.34.3 with SMTP id j3mr615556bkd.23.1265843212476; Wed, 10 Feb 2010 15:06:52 -0800 (PST) In-Reply-To: <4B718C44.90001@labn.net> References: <4B718C44.90001@labn.net> Date: Wed, 10 Feb 2010 15:06:52 -0800 Message-ID: <787be2781002101506v2b3ac4d4xac4a103bf59af025@mail.gmail.com> From: Greg Mirsky To: Lou Berger , ccamp@ietf.org Content-Type: multipart/alternative; boundary=00032555a4e6056153047f47178e Subject: Re: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 10 Feb 2010 23:05:45 -0000 --00032555a4e6056153047f47178e Content-Type: text/plain; charset=ISO-8859-1 yes/support for draft-kern-... no/do not support for draft-bellagamba-... Regards, Greg On Tue, Feb 9, 2010 at 8:24 AM, Lou Berger wrote: > All, > > The authors of the drafts have stated that they are ready for this > poll to resume. Therefore: > > This message starts a two week poll on making the documents listed below > ccamp working group documents. Please send a mail to the mailing list > indicating "yes/support to both" or "no/do not support either". Of > course, you may also support one but not the other. (We will assume > that you support/object to both if you don't specify.) Please send > mail even if you expressed an opinion on the prior poll. > > The documents being polled are: > > http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext > http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext > > The poll ends Tuesday February 23. > > Much thanks, > Lou > > -------- Original Message -------- > Subject: [CCAMP] Suspended: poll on making > draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document > Date: Tue, 01 Dec 2009 07:07:03 -0500 > From: Lou Berger > To: ccamp@ietf.org > > 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 > > > > > > > _______________________________________________ > 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 > --00032555a4e6056153047f47178e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable yes/support for draft-kern-...
no/do not support for draft-bellagamba-..= .

Regards,
Greg

On Tue, Feb 9, = 2010 at 8:24 AM, Lou Berger <lberger@labn.net> wrote:
All,

The authors of the drafts have stated that they are ready for this
poll to resume. =A0Therefore:

This message starts a two week poll on making the documents listed below ccamp working group documents. =A0Please send a mail to the mailing list indicating "yes/support to both" or "no/do not support eithe= r". =A0Of
course, you may also support one but not the other. =A0(We will assume
that you support/object to both if you don't specify.) =A0Please send mail even if you expressed an opinion on the prior poll.

The documents being polled are:

http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-= sdh-otn-oam-ext
http://tools.ietf.org/html/draft-bellagamba-cc= amp-rsvp-te-mpls-tp-oam-ext

The poll ends Tuesday February 23.

Much thanks,
Lou

-------- Original Message --------
Subject: [CCAMP] Suspended: poll on making
draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document
Date: Tue, 01 Dec 2009 07:07:03 -0500
From: Lou Berger <lberger@labn.net>
To: ccamp@ietf.org

The document authors have asked that we defer this poll until they make
some further updates to this document. =A0The plan will be to re-poll the WG once the document authors inform us that the changes have been made.
=A0Given recent discussion on the list, I expect that this poll will take<= br> 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. =A0It 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<= br> > 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
>
>
>
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp



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

--00032555a4e6056153047f47178e-- From daniele.ceccarelli@ericsson.com Wed Feb 10 23:52:44 2010 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 0F11C3A780A for ; Wed, 10 Feb 2010 23:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=1.082, 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 q06zxFDyjXJG for ; Wed, 10 Feb 2010 23:52:43 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0C9573A7808 for ; Wed, 10 Feb 2010 23:52:39 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-e0-4b73b790e157 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 1D.59.31641.097B37B4; Thu, 11 Feb 2010 08:53:52 +0100 (CET) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Feb 2010 08:53:51 +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, 11 Feb 2010 08:53:49 +0100 Message-ID: In-Reply-To: <55EA962132DCC84286EB4429B9CA773A1CF0011737@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents Thread-Index: AcqppDitcHiiPckzTgO+zJVJkUItiQALjS/gAEcy50A= References: <4B718C44.90001@labn.net> <55EA962132DCC84286EB4429B9CA773A1CF0011737@ESESSCMS0356.eemea.ericsson.se> From: "Daniele Ceccarelli" To: "Lou Berger" , "CCAMP WG" X-OriginalArrivalTime: 11 Feb 2010 07:53:51.0630 (UTC) FILETIME=[59F032E0:01CAAAEF] X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 11 Feb 2010 07:52:44 -0000 Yes/Support to both. BR Daniele =20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Elisa Bellagamba Sent: marted=EC 9 febbraio 2010 22.55 To: Lou Berger; CCAMP WG Subject: Re: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg = documents Yes/Support Ciao, Elisa -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Lou Berger Sent: den 9 februari 2010 17:25 To: CCAMP WG Subject: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg = documents All, The authors of the drafts have stated that they are ready for this poll = to resume. Therefore: This message starts a two week poll on making the documents listed below = ccamp working group documents. Please send a mail to the mailing list = indicating "yes/support to both" or "no/do not support either". Of = course, you may also support one but not the other. (We will assume = that you support/object to both if you don't specify.) Please send mail = even if you expressed an opinion on the prior poll. The documents being polled are: http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext= The poll ends Tuesday February 23. Much thanks, Lou -------- Original Message -------- Subject: [CCAMP] Suspended: poll on making = draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document Date: Tue, 01 Dec 2009 07:07:03 -0500 From: Lou Berger To: ccamp@ietf.org 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=20 > draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt a ccamp working group=20 > document. Send a mail to the mailing list indicating "yes/support" or=20 > "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 > > > _______________________________________________ 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 From loa@pi.nu Thu Feb 11 00:25:26 2010 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 47AB43A7166 for ; Thu, 11 Feb 2010 00:25:26 -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 F5Ta2S+BB5nB for ; Thu, 11 Feb 2010 00:25:25 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 31DD23A6FF9 for ; Thu, 11 Feb 2010 00:25:25 -0800 (PST) Received: from [10.104.75.131] (62-50-199-249.client.stsn.net [62.50.199.249]) (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 8D50CD4052; Thu, 11 Feb 2010 09:26:34 +0100 (CET) Message-ID: <4B73BF39.7080301@pi.nu> Date: Thu, 11 Feb 2010 09:26:33 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lou Berger References: <4B718C44.90001@labn.net> In-Reply-To: <4B718C44.90001@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP WG Subject: Re: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 11 Feb 2010 08:25:26 -0000 All, since I'm a co-author of draft-bellagamba- I obviously support that one, but I'd like say that I also support draf-kern- So "yes/support to both" /Loa Lou Berger wrote: > All, > > The authors of the drafts have stated that they are ready for this > poll to resume. Therefore: > > This message starts a two week poll on making the documents listed below > ccamp working group documents. Please send a mail to the mailing list > indicating "yes/support to both" or "no/do not support either". Of > course, you may also support one but not the other. (We will assume > that you support/object to both if you don't specify.) Please send > mail even if you expressed an opinion on the prior poll. > > The documents being polled are: > > http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext > http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext > > The poll ends Tuesday February 23. > > Much thanks, > Lou > > -------- Original Message -------- > Subject: [CCAMP] Suspended: poll on making > draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document > Date: Tue, 01 Dec 2009 07:07:03 -0500 > From: Lou Berger > To: ccamp@ietf.org > > 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 >> >> >> > _______________________________________________ > 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 -- 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 adrian@olddog.co.uk Thu Feb 11 08:02:15 2010 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 4F0243A7720 for ; Thu, 11 Feb 2010 08:02:15 -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, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWCVB8nZwdpe for ; Thu, 11 Feb 2010 08:02:14 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id C2E103A785C for ; Thu, 11 Feb 2010 08:02:02 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o1BG309m013455; Thu, 11 Feb 2010 16:03:05 GMT Received: from your029b8cecfe (62-50-195-172.client.stsn.net [62.50.195.172]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o1BG2nrg013395; Thu, 11 Feb 2010 16:02:54 GMT Message-ID: <8A45E89256EA4B358018AA259EAEE98A@your029b8cecfe> From: "Adrian Farrel" To: "Greg Mirsky" , , References: <787be2781002101443v516bc403tdd4ec03ed17713b4@mail.gmail.com> Date: Thu, 11 Feb 2010 16:02:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: ccamp@ietf.org Subject: Re: [CCAMP] Questions ondraft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 16:02:15 -0000 Hi Greg, draft-katz-ward-bfd-multipoint-02 invested some effort on P2MP BFD. The concepts are understood, but I think this timed out while the BFD WG invested time polishing the base BFD work (almost done now!). Might be worth pinging the BFD WG to find out their plans. Might be worth *this* I-D making a subtle change in language to say "and may be extended to P2MP..." Cheers, Adrian ----- Original Message ----- From: "Greg Mirsky" To: ; Cc: Sent: Wednesday, February 10, 2010 10:43 PM Subject: [CCAMP] Questions ondraft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-04 > Dear Authors, > the second paragraph of Introduction says that BFD can be used to "track > liveliness of MPLS-TP point-to-point and p2mp connections". I think that > unless multiple BFD sessions, one per each leaf, are being established BFD > cannot be used to monitor p2mp MPLS-TP connection. The main issue, as I > see > it, being session demultiplexing based on end node discriminator. Unless > BFD > changes so that ingress node can list multiple entities as Your > Discriminator, BFD will remain p2p mechanism. > The first paragraph of Section 3.1 says that both end nodes of BFD session > "should be in active mode". Is that "SHOULD"? I think that since the BFD > session is bootstrapped the ingress node SHOULD be in Passive mode and > egress node MUST be in Active mode. > Even more so. I think that MPLS-TP does not significantly benefit from BFD > session bootstrapping, OOB exchange of discriminators, because it was > added > to LSP Ping to address ambiguity resulted from PHP, which is excluded from > MPLS-TP. > > > Regards, > Greg > -------------------------------------------------------------------------------- > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From elisa.bellagamba@ericsson.com Thu Feb 11 08:13:28 2010 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 B3E443A6EAE for ; Thu, 11 Feb 2010 08:13:28 -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 gwKtnDB1gW-1 for ; Thu, 11 Feb 2010 08:13:27 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5B54A3A76EB for ; Thu, 11 Feb 2010 08:13:27 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-16-4b742cf0b6ea Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 8D.19.02429.0FC247B4; Thu, 11 Feb 2010 17:14:40 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.221]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 11 Feb 2010 17:14:39 +0100 From: Elisa Bellagamba To: Adrian Farrel , Greg Mirsky , Loa Andersson Date: Thu, 11 Feb 2010 17:14:38 +0100 Thread-Topic: [CCAMP] Questions ondraft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-04 Thread-Index: AcqrM7tofYfB7rmBTMCeVdc8ZrartAAAXx2w Message-ID: <55EA962132DCC84286EB4429B9CA773A1CF003A7CD@ESESSCMS0356.eemea.ericsson.se> References: <787be2781002101443v516bc403tdd4ec03ed17713b4@mail.gmail.com> <8A45E89256EA4B358018AA259EAEE98A@your029b8cecfe> In-Reply-To: <8A45E89256EA4B358018AA259EAEE98A@your029b8cecfe> 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" Subject: Re: [CCAMP] Questions ondraft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-04 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, 11 Feb 2010 16:13:28 -0000 Adrian, Thanks for a very useful comment and support. This change would work for me= . Greg, Would it work for you too? Elisa -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: den 11 februari 2010 17:03 To: Greg Mirsky; Elisa Bellagamba; Loa Andersson Cc: ccamp@ietf.org Subject: Re: [CCAMP] Questions ondraft-bellagamba-ccamp-rsvp-te-mpls-tp-oam= -ext-04 Hi Greg, draft-katz-ward-bfd-multipoint-02 invested some effort on P2MP BFD. The=20 concepts are understood, but I think this timed out while the BFD WG=20 invested time polishing the base BFD work (almost done now!). Might be worth pinging the BFD WG to find out their plans. Might be worth *this* I-D making a subtle change in language to say "and ma= y=20 be extended to P2MP..." Cheers, Adrian ----- Original Message -----=20 From: "Greg Mirsky" To: ; Cc: Sent: Wednesday, February 10, 2010 10:43 PM Subject: [CCAMP] Questions=20 ondraft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-04 > Dear Authors, > the second paragraph of Introduction says that BFD can be used to "track > liveliness of MPLS-TP point-to-point and p2mp connections". I think that > unless multiple BFD sessions, one per each leaf, are being established BF= D > cannot be used to monitor p2mp MPLS-TP connection. The main issue, as I=20 > see > it, being session demultiplexing based on end node discriminator. Unless= =20 > BFD > changes so that ingress node can list multiple entities as Your > Discriminator, BFD will remain p2p mechanism. > The first paragraph of Section 3.1 says that both end nodes of BFD sessio= n > "should be in active mode". Is that "SHOULD"? I think that since the BFD > session is bootstrapped the ingress node SHOULD be in Passive mode and > egress node MUST be in Active mode. > Even more so. I think that MPLS-TP does not significantly benefit from BF= D > session bootstrapping, OOB exchange of discriminators, because it was=20 > added > to LSP Ping to address ambiguity resulted from PHP, which is excluded fro= m > MPLS-TP. > > > Regards, > Greg > ---------------------------------------------------------------------------= ----- > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 From gregimirsky@gmail.com Thu Feb 11 10:07:13 2010 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 21AAB3A7779 for ; Thu, 11 Feb 2010 10:07:13 -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 T81M3n4QHEfn for ; Thu, 11 Feb 2010 10:07:12 -0800 (PST) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 8039C3A6EDE for ; Thu, 11 Feb 2010 10:07:11 -0800 (PST) Received: by bwz19 with SMTP id 19so695110bwz.28 for ; Thu, 11 Feb 2010 10:08:21 -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=ikg+EQXKA9XSZj0S/IhJnS5z2HgRPPMN3XNFZMYSv24=; b=l4butFGQ7eZlZvGO7i5TvVk8UIdhTSQ5PIraA8hV79oBKkUtDYmQKzIkq0+0EPQZFq QufE6oa9moom5MhLq96zQ7MY8JxrQ+294GXJjTIWIVHjWVNc3vNIBFHooEz/EkmBuCd4 9Uni5EaVzv8WTBOWeAs7prkT5JPslz4jiVWDE= 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=RhOYIR4MRCfoid4NPEyJ+JRBSH/Seqp4apNxlfIETOLajThqTrQSVL66A7vpsRmqop wt2ttWpIwzSxBgBGkLGf4VQG8pHVEJHEnVIjmaRYCgsvU5pJ/Lb2U6lRH37lhgzADZpW z0VMvHphbxdY+MXAm0w1LYkssfsqdctjtZv6s= MIME-Version: 1.0 Received: by 10.204.33.210 with SMTP id i18mr132176bkd.119.1265911701082; Thu, 11 Feb 2010 10:08:21 -0800 (PST) In-Reply-To: <55EA962132DCC84286EB4429B9CA773A1CF003A7CD@ESESSCMS0356.eemea.ericsson.se> References: <787be2781002101443v516bc403tdd4ec03ed17713b4@mail.gmail.com> <8A45E89256EA4B358018AA259EAEE98A@your029b8cecfe> <55EA962132DCC84286EB4429B9CA773A1CF003A7CD@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 11 Feb 2010 10:08:20 -0800 Message-ID: <787be2781002111008r514278c4o5191b97e7dc0fc1d@mail.gmail.com> From: Greg Mirsky To: Elisa Bellagamba Content-Type: multipart/alternative; boundary=00032555971e429608047f570948 Cc: Loa Andersson , "ccamp@ietf.org" Subject: Re: [CCAMP] Questions ondraft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-04 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, 11 Feb 2010 18:07:13 -0000 --00032555971e429608047f570948 Content-Type: text/plain; charset=ISO-8859-1 Elisa, I totally agree with Adrian suggestion. Adrian, thank you for reminding about the BFD draft (I think I've missed it altogether)."Friendly inquiry" to BFD will be extremely helpful. Regards, Greg On Thu, Feb 11, 2010 at 8:14 AM, Elisa Bellagamba < elisa.bellagamba@ericsson.com> wrote: > Adrian, > > Thanks for a very useful comment and support. This change would work for > me. > > Greg, > > Would it work for you too? > > Elisa > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: den 11 februari 2010 17:03 > To: Greg Mirsky; Elisa Bellagamba; Loa Andersson > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] Questions > ondraft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-04 > > Hi Greg, > > draft-katz-ward-bfd-multipoint-02 invested some effort on P2MP BFD. The > concepts are understood, but I think this timed out while the BFD WG > invested time polishing the base BFD work (almost done now!). > > Might be worth pinging the BFD WG to find out their plans. > > Might be worth *this* I-D making a subtle change in language to say "and > may > be extended to P2MP..." > > Cheers, > Adrian > > ----- Original Message ----- > From: "Greg Mirsky" > To: ; > Cc: > Sent: Wednesday, February 10, 2010 10:43 PM > Subject: [CCAMP] Questions > ondraft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-04 > > > > Dear Authors, > > the second paragraph of Introduction says that BFD can be used to "track > > liveliness of MPLS-TP point-to-point and p2mp connections". I think that > > unless multiple BFD sessions, one per each leaf, are being established > BFD > > cannot be used to monitor p2mp MPLS-TP connection. The main issue, as I > > see > > it, being session demultiplexing based on end node discriminator. Unless > > BFD > > changes so that ingress node can list multiple entities as Your > > Discriminator, BFD will remain p2p mechanism. > > The first paragraph of Section 3.1 says that both end nodes of BFD > session > > "should be in active mode". Is that "SHOULD"? I think that since the BFD > > session is bootstrapped the ingress node SHOULD be in Passive mode and > > egress node MUST be in Active mode. > > Even more so. I think that MPLS-TP does not significantly benefit from > BFD > > session bootstrapping, OOB exchange of discriminators, because it was > > added > > to LSP Ping to address ambiguity resulted from PHP, which is excluded > from > > MPLS-TP. > > > > > > Regards, > > Greg > > > > > > -------------------------------------------------------------------------------- > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > > --00032555971e429608047f570948 Content-Type: text/html; charset=ISO-8859-1 Elisa,
I totally agree with Adrian suggestion.

Adrian,
thank you for reminding about the BFD draft (I think I've missed it altogether)."Friendly inquiry" to BFD will be extremely helpful.

Regards,
Greg

On Thu, Feb 11, 2010 at 8:14 AM, Elisa Bellagamba <elisa.bellagamba@ericsson.com> wrote:
Adrian,

Thanks for a very useful comment and support. This change would work for me.

Greg,

Would it work for you too?

Elisa

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: den 11 februari 2010 17:03
To: Greg Mirsky; Elisa Bellagamba; Loa Andersson
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Questions ondraft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-04

Hi Greg,

draft-katz-ward-bfd-multipoint-02 invested some effort on P2MP BFD. The
concepts are understood, but I think this timed out while the BFD WG
invested time polishing the base BFD work (almost done now!).

Might be worth pinging the BFD WG to find out their plans.

Might be worth *this* I-D making a subtle change in language to say "and may
be extended to P2MP..."

Cheers,
Adrian

----- Original Message -----
From: "Greg Mirsky" <gregimirsky@gmail.com>
To: <elisa.bellagamba@ericsson.com>; <loa.andersson@ericsson.com>
Cc: <ccamp@ietf.org>
Sent: Wednesday, February 10, 2010 10:43 PM
Subject: [CCAMP] Questions
ondraft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext-04


> Dear Authors,
> the second paragraph of Introduction says that BFD can be used to "track
> liveliness of MPLS-TP point-to-point and p2mp connections". I think that
> unless multiple BFD sessions, one per each leaf, are being established BFD
> cannot be used to monitor p2mp MPLS-TP connection. The main issue, as I
> see
> it, being session demultiplexing based on end node discriminator. Unless
> BFD
> changes so that ingress node can list multiple entities as Your
> Discriminator, BFD will remain p2p mechanism.
> The first paragraph of Section 3.1 says that both end nodes of BFD session
> "should be in active mode". Is that "SHOULD"? I think that since the BFD
> session is bootstrapped the ingress node SHOULD be in Passive mode and
> egress node MUST be in Active mode.
> Even more so. I think that MPLS-TP does not significantly benefit from BFD
> session bootstrapping, OOB exchange of discriminators, because it was
> added
> to LSP Ping to address ambiguity resulted from PHP, which is excluded from
> MPLS-TP.
>
>
> Regards,
> Greg
>


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


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


--00032555971e429608047f570948-- From benjamin.niven-jenkins@bt.com Fri Feb 12 02:14:26 2010 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 33AAD3A7221; Fri, 12 Feb 2010 02:14:26 -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 hV6tY8oE4IjD; Fri, 12 Feb 2010 02:14:25 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by core3.amsl.com (Postfix) with ESMTP id EE8A53A68F2; Fri, 12 Feb 2010 02:14:24 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 12 Feb 2010 10:15:40 +0000 Received: from RDW083V001RVA1.domain1.systemhost.net ([10.187.59.9]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 12 Feb 2010 10:15:41 +0000 From: To: Date: Fri, 12 Feb 2010 10:11:52 +0000 Thread-Topic: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents Thread-Index: AQHKq8xUtW3lsX5EY0GfxE12KglYyA== Message-ID: <9C31FA6F6F10D641B0B16A91BC374187B87434902D@RDW083V001RVA1.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls-tp@ietf.org Subject: Re: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 12 Feb 2010 10:14:26 -0000 Lou, I support draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext becoming a WG docu= ment. I have no opinion on draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext as I haven't = read it. Ben P.S. As draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext is relevant to MPLS-= TP I guess this poll should have also included the MPLS-TP mailing list (wh= ich I have cc'd)? -------- Original Message -------- Subject: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg document= s Date: Tue, 09 Feb 2010 11:24:36 -0500 From: Lou Berger To: CCAMP WG All, The authors of the drafts have stated that they are ready for this poll to resume. Therefore: This message starts a two week poll on making the documents listed below ccamp working group documents. Please send a mail to the mailing list indicating "yes/support to both" or "no/do not support either". Of course, you may also support one but not the other. (We will assume that you support/object to both if you don't specify.) Please send mail even if you expressed an opinion on the prior poll. The documents being polled are: http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext The poll ends Tuesday February 23. Much thanks, Lou -------- Original Message -------- Subject: [CCAMP] Suspended: poll on making draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document Date: Tue, 01 Dec 2009 07:07:03 -0500 From: Lou Berger To: ccamp@ietf.org 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 > > > _______________________________________________ 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 -- 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 elisa.bellagamba@ericsson.com Fri Feb 12 03:27:16 2010 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 A123828C1AE; Fri, 12 Feb 2010 03:27:16 -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 Xbc8WuJrabOe; Fri, 12 Feb 2010 03:27:15 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B29BF28C198; Fri, 12 Feb 2010 03:27:14 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-55-4b753b5edfc2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 04.8B.31641.E5B357B4; Fri, 12 Feb 2010 12:28:30 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.221]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 12 Feb 2010 12:28:26 +0100 From: Elisa Bellagamba To: Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" , Adrian Farrel Date: Fri, 12 Feb 2010 12:28:23 +0100 Thread-Topic: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: Acqpoc0GbBr7At2GSTqdy72jzVYwGgCNHuBA Message-ID: <55EA962132DCC84286EB4429B9CA773A1CF003AAFB@ESESSCMS0356.eemea.ericsson.se> References: <4B7187EE.30404@pi.nu> In-Reply-To: <4B7187EE.30404@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== Subject: Re: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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, 12 Feb 2010 11:27:16 -0000 Hello, Yes/support I'll provide comments soon. Elisa -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= oa Andersson Sent: den 9 februari 2010 17:06 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; Adrian = Farrel Subject: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls = working group document All, This is to start two week poll on making draft-fbb-mpls-tp-data-plane-00.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". Note that this ID is a starting point for what needs to be documented on the MPLS data plane for the MPLS-TP project. The ID is largely based on the data plane specific text from the framework, together with some notes concerning how the Transport Profile of MPLS might operate over Ethernet. /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 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From hans.sjostrand@transmode.com Fri Feb 12 03:31:01 2010 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 BB5E928C122; Fri, 12 Feb 2010 03:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 M30vhHjzpXLT; Fri, 12 Feb 2010 03:31:00 -0800 (PST) Received: from gw1.transmode.se (gw1.transmode.se [213.115.205.20]) by core3.amsl.com (Postfix) with ESMTP id 1D3CE3A72C6; Fri, 12 Feb 2010 03:31:00 -0800 (PST) Received: from sesr04.transmode.se (sesr04.transmode.se [192.168.201.15]) by gw1.transmode.se (Postfix) with ESMTP id 1719F65000C; Fri, 12 Feb 2010 12:32:16 +0100 (CET) To: ccamp@ietf.org, mpls-tp@ietf.org MIME-Version: 1.0 X-KeepSent: 9918E501:7812B407-C12576C8:00375C89; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: =?ISO-8859-15?Q?Hans_Sj=F6strand?= Message-ID: Date: Fri, 12 Feb 2010 12:32:15 +0100 X-MIMETrack: Serialize by Router on sesr04/Transmode(Release 8.5.1|September 28, 2009) at 2010-02-12 12:32:16, Serialize complete at 2010-02-12 12:32:16 Content-Type: multipart/alternative; boundary="=_alternative 00398FA4C12576C8_=" X-Mailman-Approved-At: Fri, 12 Feb 2010 06:51:45 -0800 Subject: Re: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 12 Feb 2010 11:31:01 -0000 This is a multipart message in MIME format. --=_alternative 00398FA4C12576C8_= Content-Type: text/plain; charset="US-ASCII" Yes, I support draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext becoming WG doc. Unfortunately I know far to little about otn/sdh to have an educated opinion about draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext. I think this poll is interesting to the folks on the mpls-tp list aswell, hence the cross-post. Apologize for those of you who get duplicates. Regards /// Hasse -------- Original Message -------- Subject: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents Date: Tue, 09 Feb 2010 11:24:36 -0500 From: Lou Berger To: ccamp at ietf.org All, The authors of the drafts have stated that they are ready for this poll to resume. Therefore: This message starts a two week poll on making the documents listed below ccamp working group documents. Please send a mail to the mailing list indicating "yes/support to both" or "no/do not support either". Of course, you may also support one but not the other. (We will assume that you support/object to both if you don't specify.) Please send mail even if you expressed an opinion on the prior poll. The documents being polled are: http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext The poll ends Tuesday February 23. Much thanks, Lou -------- Original Message -------- Subject: [CCAMP] Suspended: poll on making draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document Date: Tue, 01 Dec 2009 07:07:03 -0500 From: Lou Berger To: ccamp at ietf.org 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 at ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ CCAMP mailing list CCAMP at ietf.org https://www.ietf.org/mailman/listinfo/ccamp --=_alternative 00398FA4C12576C8_= Content-Type: text/html; charset="US-ASCII" Yes, I support draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext becoming WG doc.

Unfortunately I know far to little about otn/sdh to have an educated opinion about draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext.

I think this poll is interesting to the folks on the mpls-tp list aswell, hence the cross-post. Apologize for those of you who get duplicates.

Regards
/// Hasse

-------- Original Message --------
Subject:  [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents
Date: Tue, 09 Feb 2010 11:24:36 -0500
From: Lou Berger <lberger at labn.net>
To: ccamp at ietf.org

All,

The authors of the drafts have stated that they are ready for this
poll to resume.  Therefore:

This message starts a two week poll on making the documents listed below
ccamp working group documents.  Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support either".  Of
course, you may also support one but not the other.  (We will assume
that you support/object to both if you don't specify.)  Please send
mail even if you expressed an opinion on the prior poll.

The documents being polled are:

http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext
http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext

The poll ends Tuesday February 23.

Much thanks,
Lou

-------- Original Message --------
Subject: [CCAMP] Suspended: poll on making
draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document
Date: Tue, 01 Dec 2009 07:07:03 -0500
From: Lou Berger <lberger at labn.net>
To: ccamp at ietf.org

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 at ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>
_______________________________________________
CCAMP mailing list
CCAMP at ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--=_alternative 00398FA4C12576C8_=-- From jeff.tantsura@ericsson.com Fri Feb 12 06:55:25 2010 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 E11003A78BC; Fri, 12 Feb 2010 06:55:25 -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 AG+GtNi3L2rt; Fri, 12 Feb 2010 06:55:24 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id C91403A76F3; Fri, 12 Feb 2010 06:55:24 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o1CEwFPX017673; Fri, 12 Feb 2010 08:58:15 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.106]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 12 Feb 2010 09:56:40 -0500 From: Jeff Tantsura To: "mpls-tp@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Date: Fri, 12 Feb 2010 09:56:38 -0500 Thread-Topic: [mpls-tp] [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: Acqpoc0GbBr7At2GSTqdy72jzVYwGgCNHuBAAAdE4LA= Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6047FC0066C@EUSAACMS0701.eamcs.ericsson.se> References: <4B7187EE.30404@pi.nu> <55EA962132DCC84286EB4429B9CA773A1CF003AAFB@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <55EA962132DCC84286EB4429B9CA773A1CF003AAFB@ESESSCMS0356.eemea.ericsson.se> 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] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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, 12 Feb 2010 14:55:26 -0000 Hi, Yes/support Cheers, Jeff -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= oa Andersson Sent: den 9 februari 2010 17:06 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; Adrian = Farrel Subject: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls = working group document All, This is to start two week poll on making draft-fbb-mpls-tp-data-plane-00.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". Note that this ID is a starting point for what needs to be documented on the MPLS data plane for the MPLS-TP project. The ID is largely based on the data plane specific text from the framework, together with some notes concerning how the Transport Profile of MPLS might operate over Ethernet. /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 _______________________________________________ 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 lberger@labn.net Fri Feb 12 06:57:01 2010 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 3B7EA28C198 for ; Fri, 12 Feb 2010 06:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.113, 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 sNpVvdGrPBfq for ; Fri, 12 Feb 2010 06:57:01 -0800 (PST) Received: from outbound-mail-01.bluehost.com (outbound-mail-01.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 110CB3A78BC for ; Fri, 12 Feb 2010 06:57:01 -0800 (PST) Received: (qmail 5120 invoked by uid 0); 12 Feb 2010 14:51:40 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy4.bluehost.com with SMTP; 12 Feb 2010 14:51: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:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=xNJoSqyXN5SwWxMwO/t8cV7H9GdjGmWX+eP5PMcHz92xmzk9JOtALuOYb5ioKHFT+9k12BOvhG4TBxPn6LHNZNTyvQteSlg2E/pkf6vq/YnFIZmqCkC9kXHoSajPlHoq; 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 1Nfwrs-0006ml-0F; Fri, 12 Feb 2010 07:51:40 -0700 Message-ID: <4B756AD8.7090204@labn.net> Date: Fri, 12 Feb 2010 09:51:04 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4 MIME-Version: 1.0 To: MPLS-TP ad hoc team , "MPLS-TP" , CCAMP References: <4B718C44.90001@labn.net> <4B753224.6070409@pi.nu> In-Reply-To: <4B753224.6070409@pi.nu> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 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] EXTENDED: Poll on OAM related drafts to ccamp wg documents 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, 12 Feb 2010 14:57:01 -0000 CCAMP, MPLS-TP, MPLS-TP ad hoc team, Loa (and others) have correctly pointed out that this poll should have been announced on all three lists as it includes an MPLS-TP document. As the announcement on the other lists was delayed, the comment/poll period has been extended through Monday March 1. Please send comments to the ccamp list. Thank you, Lou (CCAMP co-chair) On 2/12/2010 5:49 AM, Loa Andersson wrote: > MPLS-TP ad hoc team, > > please note that the ccamp working group in the IETF are polling > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext to become a > working group docuemnt. > > Comments should be sent to ccamp working group mailing list. > > /Loa > > Lou Berger wrote: >> All, >> >> The authors of the drafts have stated that they are ready for this >> poll to resume. Therefore: >> >> This message starts a two week poll on making the documents listed below >> ccamp working group documents. Please send a mail to the mailing list >> indicating "yes/support to both" or "no/do not support either". Of >> course, you may also support one but not the other. (We will assume >> that you support/object to both if you don't specify.) Please send >> mail even if you expressed an opinion on the prior poll. >> >> The documents being polled are: >> >> http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext >> http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext >> >> The poll ends Tuesday February 23. >> >> Much thanks, >> Lou >> >> -------- Original Message -------- >> Subject: [CCAMP] Suspended: poll on making >> draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document >> Date: Tue, 01 Dec 2009 07:07:03 -0500 >> From: Lou Berger >> To: ccamp@ietf.org >> >> 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 >>> >>> >>> >> _______________________________________________ >> 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 Adrian.Farrel@huawei.com Fri Feb 12 07:52:50 2010 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 60CF43A737D; Fri, 12 Feb 2010 07:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 uKHALjXjWs+Y; Fri, 12 Feb 2010 07:52:49 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id A988D3A6A8A; Fri, 12 Feb 2010 07:52:49 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXQ00A0KK67BX@usaga01-in.huawei.com>; Fri, 12 Feb 2010 07:54:08 -0800 (PST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXQ004SIK64B7@usaga01-in.huawei.com>; Fri, 12 Feb 2010 07:54:07 -0800 (PST) Date: Fri, 12 Feb 2010 11:36:26 +0000 From: Adrian Farrel To: mpls@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: mpls-chairs@tools.ietf.org, ccamp-chairs@tools.ietf.org, draft-ietf-mpls-explicit-resource-control-bundle@tools.ietf.org, ccamp@ietf.org Subject: [CCAMP] draft-ietf-mpls-explicit-resource-control-bundle X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 15:52:50 -0000 Hi MPLS working group, I received a publication request from the MPLS co-chairs for draft-ietf-mpls-explicit-resource-control-bundle at the end of November, and (after a period on my queue) I spent some time trying to understand the history of this draft and why it has popped out now. What I find is: MPLS WG last call was held in May 2006. This last call was made on the -01 revision. There were no comments during the last call. We are now at version -06 and, while I don't think the document has change substantially over the last 5 revisions, it is clearly not the revision that was lat called. Since it has been 3.5 since the last call, I am returning the draft to the WG and asking the chairs to do some things for me. 1. Poll the MPLS and CCAMP WGs to make sure that there really is interest and support for this work. 2. Re-issue the WG last call and ensure that CCAMP is involved in the last call. The next action should be an email from the MPLS chairs. Thanks, Adrian From steven.schwager@tellabs.com Fri Feb 12 09:05:58 2010 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 5675F28C1C8 for ; Fri, 12 Feb 2010 09:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=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 b5GDpdhqT-KS for ; Fri, 12 Feb 2010 09:05:55 -0800 (PST) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id 3EB0B3A73C8 for ; Fri, 12 Feb 2010 09:05:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,462,1262563200"; d="scan'208,217";a="1310211931" Received: from usnvwwmspht02.hq.tellabs.com (HELO usnvwwmspht02.tellabs-west.tellabsinc.net) ([172.23.211.70]) by mx4-priv.tellabs.com with ESMTP; 12 Feb 2010 17:07:14 +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; Fri, 12 Feb 2010 11:07:14 -0600 From: "Schwager, Steven D." To: "ccamp@ietf.org" Date: Fri, 12 Feb 2010 11:07:12 -0600 Thread-Topic: Looking for clear direction about RRO generation for bidirectional LSPs Thread-Index: AcqsBdHGANhi4HfCRXyhsL966r6HoA== Message-ID: <1F08A56363136D48A1A762C17FD6EF6E829E584852@EX-NAP.tellabs-west.tellabsinc.net> 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_1F08A56363136D48A1A762C17FD6EF6E829E584852EXNAPtellabsw_" MIME-Version: 1.0 Subject: [CCAMP] Looking for clear direction about RRO generation for bidirectional LSPs 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, 12 Feb 2010 17:15:05 -0000 --_000_1F08A56363136D48A1A762C17FD6EF6E829E584852EXNAPtellabsw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Any, Even after reading RFC 4990's clarifications on RRO processing, my colleagu= es and I are still uncertain how to interpret certain statements in some of= the RFCs. I was hoping a simple example would eliminate our confusion. In the following diagram, nodes A, B and C are connected by numbered interf= aces 1, 2, 3 and 4. ----- ----- ----- | |1 2| |3 4| | | A |-------| B |-------| C | | | lbl=3Dx | | lbl=3Dy | | ----- ----- ----- A bidirectional LSP is established from A to C, using label x upstream and = downstream from 1 to 2, and label y upstream and downstream from 3 to 4. L= abel recording for the RRO is enabled. The nodes are recording incoming an= d outgoing interfaces. Our best guess is that RRO carried in the updated PATH message (updated to = carry downstream label info) from B to C would be: RRO=3D(3,y,y,2,1,x,x), w= here 3 is the first subobject relative to the beginning of the RRO. 3, 2 a= nd 1 represent subobjects for numbered interfaces. y and x represent subob= jects for labels. Our best guess is that the RRO carried in the RESV from B to A would contai= n the following subobjects: RRO=3D(2,3,y,y,4). Note 1: The above subobjects pushed by node B for the PATH appear to confli= ct with statements made in RFC 4990 (6.1.3 "4. Link ID identifying the inco= ming (upstream) TE link, followed by a Link ID identifying the outgoing (do= wnstream) TE link, optionally followed by a Component Interface ID and/or o= ne or two Labels.") Note 2: The above subobjects only include labels for the outgoing links (p= er RFC 4990). Can anyone confirm or correct the RROs in the PATH and RESV examples? Best Regards, Steve Schwager --_000_1F08A56363136D48A1A762C17FD6EF6E829E584852EXNAPtellabsw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Any,=

 

 

Even after reading RFC 4990's clarifications on RRO processing, my colleagues and I are still uncertain how to interpret certain statements in some of the RFCs.  I = was hoping a simple example would eliminate our confusion.

 

In the following diagr= am, nodes A, B and C are connected by numbered interfaces 1, 2, 3 and 4.  =

 

 

 

 -----  = ;       -----         -----   

|   &nb= sp; |1     2|     |3     4|     |

|  A  |-------|  B  |-------|  C  |=

|   &nb= sp; | lbl=3Dx |     | lbl=3Dy |     |

 -----  = ;       -----         -----

 

 

A bidirectional LSP is established from A to C, using label x upstream and downstream from 1 to 2,= and label y upstream and downstream from 3 to 4.  Label recording for the = RRO is enabled.  The nodes are recording incoming and outgoing interfaces.=

 

 

O=
ur best guess is that RRO carried in the updated PATH message (updated to c=
arry downstream label info) from B to C would be: RRO=3D(3,y,y,2,1,x,x), wh=
ere 3 is the first subobject relative to the beginning of the RRO.&nbs=
p; 3, 2 and 1 represent subobjects for numbered interfaces.  y and x r=
epresent subobjects for labels.

 

Our best guess is that= the RRO carried in the RESV from B to A would contain the following subobjects: RRO=3D(2,3,y,y,4).

 

<=
o:p> 
Note 1: The =
above subobjects pushed by node B for the PATH appear to conflict with stat=
ements made in RFC 4990 (6.1.3 “4. Link ID identifying the incoming (=
upstream) TE link, followed by a Link ID identifying the outgoing (downstre=
am) TE link, optionally followed by a Component Interface ID and/or one or =
two Labels.”)

 

Note 2:  The abov= e subobjects only include labels for the outgoing links (per RFC 4990).<= /o:p>

 

 

Can anyone confirm or correct the RROs in the PATH and RESV examples?

 

 

Best Regards,

Steve Schwager

 

--_000_1F08A56363136D48A1A762C17FD6EF6E829E584852EXNAPtellabsw_-- From gregimirsky@gmail.com Fri Feb 12 15:29:37 2010 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 34B353A7916; Fri, 12 Feb 2010 15:29:37 -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 WMG-GpgB0fmt; Fri, 12 Feb 2010 15:29:36 -0800 (PST) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id E24783A75F1; Fri, 12 Feb 2010 15:29:35 -0800 (PST) Received: by bwz28 with SMTP id 28so2506121bwz.14 for ; Fri, 12 Feb 2010 15:30:52 -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=ukdOqH9wvV367aBeAp78mQF1pd3DcGkwGCYnvUudpeo=; b=fNCgEX16/7opgYwVQGF9TcowlMAQ6y73d3VD/6uvWGRwFODBinWGXiKmYA2tM67375 fDzPht9CuhokKgO9cundNl/UfxoEG6FojtyUQRpZTaRknAsFOq485Q2eyZ7OU0WxHbqi 40U2MtwT7tN7vAF+p4PLG0rH8vZyzhhmO8LnM= 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=ALg/IICYBzWAUcuYqGlHk37Ccr8Njg4Zy3ZxCBXGSzPEvY3gOGN6ovRLoChCIkUck6 15nonDY0M0TAbWwsOi8dblBgM1ukltOfZVuq34SiesJkqWyyYmpgF/hzS6I7irhWMNNM XuorZMkjFSbHupcQdQWrWeHwdFp+xXWstD4xI= MIME-Version: 1.0 Received: by 10.204.49.88 with SMTP id u24mr1340064bkf.44.1266017452361; Fri, 12 Feb 2010 15:30:52 -0800 (PST) In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD4DF49C6044@EUSAACMS0703.eamcs.ericsson.se> References: <60C093A41B5E45409A19D42CF7786DFD4DF49C6044@EUSAACMS0703.eamcs.ericsson.se> Date: Fri, 12 Feb 2010 15:30:52 -0800 Message-ID: <787be2781002121530g74ea76c1j6a29897177493842@mail.gmail.com> From: Greg Mirsky To: Autumn Liu Content-Type: multipart/alternative; boundary=000325556df2870871047f6fa8e0 Cc: "mpls@ietf.org" , "ccamp@ietf.org" Subject: Re: [CCAMP] [mpls] Ask for comments on draft-liu-mpls-rsvp-te-gr-frr 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, 12 Feb 2010 23:29:37 -0000 --000325556df2870871047f6fa8e0 Content-Type: text/plain; charset=ISO-8859-1 Dear Autumn, I would appreciate you you help me to understand the problem that your work addresses. As I understand scenario described in Section 3 (will refer to Fig.1) the protected LSP have failed, local repair is in use. And then Control plane on either node R2 or on node R4 restarts. Further the documet states the problem as "the protected LSP is not preserved" during GR recovery. Before the GR the working LSP is R1-R2-R6-R4-R5 and it is preserved. Correct? Do you see the problem that information about segment R2-R3-R4 will not be preserved after GR? But that would not affect the traffic or working path. Correct? Regards, Greg On Fri, Feb 12, 2010 at 10:57 AM, Autumn Liu wrote: > Hi MPLSers, > > We'd appreciate any comments and suggestions on the draft * > http://www.ietf.org/id/draft-liu-mpls-rsvp-te-gr-frr-00.txt* > . > > This draft describes a mechanism to extend RSVP-TE Graceful Restart to work > under conditions where FRR has occurred. > > Regards, > Autumn > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --000325556df2870871047f6fa8e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Autumn,
I would appreciate you you help me to understand the proble= m that your work addresses. As I understand scenario described in Section 3= (will refer to Fig.1) the protected LSP have failed, local repair is in us= e. And then Control plane on either node R2 or on node R4 restarts. Further= the documet states the problem as "the protected LSP is not preserved= " during GR recovery. Before the GR the working LSP is R1-R2-R6-R4-R5 = and it is preserved. Correct? Do you see the problem that information about= segment R2-R3-R4 will not be preserved after GR? But that would not affect= the traffic or working path. Correct?

Regards,
Greg

On Fri, Feb 12, 2010= at 10:57 AM, Autumn Liu <autumn.liu@ericsson.com> wrote:
Hi MPLSers,
=A0
We'd appreciate any comments and suggestions on the draft http://www.ietf.org/id/draft-liu-mpls-rs= vp-te-gr-frr-00.txt.
=A0
This draft describes a mechanism to extend RSVP-TE Graceful Restart to= work under conditions where FRR has occurred.
=A0
Regards,
Autumn
=A0
=A0
=A0

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


--000325556df2870871047f6fa8e0-- From Dimitri.Papadimitriou@alcatel-lucent.com Sat Feb 13 04:42:55 2010 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 D0D5A28C116; Sat, 13 Feb 2010 04:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.494 X-Spam-Level: X-Spam-Status: No, score=-5.494 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599, HELO_EQ_FR=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 GH8gl4YAHv7g; Sat, 13 Feb 2010 04:42:54 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 363D028C0ED; Sat, 13 Feb 2010 04:42:53 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o1DCi2Ff028130; Sat, 13 Feb 2010 13:44:03 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 13 Feb 2010 13:44:02 +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: Sat, 13 Feb 2010 13:42:02 +0100 Message-ID: <00275A5B436CA441900CB10936742A3803F230B9@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-11 Thread-Index: AcqsUc4YQasrI29RQXOaeZNtDbMp8AAV55aw References: From: "PAPADIMITRIOU Dimitri" To: , "VIGOUREUX MARTIN" , , , , X-OriginalArrivalTime: 13 Feb 2010 12:44:02.0717 (UTC) FILETIME=[3894BCD0:01CAACAA] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: ccamp@ietf.org, adrian.farrel@huawei.com Subject: Re: [CCAMP] Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-11 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, 13 Feb 2010 12:42:55 -0000 Hi, I will address the points listed here below. Thanks for the review.=20 Concerning the following comment: > Sections 5.1.4, 5.2.1 and 8 have me confused about the=20 > Attributes Flags TLV: > - Section 5.1.4 defines an Attributes Flags TLV here for Virtual TE links: the CALL ATTRIBUTE is defined in this document=20 > - Section 5.2.1 points to RFC 5420 for what's apparently a different > Attributes Flags TLV and defines a Pre-Planned LSP flag in > that TLV. for Soft FA's: the LSP ATTRIBUTE defined in RFC 5420 is used to = introduced a new flag > - Section 8 then apparently instructs IANA to put that bit into the > Attributes Flags TLV defined in Section 5.1.4 . > Something appears to be wrong with this combination - what was > the intent? If these two TLVs are the same, or share a common bit > assignment registry, that should be stated. I will clarify this because as they both refer to "attributes" precision = of the terms used is indeed critical Thanks, -dimitri. > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com]=20 > Sent: Saturday, February 13, 2010 3:11 AM > To: PAPADIMITRIOU Dimitri; VIGOUREUX MARTIN;=20 > shiomoto.kohei@lab.ntt.co.jp; dbrungard@att.com;=20 > jean-louis.leroux@rd.francetelecom.com; gen-art@ietf.org > Cc: Black_David@emc.com; lberger@labn.net;=20 > adrian.farrel@huawei.com; ccamp@ietf.org > Subject: Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-11 >=20 > I have been selected as the General Area Review Team (Gen-ART)=20 > reviewer for this draft (for background on Gen-ART, please see=20 > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >=20 > Please resolve these comments along with any other Last Call > comments you may receive. >=20 > Document: draft-ietf-ccamp-gmpls-mln-extensions-11 > Reviewer: David L. Black > Review Date: February 12, 2010 > IETF LC End Date: February 16, 2010 >=20 > Summary: > This draft is basically ready for publication, but has nits > that should be fixed before publication. >=20 > Comments: > This draft extends GMPLS routing and signaling to support the > operation of GMPLS Multi-Layer/Multi-Region Networks. One needs to be > a GMPLS expert to fully understand this draft - although, I'm not a > GMPLS expert, the draft reads reasonably well. All of these comments > are minor. >=20 > The IACD sub-TLV formats for OSPF and IS-IS appear to be=20 > identical. If > they are in fact identical, a single ASCII text diagram should be used > for both. >=20 > The description of the IACD sub-TLV format does not describe the > Max LSP Bandwidth fields. At a minimum the units and/or encoding of > these fields should be described here, even thought the full > specification may be elsewhere. >=20 > Please add the values for Type and Length for the XRO SC subobject > into the ASCII figure in Section 4.1.1 . >=20 > Section 4.1.2 defines a new subobject by making minor changes to an > existing one in another RFC; a complete ASCII diagram of the new > subobject would be helpful - please add one. >=20 > Sections 5.1.4, 5.2.1 and 8 have me confused about the=20 > Attributes Flags TLV: > - Section 5.1.4 defines an Attributes Flags TLV here > - Section 5.2.1 points to RFC 5420 for what's apparently a different > Attributes Flags TLV and defines a Pre-Planned LSP flag in > that TLV. > - Section 8 then apparently instructs IANA to put that bit into the > Attributes Flags TLV defined in Section 5.1.4 . > Something appears to be wrong with this combination - what was > the intent? If these two TLVs are the same, or share a common bit > assignment registry, that should be stated. >=20 > idnits 2.12.00 found three nits: >=20 > =3D=3D The page length should not exceed 58 lines per page, but=20 > there was 1 > longer page, the longest (page 1) being 62 lines >=20 > ** There are 144 instances of too long lines in the=20 > document, the longest > one being 1 character in excess of 72. >=20 > =3D=3D Line 781 has weird spacing: '...ndwidth is st...' >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) = 293-7786 > black_david@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 >=20 >=20 From yaacov.weingarten@nsn.com Sun Feb 14 00:56:39 2010 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 B81403A731D for ; Sun, 14 Feb 2010 00:56:39 -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 it1xhD1Pj8VV for ; Sun, 14 Feb 2010 00:56:38 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 836673A7255 for ; Sun, 14 Feb 2010 00:56:38 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1E8w2HU028496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 14 Feb 2010 09:58:02 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1E8w0cO031778 for ; Sun, 14 Feb 2010 09:58:02 +0100 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Feb 2010 09:56:33 +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: Sun, 14 Feb 2010 09:56:32 +0100 Message-ID: <62D9AC1F11702146A0387CBFF3A8CD3D01FC4EBA@DEMUEXC030.nsn-intra.net> In-Reply-To: <4B756AD8.7090204@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] EXTENDED: Poll on OAM related drafts to ccamp wg documents Thread-Index: Acqr8ucZGyJF8zuIRh+9EFkKwKLlRwBYH7Cg References: <4B718C44.90001@labn.net> <4B753224.6070409@pi.nu> <4B756AD8.7090204@labn.net> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: "CCAMP" X-OriginalArrivalTime: 14 Feb 2010 08:56:33.0166 (UTC) FILETIME=[9B3A4AE0:01CAAD53] Subject: Re: [CCAMP] [mpls-tp] EXTENDED: Poll on OAM related drafts to ccamp wg documents 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: Sun, 14 Feb 2010 08:56:39 -0000 Yes/ Support both drafts Yaacov Weingarten Nokia Siemens Networks -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Lou Berger Sent: Friday, February 12, 2010 16:51 To: MPLS-TP ad hoc team; MPLS-TP; CCAMP Subject: [mpls-tp] EXTENDED: Poll on OAM related drafts to ccamp wg documents CCAMP, MPLS-TP, MPLS-TP ad hoc team, Loa (and others) have correctly pointed out that this poll should have been announced on all three lists as it includes an MPLS-TP document. As the announcement on the other lists was delayed, the comment/poll period has been extended through Monday March 1. Please send comments to the ccamp list. Thank you, Lou (CCAMP co-chair) On 2/12/2010 5:49 AM, Loa Andersson wrote: > MPLS-TP ad hoc team, >=20 > please note that the ccamp working group in the IETF are polling > draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext to become a > working group docuemnt. >=20 > Comments should be sent to ccamp working group mailing list. >=20 > /Loa >=20 > Lou Berger wrote: >> All, >> >> The authors of the drafts have stated that they are ready for this >> poll to resume. Therefore: >> >> This message starts a two week poll on making the documents listed below >> ccamp working group documents. Please send a mail to the mailing list >> indicating "yes/support to both" or "no/do not support either". Of >> course, you may also support one but not the other. (We will assume >> that you support/object to both if you don't specify.) Please send >> mail even if you expressed an opinion on the prior poll. >> >> The documents being polled are: >> >> http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext >> http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ex t >> >> The poll ends Tuesday February 23. >> >> Much thanks, >> Lou >> >> -------- Original Message -------- >> Subject: [CCAMP] Suspended: poll on making >> draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document >> Date: Tue, 01 Dec 2009 07:07:03 -0500 >> From: Lou Berger >> To: ccamp@ietf.org >> >> 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 >>> >>> >>> >> _______________________________________________ >> 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 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From nurit.sprecher@nsn.com Sun Feb 14 07:46:19 2010 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 0ACF53A71CA; Sun, 14 Feb 2010 07:46:19 -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 uDhN59RALODJ; Sun, 14 Feb 2010 07:46:17 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 177463A677D; Sun, 14 Feb 2010 07:46:16 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1EFleqO021897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 14 Feb 2010 16:47:41 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1EFleVl009097; Sun, 14 Feb 2010 16:47:40 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.111]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Feb 2010 16:47:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAAD8D.09A4AE50" Date: Sun, 14 Feb 2010 16:47:39 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326401D82100@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wgdocuments Thread-Index: Acqr8xc/PuPZyzbERzCrjtjQyBNPwwBmQJPw References: From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: X-OriginalArrivalTime: 14 Feb 2010 15:47:40.0298 (UTC) FILETIME=[09FBEEA0:01CAAD8D] Cc: mpls-tp@ietf.org Subject: Re: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wgdocuments 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: Sun, 14 Feb 2010 15:46:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAAD8D.09A4AE50 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, Yes/I support both drafts.=20 Best regards, Nurit =20 =20 -------- Original Message --------=20 Subject: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents=20 Date: Tue, 09 Feb 2010 11:24:36 -0500=20 From: Lou Berger =20 To: ccamp at ietf.org=20 All,=20 The authors of the drafts have stated that they are ready for this=20 poll to resume. Therefore:=20 This message starts a two week poll on making the documents listed below ccamp working group documents. Please send a mail to the mailing list=20 indicating "yes/support to both" or "no/do not support either". Of=20 course, you may also support one but not the other. (We will assume=20 that you support/object to both if you don't specify.) Please send=20 mail even if you expressed an opinion on the prior poll.=20 The documents being polled are:=20 http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext =20 http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ex t =20 The poll ends Tuesday February 23.=20 Much thanks,=20 Lou=20 -------- Original Message --------=20 Subject: [CCAMP] Suspended: poll on making=20 draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document=20 Date: Tue, 01 Dec 2009 07:07:03 -0500=20 From: Lou Berger =20 To: ccamp at ietf.org=20 The document authors have asked that we defer this poll until they make=20 some further updates to this document. The plan will be to re-poll the=20 WG once the document authors inform us that the changes have been made.=20 Given recent discussion on the list, I expect that this poll will take place together with the other technology specific OAM document,=20 draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext.=20 Please keep in mind that becoming a WG document does not mean that the=20 technical details of a document are frozen. It does mean that the=20 working group becomes the authoritative body for technical content,=20 i.e., WG consensus drives a WG document while author consensus drives an individual document.=20 Lou=20 On 11/23/2009 5:20 PM, BRUNGARD, DEBORAH A (ATTLABS) wrote:=20 > All,=20 >=20 > This is to start a two week poll on making=20 > draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt a ccamp working group=20 > document. Send a mail to the mailing list indicating "yes/support" or=20 > "no/do not support".=20 >=20 > The poll ends Monday, Dec. 7, 2009.=20 >=20 > Deborah=20 > _______________________________________________=20 > CCAMP mailing list=20 > CCAMP at ietf.org=20 > https://www.ietf.org/mailman/listinfo/ccamp =20 >=20 >=20 >=20 _______________________________________________=20 CCAMP mailing list=20 CCAMP at ietf.org=20 https://www.ietf.org/mailman/listinfo/ccamp =20 ------_=_NextPart_001_01CAAD8D.09A4AE50 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

Yes/I support both drafts.

Best regards,

Nurit

 

 


-------- Original Message -------- =
Subject:  [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg = documents
Date: Tue, 09 Feb 2010 11:24:36 -0500
From: Lou Berger <lberger at labn.net>
To: ccamp at ietf.org

All,

The authors of the drafts have stated that they are ready for = this
poll to resume.  Therefore:

This message starts a two week poll on making the documents listed = below
ccamp working group documents.  Please send a mail to the mailing = list
indicating "yes/support to both" or "no/do not support either". =  Of
course, you may also support one but not the other.  (We will = assume
that you support/object to both if you don't specify.)  Please = send
mail even if you expressed an opinion on the prior poll.

The documents being polled are:

http://tools.ietf.org/h= tml/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext
http://tools.ietf.org/h= tml/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext

The poll ends Tuesday February 23.

Much thanks,
Lou

-------- Original Message --------
Subject: [CCAMP] Suspended: poll on making
draft-kern-ccamp-rsvp-t= e-sdh-otn-oam-ext-01.txt ccamp wg document
Date: Tue, 01 Dec 2009 07:07:03 -0500
From: Lou Berger <lberger at labn.net>
To: ccamp at ietf.org

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 at ietf.org
> https://www.ietf.org/ma= ilman/listinfo/ccamp
>
>
>
_______________________= ________________________
CCAMP mailing list
CCAMP at ietf.org
https://www.ietf.org/ma= ilman/listinfo/ccamp

------_=_NextPart_001_01CAAD8D.09A4AE50-- From root@core3.amsl.com Mon Feb 15 01:15:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 048473A7ADD; Mon, 15 Feb 2010 01:15: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: <20100215091502.048473A7ADD@core3.amsl.com> Date: Mon, 15 Feb 2010 01:15:01 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-pc-spc-rsvpte-ext-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: Mon, 15 Feb 2010 09:15: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 : RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network. Author(s) : D. Caviglia, et al. Filename : draft-ietf-ccamp-pc-spc-rsvpte-ext-07.txt Pages : 22 Date : 2010-02-15 In a transport network scenario, where Data Plane connections are controlled either by a Generalized Multi-Protocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or by a Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in [RFC5493]. This memo describes an extension to GMPLS RSVP-TE signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the handover procedures must never impact an already established Data plane connection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-spc-rsvpte-ext-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-pc-spc-rsvpte-ext-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-15011330.I-D@ietf.org> --NextPart-- From autumn.liu@ericsson.com Fri Feb 12 10:55:58 2010 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 55ACE28C1BB; Fri, 12 Feb 2010 10:55: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=[AWL=-0.001, 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 8nHSPnn0jukp; Fri, 12 Feb 2010 10:55:57 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 74F3A3A78E7; Fri, 12 Feb 2010 10:55:53 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o1CIwkea006258; Fri, 12 Feb 2010 12:58:46 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 12 Feb 2010 13:57:12 -0500 From: Autumn Liu To: "mpls@ietf.org" , "ccamp@ietf.org" Date: Fri, 12 Feb 2010 13:57:11 -0500 Thread-Topic: Ask for comments on draft-liu-mpls-rsvp-te-gr-frr Thread-Index: AcqsFS63w9mrjrbmQ2GtZOUxGHr7hA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD4DF49C6044@EUSAACMS0703.eamcs.ericsson.se> 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_60C093A41B5E45409A19D42CF7786DFD4DF49C6044EUSAACMS0703e_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 15 Feb 2010 06:27:04 -0800 Subject: [CCAMP] Ask for comments on draft-liu-mpls-rsvp-te-gr-frr 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, 12 Feb 2010 18:55:58 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD4DF49C6044EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi MPLSers, We'd appreciate any comments and suggestions on the draft http://www.ietf.o= rg/id/draft-liu-mpls-rsvp-te-gr-frr-00.txt. This draft describes a mechanism to extend RSVP-TE Graceful Restart to work= under conditions where FRR has occurred. Regards, Autumn --_000_60C093A41B5E45409A19D42CF7786DFD4DF49C6044EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi MPLSers,
 
We'd appreciate any comments and suggestions on the draft http://www.ietf.org/id/draft-liu-mpls-rsvp-te-gr-frr-00.txt= .
 
This draft describes a mechanism to extend RSVP-TE Graceful Restart to= work under conditions where FRR has occurred.
 
Regards,
Autumn
 
 
 
 --_000_60C093A41B5E45409A19D42CF7786DFD4DF49C6044EUSAACMS0703e_-- From Black_David@emc.com Fri Feb 12 18:10:23 2010 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 35A6028C25A; Fri, 12 Feb 2010 18:10:23 -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 0Ce97UhpJ6ce; Fri, 12 Feb 2010 18:10:18 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 1CF1428C183; Fri, 12 Feb 2010 18:10:16 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o1D2BOZG016911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Feb 2010 21:11:24 -0500 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Fri, 12 Feb 2010 21:11:11 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o1D2B9Jh010288; Fri, 12 Feb 2010 21:11:10 -0500 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.201]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Feb 2010 21:11:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Feb 2010 21:11:08 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-11 Thread-Index: AcqsUc4YQasrI29RQXOaeZNtDbMp8A== From: To: , , , , , X-OriginalArrivalTime: 13 Feb 2010 02:11:09.0285 (UTC) FILETIME=[CEA6D950:01CAAC51] X-EMM-EM: Active X-Mailman-Approved-At: Mon, 15 Feb 2010 06:27:04 -0800 Cc: ccamp@ietf.org, Black_David@emc.com, adrian.farrel@huawei.com Subject: [CCAMP] Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-11 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, 13 Feb 2010 02:10:23 -0000 I have been selected as the General Area Review Team (Gen-ART)=20 reviewer for this draft (for background on Gen-ART, please see=20 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-gmpls-mln-extensions-11 Reviewer: David L. Black Review Date: February 12, 2010 IETF LC End Date: February 16, 2010 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: This draft extends GMPLS routing and signaling to support the operation of GMPLS Multi-Layer/Multi-Region Networks. One needs to be a GMPLS expert to fully understand this draft - although, I'm not a GMPLS expert, the draft reads reasonably well. All of these comments are minor. The IACD sub-TLV formats for OSPF and IS-IS appear to be identical. If they are in fact identical, a single ASCII text diagram should be used for both. The description of the IACD sub-TLV format does not describe the Max LSP Bandwidth fields. At a minimum the units and/or encoding of these fields should be described here, even thought the full specification may be elsewhere. Please add the values for Type and Length for the XRO SC subobject into the ASCII figure in Section 4.1.1 . Section 4.1.2 defines a new subobject by making minor changes to an existing one in another RFC; a complete ASCII diagram of the new subobject would be helpful - please add one. Sections 5.1.4, 5.2.1 and 8 have me confused about the Attributes Flags = TLV: - Section 5.1.4 defines an Attributes Flags TLV here - Section 5.2.1 points to RFC 5420 for what's apparently a different Attributes Flags TLV and defines a Pre-Planned LSP flag in that TLV. - Section 8 then apparently instructs IANA to put that bit into the Attributes Flags TLV defined in Section 5.1.4 . Something appears to be wrong with this combination - what was the intent? If these two TLVs are the same, or share a common bit assignment registry, that should be stated. idnits 2.12.00 found three nits: =3D=3D The page length should not exceed 58 lines per page, but there = was 1 longer page, the longest (page 1) being 62 lines ** There are 144 instances of too long lines in the document, the = longest one being 1 character in excess of 72. =3D=3D Line 781 has weird spacing: '...ndwidth is st...' Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) = 293-7786 black_david@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From db3546@att.com Mon Feb 15 13:23:48 2010 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 785BB3A682A for ; Mon, 15 Feb 2010 13:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 EffkibYfVWB8 for ; Mon, 15 Feb 2010 13:23:46 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 89A9E3A69F7 for ; Mon, 15 Feb 2010 13:23:46 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1266269116!31654436!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 31963 invoked from network); 15 Feb 2010 21:25:17 -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; 15 Feb 2010 21:25:17 -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 o1FLP8Rg019734 for ; Mon, 15 Feb 2010 16:25:08 -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 o1FLP4vX019650 for ; Mon, 15 Feb 2010 16:25:04 -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: Mon, 15 Feb 2010 16:25:11 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FYI-Call For Papers to IEEE Comm. Mag. OTN Feature Topic Thread-Index: AcquhVsbizCHLy/LT6Gm6UTrzC6nug== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Subject: [CCAMP] FYI-Call For Papers to IEEE Comm. Mag. OTN Feature Topic 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, 15 Feb 2010 21:23:48 -0000 FYI- For those interested in OTN, IEEE Comm. Magazine has a call for papers on OTN (deadline April 30). This will have primary emphasis on the data plane: http://dl.comsoc.org/ci1/ ------------------------------------------------------------------------ ----------------------------- Call for Papers on the Feature Topic: ITU-T Optical Transport Network (OTN)=20 IEEE Communications Magazine Background In the late 1980s and 1990s, SONET/SDH became the global set of standards for optical network communications. SONET/SDH technology carries all types of communications services today, in under-sea cable systems and terrestrial systems all around the work. However, OTN technology, defined around the architecture in ITU-T G.872, is fast becoming the technology of choice for today's optical networks. The OTN standards define physical interfaces, signal framing, multiplexing of client signals, equipment functions, performance monitoring, and network management aspects. Network operators are deploying equipment compliant to OTN standards in backbone, metro, and access networks for carrying voice, video, and data of all sorts. This equipment consists of traditional transmission systems, multiplexers, cross-connects, switches, routers, and nearly every conceivable combination of them in newer packet-optical equipment. As a result, practically every segment of the IEEE Communications Magazine readership has some exposure to OTN technologies.=20 The first wave of OTN standards were developed in the late 1990s and early 2000s. Given the timing of the initial OTN standards publications (just at the collapse of the over-inflated Internet boom), deployment of OTN based equipment was initially very slow. However, as more economical solutions are developed to replace aging active systems, OTN deployments are growing rapidly. Expanding utilization of OTN technologies is creating greater demands for OTN functionality. To meet the demands for greater packet transport efficiency and expected 40/100 Gb/s Ethernet transport, OTN standards are being significantly enhanced at this time. Revised ITU-T G.709 is leading the way with a significant revision approved at the end of 2009.=20 With the expanding deployment and enhanced standards for OTN technologies, there is a great deal of new OTN related information that should interest IEEE Communications Magazine readers.=20 Scope of Contributions This feature topic is intended to provide tutorial information and original research articles to the Communications Magazine readers on OTN standards, applications, and related issues associated with them. Papers are solicited in, although not limited to, the following areas:=20 * OTN standards overview=20 * Recent OTN standards updates=20 * Future of OTN standards=20 * Network applications for OTN technology=20 * Value of OTN technology compared to other technologies=20 Schedule for Submissions Submission Deadline: April 30, 2010 Notification of Acceptance: June 11, 2010 Final Manuscript Due: July 1, 2010 Publication Date: September 2010=20 For manuscript submission, the authors should follow the IEEE Magazine guidelines under "information for Authors" at http://dl.comsoc.org/livepubs/ci1/info/sub_guidelines.html. Manuscripts must be submitted through the magazine's submissions Web site at: http://mc.manuscriptcentral.com/commag-ieee . Please select "September2010/ITU-T OTN" in the drop down menu.=20 Feature Topic Editors For additional information about the Feature Topic, please contact the Guest Editors listed below: Mark Jones mark.jones@tellabs.com=20 Deborah Brungard dbrungard@att.com=20 Huub van Helvoort hhelvoort@huawei.com=20 Winston Mok winston_mok@pmc-sierra.com=20 From scott.mansfield@ericsson.com Wed Feb 17 05:48:35 2010 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 A11A628C0E2 for ; Wed, 17 Feb 2010 05:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.067 X-Spam-Level: X-Spam-Status: No, score=-5.067 tagged_above=-999 required=5 tests=[AWL=1.532, 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 bxTat0KB3yid for ; Wed, 17 Feb 2010 05:48:34 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 8C1313A7CFE for ; Wed, 17 Feb 2010 05:48:34 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o1HDq0UI008207; Wed, 17 Feb 2010 07:52:00 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.106]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 17 Feb 2010 08:50:12 -0500 From: Scott Mansfield To: Lou Berger , CCAMP WG Date: Wed, 17 Feb 2010 08:49:17 -0500 Thread-Topic: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents Thread-Index: AcqppETvVMuClGJ/S0KtYaGvxLjiHAGM6T9g Message-ID: References: <4B718C44.90001@labn.net> In-Reply-To: <4B718C44.90001@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] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 17 Feb 2010 13:48:35 -0000 Yes/support to both draft-kern and draft-bellagamba. Regards, -scott.=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Tuesday, February 09, 2010 11:25 AM To: CCAMP WG Subject: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg document= s All, The authors of the drafts have stated that they are ready for this poll to = resume. Therefore: This message starts a two week poll on making the documents listed below cc= amp working group documents. Please send a mail to the mailing list indica= ting "yes/support to both" or "no/do not support either". Of course, you m= ay also support one but not the other. (We will assume that you support/ob= ject to both if you don't specify.) Please send mail even if you expressed= an opinion on the prior poll. The documents being polled are: http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext The poll ends Tuesday February 23. Much thanks, Lou -------- Original Message -------- Subject: [CCAMP] Suspended: poll on making draft-kern-ccamp-rsvp-te-sdh-otn= -oam-ext-01.txt ccamp wg document Date: Tue, 01 Dec 2009 07:07:03 -0500 From: Lou Berger To: ccamp@ietf.org The document authors have asked that we defer this poll until they make som= e further updates to this document. The plan will be to re-poll the WG onc= e the document authors inform us that the changes have been made. Given recent discussion on the list, I expect that this poll will take pl= ace together with the other technology specific OAM document, draft-bellaga= mba-ccamp-rsvp-te-mpls-tp-oam-ext. Please keep in mind that becoming a WG document does not mean that the tech= nical details of a document are frozen. It does mean that the working grou= p 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=20 > draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt a ccamp working group=20 > document. Send a mail to the mailing list indicating "yes/support" or=20 > "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 > > > _______________________________________________ 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 eric.gray@ericsson.com Wed Feb 17 06:36:34 2010 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 77CE53A7D09 for ; Wed, 17 Feb 2010 06:36:34 -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 EFIJ2T8v+lJf for ; Wed, 17 Feb 2010 06:36:33 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 8160F3A7D0C for ; Wed, 17 Feb 2010 06:36:33 -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 o1HEds3h026156 for ; Wed, 17 Feb 2010 08:39:58 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.106]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 17 Feb 2010 09:38:10 -0500 From: Eric Gray To: CCAMP WG Date: Wed, 17 Feb 2010 09:38:06 -0500 Thread-Topic: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents Thread-Index: AcqppETvVMuClGJ/S0KtYaGvxLjiHAGOmPZA Message-ID: References: <4B718C44.90001@labn.net> In-Reply-To: <4B718C44.90001@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] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 17 Feb 2010 14:36:34 -0000 Yes to both.=20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Tuesday, February 09, 2010 11:25 AM To: CCAMP WG Subject: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg document= s All, The authors of the drafts have stated that they are ready for this poll to resume. Therefore: This message starts a two week poll on making the documents listed below ccamp working group documents. Please send a mail to the mailing list indicating "yes/support to both" or "no/do not support either". Of course, you may also support one but not the other. (We will assume that you support/object to both if you don't specify.) Please send mail even if you expressed an opinion on the prior poll. The documents being polled are: http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext The poll ends Tuesday February 23. Much thanks, Lou -------- Original Message -------- Subject: [CCAMP] Suspended: poll on making draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document Date: Tue, 01 Dec 2009 07:07:03 -0500 From: Lou Berger To: ccamp@ietf.org 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 > > > _______________________________________________ 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 eric.gray@ericsson.com Wed Feb 17 06:37:34 2010 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 D75DB28C13F; Wed, 17 Feb 2010 06:37:34 -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 NhUsGcDNQjWN; Wed, 17 Feb 2010 06:37:34 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 0469328C131; Wed, 17 Feb 2010 06:37:33 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o1HEes8T026658; Wed, 17 Feb 2010 08:40:59 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.106]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 17 Feb 2010 09:39:11 -0500 From: Eric Gray To: "mpls-tp@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Date: Wed, 17 Feb 2010 09:39:09 -0500 Thread-Topic: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: Acqpod20yImQSL5nQS6RZLzzdWw3ZAGPQWjQ Message-ID: References: <4B7187EE.30404@pi.nu> In-Reply-To: <4B7187EE.30404@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 Subject: Re: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Wed, 17 Feb 2010 14:37:35 -0000 Yes -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= oa Andersson Sent: Tuesday, February 09, 2010 11:06 AM To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; Adrian = Farrel Subject: [CCAMP] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls = working group document All, This is to start two week poll on making draft-fbb-mpls-tp-data-plane-00.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". Note that this ID is a starting point for what needs to be documented on the MPLS data plane for the MPLS-TP project. The ID is largely based on the data plane specific text from the framework, together with some notes concerning how the Transport Profile of MPLS might operate over Ethernet. /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 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From david.sinicrope@ericsson.com Wed Feb 17 06:50:11 2010 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 AB5493A7ED2 for ; Wed, 17 Feb 2010 06:50:11 -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 JgZMXi8nB6py for ; Wed, 17 Feb 2010 06:50:10 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 595AD3A7ED1 for ; Wed, 17 Feb 2010 06:50:10 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o1HErZQq001309; Wed, 17 Feb 2010 08:53:35 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.238]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 17 Feb 2010 09:51:45 -0500 From: David Sinicrope To: Lou Berger , CCAMP WG Date: Wed, 17 Feb 2010 09:51:33 -0500 Thread-Topic: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents Thread-Index: AcqppEUg6GPY2OyYQECy/jC3WuZ6hgGPG0Jx Message-ID: In-Reply-To: <4B718C44.90001@labn.net> 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] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 17 Feb 2010 14:50:11 -0000 Yes, support for both On 2/9/10 11:24 AM, "Lou Berger" wrote: All, The authors of the drafts have stated that they are ready for this poll to resume. Therefore: This message starts a two week poll on making the documents listed below ccamp working group documents. Please send a mail to the mailing list indicating "yes/support to both" or "no/do not support either". Of course, you may also support one but not the other. (We will assume that you support/object to both if you don't specify.) Please send mail even if you expressed an opinion on the prior poll. The documents being polled are: http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext The poll ends Tuesday February 23. Much thanks, Lou -------- Original Message -------- Subject: [CCAMP] Suspended: poll on making draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document Date: Tue, 01 Dec 2009 07:07:03 -0500 From: Lou Berger To: ccamp@ietf.org 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 > > > _______________________________________________ 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 agmalis@gmail.com Wed Feb 17 10:46:58 2010 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 103E928C19D; Wed, 17 Feb 2010 10:46: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 fllzsFHnr0CU; Wed, 17 Feb 2010 10:46:57 -0800 (PST) Received: from mail-yx0-f190.google.com (mail-yx0-f190.google.com [209.85.210.190]) by core3.amsl.com (Postfix) with ESMTP id CB76A28C178; Wed, 17 Feb 2010 10:46:56 -0800 (PST) Received: by yxe28 with SMTP id 28so5086567yxe.29 for ; Wed, 17 Feb 2010 10:48:33 -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=cgecIBlyxK2lSHP/Eb6FbiR9w3ePqgk4o7jN5joy6Vk=; b=p02hs25UvKZCiV6B7eBlxV2qaeWe02Ko/wRNndwCqLXncUTDQlP2u7GPmkBZnBILNC GBMKkxk0zWTwmYng5WSJ/D8XV3u2mpMByGliyHyk3Wtk4FAjm0evb+TqbM2TkzNywQgc ieo7BYTbwmFX1lVCJIxG3UwSK619cnpRe9sSg= 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=aCoE05f1bxqYkgeqW0mRMyjlqdh7hrrt4ttR/dHiYxbuZ43UcjtZCQ+Cf+2I2hzTBp WfQkvIulZiDGmd8FQ8Ho2a6YmsyEk/B6sHKLi7fweFZ+2KFoh73pF7yWaGUygOVQWgTi 82aTSQNQeTzRwgMT5NTIGQVHTz1MNxWZiq0Ac= MIME-Version: 1.0 Received: by 10.101.184.38 with SMTP id l38mr7333291anp.81.1266432509293; Wed, 17 Feb 2010 10:48:29 -0800 (PST) In-Reply-To: References: <1265795114.4b72802ab7a84@discus.singnet.com.sg> From: "Andrew G. Malis" Date: Wed, 17 Feb 2010 13:48:09 -0500 Message-ID: <8c99930d1002171048s7ec00560we4683577e50403ba@mail.gmail.com> To: Alexander Vainshtein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , Loa@core3.amsl.com, "ccamp@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" , "mngpl@singnet.com.sg" Subject: Re: [CCAMP] [mpls] [PWE3] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Wed, 17 Feb 2010 18:46:58 -0000 I support the draft, and also Sasha's comment below seems quite reasonable. Cheers, Andy On Wed, Feb 10, 2010 at 10:31 AM, Alexander Vainshtein wrote: > Max, > The MPLS-TP framework draft is defined as Informational while the MPLS-TP= data plane > draft is defined as Standard Track. This seems to be one good reason not = to merge them. > > On the other hand, it makes sense to me move all the data-plane issues fr= om the > Framework draft to the data plane one and just to reference in in the Fra= mework draft. > > Regards, > =A0 =A0 Sasha > >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On >> Behalf Of mngpl@singnet.com.sg >> Sent: Wednesday, February 10, 2010 11:45 AM >> To: Loa Andersson >> Cc: mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; mpls-tp@ietf.org >> Subject: Re: [PWE3] [mpls-tp] poll on making >> draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document >> >> Hi Loa and the authors, >> >> From what I read, the main key aspect of this draft defines a >> new ethernet MAC discovery through the use of multicast MAC. >> The rest of the drafts discuss about specific dataplane >> implementation that is align with >> draft-ietf-mpls-tp-framework-10, which calls it profiling. >> >> Suggestion, why not put profile details into the framework >> draft? This improves readability? Or unless there can other >> type of profiling. >> >> /Max >> --- Loa Andersson wrote: >> >> > All, >> > >> > This is to start two week poll on making >> > draft-fbb-mpls-tp-data-plane-00.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". >> > >> > Note that this ID is a starting point for what needs to >> > be documented on the MPLS data plane for the MPLS-TP >> > project. The ID is largely based on the data plane specific >> > text from the framework, together with some notes concerning >> > how the Transport Profile of MPLS might operate over Ethernet. >> > >> > >> > /Loa >> > >> > >> > -- >> > >> > >> > 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 >> > _______________________________________________ >> > mpls-tp mailing list >> > mpls-tp@ietf.org >> > https://www.ietf.org/mailman/listinfo/mpls-tp >> > >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From loa@pi.nu Wed Feb 17 11:28:48 2010 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 907D93A7EFC; Wed, 17 Feb 2010 11:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 oxP1Hd0QPopP; Wed, 17 Feb 2010 11:28:47 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id C029E3A75C6; Wed, 17 Feb 2010 11:28:47 -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 72BB1D4052; Wed, 17 Feb 2010 20:30:25 +0100 (CET) Message-ID: <4B7C43CF.3070700@pi.nu> Date: Wed, 17 Feb 2010 20:30:23 +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 WG , pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-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: Wed, 17 Feb 2010 19:28:48 -0000 All, this is to start a two week working group poll on making draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt an mpls working group document. Send your response to the mpls-tp@ietf.org mailing list (only), indicating "yes/support" or "no/do not support". The poll ends eob March 5th 2001. /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 tom.nadeau@bt.com Wed Feb 17 11:51:05 2010 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 5F1E328C16E; Wed, 17 Feb 2010 11:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] 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 C-fnzDhmm6UE; Wed, 17 Feb 2010 11:51:04 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 6718D3A7F01; Wed, 17 Feb 2010 11:51:04 -0800 (PST) Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.105]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Feb 2010 19:52:43 +0000 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Feb 2010 19:52:41 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Wed, 17 Feb 2010 14:52:41 -0500 From: "Thomas D. Nadeau" To: Loa Andersson , "mpls-tp@ietf.org" , , CCAMP WG , Message-ID: Thread-Topic: [CCAMP] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt Thread-Index: AcqwCsOG/A+rfo1YNEWX0UNMcXX4Iw== In-Reply-To: <4B7C43CF.3070700@pi.nu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Feb 2010 19:52:43.0102 (UTC) FILETIME=[C4C707E0:01CAB00A] Subject: Re: [CCAMP] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-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: Wed, 17 Feb 2010 19:51:05 -0000 Support. On 2/17/10 2:30 PM, "Loa Andersson" wrote: > All, > > > this is to start a two week working group poll on making > draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt > an mpls working group document. > > Send your response to the mpls-tp@ietf.org mailing list > (only), indicating "yes/support" or "no/do not support". > > The poll ends eob March 5th 2001. > > /Loa From gregimirsky@gmail.com Wed Feb 17 12:14:57 2010 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 C0CE528C245; Wed, 17 Feb 2010 12:14:57 -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 TPbsnnhktAoc; Wed, 17 Feb 2010 12:14:56 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id D62C628C16E; Wed, 17 Feb 2010 12:14:55 -0800 (PST) Received: by fxm7 with SMTP id 7so9212112fxm.28 for ; Wed, 17 Feb 2010 12:16:31 -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:content-type; bh=uGLyLhOuKE0Y1673DhsQDj/0Kg4d/z5QnCbi6fClYAY=; b=MVRJxX/ljZ++E4bqE7kJqt7ZnOV69TmzMg4Egbzc2PobPQNBGfUBWsciXGir/UhG5Q 8rivg97N8G+ucGxFOZ9mSx7by/qasne6Cy01Efd+XsdlEotKfTo1KsG8dMDImrgXMD/V uXMmQ6kqqE4hD3hrLEaFQv+/3qPa/EMR91KJY= 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 :content-type; b=jXWGVSPmFD3o38RD5U4RnunEd4Ub+oXf/rf2s/lk5qd0rQSnQfsBNJn+aV6KCGlBtb iv8oXsYUVnROcmV0H18CJLNIfdK5oSU+4w1fOXVr/oTbp01EJqwzf+CUq6ADOyvxa68l f4ykVZ3Z+gLjtRbVT6M+yKt1Yye4Hc/zx3uO0= MIME-Version: 1.0 Received: by 10.204.5.154 with SMTP id 26mr1672782bkv.62.1266437791325; Wed, 17 Feb 2010 12:16:31 -0800 (PST) In-Reply-To: <4B7C43CF.3070700@pi.nu> References: <4B7C43CF.3070700@pi.nu> Date: Wed, 17 Feb 2010 12:16:31 -0800 Message-ID: <787be2781002171216n19917213k5dc16b96df92bcb@mail.gmail.com> From: Greg Mirsky To: "mpls-tp@ietf.org" , mpls@ietf.org, CCAMP WG , pwe3@ietf.org Content-Type: multipart/alternative; boundary=00151758fb9eae9dc0047fd186a5 Subject: Re: [CCAMP] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-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: Wed, 17 Feb 2010 20:14:57 -0000 --00151758fb9eae9dc0047fd186a5 Content-Type: text/plain; charset=ISO-8859-1 yes/support On Wed, Feb 17, 2010 at 11:30 AM, Loa Andersson wrote: > All, > > > this is to start a two week working group poll on making > draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt > an mpls working group document. > > Send your response to the mpls-tp@ietf.org mailing list > (only), indicating "yes/support" or "no/do not support". > > The poll ends eob March 5th 2001. > > /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 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --00151758fb9eae9dc0047fd186a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable yes/support

On Wed, Feb 17, 2010 at 11:30= AM, Loa Andersson <loa@p= i.nu> wrote:
All,


this is to start a two week working group poll on making
draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt
an mpls working group document.

Send your response to the mpls-tp@ietf.org mailing list
(only), indicating "yes/support" or "no/do not support"= .

The poll ends eob March 5th 2001.

/Loa
--


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

--00151758fb9eae9dc0047fd186a5-- From jdrake@juniper.net Wed Feb 17 12:39:30 2010 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 3BF7E28C16B; Wed, 17 Feb 2010 12:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 w32Vh5L7kPwT; Wed, 17 Feb 2010 12:39:29 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 0E1083A7BCF; Wed, 17 Feb 2010 12:39:28 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKS3xUX7nGgO1NqdMziz7CCW4xFmZnLixN@postini.com; Wed, 17 Feb 2010 12:41:09 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 17 Feb 2010 12:39:54 -0800 From: John E Drake To: Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , CCAMP WG , "pwe3@ietf.org" Date: Wed, 17 Feb 2010 12:39:52 -0800 Thread-Topic: [CCAMP] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt Thread-Index: AcqwB6wRWS9tbIMxQEWM+RKAL8uo7QACaovg Message-ID: <5E893DB832F57341992548CDBB33316398050D9620@EMBX01-HQ.jnpr.net> References: <4B7C43CF.3070700@pi.nu> In-Reply-To: <4B7C43CF.3070700@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 Subject: Re: [CCAMP] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-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: Wed, 17 Feb 2010 20:39:30 -0000 Yes > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Wednesday, February 17, 2010 11:30 AM > To: mpls-tp@ietf.org; mpls@ietf.org; CCAMP WG; pwe3@ietf.org > Subject: [CCAMP] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures- > 02.txt >=20 > All, >=20 >=20 > this is to start a two week working group poll on making > draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt > an mpls working group document. >=20 > Send your response to the mpls-tp@ietf.org mailing list > (only), indicating "yes/support" or "no/do not support". >=20 > The poll ends eob March 5th 2001. >=20 > /Loa > -- >=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 From gregimirsky@gmail.com Wed Feb 17 12:57:45 2010 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 4BCCA28C14A; Wed, 17 Feb 2010 12:57:45 -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 RFUhFB12iFgM; Wed, 17 Feb 2010 12:57:44 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 59D633A7BED; Wed, 17 Feb 2010 12:57:43 -0800 (PST) Received: by fxm7 with SMTP id 7so9269435fxm.28 for ; Wed, 17 Feb 2010 12:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=E9KOtCUMwnU/9vt7zUvgsMGXsRkSIzTlP3tS+8QheEA=; b=fE4JgG9yduekCxrXOBI7FfderTOXaMSXrLRv6x8UsYXZrOmueiQvWShTkYE8oO2wA9 DagO1P/Qac1PjLK9YO2IiuaxchycmgXg0+16OFJR/kM5rWSbG4E30sFGc7aRQ1hLiktQ S4+eS9EemkY63hXpdHAgDTMINqlNWixYBb6eQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qtkeDcURC2F9VrfYhUMutADgd5mKSEXBE6lqwDNw9Z+Xa2Wgx2zf1zsCs6CMW5PUcT JWGuzDMsZgnxmBZjztVtVc2LWDEVRMUc8Bq0MakDjqJO1K+Ca0rkphn4yx36Q9zzQ1WT tjYrKpCRcHX3ynD0jySnVVpu5KcowGkJg/Zs8= MIME-Version: 1.0 Received: by 10.204.143.130 with SMTP id v2mr5632506bku.7.1266440358309; Wed, 17 Feb 2010 12:59:18 -0800 (PST) Date: Wed, 17 Feb 2010 12:59:18 -0800 Message-ID: <787be2781002171259x1c9a3536k7dafabed3ab99f66@mail.gmail.com> From: Greg Mirsky To: Nitin Bahadur , Rahul Aggarwal , David Ward , "Thomas D. Nadeau" , mpls@ietf.org, mpls-tp@ietf.org, ccamp@ietf.org, pwe3 Content-Type: multipart/alternative; boundary=0015175caa56afb286047fd21f5b Subject: [CCAMP] Comments on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-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, 17 Feb 2010 20:57:45 -0000 --0015175caa56afb286047fd21f5b Content-Type: text/plain; charset=ISO-8859-1 Dear Authors and All, below are my comments to the document: - Abstract - "widely deployed" to replace "widely deployment" - Section 2.1, Figure 2 - Section 3 RFC 5586 states that if ACH TLVs might be present then ACH TLV Header must be present. The Length of ACH TLV Header may set to zero in no ACH TLVs are actually present in the given packet. Said that I turn to figure 2 that presents LSP Ping packet with ACH format. The ACH TLV Header is not presented in the format even though presence of ACH TLVs is indicated. I think that proper LSP Ping with ACH format will look as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS Label stack | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | LSP-Ping Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP-Ping payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Section 2.3 discusses optional use of Source Address TLV but the sentence "Only 1 source address TLV MUST be present in a LSP-Ping packet." may be interpreted as the Source Address TLV is mandatory. I propose to change "MUST" to "MAY" in the sentence - Figure 3 - same comments regarding ACH TLV Header in the format as for Figure 2 Regards, Greg --0015175caa56afb286047fd21f5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors and All,
below are my comments to the document:
  • = Abstract - "widely deployed" to replace "widely deployment&q= uot;
  • Section 2.1, Figure 2 - Section 3 RFC 5586 states that if ACH = TLVs might be present then ACH TLV Header must be present. The Length of AC= H TLV Header may set to zero in no ACH TLVs are actually present in the giv= en packet. Said that I turn to figure 2 that presents LSP Ping packet with = ACH format. The ACH TLV Header is not presented in the format even though p= resence of ACH TLVs is indicated. I think that proper LSP Ping with ACH for= mat will look as:
       0                           1            =
                2                            3

       0 1 2 3 4 5=
 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+

       |          =
                          MPLS Label stack                                |=

       |                     =
                                                                           =
|

       +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                            =
  GAL                                           |

       +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 1|Version|   Reserved    |     LSP-Pin=
g Channel Type     |

       +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                   ACH TLV H=
eader                                  |

       +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                          AC=
H TLVs                                      |

       |          =
                                                                           =
           |
<=
span style=3D"font-family: arial,helvetica,sans-serif;">       +-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       |          =
                          LSP-Ping payload                               |<=
/span>
       |                        =
                                                                        |

       +-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • Section 2= .3 discusses optional use of Source Address TLV but the sentence "Only= 1 source address TLV MUST be present in a LSP-Ping packet." may be in= terpreted as the Source Address TLV is mandatory. I propose to change "= ;MUST" to "MAY" in the sentence
  • Figure 3 - same comments regarding ACH TLV Header in the format as for = Figure 2
Regards,
Greg

--0015175caa56afb286047fd21f5b-- From agmalis@gmail.com Wed Feb 17 13:04:40 2010 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 8A2E128C24C for ; Wed, 17 Feb 2010 13:04:40 -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 qxYEs-krt81c for ; Wed, 17 Feb 2010 13:04:39 -0800 (PST) Received: from mail-gx0-f216.google.com (mail-gx0-f216.google.com [209.85.217.216]) by core3.amsl.com (Postfix) with ESMTP id 6F74A28C245 for ; Wed, 17 Feb 2010 13:04:39 -0800 (PST) Received: by gxk8 with SMTP id 8so1336014gxk.9 for ; Wed, 17 Feb 2010 13:06:14 -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=Pyyn2p0eAAZKWt5bf4+po9zMJtKXd8yn5l66xjTO9gI=; b=e5TB1wPZZqR4Hg5OikwK6DIjmjs3oRjHFGV+7rX3UAAJoXpYyv1YzenNGrAJ//RDOJ NLYjI5PT5tZWjrkKIborx7bYu8Y+LVplMbFN95EUVq+PYOMSGmTHviViVucEncTpl8MO eGqvh4tnh8lSujYtyySSWo6XX3c3mmdedtSfc= 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=ChV/t+ORb1ilpOvt8buKKMP0Ib5M7VBKpOJTVl3S18q8fmyEDBKPCNeYZKd1JdLMaQ Ib+HEtUtV2eW4yIMZlnVG4rGwNEMllobHytiN9uETfFgi39pu7udm9lHuC1dPlJoRMio h7j5/pwEOS8fvRGzRpMbNNiyKMajylVSfHCS8= MIME-Version: 1.0 Received: by 10.101.159.31 with SMTP id l31mr7664201ano.80.1266440774111; Wed, 17 Feb 2010 13:06:14 -0800 (PST) In-Reply-To: <4B718C44.90001@labn.net> References: <4B718C44.90001@labn.net> From: "Andrew G. Malis" Date: Wed, 17 Feb 2010 16:05:54 -0500 Message-ID: <8c99930d1002171305o45e14576n296346a7e4b3d08b@mail.gmail.com> To: Lou Berger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CCAMP WG Subject: Re: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 17 Feb 2010 21:04:40 -0000 Lou, Yes/support to both. Cheers, Andy On Tue, Feb 9, 2010 at 11:24 AM, Lou Berger wrote: > All, > > The authors of the drafts have stated that they are ready for this > poll to resume. =A0Therefore: > > This message starts a two week poll on making the documents listed below > ccamp working group documents. =A0Please send a mail to the mailing list > indicating "yes/support to both" or "no/do not support either". =A0Of > course, you may also support one but not the other. =A0(We will assume > that you support/object to both if you don't specify.) =A0Please send > mail even if you expressed an opinion on the prior poll. > > The documents being polled are: > > http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext > http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext > > The poll ends Tuesday February 23. > > Much thanks, > Lou > > -------- Original Message -------- > Subject: [CCAMP] Suspended: poll on making > draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document > Date: Tue, 01 Dec 2009 07:07:03 -0500 > From: Lou Berger > To: ccamp@ietf.org > > The document authors have asked that we defer this poll until they make > some further updates to this document. =A0The plan will be to re-poll the > WG once the document authors inform us that the changes have been made. > =A0Given 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. =A0It 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 >> >> >> > _______________________________________________ > 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 Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Wed Feb 17 18:13:45 2010 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 82BF63A79EF for ; Wed, 17 Feb 2010 18:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.11 X-Spam-Level: * X-Spam-Status: No, score=1.11 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=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 Szu80KEaQJDM for ; Wed, 17 Feb 2010 18:13:43 -0800 (PST) Received: from mx05.melco.co.jp (mx05.melco.co.jp [192.218.140.145]) by core3.amsl.com (Postfix) with ESMTP id A2B6E3A75C8 for ; Wed, 17 Feb 2010 18:13:42 -0800 (PST) Received: from mr05.melco.co.jp (mr05 [133.141.98.165]) by mx05.melco.co.jp (Postfix) with ESMTP id 3CA5C5D415 for ; Thu, 18 Feb 2010 10:56:35 +0900 (JST) Received: from mr05.melco.co.jp (localhost [127.0.0.1]) by mr05.imss (Postfix) with ESMTP id 1303EA8F4 for ; Thu, 18 Feb 2010 10:56:35 +0900 (JST) Received: from elgw.isl.melco.co.jp (unknown [133.141.13.130]) by mr05.melco.co.jp (Postfix) with ESMTP id A38ADAB57 for ; Thu, 18 Feb 2010 10:56:34 +0900 (JST) Received: from iswall2a.isl.melco.co.jp (iswall2a.isl.melco.co.jp [10.74.245.24]) by elgw.isl.melco.co.jp (Postfix) with ESMTP id 74A7831F3EC for ; Thu, 18 Feb 2010 10:56:34 +0900 (JST) Received: from iswall2a.isl.melco.co.jp (localhost.localdomain [127.0.0.1]) by localhost.isl.melco.co.jp (Postfix) with ESMTP id 2666622CBE7 for ; Thu, 18 Feb 2010 10:56:34 +0900 (JST) Received: from LeakStopper186 (stopper2.isl.melco.co.jp [10.74.245.36]) by iswall2a.isl.melco.co.jp (Postfix) with SMTP id 0F78C22CBB3 for ; Thu, 18 Feb 2010 10:56:34 +0900 (JST) Received: (qmail 25653 invoked by uid 507); 18 Feb 2010 10:56:33 +0900 Received: from unknown (HELO mob2501.isl.melco.co.jp) (133.141.13.135) by 0 with SMTP; 18 Feb 2010 10:51:35 +0900 Received: from KF5ZXSFDNOKJ9H8 (unknown [10.62.216.183]) by mob2501.isl.melco.co.jp (Postfix) with ESMTP id D2B9421D8148; Thu, 18 Feb 2010 10:51:34 +0900 (JST) From: "Shoichiro Seno" To: , , , Date: Thu, 18 Feb 2010 10:51:38 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-index: AcqwPOiWRafWxv+2Q/6NVNU13BvRMA== Subject: [CCAMP] iPOP 2010 submission deadline extended to March 1 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, 18 Feb 2010 02:13:45 -0000 CCAMP, MPLS, MPLS-TP and PCE subscribers, Please find below iPOP 2010 CFP with the extended deadline. Sorry for multiple messages. Sho Seno ----------------------------------------------------------------------- Call for Presentation 6th International Conference on IP + Optical Network (iPOP 2010) June 10-11, 2010 NTT Musashino R&D Center, Tokyo, Japan http://www.pilab.jp/ipop2010/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: March 1, 2010 (extended) Notification of acceptance: April 2, 2010 Submission deadline of final presentation slides: April 23, 2010 The Technical Program Committee for iPOP 2010 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not limited to the following: * GMPLS/ASON technologies * GMPLS Network management, OA&M * Multi-layer network (MLN) / Multi-region network (MRN) * Path Computation Element (PCE), Traffic engineering * Inter-area/Inter-AS network * L1VPN, Bandwidth on Demand, and Photonic Grid * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Carrier Ethernet and MPLS-TP * Photonic Network for NxGN and NwGN * Application with high-bandwidth demand * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstracts of a 400 words and a maximum of 1 page, including figures and diagrams, speaker's name, affiliation, and contact information to the Technical Program Committee at ipop2010-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2010/ for more details. General Chairs: Tomonori Aoyama, Keio University, Japan Bijan Jabbari, ISOCORE, USA Hisashi Koumura, NTT, Japan Organization Committee Co-Chairs: Naoaki Yamanaka, Keio University, Japan Atsushi Hiramatsu, NTT, Japan Soichiro Araki, NEC, Japan Exhibition Committee Co-Chairs: Kohei Shiomoto, NTT, Japan Munefumi Tsurusawa, KDDI R&D, Japan Technical Program Committee Co-Chairs: Eiji Oki, University of Electro-Communications, Japan Monique Morrow, Cisco Systems, USA ---------------------------------------------------------------------------- ---- From nitinb@juniper.net Wed Feb 17 23:29:37 2010 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 6668028C10D; Wed, 17 Feb 2010 23:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 80FCaRE+OjGb; Wed, 17 Feb 2010 23:29:36 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id DFB363A7DD2; Wed, 17 Feb 2010 23:29:35 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKS3zswraBGjj9lUI4zD1n49hbm1j7mmv+@postini.com; Wed, 17 Feb 2010 23:31:18 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 17 Feb 2010 23:28:45 -0800 From: Nitin Bahadur To: Greg Mirsky , Rahul Aggarwal , David Ward , "Thomas D. Nadeau" , "mpls@ietf.org" , "mpls-tp@ietf.org" , "ccamp@ietf.org" , pwe3 Date: Wed, 17 Feb 2010 23:28:42 -0800 Thread-Topic: Comments on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02 Thread-Index: AcqwFBO+zMuQ18V2SDiRtp4XiQfBkAAV+tHV Message-ID: In-Reply-To: <787be2781002171259x1c9a3536k7dafabed3ab99f66@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] Comments on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-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: Thu, 18 Feb 2010 07:29:37 -0000 Hi Greg, Thanks for reading the draft in detail. See inline below for responses t= o your comments. On 2/17/10 12:59 PM, "Greg Mirsky" wrote: Dear Authors and All, below are my comments to the document: * Abstract - "widely deployed" to replace "widely deployment" NB> Will fix that. * Section 2.1, Figure 2 - Section 3 RFC 5586 states that if ACH TLVs mig= ht be present then ACH TLV Header must be present. The Length of ACH TLV He= ader may set to zero in no ACH TLVs are actually present in the given packe= t. Said that I turn to figure 2 that presents LSP Ping packet with ACH form= at. The ACH TLV Header is not presented in the format even though presence = of ACH TLVs is indicated. I think that proper LSP Ping with ACH format will= look as: 0 1 2 = 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS Label stack = | | = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | LSP-Ping Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLVs = | | = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP-Ping payload = | | = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NB> You are right. I will fix that. * Section 2.3 discusses optional use of Source Address TLV but the sente= nce "Only 1 source address TLV MUST be present in a LSP-Ping packet." may b= e interpreted as the Source Address TLV is mandatory. I propose to change "= MUST" to "MAY" in the sentence NB> Sure...will rephrase to avoid confusion. * Figure 3 - same comments regarding ACH TLV Header in the format as for= Figure 2 NB> Will fix. Thanks for your useful comments Greg. Nitin From Jonas.Martensson@acreo.se Thu Feb 18 04:54:51 2010 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 D64313A7B3A for ; Thu, 18 Feb 2010 04:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 uV3E+-SSVK2w for ; Thu, 18 Feb 2010 04:54:51 -0800 (PST) Received: from mail33.messagelabs.com (mail33.messagelabs.com [195.245.230.51]) by core3.amsl.com (Postfix) with ESMTP id 85B9C3A7AE3 for ; Thu, 18 Feb 2010 04:54:50 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Jonas.Martensson@acreo.se X-Msg-Ref: server-2.tower-33.messagelabs.com!1266497790!33353357!1 X-StarScan-Version: 6.2.4; banners=acreo.se,-,- X-Originating-IP: [217.151.195.216] Received: (qmail 12168 invoked from network); 18 Feb 2010 12:56:31 -0000 Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by server-2.tower-33.messagelabs.com with RC4-SHA encrypted SMTP; 18 Feb 2010 12:56:31 -0000 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Thu, 18 Feb 2010 13:56:30 +0100 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Lou Berger , CCAMP WG Date: Thu, 18 Feb 2010 13:56:29 +0100 Thread-Topic: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents Thread-Index: AcqppDjXBATpVDiUSiObVf+ooPQYoAG9T+rA Message-ID: <1EC35EEAF3A9FA439C7D6AE45BF43787018A067DDF7D@acreoexc01.ad.acreo.se> References: <4B718C44.90001@labn.net> In-Reply-To: <4B718C44.90001@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 18 Feb 2010 12:54:51 -0000 Yes/support to both. Regards, Jonas > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: den 9 februari 2010 17:25 > To: CCAMP WG > Subject: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg > documents >=20 > All, >=20 > The authors of the drafts have stated that they are ready for this > poll to resume. Therefore: >=20 > This message starts a two week poll on making the documents listed > below > ccamp working group documents. Please send a mail to the mailing list > indicating "yes/support to both" or "no/do not support either". Of > course, you may also support one but not the other. (We will assume > that you support/object to both if you don't specify.) Please send > mail even if you expressed an opinion on the prior poll. >=20 > The documents being polled are: >=20 > http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext > http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam- > ext >=20 > The poll ends Tuesday February 23. >=20 > Much thanks, > Lou >=20 > -------- Original Message -------- > Subject: [CCAMP] Suspended: poll on making > draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document > Date: Tue, 01 Dec 2009 07:07:03 -0500 > From: Lou Berger > To: ccamp@ietf.org >=20 > 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. >=20 > 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. >=20 > Lou >=20 > 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 > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ From ylee@huawei.com Thu Feb 18 08:14:14 2010 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 3E59C3A7EC0 for ; Thu, 18 Feb 2010 08:14:14 -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 6SzJvXFSSegJ for ; Thu, 18 Feb 2010 08:14:11 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 260AF3A79A1 for ; Thu, 18 Feb 2010 08:14:11 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KY100574P0QN9@usaga02-in.huawei.com> for ccamp@ietf.org; Thu, 18 Feb 2010 08:12:27 -0800 (PST) Received: from L73682 ([10.124.12.56]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KY100HN1P0MFH@usaga02-in.huawei.com> for ccamp@ietf.org; Thu, 18 Feb 2010 08:12:26 -0800 (PST) Date: Thu, 18 Feb 2010 10:12:22 -0600 From: Young Lee In-reply-to: <4B718C44.90001@labn.net> To: 'Lou Berger' , 'CCAMP WG' Message-id: <000301cab0b5$275d5e40$380c7c0a@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: AcqppGGPvWLqZzjSQSWWRgrEgdkcxAHELnfA References: <4B718C44.90001@labn.net> Subject: Re: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 18 Feb 2010 16:14:14 -0000 Yes, support for both. Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Tuesday, February 09, 2010 10:25 AM To: CCAMP WG Subject: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents All, The authors of the drafts have stated that they are ready for this poll to resume. Therefore: This message starts a two week poll on making the documents listed below ccamp working group documents. Please send a mail to the mailing list indicating "yes/support to both" or "no/do not support either". Of course, you may also support one but not the other. (We will assume that you support/object to both if you don't specify.) Please send mail even if you expressed an opinion on the prior poll. The documents being polled are: http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext The poll ends Tuesday February 23. Much thanks, Lou -------- Original Message -------- Subject: [CCAMP] Suspended: poll on making draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document Date: Tue, 01 Dec 2009 07:07:03 -0500 From: Lou Berger To: ccamp@ietf.org 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 > > > _______________________________________________ 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 root@core3.amsl.com Thu Feb 18 10:15:03 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 42CC43A7FC0; Thu, 18 Feb 2010 10:15: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: <20100218181502.42CC43A7FC0@core3.amsl.com> Date: Thu, 18 Feb 2010 10:15:01 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-encode-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, 18 Feb 2010 18:15: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 : Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-rwa-wson-encode-04.txt Pages : 33 Date : 2010-02-18 A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are fairly specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON specific information elements. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rwa-wson-encode-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-18100457.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Feb 18 10:15:05 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id AFDBF3A7FEE; Thu, 18 Feb 2010 10:15: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: <20100218181503.AFDBF3A7FEE@core3.amsl.com> Date: Thu, 18 Feb 2010 10:15:02 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-info-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, 18 Feb 2010 18:15:05 -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 : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-rwa-info-07.txt Pages : 22 Date : 2010-02-18 This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-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-rwa-info-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-18100510.I-D@ietf.org> --NextPart-- From daniel@olddog.co.uk Thu Feb 18 14:12:49 2010 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 903343A7F2A for ; Thu, 18 Feb 2010 14:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=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 HccbbQy3EOYN for ; Thu, 18 Feb 2010 14:12:48 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id A024E3A787A for ; Thu, 18 Feb 2010 14:12:47 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o1IMEFn3030607; Thu, 18 Feb 2010 22:14:15 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id o1IMEEqi030602; Thu, 18 Feb 2010 22:14:14 GMT From: "Daniel King" To: Date: Thu, 18 Feb 2010 22:14:15 -0000 Message-ID: <003601cab0e7$b5474040$1fd5c0c0$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acqw57TEOgs0P+/hQGW/9xkKgEy11Q== Content-Language: en-gb Cc: "'Brungard, Deborah A, ALABS'" Subject: [CCAMP] Agenda Requests for IETF 77 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, 18 Feb 2010 22:12:49 -0000 Hello CCAMP'rs, Please let us know if you have an agenda request for our CCAMP sessions at IETF 77. Reply to this email (please also CC the co-chairs) with the desired duration, topic/draft title, and presenter for each slot that you request. Please let us have your requests by Friday, March 12th. Key dates are at: http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF77 2010-02-26 (Friday): Final agenda to be published. 2010-03-01 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PST (01:00 Tuesday, March 2 UTC), upload using IETF ID Submission Tool. 2010-03-08 (Monday): Internet Draft final submission cut-off by 17:00 PST (01:00 Tuesday, March 9 UTC), upload using IETF ID Submission Tool. The preliminary agenda is at: https://datatracker.ietf.org/meeting/agenda/ Thanks, Dan From Anders.Gavler@acreo.se Thu Feb 18 14:23:46 2010 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 5296C3A78B1 for ; Thu, 18 Feb 2010 14:23:46 -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 gTKnCpsjYQGT for ; Thu, 18 Feb 2010 14:23:45 -0800 (PST) Received: from mail36.messagelabs.com (mail36.messagelabs.com [85.158.136.83]) by core3.amsl.com (Postfix) with ESMTP id EB0673A7445 for ; Thu, 18 Feb 2010 14:23:44 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Anders.Gavler@acreo.se X-Msg-Ref: server-14.tower-36.messagelabs.com!1266531927!38600735!1 X-StarScan-Version: 6.2.4; banners=acreo.se,-,- X-Originating-IP: [217.151.195.216] Received: (qmail 19948 invoked from network); 18 Feb 2010 22:25:27 -0000 Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by server-14.tower-36.messagelabs.com with RC4-SHA encrypted SMTP; 18 Feb 2010 22:25:27 -0000 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Thu, 18 Feb 2010 23:25:27 +0100 From: Anders Gavler To: Lou Berger , CCAMP WG Date: Thu, 18 Feb 2010 23:25:25 +0100 Thread-Topic: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents Thread-Index: AcqppDjXBATpVDiUSiObVf+ooPQYoAG+iEgg Message-ID: <73B74934786FBB4F951B5F99724CEB60E5018B006A@acreoexc01.ad.acreo.se> References: <4B718C44.90001@labn.net> In-Reply-To: <4B718C44.90001@labn.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 18 Feb 2010 22:23:46 -0000 Yes/support to both. Cheers, Anders > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: den 9 februari 2010 17:25 > To: CCAMP WG > Subject: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg > documents >=20 > All, >=20 > The authors of the drafts have stated that they are ready for this > poll to resume. Therefore: >=20 > This message starts a two week poll on making the documents listed > below > ccamp working group documents. Please send a mail to the mailing list > indicating "yes/support to both" or "no/do not support either". Of > course, you may also support one but not the other. (We will assume > that you support/object to both if you don't specify.) Please send > mail even if you expressed an opinion on the prior poll. >=20 > The documents being polled are: >=20 > http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext > http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam- > ext >=20 > The poll ends Tuesday February 23. >=20 > Much thanks, > Lou >=20 > -------- Original Message -------- > Subject: [CCAMP] Suspended: poll on making > draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document > Date: Tue, 01 Dec 2009 07:07:03 -0500 > From: Lou Berger > To: ccamp@ietf.org >=20 > 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. >=20 > 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. >=20 > Lou >=20 > 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 > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ From root@core3.amsl.com Thu Feb 18 17:00:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1B6943A7BE0; Thu, 18 Feb 2010 17: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: <20100219010002.1B6943A7BE0@core3.amsl.com> Date: Thu, 18 Feb 2010 17:00:02 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-dcsc-channel-ext-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: Fri, 19 Feb 2010 01: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 : Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-dcsc-channel-ext-04.txt Pages : 11 Date : 2010-02-18 This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching. The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of an LSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-dcsc-channel-ext-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-dcsc-channel-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-18165110.I-D@ietf.org> --NextPart-- From Pontus.Skoldstrom@acreo.se Fri Feb 19 02:30:11 2010 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 E40F828C228 for ; Fri, 19 Feb 2010 02:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 F4VueeViqo8r for ; Fri, 19 Feb 2010 02:30:08 -0800 (PST) Received: from mail36.messagelabs.com (mail36.messagelabs.com [85.158.136.83]) by core3.amsl.com (Postfix) with ESMTP id 12D3828C23F for ; Fri, 19 Feb 2010 02:30:07 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: Pontus.Skoldstrom@acreo.se X-Msg-Ref: server-14.tower-36.messagelabs.com!1266575512!38684900!1 X-StarScan-Version: 6.2.4; banners=acreo.se,-,- X-Originating-IP: [217.151.195.216] Received: (qmail 3360 invoked from network); 19 Feb 2010 10:31:52 -0000 Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by server-14.tower-36.messagelabs.com with RC4-SHA encrypted SMTP; 19 Feb 2010 10:31:52 -0000 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Fri, 19 Feb 2010 11:31:52 +0100 From: =?iso-8859-1?Q?Pontus_Sk=F6ldstr=F6m?= To: "ccamp@ietf.org" Date: Fri, 19 Feb 2010 11:31:49 +0100 Thread-Topic: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents Thread-Index: AcqppDjXBATpVDiUSiObVf+ooPQYoAHqe3Ww Message-ID: In-Reply-To: <4B718C44.90001@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg documents 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, 19 Feb 2010 10:30:12 -0000 I support both draft-bellagamba- (as a co-author) and I also support draft= -kern-, so "yes/support to both" Regards,=20 Pontus Skoldstrom > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf O= f > Lou Berger > Sent: den 9 februari 2010 17:25 > To: CCAMP WG > Subject: [CCAMP] (Resuming) Poll on OAM related drafts to ccamp wg > documents >=20 > All, >=20 > The authors of the drafts have stated that they are ready for this > poll to resume. Therefore: >=20 > This message starts a two week poll on making the documents listed below= > ccamp working group documents. Please send a mail to the mailing list > indicating "yes/support to both" or "no/do not support either". Of > course, you may also support one but not the other. (We will assume > that you support/object to both if you don't specify.) Please send > mail even if you expressed an opinion on the prior poll. >=20 > The documents being polled are: >=20 > http://tools.ietf.org/html/draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext > http://tools.ietf.org/html/draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ex= t >=20 > The poll ends Tuesday February 23. >=20 > Much thanks, > Lou >=20 > -------- Original Message -------- > Subject: [CCAMP] Suspended: poll on making > draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01.txt ccamp wg document > Date: Tue, 01 Dec 2009 07:07:03 -0500 > From: Lou Berger > To: ccamp@ietf.org >=20 > 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. >=20 > 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. >=20 > Lou >=20 > 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 > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ From dieter.beller@alcatel-lucent.com Fri Feb 19 06:21:10 2010 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 5E8F23A7F6D; Fri, 19 Feb 2010 06:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 Ue0Fs8DcXHLq; Fri, 19 Feb 2010 06:21:09 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id C6D4F3A7DE7; Fri, 19 Feb 2010 06:21:08 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o1JEMrEq018443 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Feb 2010 15:22:53 +0100 Received: from [135.244.182.16] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 19 Feb 2010 15:22:52 +0100 Message-ID: <4B7E9EBB.5080102@alcatel-lucent.com> Date: Fri, 19 Feb 2010 15:22:51 +0100 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: "mpls-tp@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" , ITU-T ad hoc team on MPLS-TP Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: [CCAMP] Early version of revised ITU-T Recommendation G.7712 including MPLS-TP 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, 19 Feb 2010 14:21:11 -0000 Dear colleagues,

Please find below  an early version of revised ITU-T Recommendation G.7712
(in “word” and “pdf”), which updates SCN and MSN aspects based on recently
published IETF RFCs for MPLS-TP and describes the associated MPLS-TP atomic
functions.

http://ifa.itu.int/t/2009/sg15/ahmpls-tp/documents/wdxx_editor_G7712-revised_v0.2.pdf

http://ifa.itu.int/t/2009/sg15/ahmpls-tp/documents/wdxx_editor_G7712-revised_v0.2.doc

The alignment is not complete yet as indicated by several editor's notes,
but the intention is that the experts can start providing comments and
discussing specific MPLS-TP related topics on the mailing lists of the two
organizations before the revised MPLS-TP sections and new MPLS-TP
related amendments will be presented and discussed at the Stockholm
interim meeting in April dedicated to MPLS-TP.


In case you do not have permissions yet to access the documents, please
go to the following web site and follow the instructions in section 6:

http://www.itu.int/ITU-T/studygroups/com15/ahmpls-tp/


Regards,
Dieter
--
From wwwrun@core3.amsl.com Fri Feb 19 07:27:49 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8F4153A7EB6; Fri, 19 Feb 2010 07:27:49 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100219152749.8F4153A7EB6@core3.amsl.com> Date: Fri, 19 Feb 2010 07:27:49 -0800 (PST) Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Protocol Action: 'RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network.' to Proposed Standard 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, 19 Feb 2010 15:27:49 -0000 The IESG has approved the following document: - 'RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network. ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-spc-rsvpte-ext-07.txt Technical Summary This memo describes an extension to Generalized Multi-Protocol Label Switching signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover related procedures. This includes the handling of failure conditions and subsequent rversion to original state. A basic premise of the extension is that the handover procedures must never impact an already established data plane. Working Group Summary This document received adequate attention and discussion in its early revisions. The document has been laregly stable for quite some time, mainly needing revisions as part of the publication process. Document Quality There have been no public statements related to intent to implement, but it is expected that some/all of the primary Authors plan to implement. Personnel Lou Berger is the Document Shepherd for this document. Adrian Farrel is the Responsible Area Director. From wwwrun@core3.amsl.com Fri Feb 19 07:32:13 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 50F163A7CBC; Fri, 19 Feb 2010 07:32:13 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100219153213.50F163A7CBC@core3.amsl.com> Date: Fri, 19 Feb 2010 07:32:13 -0800 (PST) Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Protocol Action: 'Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions' to Proposed Standard 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, 19 Feb 2010 15:32:13 -0000 The IESG has approved the following document: - 'Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-dcsc-channel-ext-04.txt Technical Summary 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 Nothing to report. Document Quality There are no known implementations, but it is expected that several vendors plan to implement. Personnel Deborah Brungard (db3546@att.com) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD RFC Editor Note RFC Editor - we suggest that you treat this I-D as part of a cluster including the following five documents. draft-ietf-ccamp-ethernet-traffic-parameters draft-ietf-ccamp-gmpls-dcsc-channel-ext draft-ietf-ccamp-gmpls-ether-svcs draft-ietf-ccamp-gmpls-mef-uni draft-ietf-ccamp-gmpls-mln-extensions IANA Note IANA please note the requested update to IANAGmplsSwitchingTypeTC at http://www.iana.org/assignments/ianagmplstc-mib From sboutros@cisco.com Fri Feb 19 11:24:22 2010 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 C8FF53A7CCD; Fri, 19 Feb 2010 11:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 CmLwQK24rPSs; Fri, 19 Feb 2010 11:24:21 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C884F3A72CE; Fri, 19 Feb 2010 11:24:21 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4FAFt0fkurR7Hu/2dsb2JhbACGJ5Ric6U1l20ChGUEgxU X-IronPort-AV: E=Sophos;i="4.49,505,1262563200"; d="scan'208";a="300962444" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 19 Feb 2010 19:26:09 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o1JJQ9t4026134; Fri, 19 Feb 2010 19:26:09 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 11:26:09 -0800 Received: from sboutros-wxp02.ciswco.com ([10.21.95.24]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 11:26:08 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 19 Feb 2010 11:16:50 -0800 To: Loa Andersson , "mpls-tp@ietf.org" , mpls@ietf.org, CCAMP WG , pwe3@ietf.org From: Sami Boutros In-Reply-To: <4B7C43CF.3070700@pi.nu> References: <4B7C43CF.3070700@pi.nu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 19 Feb 2010 19:26:09.0075 (UTC) FILETIME=[637D5030:01CAB199] X-Mailman-Approved-At: Fri, 19 Feb 2010 12:31:37 -0800 Subject: Re: [CCAMP] [PWE3] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-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: Fri, 19 Feb 2010 19:24:23 -0000 yes/support. At 11:30 AM 2/17/2010, Loa Andersson wrote: >All, > > >this is to start a two week working group poll on making >draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt >an mpls working group document. > >Send your response to the mpls-tp@ietf.org mailing list >(only), indicating "yes/support" or "no/do not support". > >The poll ends eob March 5th 2001. > >/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 >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www.ietf.org/mailman/listinfo/pwe3 From pratiravi@gmail.com Fri Feb 19 14:09:19 2010 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 0C5A03A7B89; Fri, 19 Feb 2010 14:09:19 -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 2INItBwgAKzk; Fri, 19 Feb 2010 14:09:18 -0800 (PST) Received: from mail-qy0-f177.google.com (mail-qy0-f177.google.com [209.85.221.177]) by core3.amsl.com (Postfix) with ESMTP id 13C403A7B77; Fri, 19 Feb 2010 14:09:17 -0800 (PST) Received: by qyk8 with SMTP id 8so325340qyk.14 for ; Fri, 19 Feb 2010 14:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=rpZrpEauFP3UN8PbG7StXjDj+AJAZKzjElqTrQ9DDms=; b=gUDAD1Et/yZzdKbPkWbnb5cqtGYJ/aqmukL8J0IrUfWjG7JuwmdgZi7aYMpKeL5rYo JveUgdE8gXTIfWbDYfDdV9LQ9kAVFVKfFv64gcqjIEsRWl2MX49aUS3aQx9XuyBZIYH7 /WDM3OumFWLfqPMLqxvAdT10Aym5iodUOu5YY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=LX0ZnB95XDz3EzzrkXSyfT4P2+bOaCLB+YPT983E4wZW4wQdt9dlsyBa5YMSb6eySV s++hwjSBXWwOnoabzQ1UhRF6aF09AOA0QG62O1aPYAcTJUfeagfFvXkQCeuNtavTL1FQ KH4EK9Uu/r47nHrxvNNOLO8iNJ0jojB2waPRs= Received: by 10.224.95.202 with SMTP id e10mr3865909qan.171.1266617463001; Fri, 19 Feb 2010 14:11:03 -0800 (PST) Received: from ?192.168.1.106? (c-24-218-22-68.hsd1.nh.comcast.net [24.218.22.68]) by mx.google.com with ESMTPS id 5sm1806110qwg.8.2010.02.19.14.11.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Feb 2010 14:11:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Raveendra Torvi In-Reply-To: <4B7C43CF.3070700@pi.nu> Date: Fri, 19 Feb 2010 17:10:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2D49AC93-6FD6-4E7A-BCF5-6204C60A1166@gmail.com> References: <4B7C43CF.3070700@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Fri, 19 Feb 2010 19:11:13 -0800 Cc: mpls@ietf.org, CCAMP WG , pwe3@ietf.org Subject: Re: [CCAMP] [mpls-tp] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-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: Fri, 19 Feb 2010 22:09:19 -0000 Could we keep P2MP ping-bfd procedures outside the scope of this = document, until the mpls-tp-p2mp-framework and mp-bfd are well defined?=20= -Ravi. On Feb 17, 2010, at 2:30 PM, Loa Andersson wrote: > All, >=20 >=20 > this is to start a two week working group poll on making > draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt > an mpls working group document. >=20 > Send your response to the mpls-tp@ietf.org mailing list > (only), indicating "yes/support" or "no/do not support". >=20 > The poll ends eob March 5th 2001. >=20 > /Loa > --=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 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp From lufang@cisco.com Sun Feb 21 19:40:20 2010 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 2112828C20E; Sun, 21 Feb 2010 19:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 dU57PfzmJ4hs; Sun, 21 Feb 2010 19:40:19 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 99C1928C129; Sun, 21 Feb 2010 19:40:18 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABOMgUtAZnwM/2dsb2JhbACbBHOjcpc2AoRpBIMV X-IronPort-AV: E=Sophos;i="4.49,515,1262563200"; d="scan'208";a="87851430" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Feb 2010 03:42:15 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1M3gElQ024909; Mon, 22 Feb 2010 03:42:15 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Feb 2010 21:42:14 -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: Sun, 21 Feb 2010 21:42:13 -0600 Message-ID: <238542D917511A45B6B8AA806E875E259FBEAA@XMB-RCD-201.cisco.com> In-Reply-To: <4B7187EE.30404@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: AcqpodIlZoRhCNeZSgSodpS2IOgCRgJzpEXQ References: <4B7187EE.30404@pi.nu> From: "Luyuan Fang (lufang)" To: "Loa Andersson" , , , , , "Adrian Farrel" X-OriginalArrivalTime: 22 Feb 2010 03:42:14.0736 (UTC) FILETIME=[06083D00:01CAB371] Subject: Re: [CCAMP] [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Mon, 22 Feb 2010 03:40:20 -0000 yes/support. Thanks, Luyuan=20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: 09 February 2010 11:06 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; Adrian Farrel Subject: [mpls-tp] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document All, This is to start two week poll on making draft-fbb-mpls-tp-data-plane-00.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". Note that this ID is a starting point for what needs to be documented on the MPLS data plane for the MPLS-TP project. The ID is largely based on the data plane specific text from the framework, together with some notes concerning how the Transport Profile of MPLS might operate over Ethernet. /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 prabhu.ashwin@gmail.com Mon Feb 22 01:20:44 2010 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 C401528C0E6; Mon, 22 Feb 2010 01:20:44 -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 uRZYLEmMTiVV; Mon, 22 Feb 2010 01:20:44 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 6E9DA28C13D; Mon, 22 Feb 2010 01:20:43 -0800 (PST) Received: by vws20 with SMTP id 20so684206vws.31 for ; Mon, 22 Feb 2010 01:22:38 -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=pYfDIP8MdxXVmaJXr6CopepFyFUO26CcKKi3INKy3Fo=; b=vo8sUcltqBvF1sS79KK81UaWItM4RyMAXDJNL0GqrZtz1pDlj8G4B3S+qnzJQBMsJ/ VqKT9fEmGXgaRpHVnoBW3/W7vOrL30ANuZdmlclIAfEHKCpXFYpo7E08nK9nCubvA6JS p/ZNqu3yv0nJla0eHzC5r/SGMUjY/oQUXmxAE= 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=qKqvfAgxYgwpBubDayftIlm+y9yY3Xz425wUCfmuWWdHVTj0617w7GoNHoE8do3aR7 eTDJlGtufrA3AyT9sMHiA1sAoZEYzrIaGQ4M8N/exkJqB+Jq0yAfW2dvp02ABvstqyxV sisqYD0T5ZuSkGE9tcTRRvN3gbeSO9KCmUJvc= MIME-Version: 1.0 Received: by 10.220.124.24 with SMTP id s24mr7384643vcr.62.1266830557973; Mon, 22 Feb 2010 01:22:37 -0800 (PST) In-Reply-To: <4B7C43CF.3070700@pi.nu> References: <4B7C43CF.3070700@pi.nu> Date: Mon, 22 Feb 2010 14:52:37 +0530 Message-ID: <3c33c551002220122u6380c42ep54d26cef9ee5a6a6@mail.gmail.com> From: "Ashwin C. Prabhu" To: Loa Andersson Content-Type: multipart/alternative; boundary=001636ed62f0660bea04802cf98f X-Mailman-Approved-At: Mon, 22 Feb 2010 04:03:37 -0800 Cc: mpls@ietf.org, CCAMP WG , pwe3@ietf.org, "mpls-tp@ietf.org" Subject: Re: [CCAMP] [mpls] poll on draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-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: Mon, 22 Feb 2010 09:20:44 -0000 --001636ed62f0660bea04802cf98f Content-Type: text/plain; charset=ISO-8859-1 yes/support On Thu, Feb 18, 2010 at 1:00 AM, Loa Andersson wrote: > All, > > > this is to start a two week working group poll on making > draft-nitinb-mpls-tp-lsp-ping-bfd-procedures-02.txt > > an mpls working group document. > > Send your response to the mpls-tp@ietf.org mailing list > (only), indicating "yes/support" or "no/do not support". > > The poll ends eob March 5th 2001. > > > /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 mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --001636ed62f0660bea04802cf98f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
yes/support


=A0
On Thu, Feb 18, 2010 at 1:00 AM, Loa Andersson <= span dir=3D"ltr"><loa@pi.nu> = wrote:
All,


this is to start= a two week working group poll on making
draft-nitinb-mpls-tp-lsp-ping-b= fd-procedures-02.txt=20

an mpls working group document.

Send you= r response to the mpl= s-tp@ietf.org mailing list
(only), indicating "yes/support"= ; or "no/do not support".

The poll ends eob March 5th 2001.=20


/Loa
--


Loa Andersson =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@ericsson.com
Sr Strate= gy 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
__________________________= _____________________

--001636ed62f0660bea04802cf98f-- From root@core3.amsl.com Mon Feb 22 09:15:03 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DF4FB28C0F5; Mon, 22 Feb 2010 09:15: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: <20100222171502.DF4FB28C0F5@core3.amsl.com> Date: Mon, 22 Feb 2010 09:15:02 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D ACTION:draft-ietf-ccamp-gmpls-mln-extensions-12.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, 22 Feb 2010 17:15: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 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-12.txt Pages : 24 Date : 2010-2-22 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-12.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-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-2-22090728.I-D@ietf.org> --NextPart-- From gregb@grotto-networking.com Mon Feb 22 10:33:01 2010 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 616FC28C342 for ; Mon, 22 Feb 2010 10:33:01 -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 IlyLdx5am6w2 for ; Mon, 22 Feb 2010 10:33:00 -0800 (PST) Received: from mail32c40.carrierzone.com (mail32c40.carrierzone.com [209.235.156.172]) by core3.amsl.com (Postfix) with ESMTP id 7133D28C0DC for ; Mon, 22 Feb 2010 10:32:57 -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 o1MIYnnT002751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Feb 2010 13:34:54 -0500 Message-ID: <4B82CE48.5010100@grotto-networking.com> Date: Mon, 22 Feb 2010 10:34:48 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ccamp@ietf.org, attila.takacs@ericsson.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] Limitations in "OAM Configuration Framework"... 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, 22 Feb 2010 18:33:01 -0000 Hi Attilla, co-authors and CCAMPers, I like the "OAM Configuration Framework" draft and the corresponding RSVP SDH & OTN extensions, since some of these issues are very similar to those seen in Wavelength Switched Optical Networks (WSON). In WSON we have a need to specify a particular operation (say regeneration) take place at a particular intermediate node along a path. It seems that the current "OAM Configuration Framework" details don't include such a case. While we have in general: (a) Maintenance End Points (MEPs) (b) Maintenance Intermediate Points (MIP) There is a statement in section 4.1: "...the establishment of OAM MIP entities is required at every transit node of the signalled LSP...". This seemed to me to indicate the ability to configure processing at all intermediate nodes or none. Is this correct? It also seemed to me that this would preclude using this mechanism for configuring tandem connection monitoring (TCM) OAM. Note G.709 has particularly good TCM facilities. Was there another set of drafts in the works that would include TCM configuration? This would probably look more like some of the functionality that we need for WSONs. Regards Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From loa@pi.nu Mon Feb 22 11:25:56 2010 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 AD16A3A7D1B; Mon, 22 Feb 2010 11:25: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 jQynRSejkYCI; Mon, 22 Feb 2010 11:25:56 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id DFC183A832B; Mon, 22 Feb 2010 11:25:55 -0800 (PST) Received: from [109.58.58.181] (109.58.58.181.bredband.tre.se [109.58.58.181]) (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 85815D4052; Mon, 22 Feb 2010 20:27:51 +0100 (CET) Message-ID: <4B82DABF.1070504@pi.nu> Date: Mon, 22 Feb 2010 20:27:59 +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 WG , pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] clarification on poll to accept lsp-ping/bfd draft(s) as working group document(s) 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, 22 Feb 2010 19:25:56 -0000 Working Group(s) Two drafts are being progressed in the MPLS Working Group now: draft-nitinb-mpls-tp-lsp-ping-bfd-procedures and draft-asm-mpls-tp-bfd-cc-cv This note is intended to clarify the relationship between these drafts. Draft-nintinb addresses the problem of running BFD as it is currently defined for MPLS, this obviously has aspects that are relevant to packet transport networks. Draft-asm is intended to meet all the requirements in the MPLS-TP OAM Requirements. It turns out that the two drafts are closer than we earlier anticipated and there is a bit of overlap. This will not stop us from progressing both drafts, but it introduces a new need for coordination between the two author teams. /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 Black_David@emc.com Mon Feb 22 14:11:22 2010 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 2EA833A833E; Mon, 22 Feb 2010 14:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.304 X-Spam-Level: X-Spam-Status: No, score=-6.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 nxiUdZCR3B90; Mon, 22 Feb 2010 14:11:16 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id B02AA3A8307; Mon, 22 Feb 2010 14:11:16 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o1MMD5DQ024607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Feb 2010 17:13:05 -0500 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 22 Feb 2010 17:12:56 -0500 Received: from corpussmtp1.corp.emc.com (corpussmtp1.corp.emc.com [128.221.166.44]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o1MMCr1G000812; Mon, 22 Feb 2010 17:12:53 -0500 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.202]) by corpussmtp1.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Feb 2010 17:12:52 -0500 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: Mon, 22 Feb 2010 17:12:52 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-12 Thread-Index: AcqsUc4YQasrI29RQXOaeZNtDbMp8AHud4cw References: From: To: , , , , , X-OriginalArrivalTime: 22 Feb 2010 22:12:52.0871 (UTC) FILETIME=[2D74B170:01CAB40C] X-EMM-EM: Active Cc: ccamp@ietf.org, adrian.farrel@huawei.com, Black_David@emc.com Subject: [CCAMP] Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-12 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, 22 Feb 2010 22:11:22 -0000 The -12 version of this draft resolves all of the comments from the = Gen-ART review of the -11 version with one minor exception -- the word = "Call" needs to be inserted into the second line of section 5.1.5 as = indicated below: 5.1.5 Call Inheritance Flag =20 =20 This document introduces a specific Call Inheritance Flag at=20 position bit 0 (most significant bit) in the Attributes Flags ^ | Call ----------------------------------------------/ An RFC Editor Note would be a fine way of handling this change, but it = does need to be made. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, February 12, 2010 9:11 PM > To: dimitri.papadimitriou@alcatel-lucent.be; = martin.vigoureux@alcatel-lucent.fr; > shiomoto.kohei@lab.ntt.co.jp; dbrungard@att.com; = jean-louis.leroux@rd.francetelecom.com; 'gen- > art@ietf.org' > Cc: Black, David; Lou Berger; Adrian Farrel; ccamp@ietf.org > Subject: Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-11 >=20 > 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). >=20 > Please resolve these comments along with any other Last Call > comments you may receive. >=20 > Document: draft-ietf-ccamp-gmpls-mln-extensions-11 > Reviewer: David L. Black > Review Date: February 12, 2010 > IETF LC End Date: February 16, 2010 >=20 > Summary: > This draft is basically ready for publication, but has nits > that should be fixed before publication. >=20 > Comments: > This draft extends GMPLS routing and signaling to support the > operation of GMPLS Multi-Layer/Multi-Region Networks. One needs to be > a GMPLS expert to fully understand this draft - although, I'm not a > GMPLS expert, the draft reads reasonably well. All of these comments > are minor. >=20 > The IACD sub-TLV formats for OSPF and IS-IS appear to be identical. = If > they are in fact identical, a single ASCII text diagram should be used > for both. >=20 > The description of the IACD sub-TLV format does not describe the > Max LSP Bandwidth fields. At a minimum the units and/or encoding of > these fields should be described here, even thought the full > specification may be elsewhere. >=20 > Please add the values for Type and Length for the XRO SC subobject > into the ASCII figure in Section 4.1.1 . >=20 > Section 4.1.2 defines a new subobject by making minor changes to an > existing one in another RFC; a complete ASCII diagram of the new > subobject would be helpful - please add one. >=20 > Sections 5.1.4, 5.2.1 and 8 have me confused about the Attributes = Flags TLV: > - Section 5.1.4 defines an Attributes Flags TLV here > - Section 5.2.1 points to RFC 5420 for what's apparently a different > Attributes Flags TLV and defines a Pre-Planned LSP flag in > that TLV. > - Section 8 then apparently instructs IANA to put that bit into the > Attributes Flags TLV defined in Section 5.1.4 . > Something appears to be wrong with this combination - what was > the intent? If these two TLVs are the same, or share a common bit > assignment registry, that should be stated. >=20 > idnits 2.12.00 found three nits: >=20 > =3D=3D The page length should not exceed 58 lines per page, but = there was 1 > longer page, the longest (page 1) being 62 lines >=20 > ** There are 144 instances of too long lines in the document, the = longest > one being 1 character in excess of 72. >=20 > =3D=3D Line 781 has weird spacing: '...ndwidth is st...' >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) = 293-7786 > black_david@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 From pierre.peloso@alcatel-lucent.com Tue Feb 23 02:49:22 2010 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 5199928C0F6 for ; Tue, 23 Feb 2010 02:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_52=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 InbqE1gg07BP for ; Tue, 23 Feb 2010 02:49:21 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id D11E928C16D for ; Tue, 23 Feb 2010 02:49:20 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o1NAn9vK017971 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 23 Feb 2010 11:51:11 +0100 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 23 Feb 2010 11:50:09 +0100 From: "PELOSO, PIERRE (PIERRE)" To: "'Greg Bernstein'" , Young Lee Date: Tue, 23 Feb 2010 11:50:09 +0100 Thread-Topic: Disscussion and contribution in RWA drafts (encode and info) on the matter of wavelength converters and regenerators Thread-Index: Acq0dfeQrkRBbRNVTGah4uvu/qlB8g== Message-ID: Accept-Language: en-US Content-Language: fr-FR 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-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "ccamp@ietf.org" Subject: [CCAMP] Disscussion and contribution in RWA drafts (encode and info) on the matter of wavelength converters and regenerators 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, 23 Feb 2010 10:49:22 -0000 Hi Greg, Young and CCAMP'rs, =20 I have read carefully the recents updates on draft-ietf-ccamp-rwa-info and = draft-ietf-ccamp-rwa-wson-encode, particulary to all the ones related to th= e description of O-E-O ressources. Some of these updates seem to take converging directions (according to what= we discussed earlier this month), specifically: 1. Common way of handling: regeneration and wavelength conversion as in fin= e both these functions are achieved by the same type of equipments and henc= e their constraints are the same. 2. Better distinction is made between the accessibility of these resources = and their capabilities especially regarding the wavelength range. (Having a= wavelength available to reach an equipment is not equivalent to the fact t= hat this equipment is able to handle this wavelength - one of this piece of= information is dynamic the other one is static). This is specifically a cr= itical difference when multiple resources are gathered in a pool. There are also some areas where I view some enhancements as being beneficia= l: 1. The drafts propose different pieces of information to describe the node = internal switching structure (and constraints) and to describe the O-E-O re= sources inside the node. However, they do not describe how these pieces of = information fit together in order to build the global picture of the node i= nternal switching constraints. For example, considering the list of O-E-O = resources how you determine which of those are available from a given incom= ing link to a given outgoing link, what are the associated wavelength restr= ictions associated, etc... Even when examining the ospf derivations of these drafts, I still find diff= iculties in figuring how this would run. 2. Regarding the dynamic and static information that can be updated with di= fferent time-constraints (e.g. draft info p6), I notice that, for example i= n the node, the dynamic fields of info are inside the sub-TLV if not in sub= -sub-TLV. I do not know how IGPs are supposed to handle that. E.g. would OS= PF-TE allow the update of a LSA with a only a sub-set of its sub-TLVs, with= out discarding all the other sub-TLVs? To follow a contributive approach, I would propose a slightly different lay= out of information inside IGP that would address the two points above in a = simple fashion. 1. Have a "Node information" that holds only static information: It would d= etail the switching constraints (both spatial and spectral). This Node desc= ription would refer to "Link local/remote identifiers" to provide ports ref= erences compliants with "Link information" (e.g. link opaque LSA). The swit= ching matrix description would also list the O-E-O pools ports. 2. Have an "O-E-O pool information" which would need to be updated only whe= n an allocation/disallocation concerns a ressource in the pool. This "O-E-O= pool information" would then be a Top-level TLV, containing description of= the ressources of the pool, their availability, their accessibility (in te= rms of wavelength), and their ports identifiers. =20 I welcome further discussions on this proposal that you can find further de= tailed hereafter under the form of a piece of text that could be integrated= in an ospf-draft. Regards, Pierre ________________________________________ X. O-E-O Pool Information This draft defines a new top-TLV named "O-E-O pool Attribute" TLV. It carri= es attributes related to a pool of Optical-Electric-Optical regeneration re= source, thus allowing route computation to take into account available sign= al regenerators in the network. Multiple O-E-O ressources are logically gat= hered in a pool when they share a common transmission media before (and aft= er) entering (exiting) the actual switching matrix of the node. This Node A= ttribute TLV contains one or more sub-TLVs.=20 The O-E-O pool information related to pools in WSON nodes include Pool ID, = lists of available wavelength on the ingress and egress side of the pool, a= nd the features of the O-E-O in the pool on the ingress and egress side of = the pool. These pieces of information are defined in this document. The O-E= -O pool information would also include some sub-TLVs identical to sub-TLVs = of the TE-link top-TLV: TE-metric [rfc3630], Administrative Group [rfc3630]= , Link Local/Remote Identifiers [rfc4203], Shared-Risk Link Group [rfc4203]= . The following new sub-TLVs are added to the "O-E-O Pool Attribute" TLV. Det= ailed description for newly defined sub-TLVs is provided at the end of the = section. Sub-TLV Type Length Name TBD 4 Bytes Pool ID TBD variable Ingress Available Wavelength TBD variable Egress Available Wavelength TBD fixed Ingress O-E-O Features TBD fixed Egress O-E-O Features In "O-E-O Pool Attribute", the sub-TLVs "Ingress Available Wavelength" and = "Ingress O-E-O Features" are mandatory, the other sub-TLVs listed above are= optional. The omission of egress sub-TLV implies a symmetry status of egre= ss and ingress. The following sub-TLVs to the "O-E-O Pool Attribute" TLV are identical to t= he ones defined respectively in [RFC3630] and [RFC4203], and being defined = for the TE-link top-TLV. Detailed description for newly defined sub-TLV is = provided at the end of the section. Sub-TLV Type Length Name TBD 4 Bytes TE-metric [alike RFC3630] TBD 4 Bytes Administrative Group [alike RFC3630] TBD 8 Bytes Link Local/Remote Identifiers [alike RFC4203] TBD variable Shared Risk Link Group [alike RFC4203] In "O-E-O Pool", the sub-TLV "Link Local/Remote Identifiers" is mandatory a= s it is needed to ensure the consistency with the Node Information describe= d in Section 2. The other sub-TLVs listed above are optional.=20 X.1. Pool ID This optional sub-TLV can be used to provide an identifier to the regenerat= or pool. X.2. Ingress/Egress Available Wavelength These sub-TLVs provide the list of= available wavelength respectively to reach the pool from the Node and to r= each the Node from the pool (meaning first before and second after the sign= al crosses the O-E-O). These sub-TLVs share the same format as the Availabl= e Wavelength sub-TLVs depicted in [WSON-Encode]. The omission of the egress= sub-TLV is depicting a symmetrical usage of wavelength on each side of the= pool. X.3. Ingress/Egress O-E-O Features Both these sub-TLVs provide the features of a given O-E-O resource, respect= ively on its incoming and on its outgoing side. The encoding of this sub-TL= V is not provided yet, but is likely to resemble elements of [OSPF-signal-c= ompatibility] and of Wavelength Converter Range define in [WSON-encode] Ele= ments of the sub-TLVs: - Signal Type: Modulation Format, Bit-Rate, Modulation parameters, etc... - Wavelength constraints: (alike Wavelength Converter Range). A pair of these sub-TLVs is describing a given O-E-O piece of equipment. He= nce, there will be an instance of a pair of these sub-TLVs for each O-E-O r= esource present in the pool, which shall in fine construct a list of these = sub-TLVs to describe the list of O-E-O resource. The omission of the egress sub-TLV translates symmetry in the features of t= he O-E-O on its ingress and on its egress side. = From gregb@grotto-networking.com Tue Feb 23 08:17:03 2010 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 058CE28C1C6 for ; Tue, 23 Feb 2010 08:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=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 9B48XIcK0vvZ for ; Tue, 23 Feb 2010 08:17:01 -0800 (PST) Received: from mail30c40.carrierzone.com (mail30c40.carrierzone.com [209.235.156.170]) by core3.amsl.com (Postfix) with ESMTP id 6B42328C150 for ; Tue, 23 Feb 2010 08:17:01 -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 o1NGIn6A003372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 11:18:54 -0500 Message-ID: <4B83FFEF.3090106@grotto-networking.com> Date: Tue, 23 Feb 2010 08:18:55 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "PELOSO, PIERRE (PIERRE)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Disscussion and contribution in RWA drafts (encode and info) on the matter of Wavelength Converters and Regenerators 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, 23 Feb 2010 16:17:03 -0000 Hi Pierre and fellow CCAMPers, see response in line below. Greg PELOSO, PIERRE (PIERRE) wrote: > Hi Greg, Young and CCAMP'rs, > > I have read carefully the recents updates on draft-ietf-ccamp-rwa-info and draft-ietf-ccamp-rwa-wson-encode, particulary to all the ones related to the description of O-E-O ressources. > Some of these updates seem to take converging directions (according to what we discussed earlier this month), specifically: > 1. Common way of handling: regeneration and wavelength conversion as in fine both these functions are achieved by the same type of equipments and hence their constraints are the same. > --> Yes. This should be able to handle other processing resources such as those related to performance monitoring too. Hence we just call these resources rather than O-E-O resources, though the initial application are to OEO type resources. > 2. Better distinction is made between the accessibility of these resources and their capabilities especially regarding the wavelength range. (Having a wavelength available to reach an equipment is not equivalent to the fact that this equipment is able to handle this wavelength - one of this piece of information is dynamic the other one is static). This is specifically a critical difference when multiple resources are gathered in a pool. > > There are also some areas where I view some enhancements as being beneficial: > 1. The drafts propose different pieces of information to describe the node internal switching structure (and constraints) and to describe the O-E-O resources inside the node. However, they do not describe how these pieces of information fit together in order to build the global picture of the node internal switching constraints. For example, considering the list of O-E-O resources how you determine which of those are available from a given incoming link to a given outgoing link, what are the associated wavelength restrictions associated, etc... > --> Hmm, maybe this section needs more explanatory text. It looks like you gave the high level summary in your point "2" above. In more detail: we break the resource pool into the largest blocks possible (with identical ingress, egress and wavelength constraints), we specify the ingress connectivity constraints to the blocks and ingress wavelength constraints to each block. Similarly we specify the egress connectivity constraints from each block and any wavelength constraints associated with those. If needed a minimal amount of state information can be associated with each resource block (number of resources available in each block). We have a paper in progress that shows this technique used to model a fairly wide collection of different combined switch architectures gathered from the literature. We can make a preliminary draft available to those interested in the details. > Even when examining the ospf derivations of these drafts, I still find difficulties in figuring how this would run. > --> The OSPF versions are not quite up to date with the latest info and encoding drafts yet. > 2. Regarding the dynamic and static information that can be updated with different time-constraints (e.g. draft info p6), I notice that, for example in the node, the dynamic fields of info are inside the sub-TLV if not in sub-sub-TLV. I do not know how IGPs are supposed to handle that. E.g. would OSPF-TE allow the update of a LSA with a only a sub-set of its sub-TLVs, without discarding all the other sub-TLVs? > --> We don't specify TLV structure in the info draft, but identify relatively static versus dynamic information. Hence in section 5.1 where we give the resource pool model and it includes the "resource block state" information we are giving the complete information model rather than specifying which items should be TLVs, sub-TLVs, sub-sub-TLVs, etc... Later in the document (section 7) we explicitly point out the "dynamic" information. In the encoding drafts this is then used to guide the creation of separate TLVs/sub-TLVs. > To follow a contributive approach, I would propose a slightly different layout of information inside IGP that would address the two points above in a simple fashion. > 1. Have a "Node information" that holds only static information: It would detail the switching constraints (both spatial and spectral). This Node description would refer to "Link local/remote identifiers" to provide ports references compliants with "Link information" (e.g. link opaque LSA). The switching matrix description would also list the O-E-O pools ports. > --> The encoding draft takes this approach. The text may not be clear enough... > 2. Have an "O-E-O pool information" which would need to be updated only when an allocation/disallocation concerns a ressource in the pool. This "O-E-O pool information" would then be a Top-level TLV, containing description of the ressources of the pool, their availability, their accessibility (in terms of wavelength), and their ports identifiers. > --> This is what the "resource block state" information is for and it's broken out into a separate TLV in the encoding document. Note that exact usage would be specified in a protocol specific document, e.g., OSPF. > I welcome further discussions on this proposal that you can find further detailed hereafter under the form of a piece of text that could be integrated in an ospf-draft. > > Regards, > > Pierre > ________________________________________ > > X. O-E-O Pool Information > This draft defines a new top-TLV named "O-E-O pool Attribute" TLV. It carries attributes related to a pool of Optical-Electric-Optical regeneration resource, thus allowing route computation to take into account available signal regenerators in the network. Multiple O-E-O ressources are logically gathered in a pool when they share a common transmission media before (and after) entering (exiting) the actual switching matrix of the node. This Node Attribute TLV contains one or more sub-TLVs. > The O-E-O pool information related to pools in WSON nodes include Pool ID, lists of available wavelength on the ingress and egress side of the pool, and the features of the O-E-O in the pool on the ingress and egress side of the pool. These pieces of information are defined in this document. The O-E-O pool information would also include some sub-TLVs identical to sub-TLVs of the TE-link top-TLV: TE-metric [rfc3630], Administrative Group [rfc3630], Link Local/Remote Identifiers [rfc4203], Shared-Risk Link Group [rfc4203]. > The following new sub-TLVs are added to the "O-E-O Pool Attribute" TLV. Detailed description for newly defined sub-TLVs is provided at the end of the section. > Sub-TLV Type Length Name > TBD 4 Bytes Pool ID > TBD variable Ingress Available Wavelength > TBD variable Egress Available Wavelength > TBD fixed Ingress O-E-O Features > TBD fixed Egress O-E-O Features > In "O-E-O Pool Attribute", the sub-TLVs "Ingress Available Wavelength" and "Ingress O-E-O Features" are mandatory, the other sub-TLVs listed above are optional. The omission of egress sub-TLV implies a symmetry status of egress and ingress. > > The following sub-TLVs to the "O-E-O Pool Attribute" TLV are identical to the ones defined respectively in [RFC3630] and [RFC4203], and being defined for the TE-link top-TLV. Detailed description for newly defined sub-TLV is provided at the end of the section. > Sub-TLV Type Length Name > TBD 4 Bytes TE-metric [alike RFC3630] > TBD 4 Bytes Administrative Group [alike RFC3630] > TBD 8 Bytes Link Local/Remote Identifiers [alike RFC4203] > TBD variable Shared Risk Link Group [alike RFC4203] > In "O-E-O Pool", the sub-TLV "Link Local/Remote Identifiers" is mandatory as it is needed to ensure the consistency with the Node Information described in Section 2. The other sub-TLVs listed above are optional. > > X.1. Pool ID > This optional sub-TLV can be used to provide an identifier to the regenerator pool. > > X.2. Ingress/Egress Available Wavelength > These sub-TLVs provide the list of available wavelength respectively to reach the pool from the Node and to reach the Node from the pool (meaning first before and second after the signal crosses the O-E-O). These sub-TLVs share the same format as the Available Wavelength sub-TLVs depicted in [WSON-Encode]. The omission of the egress sub-TLV is depicting a symmetrical usage of wavelength on each side of the pool. > > X.3. Ingress/Egress O-E-O Features > Both these sub-TLVs provide the features of a given O-E-O resource, respectively on its incoming and on its outgoing side. The encoding of this sub-TLV is not provided yet, but is likely to resemble elements of [OSPF-signal-compatibility] and of Wavelength Converter Range define in [WSON-encode] > Elements of the sub-TLVs: > - Signal Type: Modulation Format, Bit-Rate, Modulation parameters, etc... > - Wavelength constraints: (alike Wavelength Converter Range). > A pair of these sub-TLVs is describing a given O-E-O piece of equipment. Hence, there will be an instance of a pair of these sub-TLVs for each O-E-O resource present in the pool, which shall in fine construct a list of these sub-TLVs to describe the list of O-E-O resource. > The omission of the egress sub-TLV translates symmetry in the features of the O-E-O on its ingress and on its egress side. > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From peng.he.2000@gmail.com Tue Feb 23 13:23:53 2010 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 7CBE528C1CA for ; Tue, 23 Feb 2010 13:23:53 -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 ezX1-RtZerlz for ; Tue, 23 Feb 2010 13:23:52 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 9139228C1A8 for ; Tue, 23 Feb 2010 13:23:52 -0800 (PST) Received: by gyg13 with SMTP id 13so514392gyg.31 for ; Tue, 23 Feb 2010 13:25:50 -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=ICMOhC+uj3OlfKxgNZlMZWefiEf8LxXZwJetWBpjcMs=; b=mEQCZ+9DWyW4Z6UPK7zxP1pI3AJxahN1fTt01sJr1VZeQVZSv4J/nTRhuF+xtoIPsI pHE4qEoIN+V3sYiCCl7wTIQZbt6dcH1K0LPpZrIzZc+GyDmx/zIV1i+ZURgXspFTsEvK EAWkflg//AlAknAfAcUIBfEuyYl2HsC323qeo= 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=KRqABpFKD40UXqhV+lZKC1nDk9DDBtCwdKjI1Eg9N4cPsaV42QAMsszRaau/GV7EFl NvYXYfQWbchk3lCKgMpcgSn1Yjly3fMYNzHsojL6B3n5sGTMF69KG3QKaNiWzK8Gv34w n2Y6iE4kYUsR/ueL8894aFu55P/e2QV1gxKmE= MIME-Version: 1.0 Received: by 10.101.36.14 with SMTP id o14mr6105321anj.28.1266960350085; Tue, 23 Feb 2010 13:25:50 -0800 (PST) In-Reply-To: <4B82CE48.5010100@grotto-networking.com> References: <4B82CE48.5010100@grotto-networking.com> Date: Tue, 23 Feb 2010 16:25:50 -0500 Message-ID: <406e32c01002231325u6882044cs5bec62f7ad6bb859@mail.gmail.com> From: Peng He To: Greg Bernstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ccamp@ietf.org Subject: Re: [CCAMP] Limitations in "OAM Configuration Framework"... 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, 23 Feb 2010 21:23:53 -0000 continued with Greg's comments, so according to this Section 4.1 "...the establishment of OAM MIP entities is required at every transit node of the signalled LSP...", there is no flexible choice to select several (not all) transit node(s) to configure MIP(s)? that is, either no MIP, or MIPs on all nodes? Regards, Peng On Mon, Feb 22, 2010 at 1:34 PM, Greg Bernstein wrote: > Hi Attilla, co-authors and CCAMPers, I like the "OAM Configuration > Framework" draft and the corresponding RSVP SDH & OTN extensions, since s= ome > of these issues are very similar to those seen in Wavelength Switched > Optical Networks (WSON). > > In WSON we have a need to specify a particular operation (say regeneratio= n) > take place at a particular intermediate node along a path. > It seems that the current "OAM Configuration Framework" details don't > =A0include such a case. While we have in general: > (a) Maintenance End Points (MEPs) > (b) Maintenance Intermediate Points (MIP) > There is a statement in section 4.1: "...the establishment of OAM MIP > entities is required at every transit node of the signalled LSP...". =A0T= his > seemed to me to indicate the ability to configure processing at all > intermediate nodes or none. Is this correct? > > It also seemed to me that this would preclude using this mechanism for > configuring tandem connection monitoring (TCM) OAM. Note G.709 has > particularly good TCM facilities. Was there another set of drafts in the > works that would include TCM configuration? > This would probably look more like some of the functionality that we need > for WSONs. > > Regards > > Greg B. > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=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 Attila.Takacs@ericsson.com Tue Feb 23 22:57:57 2010 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 9DA0D3A844E for ; Tue, 23 Feb 2010 22:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=-1.825, 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 puXRe0pYpPC9 for ; Tue, 23 Feb 2010 22:57:56 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 7CFAB3A844B for ; Tue, 23 Feb 2010 22:57:56 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-37-4b84ce708e9a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F8.92.01038.07EC48B4; Wed, 24 Feb 2010 08:00:00 +0100 (CET) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.2.93]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 24 Feb 2010 08:00:00 +0100 From: Attila Takacs To: Greg Bernstein , "ccamp@ietf.org" Date: Wed, 24 Feb 2010 07:59:59 +0100 Thread-Topic: Limitations in "OAM Configuration Framework"... Thread-Index: Acqz7dVohcjC2zCtRhaWuITMMJCR4ABL4juw Message-ID: <79F41BA1E9BF3C489375521EF8DDE23C1211B51971@ESESSCMS0355.eemea.ericsson.se> References: <4B82CE48.5010100@grotto-networking.com> In-Reply-To: <4B82CE48.5010100@grotto-networking.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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] Limitations in "OAM Configuration Framework"... 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, 24 Feb 2010 06:57:57 -0000 Hi Greg, Based on the discussions at the last IETF on the scalability of configuring= functions on intermediate nodes selectively, we thought that it would be p= ractical to break out the discussion on segment OAM/TCM configuration to a = new document. It is in the works now, and we plan to publish the initial ve= rsion by the deadline.=20 Last time we scratched the HOP_ATTRIBUTES option, in this new draft we want= to review other alternatives for configuring intermediate nodes that poppe= d up in the discussions in Hiroshima and on the list. Based on that summary= /comparison we may move on and nail down a solution. There seems to be a more general interest to configure intermediate nodes, = besides TCM/segment OAM, we have WSON and I also heard about some local rec= overy related ideas. If this is the case we should look for a solution that= fits best the different use-cases. Best regards, Attila =20 =20 > -----Original Message----- > From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 > Sent: Monday, February 22, 2010 7:35 PM > To: ccamp@ietf.org; Attila Takacs > Subject: Limitations in "OAM Configuration Framework"... >=20 > Hi Attilla, co-authors and CCAMPers, I like the "OAM=20 > Configuration Framework" draft and the corresponding RSVP SDH=20 > & OTN extensions, since some of these issues are very similar=20 > to those seen in Wavelength Switched Optical Networks (WSON). >=20 > In WSON we have a need to specify a particular operation (say > regeneration) take place at a particular intermediate node=20 > along a path. > It seems that the current "OAM Configuration Framework"=20 > details don't include such a case. While we have in general: > (a) Maintenance End Points (MEPs) > (b) Maintenance Intermediate Points (MIP) There is a=20 > statement in section 4.1: "...the establishment of OAM MIP=20 > entities is required at every transit node of the signalled LSP...". =20 > This seemed to me to indicate the ability to configure=20 > processing at all intermediate nodes or none. Is this correct? >=20 > It also seemed to me that this would preclude using this=20 > mechanism for configuring tandem connection monitoring (TCM)=20 > OAM. Note G.709 has particularly good TCM facilities. Was=20 > there another set of drafts in the works that would include=20 > TCM configuration? > This would probably look more like some of the functionality=20 > that we need for WSONs. >=20 > Regards >=20 > Greg B. >=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 > = From Attila.Takacs@ericsson.com Tue Feb 23 22:59:47 2010 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 2C5F828C1D2 for ; Tue, 23 Feb 2010 22:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=-0.913, 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 YJDmlAKHPU2f for ; Tue, 23 Feb 2010 22:59:46 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id F0F4028C196 for ; Tue, 23 Feb 2010 22:59:45 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-a1-4b84cede087d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 4E.AE.31641.EDEC48B4; Wed, 24 Feb 2010 08:01:50 +0100 (CET) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.2.93]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 24 Feb 2010 08:01:49 +0100 From: Attila Takacs To: Peng He , Greg Bernstein Date: Wed, 24 Feb 2010 08:01:48 +0100 Thread-Topic: [CCAMP] Limitations in "OAM Configuration Framework"... Thread-Index: Acq0zsYlUrkBzDf/SFO4kdwQ2pzNpAAUDrrA Message-ID: <79F41BA1E9BF3C489375521EF8DDE23C1211B51973@ESESSCMS0355.eemea.ericsson.se> References: <4B82CE48.5010100@grotto-networking.com> <406e32c01002231325u6882044cs5bec62f7ad6bb859@mail.gmail.com> In-Reply-To: <406e32c01002231325u6882044cs5bec62f7ad6bb859@mail.gmail.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Limitations in "OAM Configuration Framework"... 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, 24 Feb 2010 06:59:47 -0000 Hi Peng, Your observation is correct with regards to the OAM framework.=20 For selective configuration of MIPs please see my mail to Greg. Thanks, Attila=20 > -----Original Message----- > From: Peng He [mailto:peng.he.2000@gmail.com]=20 > Sent: Tuesday, February 23, 2010 10:26 PM > To: Greg Bernstein > Cc: ccamp@ietf.org; Attila Takacs > Subject: Re: [CCAMP] Limitations in "OAM Configuration Framework"... >=20 > continued with Greg's comments, so according to this Section=20 > 4.1 "...the establishment of OAM MIP entities is required at=20 > every transit node of the signalled LSP...", there is no=20 > flexible choice to select several (not all) transit node(s)=20 > to configure MIP(s)? that is, either no MIP, or MIPs on all nodes? >=20 > Regards, > Peng >=20 >=20 >=20 > On Mon, Feb 22, 2010 at 1:34 PM, Greg Bernstein=20 > wrote: > > Hi Attilla, co-authors and CCAMPers, I like the "OAM Configuration=20 > > Framework" draft and the corresponding RSVP SDH & OTN extensions,=20 > > since some of these issues are very similar to those seen in=20 > > Wavelength Switched Optical Networks (WSON). > > > > In WSON we have a need to specify a particular operation (say=20 > > regeneration) take place at a particular intermediate node=20 > along a path. > > It seems that the current "OAM Configuration Framework"=20 > details don't > > =A0include such a case. While we have in general: > > (a) Maintenance End Points (MEPs) > > (b) Maintenance Intermediate Points (MIP) There is a statement in=20 > > section 4.1: "...the establishment of OAM MIP entities is=20 > required at=20 > > every transit node of the signalled LSP...". =A0This seemed to me to=20 > > indicate the ability to configure processing at all=20 > intermediate nodes=20 > > or none. Is this correct? > > > > It also seemed to me that this would preclude using this=20 > mechanism for=20 > > configuring tandem connection monitoring (TCM) OAM. Note G.709 has=20 > > particularly good TCM facilities. Was there another set of=20 > drafts in=20 > > the works that would include TCM configuration? > > This would probably look more like some of the=20 > functionality that we=20 > > need for WSONs. > > > > Regards > > > > Greg B. > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=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 loa@pi.nu Wed Feb 24 02:51:25 2010 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 99C443A843C; Wed, 24 Feb 2010 02:51: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 JdnkbBmOA1bU; Wed, 24 Feb 2010 02:51:24 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id B1E573A8430; Wed, 24 Feb 2010 02:51:24 -0800 (PST) Received: from pi.nu (localhost [127.0.0.1]) by mail.pi.nu (Postfix) with ESMTP id 76BA8D4052; Wed, 24 Feb 2010 11:53:27 +0100 (CET) Received: from 194.237.142.17 (SquirrelMail authenticated user loa@pi.nu) by pi.nu with HTTP; Wed, 24 Feb 2010 11:53:28 +0100 Message-ID: In-Reply-To: <4B7187EE.30404@pi.nu> References: <4B7187EE.30404@pi.nu> Date: Wed, 24 Feb 2010 11:53:28 +0100 From: "Loa Andersson" To: "Loa Andersson" User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Wed, 24 Feb 2010 10:51:25 -0000 All, this poll has ended. We have accepted draft-fbb-mpls-tp-data-plane as an MPLS wroking group document. Could the authors please re-publish the document (without any othr changes than name and date) as draft-ietf-mpls-tp-data-plane-00.txt. And in the -01 version address both the comments that we recieved before the poll started and the commetns we received as response to the poll. /Loa > All, > > This is to start two week poll on making > draft-fbb-mpls-tp-data-plane-00.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". > > Note that this ID is a starting point for what needs to > be documented on the MPLS data plane for the MPLS-TP > project. The ID is largely based on the data plane specific > text from the framework, together with some notes concerning > how the Transport Profile of MPLS might operate over Ethernet. > > > /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 mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 10 717 52 13 +46 767 72 92 13 email: loa.andersson@ericsson.com loa@pi.nu From Alexander.Vainshtein@ecitele.com Wed Feb 24 03:46:49 2010 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 4477D28C11F; Wed, 24 Feb 2010 03:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 yBayMp4b6S3K; Wed, 24 Feb 2010 03:46:48 -0800 (PST) Received: from ilptbmg01.ecitele.com (ilptbmg01-out.ecitele.com [147.234.242.234]) by core3.amsl.com (Postfix) with ESMTP id 2E7483A8489; Wed, 24 Feb 2010 03:46:44 -0800 (PST) X-AuditID: 93eaf2e7-b7bafae000003e7b-bc-4b851071b074 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01.ecitele.com (Symantec Brightmail Gateway) with SMTP id 09.5D.15995.170158B4; Wed, 24 Feb 2010 13:41:37 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Wed, 24 Feb 2010 13:48:45 +0200 From: Alexander Vainshtein To: Loa Andersson Date: Wed, 24 Feb 2010 13:48:42 +0200 Thread-Topic: [PWE3] [mpls] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls working group document Thread-Index: Acq1P6J8iltoMu6oRcekljq8bYpafwABhqTg Message-ID: References: <4B7187EE.30404@pi.nu> In-Reply-To: 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: "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [CCAMP] [PWE3] [mpls] poll on making draft-fbb-mpls-tp-data-plane-00.txt a mpls 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: Wed, 24 Feb 2010 11:46:49 -0000 Loa, One of my early comments on the data plane draft proposed moving all data p= lane-related issues=20 from the MPLS-TP Framework draft to this one. To the best of my recollectio= n, several people =20 have supported this proposal during the poll. When you ask the authors to address "both the comments that we received bef= ore the poll started and the comments we received as response to the poll" = in the -01 version, do you include this comment as well? I am asking because the LC on draft-ietf-mpls-tp-framework-10 was expected = to end on February 19. Regards, Sasha -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Wednesday, February 24, 2010 12:53 PM To: Loa Andersson Cc: mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org; mpls-tp@ietf.org Subject: Re: [PWE3] [mpls] poll on making draft-fbb-mpls-tp-data-plane-00.t= xt a mpls working group document All, this poll has ended. We have accepted draft-fbb-mpls-tp-data-plane as an MPLS wroking group document. Could the authors please re-publish the document (without any othr changes than name and date) as draft-ietf-mpls-tp-data-plane-00.txt. And in the -01 version address both the comments that we recieved before the poll started and the commetns we received as response to the poll. /Loa > All, > > This is to start two week poll on making > draft-fbb-mpls-tp-data-plane-00.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". > > Note that this ID is a starting point for what needs to > be documented on the MPLS data plane for the MPLS-TP > project. The ID is largely based on the data plane specific > text from the framework, together with some notes concerning > how the Transport Profile of MPLS might operate over Ethernet. > > > /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 mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > Loa Andersson Sr Strategy and Standards Manager Ericsson /// phone: +46 10 717 52 13 +46 767 72 92 13 email: loa.andersson@ericsson.com loa@pi.nu _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From gregb@grotto-networking.com Wed Feb 24 07:41:28 2010 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 2774528C1B9 for ; Wed, 24 Feb 2010 07:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, 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 JBN3RsKKS5Dl for ; Wed, 24 Feb 2010 07:41:27 -0800 (PST) Received: from mail30c40.carrierzone.com (mail30c40.carrierzone.com [209.235.156.170]) by core3.amsl.com (Postfix) with ESMTP id E12F128C12E for ; Wed, 24 Feb 2010 07:41:26 -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 o1OFhMXT000397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Feb 2010 10:43:26 -0500 Message-ID: <4B854920.3050108@grotto-networking.com> Date: Wed, 24 Feb 2010 07:43:28 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Attila Takacs References: <4B82CE48.5010100@grotto-networking.com> <79F41BA1E9BF3C489375521EF8DDE23C1211B51971@ESESSCMS0355.eemea.ericsson.se> In-Reply-To: <79F41BA1E9BF3C489375521EF8DDE23C1211B51971@ESESSCMS0355.eemea.ericsson.se> Content-Type: multipart/alternative; boundary="------------000905050005060202070707" Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Limitations in "OAM Configuration Framework"... 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, 24 Feb 2010 15:41:28 -0000 This is a multi-part message in MIME format. --------------000905050005060202070707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for the update Attila, our WSON signaling draft has a requirement for some type of mechanism for selectively configuring intermediate nodes along a path but we are not committed to any one solution at this point. It would be great if your new draft summarizes the options and makes a recommendation. Let me know if you need any assistance. Cheers Greg Attila Takacs wrote: > Hi Greg, > > Based on the discussions at the last IETF on the scalability of configuring functions on intermediate nodes selectively, we thought that it would be practical to break out the discussion on segment OAM/TCM configuration to a new document. It is in the works now, and we plan to publish the initial version by the deadline. > > Last time we scratched the HOP_ATTRIBUTES option, in this new draft we want to review other alternatives for configuring intermediate nodes that popped up in the discussions in Hiroshima and on the list. Based on that summary/comparison we may move on and nail down a solution. > > There seems to be a more general interest to configure intermediate nodes, besides TCM/segment OAM, we have WSON and I also heard about some local recovery related ideas. If this is the case we should look for a solution that fits best the different use-cases. > > Best regards, > Attila > > > > > > >> -----Original Message----- >> From: Greg Bernstein [mailto:gregb@grotto-networking.com] >> Sent: Monday, February 22, 2010 7:35 PM >> To: ccamp@ietf.org; Attila Takacs >> Subject: Limitations in "OAM Configuration Framework"... >> >> Hi Attilla, co-authors and CCAMPers, I like the "OAM >> Configuration Framework" draft and the corresponding RSVP SDH >> & OTN extensions, since some of these issues are very similar >> to those seen in Wavelength Switched Optical Networks (WSON). >> >> In WSON we have a need to specify a particular operation (say >> regeneration) take place at a particular intermediate node >> along a path. >> It seems that the current "OAM Configuration Framework" >> details don't include such a case. While we have in general: >> (a) Maintenance End Points (MEPs) >> (b) Maintenance Intermediate Points (MIP) There is a >> statement in section 4.1: "...the establishment of OAM MIP >> entities is required at every transit node of the signalled LSP...". >> This seemed to me to indicate the ability to configure >> processing at all intermediate nodes or none. Is this correct? >> >> It also seemed to me that this would preclude using this >> mechanism for configuring tandem connection monitoring (TCM) >> OAM. Note G.709 has particularly good TCM facilities. Was >> there another set of drafts in the works that would include >> TCM configuration? >> This would probably look more like some of the functionality >> that we need for WSONs. >> >> Regards >> >> Greg B. >> >> -- >> =================================================== >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> >> >> >> > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------000905050005060202070707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for the update Attila, our WSON signaling draft has a requirement for some type of mechanism for selectively configuring  intermediate nodes along a path but we are not committed to any one solution at this point. It would be great if your new draft summarizes the options and makes a recommendation.
Let me know if you need any assistance.

Cheers

Greg

Attila Takacs wrote: 
Hi Greg,

Based on the discussions at the last IETF on the scalability of configuring functions on intermediate nodes selectively, we thought that it would be practical to break out the discussion on segment OAM/TCM configuration to a new document. It is in the works now, and we plan to publish the initial version by the deadline. 

Last time we scratched the HOP_ATTRIBUTES option, in this new draft we want to review other alternatives for configuring intermediate nodes that popped up in the discussions in Hiroshima and on the list. Based on that summary/comparison we may move on and nail down a solution.

There seems to be a more general interest to configure intermediate nodes, besides TCM/segment OAM, we have WSON and I also heard about some local recovery related ideas. If this is the case we should look for a solution that fits best the different use-cases.

Best regards,
Attila

 

 

  
-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com] 
Sent: Monday, February 22, 2010 7:35 PM
To: ccamp@ietf.org; Attila Takacs
Subject: Limitations in "OAM Configuration Framework"...

Hi Attilla, co-authors and CCAMPers, I like the "OAM 
Configuration Framework" draft and the corresponding RSVP SDH 
& OTN extensions, since some of these issues are very similar 
to those seen in Wavelength Switched Optical Networks (WSON).

In WSON we have a need to specify a particular operation (say
regeneration) take place at a particular intermediate node 
along a path.
It seems that the current "OAM Configuration Framework" 
details don't include such a case. While we have in general:
(a) Maintenance End Points (MEPs)
(b) Maintenance Intermediate Points (MIP) There is a 
statement in section 4.1: "...the establishment of OAM MIP 
entities is required at every transit node of the signalled LSP...".  
This seemed to me to indicate the ability to configure 
processing at all intermediate nodes or none. Is this correct?

It also seemed to me that this would preclude using this 
mechanism for configuring tandem connection monitoring (TCM) 
OAM. Note G.709 has particularly good TCM facilities. Was 
there another set of drafts in the works that would include 
TCM configuration?
This would probably look more like some of the functionality 
that we need for WSONs.

Regards

Greg B.

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



    


  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------000905050005060202070707-- From Adrian.Farrel@huawei.com Wed Feb 24 10:12:13 2010 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 E41B928C268; Wed, 24 Feb 2010 10:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSQYGt2AHAKW; Wed, 24 Feb 2010 10:12:11 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id B7D6728C1ED; Wed, 24 Feb 2010 10:12:10 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYC00E0VYNUM8@usaga03-in.huawei.com>; Wed, 24 Feb 2010 12:14:18 -0600 (CST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYC00253YNPA0@usaga03-in.huawei.com>; Wed, 24 Feb 2010 12:14:18 -0600 (CST) Date: Wed, 24 Feb 2010 18:12:08 +0000 From: Adrian Farrel To: Black_David@emc.com, dimitri.papadimitriou@alcatel-lucent.be, martin.vigoureux@alcatel-lucent.fr, shiomoto.kohei@lab.ntt.co.jp, dbrungard@att.com, jean-louis.leroux@rd.francetelecom.com, gen-art@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Cc: ccamp@ietf.org, Black_David@emc.com Subject: Re: [CCAMP] Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-12 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 18:12:13 -0000 Thanks for your thoroughness, David. RFC Editor note has been created. Cheers, Adrian ----- Original Message ----- From: To: ; ; ; ; ; Cc: ; ; ; Sent: Monday, February 22, 2010 10:12 PM Subject: Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-12 The -12 version of this draft resolves all of the comments from the Gen-ART review of the -11 version with one minor exception -- the word "Call" needs to be inserted into the second line of section 5.1.5 as indicated below: 5.1.5 Call Inheritance Flag This document introduces a specific Call Inheritance Flag at position bit 0 (most significant bit) in the Attributes Flags ^ | Call ----------------------------------------------/ An RFC Editor Note would be a fine way of handling this change, but it does need to be made. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, February 12, 2010 9:11 PM > To: dimitri.papadimitriou@alcatel-lucent.be; > martin.vigoureux@alcatel-lucent.fr; > shiomoto.kohei@lab.ntt.co.jp; dbrungard@att.com; > jean-louis.leroux@rd.francetelecom.com; 'gen- > art@ietf.org' > Cc: Black, David; Lou Berger; Adrian Farrel; ccamp@ietf.org > Subject: Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-11 > > 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-gmpls-mln-extensions-11 > Reviewer: David L. Black > Review Date: February 12, 2010 > IETF LC End Date: February 16, 2010 > > Summary: > This draft is basically ready for publication, but has nits > that should be fixed before publication. > > Comments: > This draft extends GMPLS routing and signaling to support the > operation of GMPLS Multi-Layer/Multi-Region Networks. One needs to be > a GMPLS expert to fully understand this draft - although, I'm not a > GMPLS expert, the draft reads reasonably well. All of these comments > are minor. > > The IACD sub-TLV formats for OSPF and IS-IS appear to be identical. If > they are in fact identical, a single ASCII text diagram should be used > for both. > > The description of the IACD sub-TLV format does not describe the > Max LSP Bandwidth fields. At a minimum the units and/or encoding of > these fields should be described here, even thought the full > specification may be elsewhere. > > Please add the values for Type and Length for the XRO SC subobject > into the ASCII figure in Section 4.1.1 . > > Section 4.1.2 defines a new subobject by making minor changes to an > existing one in another RFC; a complete ASCII diagram of the new > subobject would be helpful - please add one. > > Sections 5.1.4, 5.2.1 and 8 have me confused about the Attributes Flags > TLV: > - Section 5.1.4 defines an Attributes Flags TLV here > - Section 5.2.1 points to RFC 5420 for what's apparently a different > Attributes Flags TLV and defines a Pre-Planned LSP flag in > that TLV. > - Section 8 then apparently instructs IANA to put that bit into the > Attributes Flags TLV defined in Section 5.1.4 . > Something appears to be wrong with this combination - what was > the intent? If these two TLVs are the same, or share a common bit > assignment registry, that should be stated. > > idnits 2.12.00 found three nits: > > == The page length should not exceed 58 lines per page, but there was 1 > longer page, the longest (page 1) being 62 lines > > ** There are 144 instances of too long lines in the document, the > longest > one being 1 character in excess of 72. > > == Line 781 has weird spacing: '...ndwidth is st...' > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > From giomarti@cisco.com Fri Feb 26 06:40:19 2010 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 81A1B28C1D5 for ; Fri, 26 Feb 2010 06:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 M6B8uAEPjH3J for ; Fri, 26 Feb 2010 06:40:18 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 32C3F28C119 for ; Fri, 26 Feb 2010 06:40:18 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhABAP5sh0uQ/uCWe2dsb2JhbACbEBUBARYkBhYGowyYOoR5BA X-IronPort-AV: E=Sophos;i="4.49,546,1262563200"; d="scan'208,217";a="57540733" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Feb 2010 14:42:31 +0000 Received: from [144.254.166.116] (mnza1-dhcp-vl301-144-254-166-116.cisco.com [144.254.166.116]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1QEgVPD026346 for ; Fri, 26 Feb 2010 14:42:31 GMT Message-ID: <4B87DE23.8080004@cisco.com> Date: Fri, 26 Feb 2010 15:43:47 +0100 From: Giovanni Martinelli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100201 Lightning/1.0b2pre Thunderbird/3.0.1 MIME-Version: 1.0 To: "ccamp@ietf.org" Content-Type: multipart/alternative; boundary="------------050902000304090400020105" Subject: [CCAMP] Comments on draft-ietf-ccamp-rwa-wson-framework-05 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, 26 Feb 2010 14:40:19 -0000 This is a multi-part message in MIME format. --------------050902000304090400020105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Greg/Young/Authors, regarding the rwa framework I appreciate last updates, they goes in the right direction. I still have few comment on the draft: 1) Sec. 3.5.1 Regenerators According to ITU inputs (Q6 mtg last october) the regeneration classification was: 1R: amplifier 2R: does not exist 3R: the regenerator (indeed). I can understand the framework list all the three types (for sake of completess) but at the end we can consider only 3R as regeneration. This should also simplify the related encoding: we need only to know if regen is available and not the specific type (1, 2 or 3). 2) Sec. 4.1.1 PCE is one of the architectural options but reading the first bullet looks like there is a need of a *stateful* PCE to support RWA. If that the case probably worth a reference to RFC4655 section 6.8. 3) Sec. 4.1.3 The statement "this approach may generate higher blocking probability.." is there any reference that demonstrate this? 4) Section 4.3 Is not really clear to me the scope of this section, why do we need to state anything about temporal characteristics? Another comment that I did some time ago was about defining dynamic/pseudo-static/static with no reference: the draft just mention short or moderately-long and long duration. 5) Sec. 5.5.4 I understand you need to clarify some typical optical terminology like: transparent / translucent etc. but how about having all terminology grouped in section 3? And basically this WSON framework support either transparent (in different flavors) and translucent. Cheers G --------------050902000304090400020105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Greg/Young/Authors,

regarding the rwa framework I appreciate last updates, they goes in the right direction. I still have few comment on the draft:


1) Sec. 3.5.1 Regenerators
According to ITU inputs (Q6 mtg last october) the regeneration classification was:
1R: amplifier
2R: does not exist
3R: the regenerator (indeed).

I can understand the framework list all the three types (for sake of completess) but at the end we can consider only 3R as regeneration. This should also simplify the related encoding: we need only to know if regen is available and not the specific type (1, 2 or 3).

2) Sec. 4.1.1
PCE is one of the architectural options but reading the first bullet looks like there is a need of a *stateful* PCE to support RWA.
If that the case probably worth a reference to RFC4655 section 6.8.


3) Sec. 4.1.3
The statement "this approach may generate higher blocking probability.." is there any reference that demonstrate this?


4) Section 4.3
Is not really clear to me the scope of this section, why do we need to state anything about temporal characteristics?
Another comment that I did some time ago was about defining dynamic/pseudo-static/static with no reference: the draft just mention short or moderately-long and long duration.


5) Sec. 5.5.4
I understand you need to clarify some typical optical terminology like: transparent / translucent etc. but how about having all terminology grouped in section 3?
And basically this WSON framework support either transparent (in different flavors) and translucent.


Cheers
G

 --------------050902000304090400020105-- From db3546@att.com Fri Feb 26 13:50:57 2010 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 D98F73A885B; Fri, 26 Feb 2010 13:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 RnAwzDbNe5Fm; Fri, 26 Feb 2010 13:50:55 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 7FF523A870D; Fri, 26 Feb 2010 13:50:55 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-3.tower-161.messagelabs.com!1267221190!23979943!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 12125 invoked from network); 26 Feb 2010 21:53:11 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Feb 2010 21:53:11 -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 o1QLr1Fb030582; Fri, 26 Feb 2010 16:53:01 -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 o1QLr0jH030557; Fri, 26 Feb 2010 16:53:00 -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: Fri, 26 Feb 2010 16:53:08 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: poll on draft-abfb-mpls-tp-control-plane-framework Thread-Index: Acq3LhTmuSG/kxGCTt+1iMNqBtXcyg== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Cc: mpls@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: [CCAMP] poll on draft-abfb-mpls-tp-control-plane-framework 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, 26 Feb 2010 21:50:57 -0000 All, This is to start a two week working group poll on making draft-abfb-mpls-tp-control-plane-framework-02.txt as a ccamp working group document. This poll is being initiated at this time as this document is part of the MPLS-TP work and it is needed to progress the work. Send your response to the ccamp@ietf.org mailing list (only), indicating "yes/support" or "no/do not support". This poll ends March 12th. Deborah From agmalis@gmail.com Fri Feb 26 14:05:30 2010 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 D88F03A8877 for ; Fri, 26 Feb 2010 14:05:30 -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 E4W3STabAB8q for ; Fri, 26 Feb 2010 14:05:30 -0800 (PST) Received: from mail-yx0-f188.google.com (mail-yx0-f188.google.com [209.85.210.188]) by core3.amsl.com (Postfix) with ESMTP id D30573A886D for ; Fri, 26 Feb 2010 14:05:26 -0800 (PST) Received: by yxe26 with SMTP id 26so315305yxe.29 for ; Fri, 26 Feb 2010 14:07:39 -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; bh=2S0dKictzwGOp/IvfnE17eIpDWJ0p6RSIj3HULH3uwA=; b=HMcsM3tEp5ONZEKS7hWkUgKkI/JWoZRHXYaYUx0qqNImZb4ssPh6H8incqDk5nzhKj wD1BkYEqFJQxYj/7An//eyEJS1Yxn/xmsjNmL0RkivCbWFKSzmk6in8w9ho6XXTZqQeU e32Ek+HL/yYDjnbMX/md6bAGvELzdC6Ee9juA= 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; b=nYbxLap+Vtmk+gVqqDsGWwo+L8NZAAH+50eZMzguOduQOTXWMU8WADCP0q4CvcqA02 70T3THHVWFMaADuLPid/fE/RNfz0sJ9JWok4UqkLL5NSxjP2JMr1r0rNaZwgKzt22C+8 Sx83qcm1C9ulASEqc4vxNUERKRw5fIuzxRvL8= MIME-Version: 1.0 Received: by 10.101.206.5 with SMTP id i5mr1663652anq.166.1267222059199; Fri, 26 Feb 2010 14:07:39 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 26 Feb 2010 17:07:19 -0500 Message-ID: <8c99930d1002261407yc7328c2t128b8a60bfa07095@mail.gmail.com> To: "BRUNGARD, DEBORAH A (ATTLABS)" Content-Type: text/plain; charset=ISO-8859-1 Cc: CCAMP Subject: Re: [CCAMP] [PWE3] poll on draft-abfb-mpls-tp-control-plane-framework 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, 26 Feb 2010 22:05:31 -0000 yes/support!!!!!!! On Fri, Feb 26, 2010 at 4:53 PM, BRUNGARD, DEBORAH A (ATTLABS) wrote: > All, > > This is to start a two week working group poll on making > draft-abfb-mpls-tp-control-plane-framework-02.txt as a ccamp working > group document. This poll is being initiated at this time as this > document is part of the MPLS-TP work and it is needed to progress the > work. > > Send your response to the ccamp@ietf.org mailing list (only), indicating > "yes/support" or "no/do not support". > > This poll ends March 12th. > > Deborah From pierre.peloso@alcatel-lucent.com Fri Feb 26 14:28:19 2010 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 42EC63A8890 for ; Fri, 26 Feb 2010 14:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_52=0.6, J_CHICKENPOX_62=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 TwMESG5Zy0yf for ; Fri, 26 Feb 2010 14:28:18 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id DB1E83A85CF for ; Fri, 26 Feb 2010 14:28:17 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o1QMUN3R029511 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 26 Feb 2010 23:30:24 +0100 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 26 Feb 2010 23:30:17 +0100 From: "PELOSO, PIERRE (PIERRE)" To: Greg Bernstein Date: Fri, 26 Feb 2010 23:30:22 +0100 Thread-Topic: Disscussion and contribution in RWA drafts (encode and info) - switching constraints Thread-Index: Acq0pCBiEg6dFQowSdSpfku4iZCwkgCKQuKw Message-ID: References: <4B83FFEF.3090106@grotto-networking.com> In-Reply-To: <4B83FFEF.3090106@grotto-networking.com> Accept-Language: en-US Content-Language: fr-FR 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-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Disscussion and contribution in RWA drafts (encode and info) - switching constraints 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, 26 Feb 2010 22:28:19 -0000 Hi Greg and CCAMPers, For clarification purposes, I've taken the freedom to clean a bit the origi= nal email and separate its content in smaller pieces. This one deals specifically with the clarification of the node switching co= nstraints and resource identification: - Pierre BERNSTEIN, GREG (wrote): >Hi Pierre and fellow CCAMPers, see response in line below. > >Greg > >PELOSO, PIERRE (PIERRE) wrote: >> Hi Greg, Young and CCAMP'rs, >> [...] >> 1. The drafts propose different pieces of information to describe the no= de internal switching structure (and constraints) and to describe the O-E-O= resources inside the node. However, they do not describe how these pieces = of information fit together in order to build the global picture of the nod= e internal switching constraints. For example, considering the list of O-E= -O resources how you determine which of those are available from a given in= coming link to a given outgoing link, what are the associated wavelength re= strictions associated, etc... >> =20 >--> Hmm, maybe this section needs more explanatory text. It looks like you= gave the high level summary in your point "2" above. In more detail: we br= eak the resource pool into the largest blocks possible (with identical ingr= ess, egress and wavelength constraints), we specify the ingress connectivit= y constraints to the blocks and ingress wavelength constraints to each bloc= k. Similarly we specify the egress connectivity constraints from each block= and any wavelength constraints associated with those. If needed a minimal = amount of state information can be associated with each resource block (num= ber of resources available in each block). We have a paper in progress tha= t shows this technique used to model a fairly wide collection of different = combined switch architectures gathered from the literature. We can make a p= reliminary draft available to those interested in the details. PP: I have no issue with the capabilities of your technique to describe a n= ode and its O-E-O resources whatever the architecture used. I am more conce= rned with the lack of detail provided in current drafts. At this stage, there are too many unspecified details for implementing the = drafts in a unique manner. E.g. There is supposedly a switching matrix information to depict the node = internal switching structure. Is it supposed to be in [Gen-Encode] draft under preparation? In previous v= ersion of the draft this object was refering to "port ID", are those suppos= ed to be "link local/remote identifiers", I understand yes from your last e= mail but would this appear in the draft? Then should'nt there be a recommen= dation to use "LLRI" in the Link information object as well? When adding the resource pool, things are getting more complex: Can there be more than one Resource pool object in the description of a nod= e? Is this object supposed to be a top-level TLV or is it supposed to be a = sub-TLV inside a Node object?=20 A "resource pool" object is composed of: - A "resource block info" basically a list of resource ID with their fe= atures regarding signal (incoming and outgoing)- is that right? Then I imag= ine that we will have as many resource block info object as there are diffe= rent combination of signal features in the node. - A "resource block accessibility" basically a list of (resource blocks= , switching constraints on each side of the block). Then I imagine that the= resource blocks here have nothing to do with the one used for the "resourc= e block info"? Are the switching constraints to be related to the Link info= rmation object, then once again the draft would benefit from refering to "l= ink local/remote identifiers"? - A "resource wave constraints" basically a resource block with wavelen= gth constraint on each side of the block. Is that to depict: 1.the waveleng= th constraints of the architecture, 2. the limitations of the resources/dev= ices or 3.the usage of the wavelengths by other resources sharing the same = port? Because some of these elements are dynamic and some are static. And t= he grouping of resources in blocks will follow different rules depending on= what is to be depicted with that (leading certainly to a third list of res= ource blocks). Hence that is giving me the idea that something is missing, = as we would certainly like to depict all these 3 constraints and only one c= an be depicted there, isn't it? To summarize, I end up having the impression that a node and its switching = matrix is depicted twice in the same object. A first time for the bypassing= traffic and a second one comporting the additional information of the reso= urces. Then I have the feeling that gathering all the information relative = to the switching constraints in a unique object with more ports would be mo= re efficient as this object would never change and the ports would be defin= ed once and for all. There would be the external ports that are referring t= o the "WDM link information" and using the LLRI of the WDM links. And there= would be the internal ports corresponding to physical pools of ressources. This modification is just a minor adaptation of your technique, using most = of the same encodings, did you try this direction ? Pierre= From root@core3.amsl.com Fri Feb 26 18:15:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6DB0128C217; Fri, 26 Feb 2010 18:15: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: <20100227021502.6DB0128C217@core3.amsl.com> Date: Fri, 26 Feb 2010 18:15:02 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-hierarchy-bis-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: Sat, 27 Feb 2010 02:15: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 : Procedures for Dynamically Signaled Hierarchical Label Switched Paths Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-lsp-hierarchy-bis-08.txt Pages : 29 Date : 2010-02-26 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-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-lsp-hierarchy-bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-26180713.I-D@ietf.org> --NextPart-- From Adrian.Farrel@huawei.com Fri Feb 26 18:18:37 2010 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 C52F328C1FB for ; Fri, 26 Feb 2010 18:18:37 -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.080, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5bMgsSfT9pO for ; Fri, 26 Feb 2010 18:18:36 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id AAD7028C0F8 for ; Fri, 26 Feb 2010 18:18:36 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYH00DN3AITVS@usaga03-in.huawei.com> for ccamp@ietf.org; Fri, 26 Feb 2010 20:20:53 -0600 (CST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYH00732AIQLZ@usaga03-in.huawei.com> for ccamp@ietf.org; Fri, 26 Feb 2010 20:20:53 -0600 (CST) Date: Sat, 27 Feb 2010 02:20:25 +0000 From: Adrian Farrel To: ccamp@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [CCAMP] Update to draft-ietf-ccamp-lsp-hierarchy-bis X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 02:18:38 -0000 Hi, I carried out a sort of AD review of draft-ietf-ccamp-lsp-hierarchy-bis and fixed a couple of typos, updated the references, and fixed the boilerplate. However, as I am an editor of this document, I will now hand it over to Ross to push the buttons. Cheers, Adrian From loa@pi.nu Sat Feb 27 03:59:54 2010 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 7E9F33A8764; Sat, 27 Feb 2010 03:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 T+GUoByijLFo; Sat, 27 Feb 2010 03:59:53 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 7F6E13A8760; Sat, 27 Feb 2010 03:59:53 -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 B9AF9D4052; Sat, 27 Feb 2010 13:02:09 +0100 (CET) Message-ID: <4B8909D8.9020208@pi.nu> Date: Sat, 27 Feb 2010 13:02:32 +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, pwe3@ietf.org, CCAMP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] poll to make draft-nitinb-mpls-tp-lsp-ping-extensions an mpls working 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, 27 Feb 2010 11:59:54 -0000 All, this is to start a poll on accepting draft-nitinb-mpls-tp-lsp-ping-extensions-01 as an mpls working group document. Please respond to the mpls-tp mailing list *only*! Indicating "yes/support" or "no/do not support". Technical comments, which are very welcome, should be sent to the same list, but with a differnt subject line. The poll ends eob March 12th 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 nurit.sprecher@nsn.com Sat Feb 27 14:03:30 2010 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 9A38F3A7B51 for ; Sat, 27 Feb 2010 14:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, 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 1pQ6auykjH+7 for ; Sat, 27 Feb 2010 14:03:29 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 74A063A7AEC for ; Sat, 27 Feb 2010 14:03:28 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o1RM5hNZ015767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 27 Feb 2010 23:05:43 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o1RM5eHK002272; Sat, 27 Feb 2010 23:05:40 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Feb 2010 23:05:40 +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: Sat, 27 Feb 2010 23:05:36 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326401E4DB2C@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] poll on draft-abfb-mpls-tp-control-plane-framework Thread-Index: Acq3LhTmuSG/kxGCTt+1iMNqBtXcygAytrqw References: From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext BRUNGARD, DEBORAH A (ATTLABS)" , "CCAMP" X-OriginalArrivalTime: 27 Feb 2010 22:05:40.0405 (UTC) FILETIME=[FFC05E50:01CAB7F8] Subject: Re: [CCAMP] [PWE3] poll on draft-abfb-mpls-tp-control-plane-framework 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, 27 Feb 2010 22:03:30 -0000 Yes/support -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of ext BRUNGARD, DEBORAH A (ATTLABS) Sent: Friday, February 26, 2010 11:53 PM To: CCAMP Cc: mpls@ietf.org; pwe3@ietf.org; mpls-tp@ietf.org Subject: [PWE3] poll on draft-abfb-mpls-tp-control-plane-framework All, This is to start a two week working group poll on making draft-abfb-mpls-tp-control-plane-framework-02.txt as a ccamp working group document. This poll is being initiated at this time as this document is part of the MPLS-TP work and it is needed to progress the work. Send your response to the ccamp@ietf.org mailing list (only), indicating "yes/support" or "no/do not support". This poll ends March 12th. Deborah _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From tm-otani@kddi.com Sun Feb 28 15:28:41 2010 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 EC17E3A89CC; Sun, 28 Feb 2010 15:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.018 X-Spam-Level: * X-Spam-Status: No, score=1.018 tagged_above=-999 required=5 tests=[AWL=1.203, BAYES_40=-0.185] 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 u-DJvYla0Lxy; Sun, 28 Feb 2010 15:28:41 -0800 (PST) Received: from UTMC1103.kddi.com (athena.kddi.com [210.141.112.39]) by core3.amsl.com (Postfix) with ESMTP id 300433A8886; Sun, 28 Feb 2010 15:28:40 -0800 (PST) Received: from UTMC1132 (unknown [10.5.16.195]) by UTMC1103.kddi.com (Postfix) with SMTP id E1C101D95; Mon, 1 Mar 2010 08:28:40 +0900 (JST) Received: from UTMC1123.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id D26D21A41; Mon, 1 Mar 2010 08:28:37 +0900 (JST) Received: from UTMC1113.kddi.com (unknown [10.5.16.13]) by UTMC1123.kddi.com (Postfix) with ESMTP id C299119FC; Mon, 1 Mar 2010 08:28:37 +0900 (JST) Received: from KDDI-0805PC0145 ([10.211.58.104] [10.211.58.104]) by post-ims.kddi.com with ESMTPA; Mon, 1 Mar 2010 08:28:37 +0900 To: db3546@att.com, ccamp@ietf.org From: Tomohiro Otani References: In-Reply-To: Message-Id: <201003010828.CIJ90157.OPUBUJtN@kddi.com> X-Mailer: Winbiff [Version 2.51 PL3] X-Accept-Language: ja,en,zh Date: Mon, 1 Mar 2010 08:28:38 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-WAuditID: 1003010828370000201171 Cc: mpls@ietf.org, pwe3@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] poll on draft-abfb-mpls-tp-control-plane-framework 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: Sun, 28 Feb 2010 23:28:42 -0000 Hi all, Yes/Support. This is a good draft for starting to formalize application of GMPLS. # I have been re-subscribing a couple of lists. Regards, Tomo $B$N!"(B "[CCAMP] poll on draft-abfb-mpls-tp-control-plane-framework" $B$K$*$$$F!"(B ""BRUNGARD, DEBORAH A (ATTLABS)" "$B$5$s$O=q$-$^$7$?!'(B >All, > >This is to start a two week working group poll on making >draft-abfb-mpls-tp-control-plane-framework-02.txt as a ccamp working >group document. This poll is being initiated at this time as this >document is part of the MPLS-TP work and it is needed to progress the >work. > >Send your response to the ccamp@ietf.org mailing list (only), indicating >"yes/support" or "no/do not support". > >This poll ends March 12th. > >Deborah >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp > From bao.yuanlin@zte.com.cn Sun Feb 28 17:04:44 2010 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 CC7B028C22F; Sun, 28 Feb 2010 17:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[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 10qXS+EJsXce; Sun, 28 Feb 2010 17:04:44 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 53A0B28C22B; Sun, 28 Feb 2010 17:04:43 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111641461793122; Mon, 1 Mar 2010 08:27:01 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 64572.4511082050; Mon, 1 Mar 2010 09:04:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o2112SDr000675; Mon, 1 Mar 2010 09:02:29 +0800 (CST) (envelope-from Bao.Yuanlin@zte.com.cn) In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326401E4DB2C@DEMUEXC014.nsn-intra.net> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: Bao.Yuanlin@zte.com.cn Date: Mon, 1 Mar 2010 09:04:22 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-01 09:02:25, Serialize complete at 2010-03-01 09:02:25 Content-Type: multipart/alternative; boundary="=_alternative 0005B6B3482576D9_=" X-MAIL: mse2.zte.com.cn o2112SDr000675 Cc: CCAMP , ccamp-bounces@ietf.org Subject: [CCAMP] =?gb2312?b?tPC4tDogUmU6ICBbUFdFM10gcG9sbCBvbglkcmFmdC1h?= =?gb2312?b?YmZiLW1wbHMtdHAtY29udHJvbC1wbGFuZS1mcmFtZXdvcms=?= 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, 01 Mar 2010 01:04:44 -0000 This is a multipart message in MIME format. --=_alternative 0005B6B3482576D9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVzL3N1cHBvcnQNCg0KDQpSZWdhcmRzLA0KWXVhbmxpbiBCYW8NCg0KDQoNCg0KIlNwcmVjaGVy LCBOdXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKSIgPG51cml0LnNwcmVjaGVyQG5zbi5jb20+ IA0Kt6K8/sjLOiAgY2NhbXAtYm91bmNlc0BpZXRmLm9yZw0KMjAxMC0wMi0yOCAwNjowNQ0KDQrK 1bz+yMsNCiJleHQgQlJVTkdBUkQsIERFQk9SQUggQSAoQVRUTEFCUykiIDxkYjM1NDZAYXR0LmNv bT4sICJDQ0FNUCIgDQo8Y2NhbXBAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOINClJlOiBbQ0NBTVBd IFtQV0UzXSBwb2xsIG9uICAgICAgZHJhZnQtYWJmYi1tcGxzLXRwLWNvbnRyb2wtcGxhbmUtZnJh bWV3b3JrDQoNCg0KDQoNCg0KDQoNClllcy9zdXBwb3J0DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBwd2UzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwd2UzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KZXh0IEJSVU5HQVJELCBERUJPUkFIIEEgKEFUVExBQlMp DQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDI2LCAyMDEwIDExOjUzIFBNDQpUbzogQ0NBTVANCkNj OiBtcGxzQGlldGYub3JnOyBwd2UzQGlldGYub3JnOyBtcGxzLXRwQGlldGYub3JnDQpTdWJqZWN0 OiBbUFdFM10gcG9sbCBvbiBkcmFmdC1hYmZiLW1wbHMtdHAtY29udHJvbC1wbGFuZS1mcmFtZXdv cmsNCg0KQWxsLA0KDQpUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBw b2xsIG9uIG1ha2luZw0KZHJhZnQtYWJmYi1tcGxzLXRwLWNvbnRyb2wtcGxhbmUtZnJhbWV3b3Jr LTAyLnR4dCBhcyBhIGNjYW1wIHdvcmtpbmcNCmdyb3VwIGRvY3VtZW50LiBUaGlzIHBvbGwgaXMg YmVpbmcgaW5pdGlhdGVkIGF0IHRoaXMgdGltZSBhcyB0aGlzDQpkb2N1bWVudCBpcyBwYXJ0IG9m IHRoZSBNUExTLVRQIHdvcmsgYW5kIGl0IGlzIG5lZWRlZCB0byBwcm9ncmVzcyB0aGUNCndvcmsu DQoNClNlbmQgeW91ciByZXNwb25zZSB0byB0aGUgY2NhbXBAaWV0Zi5vcmcgbWFpbGluZyBsaXN0 IChvbmx5KSwgaW5kaWNhdGluZw0KInllcy9zdXBwb3J0IiBvciAibm8vZG8gbm90IHN1cHBvcnQi Lg0KDQpUaGlzIHBvbGwgZW5kcyBNYXJjaCAxMnRoLg0KDQpEZWJvcmFoDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHdlMyBtYWlsaW5nIGxpc3QNCnB3 ZTNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdlMw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1h aWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2NhbXANCg0KDQoNCg== --=_alternative 0005B6B3482576D9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5ZZXMvc3VwcG9ydDwvZm9udD48L3R0Pg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5SZWdhcmRzLDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WXVhbmxpbiBCYW88YnI+DQo8L2ZvbnQ+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7U3By ZWNoZXIsIE51cml0IChOU04NCi0gSUwvSG9kIEhhU2hhcm9uKSZxdW90OyAmbHQ7bnVyaXQuc3By ZWNoZXJAbnNuLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtjY2FtcC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDItMjggMDY6MDU8L2ZvbnQ+DQo8 dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7Iyzwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7ZXh0 IEJSVU5HQVJELCBERUJPUkFIIEEgKEFUVExBQlMpJnF1b3Q7DQombHQ7ZGIzNTQ2QGF0dC5jb20m Z3Q7LCAmcXVvdDtDQ0FNUCZxdW90OyAmbHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW0NDQU1Q XSBbUFdFM10gcG9sbCBvbiAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ZHJhZnQtYWJmYi1t cGxzLXRwLWNvbnRyb2wtcGxhbmUtZnJhbWV3b3JrPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFi bGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8 YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpZZXMvc3VwcG9ydDxicj4NCjxi cj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogcHdlMy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86cHdlMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Y8YnI+DQpl eHQgQlJVTkdBUkQsIERFQk9SQUggQSAoQVRUTEFCUyk8YnI+DQpTZW50OiBGcmlkYXksIEZlYnJ1 YXJ5IDI2LCAyMDEwIDExOjUzIFBNPGJyPg0KVG86IENDQU1QPGJyPg0KQ2M6IG1wbHNAaWV0Zi5v cmc7IHB3ZTNAaWV0Zi5vcmc7IG1wbHMtdHBAaWV0Zi5vcmc8YnI+DQpTdWJqZWN0OiBbUFdFM10g cG9sbCBvbiBkcmFmdC1hYmZiLW1wbHMtdHAtY29udHJvbC1wbGFuZS1mcmFtZXdvcms8YnI+DQo8 YnI+DQpBbGwsPGJyPg0KPGJyPg0KVGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHdvcmtpbmcg Z3JvdXAgcG9sbCBvbiBtYWtpbmc8YnI+DQpkcmFmdC1hYmZiLW1wbHMtdHAtY29udHJvbC1wbGFu ZS1mcmFtZXdvcmstMDIudHh0IGFzIGEgY2NhbXAgd29ya2luZzxicj4NCmdyb3VwIGRvY3VtZW50 LiBUaGlzIHBvbGwgaXMgYmVpbmcgaW5pdGlhdGVkIGF0IHRoaXMgdGltZSBhcyB0aGlzPGJyPg0K ZG9jdW1lbnQgaXMgcGFydCBvZiB0aGUgTVBMUy1UUCB3b3JrIGFuZCBpdCBpcyBuZWVkZWQgdG8g cHJvZ3Jlc3MgdGhlPGJyPg0Kd29yay48YnI+DQo8YnI+DQpTZW5kIHlvdXIgcmVzcG9uc2UgdG8g dGhlIGNjYW1wQGlldGYub3JnIG1haWxpbmcgbGlzdCAob25seSksIGluZGljYXRpbmc8YnI+DQom cXVvdDt5ZXMvc3VwcG9ydCZxdW90OyBvciAmcXVvdDtuby9kbyBub3Qgc3VwcG9ydCZxdW90Oy48 YnI+DQo8YnI+DQpUaGlzIHBvbGwgZW5kcyBNYXJjaCAxMnRoLjxicj4NCjxicj4NCkRlYm9yYWg8 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CnB3ZTMgbWFpbGluZyBsaXN0PGJyPg0KcHdlM0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdlMzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KQ0NB TVBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj YW1wPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 0005B6B3482576D9_=--