From nobody Sun Aug 2 20:49:42 2015 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 7DC5F1B2BB8 for ; Sun, 2 Aug 2015 20:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 WGSdPI8VI9Lm for ; Sun, 2 Aug 2015 20:49:40 -0700 (PDT) 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 980711B2BB7 for ; Sun, 2 Aug 2015 20:49:39 -0700 (PDT) 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 BVT97648; Mon, 03 Aug 2015 03:49:38 +0000 (GMT) Received: from SZXEML434-HUB.china.huawei.com (10.82.67.225) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 3 Aug 2015 04:49:37 +0100 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.55]) by szxeml434-hub.china.huawei.com ([10.82.67.225]) with mapi id 14.03.0158.001; Mon, 3 Aug 2015 11:49:32 +0800 From: wangzitao To: "pce@ietf.org" Thread-Topic: update to the draft-wu-pce-discovery-pceps-support Thread-Index: AdDNn2eeOraisYYCQbuaEkdvdY4J1g== Date: Mon, 3 Aug 2015 03:49:32 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.62] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EAC5369Fszxeml501mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] update to the draft-wu-pce-discovery-pceps-support 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, 03 Aug 2015 03:49:41 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EAC5369Fszxeml501mbxchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Here is the update to draft-wu-pce-discovery-pceps-support: https://www.ietf.org/internet-drafts/draft-wu-pce-discovery-pceps-support-0= 4.txt The version number is v(-04). The diff is: https://www.ietf.org/rfcdiff?url2=3Ddraft-wu-pce-discovery-pceps-support-04 The main change is to remove MD-5 as new capability flag bits based on IETF= 93 Prague meeting discussion and make it completely compliant with RFC5440 and add a new section in the appendix to clarify why MD-5 Capability bit is= not required. Best Regards! -Michael --_000_E6BC9BBCBCACC246846FC685F9FF41EAC5369Fszxeml501mbxchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Here is the update to draft-wu-pce-= discovery-pceps-support:

https://www.ietf.org/internet-drafts/draft-wu-= pce-discovery-pceps-support-04.txt

The version number is v(-04).

The diff is:

https://www.iet= f.org/rfcdiff?url2=3Ddraft-wu-pce-discovery-pceps-support-04=

The main change is to remove MD-5 a= s new capability flag bits based on IETF 93 Prague meeting discussion and m= ake it completely compliant with RFC5440

and add a new section in the append= ix to clarify why MD-5 Capability bit is not required.<= /span>

Be= st Regards!

-M= ichael

--_000_E6BC9BBCBCACC246846FC685F9FF41EAC5369Fszxeml501mbxchina_-- From nobody Wed Aug 5 15:31:14 2015 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 078AF1A03AB for ; Wed, 5 Aug 2015 15:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Gp0M2FjjejtD for ; Wed, 5 Aug 2015 15:31:10 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB921A1A92 for ; Wed, 5 Aug 2015 15:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18961; q=dns/txt; s=iport; t=1438813870; x=1440023470; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=X0o/oNUl2sM4pVSJQwHyIL3Blzd56gsEcGSg559I5Ks=; b=N5skFyMWUyt4U4EatbPwwqmcsFN10V/Ex4Ze9+xWvxzeSScCoC5qa+Dw 376zF4W6obG6Vx5CzDWfP70I0l+Tv1hrpIdMaj6H8ohxuDeD5YZSBivQJ SYNxrqo44wEr31YiGKYNOcPIOyEM6VVRWzc6Fj9CCXYscRhBly75cTDpI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A0BQBDjsJV/4gNJK1bgk5NVGkGvQCHfQKBUDoSAQEBAQEBAYEKhCMBAQEELUwQAgEIDgMDAQIoBzIUCQgCBAENBYguzU8BAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0+EeBEHhCwFhWiME4MEAYdihHOZZiaDfW+BSIEEAQEB X-IronPort-AV: E=Sophos;i="5.15,620,1432598400"; d="scan'208,217";a="175657485" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP; 05 Aug 2015 22:31:09 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t75MV9tr005714 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Aug 2015 22:31:09 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 5 Aug 2015 17:31:08 -0500 Received: from xhc-aln-x04.cisco.com (173.36.12.78) by xch-rcd-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 5 Aug 2015 17:31:08 -0500 Received: from xmb-aln-x07.cisco.com ([169.254.2.62]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0248.002; Wed, 5 Aug 2015 17:31:08 -0500 From: "Rakesh Gandhi (rgandhi)" To: Luyuan Fang , Dhruv Dhody Thread-Topic: PCE Auto-bandwidth Draft Thread-Index: AQHQxJhgbZaQiqMgok6UMsPmFqioyp3zIVkggAsDDIA= Date: Wed, 5 Aug 2015 22:31:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [173.37.102.21] Content-Type: multipart/alternative; boundary="_000_D1E805CA6ADA8rgandhiciscocom_" MIME-Version: 1.0 Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] PCE Auto-bandwidth Draft 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, 05 Aug 2015 22:31:13 -0000 --_000_D1E805CA6ADA8rgandhiciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Luyuan for providing review comments on the draft-dhody-pce-state= ful-pce-auto-bandwidth. Adding PCE WG. Thanks again, Rakesh (for authors) From: Luyuan Fang > Date: Wednesday, 29 July, 2015 8:14 PM To: Rakesh Gandhi >, Dhruv Dhod= y > Cc: Ravi Singh > Subject: RE: PCE Auto-bandwidth Draft Hi Rakesh and all, Thanks for asking! Here is my feedback. In general, it is a very well written and very useful draft. I appreciate a= lot of the thoughtful operation considerations and detailed procedural/pro= tocol specifications throughout the document, very good work. Here are some comments: 1. On pg 8: "...With Auto-Bandwidth feature, the LSP bandwidth can be set to some arbitrary value (including zero) during initial setup time, and it will be periodically adjusted over time based on the actual bandwidth requirement...." I don't quite like to have initial BW set as arbitrary value "including zer= o". In theory, nothing wrong here. But in practice, operators planned the netwo= rk, they should have rough ideas what to expect. Reducing the churns when using auto-bandwidth is very important. I saw operator removed auto-bandwidth because seeing too= many churns per day. Of course, when that happens, it also means the network capacity p= lanning need to be revisited=85 I=92d suggest change "the LSP bandwidth can be set to some arbitrary value (including zero) during initial setup time, " to "the LSP b= andwidth can be set to arbitrary value, in practice, it can be operator expected value from the in= itial planning/design if known". Or something along the similar line. 2. On pg 9: "overflow count" is mentioned in Overflow-Threshold, should it be defined. Same for "underflow count"=85 3. Nice to see the flexibility and operation considerations, such as "Multiple bandwidth samples are collected every report-interval, and reported together to the PCE. To avoid reporting minor changes in real-time traffic, report-threshold is used, to suppress the sending of the collected samples during the report-interval. The collected samples are reported if at least one sample crosses the Report-Threshold (percentage or absolute value). " I like this. And I like the following as well, so to deal with traffic surge... "In order to accommodate sudden changes in the real-time traffic, report flow threshold is employed by pre-maturely expiry of the report-interval to report the unreported bandwidth samples collected so far." As well as the report reduction consideration is very nice. 4. One thought =96 PCE should also have ability to adjust the intervals depending on the traff= ic pattern. Some LSPs are rather less eventful, some encounter a lot of changes, so the= reporting and adjusting interval should also be able to change accordingly by the PCE. The draft can be very helpful to operators when implemented correctly, and = used correctly. Thanks, Luyuan --_000_D1E805CA6ADA8rgandhiciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7554DF71391184458076F78BE9D72313@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Thank you Luyuan for providing review comments on the draft-dhody= -pce-stateful-pce-auto-bandwidth.

Adding PCE WG.

Thanks again,

Rakesh (for authors)

From: Luyuan Fang <lufang@microsoft.com>
Date: Wednesday, 29 July, 2015 8:14= PM
To: Rakesh Gandhi <rgandhi@cisco.com>, Dhruv Dhody <dhruv.dhody@huawei.com>
Cc: Ravi Singh <ravis@juniper.net>
Subject: RE: PCE Auto-bandwidth Dra= ft

Hi Rakesh and all,

Thanks for asking! Here is my feed= back.

In general, it is a very well writ= ten and very useful draft. I appreciate a lot of the thoughtful operation c= onsiderations and detailed procedural/protocol specifications throughout the document, very good work. =

Here are some comments:=

On pg 8:

"...With Auto-Bandwidth featu= re, the LSP bandwidth can be set to some

arbitrary value (including zero) d= uring initial setup time, and it

will be periodically adjusted over= time based on the actual bandwidth

requirement...."

I don't quite like to have initial= BW set as arbitrary value "including zero".

In theory, nothing wrong here. But= in practice, operators planned the network, they should have

rough ideas what to expect. Reduci= ng the churns when using auto-bandwidth

is very important. I saw operator = removed auto-bandwidth because seeing too many churns

per day. Of course, when that happ= ens, it also means the network capacity planning need to be

revisited=85 I=92d suggest change = "the LSP bandwidth can be set to some

arbitrary value (including zero) d= uring initial setup time, " to "the LSP bandwidth can be set to

arbitrary value, in practice, it c= an be operator expected value from the initial planning/design

if known". Or something along= the similar line.

2. On pg 9:

"overflow count" is ment= ioned in Overflow-Threshold, should it be defined.

Same for "underflow count&quo= t;=85

3. Nice to see the flexibility and= operation considerations, such as

"Multiple

bandwidth samples are= collected every report-interval, and reported

together to the PCE.&= nbsp; To avoid reporting minor changes in real-time

traffic, report-thres= hold is used, to suppress the sending of the

collected samples dur= ing the report-interval. The collected samples

are reported if at le= ast one sample crosses the Report-Threshold

(percentage or absolu= te value). "

I like this.

And I like the following as well, = so to deal with traffic surge...

"In order to accommodate sudd= en

changes in the real-t= ime traffic, report flow threshold is employed

by pre-maturely expir= y of the report-interval to report the

unreported bandwidth = samples collected so far."

As well as the report reduction co= nsideration is very nice.

4. One thought =96

PCE should also have ability to ad= just the intervals depending on the traffic pattern.

Some LSPs are rather less eventful= , some encounter a lot of changes, so the reporting and adjusting

interval should also be able to ch= ange accordingly by the PCE.

The draft can be very helpful to o= perators when implemented correctly, and used correctly.<= /p>

Thanks,

Luyuan

--_000_D1E805CA6ADA8rgandhiciscocom_-- From nobody Sun Aug 9 20:18:37 2015 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 67FF41B32F2; Sun, 9 Aug 2015 20:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 F4c8Op2Cewy1; Sun, 9 Aug 2015 20:18:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 287D71B32EE; Sun, 9 Aug 2015 20:18:35 -0700 (PDT) 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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150810031835.25060.70888.idtracker@ietfa.amsl.com> Date: Sun, 09 Aug 2015 20:18:35 -0700 Archived-At: Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-06.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: Mon, 10 Aug 2015 03:18:36 -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 : PCEP Extensions for Segment Routing Authors : Siva Sivabalan Jan Medved Clarence Filsfils Edward Crabbe Victor Lopez Jeff Tantsura Wim Henderickx Jon Hardwick Filename : draft-ietf-pce-segment-routing-06.txt Pages : 21 Date : 2015-08-09 Abstract: Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by Link- State Interior Gateway Protocols (IGPs). A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as a PCC to request a path subject to certain constraint(s) and optimization criteria in SR networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pce-segment-routing-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-06 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 Aug 12 05:54:21 2015 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 A89C41B2D5D for ; Wed, 12 Aug 2015 05:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 HFwPFAegUxUn for ; Wed, 12 Aug 2015 05:54:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB381A88F3 for ; Wed, 12 Aug 2015 05:54:18 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4B90422C6D0; Wed, 12 Aug 2015 14:54:15 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 25FD6238048; Wed, 12 Aug 2015 14:54:15 +0200 (CEST) Received: from [10.193.71.204] (10.168.234.5) by OPEXCLILM22.corporate.adroot.infra.ftgroup (10.114.31.31) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 12 Aug 2015 14:54:14 +0200 Message-ID: <2308_1439384055_55CB41F7_2308_3368_1_55CB41F6.8070802@orange.com> Date: Wed, 12 Aug 2015 14:54:14 +0200 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.5] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.8.12.115715 Archived-At: Cc: "draft-ietf-pce-segment-routing@tools.ietf.org" , "pce@ietf.org" , "draft-ietf-pce-lsp-setup-type@tools.ietf.org" Subject: [Pce] New Early Allocation Request for draft-ietf-pce-lsp-setup-type and draft-ietf-pce-segment-routing 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, 12 Aug 2015 12:54:19 -0000 Dear IANA specialist, Following RFC 7120 process and with agreement from our AD (Deborah), we request early allocation of codepoints for the two following PCE WG's I-Ds: - draft-ietf-pce-lsp-setup-type-03, - draft-ietf-pce-segment-routing-06. Please note that: - There are recommended values in corresponding IANA sections (6 and 9, respectively); to avoid clashes with other work in progress, we hope that these suggestions are acceptable; - The authors are aware that the ("Path Type") sub-registry creation requested in the 1st I-D will be deferred until the document is approved, as well as the entry addition requested by the 2nd I-D; - This new request follows our previous discussion in [IANA #824532]. Thanks, JP & Julien, PCE WG co-chairs _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Fri Aug 21 02:23:11 2015 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 A79BE1A0264; Fri, 21 Aug 2015 02:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 XDvkq0KlMtqo; Fri, 21 Aug 2015 02:23:08 -0700 (PDT) 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 5F92F1A01BA; Fri, 21 Aug 2015 02:23:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAF40212; Fri, 21 Aug 2015 09:23:05 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 21 Aug 2015 10:23:03 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.64]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Fri, 21 Aug 2015 17:22:50 +0800 From: "Zhangxian (Xian)" To: Lou Berger Thread-Topic: comments on draft-minei-pce-association-group Thread-Index: AQHQyGFo8dFInO3Zt0STEV715n/9xJ4WPfCQ Date: Fri, 21 Aug 2015 09:22:49 +0000 Message-ID: References: <55B1FF09.8040100@labn.net> <55B61927.6080303@labn.net> In-Reply-To: <55B61927.6080303@labn.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: PCE WG List , "draft-minei-pce-association-group@ietf.org" Subject: Re: [Pce] comments on draft-minei-pce-association-group 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: Fri, 21 Aug 2015 09:23:10 -0000 SGksIExvdSwNCg0KICAgVGhhbmsgeW91IGZvciB0aGUgdXNlZnVsIGNvbW1lbnRzLiBMZXQgbWUg dHJ5IHRvIGV4cGxhaW4gdG8gc2VlIGlmIHdlIGNhbiBjb252ZXJnZSBiZWZvcmUgd2UgdXBkYXRp bmcgdGhlIGRyYWZ0Lg0KDQogICBMZXQgbWUgc3RhcnQgd2l0aCB0aGUgb2JqZWN0aXZlIG9mIHRo ZSBkcmFmdDogdG8gZGVmaW5lIGEgZ2VuZXJhbCBtZWNoYW5pc20gdGhhdCBzdXBwb3J0IExTUCBh c3NvY2lhdGlvbiB2aWEgUENFUC4gU28sIHdlIGNvbmZpbmUgb3Vyc2VsdmVzIHRvIGhhdmluZyBt aW5pbXVtL01VU1QtaGF2ZSBhdHRyaWJ1dGVzLCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGNhbiBi ZSBhZGRlZCBpbnRvIHRoZSBvcHRpb25hbCBUTFZzIGlmIG5lZWRlZCBhcyBwZXIgYXBwbGljYXRp b24uIA0KDQogICBOb3csIHRvIHlvdXIgY29tbWVudHM6IA0KDQo+ICAgICAxKSBJcyB0aGVyZSBh IHJlYXNvbiB0byBub3QgZm9sbG93IGFuZCBwcm92aWRlIHRoZSBmdWxsIGZ1bmN0aW9uDQo+ICAg ICBzdXBwb3J0ZWQgYnkgIFJTVlAgRXh0ZW5kZWQgQVNTT0NJQVRJT04gT2JqZWN0IFtSRkM2Nzgw XT8NCg0KW1hpYW5dOiBCeSBsb29raW5nIGF0IFJGQzY3ODAsIEkgdGhpbmsgdGhlIGZvbGxvd2lu ZyBjaGFuZ2VzIG1heSBiZSBuZWVkZWQgd2hlbiB1cGRhdGluZyBkcmFmdC1taW5laS1wY2UtYXNz b2NpYXRpb24tZ3JvdXA6DQpBKQlFeHRlbmRpbmcgdGhlIDQtYml0IGFzc29jaWF0aW9uIHR5cGUg dG8gMTYgYml0czsNCkIpCUN1cnJlbnRseSBhc3NvY2lhdGlvbiBJRCBpbiBkcmFmdC1taW5laS1w Y2UtYXNzb2NpYXRpb24tZ3JvdXAtMDIgaXMgMzIgYml0cyBidXQgaW4gUkZDNjc4MCAxNiBiaXRz LiBTbywgdGhpcyBjYW4gYmUgY292ZXJlZCwgdGh1cyBubyBuZWVkIGZvciByZXZpc2lvbjsNCkMp CUdsb2JhbCBBc3NvY2lhdGlvbiBzb3VyY2UgYW5kIGV4dGVuZGVkIGFzc29jaWF0aW9uIElEOiBp cyB0aGlzIHNvbWV0aGluZyBiYXNpYz8gT3IgY2FuIGl0IGJlIGFkZGVkIGludG8gdGhlIG9wdGlv bmFsIFRMVnMgYXMgcGVyIGFwcGxpY2F0aW9uPyBPcGVuIHRvIHlvdXIgc3VnZ2VzdGlvbiBvbiB0 aGlzIHBvaW50IGFuZCBpdCB3b3VsZCBiZSBnb29kIHRvIHNoYXJlIHlvdXIgdGhvdWdodHMgYmVo aW5kLg0KDQo+ICAgICAyKSBGb3IgQXNzb2NpYXRpb24gU291cmNlIGZpZWxkIEkgc3VnZ2VzdDoN Cj4gICAgICAgICBPTEQNCj4gICAgICAgIEFuIElQdjQgb3IgSVB2NiBhZGRyZXNzLCB3aGljaA0K PiAgICAgICAgaXMgIGFzc29jaWF0ZWQgIHRvIHRoZSBQQ0UgcGVlciB0aGF0IG9yaWdpbmF0ZWQg dGhlIGFzc29jaWF0aW9uLg0KPiAgICAgICAgTkVXDQo+ICAgICAgICBBbiBJUHY0IG9yIElQdjYg YWRkcmVzcywgd2hpY2gNCj4gICAgICAgIGlkZW50aWZpZXMgdGhlIG9yaWdpbmF0b3Igb2YgdGhl IGFzc29jaWF0aW9uDQoNCltYaWFuXTogVGhpcyBpcyB0aGUgcGFydCBJIGRvIG5vdCByZWFsbHkg YWdyZWUgd2l0aC4gQXQgdGhlIG1vbWVudCwgd2UgdXNlIHRoaXMgZmllbGQgYXMgYSBkaWZmZXJl bnRpYXRvciBmb3IgZXJyb3IgaGFuZGxpbmcuIFRvIGJlIG1vcmUgc3BlY2lmaWMsIGRlcGVuZGlu ZyBvbiB3aGV0aGVyIHRoZSBhc3NvY2lhdGlvbiBpcyBvcmlnaW5hdGVkIGJ5IFBDQyBvciBQQ0Us IHdlIG5lZWQgdG8gZGVjaWRlIHdoZXRoZXIgdG8gY2xlYXIgdXAgdGhlIGFzc29jaWF0aW9uIGlu Zm9ybWF0aW9uLiBSZWxheGluZyB0aGlzIFBDRVAgb2JqZWN0IGZpZWxkIG1lc3NlcyB1cCB3aXRo IHRoZSBlcnJvciBoYW5kbGluZyB3ZSBhcmUgd29ya2luZyBvbi4gQW5vdGhlciBwb2ludCBpczog Y291bGQgeW91IGFsc28gZ2l2ZSBleGFtcGxlcyB3aGVyZSB0aGUgb3JpZ2luYXRvciBpcyBub3Qg YSBQQ0UgcGVlciwgYnV0IGl0IHdpbGwgbmVlZCB0byB1c2UgUENFUCBmb3IgY29udmV5aW5nIHN1 Y2ggaW5mb3JtYXRpb24/DQoNCkNoZWVycywNClhpYW4gJiBJbmENCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSAN ClNlbnQ6IDIwMTXlubQ35pyIMjfml6UgMTk6NDMNClRvOiBJbmEgTWluZWkNCkNjOiBkcmFmdC1t aW5laS1wY2UtYXNzb2NpYXRpb24tZ3JvdXBAaWV0Zi5vcmc7IFBDRSBXRyBMaXN0DQpTdWJqZWN0 OiBSZTogY29tbWVudHMgb24gZHJhZnQtbWluZWktcGNlLWFzc29jaWF0aW9uLWdyb3VwDQoNCkZ1 bmN0aW9uLg0KDQogLS0gYnV0IGVuY29kaW5nIGlzIGZpbmUgdG9vIChhbmQgd2h5IG5vdD8pLi4u DQoNCkxvdQ0KT24gMDcvMjYvMjAxNSAwOToxOSBBTSwgSW5hIE1pbmVpIHdyb3RlOg0KPiBMb3Us IA0KPiANCj4gVGhhbmsgeW91IGZvciB0aGUgZmVlZGJhY2suIENhbiB5b3UgY2xhcmlmeSB0aGUg Zmlyc3QgY29tbWVudCBhYm91dA0KPiByZXVzZSBvZiB0aGUgZXh0ZW5kZWQgYXNzb2NpYXRpb24g b2JqZWN0IGZyb20gUkZDNjc4MCwgYXJlIHlvdSBhc2tpbmcNCj4gYWJvdXQgdGhlIG9iamVjdCBl bmNvZGluZyBvciBhYm91dCB0aGUgZnVuY3Rpb24/IA0KPiANCj4gSW5hIA0KPiANCj4gT24gRnJp LCBKdWwgMjQsIDIwMTUgYXQgMjowMiBBTSwgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldA0K PiA8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+PiB3cm90ZToNCj4gDQo+ICAgICBBdXRob3JzLA0K PiAgICAgVXNlZnVsIGRyYWZ0ICYgYWRkaXRpb25hbCBmdW5jdGlvbi4gIEkgaGF2ZSB0d28gY29t bWVudHM6DQo+IA0KPiAgICAgMSkgSXMgdGhlcmUgYSByZWFzb24gdG8gbm90IGZvbGxvdyBhbmQg cHJvdmlkZSB0aGUgZnVsbCBmdW5jdGlvbg0KPiAgICAgc3VwcG9ydGVkIGJ5ICBSU1ZQIEV4dGVu ZGVkIEFTU09DSUFUSU9OIE9iamVjdCBbUkZDNjc4MF0/DQo+IA0KPiAgICAgMikgRm9yIEFzc29j aWF0aW9uIFNvdXJjZSBmaWVsZCBJIHN1Z2dlc3Q6DQo+ICAgICAgICAgT0xEDQo+ICAgICAgICBB biBJUHY0IG9yIElQdjYgYWRkcmVzcywgd2hpY2gNCj4gICAgICAgIGlzICBhc3NvY2lhdGVkICB0 byB0aGUgUENFIHBlZXIgdGhhdCBvcmlnaW5hdGVkIHRoZSBhc3NvY2lhdGlvbi4NCj4gICAgICAg IE5FVw0KPiAgICAgICAgQW4gSVB2NCBvciBJUHY2IGFkZHJlc3MsIHdoaWNoDQo+ICAgICAgICBp ZGVudGlmaWVzIHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBhc3NvY2lhdGlvbg0KPiANCj4gICAgIFRo YW5rcywNCj4gICAgIExvdQ0KPiANCj4gDQoNCg== From nobody Sun Aug 23 22:04:11 2015 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 7AF6D1A8F39; Sun, 23 Aug 2015 22:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.21 X-Spam-Level: X-Spam-Status: No, score=-5.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 QiCn8jNuYs7V; Sun, 23 Aug 2015 22:03:59 -0700 (PDT) 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 A783B1A8BC3; Sun, 23 Aug 2015 22:03:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAI15367; Mon, 24 Aug 2015 05:03:50 +0000 (GMT) Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 24 Aug 2015 06:03:49 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0235.001; Sun, 23 Aug 2015 22:03:42 -0700 From: Leeyoung To: TEAS WG , "ccamp@ietf.org" , "pce@ietf.org" , "sdn@irtf.org" Thread-Topic: IEEE NetSoft 2016 Conference on Network Softwarization, Seoul, Korea Thread-Index: AQHQ3io+lpNpx0+QFUyD0VhznvTfGQ== Date: Mon, 24 Aug 2015 05:03:41 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729D0EE27@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.161] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Pce] IEEE NetSoft 2016 Conference on Network Softwarization, Seoul, Korea 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, 24 Aug 2015 05:04:01 -0000 SGkgQWxsLA0KDQpUaGlzIGNvbmZlcmVuY2UgbWF5IGJlIHJlbGV2YW50IHRvIHlvdXIgV0cgYWN0 aXZpdGllcy4gQ2hlY2sgaXQgb3V0IQ0KDQpCZXN0IHJlZ2FyZHMsDQpZb3VuZw0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KMm5kIElFRUUgQ09ORkVSRU5DRSBPTiBORVRXT1JLIFNPRlRXQVJJWkFUSU9OIC0gTmV0U29m dCAyMDE2DQpTb2Z0d2FyaXphdGlvbiBvZiBOZXR3b3JrcywgQ2xvdWRzIGFuZCBJbnRlcm5ldCBv ZiBUaGluZ3MNClNFT1VMLCBLT1JFQQ0KSnVuZSA2LTEwLCAyMDE2DQpodHRwOi8vd3d3Lm5ldHNv ZnQyMDE2Lm9yZw0KDQpDQUxMIEZPUiBQQVBFUlMNClRoZSBJRUVFIEludGVybmF0aW9uYWwgQ29u ZmVyZW5jZSBvbiBOZXR3b3JrIFNvZnR3YXJpemF0aW9uIChOZXRTb2Z0IA0KMjAxNikgd2lsbCBi ZSBoZWxkIGluIGJlYXV0aWZ1bCBTZW91bCwgS29yZWEuIE5ldFNvZnQgMjAxNiBidWlsZHMgDQpm dXJ0aGVyIG9uIHRoZSBzdWNjZXNzZnVsIGZpcnN0IGVkaXRpb24sIGhlbGQgaW4gTG9uZG9uLCBV SyBpbiBBcHJpbCANCjIwMTUgYW5kIGlzIHRoZSBmbGFnc2hpcCBldmVudCBlc3RhYmxpc2hlZCBh cyBwYXJ0IG9mIHRoZSBJRUVFIA0KU29mdHdhcmUtRGVmaW5lZCBOZXR3b3JrcyAoU0ROKSBJbml0 aWF0aXZlIG9mIHRoZSBJRUVFIEZ1dHVyZSBEaXJlY3Rpb25zIA0KQ29tbWl0dGVlLiBUaGlzIGNy b3NzLXNvY2lldGllc+KAmSBJbml0aWF0aXZlIGFpbXMgYXQgY3JlYXRpbmcgdGhlIA0KY29uZGl0 aW9ucyBmb3IgYSBwcmUtaW5kdXN0cmlhbCBleHBsb2l0YXRpb24gYW5kIGFkb3B0aW9uIG9mIFNE Ti9ORlYgDQpwYXJhZGlnbXMgaW4gVGVsZWNvbW11bmljYXRpb25zIGFuZCBJQ1QgZWNvc3lzdGVt cywgdGhyb3VnaCBhIHdvcmxkd2lkZSANCmNvb3BlcmF0aW9uIG9mIGxlYWRpbmcgdGVjaG5pY2Fs IGV4cGVydHMuIEluIHBhcnRpY3VsYXIsIHRoZSB2aXNpb24gb2YgDQp0aGUgSUVFRSBTRE4gSW5p dGlhdGl2ZSBpcyB0aGF0IFNETiBhbmQgTkZWIGFyZSBwYXJ0IG9mIGEgd2lkZXIgc3lzdGVtaWMg DQp0cmVuZCwgY2FsbGVkIE5ldHdvcmsgU29mdHdhcml6YXRpb24sIGltcGFjdGluZyBib3RoIG5l dHdvcmsgYW5kIHNlcnZpY2UgDQpwbGF0Zm9ybXMuIEluIGZhY3QsIHRoZSBleHBsb2l0YXRpb24g b2YgaGlnaCBsZXZlbHMgb2YgYXV0b21hdGlvbiwgDQppbmNyZWFzZWQgZmxleGliaWxpdHkgYW5k IHByb2dyYW1tYWJpbGl0eSBhbGxvd3MgcmVpbnZlbnRpbmcgZnV0dXJlIA0KbmV0d29yayBhbmQg Y2xvdWQgYXJjaGl0ZWN0dXJlcywgYWNjZWxlcmF0aW5nIHNlcnZpY2UgZGVwbG95bWVudCBhbmQg DQpmYWNpbGl0YXRpbmcgaW5mcmFzdHJ1Y3R1cmUgbWFuYWdlbWVudC4gTmV0U29mdCBpcyB0aGUg cHJpbWFyeSBJRUVFIA0KZm9ydW0gZm9yIHB1YmxpY2F0aW9uIGFuZCB0ZWNobmljYWwgZXhjaGFu Z2Ugb2YgdGhlIGxhdGVzdCByZXNlYXJjaCBhbmQgDQppbm5vdmF0aW9uIHJlc3VsdHMgaW4gdGhp cyBjaGFsbGVuZ2luZyBhcmVhLg0KDQpUT1BJQ1MgT0YgSU5URVJFU1QNCkF1dGhvcnMgYXJlIGlu dml0ZWQgdG8gc3VibWl0IHBhcGVycyB0aGF0IGZhbGwgaW50byB0aGUgYXJlYSBvZiANCnNvZnR3 YXJlLWRlZmluZWQgYW5kIHZpcnR1YWxpemVkIGluZnJhc3RydWN0dXJlcy4NClRvcGljcyBvZiBp bnRlcmVzdCBpbmNsdWRlLCBidXQgYXJlIG5vdCBsaW1pdGVkIHRvLCB0aGUgZm9sbG93aW5nOg0K 4oCiIEFQSXMsIHByb3RvY29scyBhbmQgbGFuZ3VhZ2VzIGZvciBwcm9ncmFtbWFibGUgbmV0d29y a3MgYW5kIFNESSANCihTb2Z0d2FyZS1EZWZpbmVkIEluZnJhc3RydWN0dXJlcykNCuKAoiBBYnN0 cmFjdGlvbnMgYW5kIFZpcnR1YWxpemF0aW9uIG9mIHJlc291cmNlcywgc2VydmljZXMgYW5kIGZ1 bmN0aW9ucyANCmluIFNETiBhbmQgTkZWDQrigKIgUmVzb3VyY2UgbWFuYWdlbWVudCBhbmQgT3Jj aGVzdHJhdGlvbiBmb3IgU0ROL05GVi1iYXNlZCBzeXN0ZW1zDQrigKIgTW9kZWxpbmcsIHJlcHJl c2VudGF0aW9uLCBjb21wb3NpdGlvbiBhbGdvcml0aG1zLCBhbmQgZGVwbG95bWVudCBmb3IgDQpT ZXJ2aWNlIEZ1bmN0aW9uIENoYWlucw0K4oCiIEVmZmljaWVudCBuZXR3b3JrIGFuZCBzZXJ2aWNl IG1vbml0b3JpbmcgZm9yIFNETi9ORlYNCuKAoiBUcmFuc2l0aW9uIHN0cmF0ZWdpZXMgU2VudCBm cm9tIG15IGlQaG9uZQ0K4oCiIE1hbmFnZW1lbnQgb2YgZmVkZXJhdGVkIFNETi9ORlYgaW5mcmFz dHJ1Y3R1cmVzDQrigKIgRW5lcmd5IGVmZmljaWVudCBhbmQgZ3JlZW4gU0RJDQrigKIgVHJhZmZp YyBFbmdpbmVlcmluZyBhbmQgUW9TL1FvRSBpbiBTRE4vTkZWDQrigKIgSW50ZXJvcGVyYWJpbGl0 eSBvZiBTREkgd2l0aCBMZWdhY3kgSW5mcmFzdHJ1Y3R1cmVzDQrigKIgQ2VudHJhbGl6ZWQgdnMg RGlzdHJpYnV0ZWQgY29udHJvbCBvZiBTRE4vTkZWLWJhc2VkIHN5c3RlbXMNCuKAoiBQb2xpY3kt YmFzZWQgbWFuYWdlbWVudCBpbiBTRE4vTkZWDQrigKIgTmV0d29yayBTb2Z0d2FyaXphdGlvbiBm b3IgNUcNCuKAoiBTb2Z0d2FyaXplZCBlZGdlIGNsb3VkIGluZnJhc3RydWN0dXJlcw0K4oCiIFNv ZnR3YXJpemVkIHBsYXRmb3JtcyBmb3IgSW50ZXJuZXQtb2YtVGhpbmdzIChJb1QpDQrigKIgU0RO IHN3aXRjaC9yb3V0ZXIgYXJjaGl0ZWN0dXJlcy9kZXNpZ25zDQrigKIgU29mdHdhcml6ZWQgbmV0 d29ya3MgZm9yIEJpZyBEYXRhIGFwcGxpY2F0aW9ucw0K4oCiIFNvZnR3YXJlLWRlZmluZWQgb3B0 aWNhbCB0cmFuc3BvcnQgbmV0d29ya3MNCuKAoiBEZWJ1Z2dpbmcgYW5kIGludHJvc3BlY3Rpb24g b2Ygc29mdHdhcmUtZGVmaW5lZCAgdmlydHVhbGl6ZWQgc3lzdGVtcw0K4oCiIEF2YWlsYWJpbGl0 eSBhbmQgcmVzaWxpZW5jZSBvZiB2aXJ0dWFsaXplZCBzb2Z0d2FyZS1kZWZpbmVkIHN5c3RlbXMN CuKAoiBWZXJpZmljYXRpb24vQXVkaXRpbmcgdG9vbHMgZm9yIHNvZnR3YXJpemVkIHN5c3RlbXMN CuKAoiBFeHBlcmllbmNlIHJlcG9ydHMgZnJvbSBleHBlcmltZW50YWwgdGVzdGJlZHMgYW5kIGRl cGxveW1lbnRzDQrigKIgTW9iaWxpdHkvU2VjdXJpdHkvU2FmZXR5IHN1cHBvcnQNCuKAoiBOZXcg c2VydmljZSBtb2RlbHMgYW5kIHBhcmFkaWdtcyBlbmFibGVkIGJ5IFNvZnR3YXJpemF0aW9uDQri gKIgU29jaW8tZWNvbm9taWMgaW1wYWN0IGFuZCByZWd1bGF0b3J5IGltcGxpY2F0aW9ucyBmb3Ig U29mdHdhcml6YXRpb24NCg0KUEFQRVIgU1VCTUlTU0lPTg0KQXV0aG9ycyBhcmUgaW52aXRlZCB0 byBzdWJtaXQgb25seSBvcmlnaW5hbCBwYXBlcnMgKHdyaXR0ZW4gaW4gRW5nbGlzaCkgDQpub3Qg cHVibGlzaGVkIG9yIHN1Ym1pdHRlZCBmb3IgcHVibGljYXRpb24gZWxzZXdoZXJlLiBQYXBlcnMg c2hvdWxkIGJlIA0KaW4gSUVFRSAyLWNvbHVtbiBVUy1MZXR0ZXIgc3R5bGUgdXNpbmcgSUVFRSBD b25mZXJlbmNlIHRlbXBsYXRlcywgZm91bmQgDQphdDogDQpodHRwOi8vd3d3LmllZWUub3JnL2Nv bmZlcmVuY2VzX2V2ZW50cy9jb25mZXJlbmNlcy9wdWJsaXNoaW5nL3RlbXBsYXRlcy5odG1sIA0K YW5kIHN1Ym1pdHRlZCBpbiBQREYgZm9ybWF0IHZpYSBKRU1TIGF0OiBodHRwczovL2plbXMuc2Jj Lm9yZy5ici9uZXRzb2Z0MjAxNg0KUGFwZXJzIGNhbiBiZSBvZiB0d28gdHlwZXM6IGZ1bGwgKHVw IHRvIDggcGFnZXMpIG9yIHNob3J0ICh1cCB0byA0IA0KcGFnZXMpLiBQYXBlcnMgZXhjZWVkaW5n IHRoZXNlIGxpbWl0cywgbXVsdGlwbGUgc3VibWlzc2lvbnMsIGFuZCANCnNlbGYtcGxhZ2lhcml6 ZWQgcGFwZXJzIHdpbGwgYmUgcmVqZWN0ZWQgd2l0aG91dCBmdXJ0aGVyIHJldmlldy4gQWxsIA0K c3VibWl0dGVkIHBhcGVycyB3aWxsIGJlIHN1YmplY3QgdG8gYSBwZWVyLXJldmlldyBwcm9jZXNz LiBUaGUgYWNjZXB0ZWQgDQpwYXBlcnMgd2lsbCBiZSBwdWJsaXNoZWQgaW4gSUVFRSBYcGxvcmUs IHByb3ZpZGVkIHRoYXQgdGhlIGF1dGhvcnMgZG8gDQpwcmVzZW50IHRoZWlyIHBhcGVyIGF0IHRo ZSBjb25mZXJlbmNlLiBOb3RlOiBhdXRob3JzIG9mIHRoZSBiZXN0IGZpdmUgDQpwYXBlcnMgd2ls bCBiZSBpbnZpdGVkIHRvIHN1Ym1pdCBleHRlbmRlZCB2ZXJzaW9ucyBvZiB0aGVpciBwYXBlcnMg dG8gYSANCmZhc3QtdHJhY2sgcmV2aWV3ZWQgV2lsZXnigJlzIEludGVybmF0aW9uYWwgSm91cm5h bCBvZiBOZXR3b3JrIE1hbmFnZW1lbnQgDQooSUpOTSkuDQoNCklNUE9SVEFOVCBEQVRFUw0K4oCi IFBhcGVyIHN1Ym1pc3Npb246IE5vdmVtYmVyIDE1LCAyMDE1DQrigKIgTm90aWZpY2F0aW9uIG9m IGFjY2VwdGFuY2U6IEphbnVhcnkgMzEsIDIwMTYNCuKAoiBGaW5hbCBjYW1lcmEgcmVhZHkgcGFw ZXJzOiBNYXJjaCAxNSwgMjAxNg0K4oCiIE5ldFNvZnQgMjAxNiBjb25mZXJlbmNlOiBKdW5lIDYt MTAsIDIwMTYNCg0KR0VORVJBTCBDSEFJUg0KSmFtZXMgV29uLUtpIEhvbmcsIFBPU1RFQ0gsIEtv cmVhDQoNClRQQyBDTy1DSEFJUlMNCkZpbGlwIERlIFR1cmNrLCBHaGVudCBVbml2ZXJzaXR5LWlN aW5kcywgQmVsZ2l1bQ0KSm9vbi1NeXVuZyBLYW5nLCBIUCBMYWJzLCBVU0ENCkh5dW5zZXVuZyBD aG9vLCBTdW5na3l1bmt3YW4gVW5pdmVyc2l0eSwgS29yZWENCg0KVEVDSE5JQ0FMIFNQT05TT1JT DQpUaGUgdGVjaG5pY2FsIHNwb25zb3JzIGFyZSBJRUVFIENvbW11bmljYXRpb25zIFNvY2lldHks IElFRUUgQ29tcHV0ZXIgDQpTb2NpZXR5LCBJRUVFIFNpZ25hbCBQcm9jZXNzaW5nIFNvY2lldHkg YW5kIElFRUUgQ29uc3VtZXIgRWxlY3Ryb25pY3MgDQpTb2NpZXR5Lg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpNeWNvbGxlYWd1ZXMgbWFpbGlu ZyBsaXN0DQpNeWNvbGxlYWd1ZXNAbWFpbG1hbi51ZnNjLmJyDQpodHRwOi8vbWFpbG1hbi51ZnNj LmJyL21haWxtYW4vbGlzdGluZm8vbXljb2xsZWFndWVzDQoNCi0gVGhyb3VnaCB0aGlzIGxpbmsg YWJvdmUgeW91IGNhbiAic3Vic2NyaWJlIiwgInVuc3Vic2NyaWJlIiwgb3IgY2hhbmdlIHlvdXIg c2V0dGluZ3MgaW4gdGhlIGxpc3QsIHVzaW5nICJ1c2VybmFtZT11ZnNjIiBhbmQgInBhc3N3b3Jk PXVmc2MiLg0KLSBJZiB5b3UgbmVlZCBhbnkgaGVscCwgcGxlYXNlIHNlbmQgYSBtZXNzYWdlIHRv IG15Y29sbGVhZ3Vlcy1vd25lckBtYWlsbWFuLnVmc2MuYnIuDQotIEVOSk9ZIHRoaXMgQ09VUlRF U1kgb2ZmZXJlZCBieSBGRURFUkFMIFVOSVZFUlNJVFkgT0YgU0FOVEEgQ0FUQVJJTkEuDQo= From nobody Fri Aug 28 09:31:52 2015 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 20A551B3399; Fri, 28 Aug 2015 09:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qSbufltXDv7Y; Fri, 28 Aug 2015 09:31:46 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558891B32B7; Fri, 28 Aug 2015 09:31:42 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.74.33) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 28 Aug 2015 17:31:25 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.03.0248.002; Fri, 28 Aug 2015 17:31:34 +0100 From: Jonathan Hardwick To: "draft-ietf-pce-pcep-domain-sequence@ietf.org" , "pce-chairs@tools.ietf.org" Thread-Topic: Shepherd review of draft-ietf-pce-pcep-domain-sequence-08 Thread-Index: AdDhrI989YY3CCPrSnSO4vZIuvw+Ng== Date: Fri, 28 Aug 2015 16:31:33 +0000 Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBA0139CBAC62@ENFICSMBX1.datcon.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:0:c05b:bffa:3853:1939:a95a:29a9] Content-Type: multipart/alternative; boundary="_000_09CE6C3BE5E1EA40B987BF5F25D8DDBA0139CBAC62ENFICSMBX1dat_" MIME-Version: 1.0 Archived-At: Cc: "pce@ietf.org" Subject: [Pce] Shepherd review of draft-ietf-pce-pcep-domain-sequence-08 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: Fri, 28 Aug 2015 16:31:51 -0000 --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBA0139CBAC62ENFICSMBX1dat_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there I've performed my WG shepherd review of this draft - here are my comments. = I will wait for a response from the authors and an update before preparing= the shepherd report. Cheers Jon Note to WG Chairs This document depends on two others: draft-ietf-pce-iro-update and draft-ie= tf-teas-rsvp-te-domain-subobjects. All three documents should progress in = step. Higher Level Points What is the use case for being able to mix AS number with the other subobje= ct types? This feels a bit over-engineered to me, as it results in us havin= g to define subtle rules about "changing the AS" in the IRO. I think it is = unlikely that a PCC will know anything about the contents of a neighbouring= AS. Am I missing a use case? Technical Comments Section 3.4.1: This section duplicates draft-ietf-teas-rsvp-te-domain-subob= jects-02 and cannot be present in both (the code points are being allocated= from the same IANA registry). You should remove this section from the doc= ument and instead refer to the TEAS draft. ------ Section 3.4.1.2: IS-IS area IDs can vary from 1 to 13 bytes in length (max = NSAP length is 20, minus 1 byte for NSEL, minus 6 bytes for SysID). This s= hould be fixed in the TEAS draft (I see the drafts have overlap in authors)= . ------ Section 3.4.4, this paragraph: For each inclusion, the PCC clears the L-bit to indicate that the PCE is required to include the domain, or sets the L-bit to indicate that the PCC simply desires that the domain be included in the Domain- Sequence. That's not what the L bit means. If L is set then this is a loose hop, i.e= . the PCE is free to interpose nodes in between this (abstract) node and th= e previous (abstract) node that do not belong to either abstract node. It = does not mean that the given abstract node is optional. If an IRO is given= then the computed path MUST traverse all hops (RFC 5440). This remark als= o applies to the next-but-one paragraph. ------ Section 3.4.4 gives a set of rules for processing the IRO that specify when= the area changes in the IRO, or when the AS changes in the IRO. It took m= e a while to understand why you were doing this. I have one quibble - I do= n't think an unnumbered link can change the AS because its identifiers are = not global, they are only meaningful within the context of an AS. I would give these rules in a different way, as follows. Please let me kno= w whether you think this is clearer. * A PCC may intersperse Area and AS subobjects with other subobject= s without change to the previously specified processing of those subobjects= in the IRO. * When a PCE parses an IRO, it interprets each subobject according = to the AS number associated with the preceding subobject. We call this the= "current AS". Certain subobjects modify the current AS, as follows. o The current AS is initialized to the AS number of the PCC. o If the PCE encounters an AS subobject, then it updates the current AS t= o this new AS number. o If the PCE encounters an Area subobject, then it assumes that the area = belongs to the current AS. o If the PCE encounters an IP address that is globally routable, then it = updates the current AS to the AS that owns this IP address. This document = does not define how the PCE learns which AS owns the IP address. o If the PCE encounters an IP address that is not globally routable, then= it assumes that it belongs to the current AS. o If the PCE encounters an unnumbered link, then it assumes that it belon= gs to the current AS. * * ------ Section 3.5.1 and its subsections will need some updates to refer to the TE= AS draft. ------ In section 3.6, there are a couple of subtleties that you should cover. Firstly, if an EXRS subobject is associated with a different AS than the pr= eceding IRO subobject, should that change the "current AS"? If not, what i= s the meaning of placing such an EXRS in between two IRO subobjects that be= long to the same AS - is that invalid? Secondly, if an EXRS is placed in between two IRO subobjects that are assoc= iated with different ASes, with which AS should the EXRS subobjects be asso= ciated? ------ Section 7.2 A MIB module for management of the PCEP is being specified in a separate document [RFC7420]. That MIB module allows examination of individual PCEP messages, in particular requests, responses and errors. Not actually true - you can't look at individual PCEP messages in the MIB. Editorial Section 1 paragraph 4. Final sentence should be two sentences. Also, use = of "this document" is ambiguous. Suggest: "The use of Autonomous System (AS) (albeit with a 2-Byte AS number) as an a= bstract node representing a domain is defined in [RFC3209]. In the current= document, we specify new subobjects to include or exclude domains, includi= ng IGP areas and Autonomous Systems (4-Byte as per [RFC6793])." ------ Section 1 paragraph 5. It is unclear what this means. Please clarify or d= elete. ------ Section 3.4.3 - I'd prefer to split this section into "PCC Procedures" and = "PCE Procedures". The first paragraph is unnecessary. ------ Section 3.4.4 - these two paragraphs seem to just repeat RFC 5440. I think= they should be removed. If a PCE receives an IRO in a Path Computation request (PCReq) message that contains subobjects defined in this document, that it does not recognize, it will respond according to the rules for a malformed object as per [RFC5440]. The PCE MAY also include the IRO in the PCErr to indicate in which case the IRO SHOULD be terminated immediately after the unrecognized subobject. [...] A successful path computation reported in a path computation reply message (PCRep) MUST include an ERO to specify the path that has been computed as specified in [RFC5440] following the sequence of domains. Ditto the final paragraph of 3.5.1.2. Ditto the final paragraph of 3.7. ------ Section 4 should probably be entitled "Examples" to make it clearer that th= is section contains no normative text. ------ In section 4.1 you should clarify that the endpoints are in areas 2 and 4. Nits Section 1.1 para 1: "specify" -> "specifies" Section 3.2 point 3: "constraint" -> "constrain" Section 3.2 point 4: semicolon should be period. Section 3.4.3 paragraph 4: "comprising of" -> "comprising" Section 3.4.4 "Following processing rules" -> "The following processing rul= es" --_000_09CE6C3BE5E1EA40B987BF5F25D8DDBA0139CBAC62ENFICSMBX1dat_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there

I’ve performed my WG shepherd review of this d= raft – here are my comments. I will wait for a response from th= e authors and an update before preparing the shepherd report.

Cheers

Jon

Note to WG Chairs

This document depends on two others: draft-ietf-pce-= iro-update and draft-ietf-teas-rsvp-te-domain-subobjects. All three d= ocuments should progress in step.

Higher Level Points

What is the use case for being able to mix AS number= with the other subobject types? This feels a bit over-engineered to me, as= it results in us having to define subtle rules about “changing the A= S” in the IRO. I think it is unlikely that a PCC will know anything about the contents of a neighbouring AS. Am= I missing a use case?

Technical Comments

Section 3.4.1: This section duplicates draft-ietf-te= as-rsvp-te-domain-subobjects-02 and cannot be present in both (the code poi= nts are being allocated from the same IANA registry). You should remo= ve this section from the document and instead refer to the TEAS draft.

------

Section 3.4.1.2: IS-IS area IDs can vary from 1 to 1= 3 bytes in length (max NSAP length is 20, minus 1 byte for NSEL, minus 6 by= tes for SysID). This should be fixed in the TEAS draft (I see the dra= fts have overlap in authors).

------

Section 3.4.4, this paragraph:

For each inclusion, the PCC clears the = L-bit to indicate that the PCE

is required to include the domain, or s= ets the L-bit to indicate that

the PCC simply desires that the domain = be included in the Domain-

Sequence.

That’s not what the L bit means. If L is= set then this is a loose hop, i.e. the PCE is free to interpose nodes in b= etween this (abstract) node and the previous (abstract) node that do not be= long to either abstract node. It does not mean that the given abstract node is optional. If an IRO is given then th= e computed path MUST traverse all hops (RFC 5440). This remark also a= pplies to the next-but-one paragraph.

------

Section 3.4.4 gives a set of rules for processing th= e IRO that specify when the area changes in the IRO, or when the AS changes= in the IRO. It took me a while to understand why you were doing this= . I have one quibble – I don’t think an unnumbered link can change the AS because its identifiers are not global, = they are only meaningful within the context of an AS.

I would give these rules in a different way, as foll= ows. Please let me know whether you think this is clearer.=

· A PCC may intersperse Area and AS subobjects= with other subobjects without change to the previously specified processin= g of those subobjects in the IRO.

· When a PCE parses an IRO, it interprets each= subobject according to the AS number associated with the preceding subobje= ct. We call this the “current AS”. Certain subobjec= ts modify the current AS, as follows.

o The current AS is initialized to the AS numb= er of the PCC.

o If the PCE encounters an AS subobject, then = it updates the current AS to this new AS number.

o If the PCE encounters an Area subobject, the= n it assumes that the area belongs to the current AS.

o If the PCE encounters an IP address that is = globally routable, then it updates the current AS to the AS that owns this = IP address. This document does not define how the PCE learns which AS= owns the IP address.

o If the PCE encounters an IP address that is = not globally routable, then it assumes that it belongs to the current AS.

o If the PCE encounters an unnumbered link, th= en it assumes that it belongs to the current AS.

· <Then give similar rules for updating the= current area.>

· <Then explain that the current AS and cur= rent area influence the selection of the next PCE in the chain, in the case= that this PCE does not own the given AS or area.>

------

Section 3.5.1 and its subsections will need some upd= ates to refer to the TEAS draft.

------

In section 3.6, there are a couple of subtleties tha= t you should cover.

Firstly, if an EXRS subobject is associated with a d= ifferent AS than the preceding IRO subobject, should that change the “= ;current AS”? If not, what is the meaning of placing such an EX= RS in between two IRO subobjects that belong to the same AS – is that invalid?

Secondly, if an EXRS is placed in between two IRO su= bobjects that are associated with different ASes, with which AS should the = EXRS subobjects be associated?

------

Section 7.2

A MIB module for management of the PCEP= is being specified in a

separate document [RFC7420]. That= MIB module allows examination of

individual PCEP messages, in particular= requests, responses and errors.

Not actually true – you can’t look at in= dividual PCEP messages in the MIB.

Editorial

Section 1 paragraph 4. Final sentence should b= e two sentences. Also, use of “this document” is ambiguou= s. Suggest:

“The use of Autonomous System (AS) (albeit wit= h a 2-Byte AS number) as an abstract node representing a domain is defined = in [RFC3209]. In the current document, we specify new subobjects to i= nclude or exclude domains, including IGP areas and Autonomous Systems (4-Byte as per [RFC6793]).”

------

Section 1 paragraph 5. It is unclear what this= means. Please clarify or delete.

------

Section 3.4.3 – I’d prefer to split this= section into “PCC Procedures” and “PCE Procedures”= . The first paragraph is unnecessary.

------

Section 3.4.4 – these two paragraphs seem to j= ust repeat RFC 5440. I think they should be removed.

If a PCE receives an IRO in a Path Comp= utation request (PCReq)

message that contains subobjects define= d in this document, that it

does not recognize, it will respond acc= ording to the rules for a

malformed object as per [RFC5440]. = ; The PCE MAY also include the IRO

in the PCErr to indicate in which case = the IRO SHOULD be terminated

immediately after the unrecognized subo= bject.

[…]

A successful path computation reported = in a path computation reply

message (PCRep) MUST include an ERO to = specify the path that has been

computed as specified in [RFC5440] foll= owing the sequence of domains.

Ditto the final paragraph of 3.5.1.2.

Ditto the final paragraph of 3.7.

------

Section 4 should probably be entitled “Example= s” to make it clearer that this section contains no normative text.

------

In section 4.1 you should clarify that the endpoints= are in areas 2 and 4.

Nits

Section 1.1 para 1: “specify” -> R= 20;specifies”

Section 3.2 point 3: “constraint” -> = “constrain”

Section 3.2 point 4: semicolon should be period.

Section 3.4.3 paragraph 4: “comprising of̶= 1; -> “comprising”

Section 3.4.4 “Following processing rules̶= 1; -> “The following processing rules“

--_000_09CE6C3BE5E1EA40B987BF5F25D8DDBA0139CBAC62ENFICSMBX1dat_-- From nobody Fri Aug 28 11:57:16 2015 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 B9C3A1A00BF; Fri, 28 Aug 2015 11:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 BCZ08NrfmXes; Fri, 28 Aug 2015 11:57:08 -0700 (PDT) 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 329DE1A00E3; Fri, 28 Aug 2015 11:57:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWW50501; Fri, 28 Aug 2015 18:57:05 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 28 Aug 2015 19:57:04 +0100 Received: from BLREML509-MBS.china.huawei.com ([169.254.8.175]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0235.001; Sat, 29 Aug 2015 00:27:00 +0530 From: Dhruv Dhody To: Jonathan Hardwick , "draft-ietf-pce-pcep-domain-sequence@ietf.org" , "pce-chairs@tools.ietf.org" Thread-Topic: Shepherd review of draft-ietf-pce-pcep-domain-sequence-08 Thread-Index: AdDhrI989YY3CCPrSnSO4vZIuvw+NgAFkx7g Date: Fri, 28 Aug 2015 18:56:59 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B8C3CB07E@BLREML509-MBS.china.huawei.com> References: <09CE6C3BE5E1EA40B987BF5F25D8DDBA0139CBAC62@ENFICSMBX1.datcon.co.uk> In-Reply-To: <09CE6C3BE5E1EA40B987BF5F25D8DDBA0139CBAC62@ENFICSMBX1.datcon.co.uk> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.195.69.152] Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8C3CB07EBLREML509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "pce@ietf.org" Subject: Re: [Pce] Shepherd review of draft-ietf-pce-pcep-domain-sequence-08 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: Fri, 28 Aug 2015 18:57:14 -0000 --_000_23CE718903A838468A8B325B80962F9B8C3CB07EBLREML509MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Thanks for being the shepherd, I glanced through the comments, will get ba= ck to you start of next week! Regards, Dhruv From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick Sent: 28 August 2015 22:02 To: draft-ietf-pce-pcep-domain-sequence@ietf.org; pce-chairs@tools.ietf.org Cc: pce@ietf.org Subject: [Pce] Shepherd review of draft-ietf-pce-pcep-domain-sequence-08 Hi there I've performed my WG shepherd review of this draft - here are my comments. = I will wait for a response from the authors and an update before preparing= the shepherd report. Cheers Jon Note to WG Chairs This document depends on two others: draft-ietf-pce-iro-update and draft-ie= tf-teas-rsvp-te-domain-subobjects. All three documents should progress in = step. Higher Level Points What is the use case for being able to mix AS number with the other subobje= ct types? This feels a bit over-engineered to me, as it results in us havin= g to define subtle rules about "changing the AS" in the IRO. I think it is = unlikely that a PCC will know anything about the contents of a neighbouring= AS. Am I missing a use case? Technical Comments Section 3.4.1: This section duplicates draft-ietf-teas-rsvp-te-domain-subob= jects-02 and cannot be present in both (the code points are being allocated= from the same IANA registry). You should remove this section from the doc= ument and instead refer to the TEAS draft. ------ Section 3.4.1.2: IS-IS area IDs can vary from 1 to 13 bytes in length (max = NSAP length is 20, minus 1 byte for NSEL, minus 6 bytes for SysID). This s= hould be fixed in the TEAS draft (I see the drafts have overlap in authors)= . ------ Section 3.4.4, this paragraph: For each inclusion, the PCC clears the L-bit to indicate that the PCE is required to include the domain, or sets the L-bit to indicate that the PCC simply desires that the domain be included in the Domain- Sequence. That's not what the L bit means. If L is set then this is a loose hop, i.e= . the PCE is free to interpose nodes in between this (abstract) node and th= e previous (abstract) node that do not belong to either abstract node. It = does not mean that the given abstract node is optional. If an IRO is given= then the computed path MUST traverse all hops (RFC 5440). This remark als= o applies to the next-but-one paragraph. ------ Section 3.4.4 gives a set of rules for processing the IRO that specify when= the area changes in the IRO, or when the AS changes in the IRO. It took m= e a while to understand why you were doing this. I have one quibble - I do= n't think an unnumbered link can change the AS because its identifiers are = not global, they are only meaningful within the context of an AS. I would give these rules in a different way, as follows. Please let me kno= w whether you think this is clearer. * A PCC may intersperse Area and AS subobjects with other subobject= s without change to the previously specified processing of those subobjects= in the IRO. * When a PCE parses an IRO, it interprets each subobject according = to the AS number associated with the preceding subobject. We call this the= "current AS". Certain subobjects modify the current AS, as follows. o The current AS is initialized to the AS number of the PCC. o If the PCE encounters an AS subobject, then it updates the current AS t= o this new AS number. o If the PCE encounters an Area subobject, then it assumes that the area = belongs to the current AS. o If the PCE encounters an IP address that is globally routable, then it = updates the current AS to the AS that owns this IP address. This document = does not define how the PCE learns which AS owns the IP address. o If the PCE encounters an IP address that is not globally routable, then= it assumes that it belongs to the current AS. o If the PCE encounters an unnumbered link, then it assumes that it belon= gs to the current AS. * * ------ Section 3.5.1 and its subsections will need some updates to refer to the TE= AS draft. ------ In section 3.6, there are a couple of subtleties that you should cover. Firstly, if an EXRS subobject is associated with a different AS than the pr= eceding IRO subobject, should that change the "current AS"? If not, what i= s the meaning of placing such an EXRS in between two IRO subobjects that be= long to the same AS - is that invalid? Secondly, if an EXRS is placed in between two IRO subobjects that are assoc= iated with different ASes, with which AS should the EXRS subobjects be asso= ciated? ------ Section 7.2 A MIB module for management of the PCEP is being specified in a separate document [RFC7420]. That MIB module allows examination of individual PCEP messages, in particular requests, responses and errors. Not actually true - you can't look at individual PCEP messages in the MIB. Editorial Section 1 paragraph 4. Final sentence should be two sentences. Also, use = of "this document" is ambiguous. Suggest: "The use of Autonomous System (AS) (albeit with a 2-Byte AS number) as an a= bstract node representing a domain is defined in [RFC3209]. In the current= document, we specify new subobjects to include or exclude domains, includi= ng IGP areas and Autonomous Systems (4-Byte as per [RFC6793])." ------ Section 1 paragraph 5. It is unclear what this means. Please clarify or d= elete. ------ Section 3.4.3 - I'd prefer to split this section into "PCC Procedures" and = "PCE Procedures". The first paragraph is unnecessary. ------ Section 3.4.4 - these two paragraphs seem to just repeat RFC 5440. I think= they should be removed. If a PCE receives an IRO in a Path Computation request (PCReq) message that contains subobjects defined in this document, that it does not recognize, it will respond according to the rules for a malformed object as per [RFC5440]. The PCE MAY also include the IRO in the PCErr to indicate in which case the IRO SHOULD be terminated immediately after the unrecognized subobject. [...] A successful path computation reported in a path computation reply message (PCRep) MUST include an ERO to specify the path that has been computed as specified in [RFC5440] following the sequence of domains. Ditto the final paragraph of 3.5.1.2. Ditto the final paragraph of 3.7. ------ Section 4 should probably be entitled "Examples" to make it clearer that th= is section contains no normative text. ------ In section 4.1 you should clarify that the endpoints are in areas 2 and 4. Nits Section 1.1 para 1: "specify" -> "specifies" Section 3.2 point 3: "constraint" -> "constrain" Section 3.2 point 4: semicolon should be period. Section 3.4.3 paragraph 4: "comprising of" -> "comprising" Section 3.4.4 "Following processing rules" -> "The following processing rul= es" --_000_23CE718903A838468A8B325B80962F9B8C3CB07EBLREML509MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

Thanks for being the shepherd, I glanced t= hrough the comments, will get back to you start of next week!

Regards,

Dhruv =

From: Pce [mai= lto:pce-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 28 August 2015 22:02
To: draft-ietf-pce-pcep-domain-sequence@ietf.org; pce-chairs@tools.i= etf.org
Cc: pce@ietf.org
Subject: [Pce] Shepherd review of draft-ietf-pce-pcep-domain-sequenc= e-08

Hi there

I’ve performed my WG shep= herd review of this draft – here are my comments. I will wait f= or a response from the authors and an update before preparing the shepherd = report.

Cheers

Jon

Note to WG Chairs=

This document depends on two ot= hers: draft-ietf-pce-iro-update and draft-ietf-teas-rsvp-te-domain-subobjec= ts. All three documents should progress in step.

Higher Level Points

What is the use case for being = able to mix AS number with the other subobject types? This feels a bit over= -engineered to me, as it results in us having to define subtle rules about = “changing the AS” in the IRO. I think it is unlikely that a PCC will know anything about the contents of a neigh= bouring AS. Am I missing a use case?

Technical Comments

Section 3.4.1: This section dup= licates draft-ietf-teas-rsvp-te-domain-subobjects-02 and cannot be present = in both (the code points are being allocated from the same IANA registry).&= nbsp; You should remove this section from the document and instead refer to the TEAS draft.

------

Section 3.4.1.2: IS-IS area IDs= can vary from 1 to 13 bytes in length (max NSAP length is 20, minus 1 byte= for NSEL, minus 6 bytes for SysID). This should be fixed in the TEAS= draft (I see the drafts have overlap in authors).

------

Section 3.4.4, this paragraph:<= o:p>

For each inclusion= , the PCC clears the L-bit to indicate that the PCE

is required to inc= lude the domain, or sets the L-bit to indicate that

the PCC simply des= ires that the domain be included in the Domain-

Sequence.

That’s not what the L bit= means. If L is set then this is a loose hop, i.e. the PCE is free to= interpose nodes in between this (abstract) node and the previous (abstract= ) node that do not belong to either abstract node. It does not mean that the given abstract node is optional. If an IRO= is given then the computed path MUST traverse all hops (RFC 5440). T= his remark also applies to the next-but-one paragraph.

------

Section 3.4.4 gives a set of ru= les for processing the IRO that specify when the area changes in the IRO, o= r when the AS changes in the IRO. It took me a while to understand wh= y you were doing this. I have one quibble – I don’t think an unnumbered link can change the AS because i= ts identifiers are not global, they are only meaningful within the context = of an AS.

I would give these rules in a d= ifferent way, as follows. Please let me know whether you think this i= s clearer.

· A PCC may intersperse Area and AS subobjects wi= th other subobjects without change to the previously specified processing o= f those subobjects in the IRO.

· When a PCE parses an IRO, it interprets each su= bobject according to the AS number associated with the preceding subobject.= We call this the “current AS”. Certain subobjects = modify the current AS, as follows.

o The current AS is initialized to the AS number = of the PCC.

o If the PCE encounters an AS subobject, then it = updates the current AS to this new AS number.

o If the PCE encounters an Area subobject, then i= t assumes that the area belongs to the current AS.

o If the PCE encounters an IP address that is glo= bally routable, then it updates the current AS to the AS that owns this IP = address. This document does not define how the PCE learns which AS ow= ns the IP address.

o If the PCE encounters an IP address that is not= globally routable, then it assumes that it belongs to the current AS.=

o If the PCE encounters an unnumbered link, then = it assumes that it belongs to the current AS.

· <Then give similar rules for updating the cu= rrent area.>

· <Then explain that the current AS and curren= t area influence the selection of the next PCE in the chain, in the case th= at this PCE does not own the given AS or area.>

------

Section 3.5.1 and its subsectio= ns will need some updates to refer to the TEAS draft.

------

In section 3.6, there are a cou= ple of subtleties that you should cover.

Firstly, if an EXRS subobject i= s associated with a different AS than the preceding IRO subobject, should t= hat change the “current AS”? If not, what is the meaning = of placing such an EXRS in between two IRO subobjects that belong to the same AS – is that invalid?

Secondly, if an EXRS is placed = in between two IRO subobjects that are associated with different ASes, with= which AS should the EXRS subobjects be associated?

------

Section 7.2

A MIB module for m= anagement of the PCEP is being specified in a

separate document = [RFC7420]. That MIB module allows examination of

individual PCEP me= ssages, in particular requests, responses and errors.

Not actually true – you c= an’t look at individual PCEP messages in the MIB.

Editorial<= /u>

Section 1 paragraph 4. Fi= nal sentence should be two sentences. Also, use of “this docume= nt” is ambiguous. Suggest:

“The use of Autonomous Sy= stem (AS) (albeit with a 2-Byte AS number) as an abstract node representing= a domain is defined in [RFC3209]. In the current document, we specif= y new subobjects to include or exclude domains, including IGP areas and Autonomous Systems (4-Byte as per [RFC6793]).̶= 1;

------

Section 1 paragraph 5. It= is unclear what this means. Please clarify or delete.

------

Section 3.4.3 – I’d= prefer to split this section into “PCC Procedures” and “= PCE Procedures”. The first paragraph is unnecessary.=

------

Section 3.4.4 – these two= paragraphs seem to just repeat RFC 5440. I think they should be remo= ved.

If a PCE receives = an IRO in a Path Computation request (PCReq)

message that conta= ins subobjects defined in this document, that it

does not recognize= , it will respond according to the rules for a

malformed object a= s per [RFC5440]. The PCE MAY also include the IRO

in the PCErr to in= dicate in which case the IRO SHOULD be terminated

immediately after = the unrecognized subobject.

[…]

A successful path = computation reported in a path computation reply

message (PCRep) MU= ST include an ERO to specify the path that has been

computed as specif= ied in [RFC5440] following the sequence of domains.

Ditto the final paragraph of 3.= 5.1.2.

Ditto the final paragraph of 3.= 7.

------

Section 4 should probably be en= titled “Examples” to make it clearer that this section contains= no normative text.

------

In section 4.1 you should clari= fy that the endpoints are in areas 2 and 4.

Nits

Section 1.1 para 1: “spec= ify” -> “specifies”

Section 3.2 point 3: “con= straint” -> “constrain”

Section 3.2 point 4: semicolon = should be period.

Section 3.4.3 paragraph 4: R= 20;comprising of” -> “comprising”

Section 3.4.4 “Following = processing rules” -> “The following processing rules“<= o:p>

--_000_23CE718903A838468A8B325B80962F9B8C3CB07EBLREML509MBSchi_--