From nobody Mon Jan 18 06:45:56 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DFD1B37CA; Mon, 18 Jan 2016 06:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.804 X-Spam-Level: * X-Spam-Status: No, score=1.804 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N58GsHH3V98i; Mon, 18 Jan 2016 06:45:51 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id EE1BB1B37C8; Mon, 18 Jan 2016 06:45:46 -0800 (PST) Received: from [172.16.4.98] (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id F091F242E57; Mon, 18 Jan 2016 15:45:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1453128344; bh=juqk+Bt4OjIafDYWWwtlay8Bz0fXqysdZfbgqpdw8OE=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=bS7sOpKAz1myvxqgZV86tzyazHk1Uc/YtEazShQlQAqIEnJJNTYBKF3t/eSKk3Sqc jaoI6axZMfPCppTfQTG4267ST/zQ8EtSeOo/YK+6Wp0dcG3w5DdupFOH1GBq9QIk5Z TvWfk9Oi3DTZLstnXiu5h5S+abLOgvn0Y7yhIYIM= To: Ina Minei , Julien Meuric References: <56210C68.1080904@orange.com> From: Robert Varga Message-ID: <569CFA97.2080209@hq.sk> Date: Mon, 18 Jan 2016 15:45:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050306080002000208060302" Archived-At: Cc: draft-ietf-pce-stateful-pce@ietf.org, "pce@ietf.org" Subject: Re: [Pce] Chair's Review of draft-ietf-pce-stateful-pce-11 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 14:45:56 -0000 This is a multi-part message in MIME format. --------------050306080002000208060302 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hello, please find my comments on the pending items. On 10/26/2015 10:10 PM, Ina Minei wrote: > Julien, > > Thank you for the detailed review, please find answers inline below > ###. I have incorporated the overwhelming majority of the comments, > explained the reason for not incorporating a couple of them, and am > still working with the co-authors on a couple of items marked > "pending", which we will close on shortly. > > Two questions and one ask > 1. Forward references to SRP object and SRP-ID - there are several in > the comments, though the relevant section is always mentioned. How > should such forward references be addressed? > 2. Section 7 - s/defined in this document/defined in that > (aforementioned) document/ > The comment was not clear to me. The intention is for the flags to be > set as explained for the new objects we are defining here, can you > clarify the comment? > 3. Can you please review the comments that were not incorporated and > let us know if you agree? > > Thank you, > > Ina > > On Fri, Oct 16, 2015 at 7:40 AM, Julien Meuric > > wrote: > > Dear authors, > > To prepare the upcoming move to the IESG, please find below my > review of the aforementioned I-D (at last!). > > _Summary_ > > Main qualities: > - core specification is clear; > - wording is smooth, with very few typos; > - the manageability and security sections have been included with > relevant text. > Main issues to point out: > - RFC 2119 keywords (picky me, but so is the IESG: ask JP about 5440); > - a few corner/error cases; > - consistency with existing RFCs (5440, 5886). > I also take the opportunity to remind the WG that including > codepoint values from existing registries before allocation by the > IANA (which can be requested early) is a very bad idea, whatever > the WG. > > _Detailed Comments_ > > [snip] > - s/include an empty ERO/include an empty RRO/ [Along with RFC > 5440 (section 7.10), the object sent by a PCC to report to a PCE > is an RRO: let us keep it consistent.] > > ### XXX Pending In this case PCRpt differs from PCReq. The PCE needs to know the ERO object for each LSP, as may have been pushed by a different PCE. Reporting RRO is not sufficient, as that contains the effective LSP path, e.g. with loose hops expanded by the PCC. That is why ERO is a mandatory object in PCRpt (as part of intended_path), hence we specify an empty object for the end-of-sync marker. > > - Avoiding "positive acknowledgements for properly received > synchronization messages" has scalability benefits in normal > situations, but the PCC is blind and may keep on sending PCRpt to > dead processes behind up PCEP sessions. Have you consider > acknowledgement, possibly using a compression mechanism like the > one defined later in the I-D? > > ### XXX Pending The association between a PCEP session and PCE processes is something which I would consider an internal PCE detail, and it should be covered by the next sentence (e.g. raise PCErr 20/1). > - When mentioning errors, adding a sentence reminding that RFC > 5440 already defines a set of applicable error codes would be > valuable. > > ### XXX Pending I agree, this is an extension, so implementations should reuse RFC5440 errors when appropriate. > - In section 5.5.1, it is not clear if an empty LSP Update Request > with a Delegate flag to 1 is an acceptable way for a PCE to send a > delegation acknowledgement: to be clarified. > > ### XXX Pending It is not, as that would be seen as a request to modify the LSP setup to empty. Such an acknowledgement would have to include full configuration as previously reported -- which would be handled as a normal update. > - s/SHOULD return the LSP delegation/MUST return the LSP delegation/ > > ### This should remain SHOULD. The nice way to do it is to return it > explicitly, but it may choose to wait until the next update and return > the delegation then by not setting the delegate flag. > > - In section 5.5.3, assuming an LSP was delegated, does the > reception by the PCC of a non empty LSP Update Request with a > Delegate Flag to 0 trigger an error? > > ### XXX Pending It could, if we want to be strict about it, but it does not really have an impact on protocol operation: delegate=0 should kick in first, which means the PCC can safely discard any extra payload. > > - s/// [Per RFC 5440, a > report from PCC to PCE is RRO.] > > ### XXX Pending > > - The use of the optional xRO is mentioned, but its relationship > with the RRO (formerly ERO) is not clear. I suspect some > assumptions are made on the way the ERO/RRO are populated; RFC > 5440 only says ERO for PCE->PCC and RRO for PCC->PCE. > > ### XXX Pending The idea here is that ERO contains the path as pushed by the PCE. It may contain loose hops, which the PCC can expand as it sees fit. The RRO contains the effective path the LSP is currently taking, e.g. any loose hops are resolved. Since a backup PCE is not required to share state with the primary PCE, and there is no way to derive ERO from RRO, the PCEP session needs to communicate both, so a backup PCE can pick up the previous PCE's policy decision as well as the current LSP path. > > - The behavior associated to the resource limit per PCC rather > looks like a Notifcation than an Error (e.g., in RFC 5440, > cancelling a set of pending requests relies on PCNtf). Please > consider the use of Notification instead of Error here. > > ### XXX Pending Current wording is based on the assumption that the PCE has to have a consistent point-in-time view of the PCC's state. In this regard a PCRpt of a new LSP which exceeds PCE implementation-internal limit on the number of LSPs it supports would break that assumption, hence we chose PCErr. This makes it consistent with what would happen if that LSP is reported during initial state resynchronization. > - It would be nice to elaborate on the reason why the > SYMBOLIC-PATH-NAME MUST be included and not SHOULD. > - I do not see why SYMBOLIC-PATH-NAME may be included in SRP > Object: defining the LSP Object as its single place seems enough > and much simpler. > > > ### XXX Pending The MUST is there to maintain a single global identifier for the LSP. PLSP-ID is then used as a shorthand. I do not recollect the exact reasoning as to why the TLV can be in SRP, as the placement and semantics of that TLV has changed quite a bit over the past couple of years. If I were to venture a guess, I think it was retrofitted to allow the PCE to update the symbolic path name. Thanks, Robert --------------050306080002000208060302 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hello,

please find my comments on the pending items.

On 10/26/2015 10:10 PM, Ina Minei wrote:
Julien, 

Thank you for the detailed review, please find answers inline below ###.  I have incorporated the overwhelming majority of the comments, explained the reason for not incorporating a couple of them, and am still working with the co-authors on a couple of items marked "pending", which we will close on shortly.

Two questions and one ask
1. Forward references to SRP object and SRP-ID - there are several in the comments, though the relevant section is always mentioned. How should such forward references be addressed?
2. Section 7 - s/defined in this document/defined in that (aforementioned) document/
The comment was not clear to me. The intention is for the flags to be set as explained for the new objects we are defining here, can you clarify the comment?
3. Can you please review the comments that were not incorporated and let us know if you agree?

Thank you, 

Ina 

On Fri, Oct 16, 2015 at 7:40 AM, Julien Meuric <julien.meuric@orange.com> wrote:
Dear authors,

To prepare the upcoming move to the IESG, please find below my review of the aforementioned I-D (at last!).

_Summary_

Main qualities:
- core specification is clear;
- wording is smooth, with very few typos;
- the manageability and security sections have been included with relevant text.
Main issues to point out:
- RFC 2119 keywords (picky me, but so is the IESG: ask JP about 5440);
- a few corner/error cases;
- consistency with existing RFCs (5440, 5886).
I also take the opportunity to remind the WG that including codepoint values from existing registries before allocation by the IANA (which can be requested early) is a very bad idea, whatever the WG.

_Detailed Comments_


[snip]

- s/include an empty ERO/include an empty RRO/ [Along with RFC 5440 (section 7.10), the object sent by a PCC to report to a PCE is an RRO: let us keep it consistent.]
### XXX Pending

In this case PCRpt differs from PCReq. The PCE needs to know the ERO object for each LSP, as may have been pushed by a different PCE. Reporting RRO is not sufficient, as that contains the effective LSP path, e.g. with loose hops expanded by the PCC. That is why ERO is a mandatory object in PCRpt (as part of intended_path), hence we specify an empty object for the end-of-sync marker.
 
- Avoiding "positive acknowledgements for properly received synchronization messages" has scalability benefits in normal situations, but the PCC is blind and may keep on sending PCRpt to dead processes behind up PCEP sessions. Have you consider acknowledgement, possibly using a compression mechanism like the one defined later in the I-D?
### XXX Pending 

The association between a PCEP session and PCE processes is something which I would consider an internal PCE detail, and it should be covered by the next sentence (e.g. raise PCErr 20/1).

- When mentioning errors, adding a sentence reminding that RFC 5440 already defines a set of applicable error codes would be valuable.
### XXX Pending

I agree, this is an extension, so implementations should reuse RFC5440 errors when appropriate.

- In section 5.5.1, it is not clear if an empty LSP Update Request with a Delegate flag to 1 is an acceptable way for a PCE to send a delegation acknowledgement: to be clarified. 
### XXX Pending

It is not, as that would be seen as a request to modify the LSP setup to empty. Such an acknowledgement would have to include full configuration as previously reported -- which would be handled as a normal update.
 
- s/SHOULD return the LSP delegation/MUST return the LSP delegation/
### This should remain SHOULD. The nice way to do it is to return it explicitly, but it may choose to wait until the next update and return the delegation then by not setting the delegate flag. 
 
- In section 5.5.3, assuming an LSP was delegated, does the reception by the PCC of a non empty LSP Update Request with a Delegate Flag to 0 trigger an error?
### XXX Pending

It could, if we want to be strict about it, but it does not really have an impact on protocol operation: delegate=0 should kick in first, which means the PCC can safely discard any extra payload.
 
- s/<ERO><attribute-list>/<RRO><attribute-list>/ [Per RFC 5440, a report from PCC to PCE is RRO.]
### XXX Pending
- The use of the optional xRO is mentioned, but its relationship with the RRO (formerly ERO) is not clear. I suspect some assumptions are made on the way the ERO/RRO are populated; RFC 5440 only says ERO for PCE->PCC and RRO for PCC->PCE.
### XXX Pending

The idea here is that ERO contains the path as pushed by the PCE. It may contain loose hops, which the PCC can expand as it sees fit. The RRO contains the effective path the LSP is currently taking, e.g. any loose hops are resolved. Since a backup PCE is not required to share state with the primary PCE, and there is no way to derive ERO from RRO, the PCEP session needs to communicate both, so a backup PCE can pick up the previous PCE's policy decision as well as the current LSP path.
 
- The behavior associated to the resource limit per PCC rather looks like a Notifcation than an Error (e.g., in RFC 5440, cancelling a set of pending requests relies on PCNtf). Please consider the use of Notification instead of Error here.
### XXX Pending

Current wording is based on the assumption that the PCE has to have a consistent point-in-time view of the PCC's state. In this regard a PCRpt of a new LSP which exceeds PCE implementation-internal limit on the number of LSPs it supports would break that assumption, hence we chose PCErr. This makes it consistent with what would happen if that LSP is reported during initial state resynchronization.

- It would be nice to elaborate on the reason why the SYMBOLIC-PATH-NAME MUST be included and not SHOULD.
- I do not see why SYMBOLIC-PATH-NAME may be included in SRP Object: defining the LSP Object as its single place seems enough and much simpler.

### XXX  Pending

The MUST is there to maintain a single global identifier for the LSP. PLSP-ID is then used as a shorthand. I do not recollect the exact reasoning as to why the TLV can be in SRP, as the placement and semantics of that TLV has changed quite a bit over the past couple of years. If I were to venture a guess, I think it was retrofitted to allow the PCE to update the symbolic path name.

Thanks,
Robert

--------------050306080002000208060302-- From nobody Thu Jan 21 06:06:43 2016 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E62A11A87D2; Thu, 21 Jan 2016 06:06:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160121140640.4941.97340.idtracker@ietfa.amsl.com> Date: Thu, 21 Jan 2016 06:06:40 -0800 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-pceps-07.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:06:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Secure Transport for PCEP Authors : Diego R. Lopez Oscar Gonzalez de Dios Qin Wu Dhruv Dhody Filename : draft-ietf-pce-pceps-07.txt Pages : 20 Date : 2016-01-21 Abstract: The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describe the usage of Transport Layer Security (TLS) to enhance PCEP security, hence the PCEPS acronym proposed for it. The additional security mechanisms are provided by the transport protocol supporting PCEP, and therefore they do not affect the flexibility and extensibility of PCEP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-pceps-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pceps-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 21 06:09:10 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BED1A87F1 for ; Thu, 21 Jan 2016 06:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w3dx0ZFeJ5O for ; Thu, 21 Jan 2016 06:09:04 -0800 (PST) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0131E1A8799 for ; Thu, 21 Jan 2016 06:09:03 -0800 (PST) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 851D92D0325 for ; Thu, 21 Jan 2016 15:09:01 +0100 (CET) Received: from ESTGVMSP111.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id 6EBC72D031F for ; Thu, 21 Jan 2016 15:09:01 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.54) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 21 Jan 2016 15:09:00 +0100 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (10.161.13.142) by DB4PR06MB0621.eurprd06.prod.outlook.com (10.161.13.139) with Microsoft SMTP Server (TLS) id 15.1.390.13; Thu, 21 Jan 2016 14:07:58 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) with mapi id 15.01.0390.013; Thu, 21 Jan 2016 14:07:58 +0000 From: DIEGO LOPEZ GARCIA To: "pce@ietf.org" Thread-Topic: draft-ietf-pce-pceps-07 available Thread-Index: AQHRVFUhmsR+ydbcQ0OVlJ0ZbaJYog== Date: Thu, 21 Jan 2016 14:07:58 +0000 Message-ID: <06EC97F2-E307-4AB9-AF08-ABFAAAE20B42@telefonica.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [213.251.71.160] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0621; 5:DrmYqwO5fvK4BjQRacMoIKQBgCXLGXxoYlywUh+7/yi2DR+R8uogoVa5shCWvSF+LeYGOrXsSmK5/WqyJua6nBkCJoIUi9ZLvQq7USJ0k1Svo9ZEgCIs1Qm7vYR3b/80WIty55ZfO4mnxWnDOt1hyw==; 24:jb1wcwqtibBa7xksKORR+HByEDxmEiccfgdA57quHdaTxk+WuSuCT88TR16uqrcjnFEamvLQMUzYVy/9ZE06c4xy/VWwve1VWclASC18vfY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0621; x-ms-office365-filtering-correlation-id: 543f5c42-2eeb-40f5-aab3-08d3226c4404 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(123027)(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:DB4PR06MB0621; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0621; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(252514010)(199003)(189002)(87936001)(230783001)(83716003)(54356999)(92566002)(19580395003)(19580405001)(101416001)(82746002)(2351001)(33656002)(229853001)(40100003)(122556002)(19617315012)(16236675004)(66066001)(5002640100001)(86362001)(1096002)(97736004)(81156007)(107886002)(5004730100002)(2906002)(189998001)(102836003)(50986999)(15975445007)(450100001)(3846002)(586003)(110136002)(5001960100002)(36756003)(77096005)(5008740100001)(2900100001)(10400500002)(106356001)(2501003)(6116002)(105586002)(11100500001)(106116001)(1220700001)(1730700002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0621; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_06EC97F2E3074AB9AF08ABFAAAE20B42telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2016 14:07:58.1090 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0621 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Subject: [Pce] draft-ietf-pce-pceps-07 available X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:09:08 -0000 --_000_06EC97F2E3074AB9AF08ABFAAAE20B42telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, We have just uploaded a new version of draft-ietf-pce-pceps (https://datatr= acker.ietf.org/doc/draft-ietf-pce-pceps/) We believe this new version addresses all the comments received from the SE= CDIR review after the last call period, and other pending ones provided by = Tom while that SECDIR review was taking place. As far as the authors can sa= y, the document is ready to progress. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --_000_06EC97F2E3074AB9AF08ABFAAAE20B42telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <1C49356587D3F64191C1D28DAF34D26C@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi,

We have just uploaded a new version of draft-ietf-pce-= pceps (https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/)

We believe this new version addresses all the comments rece= ived from the SECDIR review after the last call period, and other pending o= nes provided by Tom while that SECDIR review was taking place. As far as th= e authors can say, the document is ready to progress.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.= es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
 --_000_06EC97F2E3074AB9AF08ABFAAAE20B42telefonicacom_-- From nobody Thu Jan 21 13:48:25 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828141B33B1 for ; Thu, 21 Jan 2016 13:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.095 X-Spam-Level: X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id re9o4sK2mx5L for ; Thu, 21 Jan 2016 13:48:20 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id B4ADC1ABD3C for ; Thu, 21 Jan 2016 13:48:20 -0800 (PST) Received: from [172.16.0.179] (188-167-8-120.dynamic.chello.sk [188.167.8.120]) by mail.hq.sk (Postfix) with ESMTPSA id 171AA242020; Thu, 21 Jan 2016 22:48:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1453412899; bh=ii0BevYN2KITxrNH+B6aZfe+ZdtdYRlp7NldGsRPj+w=; h=Subject:To:References:From:Date:In-Reply-To; b=iBrbP3LonU7sC9jnPz72XVMWYAUB/xOm4DWBBPsdKTEcHrI2TAUz3oJoVMD+/p15Z AwJX8KshNR3jC8mQ0xB0c9J/rrTjnUQXybr81A+2YacemlRnAAfyj9+DBkeP1Jj3Wa EIX1bxgAWRqKBvpfIwcpfxJxd1Um+d7TpG6S0zGQ= To: DIEGO LOPEZ GARCIA , "pce@ietf.org" References: <06EC97F2-E307-4AB9-AF08-ABFAAAE20B42@telefonica.com> From: Robert Varga Message-ID: <56A15221.1090808@hq.sk> Date: Thu, 21 Jan 2016 22:48:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <06EC97F2-E307-4AB9-AF08-ABFAAAE20B42@telefonica.com> Content-Type: multipart/alternative; boundary="------------020004030002080308030001" Archived-At: Subject: Re: [Pce] draft-ietf-pce-pceps-07 available X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 21:48:23 -0000 This is a multi-part message in MIME format. --------------020004030002080308030001 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 2016-01-21 15:07, DIEGO LOPEZ GARCIA wrote: > Hi, > > We have just uploaded a new version of draft-ietf-pce-pceps > (https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/) > > We believe this new version addresses all the comments received from > the SECDIR review after the last call period, and other pending ones > provided by Tom while that SECDIR review was taking place. As far as > the authors can say, the document is ready to progress. > Hello, would it make sense to request an early codepoint allocation for use in implementations? Thanks, Robert --------------020004030002080308030001 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 2016-01-21 15:07, DIEGO LOPEZ GARCIA wrote:
Hi,

We have just uploaded a new version of draft-ietf-pce-pceps (https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/)

We believe this new version addresses all the comments received from the SECDIR review after the last call period, and other pending ones provided by Tom while that SECDIR review was taking place. As far as the authors can say, the document is ready to progress.


Hello,

would it make sense to request an early codepoint allocation for use in implementations?

Thanks,
Robert

--------------020004030002080308030001-- From nobody Mon Jan 25 08:57:49 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791AB1B2D4A; Mon, 25 Jan 2016 08:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpDaXC5cRbQE; Mon, 25 Jan 2016 08:54:05 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E73F1B2D51; Mon, 25 Jan 2016 08:53:33 -0800 (PST) X-AuditID: c618062d-f79d16d000001b1c-d7-56a65053854f Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 25.15.06940.35056A65; Mon, 25 Jan 2016 17:41:55 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Mon, 25 Jan 2016 11:53:32 -0500 From: David Sinicrope To: "ccamp@ietf.org" , "pce@ietf.org" , "teas@ietf.org" Thread-Topic: Response to Broadband Forum Liaison - Achieving Packet Network Optimization using DWDM Interfaces 18-Dec-2016 Thread-Index: AQHRV5Dr9Fp8efQgSESeUtESw5p9Sw== Date: Mon, 25 Jan 2016 16:53:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.6.150930 x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_D2CBBD391B7CC4davidsinicropeericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsUyuXRPiG5wwLIwg8kTxSw+PbzEbPH351ZG iydzbrBYXO7qZrfo6dW2mL5W2uLP6b9MFh3Nb1ksmu7fYLdo/bGDxWLBmpnMFn3N51kdeDxe 9s9h9JjyeyOrx85Zd9k9Wo68ZfVYsuQnk8f1pqvsHh82NbN5HL05l9mj5dlJtgDOKC6blNSc zLLUIn27BK6MtuasglbBiik9/SwNjL38XYycHBICJhJNVzaxQ9hiEhfurWcDsYUEjjBKHPyj 0sXIBWQvZ5R4+f44E0iCDahh3cY9LCC2iEC6RPu2qUwgRcwC95klXn17ygiSEBaokPh9fDEj RFGtxP8jvVANehKzT30EG8QioCpxde0bsM28AlYSs74sBtvMCHTF91NrwGqYBcQlbj2ZzwRx nYDEkj3nmSFsUYmXj/+xgtiiQDO7zqyA+kBJYs7ra8wQvfES7xeeY4SYLyhxcuYTlgmMIrOQ jJ2FpGwWkjKIuIHE+3PzmSFsbYllC19D2foSG7+cZYSwrSU+Lv3MiKxmASPHKkaO0uKCnNx0 I4NNjMDYPybBpruD8f50z0OMAhyMSjy8BeFLw4RYE8uKK3MPMUpwMCuJ8P7nWxYmxJuSWFmV WpQfX1Sak1p8iFGag0VJnNeGd1GYkEB6YklqdmpqQWoRTJaJg1OqgTHy9e9w21dT2nYlzfT7 dCPq19E1ZibcZlOkd/Ebn5lrF7nphL5htu2dxbkqZpxvm7MPt9t5ZzMtmZ+Q6iNi3RpfEDkl +4j2zeCZ5Qe1uCttClXPdObqSu3jPbT1ZdRVn6dlzU7+xXcEHJflGL74bue0a2pDjtXnfvZp jrO8syUXnMpUfF4mqcRSnJFoqMVcVJwIAA7Fjir5AgAA Archived-At: X-Mailman-Approved-At: Mon, 25 Jan 2016 08:57:48 -0800 Cc: "jpv@cisco.com" , "vbeeram@juniper.net" , "aretana@cisco.com" Subject: [Pce] Response to Broadband Forum Liaison - Achieving Packet Network Optimization using DWDM Interfaces 18-Dec-2016 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 16:54:07 -0000 --_000_D2CBBD391B7CC4davidsinicropeericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, Just a reminder to the CCAMP, PCE and TEAS WGs that we still have https://datatracker.ietf.org/liaison/1449/ requesting a response. Please finalize and send your comments to the respective WG Chairs if you h= aven=92t already. We will coordinate a joint WG response. Thanks, Dave --_000_D2CBBD391B7CC4davidsinicropeericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <88D3F17B18F67F46AD579F082B7B8241@ericsson.com> Content-Transfer-Encoding: quoted-printable

--_000_D2CBBD391B7CC4davidsinicropeericssoncom_-- From nobody Mon Jan 25 10:39:06 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AD31B38D4; Mon, 25 Jan 2016 10:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cu4gfOFgVytj; Mon, 25 Jan 2016 10:38:52 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300301B38D3; Mon, 25 Jan 2016 10:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17145; q=dns/txt; s=iport; t=1453747132; x=1454956732; h=from:to:cc:subject:date:message-id:mime-version; bh=g4mULwIPSTdLqbM0qHzBg9kfQ0KQw14RyCMTE4p7lYA=; b=JSyK3a2BJhdHSJlbVKcVQpqrjd38OWDk1J26QAgOa3hXx4mMLEkCYNTC H0zcC4zc/U9KVPzku82amY4eRCHvfcAK66KkGnzbiJ5T74iw9+4IchUhu q6iJdI6PahxuwPmH29Az6tLSoSIIQi6BJoJIdfQZvh0mEjlC7lPBk97BI g=; X-Files: 273031C1-0F11-4D42-9226-D16B7CB14162[8].png : 1632 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgBWa6ZW/4UNJK1egm5MUm0GiFGvf?= =?us-ascii?q?oITAQ2BYyKFbQKBQjgUAQEBAQEBAYEKhEEBAgQFRDAOBAEIEQMBAgYBAQEbBAk?= =?us-ascii?q?FEAEDBgUMFAkKBAENBAEGCA2HawMSDrpHDYQCAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBDQgEhi6EbYE5gRCBXTsKDQmEBQWNYoUQhAQBhFxphhiBeIFehESIV1yGIYN?= =?us-ascii?q?vg1IBHgEBQoIOJoE1agGGAzx8AQEB?= X-IronPort-AV: E=Sophos;i="5.22,345,1449532800"; d="png'150?scan'150,208,217,150";a="65004484" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jan 2016 18:38:50 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u0PIcntE007370 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jan 2016 18:38:50 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 25 Jan 2016 13:38:49 -0500 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Mon, 25 Jan 2016 13:38:49 -0500 From: "Gabriele Maria Galimberti (ggalimbe)" To: David Sinicrope , "ccamp@ietf.org" , "pce@ietf.org" , "teas@ietf.org" Thread-Topic: [CCAMP] Response to Broadband Forum Liaison - Achieving Packet Network Optimization using DWDM Interfaces 18-Dec-2016 Thread-Index: AQHRV5+h86idbV8GX0GOyTt5wCjpXQ== Date: Mon, 25 Jan 2016 18:38:49 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.102.212] Content-Type: multipart/related; boundary="_004_D2CC21E38FE49ggalimbeciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "jpv@cisco.com" , "vbeeram@juniper.net" Subject: Re: [Pce] [CCAMP] Response to Broadband Forum Liaison - Achieving Packet Network Optimization using DWDM Interfaces 18-Dec-2016 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 18:39:00 -0000 --_004_D2CC21E38FE49ggalimbeciscocom_ Content-Type: multipart/alternative; boundary="_000_D2CC21E38FE49ggalimbeciscocom_" --_000_D2CC21E38FE49ggalimbeciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi David, Thanks for the reminder. I have few general notes on the document. * I would NOT limit the Client interface (Dd) to Ethernet or OTN. Also= Data center interfaces should be supported (like Fiber Channel). * In WT-319 Part-B is mentioned the fully separated solution while in T= R-319 the fully integrated DWDM interface in the client equipment. * The two solutions can signal on the UNI interface different servic= e request (Ethernet or OTN in the former, optical channel in the latter) * I'd like to see also the Hybrid solution to be supported (i.e. Ful= ly integrated on one side of the circuit and fully separated on the other s= ide). * Although are not yet RFC there are some draft proposal to manage the = Protection and the diverse path. * Support of LSP SRLG collection in the core and sharing the list to= the Edge (SRLG RRO) * XRO to exclude critical elements on the network when signalling LS= P (at node link and SRLG level) carrying protecting traffic. * Diverse path signalling based on LSP-id * I'd discourage the use of SNMP for the network provisioning and deplo= yment. Best Regards, Gabriele [http://www.cisco.com/swa/i/logo.gif] Gabriele Galimberti Principal Engineer Cisco Photonics Srl via S.Maria Molgora, 48 C 20871 - Vimercate (MB) Italy www.cisco.com/global/IT/ ggalimbe@cisco.com Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049 From: CCAMP > on beha= lf of David Sinicrope > Date: Monday, January 25, 2016 5:53 PM To: "ccamp@ietf.org" >, "pce@ietf.org" >, "teas@ietf.org" > Cc: "jpv@cisco.com" >, "vbeeram@juniper.net" >, "akatlas@gmail.com" > Subject: [CCAMP] Response to Broadband Forum Liaison - Achieving Packet Net= work Optimization using DWDM Interfaces 18-Dec-2016 Hi All, Just a reminder to the CCAMP, PCE and TEAS WGs that we still have https://datatracker.ietf.org/liaison/1449/ requesting a response. Please finalize and send your comments to the respective WG Chairs if you h= aven't already. We will coordinate a joint WG response. Thanks, Dave --_000_D2CC21E38FE49ggalimbeciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi David, 
Thanks for the reminder.

I have few general notes on the document.
  • I would NOT limit the Client interface (Dd) to Ethernet or OTN.  A= lso Data center interfaces should be supported (like Fiber Channel).
    • In WT-319 Part-B is mentioned the fully separated solution while in TR-31= 9 the fully integrated DWDM interface in the client equipment.
    • The two solutions can signal on the UNI interface different service req= uest (Ethernet or OTN in the former, optical channel in the latter)
      • I'd like to see also the Hybrid solution to be supported (i.e. Fully integ= rated on one side of the circuit and fully separated on the other side).
  • Although are not yet RFC there are some draft proposal to manage t= he Protection and the diverse path.
    • Support of LSP SRLG collection in the core and sharing the list to the = Edge  (SRLG RRO)
    • XRO to exclude critical elements on the netwo= rk when signalling LSP (at node link and SRLG level) carrying protecting tr= affic.
    • Diverse path signalling based on LSP-id
  • I'd discourage the use of SNMP for the network provisioning and de= ployment.

Best Regards, 

Gabriele


3D"http://www.cisco.com/swa/i/logo.gif"



Gabriele Galimberti Principal Engineer
Cisco Photonics Srl



via S.Maria Molgora, 48 C

20871 - Vimercate (MB)
Italy
www.cisco.com/global/IT/


ggalimbe@cisco.c= om
Phone :+39 039 2091462+39 335 7481947
Fax :+39 039 2092049













From: CCAMP <ccamp-bounces@ietf.org> on behalf of David Si= nicrope <david.sinicrope= @ericsson.com>
Date: Monday, January 25, 2016 5:53= PM
To: "ccamp@ietf.org" <cca= mp@ietf.org>, "pce@ietf.org= " <pce@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Cc: "jpv@cisco.com" <jpv@ci= sco.com>, "vbeeram@junip= er.net" <vbeeram@juniper= .net>, "akatlas@gmail.com" <= ;akatlas@gmail.com>
Subject: [CCAMP] Response to Broadb= and Forum Liaison - Achieving Packet Network Optimization using DWDM Interf= aces 18-Dec-2016

--_000_D2CC21E38FE49ggalimbeciscocom_-- --_004_D2CC21E38FE49ggalimbeciscocom_ Content-Type: image/png; name="273031C1-0F11-4D42-9226-D16B7CB14162[8].png" Content-Description: 273031C1-0F11-4D42-9226-D16B7CB14162[8].png Content-Disposition: inline; filename="273031C1-0F11-4D42-9226-D16B7CB14162[8].png"; size=1632; creation-date="Mon, 25 Jan 2016 18:38:49 GMT"; modification-date="Mon, 25 Jan 2016 18:38:49 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAG4AAABJCAIAAABTkIQiAAAGJ0lEQVR4nO2be0xTVxzHv30gcHk5 bRmKyMCJrhDsNi0xzldikE2dZr5mSEnm/poylxi3ZAuOkhhjspANZ0zUhT9GyNwMzoHDSHD4GEGI QGtGAQ10iEyg1a1Cy50tdH9cd7kqRVp+5WHO54/m9HDOl3M+nHvP6W2QeTweMCiQT/YAXhyYSjKY SjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjImQWXLnXvTOt8bE62yxtz2 XfnvNea2aZo/CsoJ/n0lVxsqG5sBLNcsmI75ozDRq1KYp/A6HfNHgW07ZDCVZDCVZARQpa+HkqnW 3lcCpdLXQ8lUa+8HgToM+XoomWrt/SBQq9LXQ8lUa+8HBCqn+wdBqvzxqpzuHwQJ88d7r/yooBhA ZWOz8cSX4x/NtM5n50oymEoymEoyxqty3euvia9jqafKCXS+H4x329m66g3xdSz1VDmBzveD8apc rlnwUji3eP6cMdZT5QQ63w8I7pXexjFi/SgXlE85E5DvKxP9hQThBTUp+aMgm/h/Nmm5c49qIUxK vjcmQeWLCjtXksFUkhHYbeevy5fF8tw1a8g7jqWZ32PwlYCodPN8x5Wrt4qL79fXO81NADhNctL2 bTqDwTM4KFMoANQZDMa8PADa3NxlBw8KlQBsLa2N3x7ruVwldnx5zdoVhlxOrRoxn7daAYSo1Unb t2kPfDojPExs1lVb13Wh3FJRaa+plqujI15dmJC+LvH9XarFiwIxa3qVbp5vOHnK+Mk+aaXT3HS3 PlEHeAAZgCf3useVgK2l9dLuD+011dKOFnPTss8OcFBJ828eOjRk7R1uZu29W5+YMjAgqmy7WFGz f7/w9wAwZO21W3uNNdW3z/2y9puvA7E86VU+5TFsiVbJhUntAIBM9mxHz+Bge0WF2DJOn6WMiATw oLFxBje81hpOnmr4/Au5sx8AgoLCNMlKLsx+o04a1VVbdyljvbRGro4W1DtMxt/2ZmeUlJCvTWKV TqvtdmGh+FZbcDQxPR2AvaPjkd2O/1ffiLgGeHvrLaGs2rhpdX6+cFE7rbbgmVHSfMGjXB2dmpMj zVeGhgJw87z5+yIxNmFPdvL2rQCazpRYTp2Ay+U0N7Wf/kFlMFDOnFxlR1WVw2QUytqCo7p9Hwtl cQmI98QRhhIaEqWeLZRt58uqDXnzVq+ak6abGR8vzf/3TwsABAWl5uQ8ne/xAOjv6bEcPybUJ+zJ Xpv/lTIkBMDM5BR338POou8BWCoqddQqiQ9Dfd3dYjll1y7fhqJQxL79jvjWcvzYtZ07ft28pfmn M9J8t9MJQMlxI+TLZAAc3T1ihSZLL3gEwKlVSZmZCAoCwHfTf/UWwHOlcLn5xNylb264XqvauEms cZiM13buaLtYQZIfUIhVRsTEiOW28nJfu8sUitg03ZZzP2+4XqvNzRXr20vLPIODQr6S4wC4nU5v +cFRUWK560K50BHAo35He2kZXC4AyshIX8f2XIhVqlNTw5ZohXLD4cNtFyucVpvTarO1tHbV1gEQ JzYCHo+b5908LwNi03S63Fxxebr7Hg4NDQn5wa8kAIDL9Wy+m+cBRM6bF6fPEjoa8/JaSs46rbZ/ OjqMhYWdxY+3o+gVb9FOHOTbjmrxooVbNhtNRgAOk/FSxnpBx0BnZ2hc3HtlpR7vm/ig2327tOzu latRi5IA4MF92/myx6OMiJTL5cP55ia4XA6TsUqvn5WWJuZnFBYqQ0JmhIct2f2BsL0AuLZzx83l KwDYb9QJSzI4IVGTpaedOAJxrkzZm32/3SLORNQRGhc33MjL46g+c5O4+YpwmmRNll7c+oX8jpKz cmf/kLV3xPyYlSu1BUfF4630VBuckKg7ciQ2Tefv/LxCr5JTq1bn5/+xdKnl9I/SOUTMj4eXJSlU yuVyzJr91I/i9FlJmZnSmUvz/zaZhDPmEBceMT9e3IjkCsWyvXsiYmKai4qGl3ZU1Jx3NydlZi5Y n0412SdmEdDnlX48SpB2eW6vKfU4gz36JYM9rySDqSSDqSSDqSSDqSSDqSSDqSSDqSSDqSSDqSSD qSSDqSSDqSSDqSSDqSTjP8P5+2z4huMfAAAAAElFTkSuQmCC --_004_D2CC21E38FE49ggalimbeciscocom_-- From nobody Tue Jan 26 06:01:36 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFB41A8BC0; Tue, 26 Jan 2016 06:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq7eAaEsGfdd; Tue, 26 Jan 2016 06:01:25 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF4D1A8BB1; Tue, 26 Jan 2016 06:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.onmicrosoft.com; s=selector1-metaswitch-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VyrDXZ9bh2D7VYJxppyBCpGOoZMAgnu3uJttE5nWgfk=; b=US0vtJB7R9+FuYqMSlPb4cCb1i0VPMt00n4ep2H54MhPKW/3AA9auLD3oeb5Es4fhEoiF/vEziDpxFtB+Hf5v5FUnE5CvDeiBLgnZFNteZ5FSPgUSyYzqiTOSAlCtYgJbpxy4adsXcwde/YnUlvXLVNtCayMPJXW3SQ+hgvO6E0= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) with Microsoft SMTP Server (TLS) id 15.1.390.13; Tue, 26 Jan 2016 14:01:24 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0390.013; Tue, 26 Jan 2016 14:01:24 +0000 From: Jonathan Hardwick To: "draft-ietf-pce-iro-update@ietf.org" Thread-Topic: Last IPR check for draft-ietf-pce-iro-update Thread-Index: AdFYQYNXhTLXGR8qSC+nKPJ2VbbPvgAAFxcA Date: Tue, 26 Jan 2016 14:01:23 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [86.183.200.240] x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1910; 5:mtQt5jMHED9G7ddn+bFvPq+/j+olGBrP8MXbmuVnne6CoS8rzxBJGdxCm9Ch4Hu14iDHF8sdl1lMOcj2oQGAZ9EkaED3Xp7EiLvA4WCqQa42V+bZDkXL6H8hwz3HfO4UKWi8WeI4v4QeZLGglcwe3A==; 24:aGDnVJYg9phyMnY5hJWlfEyPEWxvAT3c7ocn27KsdEt2zCFDlcxrjrNUOFkOE9hvvy5u+slmKuL4nrs9ITlq4Rk0cmpkt8jWrynJxwiEnhs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1910; x-ms-office365-filtering-correlation-id: ea3c97db-bb71-4b1a-e703-08d326592d1a x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(123027)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BY2PR0201MB1910; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1910; x-forefront-prvs: 08331F819E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(74316001)(5001960100002)(15975445007)(19625215002)(77096005)(102836003)(1220700001)(3846002)(54356999)(1096002)(76576001)(110136002)(229853001)(2900100001)(450100001)(11100500001)(106356001)(5002640100001)(101416001)(2420400006)(7110500001)(5008740100001)(105586002)(19300405004)(50986999)(5003600100002)(586003)(66066001)(189998001)(2351001)(99286002)(6116002)(3280700002)(19580395003)(122556002)(2906002)(97736004)(33656002)(87936001)(10710500007)(4326007)(2501003)(230783001)(81156007)(5004730100002)(16236675004)(10400500002)(86362001)(40100003)(790700001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1910; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB19103570910FC5E240E8B4DA84D80BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2016 14:01:23.7866 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1910 Archived-At: Cc: "pce@ietf.org" , "pce-chairs@ietf.org" Subject: [Pce] Last IPR check for draft-ietf-pce-iro-update X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 14:01:31 -0000 --_000_BY2PR0201MB19103570910FC5E240E8B4DA84D80BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors (Dhruv!), Please could you confirm (on the mailing list) whether you are aware of any= IPR that applies to draft-ietf-pce-iro-update, and if so, if it has been d= isclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and = 5378 for more details.) If you are not aware of any IPR that applies to th= is draft, please reply saying "I am not aware of any IPR that applies to th= is draft". Best regards, Jon, JP & Julien --_000_BY2PR0201MB19103570910FC5E240E8B4DA84D80BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear authors (Dhruv!),

 

Please could you confirm (on the mailing list) wheth= er you are aware of any IPR that applies to draft-ietf-pce-iro-update, and = if so, if it has been disclosed in compliance with IETF IPR rules? (See RFC= s 3979, 4879, 3669 and 5378 for more details.)  If you are not aware of any IPR that applies to this draft= , please reply saying “I am not aware of any IPR that applies to this= draft”.

 

Best regards,

 

Jon, JP & Julien

 

--_000_BY2PR0201MB19103570910FC5E240E8B4DA84D80BY2PR0201MB1910_-- From nobody Tue Jan 26 09:21:52 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BB41A9092; Tue, 26 Jan 2016 09:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UUwBGqzPs4K; Tue, 26 Jan 2016 09:21:45 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72221A908D; Tue, 26 Jan 2016 09:21:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.onmicrosoft.com; s=selector1-metaswitch-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=79L9IegzbIKUDfiY1rnsezkhFhEM3JbEq1uPO41Tzw0=; b=a8BgLUwQk6QYUW38gHxC4xFKPZc2VRtYacYLnduSh2Z/7RE3qUCi3FSR9uI8m01I78kFWpX9m4iVGeJbcvHwDJJ2VtZhkunOTUWOWubDndBy2nV2CFD85Y+1f4eoPLmnSZgkr4CSqMK9KkhRQV2tXr7qAPjgd/BPtobbBF8tbqM= Received: from BY2PR0201MB1910.namprd02.prod.outlook.com (10.163.75.152) by BY2PR0201MB1909.namprd02.prod.outlook.com (10.163.75.151) with Microsoft SMTP Server (TLS) id 15.1.390.13; Tue, 26 Jan 2016 17:21:43 +0000 Received: from BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) by BY2PR0201MB1910.namprd02.prod.outlook.com ([10.163.75.152]) with mapi id 15.01.0390.013; Tue, 26 Jan 2016 17:21:42 +0000 From: Jonathan Hardwick To: "draft-ietf-pce-iro-update@ietf.org" Thread-Topic: Shepherd's review of draft-ietf-pce-iro-update Thread-Index: AdFYSUYNKzAyfNvIRQqGxy0NqCHycA== Date: Tue, 26 Jan 2016 17:21:42 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com; x-originating-ip: [86.183.200.240] x-microsoft-exchange-diagnostics: 1; BY2PR0201MB1909; 5:VidBqawD3LJnjXBzgfNL3ZOpx8rvyxH2zSqcv7w6jocrqJuPXe/Eutugx/vfOy0Yt6O+62IFiNdo619jN1w8vcdriau+PMu8nKGJ47tRk0EjwRg+HaLiQ4mXWuYhoM4BTOF4s3+9TTxRvQO81Lt0Mg==; 24:ik/2urGVrJMpR8rkoBvBGFrBk0SMRgOg3d5Ig4LJevjIOwSjjCndxSheYiuQCfuAgeYGV1c6XEkZMky6pYlKPSLbCLHHDWiDjNAEsM4oJbg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0201MB1909; x-ms-office365-filtering-correlation-id: f89785ab-aef9-4a91-b5b1-08d3267528f3 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(123027)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BY2PR0201MB1909; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0201MB1909; x-forefront-prvs: 08331F819E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(52044002)(2351001)(105586002)(99286002)(5003600100002)(66066001)(87936001)(33656002)(76576001)(19625215002)(230783001)(16236675004)(10400500002)(106356001)(74316001)(81156007)(229853001)(5008740100001)(97736004)(2420400006)(122556002)(4326007)(54356999)(101416001)(2900100001)(1220700001)(1096002)(19580395003)(50986999)(110136002)(5001960100002)(77096005)(15975445007)(86362001)(102836003)(586003)(6116002)(790700001)(3846002)(10710500007)(2906002)(450100001)(19300405004)(5002640100001)(2501003)(40100003)(92566002)(3280700002)(5004730100002)(7110500001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0201MB1909; H:BY2PR0201MB1910.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB191070E2B67FDEFF279A740184D80BY2PR0201MB1910_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2016 17:21:42.6648 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1909 Archived-At: Cc: "pce@ietf.org" Subject: [Pce] Shepherd's review of draft-ietf-pce-iro-update X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 17:21:48 -0000 --_000_BY2PR0201MB191070E2B67FDEFF279A740184D80BY2PR0201MB1910_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have performed a document shepherd review of this draft. Here are my com= ments. Please feel free to discuss. The draft makes a good clarification to RFC 5440 and the author has taken g= reat care to check the impact on existing implementations. The draft proposes to add the L bit to IRO subobjects. Prior to this draft= , implementations should have been setting this bit to zero when sending, a= nd ignoring it on receipt. Following this draft, a value of zero is now to= be interpreted as indicating a "strict hop" in the IRO. However, accordin= g to the survey, there are at least two implementations that interpret IRO = subobjects as loose hops. From the point of view of such implementations, = this is a non-backwards-compatible change. I think the draft should explain the impact on operations if an implementat= ion conforming to this draft interworks with an implementation that does no= t. I think the impact is as follows. * If a non-conforming PCC sends an IRO to a conforming PCE, then the= PCE may unexpectedly fail to find a path (since the PCC thinks it is givin= g loose hops, but the PCE interprets them as strict hops). * If a conforming PCC sends an IRO containing strict hops to a non-c= onforming PCE, then the PCE may erroneously return a path that does not com= ply with the requested strict hops (since it interprets them all as loose h= ops). The PCC would have to double-check the returned path or else it may = end up using a path with unintended hops in it. The second impact seems worse than the first. I think the draft should not= e these possibilities in a new section, and should RECOMMEND that network o= perators ensure that all PCEs in their network conform to this draft if the= y intend to use IROs. I don't think the impact is critical enough to warra= nt adding a new capability to the protocol to indicate this updated behavio= ur, but I would be interested in hearing feedback from anyone (particularly= operators) who is worried by this. Apart from this, the draft looks good. The idnits tool throws up a handful= of warnings - please fix as many of these as you can. Thanks Jon --_000_BY2PR0201MB191070E2B67FDEFF279A740184D80BY2PR0201MB1910_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have performed a document shepherd review of this = draft.  Here are my comments.  Please feel free to discuss.<= /o:p>

 

The draft makes a good clarification to RFC 5440 and= the author has taken great care to check the impact on existing implementa= tions.

 

The draft proposes to add the L bit to IRO subobject= s.  Prior to this draft, implementations should have been setting this= bit to zero when sending, and ignoring it on receipt.  Following this= draft, a value of zero is now to be interpreted as indicating a “strict hop” in the IRO.  However, accord= ing to the survey, there are at least two implementations that interpret IR= O subobjects as loose hops.  From the point of view of such implementa= tions, this is a non-backwards-compatible change.

 

I think the draft should explain the impact on opera= tions if an implementation conforming to this draft interworks with an impl= ementation that does not.  I think the impact is as follows.

·        If a non-conforming PCC sends an IRO to a co= nforming PCE, then the PCE may unexpectedly fail to find a path (since the = PCC thinks it is giving loose hops, but the PCE interprets them as strict h= ops).

·        If a conforming PCC sends an IRO containing = strict hops to a non-conforming PCE, then the PCE may erroneously return a = path that does not comply with the requested strict hops (since it interpre= ts them all as loose hops).  The PCC would have to double-check the returned path or else it may end up usi= ng a path with unintended hops in it.

 

The second impact seems worse than the first.  = I think the draft should note these possibilities in a new section, and sho= uld RECOMMEND that network operators ensure that all PCEs in their network = conform to this draft if they intend to use IROs.  I don’t think the impact is critical enough to warra= nt adding a new capability to the protocol to indicate this updated behavio= ur, but I would be interested in hearing feedback from anyone (particularly= operators) who is worried by this.

 

Apart from this, the draft looks good.  The idn= its tool throws up a handful of warnings – please fix as many of thes= e as you can.

 

Thanks

Jon

 

--_000_BY2PR0201MB191070E2B67FDEFF279A740184D80BY2PR0201MB1910_-- From nobody Tue Jan 26 18:48:14 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8161B3440; Tue, 26 Jan 2016 18:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.288 X-Spam-Level: * X-Spam-Status: No, score=1.288 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xFWBH1QgdcZ; Tue, 26 Jan 2016 18:48:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20BE1B343F; Tue, 26 Jan 2016 18:48:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHM24113; Wed, 27 Jan 2016 02:48:08 +0000 (GMT) Received: from LHREML702-CAH.china.huawei.com (10.201.5.99) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 Jan 2016 02:48:07 +0000 Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 Jan 2016 02:48:06 +0000 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.9]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0235.001; Wed, 27 Jan 2016 08:17:58 +0530 From: Dhruv Dhody To: Jonathan Hardwick , "draft-ietf-pce-iro-update@ietf.org" Thread-Topic: Last IPR check for draft-ietf-pce-iro-update Thread-Index: AdFYQYNXhTLXGR8qSC+nKPJ2VbbPvgAAFxcAABrCiNA= Date: Wed, 27 Jan 2016 02:47:58 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C4F18FC@BLREML509-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.252] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C4F18FCBLREML509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.56A82FE8.00BF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.9, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 205f8185c777034208d0294753d64000 Archived-At: Cc: "pce@ietf.org" , "pce-chairs@ietf.org" Subject: Re: [Pce] Last IPR check for draft-ietf-pce-iro-update X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 02:48:12 -0000 --_000_23CE718903A838468A8B325B80962F9B8C4F18FCBLREML509MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 obBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0obEu DQoNClJlZ2FyZHMsDQpEaHJ1dg0KDQqxvtPKvP68sMbkuL28/rqs09C7qs6quavLvrXEsaPD3NDF z6KjrL32z97T2reiy824+MnPw+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9+w0K1rnIzrrOxuTL +8jL0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5wrahori01sahorvy yaK3oqOpsb7Tyrz+1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH68T6waK8tLXnu7C7 8tPKvP7NqNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNo bWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNo IGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3Mg aXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVy ZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBw YXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVy c29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQu IElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0KRnJv bTogUGNlIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb25hdGhh biBIYXJkd2ljaw0KU2VudDogMjYgSmFudWFyeSAyMDE2IDE5OjMxDQpUbzogZHJhZnQtaWV0Zi1w Y2UtaXJvLXVwZGF0ZUBpZXRmLm9yZw0KQ2M6IHBjZUBpZXRmLm9yZzsgcGNlLWNoYWlyc0BpZXRm Lm9yZw0KU3ViamVjdDogW1BjZV0gTGFzdCBJUFIgY2hlY2sgZm9yIGRyYWZ0LWlldGYtcGNlLWly by11cGRhdGUNCg0KRGVhciBhdXRob3JzIChEaHJ1diEpLA0KDQpQbGVhc2UgY291bGQgeW91IGNv bmZpcm0gKG9uIHRoZSBtYWlsaW5nIGxpc3QpIHdoZXRoZXIgeW91IGFyZSBhd2FyZSBvZiBhbnkg SVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdC1pZXRmLXBjZS1pcm8tdXBkYXRlLCBhbmQgaWYgc28s IGlmIGl0IGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVs ZXM/IChTZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMu KSAgSWYgeW91IGFyZSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBk cmFmdCwgcGxlYXNlIHJlcGx5IHNheWluZyChsEkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhh dCBhcHBsaWVzIHRvIHRoaXMgZHJhZnShsS4NCg0KQmVzdCByZWdhcmRzLA0KDQpKb24sIEpQICYg SnVsaWVuDQoNCg== --_000_23CE718903A838468A8B325B80962F9B8C4F18FCBLREML509MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

=A1=B0I am not aware of any IPR= that applies to this draft=A1=B1.

 

Regards,

Dhruv

 

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC= =FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC= =BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3= =F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB

=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2= =D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE= =D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1= =A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0

=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4= =FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7= =BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1= =BE=D3=CA=BC=FE=A3=A1

This e-mail and its attachments contain conf= idential information from HUAWEI, which is intended only for the person or = entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited= to, total or partial disclosure, reproduction, or dissemination) by person= s other than the intended

recipient(s) is prohibited. If you receive t= his e-mail in error, please notify the sender by phone or email immediately= and delete it!

 

From: Pce [mai= lto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 26 January 2016 19:31
To: draft-ietf-pce-iro-update@ietf.org
Cc: pce@ietf.org; pce-chairs@ietf.org
Subject: [Pce] Last IPR check for draft-ietf-pce-iro-update

 

Dear authors (Dhruv!),

 

Please could you confirm (on th= e mailing list) whether you are aware of any IPR that applies to draft-ietf= -pce-iro-update, and if so, if it has been disclosed in compliance with IET= F IPR rules? (See RFCs 3979, 4879, 3669 and 5378 for more details.)  If you are not aware of any IPR that app= lies to this draft, please reply saying =A1=B0I am not aware of any IPR tha= t applies to this draft=A1=B1.

 

Best regards,=

 

Jon, JP & Julien=

 

--_000_23CE718903A838468A8B325B80962F9B8C4F18FCBLREML509MBXchi_-- From nobody Wed Jan 27 06:35:31 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98F81B2EA8; Wed, 27 Jan 2016 06:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkv8EKsF85fL; Wed, 27 Jan 2016 06:22:52 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E21F1B2E80; Wed, 27 Jan 2016 06:22:52 -0800 (PST) Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by BLUPR05MB706.namprd05.prod.outlook.com (10.141.207.13) with Microsoft SMTP Server (TLS) id 15.1.390.13; Wed, 27 Jan 2016 14:22:29 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0390.013; Wed, 27 Jan 2016 14:22:29 +0000 From: Gert Grammel To: "Gabriele Maria Galimberti (ggalimbe)" Thread-Topic: [CCAMP] Response to Broadband Forum Liaison - Achieving Packet Network Optimization using DWDM Interfaces 18-Dec-2016 Thread-Index: AQHRV5+h86idbV8GX0GOyTt5wCjpXZ8PbQ4L Date: Wed, 27 Jan 2016 14:22:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-originating-ip: [80.187.99.190] x-microsoft-exchange-diagnostics: 1; BLUPR05MB706; 5:iir7Uc5yYtujBSfhi9gGT+Cib1e28Hk459RT7Zo21AsPE/EJUFHagJ6RrVBqjxsMaFFt3/DiGbFaosMlToyVP9i8Z9uY8UJBb0hZbKLdLtwPLWAcvnlkLIFGuJjFpoeDRMuJDmjsmIgKb6xt5mmdqQ==; 24:kZInaIDAT+EH0KmSnwkitgk9Nwv4mJmlMPXqUWF055wKNHMlkIiq26XNfQ5bkajVr7EV7cxwkzgw6wb4PnewgRJGqvHzk+WbkrxmApwRPdg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB706; x-ms-office365-filtering-correlation-id: 4922eaaa-2c45-4356-9327-08d3272549d1 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415267)(102615245)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR05MB706; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB706; x-forefront-prvs: 0834BAF534 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(85664002)(24454002)(51914003)(53434003)(164054003)(377454003)(53754006)(189002)(199003)(15975445007)(5001960100002)(561944003)(54356999)(3846002)(2950100001)(4001430100002)(1220700001)(77096005)(1096002)(102836003)(2900100001)(107886002)(11100500001)(6116002)(82746002)(105586002)(81156007)(106356001)(110136002)(189998001)(3470700001)(106116001)(5008740100001)(101416001)(5002640100001)(19580395003)(586003)(66066001)(83716003)(50986999)(99286002)(33656002)(97736004)(76176999)(122556002)(230783001)(2906002)(87936001)(10400500002)(4326007)(99936001)(19580405001)(36756003)(92566002)(3280700002)(19617315012)(16236675004)(5004730100002)(86362001)(40100003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB706; H:CY1PR0501MB1609.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: multipart/related; boundary="_004_D074283377444628AB253878CBB69481junipernet_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2016 14:22:29.3554 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB706 Archived-At: X-Mailman-Approved-At: Wed, 27 Jan 2016 06:35:30 -0800 Cc: "ccamp@ietf.org" , "jpv@cisco.com" , "teas@ietf.org" , "pce@ietf.org" , David Sinicrope , Vishnu Pavan Beeram Subject: Re: [Pce] [CCAMP] Response to Broadband Forum Liaison - Achieving Packet Network Optimization using DWDM Interfaces 18-Dec-2016 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 14:22:58 -0000 --_004_D074283377444628AB253878CBB69481junipernet_ Content-Type: multipart/alternative; boundary="_000_D074283377444628AB253878CBB69481junipernet_" --_000_D074283377444628AB253878CBB69481junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gabriele, David, My preference would be to let BBF decide upon the scope of their work. So w= hether BBF wants to deal with Fiber Channel should be their choice. In line= with that thought, the physical composition of the architecture BBF wants = to look at shouldn't concern ccamp a whole lot. In my view we should try to provide some guidance on how to deal with the t= ransition from SNMP to yang in general and the control of optical interface= s in particular. External bodies like to reference RFCs, but on the ccamp end there are stil= l gaps: 1) existing SNMP RFCs do not cover the provisioning of the colored side of = an optical interface 2) SNMP as means of provisioning is discouraged 3) yang models to provision interfaces are lingering in individual draft st= atus since a while 4) other yang models that may be of interest to BBF are not in RFC status y= et So perhaps we should respond with a framework draft as discussed last IETF = to outline what we are committed to work on so that BBF can built upon it. Gert Sent from my Apple ][ On 25 Jan 2016, at 19:39, Gabriele Maria Galimberti (ggalimbe) > wrote: Hi David, Thanks for the reminder. I have few general notes on the document. * I would NOT limit the Client interface (Dd) to Ethernet or OTN. Also= Data center interfaces should be supported (like Fiber Channel). * In WT-319 Part-B is mentioned the fully separated solution while in T= R-319 the fully integrated DWDM interface in the client equipment. * The two solutions can signal on the UNI interface different servic= e request (Ethernet or OTN in the former, optical channel in the latter) * I'd like to see also the Hybrid solution to be supported (i.e. Ful= ly integrated on one side of the circuit and fully separated on the other s= ide). * Although are not yet RFC there are some draft proposal to manage the = Protection and the diverse path. * Support of LSP SRLG collection in the core and sharing the list to= the Edge (SRLG RRO) * XRO to exclude critical elements on the network when signalling LS= P (at node link and SRLG level) carrying protecting traffic. * Diverse path signalling based on LSP-id * I'd discourage the use of SNMP for the network provisioning and deplo= yment. Best Regards, Gabriele <273031C1-0F11-4D42-9226-D16B7CB14162[8].png> Gabriele Galimberti Principal Engineer Cisco Photonics Srl via S.Maria Molgora, 48 C 20871 - Vimercate (MB) Italy www.cisco.com/global/IT/ ggalimbe@cisco.com Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049 From: CCAMP > on beha= lf of David Sinicrope > Date: Monday, January 25, 2016 5:53 PM To: "ccamp@ietf.org" >, "pce@ietf.org" >, "teas@ietf.org" > Cc: "jpv@cisco.com" >, "vbeeram@juniper.net" >, "akatlas@gmail.com" > Subject: [CCAMP] Response to Broadband Forum Liaison - Achieving Packet Net= work Optimization using DWDM Interfaces 18-Dec-2016 Hi All, Just a reminder to the CCAMP, PCE and TEAS WGs that we still have https://datatracker.ietf.org/liaison/1449/ requesting a response. Please finalize and send your comments to the respective WG Chairs if you h= aven't already. We will coordinate a joint WG response. Thanks, Dave _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_D074283377444628AB253878CBB69481junipernet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Gabriele, David,

My preference would be to let BBF decide upo= n the scope of their work. So whether BBF wants to deal with Fiber Channel = should be their choice. In line with that thought, the physical composition= of the architecture BBF wants to look at shouldn't  concern ccamp a whole lot.

In my view we should try to provide some gui= dance on how to deal with the transition from SNMP to yang in general and t= he control of optical interfaces in particular.

External bodies like to reference RFCs, but = on the ccamp end there are still gaps: 
1) existing SNMP RFCs do not cover the provi= sioning of the colored side of an optical interface
2) SNMP as means of provisioning is discoura= ged
3) yang models to provision interfaces are l= ingering in individual draft status since a while
4) other yang models that may be of interest= to BBF are not in RFC status yet

So perhaps we should respond with a framewor= k draft as discussed last IETF to outline what we are committed to work on = so that BBF can built upon it.

Gert 



Sent from my Apple ][
Hi David, 
Thanks for the reminder.

I have few general notes on the document.
  • I would NOT limit the Client interface (Dd) to Ethernet or OTN.  A= lso Data center interfaces should be supported (like Fiber Channel).
    • In WT-319 Part-B is mentioned the fully separated solution while in TR-31= 9 the fully integrated DWDM interface in the client equipment.
    • The two solutions can signal on the UNI interface different service req= uest (Ethernet or OTN in the former, optical channel in the latter)
      • I'd like to see also the Hybrid solution to be supported (i.e. Fully integ= rated on one side of the circuit and fully separated on the other side).
  • Although are not yet RFC there are some draft proposal to manage t= he Protection and the diverse path.
    • Support of LSP SRLG collection in the core and sharing the list to the = Edge  (SRLG RRO)
    • XRO to exclude critical elements on the netwo= rk when signalling LSP (at node link and SRLG level) carrying protecting tr= affic.
    • Diverse path signalling based on LSP-id
  • I'd discourage the use of SNMP for the network provisioning and de= ployment.

Best Regards, 

Gabriele




Gabriele Galimberti Principal Engineer
Cisco Photonics Srl



via S.Maria Molgora, 48 C

20871 - Vimercate (MB)
Italy
www.cisco.com/global/IT/


ggalimbe@cisco.c= om
Phone :+39 039 2091462+39 335 7481947
Fax :+39 039 2092049













From: CCAMP <ccamp-bounces@ietf.org> on behalf of David Si= nicrope <david.sinicrope= @ericsson.com>
Date: Monday, January 25, 2016 5:53= PM
To: "ccamp@ietf.org" <cca= mp@ietf.org>, "pce@ietf.org= " <pce@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Cc: "jpv@cisco.com" <jpv@ci= sco.com>, "vbeeram@junip= er.net" <vbeeram@juniper= .net>, "akatlas@gmail.com" <= ;akatlas@gmail.com>
Subject: [CCAMP] Response to Broadb= and Forum Liaison - Achieving Packet Network Optimization using DWDM Interf= aces 18-Dec-2016

--_000_D074283377444628AB253878CBB69481junipernet_-- --_004_D074283377444628AB253878CBB69481junipernet_ Content-Type: image/png; name="273031C1-0F11-4D42-9226-D16B7CB14162[8].png" Content-Description: 273031C1-0F11-4D42-9226-D16B7CB14162[8].png Content-Disposition: inline; filename="273031C1-0F11-4D42-9226-D16B7CB14162[8].png"; size=1632; creation-date="Mon, 25 Jan 2016 18:38:49 GMT"; modification-date="Mon, 25 Jan 2016 18:38:49 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAG4AAABJCAIAAABTkIQiAAAGJ0lEQVR4nO2be0xTVxzHv30gcHk5 bRmKyMCJrhDsNi0xzldikE2dZr5mSEnm/poylxi3ZAuOkhhjspANZ0zUhT9GyNwMzoHDSHD4GEGI QGtGAQ10iEyg1a1Cy50tdH9cd7kqRVp+5WHO54/m9HDOl3M+nHvP6W2QeTweMCiQT/YAXhyYSjKY SjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjKYSjImQWXLnXvTOt8bE62yxtz2 XfnvNea2aZo/CsoJ/n0lVxsqG5sBLNcsmI75ozDRq1KYp/A6HfNHgW07ZDCVZDCVZARQpa+HkqnW 3lcCpdLXQ8lUa+8HgToM+XoomWrt/SBQq9LXQ8lUa+8HBCqn+wdBqvzxqpzuHwQJ88d7r/yooBhA ZWOz8cSX4x/NtM5n50oymEoymEoyxqty3euvia9jqafKCXS+H4x329m66g3xdSz1VDmBzveD8apc rlnwUji3eP6cMdZT5QQ63w8I7pXexjFi/SgXlE85E5DvKxP9hQThBTUp+aMgm/h/Nmm5c49qIUxK vjcmQeWLCjtXksFUkhHYbeevy5fF8tw1a8g7jqWZ32PwlYCodPN8x5Wrt4qL79fXO81NADhNctL2 bTqDwTM4KFMoANQZDMa8PADa3NxlBw8KlQBsLa2N3x7ruVwldnx5zdoVhlxOrRoxn7daAYSo1Unb t2kPfDojPExs1lVb13Wh3FJRaa+plqujI15dmJC+LvH9XarFiwIxa3qVbp5vOHnK+Mk+aaXT3HS3 PlEHeAAZgCf3useVgK2l9dLuD+011dKOFnPTss8OcFBJ828eOjRk7R1uZu29W5+YMjAgqmy7WFGz f7/w9wAwZO21W3uNNdW3z/2y9puvA7E86VU+5TFsiVbJhUntAIBM9mxHz+Bge0WF2DJOn6WMiATw oLFxBje81hpOnmr4/Au5sx8AgoLCNMlKLsx+o04a1VVbdyljvbRGro4W1DtMxt/2ZmeUlJCvTWKV TqvtdmGh+FZbcDQxPR2AvaPjkd2O/1ffiLgGeHvrLaGs2rhpdX6+cFE7rbbgmVHSfMGjXB2dmpMj zVeGhgJw87z5+yIxNmFPdvL2rQCazpRYTp2Ay+U0N7Wf/kFlMFDOnFxlR1WVw2QUytqCo7p9Hwtl cQmI98QRhhIaEqWeLZRt58uqDXnzVq+ak6abGR8vzf/3TwsABAWl5uQ8ne/xAOjv6bEcPybUJ+zJ Xpv/lTIkBMDM5BR338POou8BWCoqddQqiQ9Dfd3dYjll1y7fhqJQxL79jvjWcvzYtZ07ft28pfmn M9J8t9MJQMlxI+TLZAAc3T1ihSZLL3gEwKlVSZmZCAoCwHfTf/UWwHOlcLn5xNylb264XqvauEms cZiM13buaLtYQZIfUIhVRsTEiOW28nJfu8sUitg03ZZzP2+4XqvNzRXr20vLPIODQr6S4wC4nU5v +cFRUWK560K50BHAo35He2kZXC4AyshIX8f2XIhVqlNTw5ZohXLD4cNtFyucVpvTarO1tHbV1gEQ JzYCHo+b5908LwNi03S63Fxxebr7Hg4NDQn5wa8kAIDL9Wy+m+cBRM6bF6fPEjoa8/JaSs46rbZ/ OjqMhYWdxY+3o+gVb9FOHOTbjmrxooVbNhtNRgAOk/FSxnpBx0BnZ2hc3HtlpR7vm/ig2327tOzu latRi5IA4MF92/myx6OMiJTL5cP55ia4XA6TsUqvn5WWJuZnFBYqQ0JmhIct2f2BsL0AuLZzx83l KwDYb9QJSzI4IVGTpaedOAJxrkzZm32/3SLORNQRGhc33MjL46g+c5O4+YpwmmRNll7c+oX8jpKz cmf/kLV3xPyYlSu1BUfF4630VBuckKg7ciQ2Tefv/LxCr5JTq1bn5/+xdKnl9I/SOUTMj4eXJSlU yuVyzJr91I/i9FlJmZnSmUvz/zaZhDPmEBceMT9e3IjkCsWyvXsiYmKai4qGl3ZU1Jx3NydlZi5Y n0412SdmEdDnlX48SpB2eW6vKfU4gz36JYM9rySDqSSDqSSDqSSDqSSDqSSDqSSDqSSDqSSDqSSD qSSDqSSDqSSDqSSDqSTjP8P5+2z4huMfAAAAAElFTkSuQmCC --_004_D074283377444628AB253878CBB69481junipernet_-- From nobody Wed Jan 27 20:13:02 2016 Return-Path: X-Original-To: pce@ietf.org Delivered-To: pce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3371B2ED6; Wed, 27 Jan 2016 20:13:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160128041300.7667.92017.idtracker@ietfa.amsl.com> Date: Wed, 27 Jan 2016 20:13:00 -0800 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-iro-update-05.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 04:13:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Update to Include Route Object (IRO) specification in Path Computation Element communication Protocol (PCEP) Author : Dhruv Dhody Filename : draft-ietf-pce-iro-update-05.txt Pages : 7 Date : 2016-01-27 Abstract: During discussions of a document to provide a standard representation and encoding of Domain-Sequence within the Path Computation Element (PCE) communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs, it was determined that there was a need for clarification with respect to the ordered nature of the Include Route Object (IRO). An informal survey was conducted to determine the state of current and planned implementation with respect to IRO ordering and handling of Loose bit (L bit). This document updates RFC 5440 regarding the IRO specification, based on the survey conclusion and recommendation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-iro-update/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-iro-update-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-iro-update-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 27 20:18:09 2016 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF0F1B328B; Wed, 27 Jan 2016 20:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.288 X-Spam-Level: * X-Spam-Status: No, score=1.288 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3HCWoi0fLYd; Wed, 27 Jan 2016 20:18:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93E41B3280; Wed, 27 Jan 2016 20:18:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDN91599; Thu, 28 Jan 2016 04:18:00 +0000 (GMT) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 28 Jan 2016 04:17:59 +0000 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.9]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0235.001; Thu, 28 Jan 2016 09:47:53 +0530 From: Dhruv Dhody To: Jonathan Hardwick , "draft-ietf-pce-iro-update@ietf.org" Thread-Topic: Shepherd's review of draft-ietf-pce-iro-update Thread-Index: AdFYSUYNKzAyfNvIRQqGxy0NqCHycAAk4LJQ Date: Thu, 28 Jan 2016 04:17:53 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C4F2E38@BLREML509-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.252] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C4F2E38BLREML509MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56A99679.0050, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.9, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b62cf2c60f7ef60c9259d54f6f88c075 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-iro-update X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 04:18:08 -0000 --_000_23CE718903A838468A8B325B80962F9B8C4F2E38BLREML509MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSm9uLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LiBTZWUgaW5saW5loa0NCg0KRnJvbTog UGNlIFttYWlsdG86cGNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb25hdGhhbiBI YXJkd2ljaw0KU2VudDogMjYgSmFudWFyeSAyMDE2IDIyOjUyDQpUbzogZHJhZnQtaWV0Zi1wY2Ut aXJvLXVwZGF0ZUBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1wY2UtaXJvLXVwZGF0ZUBpZXRm Lm9yZz4NCkNjOiBwY2VAaWV0Zi5vcmc8bWFpbHRvOnBjZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtQ Y2VdIFNoZXBoZXJkJ3MgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGNlLWlyby11cGRhdGUNCg0KSSBo YXZlIHBlcmZvcm1lZCBhIGRvY3VtZW50IHNoZXBoZXJkIHJldmlldyBvZiB0aGlzIGRyYWZ0LiAg SGVyZSBhcmUgbXkgY29tbWVudHMuICBQbGVhc2UgZmVlbCBmcmVlIHRvIGRpc2N1c3MuDQoNClRo ZSBkcmFmdCBtYWtlcyBhIGdvb2QgY2xhcmlmaWNhdGlvbiB0byBSRkMgNTQ0MCBhbmQgdGhlIGF1 dGhvciBoYXMgdGFrZW4gZ3JlYXQgY2FyZSB0byBjaGVjayB0aGUgaW1wYWN0IG9uIGV4aXN0aW5n IGltcGxlbWVudGF0aW9ucy4NCg0KVGhlIGRyYWZ0IHByb3Bvc2VzIHRvIGFkZCB0aGUgTCBiaXQg dG8gSVJPIHN1Ym9iamVjdHMuICBQcmlvciB0byB0aGlzIGRyYWZ0LCBpbXBsZW1lbnRhdGlvbnMg c2hvdWxkIGhhdmUgYmVlbiBzZXR0aW5nIHRoaXMgYml0IHRvIHplcm8gd2hlbiBzZW5kaW5nLCBh bmQgaWdub3JpbmcgaXQgb24gcmVjZWlwdC4gIEZvbGxvd2luZyB0aGlzIGRyYWZ0LCBhIHZhbHVl IG9mIHplcm8gaXMgbm93IHRvIGJlIGludGVycHJldGVkIGFzIGluZGljYXRpbmcgYSChsHN0cmlj dCBob3ChsSBpbiB0aGUgSVJPLiAgSG93ZXZlciwgYWNjb3JkaW5nIHRvIHRoZSBzdXJ2ZXksIHRo ZXJlIGFyZSBhdCBsZWFzdCB0d28gaW1wbGVtZW50YXRpb25zIHRoYXQgaW50ZXJwcmV0IElSTyBz dWJvYmplY3RzIGFzIGxvb3NlIGhvcHMuICBGcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHN1Y2gg aW1wbGVtZW50YXRpb25zLCB0aGlzIGlzIGEgbm9uLWJhY2t3YXJkcy1jb21wYXRpYmxlIGNoYW5n ZS4NCg0KSSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIGV4cGxhaW4gdGhlIGltcGFjdCBvbiBvcGVy YXRpb25zIGlmIGFuIGltcGxlbWVudGF0aW9uIGNvbmZvcm1pbmcgdG8gdGhpcyBkcmFmdCBpbnRl cndvcmtzIHdpdGggYW4gaW1wbGVtZW50YXRpb24gdGhhdCBkb2VzIG5vdC4gIEkgdGhpbmsgdGhl IGltcGFjdCBpcyBhcyBmb2xsb3dzLg0KDQoqICAgICAgICBJZiBhIG5vbi1jb25mb3JtaW5nIFBD QyBzZW5kcyBhbiBJUk8gdG8gYSBjb25mb3JtaW5nIFBDRSwgdGhlbiB0aGUgUENFIG1heSB1bmV4 cGVjdGVkbHkgZmFpbCB0byBmaW5kIGEgcGF0aCAoc2luY2UgdGhlIFBDQyB0aGlua3MgaXQgaXMg Z2l2aW5nIGxvb3NlIGhvcHMsIGJ1dCB0aGUgUENFIGludGVycHJldHMgdGhlbSBhcyBzdHJpY3Qg aG9wcykuDQoNCiogICAgICAgIElmIGEgY29uZm9ybWluZyBQQ0Mgc2VuZHMgYW4gSVJPIGNvbnRh aW5pbmcgc3RyaWN0IGhvcHMgdG8gYSBub24tY29uZm9ybWluZyBQQ0UsIHRoZW4gdGhlIFBDRSBt YXkgZXJyb25lb3VzbHkgcmV0dXJuIGEgcGF0aCB0aGF0IGRvZXMgbm90IGNvbXBseSB3aXRoIHRo ZSByZXF1ZXN0ZWQgc3RyaWN0IGhvcHMgKHNpbmNlIGl0IGludGVycHJldHMgdGhlbSBhbGwgYXMg bG9vc2UgaG9wcykuICBUaGUgUENDIHdvdWxkIGhhdmUgdG8gZG91YmxlLWNoZWNrIHRoZSByZXR1 cm5lZCBwYXRoIG9yIGVsc2UgaXQgbWF5IGVuZCB1cCB1c2luZyBhIHBhdGggd2l0aCB1bmludGVu ZGVkIGhvcHMgaW4gaXQuDQoNClRoZSBzZWNvbmQgaW1wYWN0IHNlZW1zIHdvcnNlIHRoYW4gdGhl IGZpcnN0LiAgSSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIG5vdGUgdGhlc2UgcG9zc2liaWxpdGll cyBpbiBhIG5ldyBzZWN0aW9uLCBhbmQgc2hvdWxkIFJFQ09NTUVORCB0aGF0IG5ldHdvcmsgb3Bl cmF0b3JzIGVuc3VyZSB0aGF0IGFsbCBQQ0VzIGluIHRoZWlyIG5ldHdvcmsgY29uZm9ybSB0byB0 aGlzIGRyYWZ0IGlmIHRoZXkgaW50ZW5kIHRvIHVzZSBJUk9zLiAgSSBkb26hr3QgdGhpbmsgdGhl IGltcGFjdCBpcyBjcml0aWNhbCBlbm91Z2ggdG8gd2FycmFudCBhZGRpbmcgYSBuZXcgY2FwYWJp bGl0eSB0byB0aGUgcHJvdG9jb2wgdG8gaW5kaWNhdGUgdGhpcyB1cGRhdGVkIGJlaGF2aW91ciwg YnV0IEkgd291bGQgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIGZlZWRiYWNrIGZyb20gYW55b25l IChwYXJ0aWN1bGFybHkgb3BlcmF0b3JzKSB3aG8gaXMgd29ycmllZCBieSB0aGlzLg0KDQpbRGhy dXZdOiBMdWNraWx5IHRoZXNlIGltcGxlbWVudGF0aW9ucyB3ZXJlIG5vdCChsHNoaXBwaW5nIHBy b2R1Y3ShsSwgc28gdGhlcmUgc2hvdWxkbqGvdCBiZSBhbnkgaW1wYWN0IG9uIGxpdmUgbmV0d29y a3MuDQpJIGhhdmUgYWRkZWQgYSBzZWN0aW9uIGRlc2NyaWJpbmcgdGhpcyBhbnl3YXlzLg0KDQpB cGFydCBmcm9tIHRoaXMsIHRoZSBkcmFmdCBsb29rcyBnb29kLiAgVGhlIGlkbml0cyB0b29sIHRo cm93cyB1cCBhIGhhbmRmdWwgb2Ygd2FybmluZ3MgqEMgcGxlYXNlIGZpeCBhcyBtYW55IG9mIHRo ZXNlIGFzIHlvdSBjYW4uDQoNCltEaHJ1dl06IERvbmUsIG9uZSBjb21tZW50IHJlZ2FyZGluZyB0 aGUgYm9pbGVycGxhdGUgaXMgcGVuZGluZyAoYnV0IHRoaXMgc2hvdWxkIG5vdCBibG9jayBwcm9n cmVzcyBvZiB0aGUgZHJhZnQpLg0KDQpJIGhhdmUgcG9zdGVkIGFuIHVwZGF0ZWQgdmVyc2lvbi4N Cg0KUmVnYXJkcywNCkRocnV2DQoNClRoYW5rcw0KSm9uDQqxvtPKvP68sMbkuL28/rqs09C7qs6q uavLvrXEsaPD3NDFz6KjrL32z97T2reiy824+MnPw+a12Na31tDB0LP2tcS49sjLu/LIutfpoaO9 +w0K1rnIzrrOxuTL+8jL0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5 wrahori01sahorvyyaK3oqOpsb7Tyrz+1tANCrXE0MXPoqGjyOe5+8T6tO3K1cHLsb7Tyrz+o6zH 68T6waK8tLXnu7C78tPKvP7NqNaqt6K8/sjLsqLJvrP9sb7Tyrz+o6ENClRoaXMgZS1tYWlsIGFu ZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBI VUFXRUksIHdoaWNoIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdo b3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRv LCB0b3RhbCBvciBwYXJ0aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5h dGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlz IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0 ZSBpdCENCg0K --_000_23CE718903A838468A8B325B80962F9B8C4F2E38BLREML509MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Thanks for your review. See inline=A1= =AD

 

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 26 January 2016 22:52
To: draft-ietf= -pce-iro-update@ietf.org
Cc: pce@ietf.org
Subject: [Pce] Shepherd's review of draft-ietf-pce-iro-update

 

I have performed a document she= pherd review of this draft.  Here are my comments.  Please feel f= ree to discuss.

 

The draft makes a good clarific= ation to RFC 5440 and the author has taken great care to check the impact o= n existing implementations.

 

The draft proposes to add the L= bit to IRO subobjects.  Prior to this draft, implementations should h= ave been setting this bit to zero when sending, and ignoring it on receipt.=   Following this draft, a value of zero is now to be interpreted as indicating a =A1=B0strict hop=A1=B1 in the IRO.&n= bsp; However, according to the survey, there are at least two implementatio= ns that interpret IRO subobjects as loose hops.  From the point of vie= w of such implementations, this is a non-backwards-compatible change.

 

I think the draft should explai= n the impact on operations if an implementation conforming to this draft in= terworks with an implementation that does not.  I think the impact is = as follows.

=A1=A4        If a non-conforming PCC sends an IRO to a confo= rming PCE, then the PCE may unexpectedly fail to find a path (since the PCC= thinks it is giving loose hops, but the PCE interprets them as strict hops= ).

=A1=A4        If a conforming PCC sends an IRO containing str= ict hops to a non-conforming PCE, then the PCE may erroneously return a pat= h that does not comply with the requested strict hops (since it interprets = them all as loose hops).  The PCC would have to double-check the returned path or else it may end up using a= path with unintended hops in it.

 

The second impact seems worse t= han the first.  I think the draft should note these possibilities in a= new section, and should RECOMMEND that network operators ensure that all P= CEs in their network conform to this draft if they intend to use IROs.  I don=A1=AFt think the impact is critica= l enough to warrant adding a new capability to the protocol to indicate thi= s updated behaviour, but I would be interested in hearing feedback from any= one (particularly operators) who is worried by this.

 

[Dhruv]: Luckily these implementation= s were not =A1=B0shipping product=A1=B1, so there shouldn=A1=AFt be any imp= act on live networks.  

I have added a section describing thi= s anyways.

 

Apart from this, the draft look= s good.  The idnits tool throws up a handful of warnings =A8C please f= ix as many of these as you can.

 

[Dhruv]: Done, one comment regarding = the boilerplate is pending (but this should not block progress of the draft= ).

 

I have posted an updated version.

 

Regards,

Dhruv

 

Thanks

Jon

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC= =FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC= =BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3= =F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB

=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2= =D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE= =D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1= =A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0

=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4= =FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7= =BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1= =BE=D3=CA=BC=FE=A3=A1

This e-mail and its attachments contain conf= idential information from HUAWEI, which is intended only for the person or = entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited= to, total or partial disclosure, reproduction, or dissemination) by person= s other than the intended

recipient(s) is prohibited. If you receive t= his e-mail in error, please notify the sender by phone or email immediately= and delete it!

 

--_000_23CE718903A838468A8B325B80962F9B8C4F2E38BLREML509MBXchi_--